+1 On Thu, Nov 19, 2009 at 9:46 AM, John Bradley <[email protected]> wrote: > I can live with Nat's latest edit based on Dick's input. > > Let's call the scope done. > > John B. > On 2009-11-19, at 2:39 PM, Breno de Medeiros wrote: > >> 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 > >
-- --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
