On Nov 18, 2009, at 7:27 PM, Nat Sakimura wrote: > (2009/11/18 15:04), 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) >> > I understand this concern, but on the other hand, I have got the feeling that > it will not change too much either. > I have got the feeling that it ends up as > > ax.type.<alias>=http://openid.net/spec/ax/2.0/json > ax.type.value.<alias>=[json file] > > which is the same as we have now. Only the difference is that we are not any > more using any other <alias>, > and we will not need <alias>.count. > > Of course, we have to agree on how to express attributes in json format, > agree on signature, etc. and these are the main things that we should be > dealing with in AX 2.0. Then, the finer semantics / data format / etc.needs > to be addressed in other WGs specifically for that purpose. CX WG is one > example of such thing. > > Needless to say, if you wanted to use SAML assertion in it, you could do > something like > > ax.type.<alias>=http://openid.net/spec/ax/2.0/saml/2.0 > ax.type.value.<alias>=[saml assertion] > > etc. as well.
If you're going to do that, then why even keep the aliases around? Why not just have ns.ax = http://openid.net/specs/ax/2.0 ax = [json/xml file] That would be perfectly valid and avoid the overhead. Now I'm not actually suggesting we do this, because I don't think we have a clear understanding of the requirements for AX 2.0. But my point is, we may end up with something drastically different from AX 1.0. I'm actually okay with that prospect, and kind of like the idea that we have the freedom to make such a complete departure if we thinking it's warranted. I'd hate to make a hasty decision now, expecting that it will *probably* be compatible with what we come up with in AX 2.0, only to find that it is actually a hindrance. I don't know that this is going to be a problem, but that's exactly my point... we don't know. So the fewer changes we make in AX 1.1, the better, I think. -will _______________________________________________ specs mailing list [email protected] http://lists.openid.net/mailman/listinfo/openid-specs
