Or perhaps hosting the list someplace that supports exporting the archive? I'm quite satisfied with the mailman at lists.openid.net. -- j
On Jan 28, 2010, at 4:47 AM, Nat Sakimura wrote: > Yes, we definitely need it (for IPR control reason). > I'd volunteer for an admin. > > Will it be a google group? > For repository etc., I have setup one at bitbucket.org/openid/ax > > > > =nat > > (2010/01/28 18:14), David Recordon wrote: >> Let me know if you need a mailing list and who is the admin for it. >> >> On Thu, Jan 21, 2010 at 6:51 PM, Nat Sakimura <[email protected]> wrote: >> Indeed. And, I have started collecting the Contribution Agreement from the >> proposers. >> >> Cheers! >> >> =nat >> >> >> On Fri, Jan 22, 2010 at 7:11 AM, Mike Jones <[email protected]> >> wrote: >> Hi all, >> >> >> In catching up on the specs mail I noticed that the specs council (myself >> included) had not made a recommendation about this proposal. Under the >> newly approved IPR policy (relevant section quoted below), since the council >> had not made a recommendation within 15 days, the working group is >> automatically approved. >> >> >> 4.2 Review. The Specifications Council will review each proposal within 15 >> days after receipt and promptly provide notice to [email protected] of its >> recommendation to either accept or reject it, together with a brief >> statement of the rationale for its recommendation (including any findings or >> opinions by the Specifications Council regarding the criteria for rejection >> in the following clauses (a)-(d). If a proposal is rejected, it may be >> modified and resubmitted. The reasons for rejection will be limited to: >> >> (a) an incomplete Proposal (i.e., failure to comply with §4.1); >> >> (b) a determination that the proposal contravenes the OpenID community’s >> purpose; >> >> (c) a determination that the proposed WG does not have sufficient >> support to succeed or to deliver proposed deliverables within projected >> completion dates; or >> >> (d) a determination that the proposal is likely to cause legal liability >> for the OIDF or others. >> >> If no recommendation was issued within 15 days after receipt, the Proposal >> is deemed to be accepted. >> >> >> Nat, I believe that the next steps for you to take are to create the working >> group mailing list and put members on the list once their signed >> contribution agreements for the working group have been received. >> >> >> Best wishes, >> >> -- Mike >> >> >> -----Original Message----- >> From: [email protected] >> [mailto:[email protected]] On Behalf Of Nat Sakimura >> Sent: Monday, December 28, 2009 11:30 PM >> To: [email protected] >> Cc: [email protected] >> Subject: AX 1.1 WG Proposal >> >> >> 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 >> >> >> >> >> >> -- >> 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 >> >> >> > > > -- > Nat Sakimura ( > [email protected] > ) > Nomura Research Institute, Ltd. > Tel:+81-3-6274-1412 Fax:+81-3-6274-1547 > > _______________________________________________ > specs mailing list > [email protected] > http://lists.openid.net/mailman/listinfo/openid-specs _______________________________________________ specs mailing list [email protected] http://lists.openid.net/mailman/listinfo/openid-specs
