[OpenID] Applying the XRI synonym mechanism to OpenID/Yadis

Steve Churchill steven.churchill at ootao.com
Fri Jan 19 05:51:12 UTC 2007


Martin,

I will make an observation about synonym support in XRI/OpenID and then
address your email below.

Observation: Because XRI discovery involves the XRI resolution platform
which supports "CanonicalID verification", in XRI only a single discovery
step is needed by the RP to safely support synonyms. Because OpenID uses raw
HTTP GET for discovery, separate discovery steps would be needed by the RP
for each synonym.

Explanation: In XRI, without "CanonicalID verification" I can be evil and
create an XRI @hacker*steve that resolves to an XRD containing the
CanonicalID for =drummond but with a OpenID URL that allows hacker me to
login. If an RP is using the CanonicalID as a primary key, this allows me to
hack into Drummond's account. 

But *with* CanonicalID verification, the XRI resolver will make sure that
any XRD containing a CanonicalID for =drummond was actually produced by
drummond's namespace ("="). Thus evil @hacker*steve may be able to return an
XRD with Drummond's CanonicalID, but that XRD must also contain Drummond's
real OpenID URL, so hacker me cannot login. I have an article which
discusses XRI synonyms and CanonicalID verification in depth. See
http://dev.inames.net/wiki/XRI_CanonicalID_Verification.

Because OpenID uses raw HTTP GET for discovery, if an XRD came back with an
synonym OpenID URL in its CanonicalID, then, to prevent the above described
spoof, the RP would need to perform discovery a second time on that synonym
URL before the synonym could be used as a primary key for the RP. I'm not
saying that this is either good or bad. It is just different. [1]

Note that delegates in OpenID 1.1 work this way. The RP needs to perform
another GET on the delegate to obtain the OpenID URL before using the
delegate URL for a primary key. [Someone please correct me if I am wrong
here.]

[1] In fact, because CanonicalID verification is still not yet implemented
by the xri.net resolver, a second discovery step is in fact needed today to
prevent the spoof.

---

Now I will respond to your email. My comments in ###.

-----Original Message-----
Martin Atkins wrote:

One thing I've been pondering recently is the issue of identifier 
synonyms as we've discussed on several previous occasions.

XRI already offers a solution to this, so I'm wondering if we can borrow 
from XRI's mechanism either fully or partially. The goal as I see it is 
to map an arbitrary number of "display identifiers" to a single 
canonical "key" identifier; in the XRI world the former are generally 
i-names and the latter are usually i-numbers. In OpenID land they are 
all just identifier URLs.

My understanding of the XRI mechanism is incomplete, so first allow me 
to throw out what I currently understand and hopefully Drummond or 
someone else can fill in the gaps for me or correct me as necessary:

When you resolve an XRI, you ultimately end up with an XRDS document[1]. 
Inside this document is, amongst other things, a <CanonicalID> element 
which gives the i-number that the display i-name represents. Multiple 
i-names can point at a single i-number, and these i-names are known as 
"synonyms".

### There are two major types of XRI synonyms -- what I call "local" and
"polygraphical" synonyms. You can see examples of both in the above
mentioned article.


When processing an OpenID login with an XRI, the endpoint is found via 
XRI resolution instead of OpenID or Yadis discovery. In addition to 
regular OpenID authentication, the RP must perform an additional step to 
verify that the nominated canonical i-number agrees that it can be 
represented by the given i-name. I'm not sure of the specifics of how 
this step is implemented beyond the fact that it must be to avoid any 
user claiming any arbitrary i-number.

### This is CanonicalID verification. It is performed during XRI resolution
[but because the resolver at xri.net does not support it yet, it is
interesting to note that an RP currently *does* need to do an "additional
step" and perform the resolve twice. The above mentioned article gives more
details about this temporary workaround.]


So can we apply this to OpenID? Here are some initial thoughts/questions:

  * The CanonicalID element in the XRD contains a URI, so there's no 
syntactic reason why we can't throw http: or https: URIs in there 
instead of xri: ones and include it in Yadis XRD responses.

  * The main sticking point is whether we can apply the 
"synonym-checking" mechanism employed for XRI to validate OpenID 
URL-based synonyms.

### I would say no. Assuming that the "synonym-checking" mechanism is
CanonicalID verification, it takes a framework such as XRI resolution to
allow this verification to be performed in a single discovery call. In the
case of OpenID's HTTP GET-based discovery, the RP would still need to
perform independent discovery on any URL returned in the CanonicalID. Again,
this is to foil the spoof described above.


  * We must consider the performance implications of adding this 
additional verification step to the login process.

  * Since OpenID URLs are volatile and re-assignable, is it safe to 
substitute them for i-numbers as used in the XRI mechanism? In 
particular, what happens if the provider of my canonical identifier goes 
away? 

### I think that you are in trouble, because, to avoid spoofing, the RP
needs to perform independent discovery on the canonical identifier. If it
goes away, discovery cannot be performed. 


Can I switch to a different canonical identifier without losing 
all of my accounts, or are we just re-creating the identifier assignment 
problem with a few more layers of abstraction?

### If the overall idea is that the RP uses the canonical identifier as the
account's primary key, then I think you lose your accounts if you switched
your canonical identifier.


  * Can I use my XRI i-number as the CanonicalID for an OpenID 
identifier? (i.e. can we inter-breed identifiers?)

### Since the RP needs to perform discovery again on the CanonicalID, I
suppose it could recognize that the CanonicalID is an XRI and use XRI
resolution instead of YADIS discovery.


  * Can I take my several existing distinct identifers, all of which 
I've previously used, and retroactively decide to make them synonyms? 
What happens to my existing accounts on various sites?

### I would say no, because the RPs are using the existing URLs as primary
keys. You need one canonical synonym URL as the primary key in all the
accounts where the other synonym URLs return that canonical synonym as the
claimed identity.


I don't claim to have all (any?) of the answers, but I do think this is 
an important topic to discuss, so, um... discuss?

### Hope this helps.

~ Steve



More information about the general mailing list