<HTML dir=ltr><HEAD><TITLE>Re: [OpenID] OpenID Description?</TITLE></HEAD>
<BODY>
<DIV id=idOWAReplyText55528 dir=ltr>
<DIV dir=ltr><FONT face=Arial color=#000000 size=2>There were two things I learned from the discovery paper by Reed et al - which I'm still thinking about. So it had impact! (...as a really good paper should.) As I tried to sort each of them in my mind, I found myself trying to relate the issue set to how, 15+ years ago, we used - as the (RP) agent receiving a user's signed query (SSO assertion supporting a web service call, in modern parlance) - to try to walk the internal name context references built into the knowledge system within the X.500 tree to gather a reverse chain of X.509 cross-certificates, where the query resolver algorithm constraints were assumed to ensure/assure that only (multi-)master agents could contribute to the trusted tree walk. This was merely the opposite use case to Lampson's famous tree walking authentication logic, attempting to assign from the collection of cross-certs a confidence level to the originator's keying material - allowing a community of RPs operating under a common security policy to rely thereby on trusted key distribution to act as an implicit access control system (enforcing a control regime that ensured that only _authorized_ RPs would get access to certain ciphertext tokens , persisted as encrypted elements of more complex assertions). </FONT></DIV>
<DIV dir=ltr><FONT face=Arial size=2></FONT> </DIV>
<DIV dir=ltr><FONT face=Arial size=2>But, enough of history and dead standards. Thinking openly about something modern and pertinent:-</FONT></DIV>
<DIV dir=ltr><FONT face=Arial color=#000000 size=2></FONT> </DIV>
<DIV dir=ltr><FONT face=Arial color=#000000 size=2>1. I learned to clearly distinguish cardspace discovery from openid2 discovery, and to distinguish each of those from cardspace+openid discovery. I had previously assumed that all three were merely different protocol-level mechanisms attempting to provide the directed identity (law#4) security service (which admittedly, I didn't even understand until 6 month ago). The paper introduced me the idea of distinguishing subcases of law#4, using the unique discovery properties as the criterion. Viewing cardspace and openid-auth and cardspace+openid each as a mechanism attempting to provide a common security service known as"law#4", we really do surely obtain criteria for determining the "effectiveness" of each candidate. Alternatively, one could argue that we are learning to engineer the "component semantics" of law#4 as distinct security services.</FONT></DIV>
<DIV dir=ltr><FONT face=Arial size=2></FONT> </DIV>
<DIV dir=ltr><FONT face=Arial size=2>2. I learned about the need to distinguish the RP view vs. the OP view of identifier provisioning and lifecycle management, to then distinguish the properties of URL fragments from the properties of XRI resolution, to understand the limits of the URL fragment approach, and to understand how the interaction of XRI resolution and the assertion of the claimed identity leads to a core trust apparatus addressing issues of authority. There was a lovely example given where two authorities can be each responsible for the i-number vs. i-name, showing that the means exists within (trusted) resolution to distinguish authoritative vs. non-authoritative claims. For example, there was the test to make a determination whether an id (*) is _authoritatively_ provisioned, at the time of name resolution. Assuming that different responders are producing, in the general case, different elements of the XRDS, we got to see how a signed assertion _within_ a query response allows one to test that the different query result components can each show they all satisfy a common security policy. (**)</FONT></DIV>
<DIV dir=ltr><FONT face=Arial size=2></FONT> </DIV>
<DIV dir=ltr><FONT face=Arial size=2>On 2, it would be fun to read more on this last point. I can see how labels in the signed assertions within each XRD can be used with different lattices, enabling the RP to enforce technical security policies such as good ol MAC in MLS environments. Similarly, searching for a particular sequence of XRDs (XRD plural) to conform an XRDS (the final closure sequence) that always enforces the MAC constraints as one tree walks would also lead to a trusted resolution - imposing a _desired_ trust model as a consequence of the act of closure.</FONT></DIV>
<DIV dir=ltr><FONT face=Arial size=2></FONT> </DIV>
<DIV dir=ltr><FONT face=Arial size=2>Of course, this very telematic/telco-centric kind of trust modeling is quite different in style to the reputation-feedback trust model that is commonly association with openid, when openid is thought of in the web2.0 space. But you get to see how telco trust and web2.0 trust are starting to converge, just as device addressing/provisioning is converging with internet provisioning issues. I'm going to perhaps guess that just as the paper distinguishes URL fragments from XRI properties on the issue of identifier reuse (using controls similar to those introduced by DEC(**) in the X.509 v2 (yes v2) certificate for almost identical reasons), one can now distinguish the feedback model suited to URL trust management and modeling from the resolution model suited to XRI-based trust management and modeling.</FONT></DIV>
<DIV dir=ltr><FONT face=Arial size=2></FONT> </DIV>
<DIV dir=ltr><FONT face=Arial size=2>(*) or a public key, I assume, where the key is the id - in the IETF SPKI sense</FONT></DIV>
<DIV dir=ltr><FONT face=Arial size=2></FONT> </DIV>
<DIV dir=ltr><FONT face=Arial size=2>(**) For the first time, I think I caught a glimmer of understanding why SAML has signed assertions, in addition to signed requests/responses. Always wondered about that! Reminds me to go study the SAML profiles tuned for XCAML and name serving, vs websso</FONT></DIV>
<DIV dir=ltr><FONT face=Arial size=2></FONT> </DIV>
<DIV dir=ltr><FONT face=Arial size=2>(**) Hoyt Kesterson was at RSA and as the ISO editor of X.5xx at the time of all the DEC contributions to the trusted directory standardization work in ISO/CCITT, he still has all the formal contributions ITU/ISO members made in that period to either ITU or ISO, including all the formal disclosures (under rules of international law) and all the unpublished drafts and working materials only available to committee members and the national standards bodies. It might be useful to do formal documentary research on all that material to now drawup parallels with the development of trusted XRI resolution. Assuming XRI takes off, this will be valuable later, to get the prior art sorted -- to help resolve the inevitable patent wars. </FONT><FONT face=Arial size=2></FONT></DIV>
<DIV dir=ltr><FONT face=Arial size=2></FONT> </DIV></DIV>
<DIV id=idSignature16299 dir=ltr>
<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> Peter Williams<BR><B>Sent:</B> Thu 4/17/2008 5:16 PM<BR><B>To:</B> Drummond Reed; openid-general List<BR><B>Subject:</B> Re: [OpenID] OpenID Description?<BR></FONT><BR></DIV></DIV>
<DIV dir=ltr>
<DIV id=idOWAReplyText51976 dir=ltr>
<DIV dir=ltr><FONT face=Arial color=#000000 size=2>The Reed et al paper argues that discovery is key. And who can argue with that! (NSA semantic joke!) Its a pretty convincing statement of current activity, c2008. The main flaw in the paper is its failure to recognize its fore-bears: X.500 name resolution. That flaw raises particular questions about the truth of the argument's claims, since X.500 was only a codification of other research-grade secure name server schemes, by ISO, long long long ago. Its most significant fact, for me, was to clarify that Higgins is really all about owl and rdf, and a meta-directory schema that assume rdf-capable UAs. It's most significant revelation was: that an XRD could contain a signed assertion (formatted using a SAML blob) that an RP may use to _control_ the later stages of name/key/canonicalID resolution.</FONT></DIV>
<DIV dir=ltr><FONT face=Arial size=2></FONT> </DIV>
<DIV dir=ltr><FONT face=Arial size=2>I could not deduce the final message of the Fletcher slide show. If I have not said it in a while, remember that I'm not that bright/intelligent... so don't worry. Some of its Microsoft references were worrying.</FONT></DIV>
<DIV dir=ltr><FONT face=Arial size=2></FONT> </DIV>
<DIV dir=ltr><FONT face=Arial color=#000000 size=2><SPAN style="FONT-SIZE: 7.5pt">_________________________<BR></SPAN><B>Peter Williams<BR></B></FONT></DIV></DIV>
<DIV dir=ltr><BR></DIV>
<DIV dir=ltr>
<HR tabIndex=-1>
</DIV>
<DIV dir=ltr><FONT face=Tahoma size=2><B>From:</B> Drummond Reed<BR><B>Sent:</B> Thu 4/17/2008 12:01 PM<BR><B>To</B></FONT></DIV>
<DIV dir=ltr><FONT face=Tahoma size=2><B>:</B> Stephen Edgar; openid-general List<BR><B>Subject:</B> Re: [OpenID] OpenID Description?<BR></FONT><BR></DIV>
<DIV>
<P><FONT size=2>Stephen,<BR><BR>Unfortunately, as much as you would expect <A href="http://openid.org/" target=_blank>http://openid.org/</A> to represent<BR>the OpenID Foundation, it does not (the owners said they wanted to donate<BR>the domain to the OpenID Foundation but they did not). The official OpenID<BR>Foundation site is at <A href="http://openid.net/" target=_blank>http://openid.net/</A>. I'm sincerely hoping that the<BR>information you find there is not "sales blarney".<BR><BR>Second, the fourth assumption on your bullet list below - "the intention<BR>that each person have only one id" - is definitely not true. A key feature<BR>of OpenID 2.0 is widely referred to as "directed identity" after Kim<BR>Cameron's Fourth Law of Identity<BR>(<A href="http://www.identityblog.com/stories/2005/05/13/TheLawsOfIdentity.pdf" target=_blank>http://www.identityblog.com/stories/2005/05/13/TheLawsOfIdentity.pdf</A>). This<BR>feature allows a user to login to a relying party (RP) with the identifier<BR>of their OpenID Provider (OP) rather than their own identifier, and for the<BR>OP to generate a pairwise unique OpenID identifier for the user at that<BR>particular RP.<BR><BR>If you want a deeper analysis of that feature, plus other privacy-related<BR>features of OpenID, one reference is a paper on OpenID discovery I gave last<BR>month at the IDtrust Symposium:<BR><BR> <BR><A href="http://middleware.internet2.edu/idtrust/2008/papers/01-reed-openid-xri-xrds" target=_blank>http://middleware.internet2.edu/idtrust/2008/papers/01-reed-openid-xri-xrds</A>.<BR>pdf <BR><BR>George Fletcher of AOL also gave another OpenID paper there:<BR><BR> <BR><A href="http://middleware.internet2.edu/idtrust/2008/slides/11-fletcher-openid.pdf" target=_blank>http://middleware.internet2.edu/idtrust/2008/slides/11-fletcher-openid.pdf</A><BR><BR>Hope this helps,<BR><BR>=Drummond<BR><BR>> -----Original Message-----<BR>> From: general-bounces@openid.net [<A href="mailto:general-bounces@openid.net" target=_blank>mailto:general-bounces@openid.net</A>] On<BR>> Behalf Of Stephen Edgar<BR>> Sent: Thursday, April 17, 2008 2:38 AM<BR>> To: openid-general List<BR>> Subject: [OpenID] OpenID Description?<BR>><BR>> Hi OpenID List!<BR>><BR>> This is my first post to the list and I am not bad myself on understanding<BR>> OpenID and some implementations on the tech front though I received via<BR>> another mail list the following and was hoping someone could point me to<BR>> some articles/links to address the following:-<BR>><BR>> <snip><BR>> Can anyone point to an accessible description of OpenID?<BR>><BR>> Like a lot of open source, the sites and the documentation are very<BR>> much by-geeks/for-geeks.<BR>><BR>> I suspect that it's just a latter-day MS Passport, but with:<BR>> - open specs<BR>> - more adopters (among corporations, if not among people)<BR>> - the scope for stronger linkage between the id and the entity<BR>> - the intention that each person have only one id<BR>><BR>> But I'd welcome any leads to a description or analysis somewhere<BR>> between the sales blarney at: <A href="http://www.openid.org/" target=_blank>http://www.openid.org/</A><BR>> and the highly segmented and detailed (and of course necessary)<BR>> tech-speak at: <A href="http://openid.net/developers/specs/" target=_blank>http://openid.net/developers/specs/</A><BR>><BR>> Thanks!<BR>><BR>> Roger Clarke <A href="http://www.anu.edu.au/people/Roger.Clarke/" target=_blank>http://www.anu.edu.au/people/Roger.Clarke/</A><BR>> Visiting Professor in Info Science & Eng Australian National University<BR>> Visiting Professor in the eCommerce Program University of Hong Kong<BR>> Visiting Professor in the Cyberspace Law & Policy Centre Uni of NSW<BR>> </snip><BR>><BR>><BR>> Regards,<BR>><BR>> Stephen Edgar<BR>> Stephen@netweb.com.au<BR>><BR>> _______________________________________________<BR>> general mailing list<BR>> general@openid.net<BR>> <A href="http://openid.net/mailman/listinfo/general" target=_blank>http://openid.net/mailman/listinfo/general</A><BR><BR>_______________________________________________<BR>general mailing list<BR>general@openid.net<BR><A href="http://openid.net/mailman/listinfo/general" target=_blank>http://openid.net/mailman/listinfo/general</A><BR></FONT></P></DIV></DIV></BODY></HTML>