Auth 2.0 spec errata regarding delegation vs. directed identity

John Ehn john at
Wed May 21 20:04:59 UTC 2008

Arrgh!  I'm horrible with names.  See below for corrected text.

On Wed, May 21, 2008 at 4:03 PM, John Ehn <john at> 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
> On Wed, May 21, 2008 at 3:20 PM, Josh Hoyt <josh at> wrote:
>> On Wed, May 14, 2008 at 11:20 AM, Martin Atkins <mart at>
>> 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
>>  _______________________________________________
>> specs mailing list
>> specs at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the specs mailing list