<HTML dir=ltr><HEAD></HEAD>
<BODY>
<DIV id=idOWAReplyText15913 dir=ltr>
<DIV dir=ltr><FONT face=Arial color=#000000 size=2>"How to apply openid to linked data and semweb agents?" is a harder question to answer than I ever imagined it would be.</FONT></DIV>
<DIV dir=ltr><FONT face=Arial color=#000000 size=2></FONT> </DIV>
<DIV dir=ltr><FONT face=Arial color=#000000 size=2>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". </FONT></DIV>
<DIV dir=ltr><FONT face=Arial size=2></FONT> </DIV>
<DIV dir=ltr><FONT face=Arial><FONT size=2>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).</FONT></FONT></DIV>
<DIV dir=ltr><FONT face=Arial size=2></FONT> </DIV>
<DIV dir=ltr><FONT face=Arial size=2>In Figure 5 of </FONT><FONT face=Arial color=#000000 size=2><A href="http://www.projectliberty.org/liberty/content/download/319/2369/file/draft-liberty-idff-bindings-profiles-1.2-errata-v2.0.pdf" target=_blank>http://www.projectliberty.org/liberty/content/download/319/2369/file/draft-liberty-idff-bindings-profiles-1.2-errata-v2.0.pdf</A>, 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.</FONT></DIV>
<DIV dir=ltr><FONT face=Arial size=2></FONT> </DIV>
<DIV dir=ltr><FONT face=Arial size=2>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_. </FONT></DIV>
<DIV dir=ltr><FONT face=Arial size=2></FONT> </DIV>
<DIV dir=ltr><FONT face=Arial size=2>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.</FONT></DIV>
<DIV dir=ltr><FONT face=Arial size=2></FONT> </DIV>
<DIV dir=ltr><FONT face=Arial size=2>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. </FONT><FONT face=Arial size=2>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.</FONT></DIV>
<DIV dir=ltr><FONT face=Arial color=#000000 size=2></FONT> </DIV></DIV>
<DIV id=idSignature61779>
<DIV><FONT face=Arial color=#000000 size=2><SPAN style="FONT-SIZE: 7.5pt">_________________________<BR></SPAN><B>Peter Williams<BR></B></FONT><BR>
<HR tabIndex=-1>
<FONT face=Tahoma size=2><B>From:</B> Story Henry<BR><B>Sent:</B> Mon 4/21/2008 8:07 AM<BR><B>To:</B> OpenID General<BR><B>Subject:</B> Re: [OpenID] OpenId sequence diagram<BR></FONT><BR></DIV></DIV>
<DIV><PRE style="WORD-WRAP: break-word">_______________________________________________
general mailing list
general@openid.net
http://openid.net/mailman/listinfo/general
</PRE></DIV></BODY></HTML>