Let me know if you need a mailing list and who is the admin for it.<br><br><div class="gmail_quote">On Thu, Jan 21, 2010 at 6:51 PM, Nat Sakimura <span dir="ltr"><<a href="mailto:sakimura@gmail.com">sakimura@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">Indeed. And, I have started collecting the Contribution Agreement from the proposers. <div><br></div><div>Cheers!</div>
<div><br></div><div><font color="#888888">=nat</font><div><div></div><div class="h5"><br><br><div class="gmail_quote">On Fri, Jan 22, 2010 at 7:11 AM, Mike Jones <span dir="ltr"><<a href="mailto:Michael.Jones@microsoft.com" target="_blank">Michael.Jones@microsoft.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div lang="EN-US" link="blue" vlink="purple">
<div>
<p><span style="font-size:11.0pt;color:#1F497D">Hi all,</span></p>
<p><span style="font-size:11.0pt;color:#1F497D"> </span></p>
<p><span style="font-size:11.0pt;color:#1F497D">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 <a href="http://openid.net/wordpress-content/uploads/2010/01/OpenID_Process_Document_December_2009_Final_Approved.pdf" target="_blank">IPR
policy</a> (relevant section quoted below), since the council had not made a
recommendation within 15 days, the working group is automatically approved.</span></p>
<p><span style="font-size:11.0pt;color:#1F497D"> </span></p>
<p style="margin-left:.35in;text-indent:0in"><a name="12653f13cf0d48ce_12652f2259ffa82b__Ref175333071"><b>4.2 Review.</b> The Specifications Council will
review each proposal within 15 days after receipt and promptly provide notice
to </a><a href="mailto:specs@openid.net" target="_blank">specs@openid.net</a> 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:</p>
<p style="margin-left:0in"><a name="12653f13cf0d48ce_12652f2259ffa82b__Ref185441723"><b><span>(a)<span style="font:7.0pt "Times New Roman"">
</span></span></b>an incomplete Proposal (i.e., failure to comply
with §</a>4.1);</p>
<p style="margin-left:0in"><b><span>(b)<span style="font:7.0pt "Times New Roman"">
</span></span></b>a determination that the proposal contravenes the
OpenID community’s purpose;</p>
<p style="margin-left:0in"><b><span>(c)<span style="font:7.0pt "Times New Roman"">
</span></span></b>a determination that the proposed WG does not have
sufficient support to succeed or to deliver proposed deliverables within
projected completion dates; or</p>
<p style="margin-left:0in"><a name="12653f13cf0d48ce_12652f2259ffa82b__Ref185441727"><b><span>(d)<span style="font:7.0pt "Times New Roman"">
</span></span></b>a determination that the proposal is likely to
cause legal liability for the OIDF or others</a>.</p>
<p style="text-indent:0in"><span style="background:yellow">If no recommendation was issued
within 15 days after receipt, the Proposal is deemed to be accepted.</span> </p>
<p><span style="font-size:11.0pt;color:#1F497D"> </span></p>
<p><span style="font-size:11.0pt;color:#1F497D">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 <a href="http://openid.net/wordpress-content/uploads/2008/03/paper-contribution-agr-final-clean-20080107.pdf" target="_blank">contribution
agreements</a> for the working group have been received.</span></p>
<p><span style="font-size:11.0pt;color:#1F497D"> </span></p>
<p><span style="font-size:11.0pt;color:#1F497D"> Best
wishes,</span></p>
<p><span style="font-size:11.0pt;color:#1F497D"> --
Mike</span></p><div><div></div><div>
<p><span style="font-size:11.0pt;color:#1F497D"> </span></p>
<p>-----Original Message-----<br>
From: <a href="mailto:openid-specs-bounces@lists.openid.net" target="_blank">openid-specs-bounces@lists.openid.net</a>
[mailto:<a href="mailto:openid-specs-bounces@lists.openid.net" target="_blank">openid-specs-bounces@lists.openid.net</a>] On Behalf Of Nat Sakimura<br>
Sent: Monday, December 28, 2009 11:30 PM<br>
To: <a href="mailto:specs-council@openid.net" target="_blank">specs-council@openid.net</a><br>
Cc: <a href="mailto:openid-specs@lists.openid.net" target="_blank">openid-specs@lists.openid.net</a><br>
Subject: AX 1.1 WG Proposal</p>
<p> </p>
<p>Dear Specs Council Representative:</p>
<p> </p>
<p>Here is the Proposal for Attribute Exchange 1.1 Working
Group creation.</p>
<p>We have reached the substantial consensus on the scope in
<a href="mailto:specs@openid.net" target="_blank">specs@openid.net</a>.</p>
<p>Please review it towards the formation of the WG.</p>
<p> </p>
<p>Yours Faithfully,</p>
<p> </p>
<p>Nat Sakimura</p>
<p> </p>
<p>=============================================</p>
<p>OpenID Attribute Exchange 1.1 Working Group</p>
<p>=============================================</p>
<p> </p>
<p>Charter Proposal</p>
<p> </p>
<p>In accordance with the OpenID Foundation IPR policies and
procedures</p>
<p>this note proposes the formation of a new working group
chartered to</p>
<p>produce an OpenID specification. As per Section 4.1 of
the Policies,</p>
<p>the proposed charter is below.</p>
<p> </p>
<p>I. Name</p>
<p> </p>
<p>Attribute Exchange Extension 1.1 Working Group (AX)</p>
<p> </p>
<p>II. Statement of Purpose</p>
<p> </p>
<p>Produce an updated version of the Attribute Exchange (AX)
and Simple</p>
<p>Registration (SREG) Extensions. The extensions should be</p>
<p>backwards-compatible with AX 1.0.</p>
<p> </p>
<p>III. Scope</p>
<p> </p>
<p>Update the Attribute Exchange Extension to include
support for the following:</p>
<p> </p>
<p>Including parameters in fetch requests.</p>
<p>Including privacy information.</p>
<p>Providing short names for common attributes.</p>
<p> </p>
<p> </p>
<p>IV. Specifications</p>
<p> </p>
<p>OpenID Attribute Exchange 1.1</p>
<p> </p>
<p>V. Anticipated audience</p>
<p> </p>
<p>All those interested in the obtaining attributes about
users</p>
<p>authenticated via OpenID.</p>
<p> </p>
<p>VI. Language of business</p>
<p> </p>
<p>English.</p>
<p> </p>
<p>VII. Method of work</p>
<p> </p>
<p>Mailing list discussion. Posting of intermediate drafts
in the OpenID</p>
<p>Wiki. Virtual conferencing on an ad-hoc basis.</p>
<p> </p>
<p>VIII. Basis for completion of the activity</p>
<p> </p>
<p>The Attribute Exchange 1.1 final drafts are delivered.</p>
<p> </p>
<p>Background Information</p>
<p> </p>
<p>IX. Related Work</p>
<p> </p>
<p>Attribute Exchange (1.0), and Simple Registration (1.0
and 1.1 Draft).</p>
<p> </p>
<p>X. Initial Membership</p>
<p> </p>
<p>Allen Tom, <a href="mailto:atom@yahoo-inc.com" target="_blank">atom@yahoo-inc.com</a>. Yahoo! Inc (editor)</p>
<p>Mike Graves, <a href="mailto:mgraves@janrain.com" target="_blank">mgraves@janrain.com</a>, JanRain, Inc.</p>
<p>Dick Hardt, <a href="mailto:dick@skip.com" target="_blank">dick@skip.com</a>. Sxip Identity.</p>
<p>Breno de Medeiros, <a href="mailto:breno@google.com" target="_blank">breno@google.com</a>. Google, Inc.
(editor)</p>
<p>Hideki Nara, <a href="mailto:hdknr@ic-tact.co.jp" target="_blank">hdknr@ic-tact.co.jp</a>, Tact Communications</p>
<p>Nat Sakimura, <a href="mailto:n-sakimura@nri.co.jp" target="_blank">n-sakimura@nri.co.jp</a> (editor)</p>
<p>John Bradley, <a href="mailto:ve7jtb@ve7jtb.com" target="_blank">ve7jtb@ve7jtb.com</a></p>
<p>Will Norris, <a href="mailto:will@willnorris.com" target="_blank">will@willnorris.com</a></p>
<p> </p>
<p>XI. Expected contribution</p>
<p> </p>
<p><a href="http://lists.openid.net/pipermail/openid-specs/attachments/20091117/c5754ef7/attachment-0001.html" target="_blank">http://lists.openid.net/pipermail/openid-specs/attachments/20091117/c5754ef7/attachment-0001.html</a></p>
<p> </p>
<p>=============================================</p>
<p> </p>
<p> </p>
<p>---------- Forwarded message ----------</p>
<p>From: Breno de Medeiros <<a href="mailto:breno@google.com" target="_blank">breno@google.com</a>></p>
<p>Date: Fri, Nov 20, 2009 at 3:07 AM</p>
<p>Subject: Re: AX and Artifact Binding Charter Proposal</p>
<p>To: John Bradley <<a href="mailto:john.bradley@wingaa.com" target="_blank">john.bradley@wingaa.com</a>></p>
<p>Cc: Nat Sakimura <<a href="mailto:sakimura@gmail.com" target="_blank">sakimura@gmail.com</a>>,
<a href="mailto:openid-specs@lists.openid.net" target="_blank">openid-specs@lists.openid.net</a></p>
<p> </p>
<p> </p>
<p>+1</p>
<p> </p>
<p>On Thu, Nov 19, 2009 at 9:46 AM, John Bradley
<<a href="mailto:john.bradley@wingaa.com" target="_blank">john.bradley@wingaa.com</a>> wrote:</p>
<p>> I can live with Nat's latest edit based on Dick's
input.</p>
<p>> </p>
<p>> Let's call the scope done.</p>
<p>> </p>
<p>> John B.</p>
<p>> On 2009-11-19, at 2:39 PM, Breno de Medeiros wrote:</p>
<p>> </p>
<p>>> Agree, let's define the scope, create the WG and
then we can have</p>
<p>>> discussions there.</p>
<p>>> </p>
<p>>> On Thu, Nov 19, 2009 at 7:33 AM, Nat Sakimura
<<a href="mailto:sakimura@gmail.com" target="_blank">sakimura@gmail.com</a>> wrote:</p>
<p>>>> Will,</p>
<p>>>> You are right, but that will be incompatible
with AX 1.0, and the</p>
<p>>>> prerequisite of the scope is that it should
be backward compatible. I feel</p>
<p>>>> that keeping aliases is a small compromise
for keeping the compatibility and</p>
<p>>>> flexibility.</p>
<p>>>> =nat</p>
<p>>>> </p>
<p>>>> On Thu, Nov 19, 2009 at 12:37 PM, Will
Norris <<a href="mailto:will@willnorris.com" target="_blank">will@willnorris.com</a>> wrote:</p>
<p>>>>> </p>
<p>>>>> On Nov 18, 2009, at 7:27 PM, Nat
Sakimura wrote:</p>
<p>>>>> </p>
<p>>>>>> (2009/11/18 15:04), Will Norris
wrote:</p>
<p>>>>>>> On Nov 16, 2009, at 6:42 PM, Nat
Sakimura wrote:</p>
<p>>>>>>> </p>
<p>>>>>>> </p>
<p>>>>>>>> (2009/11/17 10:58), Will
Norris wrote:</p>
<p>>>>>>>> </p>
<p>>>>>>>>> On Nov 16, 2009, at 3:49
PM, Nat Sakimura wrote:</p>
<p>>>>>>>>> </p>
<p>>>>>>>>> </p>
<p>>>>>>>>> </p>
<p>>>>>>>>>> Right. AX 1.1 is to
be expedient so that it will remove the current</p>
<p>>>>>>>>>> acute</p>
<p>>>>>>>>>> pain.</p>
<p>>>>>>>>>> It should be
minimalistic as to the spec change and to the</p>
<p>>>>>>>>>> implementation</p>
<p>>>>>>>>>> change.</p>
<p>>>>>>>>>> </p>
<p>>>>>>>>>> AX 2.0 will be more
generic fix, and that is the place we should</p>
<p>>>>>>>>>> consider</p>
<p>>>>>>>>>> whole bunch of
issues.</p>
<p>>>>>>>>>> </p>
<p>>>>>>>>>> I agree that there
should be discovery way of it in XRD/s for many</p>
<p>>>>>>>>>> use</p>
<p>>>>>>>>>> cases,</p>
<p>>>>>>>>>> but it seems to me
to be in the territory of AX2.0.</p>
<p>>>>>>>>>> </p>
<p>>>>>>>>>> Attached please find
the first cut of AX1.1 Draft01.</p>
<p>>>>>>>>>> </p>
<p>>>>>>>>>> </p>
<p>>>>>>>>> It looks like you have
policy URL defined as an actual AX attribute?</p>
<p>>>>>>>>> How would that
work if the RP is sending the URL to the OP. Doesn't it</p>
<p>>>>>>>>> need to be a standalone
parameter like update_url is?</p>
<p>>>>>>>>> </p>
<p>>>>>>>>> </p>
<p>>>>>>>> In this 1.1 draft, I have
added the capability for the fetch request</p>
<p>>>>>>>> to include
"value"/"parameter".</p>
<p>>>>>>>> Thus, you can do something
like:</p>
<p>>>>>>>> </p>
<p>>>>>>>>
<a href="http://openid.ns.ax" target="_blank">openid.ns.ax</a>=<a href="http://openid.net/srv/ax/1.1" target="_blank">http://openid.net/srv/ax/1.1</a></p>
<p>>>>>>>> openid.ax.mode=fetch_request</p>
<p>>>>>>>>
openid.ax.type.policy_url=<a href="http://axschema.org/policy_url" target="_blank">http://axschema.org/policy_url</a></p>
<p>>>>>>>>
openid.ax.value.policy_url=<a href="http://examplerp.com/data_usage_policy.html" target="_blank">http://examplerp.com/data_usage_policy.html</a></p>
<p>>>>>>>> </p>
<p>>>>>>> ahh, I missed that. This
actually brings up a bigger concern regarding</p>
<p>>>>>>> what features go into 1.1 versus
2.0. During IIW, we talked about needing a</p>
<p>>>>>>> more robust message format,
(even serialized XML or JSON was thrown about).</p>
<p>>>>>>> I've heard all kinds of
ideas for attached metadata to attributes in an AX</p>
<p>>>>>>> request...</p>
<p>>>>>>> </p>
<p>>>>>>> - give me a verified email
address</p>
<p>>>>>>> - give me an email address
that was verified using method X</p>
<p>>>>>>> - tell me if the email
address "<a href="mailto:bob@example.com" target="_blank">bob@example.com</a>" belongs to this user</p>
<p>>>>>>> - give me a payment token
authorized for up to $50</p>
<p>>>>>>> </p>
<p>>>>>>> and I'm sure folks have many,
many more. In order to support these</p>
<p>>>>>>> kinds of scenarios, we will almost
certainly need something richer than the</p>
<p>>>>>>> extended request format
currently included in the 1.1 draft. I'm a little</p>
<p>>>>>>> concerned about changing the
message format for 1.1, and then turning around</p>
<p>>>>>>> and changing it again for 2.0.
(If others are okay with this prospect, and</p>
<p>>>>>>> it's just something I need to
get over, that's fine)</p>
<p>>>>>>> </p>
<p>>>>>> I understand this concern, but on
the other hand, I have got the feeling</p>
<p>>>>>> that it will not change too much
either.</p>
<p>>>>>> I have got the feeling that it ends
up as</p>
<p>>>>>> </p>
<p>>>>>>
ax.type.<alias>=<a href="http://openid.net/spec/ax/2.0/json" target="_blank">http://openid.net/spec/ax/2.0/json</a></p>
<p>>>>>> ax.type.value.<alias>=[json
file]</p>
<p>>>>>> </p>
<p>>>>>> which is the same as we have now.
Only the difference is that we are not</p>
<p>>>>>> any more using any other
<alias>,</p>
<p>>>>>> and we will not need
<alias>.count.</p>
<p>>>>>> </p>
<p>>>>>> Of course, we have to agree on how
to express attributes in json format,</p>
<p>>>>>> agree on signature, etc. and these
are the main things that we should be</p>
<p>>>>>> dealing with in AX 2.0. Then, the
finer semantics / data format / etc.needs</p>
<p>>>>>> to be addressed in other WGs
specifically for that purpose. CX WG is one</p>
<p>>>>>> example of such thing.</p>
<p>>>>>> </p>
<p>>>>>> Needless to say, if you wanted to
use SAML assertion in it, you could do</p>
<p>>>>>> something like</p>
<p>>>>>> </p>
<p>>>>>>
ax.type.<alias>=<a href="http://openid.net/spec/ax/2.0/saml/2.0" target="_blank">http://openid.net/spec/ax/2.0/saml/2.0</a></p>
<p>>>>>> ax.type.value.<alias>=[saml
assertion]</p>
<p>>>>>> </p>
<p>>>>>> etc. as well.</p>
<p>>>>> </p>
<p>>>>> If you're going to do that, then why
even keep the aliases around? Why</p>
<p>>>>> not just have</p>
<p>>>>> </p>
<p>>>>> <a href="http://ns.ax" target="_blank">ns.ax</a> = <a href="http://openid.net/specs/ax/2.0" target="_blank">http://openid.net/specs/ax/2.0</a></p>
<p>>>>> ax = [json/xml file]</p>
<p>>>>> </p>
<p>>>>> That would be perfectly valid and avoid
the overhead. Now I'm not</p>
<p>>>>> actually suggesting we do this, because
I don't think we have a clear</p>
<p>>>>> understanding of the requirements for AX
2.0. But my point is, we may end</p>
<p>>>>> up with something drastically different
from AX 1.0. I'm actually okay with</p>
<p>>>>> that prospect, and kind of like the idea
that we have the freedom to make</p>
<p>>>>> such a complete departure if we thinking
it's warranted. I'd hate to make a</p>
<p>>>>> hasty decision now, expecting that it
will *probably* be compatible with</p>
<p>>>>> what we come up with in AX 2.0, only to
find that it is actually a</p>
<p>>>>> hindrance. I don't know that this
is going to be a problem, but that's</p>
<p>>>>> exactly my point... we don't know.
So the fewer changes we make in AX 1.1,</p>
<p>>>>> the better, I think.</p>
<p>>>>> </p>
<p>>>>> -will</p>
<p>>>>> </p>
<p>>>>>
_______________________________________________</p>
<p>>>>> specs mailing list</p>
<p>>>>> <a href="mailto:specs@lists.openid.net" target="_blank">specs@lists.openid.net</a></p>
<p>>>>>
<a href="http://lists.openid.net/mailman/listinfo/openid-specs" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs</a></p>
<p>>>> </p>
<p>>>> </p>
<p>>>> </p>
<p>>>> --</p>
<p>>>> Nat Sakimura (=nat)</p>
<p>>>> <a href="http://www.sakimura.org/en/" target="_blank">http://www.sakimura.org/en/</a></p>
<p>>>> </p>
<p>>>>
_______________________________________________</p>
<p>>>> specs mailing list</p>
<p>>>> <a href="mailto:specs@lists.openid.net" target="_blank">specs@lists.openid.net</a></p>
<p>>>> <a href="http://lists.openid.net/mailman/listinfo/openid-specs" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs</a></p>
<p>>>> </p>
<p>>>> </p>
<p>>> </p>
<p>>> </p>
<p>>> </p>
<p>>> --</p>
<p>>> --Breno</p>
<p>>> </p>
<p>>> +1 (650) 214-1007 desk</p>
<p>>> +1 (408) 212-0135 (Grand Central)</p>
<p>>> MTV-41-3 : 383-A</p>
<p>>> PST (GMT-8) / PDT(GMT-7)</p>
<p>>> _______________________________________________</p>
<p>>> specs mailing list</p>
<p>>> <a href="mailto:specs@lists.openid.net" target="_blank">specs@lists.openid.net</a></p>
<p>>>
<a href="http://lists.openid.net/mailman/listinfo/openid-specs" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs</a></p>
<p>> </p>
<p>> </p>
<p> </p>
<p> </p>
<p> </p>
<p>--</p>
<p>--Breno</p>
<p> </p>
<p>+1 (650) 214-1007 desk</p>
<p>+1 (408) 212-0135 (Grand Central)</p>
<p>MTV-41-3 : 383-A</p>
<p>PST (GMT-8) / PDT(GMT-7)</p>
<p> </p>
<p> </p>
<p> </p>
<p>-- </p>
<p>Nat Sakimura (=nat)</p>
<p><a href="http://www.sakimura.org/en/" target="_blank">http://www.sakimura.org/en/</a></p>
<p><a href="http://twitter.com/_nat_en" target="_blank">http://twitter.com/_nat_en</a></p>
<p>_______________________________________________</p>
<p>specs mailing list</p>
<p><a href="mailto:specs@lists.openid.net" target="_blank">specs@lists.openid.net</a></p>
<p><a href="http://lists.openid.net/mailman/listinfo/openid-specs" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs</a></p>
<p> </p>
</div></div></div>
</div>
</blockquote></div><br><br clear="all"><br></div></div>-- <br><div class="im">Nat Sakimura (=nat)<br><a href="http://www.sakimura.org/en/" target="_blank">http://www.sakimura.org/en/</a><br><a href="http://twitter.com/_nat_en" target="_blank">http://twitter.com/_nat_en</a><br>
</div></div>
</blockquote></div><br>