[OpenID] Wiki misbehaving with i-names
drummond.reed at cordance.net
Wed Jan 3 04:13:24 UTC 2007
>Martin Atkins wrote:
>Both the OpenID wiki and the new i-names dev wiki (both sporting the
>same MediaWiki patch, I guess) are exhibiting an undesirable and, unless
>I'm missing something, incorrect behavior when dealing with i-names logins.
>In an attempt to "get with the programme" I've invested in a pair of
>i-names. Both of these i-names point at an XRD with the same i-number in
>the CanonicalID. However, the MediaWiki patch does not seem to correctly
>link my login to my canonical i-number, as when I sign in with my second
>i-name it wants me to create a second user account on the wiki.
>Was this intentional? It's certainly not the behavior I was expecting
>given all the talk about synonyms and identifier re-assignability. If
>our own wiki can't get this right, what are the chances of random
>third-party developers getting it right?
>(Or do I have to wait until OpenID 2 before this will work?)
Martin, I know Kevin Turner has already diagnosed this as the Mediawiki
plugin not using the XRI i-number value supplied by the XRDS CanonicalID
element as the OpenID Authentication 2.0 spec dicates. But I wanted to
address your 2 questions, "If our own wiki can't get this right, what are
the chances of random third-party developers getting it right?", and, "Or do
I have to wait until OpenID 2 before this will work?"
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.
To that end, here's my first stab at a general set of guidelines for RPs
about the mods they should make to their userid tables when they adopt
OpenID (something like this may already exist somewhere, but if so I don't
know where it is). This should be posted on either the OpenID or XRI/i-names
wiki (see below for more on that):
**** GUIDELINES FOR OPENID RPS MODIFYING USER TABLES ****
1) Establish a persistent primary key (PPK) for the user, and allow mapping
from a separate "synonym table" of 0-n additional keys that serve as
synonyms for the PPK. (In other words, build OpenID synonym management into
your user tables from the start.)
2) If a user registers with a URL, generate a locally-unique persistent
identifier for the user and use this as the PPK, then add the URL to the
2a) If a user with a URL later logs in with another URL and wants to
associate it with the original URL, after authentication of BOTH add the new
URL to the synonym table.
2b) If a user with a URL later logs in with an i-name and wants to
associate it with the original URL, after authentication of BOTH add both
the i-name and the CanonicalID i-number to the synonym table (the fact that
both the PPK and the CanonicalID i-number are both persistent identifiers is
just icing on the cake).
3) If a user registers with an XRI, use the i-number (supplied as the value
of the highest priority CanonicalID element in the authoritative XRDS) as
the PPK and add the i-name to the synonym table (realizing that it may be
reassigned just like a URL).
3a) If a user later logs in with a different i-name that is
synonymous with the original i-name/i-number (because the new XRDS contain
the same i-number as its CanonicalID), after authentication add the new
i-name to the synonym table.
3b) If a user later logs in with a different i-name that is NOT
synonymous with the original i-name/i-number (because the new XRDS contains
a different CanonicalID i-number), but the user can prove this
i-name/i-number is a synonym of the original i-number by authenticating BOTH
the old and new i-numbers, then add both the new i-name and i-number to the
3b) If a user later logs in with a URL that the user can prove is a
synonym for the original i-number by authenticating both, add the URL to the
****** END *******
I believe this covers all the options -- but if corrections are needed, my
suggestion is we get it on the wiki first and fix it there. Now, the
question is: which wiki should we create this page on? The OpenID wiki or
the XRI/i-names wiki? I don't care which one, just that we do it only in one
place and point to it from the other.
More information about the general