New Charter for AX 1.1

John Bradley john.bradley at wingaa.com
Thu Nov 19 15:38:18 UTC 2009


Nat,

I never proposed anything that involved XRD 1.0.

Only adding some additional elements to the return_to Service in the existing RP XRDS.

I understand that that you want fetch to support CX.   I think it is a good thing.

However we are making a trade off in scope by including something that I don't think is as high a priority for most of the large IdP.

John B.
On 2009-11-19, at 12:22 PM, Nat Sakimura wrote:

> John, 
> 
> Well, AX uptake in RP is not that great, unfortunately, to start with. 
> Realistically, if they want to take advantage of AX, they have to do some programming anyways. So, achieving by just config change is not so realistic. 
> Updating libraries would be orders smaller task than re-programming the application logic, if you are using a third party library. (If you are writing your own, that is another story, but majority of the people are just using somebody else's library.) 
> 
> Moreover, even if your library is not supporting fetch parameters, it is not that complex to add it. Just concatenate the ax.value.<alias>=value to the end of the query. OpenID requests are not signed right now, so it is not hard to do at all. Not to mention that many RPs actually does not provide sensible XRDS right now. IMHO, it is easier for those RP to add a request parameter than to write an XRDS. 
> 
> From the use case point of view, I have bunch of people waiting for this kind of feature around me. I could built it into CX, of course, and I did in fact in an earlier draft, but it is more generic than that. That was one of the reason for putting forward fetch parameter in AX1.1, and it is immensely useful. ROI for doing it is rather high. 
> 
> Also remember that the resource descriptor document is still at limbo. We could probably finish off AX1.1 faster than that, independently. 
> 
> One of the promised quality of OpenID was that it is fast moving. We have lost that long since. We should come back to the basic principle now. 
> 
> =nat
> 
> 
> 
> On Thu, Nov 19, 2009 at 11:49 PM, John Bradley <john.bradley at wingaa.com> wrote:
> 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
> 
> 
> _______________________________________________
> specs mailing list
> specs at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs
> 
> 
> 
> 
> -- 
> Nat Sakimura (=nat)
> http://www.sakimura.org/en/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs/attachments/20091119/d4e6c69d/attachment-0001.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/d4e6c69d/attachment-0001.bin>


More information about the specs mailing list