OpenID Attribute Exchange Protocol questions

[Dick Hardt]

On 10-Jul-07, at 1:47 AM, James Henstridge wrote:

>
>>>> 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.).
>
> The issue I was thinking of was how to handle a "lost update".  In
> cases where two attributes are related (like two components of a
> postal address), I'd want to make sure the RP has matching versions of
> those attributes.
>
> An update could be lost due to temporary network failures, or possibly
> if the RP could not verify the update (e.g. if an association handle
> is used that the RP does not have).

If the OP does not successfully send the update, I would hope that a  
*good* OP implmentation would try again until it was successful.
I imagined that an OP would retain the state of an original request  
and update URL.

Good point brought up about subsequent requests. A mechanism for  
indicating that request B replaces request A is needed so that the RP  
does not get an update for each request that has ever been made.

-- Dick