[OpenID] Attribute Exchange without simultaneous authentication

[Dick Hardt]

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/133a8009/attachment-0002.htm>