<HTML dir=ltr><HEAD><TITLE>Re: [OpenID] moving onto inames inumbers ibrokers .. or at least tryingto</TITLE></HEAD>
<BODY>
<DIV id=idOWAReplyText78896 dir=ltr>
<DIV dir=ltr><FONT face=Arial color=#000000 size=2>John: thanks for supplying the mental model to use. This got me back to trying to make something work with XRIs per the model -- and using actually live/beta services:-</FONT></DIV>
<DIV dir=ltr><FONT face=Arial size=2></FONT> </DIV>
<DIV dir=ltr><FONT face=Arial size=2>I also tried <A href="http://www.freexri.com/user/Login/" target=_blank>http://www.freexri.com/user/Login/</A>. This vendor's service allows me to also register a (no-fee) XRI, and even login locally using the XRI name form (with a password, but no infocard, yet). This got me a little beyond freeid (where I could not login locally, by any means, to configure SEPs). However, I cannot get the <FONT face=Arial size=2>freexri.org's </FONT>openid consumer to work, even targeting is own account management webservices. All input (XRI, HXRIs, http URLs, and "openid user input" ) all invoke a common exception. Just another bug on their part this time, Im sure.</FONT></DIV>
<DIV dir=ltr><FONT face=Arial size=2></FONT> </DIV>
<DIV dir=ltr><FONT face=Arial size=2>Anyways, I did set up @blog*lockbox as the only alias that is authoritative for releasing SEPs. Then, I set up the @blog*lockbox forwarding service to point to my <A href="http://rapattoni.trustbearer.com/lockbox" target=_blank>http://rapattoni.trustbearer.com/lockbox</A> openid. Used at my own consumer, this all DOES NOW work - as one can tryout at </FONT><FONT face=Arial size=2><A href="http://rapattoni.trustbearer.com/consumer/try_auth.php?action=verify&openid_identifier=@blog*lockbox" target=_blank>http://rapattoni.trustbearer.com/consumer/try_auth.php?action=verify&openid_identifier=@blog*lockbox</A></FONT></DIV>
<DIV dir=ltr><FONT face=Arial size=2></FONT> </DIV>
<DIV dir=ltr><FONT face=Arial size=2>I think this means, for the first time, that I'm FINALLY using a "non-OP" hosted XRDS file. This matches what I was able to do in blogger's HTML file, using openid1-era metadata tags.</FONT></DIV>
<DIV dir=ltr><FONT face=Arial size=2></FONT> </DIV>
<DIV dir=ltr><FONT face=Arial size=2>Now Ill try a harder case, of having @blog*lockbox map to <A href="x-excid://DE250000/uri:http://xri.net/@freeid*lockbox" target=_blank><FONT face=Arial size=2>http://xri.net/@freeid*lockbox</FONT></A> (and then to @freeid*lockbox, and thereafter <A href="http://xri.net/@freeid*lockbox" target=_blank>http://xri.net/@freeid*lockbox</A>)</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></FONT> </DIV>
<DIV dir=ltr><FONT face=Arial size=2></FONT> </DIV>
<DIV dir=ltr><FONT face=Arial size=2>Following up your email, I finally stopped analysing specifications and just observed some OpenID2 messages using an http(s) spying/intercepting proxy (much like I did last year, for JanRain's earlier Openid1-centric .NET code),</FONT></DIV>
<DIV dir=ltr><FONT face=Arial size=2></FONT> </DIV>
<DIV dir=ltr><FONT face=Arial size=2>My mental model has simplified down to 5 rules:</FONT></DIV>
<BLOCKQUOTE dir=ltr style="MARGIN-RIGHT: 0px">
<DIV dir=ltr><FONT face=Arial size=2>I. When some or other "user -controlled" HTML/XRDS file is the discovery provider, "send" an (unasserted) claimed_id to RP via YADIS response</FONT></DIV>
<DIV dir=ltr><FONT face=Arial size=2></FONT> </DIV>
<DIV dir=ltr><FONT face=Arial size=2>II. When OP#1 acts as a "discovery-redirector", send an <EM>asserted</EM> claimed-id to the RP via id_resp (solicited only) that does not match openid.identity in the auth id_req</FONT></DIV>
<DIV dir=ltr><FONT face=Arial size=2></FONT> </DIV>
<DIV dir=ltr><FONT face=Arial size=2>III. Given RP detection of an OP#1's "restart-discovery signal" (**), RP <FONT face=Arial size=2>MAY/SHOULD </FONT>normalize the asserted OP#1. id_resp.claimed_id and issue a YADIS request</FONT></DIV>
<DIV dir=ltr><FONT face=Arial size=2></FONT> </DIV>
<DIV dir=ltr><FONT face=Arial size=2>IV. When OP#n acts as an asserting party, RP MUST treat un-normalized <FONT face=Arial size=2>OP#1.id_resp.claimed_id as a "primary key" (i.e. retain fragments <url>#x#xy#xyz when claimed_id has HTTP form)</FONT></FONT></DIV>
<DIV dir=ltr><FONT face=Arial size=2><FONT face=Arial size=2></FONT></FONT> </DIV>
<DIV dir=ltr><FONT face=Arial size=2><FONT face=Arial size=2>V. RP may account link the primary key from an asserting OP (either a solicited or unsolicited <FONT face=Arial size=2>OP#1.id_resp.claimed_id) using any </FONT>identity management system. One such linking system could even auto-enroll the user with a new openid administered by the RP...</FONT></FONT></DIV></BLOCKQUOTE>
<DIV dir=ltr><FONT face=Arial size=2>About the only thing Im not clear on is a sub-case of V: shall an OP shall always send an XRI primary key (in canonical form) using XRI URI form, or may it use HXRI form? Is there are difference to an RP, if so?</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></FONT> </DIV>
<DIV dir=ltr><FONT face=Arial size=2>(**) Note: Peter defined term, for the "discovery-redirector" condition of Roman II</FONT></DIV>
<DIV dir=ltr><FONT face=Arial size=2></FONT> </DIV>
<DIV dir=ltr><FONT face=Arial color=#000000 size=2></FONT> </DIV></DIV>
<DIV id=idSignature94904>
<DIV>
<HR tabIndex=-1>
<FONT face=Tahoma size=2><B>From:</B> John Bradley<BR><B>Sent:</B> Fri 3/21/2008 4:14 PM<BR><B>To:</B> Peter Williams<BR><B>Cc:</B> general@openid.net; Michael Mell; Markus Sabadello; William Tan; les chasen; Drummond Reed<BR><B>Subject:</B> Re: [OpenID] moving onto inames inumbers ibrokers .. or at least tryingto<BR></FONT><BR></DIV></DIV>
<DIV>
<P><FONT size=2>Peter,<BR><BR>You seem to have a bunch of issues. Feel free to email me directly <BR>and I will try to help you sort it out.<BR><BR>xri://@!4E3C.6E35.633A.FD2A!729B.7E1E is the iNumber or canonical ID <BR>for @freeid*lockbox<BR><BR>The problem is that the RP is sending that as the openid.identity <BR>rather than @freeid*lockbox<BR><BR>As iNames support a Polyarchical relationship ie more than one iName <BR>may resolve to the same iNumber.<BR><BR>The notion is that the iNumber should be used as the openid.claimed_id <BR>and become the primary key allowing any iName resolving to that <BR>iNumber access to the RP.<BR><BR>This is the way that Plaxo is set up. They are sending the iName in <BR>the openid.identity so that it displays properly. My guess is that <BR>Rapattoni/trustbearer consumer is sending the iNumber in both fields.<BR><BR>You are going to the same openID endpoint in both cases but the <BR>Identity displayed is different because the RPs are sending different <BR>identifiers in the openid.identity to be validated. @!4E3C.<BR>6E35.633A.FD2A!729B.7E1E and @freeid*lockbox are effectively synonyms <BR>from the OP's point of view and should authenticate both with the same <BR>password.<BR><BR>I don't know the URL for the Rapattoni/trustbearer consumer so I cant <BR>test it myself at the moment. I see there OP but not a obvious RP.<BR><BR>I need to check to see if infocard login is enabled on Linksafe's free <BR>site. It is working on the regular site.<BR><BR>You can create your own community at Linksafe and delegate names if <BR>you like. ie @trustbearer*lockbox<BR><BR>You could also purchase an iName and run your own community registry. <BR>Though the cost beyond that of a single iName for using Linksages <BR>registry for delegated names small to non existent depending on the <BR>size of the community.<BR><BR>Contact me directly and I will see if I can get you sorted out.<BR><BR>Regards<BR>=jbradley<BR><BR>PS no I don't subscribe to this list.<BR><BR>On 21-Mar-08, at 2:57 PM, Drummond Reed wrote:<BR>> Peter,<BR>><BR>> I’m cc’ing five folks who can help but whom may not be monitoring <BR>> this list closely:<BR>><BR>> 1) John Bradley at Wingaa/ooTao (the wholesale i-broker on whose <BR>> platform LinkSafe operates), who has been helping with OpenID and i-<BR>> names integration at Plaxo.<BR>><BR>> 2) Mike Mell, who does a lot of the magic at LinkSafe.<BR>><BR>> 3) Markus Sabadello (based in Vienna), who operates FreeXRI, which <BR>> has no connection with LinkSafe or Wingaa/ooTao, but who is very <BR>> involved in contributing the open source OpenXRI codebase which he <BR>> operates at FreeXRI.com.<BR>><BR>> 4) Wil Tan of NeuStar who is another key contributor to OpenXRI and <BR>> has integrated it with the public XRI resolver services NeuStar <BR>> operates on behalf of XDI.org.<BR>><BR>> 5) Les Chasen, director of registry engineering at NeuStar.<BR>><BR>> Any or all of them might be willing to help with your test i-broker <BR>> server and “controlled test lab”.<BR>><BR>> =Drummond<BR>><BR>> From: general-bounces@openid.net [<A href="mailto:general-bounces@openid.net" target=_blank>mailto:general-bounces@openid.net</A>] <BR>> On Behalf Of Peter Williams<BR>> Sent: Friday, March 21, 2008 2:33 PM<BR>> To: general@openid.net<BR>> Subject: [OpenID] moving onto inames inumbers ibrokers .. or at <BR>> least tryingto<BR>><BR>> I’ve been been struggling for the last hour with the freeid (beta) <BR>> i-services from <A href="https://linksafe.ezibroker.net/" target=_blank>https://linksafe.ezibroker.net/</A>. I’m making an <BR>> effort to address XRI, i-names etc etc etc.<BR>><BR>> Basically, that service has provisioned me 2 openids (in xri form). <BR>> I cannot access either of the accounts associated with those names, <BR>> tho. Password auth seems broken, for now. One can provision the <BR>> password, but not use it. But, it is a beta service. The site <BR>> clearly says upon attempting to logon: authentication failed, and I <BR>> have been unable to bind my infocard, as yet. I have asserted my <BR>> card, though (I think).<BR>><BR>> So I now get to type “@freeid*lockbox” … into plaxo (which is going <BR>> to go down like a lead balloon, in my user community). But, at <BR>> least it worked – in that it redirected to the expected OP.<BR>><BR>> When, I type that string into the Rapattoni/trustbearer consumer, it <BR>> redirects to a different OP logon page to that which Plaxo redirects <BR>> me to, giving me a page of stuff all logging in as xri://@!4E3C.<BR>> 6E35.633A.FD2A!729B.7E1E (which is going to go down like 32 lead <BR>> balloons, in my user community)<BR>><BR>> 1. I have no idea what that particular xri blurb is – never having <BR>> seen the particular value before.<BR>> 2. Similar strings have appeared at times on the freeid website, <BR>> as if I have half-logged onto a session. I may thus be in buggy <BR>> sessions.<BR>> 3. Is there a reason why the same openid goes to different logon <BR>> servers (in terms of the openid/xri model)?<BR>> 4. Has anyone got either long server’s local password <BR>> authentication to work, so they can (a) bind the infocard via <BR>> account management, and/or (b) assert to plaxo?<BR>><BR>> If I pay the $12 for the paid name, anyone know if the services <BR>> associated with the name would work _today_ (while I’m still trying <BR>> to grasp what’s going on)?<BR>><BR>> Anyone willing to recommend spending time on installing the open <BR>> source ibroker server, as mentioned by the freeid service? Would <BR>> such an effort practically (and reasonably easily) help me get to <BR>> grips with xri and openid2 – in a controlled test lab?<BR>><BR>> Peter.<BR>><BR>><BR><BR></FONT></P></DIV></BODY></HTML>