Agree, let's define the scope, create the WG and then we can have discussions there.
On Thu, Nov 19, 2009 at 7:33 AM, Nat Sakimura <[email protected]> wrote: > Will, > You are right, but that will be incompatible with AX 1.0, and the > prerequisite of the scope is that it should be backward compatible. I feel > that keeping aliases is a small compromise for keeping the compatibility and > flexibility. > =nat > > On Thu, Nov 19, 2009 at 12:37 PM, Will Norris <[email protected]> wrote: >> >> 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 > > > > -- > Nat Sakimura (=nat) > http://www.sakimura.org/en/ > > _______________________________________________ > specs mailing list > [email protected] > http://lists.openid.net/mailman/listinfo/openid-specs > > -- --Breno +1 (650) 214-1007 desk +1 (408) 212-0135 (Grand Central) MTV-41-3 : 383-A PST (GMT-8) / PDT(GMT-7) _______________________________________________ specs mailing list [email protected] http://lists.openid.net/mailman/listinfo/openid-specs
