> > Drummond wrote:
>> >
>> > "To achieve identifier portability in OpenID, it MUST be
>> > possible for the RP and the IdP to identify the user using
>> > two different identifiers: an identifier by which the RP
>> > knows the user (the portable identifier), and an identifier
>> > by which the IdP knows the user (the IdP-specific identifier)."
>>
>> Hans wrote:
>>
>> There is no reason why the idp MUST require to know both
>> identifiers for identifier portability to be possible in
>> the system.
>
>Brad wrote:
>
>Existence proof: OpenID 1.1 does identifier portability without two
>identifiers in the spec.
Just to clarify: the "postulate" above did not mean to imply there must be
two different identifiers in the spec/protocol. It was just meant to assert
that the principle of identifier portability (upon which we already have
consensus) requires that it be possible for the RP and IdP to use two
different identifiers.
I was hoping to inch our way towards consensus here by seeing if we had
agreement on this second principle (as some messages have been implying that
IdP-specific identifiers were not needed at all).
>And despite all the "but it can't be stateless without two!" noise, it
>actually can: you put the portable identifier in the return_to URL and
>verify it again when you get the signature back from the IdP. That is,
>verify the mapping from portable -> IdP-specific still holds. Because you
>can't just trust the 1 (or 2) values you get back from the IdP, otherwise
>the IdP (which could be malicious) could be fucking with you, asserting a
>portable identifier which it's not actually permitted to do, according to
>the portable identifer's YADIS/<head>/etc.
Good point. I've never figured an attack vector for the RP to send the wrong
identifiers to the IdP, since the RP is just "fooling itself". But I agree
there can be one for a malicious IdP to return the wrong ones to an RP.
>So with 1 or 2, you still need to verify, but that verification doesn't
>have to be painful: you can cache it. "But that's state! omg!" Okay,
>so don't cache it and re-check it. But OpenID's been all about the
>state(caching) vs. roundtrip(slow) for some time, so it's a fair tradeoff.
Agreed.
>Counter-argument: but OpenID 1.1 does have two parameters: one's just in
>the return_to URL and managed by the client library, arguably in its own
>ugly namespace (not IdP/RP managed, not "openid.", but something else...
>the Perl library uses "oic." or something). So then it's harder to
>document the correct behavior to people ("RPs should verify the mapping
>when you get a signature!") because the parameter names aren't consistent
>between RP clients.
Agreed, and you articulated well the reasons for doing it at the spec level.
>So whether it's in the spec formally or not, I don't really care. But the
>spec MUST contain details on the precautions a RP should take.
Yup.(Got that, editors?)
=Drummond
_______________________________________________
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs
