New Charter for AX 1.1

[John Bradley]

Nat,

I understand why people want a fetch parameter.  I would like it, or something like it as well.

However I think that is AX 2.0 work.

Anything that requires code changes at the RP will slow adoption.

I think we should limit AX 1.1 to practical things we can accomplish through config changes at the RP.

Yes OP's will need some changes.

My argument is adoption if code changes are required RP's will tend to wait for AX 2.0.

There is also the slippery slope argument.   Why make a code change that for fetch as opposed to something else.   

I also have a suspicion that to do fetch properly at the RP it will require rethinking a bunch of things to use it.

I think we should add 1 Privacy Policy and 1 TOS in the RP's XRDS,  and define the SREG compatible AX attributes (short if possible).  

I think fetch and the RP sending more specific Privacy policy are AX 2.0 features.

I am uncharacteristically making an argument for practicality.
Fix what we can quickly, and have it implemented by those that want it in weeks not years.

John B.

On 2009-11-19, at 1:21 AM, Nat Sakimura wrote:

> Hi.
> 
> 
> 
> 
> To separate out the 2.0 and 1.1 discussion, I have created a new
> separate charter for AX 1.1
> 
> 
> 
> https://openid.pbworks.com/OpenID_Attribute_Exchange_Extention_1_1
> 
> 
> 
> Regards, 
> 
> 
> 
> =nat
> 
> _______________________________________________
> specs mailing list
> specs at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs/attachments/20091119/0d2f67e1/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2486 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs/attachments/20091119/0d2f67e1/attachment.bin>