SeparateIdentifierFromIdPToken
Contents |
Proposal: Separate Identifier from IdP Token
Currently the conceptual model is that each user has a "public" (that is, presented to RPs) identifier, but can optionally create additional identifiers which "delegate" to the real identifier. The delegate functionality has several purposes, including:
* "Vanity" identifiers on personal domains while letting someone else do the hard work in running the IdP. * Ability to switch !IdPs without losing identity
However, experience has shown that the above model is often difficult to grasp for those new to OpenID. This proposal is really just a set of terminology changes and an alternative conceptual model that aim to make the delegate functionality easier to understand. It does not change the mechanism of delegation at all.
Delegation as the only case
Currently there is a distinction between "normal" identifiers and delegated identifiers. However, the "normal" case is really just a funny special case of the delegation scenario where the delegated identifier and the "real" identifier are the same.
The protocol makes some optimisations in the "normal" case (the RP doesn't have to separately track the delegated indentifier), but since the RP has to implement delegate anyway there is no loss to using this mechanism on *all* requests. This has the benefit of simplifying the protocol by removing the special case.
Separate Public Identifer and IdP Identifier
Delegation has the interesting property that the delegation target URL (the URL listed in the openid.delegate field) is never actually resolved. Assuming now that delegation is the only case, we find that the delegation target URL doesn't need to mean anything to anyone except the IdP.
From now on, let's call the delegation target URL the "IdP Token URI"
IdP Token URI doesn't need to be resolvable
Since the IdP is the only party using the Token URI, it is no longer necessary for this URI to be resolvable. This means that it can now use any URI scheme, including "mailto:" (identify users by email address), "xmpp:" (identify by Jabber ID) and "urn:" (identify by some random URN).
Of course, the Token *can* still be resolvable if that is useful to a particular IdP.
We can potentially go so far as to say that the IdP Token doesn't need to be a URI at all, though I'm still in two minds about this: on one hand it adds more flexibility, but on the other hand the processing expectations for URIs embedded in XML are much more obvious than arbitrary data embedded in XML. URIs also have the nice advantage of being (in most cases) quite memorable and readable; certainly more memorable than a string like "P3X5313".
Changes in Terminology and Discovery
As noted above, this proposal does not change the delegation mechanism at all. However, it does make some changes to the discovery mechanism and terminology surrounding delegation.
The first and only functional change is that the openid:delegate element is now **required** in the Yadis service elements for OpenID 2.0. Additionally, openid:Delegate is renamed to openid:Token to avoid the confusion that has arisen about the term "delegate". This leaves the Yadis service elements looking something like this:
<Service priority="50">
<Type>http://openid.net/signon/1.1</Type>
<URI>http://www.whatever.com/openid</URI>
<openid:Token>http://mart.whatever.com/</openid:Token>
</Service>
IdP services which previously used the user's public identifier as the IdP identifier can simply list the public identifier as openid:Token and continue as before.
Impacts on Directed Identity and XRI auth
(This section was added on 5th Oct to address a few points that were absent in the original proposal)
Two other important new features of OpenID 2.0 are Directed Identity and use of XRIs as identifiers. This section discusses the impact (or lack thereof) on these features by this spec.
Impact on Directed Identity
In Directed Identity, the user enters into the RP a generic "anonymous user" identifier, which may be the identifier of an IdP or it may be some special identifier representing directed identity.
Per the above proposal, directed identity is implemented by having the openid:Token set to something that represents directed identity to the named IdP. Assuming the IdP has a public directed identity identifier of http://anon.myidp.com/:
* The RP initiates Yadis discovery on http://anon.myidp.com/ * The IdP returns a document naming its authentication endpoint (in the "URI" field) and a special anonymous token as openid:Token. openid:Token *may* be the same as the public identifier from the previous step, but this is not required. * The RP initiates OpenID auth to the named endpoint using the openid:Token. * Directed identity proceeds as normal.
Impact on XRI-based auth
An XRI is, for this purpose, a URI that can be resolved into a URL at which we can do Yadis discovery. Once Yadis discovery begins, flow continues as in the original proposal, where openid:Token can be any URI.
It is worth mentioning that since it is up to the IdP to interpret the token, giving an i-name to an IdP that is expecting an HTTP URL, even if that i-name resolves to the HTTP URL, may not work. Since the openid:Token is IdP-specific, users must specify whatever they have been told to specify by the IdP. (Of course, some !IdPs *may* resolve an i-name, but that's up to each individual IdP to decide.)
