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
