I was looking at the attribute exchange protocol spec (draft 5), and
had a few questions about it:

1. I noticed a few typos in the examples.  In section 5.1, it gives an
example of a fetch_request request reading:


It uses "openid.ns.ax" twice.  It looks like the second occurrence
should be "openid.ax.mode".  The same typo appears in sections 5.2 and

2. The spec seems to omit details of how messages should be sent to
openid.ax.update_url.  In particular:

* What format should the message take?  Should the OP just send a
request with the openid.ax.* values?  Or should it be a full "id_res"

* The spec says that the RP may include transaction information in the
update_url to link the update to a particular identity URL.  I guess
this only makes sense if we aren't sending a full id_res response,
since in that case the identity URL would be included.

* How does the RP verify that posts to its update_url came from the OP
and not some other party who got hold of/guessed update_url?  If we
are using an id_res response, then this'd be handled by the signature.

If we sign the response, it brings up the second question: what do we
use as an association handle?  Can we use any available association
handle, or would it be better to treat it as a "dumb" mode response
and require the RP to do a check_authentication request to verify the

If we aren't sending a full id_res response to the RP, it seems that
the only security is in the secrecy of the update_url, which seems
strange given the use of cryptographically signed messages in other
parts of OpenID.

* The spec seems to indicate that only the changed data should be sent
in the update response.  How would I notify the RP about the absence
of an attribute?  The closest I could come up with was to use count=0:


It would be good to document the preferred way of doing this, since I
could imagine an RP misinterpreting such a response (especially if the
attribute is usually single valued).

specs mailing list

Reply via email to