Re: OpenID Attribute Exchange Protocol questions

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

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


Re: OpenID Attribute Exchange Protocol questions

2007-07-10 Thread Dick Hardt

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

 On 10/07/07, Johnny Bufu [EMAIL PROTECTED] wrote:

 On 6-Jul-07, at 3:54 AM, James Henstridge wrote:

 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.

 That would be appropriate if the OpenID authentication spec covered
 the idea of unsolicited OpenID responses.

 Given that it does not cover unsolicited responses and the AX spec
 uses them, it would seem sensible for the AX spec to describe in
 detail how they are meant to work.

The appropriate place would be in the core spec so that other  
extensions would work the same way.

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


Re: OpenID Attribute Exchange Protocol questions

2007-07-10 Thread 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
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs


Re: OpenID Attribute Exchange Protocol questions

2007-07-10 Thread James Henstridge
[replying to myself]

On 10/07/07, James Henstridge [EMAIL PROTECTED] wrote:
 The only real constraint the authentication spec places on the RP is
 that it maintain the association for the duration of an OpenID
 authentication request.

 With unsolicited response though, there is no prior request that tells
 us the RP is holding a particular association _right now_.

I just realised another difference when working with unsolicited responses.

With a normal OpenID authentication request the RP picks an
association handle, so we know the RP believes it is valid.  However,
the OP can use a private association handle in the response if it
considers the handle from the request to be invalid.  So the OpenID
authentication spec does not seem to require either the RP or OP to
store an association for longer than ~ one request.

In contrast, if a previously established association is used in an
unsolicited response there doesn't seem to be any way the RP can tell
the OP that it has lost the handle.

Given that there doesn't seem to be any way to recover from this
situation, it seems like private associations are the only sane option
for unsolicited responses.

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


Re: OpenID Attribute Exchange Protocol questions

2007-07-10 Thread James Henstridge
On 10/07/07, Dick Hardt [EMAIL PROTECTED] wrote:
  Given that there doesn't seem to be any way to recover from this
  situation, it seems like private associations are the only sane option
  for unsolicited responses.

 An update message would require direct verification and not use an
 association. Associations are set by the RP, and in this case, the OP
 is initiating the conversation. I might be missing something, but I
 don't see how you can reliably use an association.

That was the conclusion that I came to.

I was replying to Johnny's statement that the OP knows the expiry time
of the association handles it stores so could use a previously
negotiated handle in the unsolicited response.

I think it would be good to include a statement to this effect in the
specification so that implementers don't have to work this out for
themselves (and maybe get it wrong).

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


Re: OpenID Attribute Exchange Protocol questions

2007-07-10 Thread Johnny Bufu

On 10-Jul-07, at 8:43 AM, James Henstridge wrote:

 On 10/07/07, Dick Hardt [EMAIL PROTECTED] wrote:
  Given that there doesn't seem to be any way to recover from this
  situation, it seems like private associations are the only sane  
 option
  for unsolicited responses.

 An update message would require direct verification and not use an
 association. Associations are set by the RP, and in this case, the OP
 is initiating the conversation. I might be missing something, but I
 don't see how you can reliably use an association.

 That was the conclusion that I came to.

 I was replying to Johnny's statement that the OP knows the expiry time
 of the association handles it stores so could use a previously
 negotiated handle in the unsolicited response.

 I think it would be good to include a statement to this effect in the
 specification so that implementers don't have to work this out for
 themselves (and maybe get it wrong).


Looks like it's already in the spec, in section 10,  Responding to  
Authentication Requests:

 If no association handle is specified, the OP SHOULD create a  
 private association for signing the response. The OP MUST store  
 this association and MUST respond to later requests to check the  
 signature of the response via Direct Verification.

http://openid.net/specs/openid- 
authentication-2_0-11.html#responding_to_authentication


Johnny

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


Re: OpenID Attribute Exchange Protocol questions

2007-07-10 Thread Dick Hardt

On 10-Jul-07, at 10:52 AM, Johnny Bufu wrote:


 On 10-Jul-07, at 8:43 AM, James Henstridge wrote:

 On 10/07/07, Dick Hardt [EMAIL PROTECTED] wrote:
  Given that there doesn't seem to be any way to recover from this
  situation, it seems like private associations are the only sane  
 option
  for unsolicited responses.

 An update message would require direct verification and not use an
 association. Associations are set by the RP, and in this case,  
 the OP
 is initiating the conversation. I might be missing something, but I
 don't see how you can reliably use an association.

 That was the conclusion that I came to.

 I was replying to Johnny's statement that the OP knows the expiry  
 time
 of the association handles it stores so could use a previously
 negotiated handle in the unsolicited response.

 I think it would be good to include a statement to this effect in the
 specification so that implementers don't have to work this out for
 themselves (and maybe get it wrong).


 Looks like it's already in the spec, in section 10,  Responding to  
 Authentication Requests:

 If no association handle is specified, the OP SHOULD create a  
 private association for signing the response. The OP MUST store  
 this association and MUST respond to later requests to check the  
 signature of the response via Direct Verification.

 http://openid.net/specs/openid- 
 authentication-2_0-11.html#responding_to_authentication

That does not explain why no association handle was specified. I  
think adding language to explain that an OP may initiate a  
conversation and the message would be verified by Direct Verification  
as no association is available.

-- Dick

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


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


Re: OpenID Attribute Exchange Protocol questions

2007-07-05 Thread Johnny Bufu
Hi James!

On 4-Jul-07, at 9:05 PM, James Henstridge wrote:
 1. I noticed a few typos in the examples.  In section 5.1, it gives an
 example of a fetch_request request reading:

 openid.ns.ax=http://openid.net/srv/ax/1.0
 openid.ns.ax=fetch_request
 ...

This would be a copy / paste error on my part; thanks for finding it!  
It's fixed now.

 2. The spec seems to omit details of how messages should be sent to
 openid.ax.update_url.  In particular:

Draft 5 is a bit old; there was also a draft 6 that never made it to  
the index page on openid.net.

The latest revision in svn [1]  should be tagged as draft-7 any time  
now. Please have a look at it and see if there are still issues with  
the update mechanism (or anything else for that matter).


Thanks for the feedback!
Johnny


[1] http://openid.net/svn/specifications/attribute_exchange/1.0/trunk/ 
openid-attribute-exchange.html
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs


OpenID Attribute Exchange Protocol questions

2007-07-04 Thread James Henstridge
Hi,

I was looking at the attribute exchange protocol spec (draft 5), and
had a few questions about it:

1. I noticed a few typos in the examples.  In section 5.1, it gives an
example of a fetch_request request reading:

openid.ns.ax=http://openid.net/srv/ax/1.0
openid.ns.ax=fetch_request
...

It uses openid.ns.ax twice.  It looks like the second occurrence
should be openid.ax.mode.  The same typo appears in sections 5.2 and
6.1.

2. The spec seems to omit details of how messages should be sent to
openid.ax.update_url.  In particular:

* What format should the message take?  Should the OP just send a
request with the openid.ax.* values?  Or should it be a full id_res
response?

* The spec says that the RP may include transaction information in the
update_url to link the update to a particular identity URL.  I guess
this only makes sense if we aren't sending a full id_res response,
since in that case the identity URL would be included.

* How does the RP verify that posts to its update_url came from the OP
and not some other party who got hold of/guessed update_url?  If we
are using an id_res response, then this'd be handled by the signature.

If we sign the response, it brings up the second question: what do we
use as an association handle?  Can we use any available association
handle, or would it be better to treat it as a dumb mode response
and require the RP to do a check_authentication request to verify the
data?

If we aren't sending a full id_res response to the RP, it seems that
the only security is in the secrecy of the update_url, which seems
strange given the use of cryptographically signed messages in other
parts of OpenID.

* The spec seems to indicate that only the changed data should be sent
in the update response.  How would I notify the RP about the absence
of an attribute?  The closest I could come up with was to use count=0:

openid.ax.type.foo=http://example.com/foo
openid.ax.count.foo=0

It would be good to document the preferred way of doing this, since I
could imagine an RP misinterpreting such a response (especially if the
attribute is usually single valued).


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