<HTML dir=ltr><HEAD></HEAD>
<BODY>
<DIV id=idOWAReplyText79253 dir=ltr>
<DIV dir=ltr><FONT face=Arial color=#000000 size=2>I'm still trying to decide how to apply the standard features of sreg and ax. Above and beyond the standardization of the signals and issues of profiling to maximise compatibility between deployed OPs and deployed generations of RPs, the question in my mind comes down to a need to clearly understand the use cases in the mind of the designer collective, as I slowly peer into the cluster. Then I have to apply these to the reality of our particular deployment environment - which may well not match the intended environment or the assumed telco/infrastructure/outsourcing/TTP vision.</FONT></DIV>
<DIV dir=ltr><FONT face=Arial size=2></FONT> </DIV>
<DIV dir=ltr><FONT face=Arial size=2>1. In sreg, the idea was to auto-populate signup wizards. Detailed inspection of 10 commercial RPs showed that it is not widely used. Where used, it doesn't seem to be really used as intended (one latina dating site being quite the exception.) Its application is also quirky. In blogspot, the nickname determined from sreg became part of the comment, linked to the openid - which when clicked takes one to the OP-hosted identity page for the OpenID URI. Its mostly used for account linking, where sites generally re-confirm the sreg'ed email address ANYWAYS (*).</FONT></DIV>
<DIV dir=ltr><FONT face=Arial size=2></FONT> </DIV>
<DIV dir=ltr><FONT face=Arial size=2>2. Rather than look at AX as a more flexible replacement for SREG, I'm increasingly seeing it as being intended for identity management outsourcing and SP-centric hub management You see this clearly in the email-update demo, shared between skip and myopenid. You have to look at more as an implementation of what saml calls sp affiliations sharing an account linked primary key (the openid URL/canonicalXRI), where the AX protocol facilitates "inter-rp" attribute exchange. The average reader would not infer any of what I just wrote though... from reading the AX protocol spec! But, the skip email-update demo and other disclosures on this list show the service's intent.</FONT></DIV>
<DIV dir=ltr><FONT face=Arial size=2></FONT> </DIV>
<DIV dir=ltr><FONT face=Arial size=2>Now I better understand XRI, and the i-services that are attached to XRI including contacts and forwarding, I know I see AX in quite a different light.</FONT></DIV>
<DIV dir=ltr><FONT face=Arial size=2></FONT> </DIV>
<DIV dir=ltr><FONT face=Arial size=2>Comment</FONT></DIV>
<DIV dir=ltr><FONT face=Arial size=2></FONT> </DIV>
<DIV dir=ltr><FONT face=Arial size=2>There is nothing lightweight or flimsy about OpenID! Apart from its authentication handshake (which can easily be improved with key wrapping and better application of public key control systems), its heavyweight in scope. Whereas the SAML writing is pretty inscrutable and somewhat pretentious, OpenID writing is highly transparent. But, OpenID is also somewhat mischievous - presenting itself as simple and minimalist while actually subscribing (probably intentionally) to Neustar's very, very ambitious goals (e.g. TTP-style authority resolution in a global name directory, ENUM integration for device sync, Telco outsourcing, escrow/key management, PIV card provisioning/issuing, VISA merchant aggregation for PCI compliance, etc. etc.).</FONT></DIV>
<DIV dir=ltr><FONT face=Arial size=2></FONT> </DIV>
<DIV dir=ltr><FONT face=Arial size=2>Peter.</FONT></DIV>
<DIV dir=ltr><FONT face=Arial size=2></FONT> </DIV>
<DIV dir=ltr><FONT face=Arial size=2></FONT> </DIV>
<DIV dir=ltr><FONT face=Arial size=2>(*) OpenID specs hardly discuss the concept of the micro-formatted Identity Page, for each openid: the FOAF-killer. But, contrast <A href="http://homepw.myopenid.com/" target=_blank>http://homepw.myopenid.com/</A> which discloses publicly stuff I really don't want disclosed using both HTML and semantic annotation vs <A href="http://rapattoni.trustbearer.com/lockbox" target=_blank>http://rapattoni.trustbearer.com/lockbox</A> where data release requires first authenticating the requestor's PIV/CAC/muscle SIM. To be fair to JanRain, in the course of researching this note, I learned about the capability to manually apply persona-based access controls to myopenid - but this stuff was public for months after a confusing signup. I've left all the personal data disclosed , since its been crawled a billion times by now.</FONT></DIV>
<DIV dir=ltr><FONT face=Arial color=#000000 size=2></FONT> </DIV></DIV>
<DIV id=idSignature75764>
<DIV><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>
<HR tabIndex=-1>
<FONT face=Tahoma size=2><B>From:</B> Patrick Aljord<BR><B>Sent:</B> Tue 4/1/2008 10:56 PM<BR><B>To:</B> OpenID List<BR><B>Subject:</B> Re: [OpenID] openid and hcard<BR></FONT><BR></DIV>
<DIV><PRE style="WORD-WRAP: break-word">Thanks a lot Tom for your great explanation, you've confirmed my
doubts though that the situation is kind of mess. I suppose that
people will move to AX if they want to support other fields than
sreg's (such as im, image etc), so hopefully they'll make the switch
eventually.
_______________________________________________
general mailing list
general@openid.net
http://openid.net/mailman/listinfo/general
</PRE></DIV></BODY></HTML>