AX 1.1 WG Proposal
Nat Sakimura
sakimura at gmail.com
Fri Jan 22 02:51:19 UTC 2010
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 <Michael.Jones at microsoft.com>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
> specs at openid.net 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: openid-specs-bounces at lists.openid.net [mailto:
> openid-specs-bounces at lists.openid.net] On Behalf Of Nat Sakimura
> Sent: Monday, December 28, 2009 11:30 PM
> To: specs-council at openid.net
> Cc: openid-specs at lists.openid.net
> 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 specs at openid.net
> .
>
> 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, atom at yahoo-inc.com. Yahoo! Inc (editor)
>
> Mike Graves, mgraves at janrain.com, JanRain, Inc.
>
> Dick Hardt, dick at skip.com. Sxip Identity.
>
> Breno de Medeiros, breno at google.com. Google, Inc. (editor)
>
> Hideki Nara, hdknr at ic-tact.co.jp, Tact Communications
>
> Nat Sakimura, n-sakimura at nri.co.jp (editor)
>
> John Bradley, ve7jtb at ve7jtb.com
>
> Will Norris, will at willnorris.com
>
>
>
> XI. Expected contribution
>
>
>
>
> http://lists.openid.net/pipermail/openid-specs/attachments/20091117/c5754ef7/attachment-0001.html
>
>
>
> =============================================
>
>
>
>
>
> ---------- Forwarded message ----------
>
> From: Breno de Medeiros <breno at google.com>
>
> Date: Fri, Nov 20, 2009 at 3:07 AM
>
> Subject: Re: AX and Artifact Binding Charter Proposal
>
> To: John Bradley <john.bradley at wingaa.com>
>
> Cc: Nat Sakimura <sakimura at gmail.com>, openid-specs at lists.openid.net
>
>
>
>
>
> +1
>
>
>
> On Thu, Nov 19, 2009 at 9:46 AM, John Bradley <john.bradley at wingaa.com>
> 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 <sakimura at gmail.com>
> 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 <will at willnorris.com>
> 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 "bob at example.com" 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
>
> >>>> specs at lists.openid.net
>
> >>>> http://lists.openid.net/mailman/listinfo/openid-specs
>
> >>>
>
> >>>
>
> >>>
>
> >>> --
>
> >>> Nat Sakimura (=nat)
>
> >>> http://www.sakimura.org/en/
>
> >>>
>
> >>> _______________________________________________
>
> >>> specs mailing list
>
> >>> specs at lists.openid.net
>
> >>> 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
>
> >> specs at lists.openid.net
>
> >> 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
>
> specs at lists.openid.net
>
> http://lists.openid.net/mailman/listinfo/openid-specs
>
>
>
--
Nat Sakimura (=nat)
http://www.sakimura.org/en/
http://twitter.com/_nat_en
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs/attachments/20100122/d159569c/attachment-0001.htm>
More information about the specs
mailing list