Josh Hoyt wrote: > On 10/10/06, Martin Atkins wrote: >> Does the IdP really need to know what URL I gave to the RP? >> >> Earlier versions handled this adequately by the library including >> implementer-defined variables in the return_to URL, which allows a >> stateful RP to hide the real identifier behind a meaningless session >> token, which satisfies Brad's criteria that the RP should be able to >> hide from the IdP the fact that delegation is in use. > > see [1] where I addressed this question. I think that the benefits of > having it there outweigh the benefit of hiding your identifier *from > your chosen IdP*. The benefits for having it available to the IdP are > the same as the benefits outlined in [2]. >
Trusting the IdP to do one thing (authenticate you) does not imply that you trust the IdP to do all things (for example, to know the identifier you used on a particular site.) While it's true that the IdP will know what RPs you have been signing into (based on the return_to URLs) it will not necessarily be able to track *what you do* on that site unless it knows what identifier you used there. In sensitive situations, one can use a throw-away identifier that resolves only once and which only the RP need know about without IdP involvement. Giving each party only the information it absolutely requires is a good general design principle, in my opinion. I'm not convinced that the directed identity case needs to work with delegated identifiers, but even still there's nothing to stop an IdP from giving the user the *option* of disclosing their delegated identities through a configuration setting, thus giving the user the choice about whether to trust the IdP with this information. I'm surprised that our resident privacy advocates aren't making a bigger deal out of this. (If the privacy advocates have no problem then I'll let this go, since this isn't a use case I feel particularly strongly about myself.) _______________________________________________ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs