Attribute Exchange pre-draft 5

Johnny Bufu johnny at sxip.com
Mon Mar 26 18:42:31 UTC 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