[OpenID] Wiki misbehaving with i-names

Recordon, David drecordon at verisign.com
Thu Jan 4 09:19:30 UTC 2007


All of that sounds good to me.  I think part of the issue is that the
MediaWiki extension is working with 1.1 libraries versus 2.0 ones.  I'd
hope in 2.0, since this is now an issue, they'll have the ability to
easily get at the Canonical ID.

This is really calling for an "Implementors Guide" on the OpenID wiki
discussing things like this and UX.

--David 

-----Original Message-----
From: general-bounces at openid.net [mailto:general-bounces at openid.net] On
Behalf Of Martin Atkins
Sent: Thursday, January 04, 2007 12:40 AM
To: general at openid.net
Subject: Re: [OpenID] Wiki misbehaving with i-names

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
i-number:

* 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,
http://mart.example.com/)

* 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:
  xri://=!E989.968A.C2F8.A8BA
  xri://=!la.la.la.example.inumber
  http://mart.example.com/

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.


_______________________________________________
general mailing list
general at openid.net
http://openid.net/mailman/listinfo/general



More information about the general mailing list