[OpenID] general Digest, Vol 34, Issue 65

Sat Jun 27 16:27:00 UTC 2009

Im glad to have found some material that is at least on the same wavelength as what Im trying to get my head around, when having 2 (signed) XRD files expressing address authority-spoofing in openid-delegation flows.

http://dev.inames.net/wiki/XRDSP_Use_Cases

While XRDSP has notions I really don't like (RPs consuming assertion will need to establish a governance relationships with other XRD providers to get "rights' to add their RP-centric SEPs to the OP-centric XRD files managed by those third-party i-brokers), it also has core notions I do like:-

- the notion that SEPs  in the XRD can be target object services at an RP (which aligns with the resource-sts concept, from Microsoft's Azure cloud)

- the notion of user designating a "primary" openid, which can certainly act as an OP minting assertion AND which can via publication of n additional SEP authentication elements point upstream to other "secondary" openids/OPs (which aligns with the SAML2 "nameid" functional group of IDP services).

- the notion of using equivID fields in XRD files to "link" two XRD files as equivalent, in the users eye (which aligns some SAML1 notions of account linking for persistent identity/subject claims)

- the notion of using canonicalEquivID fields in XRD files to address mergers and aquisition type issues (which has some elements of SAML concept of the "SP affiliation" )

- the notion of combining 1 canonicalEquidID mapping with n EquivID field mappings, to build a synonym mesh capable of surviivng mergers and aquisition type ownerhip changes (which aligns with the semweb's "semantic switchboard" concept)

- the obligation to use refs/redirects properly ( in XRDs or HTTP 302/303) when resolving identifiers to XRD address - and not abuse them as an embodiment of synonym meshes.

________________________________
From: Peter Williams
Sent: Thursday, June 25, 2009 8:45 AM
To: John Bradley; general at openid.net
Subject: RE: [OpenID] general Digest, Vol 34, Issue 65

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]

______