Dear Specs Council Representative: Here is the Proposal for Attribute Exchange 1.1 Working Group creation. We have reached the substantial consensus on the scope in [email protected]. Please review it towards the formation of the WG.
Yours Faithfully, Nat Sakimura ============================================= OpenID Attribute Exchange 1.1 Working Group ============================================= Charter Proposal In accordance with the OpenID Foundation IPR policies and procedures this note proposes the formation of a new working group chartered to produce an OpenID specification. As per Section 4.1 of the Policies, the proposed charter is below. I. Name Attribute Exchange Extension 1.1 Working Group (AX) II. Statement of Purpose Produce an updated version of the Attribute Exchange (AX) and Simple Registration (SREG) Extensions. The extensions should be backwards-compatible with AX 1.0. III. Scope Update the Attribute Exchange Extension to include support for the following: Including parameters in fetch requests. Including privacy information. Providing short names for common attributes. IV. Specifications OpenID Attribute Exchange 1.1 V. Anticipated audience All those interested in the obtaining attributes about users authenticated via OpenID. VI. Language of business English. VII. Method of work Mailing list discussion. Posting of intermediate drafts in the OpenID Wiki. Virtual conferencing on an ad-hoc basis. VIII. Basis for completion of the activity The Attribute Exchange 1.1 final drafts are delivered. Background Information IX. Related Work Attribute Exchange (1.0), and Simple Registration (1.0 and 1.1 Draft). X. Initial Membership Allen Tom, [email protected]. Yahoo! Inc (editor) Mike Graves, [email protected], JanRain, Inc. Dick Hardt, [email protected]. Sxip Identity. Breno de Medeiros, [email protected]. Google, Inc. (editor) Hideki Nara, [email protected], Tact Communications Nat Sakimura, [email protected] (editor) John Bradley, [email protected] Will Norris, [email protected] XI. Expected contribution http://lists.openid.net/pipermail/openid-specs/attachments/20091117/c5754ef7/attachment-0001.html ============================================= ---------- Forwarded message ---------- From: Breno de Medeiros <[email protected]> Date: Fri, Nov 20, 2009 at 3:07 AM Subject: Re: AX and Artifact Binding Charter Proposal To: John Bradley <[email protected]> Cc: Nat Sakimura <[email protected]>, [email protected] +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) -- Nat Sakimura (=nat) http://www.sakimura.org/en/ http://twitter.com/_nat_en _______________________________________________ specs mailing list [email protected] http://lists.openid.net/mailman/listinfo/openid-specs
