I think we are getting into scope creep for AX 1.1 I was hoping for something that could fix the major pain points now without requiring significant RP library changes.
That is one of the reasons I liked adding the privacy and TOS policy to the RP XRDS. They require 0 changes to the library. Adding discoverable endpoints and clarifying what URI to use can be done without RP lib code changes, only config changes. I think anything requiring lib changes for the RP is going to take longer to deploy. I am OK with OP lib changes for AX 1.1 that is easier to manage. I prefer all of the RP changes to go into AX 2.0. John B. On 2009-11-18, at 3:04 AM, Will Norris wrote: > > On Nov 16, 2009, at 6:42 PM, Nat Sakimura wrote: > >> (2009/11/17 10:58), Will Norris wrote: >>> On Nov 16, 2009, at 3:49 PM, Nat Sakimura wrote: >>> >>> >>>> Right. AX 1.1 is to be expedient so that it will remove the current acute >>>> pain. >>>> It should be minimalistic as to the spec change and to the implementation >>>> change. >>>> >>>> AX 2.0 will be more generic fix, and that is the place we should consider >>>> whole bunch of issues. >>>> >>>> I agree that there should be discovery way of it in XRD/s for many use >>>> cases, >>>> but it seems to me to be in the territory of AX2.0. >>>> >>>> Attached please find the first cut of AX1.1 Draft01. >>>> >>> It looks like you have policy URL defined as an actual AX attribute? How >>> would that work if the RP is sending the URL to the OP. Doesn't it need to >>> be a standalone parameter like update_url is? >>> >> In this 1.1 draft, I have added the capability for the fetch request to >> include "value"/"parameter". >> Thus, you can do something like: >> >> openid.ns.ax=http://openid.net/srv/ax/1.1 >> openid.ax.mode=fetch_request >> openid.ax.type.policy_url=http://axschema.org/policy_url >> openid.ax.value.policy_url=http://examplerp.com/data_usage_policy.html > > ahh, I missed that. This actually brings up a bigger concern regarding what > features go into 1.1 versus 2.0. During IIW, we talked about needing a more > robust message format, (even serialized XML or JSON was thrown about). I've > heard all kinds of ideas for attached metadata to attributes in an AX > request... > > - give me a verified email address > - give me an email address that was verified using method X > - tell me if the email address "[email protected]" belongs to this user > - give me a payment token authorized for up to $50 > > and I'm sure folks have many, many more. In order to support these kinds of > scenarios, we will almost certainly need something richer than the extended > request format currently included in the 1.1 draft. I'm a little concerned > about changing the message format for 1.1, and then turning around and > changing it again for 2.0. (If others are okay with this prospect, and it's > just something I need to get over, that's fine) > > Addressing some of the specific changes in the 1.1 message format... > > - why not also support single attributes values in the request using the form > "ax.value.<alias>"? Why always require the count? > > - it seems the ax.count.<alias> parameter on the request is serving double > duty. It is defined as specifying the max number of attribute values the OP > should include in the response. But then it is also used for the max number > of values that can be in the request. That seems a bit weird. > > -will > _______________________________________________ > specs mailing list > [email protected] > http://lists.openid.net/mailman/listinfo/openid-specs
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ specs mailing list [email protected] http://lists.openid.net/mailman/listinfo/openid-specs
