> * Protocol has two distinct identifiers: public and IdP-local. Relying > party manages delegation. IdP does not even know that the delegation has > taken place and has no way to stop it happening [1]. RP now has to do > more work, but identifier portability now comes for free. I'm much more in favor of that, though see the value in having the IdP know the public identifier so that it can correctly prompt the user.
I think one identifier, with the IdP managing the entire relationship is too much of an architectural jump from 1.1. Take LiveJournal for example, somehow I doubt we'd see delegation support in this case anytime soon. I think what is important is keeping the simplicity of delegation in 1.1, while cleaning up the metaphor and making it more user-friendly at the same time. Perfection is the enemy of the good. --David -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Martin Atkins Sent: Sunday, October 22, 2006 1:34 PM To: specs@openid.net Subject: Re: Two Identifiers - no caching advantage Dick Hardt wrote: > On 21-Oct-06, at 10:52 PM, Josh Hoyt wrote: > >> On 10/21/06, Dick Hardt <[EMAIL PROTECTED]> wrote: >>> 2) the RP does not verify the binding between the portable >>> identifier and the IdP-specific identifier in the response. >>> to the one the attacker controls and the IdP has mapped >> This is the part where I think you're wrong. The RP MUST verify that >> binding, whether it is by keeping state, self-signing the request >> (which gets passed through to the response) or doing discovery again. > > I agree the RP SHOULD do that. The proposal does not specify that. > I thought we had that conversation. I have not looked at the patch > that you sent. Perhaps you address the issue there. > > My point though is: why have the RP bind the IdP-specific identifier > and the public identifier? Why not let the IdP be responsible for this? > > In 1.x when the IdP was not aware of the public identifier, then the > RP had to do the binding. Now that the IdP is aware of the public > identifier, it would be simpler and logical for the IdP to be > responsible for the binding. It is doing it anyway. > > All the RP wants is which public identifier is the user, and is the > IdP authoritative for it. > If "delegation" is going to require cooperation from the IdP anyway, there's no longer any value in having the distinction between a public identifier and an IdP-local identifier. The hypothetical IdP "IdP-tastic" can just store a relationship between http://mart.vanitydomain.com/ and my user account at IdP-tastic. There's no need for http://mart.idp-tastic.com/ anymore, and with that gone delegation is no longer useful: the public identifier, whatever it might be, is the only identifier. Any disadvantages to uniting the public identifier and the IdP identifier are also disadvantages of having the IdP do the "binding" as you describe. For simplicity's sake, I'm currently only willing to vote positively for one of the following scenarios: * Have only one identifer in the protocol. Remove delegation entirely. IdP maintains relationships between arbitrary identifiers and its local user accounts. IdP no longer needs to issue its own identifiers, though it can if desired. This makes life simpler for RPs, but has the risk that delegation would become an IdP "premium" feature, which may hurt users in the long term. * Protocol has two distinct identifiers: public and IdP-local. Relying party manages delegation. IdP does not even know that the delegation has taken place and has no way to stop it happening [1]. RP now has to do more work, but identifier portability now comes for free. Having the IdP deal with the public identifier while still keeping the IdP-local identifier (and thus delegation) is, it seems to to me, muddled nonsense; the whole purpose of delegation was to make these identifiers distinct. [1] Conceivably a mischievous IdP could make use of knowledge of how particular RPs round-trip their delegation state to block it, but that would be an arms race in the RP's favour rather than a designed-in mechanism for detecting delegation. _______________________________________________ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs _______________________________________________ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
