Re: More questions about openid.ax.update_url

2007-10-22 Thread James Henstridge
On 18/10/2007, Johnny Bufu [EMAIL PROTECTED] wrote:
 Hi James,

 On 17-Oct-07, at 2:42 AM, James Henstridge wrote:

  I have a few more questions about the update_url feature of OpenID
  attribute exchange that I feel could do with answers in the
  specification.
 
  For the questions, imagine an OpenID RP with the following properties:
 
  1. The RP provides a unified login/signup workflow, so that if a user
  signs in with a previously unused OpenID a new account is created.
 
  2. The RP does not manage any user details, instead requesting them
  via attribute exchange during login, and through updates provided via
  the openid.ax.update_url protocol.

 If the RP does not store any user attributes (and requests them with
 each transaction from the OP), why does it want to be updated when
 the user changes an attribute value at their OP?

What I meant was that the RP would act as a cache for the user details
stored in the OP.

So the RP would not provide a form letting the user change their
profile details, instead advising them to make the changes at their
OP.  The changes would then be communicated back to the RP via an
update_url message.


 Maybe I'm not understanding the flow and what the RP is supposed to
 do with a new value sent to the update_url.

It'd update the cached user details stored by the RP.


  3. Some portion of users enter an OP identifier URL into the login
  page on the RP (i.e. they are using directed identity).
 
  4. The RP does not want to ask the user to authenticate twice, even if
  they are creating an account.
 
 
  With this setup, it is highly likely that the RP will send multiple
  openid.ax.update_url requests for some users.

 I believe this happens because of the incompatible RP requirements
 you listed at step 2.

Here, I meant that the RP is likely to send multiple authentication
requests with openid.ax.mode=fetch_request and openid.ax.update_url
fields, since it doesn't know that it has already asked for updates
for the particular identity.


  For standard authentication requests, the RP will know whether it has
  previously requested updates, but in the directed identity case we
  don't know what claimed ID will be picked at the time of making the
  request.  So in some cases the RP will ask for updates for an OpenID
  that they are already receiving updates for.
 
  So the question is what should an OP do if it receives multiple
  requests for updates for a particular claimed identifier with the same
  ax.update_url or realm value?  Should it treat the latest request as
  superseding the previous ones?

 If the (claimed_id, update_url) pair is the same the OP already has
 it on file and doesn't need to do anything extra when processing the
 update_url in the fetch request.

Okay, that is good to know.  It seems like a good reason not to
include a transaction ID or similar in the update_url like the
example in the specification then.

If the two requests for updates ask for different sets of attributes
(as might happen after upgrading the software on the RP), could the OP
decide to throw out the old update request, or should it send updates
for the union of the two requests?

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


Re: More questions about openid.ax.update_url

2007-10-22 Thread Johnny Bufu

On 22-Oct-07, at 3:23 AM, James Henstridge wrote:
 If the RP does not store any user attributes (and requests them with
 each transaction from the OP), why does it want to be updated when
 the user changes an attribute value at their OP?

 What I meant was that the RP would act as a cache for the user details
 stored in the OP.

 So the RP would not provide a form letting the user change their
 profile details, instead advising them to make the changes at their
 OP.  The changes would then be communicated back to the RP via an
 update_url message.

That's a possibility, but I think it would be poor user experience  
for the RP to tell the user in plain text go to the OP and then come  
back.

Attribute Exchange also has a store message: the user can update  
their data at the RP, and if the RP thinks that piece of data may be  
useful in other places it can 'store' it at the OP (user has to  
confirm etc, but the whole process is specified and can be automated).

 3. Some portion of users enter an OP identifier URL into the login
 page on the RP (i.e. they are using directed identity).

 4. The RP does not want to ask the user to authenticate twice,  
 even if
 they are creating an account.


 With this setup, it is highly likely that the RP will send multiple
 openid.ax.update_url requests for some users.

 I believe this happens because of the incompatible RP requirements
 you listed at step 2.

 Here, I meant that the RP is likely to send multiple authentication
 requests with openid.ax.mode=fetch_request and openid.ax.update_url
 fields, since it doesn't know that it has already asked for updates
 for the particular identity.

If it's a stateless RP, then I agree - there can be some overhead.

Otherwise, the RP can use the browser session (or even a  
transaction_id in the return url) to keep track of which user is  
which, what data was requested for each one etc. So not really a AX  
protocol issue as I see it.


 For standard authentication requests, the RP will know whether it  
 has
 previously requested updates, but in the directed identity case we
 don't know what claimed ID will be picked at the time of making the
 request.  So in some cases the RP will ask for updates for an OpenID
 that they are already receiving updates for.

 So the question is what should an OP do if it receives multiple
 requests for updates for a particular claimed identifier with the  
 same
 ax.update_url or realm value?  Should it treat the latest request as
 superseding the previous ones?

 If the (claimed_id, update_url) pair is the same the OP already has
 it on file and doesn't need to do anything extra when processing the
 update_url in the fetch request.

 Okay, that is good to know.  It seems like a good reason not to
 include a transaction ID or similar in the update_url like the
 example in the specification then.

 If the two requests for updates ask for different sets of attributes
 (as might happen after upgrading the software on the RP), could the OP
 decide to throw out the old update request,

The OP should throw it away only when it receives a 404 on the  
update_url.

 or should it send updates for the union of the two requests?

As the user updates their data at the OP, the OP can optimize the  
updates it sends out (as long as they match the requests and the user  
has approved them).


Johnny

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


Re: More questions about openid.ax.update_url

2007-10-17 Thread Johnny Bufu
Hi James,

On 17-Oct-07, at 2:42 AM, James Henstridge wrote:

 I have a few more questions about the update_url feature of OpenID
 attribute exchange that I feel could do with answers in the
 specification.

 For the questions, imagine an OpenID RP with the following properties:

 1. The RP provides a unified login/signup workflow, so that if a user
 signs in with a previously unused OpenID a new account is created.

 2. The RP does not manage any user details, instead requesting them
 via attribute exchange during login, and through updates provided via
 the openid.ax.update_url protocol.

If the RP does not store any user attributes (and requests them with  
each transaction from the OP), why does it want to be updated when  
the user changes an attribute value at their OP?

Maybe I'm not understanding the flow and what the RP is supposed to  
do with a new value sent to the update_url.

 3. Some portion of users enter an OP identifier URL into the login
 page on the RP (i.e. they are using directed identity).

 4. The RP does not want to ask the user to authenticate twice, even if
 they are creating an account.


 With this setup, it is highly likely that the RP will send multiple
 openid.ax.update_url requests for some users.

I believe this happens because of the incompatible RP requirements  
you listed at step 2.


 For standard authentication requests, the RP will know whether it has
 previously requested updates, but in the directed identity case we
 don't know what claimed ID will be picked at the time of making the
 request.  So in some cases the RP will ask for updates for an OpenID
 that they are already receiving updates for.

 So the question is what should an OP do if it receives multiple
 requests for updates for a particular claimed identifier with the same
 ax.update_url or realm value?  Should it treat the latest request as
 superseding the previous ones?

If the (claimed_id, update_url) pair is the same the OP already has  
it on file and doesn't need to do anything extra when processing the  
update_url in the fetch request.

 [I am not sure whether checking (claimed_id, realm) or (claimed_id,
 ax.update_url) pairs would be more appropriate in the above].


Johnny

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


Re: More questions about openid.ax.update_url

2007-10-17 Thread Johnny Bufu

On 17-Oct-07, at 2:42 AM, James Henstridge wrote:

 The next question is how much information from the original OpenID
 authentication request/response can the RP expect to be included in
 the subsequent update responses.

Attribute Exchange is an OpenID extension, so a full/valid/positive  
assertion must be sent each time with an attribute exchange response.

 If the original request was for
 openid.claimed_id=http://www.jamesh.id.au/ and
 openid.identity=http://example.com/jamesh, will those values be
 included in future updates responses?

Being an extension, it is assumed that the RP has completed  
successfully the OpenID verification and has identified the user by  
the claimed_id in the positive assertion.

Therefore the RP has identified the correct user when it is  
processing the AX fetch response sent to an update_url.

 Looking at it from the other side, an OP implementer would want to
 know how much information from the request needs to be stored in order
 to satisfy future update responses.

I believe this is specified already:

If present, the OpenID Provider may re-post the fetch response  
message to the specified URL at some time after the initial response  
has been sent, using a OpenID Authentication Positive Assertion.


Johnny

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


Re: More questions about openid.ax.update_url

2007-10-17 Thread Johnny Bufu

On 17-Oct-07, at 2:42 AM, James Henstridge wrote:

 The next one is not so much a question as an observation: As an
 identity URL may change its delegation over time (possibly without the
 underlying OP's knowledge), it is possible that an RP will receive
 updates from an OP that is not authoritative for the claimed ID.

 So in addition to checking the signature on the unsolicited OpenID
 response, an RP must perform discovery on the claimed ID to verify
 that the OP is correct.  I could imagine an RP missing this step when
 implementing the spec.

Checking the signature and discovered information are requirements in  
the core OpenID protocol.

See 11.  Verifying Assertions :
http://openid.net/specs/openid-authentication-2_0-12.html#verification

Johnny

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