I'm hoping someone else more familiar with XRI authority servers can chime in here... I don't think I can answer your question, Peter.<div><br></div><div>I haven't read the XRD 1.0 draft, but in OpenID 2.0 delegation as far as I've seen it for URIs, one XRD never references another. So XRD#1 can have all the meaningful values and XRD#2 may as well not exist. For XRIs however, I believe XRDs can reference/import other XRDs and the XRI resolvers are supposed to be able to actually make that work so that the OpenID RP doesn't have to do that extra import explicitly. In that case, perhaps the OP-hosted XRD#2 can be imported into XRD#1, allowing you to control your own identity, having an i-number of your own or what-not, and XRD#2 is imported, allowing the OP you have selected to provide its portion of your XRD for as long as you care to allow it.</div>
<div><br clear="all">--<br>Andrew Arnott<br>"I [may] not agree with what you have to say, but I'll defend to the death your right to say it." - S. G. Tallentyre<br>
<br><br><div class="gmail_quote">On Wed, Jun 24, 2009 at 9:00 PM, Peter Williams <span dir="ltr"><<a href="mailto:pwilliams@rapattoni.com">pwilliams@rapattoni.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
ok. Thats where I was 12+ months ago. It seemed so simple - and entirely intuitive.<br>
<br>
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.<br>
<br>
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."<br>
<br>
I specifically want to induce any RP to store an i-number as its primary key (after a delegation-flow).<br>
<br>
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.<br>
<br>
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?<br>
<br>
1.<br>
<br>
<br>
<br>
<br>
"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 IdP I can rest assured that no one can ever buy off my Identifier." [Andrew's blog]<br>
<div class="im"><br>
________________________________<br>
From: Andrew Arnott [<a href="mailto:andrewarnott@gmail.com">andrewarnott@gmail.com</a>]<br>
</div>Sent: Wednesday, June 24, 2009 6:46 PM<br>
<div class="im">To: Peter Williams<br>
Cc: <a href="mailto:general@openid.net">general@openid.net</a><br>
Subject: Re: [OpenID] metadata/annotations in the primary key<br>
<br>
</div><div><div></div><div class="h5">if there is a "match", the primary key at the RP should be the blog site URL, as redirected to a final URL.<br>
<br>
Is that correct? Or should it be<br>
<br>
if there is a "match", the primary key at the RP should be the identity field from the assertion<br>
<br>
The former is correct, that is, the claimed identifier, which is the last url after all redirects during discovery.<br>
</div></div></blockquote></div><br></div>