New Charter for AX 1.1

Nat Sakimura n-sakimura at nri.co.jp
Thu Nov 19 15:22:31 UTC 2009


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/20091120/4431abb9/attachment.htm>


More information about the specs mailing list