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