Auth 2.0 spec errata regarding delegation vs. directed identity

[John Ehn]

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 Josh
made mention of it on this list.  From what Josh 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/51230bca/attachment-0001.htm>