[OpenID] general Digest, Vol 34, Issue 65

[Peter Williams]

Ok.

Now copy all that and rewrite it where the op must do directed id. Ie:

You send a checkid_setup to Yahoo with
openid.claimed_id==!234  (URL encoded)
openid.identity=https://yahoo.com/

The op asks the user: which of the following xri values would you like to release about yourself. I the user choose a real public I-name =kermit that is not and does not resolve to !234. (it resolves to !987)

Should this release not invoke the equivalent of the bufu rule at the rp?

That is: rp now does (round 2) xri resolution on the openid.identity= =kermit, determing "somehow" that yahoo is authoritative for minting assertions about that xri#2.

Bufu rule is satisfied, by yahoo, lets say.

Rp THEREFORE makes primary key be !234, by analogy with andrews blogsite example.

End of openid auth.

Meantime, the rp does this (the first time):

=peter gets a canonicalequivid !987.
I-name =kermit gets a canonicalequivid !234.

If =kermit is typed at that and only that rp subsequently, !234 primary key is eventually invoked (for which an rp accountrecord exists). Openid auth does NOT invoke !987, because synonyms override.

Now, im sure my use of canonicalequivid semantics is slightly wrong. But the point is made, I hope. The flow and the delegations using multiple xrd files would now have exactly the same -form- as the blogsite example andrew and I went through for the non xri case.

The openxri server wiki has a nice page describing how an advanced rp with openid + xri might maintain a synonym table, by adding lots of non standard code. What I want is that a walled garden xri server associated with the rp, serving a local non xdi-registered root domain, does most of that work - exploiting synonym equiv fields that bridge the local (serving =peter/!234) and I-name public ( serving =kermit/!987) root domains.


________________________________
From: John Bradley <john.bradley at wingaa.com>
Sent: Thursday, June 25, 2009 6:59 AM
To: general at openid.net <general at openid.net>
Subject: Re: [OpenID] general Digest, Vol 34, Issue 65

Peter,

If your RP resolves =peter and gets a CID of =!234 and has a single openID sep that delegates to Yahoo.

That is points to Yahoo's openID endpoint and has your Yahoo openID as the LocalID in the Service.

You send a ceckid_setup to Yahoo with.
openid.claimed_id==!234  (URL encoded)
openid.identity=https://me.yahoo.com/peterw  (or whatever your ID is)

Yahoo should send back a positive assertion for :
openid.claimed_id==!234  (URL encoded)
openid.identity=https://me.yahoo.com/peterw  (or whatever your ID is)

You then do discovery again on =!234 and discover that the LocalID matches the openid.identity and the OP endpoint is correct etc.

If the OP is supporting delegation they will not modify the claimed_id.

If your LocalID is http://me.yahoo.com/foo and there is no foo Yahoo will do directed identity an you will get back whatever ID was used to loginto yahoo as the openid.identity.

That is why the second discovery step is required to check that the directed identity used is asserted in the originally discovered XRDS.

If delegation is working there is no XRD#2 you discover XRD#1 twice.

The second XRD is only used when the OP doesn't recognize it as delegation and treats it as regular directed identity.

John B.

On 25-Jun-09, at 5:27 AM, general-request at openid.net<mailto:general-request at openid.net> wrote:

Date: Wed, 24 Jun 2009 21:00:30 -0700
From: Peter Williams <pwilliams at rapattoni.com<mailto:pwilliams at rapattoni.com>>
Subject: Re: [OpenID] metadata/annotations in the primary key
To: Andrew Arnott <andrewarnott at gmail.com<mailto:andrewarnott at gmail.com>>
Cc: "general at openid.net<mailto:general at openid.net>" <general at openid.net<mailto:general at openid.net>>
Message-ID:
<BFBC0F17A99938458360C863B716FE46398DCE9075 at simmbox01.rapnt.com<mailto:BFBC0F17A99938458360C863B716FE46398DCE9075 at simmbox01.rapnt.com>>
Content-Type: text/plain; charset="iso-8859-1"

ok. Thats where I was 12+ months ago. It seemed so simple - and entirely intuitive.

There were  2 XRDs involved, one I control (that induces delegation-flow and known as XRD#1) and one at an OP (known as XRD#2). its the Bufu rule that causes both XRD files to be used and the use of XRD#2 addresses impersonation issues introduced uniquely by openid-delegation.

Now, concerning the XRD#1, what 1 or 2 things do I need to do in the file so that "But my i-number that came with that i-name is universally unique and mine forever, long after I cancel my i-name.  Since RPs I log into using my i-name actually store my i-number as my Identifier, using my i-name actually store my i-number as my Identifier, I can change my i-name anytime I like and still log in because my i-number is mine forever."

I specifically want to induce any RP to store an i-number as its primary key (after a delegation-flow).

Im running an XRI authority server. Its deliberately only visible to the XRI Resolver in my RP. I can make it generate any XRD#1 I like, and I currently have it with 1 SEP  that is delegating to Yahoo OP and the localid in the SEP is the Yahoo OP Identifier URL. This is all very similar to the previous protocol run and should (a) induce delegation and (b) induce the OP to only do directed ID.

The intent is... that this all invokes a classical delegation flow, that interacts with XRD#1 (following XRI resolution), which invokes the Bufu rule (which induces the RP to then talks to XRD#2 associated with the assertion's openid.identity value). Since interaction with XRD#2 has no impact on the primary key (in the delegation flow) I really dont care what values are in XRD#2, do I?

1.




"Finally, and the best solution in my opinion, is that OpenID 2.0 introduced the use of XRIs as Identifiers that we can use instead of URLs. XRI's come in two forms: i-names and i-numbers.  My i-name is =arnott, and my i-number is =!9B72.7DD1.50A9.5CCD.  My i-name, like a domain name, only belongs to me as long as I maintain an account with the service I registered it with.  But my i-number that came with that i-name is universally unique and mine forever, long after I cancel my i-name.  Since RPs I log into using my i-name actually store my i-number as my Identifier, I can change my i-name anytime I like and still log in because my i-number is mine forever.  And a future owner of =arnott will not be able to impersonate me because their i-number must be different than mine.  And no I do not have to memorize my i-number.  I just remember =arnott, and the infrastructure does all the work of resolving that to an i-number and authenticating me.  Now even if I'm hosting my own Id
P I can rest assured that no one can ever buy off my Identifier."  [Andrew's blog]

______