[OpenID] moving onto inames inumbers ibrokers .. or at least tryingto

Mon Mar 24 01:03:10 UTC 2008

Heya Peter,

Glad to hear @freeXRI community i-names are working for you as an OpenID OP,
even with delegation.
As far as the consumer part is concerned, I can reproduce the problem you
mention, and I'll look into it.

I am using Sxip's openid4java, in case you're interested.

Thanks for sharing your experiences. Let me know if I can you with anything
else at @freeXRI.

BTW you can create as many and as deeply nested i-names as you like, e.g.
@blog*lockbox*even*more. That works just like your first one.

greetings from Vienna,
Markus

On Sun, Mar 23, 2008 at 8:56 PM, Peter Williams <pwilliams at rapattoni.com>
wrote:

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