On 5-Oct-06, at 3:36 PM, Recordon, David wrote: > Conceptually I think I like this model. It does seem easier to > understand. > > Other thoughts on this?
I am still not sure how the delegated identifier is useful. I did miss the earlier discussions, so probably I don't have enough background on this. The only problem it seems to solve is that of vanity identifiers. Switching IdPs where you had an IdP issued identity for the original IdP does not seem to be possible, you have no control over that original identity so you cannot use it anymore. If you had a vanity identity with the original IdP then switching only means pointing your vanity identity to the new IdP. So it really boils down to controlling your vanity identity. Instead of dealing with vanity identities using the delegate tag why not let the IdP manage your vanity identities? When you register with an IdP you should be able to register additional vanity identities, as many as you want. You have to prove to the IdP that you control them, but this is a different problem (I'll get back to this). This is similar to domain names (identities) and hosting companies (IdPs). You can configure your domain to point to a different hosting company (this is like editing your Yadis document to point to another IdP). If you don't care about your own domain then you can get cheap or free hosting but at some URL controlled by the hosting company (these would be the IdP issued identities). Most of the sites you deal with are RPs, not IdPs. Also, you would trust more your IdP then any RP. The link between multiple vanity identifiers will be know only to the IdP, the RPs will not know this. Now, how would the IdP check that you indeed control a vanity identity? First of all, you have to point to that IdP. Second, the IdP will check that no one else claimed this vanity identity. So unless there is an attempt by someone else to claim the same identity the IdP can take your word for it. If it wants to go one step further (or if there is a conflict) then the IdP can ask you for more proof that you own this identity: - it can send a verification email associated with the domain of this identity (if it is a root domain) - it can ask you to place a special file under this domain/path - it can ask you to add special headers in the HTML page of this identity - it can ask you to add a special field into the yadis document (and this field could be a replacement for the delegate element) Does this make sense? What am I missing? Thanks, Marius > > --David > > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of Martin Atkins > Sent: Wednesday, October 04, 2006 11:34 AM > To: email@example.com > Subject: [PROPOSAL] Separate Public Identifier from IdP Identifier > > > 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, though it does change the discovery > protocol. > > I've placed the full proposal on the OpenID wiki: > <http://www.lifewiki.net/openid/SeparateIdentifierFromIdPToken> > > > _______________________________________________ > specs mailing list > firstname.lastname@example.org > http://openid.net/mailman/listinfo/specs > > _______________________________________________ > specs mailing list > email@example.com > http://openid.net/mailman/listinfo/specs > > _______________________________________________ specs mailing list firstname.lastname@example.org http://openid.net/mailman/listinfo/specs