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: specs@openid.net
> 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
> specs@openid.net
> http://openid.net/mailman/listinfo/specs
>
> _______________________________________________
> specs mailing list
> specs@openid.net
> http://openid.net/mailman/listinfo/specs
>
>

_______________________________________________
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Reply via email to