[OpenID] Wiki misbehaving with i-names

Martin Atkins mart at degeneration.co.uk
Thu Jan 4 08:40:25 UTC 2007

Drummond Reed wrote:
> I had a long talk about this with Larry Drebes at JanRain last spring when
> XRI and OpenID "got married". First I explained the whole bit about one of
> the fundamental advantages of XRI being the ability to map multiple
> reassignable i-name synonyms to a persistent i-number. Then I explained that
> this advantage is totally lost if an RP keys a user's identity to their
> i-name instead of their i-number.
> Larry's reaction was to shrug and say, "You're right, but it will take time.
> You can't expect RPs to learn all this in a single bound. First they'll
> decide to try OpenID. Then at some point they'll learn that they should key
> an identity to the i-number rather than an i-name or URL because the former
> is persistent and the latter reassignable."
> So while I completely agree with you that RPs SHOULD do the right thing, all
> we can do is educate them as to what the right thing is, show them in our
> own implementations <ouch!>, and hope they go there.

The other night, after seeing Kevin's response, I made a stab at trying 
to "fix" the Mediawiki extension to use the canonical id. However, I 
couldn't see any obvious way to get at the canonical ID from the 
Auth_OpenID library.

I think it'd be a good idea to add a simple function to the response 
class that returns the canonical identifier as a string. For HTTP URLs 
this would just return the URL, perhaps after some canonicalization. For 
XRIs this would return the associated i-number. That way we can just 
tell implementers to call that and use the result as the "key"; the XRI 
synonym support will "just work" with no special effort on the RP 
implementor's part.


I think one thing which could be made clearer in your guidelines is the 
distinction between "identifiers that we match on" and "identifiers that 
we store for display purposes". If I log in as =martin.atkins, then the 
RP could store that as my "display identifier" but it should not store 
that as a key at all; if it does, then if =martin.atkins is later 
re-assigned, the new owner will end up inheriting my accounts despite 
the change in i-number.

For example, in the case where I log in as =martin.atkins and my 
i-number is not recognised as an existing account:

* Create a new "user" row with some site-specific PPK and a "display 
identity" of =martin.atkins.
* Add a new "openidmap" row which maps the PPK from the previous step to 
the identifier xri://=!E989.968A.C2F8.A8BA

If I later log in with some other i-name which is a synonym, no changes 
would be made to the above, though the RP might like to prompt me to 
change my "display identity" and perhaps validate whether the old 
display identity is still pointing at the same i-number.

If I later associate a second i-name with this account (by some 
RP-provided synonym adding interface) but that i-name has a distinct 

* Add a new "openidmap" row which maps my site-specific PPK to the new 
i-number. The old i-number is retained too.

If I associate a HTTP URL in a similar fashion, (say, 

* Add a new "openidmap" row which maps my site-specific PPK to the 
identifier http://mart.example.com/

So the end result is that I have one account identified by a 
site-specific PPK which has associated with it some identifier used only 
for display purposes (=martin.atkins) but has three "key"-type identifiers:

I guess what I'm really doing here is making a distinction between XRI 
synonyms and OpenID synonyms. XRI synonyms don't require any special 
handling on the RP's part besides using the correct canonical ID as a 
key. OpenID synonyms, on the other hand, require special UI provided by 
the RP to add and remove them. It is the OpenID synonyms that get stored 
in the openidmap table, not the XRI synonyms. The XRI synonyms should 
not be stored by the RP at all, because there is no guarantee that they 
will retain their relationship with the canonical i-number.

In the long term, we should look into providing some way for the RP to 
automatically discover the OpenID synonyms so that each RP doesn't have 
to implement its own synonym management interface.

Does this seem reasonable?
(If so, I think we need to call "OpenID synonyms" something else to 
avoid confusing them with "XRI synonyms".)


As long as this write-up talks about XRI, i-names and i-numbers I think 
it belongs on the XRI wiki. If this "canonical identifier" function is 
added to the reference OpenID libraries and we can rewrite the 
guidelines in terms of that rather than the explicit distinction between 
HTTP URLs and XRIs then it would have a place on the OpenID wiki, but 
since this rule of using the i-number is an XRI implementation detail it 
should be "abstracted away" where OpenID is concerned.

Perhaps the sensible approach is to create a section on the i-names wiki 
  about how i-names integrate with OpenID. The OpenID wiki can then 
reference that entire section and we can avoid getting into the gory 
details about XRI on the OpenID wiki.

More information about the general mailing list