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 <[email protected]
<mailto:[email protected]>> 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
<[email protected] <mailto:[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] <mailto:[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]>
[mailto:[email protected]
<mailto:[email protected]>] On Behalf Of
Nat Sakimura
Sent: Monday, December 28, 2009 11:30 PM
To: [email protected] <mailto:[email protected]>
Cc: [email protected]
<mailto:[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] <mailto:[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] <mailto:[email protected]>.
Yahoo! Inc (editor)
Mike Graves, [email protected] <mailto:[email protected]>,
JanRain, Inc.
Dick Hardt, [email protected] <mailto:[email protected]>. Sxip Identity.
Breno de Medeiros, [email protected] <mailto:[email protected]>.
Google, Inc. (editor)
Hideki Nara, [email protected] <mailto:[email protected]>,
Tact Communications
Nat Sakimura, [email protected]
<mailto:[email protected]> (editor)
John Bradley, [email protected] <mailto:[email protected]>
Will Norris, [email protected] <mailto:[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]
<mailto:[email protected]>>
Date: Fri, Nov 20, 2009 at 3:07 AM
Subject: Re: AX and Artifact Binding Charter Proposal
To: John Bradley <[email protected]
<mailto:[email protected]>>
Cc: Nat Sakimura <[email protected]
<mailto:[email protected]>>, [email protected]
<mailto:[email protected]>
+1
On Thu, Nov 19, 2009 at 9:46 AM, John Bradley
<[email protected] <mailto:[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] <mailto:[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] <mailto:[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.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]
<mailto:[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://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] <mailto:[email protected]>
>>>> http://lists.openid.net/mailman/listinfo/openid-specs
>>>
>>>
>>>
>>> --
>>> Nat Sakimura (=nat)
>>> http://www.sakimura.org/en/
>>>
>>> _______________________________________________
>>> specs mailing list
>>> [email protected] <mailto:[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] <mailto:[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] <mailto:[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
