[OIDFSC] AX 1.1 WG Proposal
David Recordon
recordond at gmail.com
Thu Jan 28 09:14:11 UTC 2010
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> 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>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/20100128/040ee5af/attachment-0001.htm>
More information about the specs
mailing list