AX 1.1 WG Proposal

Mike Jones Michael.Jones at microsoft.com
Thu Jan 21 22:11:55 UTC 2010


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] 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


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs/attachments/20100121/d5f261dc/attachment.htm>


More information about the specs mailing list