OpenID Attribute Exchange Protocol questions

[Johnny Bufu]

On 6-Jul-07, at 3:54 AM, James Henstridge wrote:
>> Not entirely; the OP MUST NOT honor check_authentication requests for
>> shared associations (this would allow a type of attack).
>
> Okay.  In that case it sounds like it would be best practice to
> generate a private association handle for each unsolicited response
> since there is no guarantee that the RP has kept hold of its
> association handle, so may not be able to verify the update if a
> pre-existing handle is used.

The OPs knows the expiration time for each handle, so if they link  
them with the update URLs they can determine their validity.

But most of the time the updates will probably happen at much longer  
intervals than association expiry time, so using private association  
would be required.

> Would that be appropriate to include in the spec or some best
> practices document?

I see this as a pure OpenID (core) issue and don't feel the need to  
touch it in the AX spec.

>> I don't think it's implied anywhere (or a good design) to keep state
>> between the original request and subsequent updates. So the RP cannot
>> infer the 'removed' statement just because an update did not contain
>> an attribute that was part of the original exchange.
>>
>> The update message is a fetch response, so I think it should be
>> interpreted as such by the RP: "the user has a new phone number".
>> Then the RP can decide what it wants to do with the new value, as if
>> it had requested the same attributes again.
>
> Thank you for the clarification.  It seems that an OP will get the
> most consistent results if it always sends all attributes in an update
> then, so it doesn't need to track whether intermediate updates failed
> (or track exactly which attributes were changed).

Sending all of the originally requested attributes would also require  
the OP to keep an "original request" data structure for each Fetch  
Request with an update_url in it, with the possibility of  
conflicting / overlapping requests.

A cleaner way would be to attach a list of update URLs to each  
attribute in the user's profile, and when that attribute's value  
changes to post an update to the RP (after prompting the user etc.).

>> To indicate that the user has deleted an attribute, the count=0
>> mechanism can be used:
>>
>> > An "openid.ax.count.<alias>" with a value of "0" together with its
>> > corresponding "openid.ax.type.<alias>" field MAY be included to
>> > explicitly state that no values are provided for an attribute.
>
> It might be worth demonstrating this in the example from section 5.2
> then.  Currently it reads:
>    openid.ax.type.gender=http://example.com/schema/gender
>    ...
>    openid.ax.value.gender=
>
> If this is a case where the user has not given their gender it should
> perhaps use "openid.ax.count.gender=0" instead.

You are right - thanks for catching this one as well! Previous drafts  
required that empty values are sent if the user did not send a  
meaningful value (which led to confusions and were clarified with the  
count param).


Thanks,
Johnny