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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ specs mailing list [email protected] http://lists.openid.net/mailman/listinfo/openid-specs
