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
