Attribute Exchange pre-draft 5
Johnny Bufu
johnny at sxip.com
Mon Mar 26 11:42:31 PDT 2007
Hello list!
Since draft_4 [1] we've done some implementation and testing (as well
as listened to community's suggestions on related issues), and have
incorporated some changes into a pre-draft-5. Before publishing it I
would like to see your comments about them or about other features /
changes that would be useful in AX.
One feature we didn't figure out yet if its benefits would be worth
the added complexity:
- in a fetch response, distinguish between attributes
that the user didn't *want* to release and the ones
not supported by the OP.
What do you think?
The changes are:
- Added ax.mode parameters to all messages, to unambiguously identify
the message types; the values are:
fetch_request
fetch_response
store_request
store_response_success
store_response_failure
This allows implementers to decouple the processing of the underlying
OpenID Auth message and the extension layer.
- Clarified that the required flags are hints about the RP's
requirements
meant to help the user decide what data to release
should not be enforced by the OP
RPs should perform validation on the data they receive anyhow
same principle for SREG discussed here:
http://openid.net/pipermail/general/2007-March/001874.html
- Clarified that a fetch response parameter MUST be sent for each
requested attribute, with an empty value if the user did not supply one.
along the lines of the above, so that the RP can fallback to
alternative data collection methods
- Clarified that extension namespace aliases should be determined
dynamically by the party composing the message
discussed here: http://openid.net/pipermail/specs/2007-March/
001372.html
Thanks,
Johnny
[1] http://openid.net/specs/openid-attribute-exchange-1_0-04.html
More information about the specs
mailing list