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 <[email protected]> > 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 >> [email protected] >> http://lists.openid.net/mailman/listinfo/openid-specs > > > _______________________________________________ > specs mailing list > [email protected] > http://lists.openid.net/mailman/listinfo/openid-specs > > > > > -- > Nat Sakimura (=nat) > http://www.sakimura.org/en/
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ specs mailing list [email protected] http://lists.openid.net/mailman/listinfo/openid-specs
