[OpenID] Attribute Exchange without simultaneous authentication

Mon May 26 19:31:36 UTC 2008

I think its more important to fix the critical issue: follow through the intent and ensure the docs allow any (perhaps vendor-defined) extension (not only AX) to leverage a pre-existing OpenID Association without seeking an athentication Statement (or imply the processing of authenticaiton requests signals, by an OP).

One should formalize (and correct as approriate) the architecture that the OP is only one consumer of (a) an attribute store (b) an Association cache. An AX responder that happens not to be co-resident with the OP may leverage the association cache, for example. 

This implementation practice emulates what goes on in the modern SSL world, where the protocol engine for is distinct from the cache of sessions and associates keys. You see this done nicely in WS-SX, where the ws-trust tokens pass (binary) SSL3 handshake messages using XML bearers (rather than the Internet-era TLS record layer protocol) where the sessions and key stores are maintained by the WS-SX engine (rather than say "load balancer stored" SSL key caches and session stores, as is common in late-1990s era https). 

_________________________
Peter Williams

From: Dick Hardt
Sent: Mon 5/26/2008 12:20 PM
To: Andrew Arnott; Johnny Bufu; Josh Hoyt
Cc: OpenID List
Subject: Re: [OpenID] Attribute Exchange without simultaneous authentication

A reasonable suggestion. 

Johnny, Josh?

On 26-May-08, at 12:15 PM, Andrew Arnott wrote:

I would suggest an optional parameter be added to AX called "ax.subject_id" or something like that, that would be used only when openid.claimed_id and openid.identity is not specified.

On Mon, May 26, 2008 at 12:08 PM, Dick Hardt <dick at sxip.com> wrote:

Not requiring a simultaneous authentication was intended to be possible. See the language from the OpenID 2.0 Authentication spec below that hints that things are possible without authenticating the user.

In practice, no one has wanted to move attributes without authenticating ... so the exact mechanics for doing it may not be represented in the spec.

Suggestions?

-- Dick

#  openid.claimed_id

    Value: (optional) The Claimed Identifier.

    "openid.claimed_id" and "openid.identity" SHALL be either both present or both absent. If neither value is present, the assertion is not about an identifier, and will contain other information in its payload, using extensions (Extensions).

    It is RECOMMENDED that OPs accept XRI identifiers with or without the "xri://" prefix, as specified in the Normalization (Normalization) section.

# openid.identity

    Value: (optional) The OP-Local Identifier.

    If a different OP-Local Identifier is not specified, the claimed identifier MUST be used as the value for openid.identity.

    Note: If this is set to the special value "http://specs.openid.net/auth/2.0/identifier_select" then the OP SHOULD choose an Identifier that belongs to the end user. This parameter MAY be omitted if the request is not about an identifier (for instance if an extension is in use that makes the request meaningful without it; see openid.claimed_id above).

On 26-May-08, at 11:56 AM, Andrew Arnott wrote:

I think a simultaneous authentication is necessary because without it, the openid.claimed_id and openid.identity parameters will be missing, and thus no way for the OP to determine what Identifier is being queried for attributes.  

>From the AX spec:

3.1.  Subject Identifier
An identifier for a set of attributes. It MUST be a URI. The subject identifier corresponds to the end-user identifier in the authentication portion of the messages. In other words, the subject of the identity attributes in the attribute exchange part of the message is the same as the end-user in the authentication part. The subject identifier is not included in the attribute exchange. 
It seems that the only way for an RP to send an OP an OpenID message with extensions for this purpose without actually requesting authentication is to leave off the claimed_id and identity parameters, which kills AX's use of them.  At least that's how I unerstand the OpenID 2.0 spec.  Perhaps I misunderstand it.  If I do misunderstand it, how is an extension supposed to send a request without a simultaneous authentication request?

Thanks.

On Mon, May 26, 2008 at 11:43 AM, Dick Hardt <dick at sxip.com> wrote:

The Subject Identifier is to let the OP and RP know which user is being referred to. An authentication request SHOULD not be needed.  

In other words, you should be able to do what you want to do now ... why do you think you can't?

-- Dick

On 25-May-08, at 7:43 AM, Andrew Arnott wrote:

Attribute Exchange seems to rely on being part of an authentication message as opposed to being able to work when in OpenID's no-authentication extension mode.  I get this from section 3.1 of the AX spec getting the subject identifier from the authentication part of the message.

My suggestion would be that if we can, in a subsequent version of AX, allow AX to stand alone without OpenID having to send an authentication request at the same time, then given an OpenID URL by itself, people can query against it.  Now, most information would probably need to be kept private, but perhaps some information, like contact information, can be made available provided the requestor respond to a CAPTCHA or something like that.  That would be up to the individual OPs and their users of course as to which information to be willing to disseminate, but the power of the feature is there.

What do you think?

-- 

Andrew Arnott _______________________________________________
general mailing list
general at openid.net
http://openid.net/mailman/listinfo/general

-- 
Andrew Arnott

-- 
Andrew Arnott _______________________________________________
general mailing list
general at openid.net
http://openid.net/mailman/listinfo/general
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20080526/e738ba4a/attachment-0001.htm>