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. 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. 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? [I am not sure whether checking (claimed_id, realm) or (claimed_id, ax.update_url) pairs would be more appropriate in the above]. 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. 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? 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. 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. James. _______________________________________________ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
