Identifier_select response

[Kevin Turner]

On Thu, 2008-02-07 at 02:17 +0200, Eddy Nigg (StartCom Ltd.) wrote:
> One thing however I must clarify here. Why does the consumer use the
> openid.claimed_id field for discovering the second step (for XRDS) and
> not the openid.identity? I expected the openid.identity field to be
> authoritative and not openid.claimed_id! This looks somehow not really
> correct to me...

openid.identity is always the OP-local identifier.  It's the
"openid.delegate" value in OpenID 1.x speak, "openid2.local_id" or
<LocalID> in OpenID 2 terms.  This identifier only has meaning when
talking to one particular OP endpoint; it's not discoverable.  For
example, it should be technically permissible for me to publish an
identifier at http://kevin.janrain.com/ with the following service
definition:

<Type>http://specs.openid.net/auth/2.0/signon</Type>
<URI>http://example.com/endpoint/</URI>
<LocalID>urn:uuid:ed8aa824-9441-4eb3-bb9f-e3f02c529349</LocalID>

as long as example.com/endpoint knows that is my account.  My identifier
is the claimed identifier that leads to that information, not the
LocalID.


See OpenID 2.0 spec section 11.5, Identifying the End User:

        The Claimed Identifier in a successful authentication response
        SHOULD be used by the Relying Party as a key for local storage
        of information about the user.  The Claimed Identifier MAY be
        used as a user-visible Identifier.  When displaying URL
        Identifiers, the fragment MAY be omitted.