Arrgh! I'm horrible with names. See below for corrected text. On Wed, May 21, 2008 at 4:03 PM, John Ehn <[EMAIL PROTECTED]> wrote:
> Josh, > > I'm tending to agree with Martin on this one. I guess that statement does, > in a roundabout way, implies the Relying Party should do the following: > > * Run discovery against the Claimed Identifier (or use the cached response > from a previous discovery), thereby determining the Local Identifier and > endpoint URLs > * If a Local Identifier is discovered, compare the Local Identifier with > the openid.identity value in the assertion and verify they are the same - if > they do not match, then authentication validation MUST fail > * If a Local Identifier is not discovered, compare the Claimed Identifier > with the openid.identity value in the assertion and verify they are the same > - if they do not match, the Claimed Identifier MUST be ignored, and the > value of "openid.identity" MUST be used instead > > I does not state this, though. It is very much open to interpretation. > > Normative text needs to be very specific. If you make a vague statement > like "you MUST verify what was received against what you already know", it > can be interpreted very differently depending upon who is reading it. > > Honestly, my client implementation did not perform this check until Martin > made mention of it on this list. From what Martin states, it > appears there several implementations are affected by this issue, which > follows that the specification does not read as clearly as it should. > > Therefore, I suggest taking some action to correct the problem. Sweeping > this under the carpet will cause more harm than good. > > Thank you, > > John Ehn > extremeswank.com > > > On Wed, May 21, 2008 at 3:20 PM, Josh Hoyt <[EMAIL PROTECTED]> wrote: > >> On Wed, May 14, 2008 at 11:20 AM, Martin Atkins <[EMAIL PROTECTED]> >> wrote: >> > * The RP, when verifying that the openid.claimed_id URL in the >> > assertion is valid, checks only that the openid2.provider value is >> > correct, and doesn't check that the openid2.local_id value matches >> > (after removing the fragment part) the openid2.identity URL. >> [...] >> > >> > Both of the above are currently allowed by the Auth 2.0 spec, but since >> > doing the above checks doesn't seem to remove any useful possibilities, >> > I think there ought to be some sort of errata that requires the checks >> > I've listed above. >> >> The "Verifying Discovered Information" section[1] of the OpenID 2.0 >> Authentication spec is actually pretty explicit about the fact that >> the relying party needs to verify this: "If the Claimed Identifier is >> included in the assertion, it MUST have been discovered by the Relying >> Party and the information in the assertion MUST be present in the >> discovered information." It then goes on to list the information that >> must be verified. >> >> I think this is already covered. >> >> Josh >> >> http://openid.net/specs/openid-authentication-2_0.html#verify_disco >> _______________________________________________ >> specs mailing list >> specs@openid.net >> http://openid.net/mailman/listinfo/specs >> > >
_______________________________________________ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs