[foaf-protocols] small window of foaf opportunity in realty

[Melvin Carvalho]

On 29 October 2011 18:07, Peter Williams <pwilliams at rapattoni.com> wrote:
> I need help – on a topic that is small. No religion or architecture is
> wanted. I don’t want to be converted, or be preached to. I just want to
> point a national infrastructure system (US realty) to a foaf card, and get
> something useful out of the exercise. The entire coding effort must be less
> than 1 hour.
>
>
>
> In our realty world, we have adopted the homerealm pattern. Go to a
> protected resource and the guard no longer directs you to the login page,
> for authentication. It will direct you, by tenant, to a “home realm”
> selector. You then pick your authentication IDP (which duely presents a
> login page for authentication). The various protocol and trust models of
> websso hook things back together. Let’s say the selected IDP is google.
> Let’s say the home realm selector is azure/ACS. Let’s say the resource is an
> “MLS” website. (MLS is multiple listing service for real property, in US
> realty land). Lets say some combo of OAUTHv2/openidv2/SAML2/ws-fedp08 is the
> websso glue hooking it all together. Be assured that all that stuff works
> well, and is already in production and being used by a million folks,
> seamlessly.
>
>
>
> In our deployment concept, we have gone one step beyond the above. One of
> the guarded resources at the MLS website that can fire off all the chain of
> events described above is itself a page of links. Following these links
> induces a further act of websso, in which an assertion is released to some
> other website. Perhaps it’s a mashup concept.
>
>
>
> It’s not the IDP that asserts, note. The asserting party is the MLS site
> (that was a relying party, in the first flow). This idea is not that
> different from what SAML2 calls an “IDP proxy”. SAML2 proxying controls that
> enable one IDP to “govern” another (its proxy) are NOT in effect, however.
> This is because the environment is not pure SAML2 (being some typical web
> technology mess of OAUTH, and ws-fedp, and openid, and …)
>
>
>
> Learning from Henry about webiness, I have the page responding various
> document type, according to http headers. It delivers signed jsonp, for the
> world of jquery UI-building sites. It delivers HTML, for web browsers. It
> delivers RSS to the world of feed readers, including those embedded in
> non-browser desktop tools that do lots of web services (such as the Outlook
> MUA). It even delivers a feed object via a web service.
>
>
>
> It’s in that ordinary “browser RSS” space that Id like now, at the cost of
> 1h, to attribute an item (a link that induces an assertion release remember)
> with an author – using a Person class and using the RSS conventions
> concerning Persons. And, I’d like that Personhood to be delivered by,
> related to, or otherwise getting to the Person class/type/concept/notion
> represented in a FOAF card “out there” [somewhere] in the web (if it
> exists). AS a result of that hopefully trivial integration, the next step
> would be to finally connect up the personhood (in the foaf card) to the
> certificates (in that foaf card) – and thus to the webid capabilities.
>
>
>
> Any ideas? I just want to leverage a foaf card, in an RSS context, enabling
> someone consuming a feed of assertion-inducing links to be able to click and
> see (via the browser) that which the linked foaf card leads to  (and that’s
> all).

Which version of RSS are you using?  Got some sample output?

>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
> foaf-protocols mailing list
> foaf-protocols at lists.foaf-project.org
> http://lists.foaf-project.org/mailman/listinfo/foaf-protocols
>