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

Reply via email to