[OpenID] OpenId sequence diagram

Peter Williams pwilliams at rapattoni.com
Sun Apr 27 19:59:57 UTC 2008


"How to apply openid to linked data and semweb agents?" is a harder question to answer than I ever imagined it would be.

Over the last 12 months, I've built up a pretty complete design-history for myself, linking up a rich history of open standards SSO schemes ending at OpenID2. This started with the chained SSO model in 1986-era X.500, through Kerberos-centralist world of the NOS-based network, through distributed PKI-based military messaging a la MISSI/P.772, through RSA's inter-domain cookie issuing by isap/nsapis allow for remote reliance on SecurID tokencodes, to S2ML/SAML push/pull artifacts and websso, to recent Liberty ID-FF profiling for different classes of UAs, to OpenID1 for UCI and OpenID2 for UCI & XRI-based authority resolution environments. This of course just all leads to Henry's own profiling efforts of all that "wealth of stuff" ...for the world of the "linked data". 

Since OpenID Auth v2 seems rather weak as it applies to all the various flavors of web services (or comes with rather too much javascript or DOM-centric religion, where it does apply), I've been focusing on SAML2's "ECP view" of the world - as a stepping stone between the web culture for SSO (that is now commodity) and web services SSO culture (that is emerging - in as yet heavyweight models). In parallel, I'm trying to see which bits of Liberty/SAML2 IDP discovery (via common domain cookie services) are actually useful and viable, as they MIGHT apply  to ECP trust-fabric switching. My notion is that once something all works, viably, then one can turn back to OpenID extensions standardization to bring down the bar (and the cost).

In Figure 5 of  http://www.projectliberty.org/liberty/content/download/319/2369/file/draft-liberty-idff-bindings-profiles-1.2-errata-v2.0.pdf, we see a diagram of somewhat similar complexity to your own original diagram of "OpenID2 meets Semweb agents"- to which you later drew contrasts. Of course, the Fig 5 diagram targets a custom UA (not a browser), much like a semweb UA, perhaps.

I don't fully understand the rationales of all the design elements and the messages shown in that diagram; and I don't fully understand which specs control which bits of the ECP profile's protocol stack (SAML2 contributes a bit, as does the Liberty-controlled PAOS spec, as does Liberty ID-FF - apparently). But I _have_ made some practical progress - trying to see if ECP technology from open sources is approaching commodity status - such that the likes of me ...with low-end programming skills ...can now also participate, _finally_. 

On that practical path, I do now "amended" the open source Shib2 SP server src, so it essentially does steps 1 - 3, using a developer UA. And, I built Peter Pritchard's openliberty ECP plugin for Firefox - which, placed in a browser container, would do the "signal handling" assumed in the space between steps 3 and 4. With a bit more effort or help, I may even get it to work and actually talk to the Shib2 SP-side SAML server. But I'm already worried, since it brings alot of Mozilla-relegion and implementation-centric baggage.

Once all that works once, however,  I'm likely to abandon the effort to actually apply the openliberty client - since it focuses on browser-based, user-centered UI for Selecting IDPs, in a "lets-go-compete" with cardspace and JanRain's idselector.com mission). Rather, I may to back to applying my own data-centric/metadata-aware UA as the ECP agent, which is similar to your semweb user agent I suspect. And there, "trustworthy" metadata will guide the switching path chosen through the SP->IDP trust fabric, rather than users. Now, I have various patented techniques and other IP I can (privately) call on to accomplish automatic, trust-metric-based switching in an XRI-style tree walking environment, and you of course have the alternative W3C:WOT and PGP traditions to call on - addressing the FOAF tradition. Once the overall flow is right using a variety of modern, trust fabric infrastructures, perhaps the trick will be to then cast it all in terms of simple, OpenID extensions.

_________________________
Peter Williams



From: Story Henry
Sent: Mon 4/21/2008 8:07 AM
To: OpenID General
Subject: Re: [OpenID] OpenId sequence diagram


_______________________________________________
general mailing list
general at openid.net
http://openid.net/mailman/listinfo/general
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20080427/200c7583/attachment-0002.htm>


More information about the general mailing list