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<http://openid.net/wordpress-content/uploads/2010/01/OpenID_Process_Document_December_2009_Final_Approved.pdf>(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<http://openid.net/wordpress-content/uploads/2008/03/paper-contribution-agr-final-clean-20080107.pdf>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
