[OIDFSC] AX 1.1 WG Proposal
Nat Sakimura
n-sakimura at nri.co.jp
Thu Jan 28 10:47:49 UTC 2010
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 <sakimura at gmail.com
> <mailto:sakimura at gmail.com>> 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
> <Michael.Jones at microsoft.com <mailto: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 <mailto: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>
> [mailto: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 <mailto:specs-council at openid.net>
> Cc: openid-specs at lists.openid.net
> <mailto: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 <mailto: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 <mailto:atom at yahoo-inc.com>.
> Yahoo! Inc (editor)
>
> Mike Graves, mgraves at janrain.com <mailto:mgraves at janrain.com>,
> JanRain, Inc.
>
> Dick Hardt, dick at skip.com <mailto:dick at skip.com>. Sxip Identity.
>
> Breno de Medeiros, breno at google.com <mailto:breno at google.com>.
> Google, Inc. (editor)
>
> Hideki Nara, hdknr at ic-tact.co.jp <mailto:hdknr at ic-tact.co.jp>,
> Tact Communications
>
> Nat Sakimura, n-sakimura at nri.co.jp
> <mailto:n-sakimura at nri.co.jp> (editor)
>
> John Bradley, ve7jtb at ve7jtb.com <mailto:ve7jtb at ve7jtb.com>
>
> Will Norris, will at willnorris.com <mailto: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
> <mailto: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
> <mailto:john.bradley at wingaa.com>>
>
> Cc: Nat Sakimura <sakimura at gmail.com
> <mailto:sakimura at gmail.com>>, openid-specs at lists.openid.net
> <mailto:openid-specs at lists.openid.net>
>
> +1
>
> On Thu, Nov 19, 2009 at 9:46 AM, John Bradley
> <john.bradley at wingaa.com <mailto: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 <mailto: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 <mailto: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.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
> <mailto: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://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 <mailto: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 <mailto: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 <mailto: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 <mailto: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
>
>
>
> _______________________________________________
> specs mailing list
> specs at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs
>
--
Nat Sakimura (n-sakimura at nri.co.jp)
Nomura Research Institute, Ltd.
Tel:+81-3-6274-1412 Fax:+81-3-6274-1547
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs/attachments/20100128/3d06120c/attachment.htm>
More information about the specs
mailing list