Re: OpenID Attribute Exchange Protocol questions

2007-07-06 Thread 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

___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs


Re: OpenID Attribute Exchange Protocol questions

2007-07-06 Thread James Henstridge
On 06/07/07, Johnny Bufu [EMAIL PROTECTED] wrote:

 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).

Fair enough.  I had not considered that case.


  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).

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.

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


  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.

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).


 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.

James.
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs