OpenID Attribute Exchange Protocol questions

[Johnny Bufu]

On 6-Jul-07, at 12:37 AM, James Henstridge wrote:
> My question about the transaction ID in the update URL still stands:
> won't a positive assertion response include openid.identifier and
> openid.claimed_id, which should be enough for the RP to match up the
> response?  Or do you expect the OP to not record the claimed
> identifier from the original authentication request?

There is a use case for OpenID (though not very well defined) where  
the OP could send a positive assertion without identity / claimed_id  
fields (e.g. if the RP only requests the zipcode). For something like  
this, the RP may (note the lowercase may in the AX spec as well) add  
whatever identifying information it needs (not necessarily for a user  
id / account).

> I think my question about what association handle to use for the
> unsolicited response is adequately covered by the rules in section
> 11.4 of the OpenID Authentication spec: the OP could choose to use the
> association from the original authentication request (if it is still
> valid), or create a new private association handle.

Yes, the update uses the signature mechanism in the underlying OpenID  
message.

> In either case, it should be ready to answer a check_authentication  
> request.

Not entirely; the OP MUST NOT honor check_authentication requests for  
shared associations (this would allow a type of attack).


> 1. The RP requests my phone and fax numbers in an OpenID  
> authentication request:
>    openid.ns.ax=http://openid.net/srv/ax/1.0
>    openid.ax.mode=fetch_request
>    openid.ax.type.phone=http://example.com/phone
>    openid.ax.type.fax=http://example.com/fax
> [...]
> 3. At some later date, my OP sends an unsolicitated authentication
> response containing the following data:
>    openid.ns.ax=http://openid.net/srv/ax/1.0
>    openid.ax.mode=fetch_response
>    openid.ax.type.phone=http://example.com/phone
>    openid.ax.value.phone=555-2345
>    openid.ax.update_url=http://relying-party/...
>
> How should the RP handle this update?  According to the draft spec, I
> can think of two possibilities based on how "updated data" is
> interpreted?
> 1. the user has changed their phone number
> 2. the user has changed their phone number and removed their fax  
> number.

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.

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.


Johnny