Auth 2.0 spec errata regarding delegation vs. directed identity

[John Ehn]

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

On Wed, May 21, 2008 at 4:03 PM, John Ehn <john at extremeswank.com> 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 <josh at janrain.com> wrote:
>
>> On Wed, May 14, 2008 at 11:20 AM, Martin Atkins <mart at degeneration.co.uk>
>> 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 at openid.net
>> http://openid.net/mailman/listinfo/specs
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs/attachments/20080521/85b4f97e/attachment-0002.htm>