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 firstname.lastname@example.org http://openid.net/mailman/listinfo/specs