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

[Peter Williams]

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).










-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.foaf-project.org/pipermail/foaf-protocols/attachments/20111029/e6e1d823/attachment.htm