Hi David,&nbsp;<div><br></div><div>Since I am in the new years holiday (just when you got back from your holiday...), I will just comment on a few things inline to supplement Henrik and Drummond&#39;s comments.&nbsp;<br><br><div class="gmail_quote">
On Wed, Dec 31, 2008 at 5:33 PM, David Recordon <span dir="ltr">&lt;<a href="mailto:recordond@gmail.com">recordond@gmail.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Hi Nat,<br>I read Josh&#39;s email as agreeing with Mike&#39;s statement of:<div class="Ih2E3d"><br><blockquote style="border-left:1px solid rgb(204, 204, 204);margin:0pt 0pt 0pt 0.8ex;padding-left:1ex" class="gmail_quote">
The OpenID Specifications Council recommends that members reject this proposal to create a working group because the charter is excessively broad, it seems to propose the creation of new mechanisms that unnecessarily create new ways to do accomplish existing tasks, such as digital signatures, and it the proposal is not sufficiently clear on whether it builds upon existing mechanisms such as AX 1.0 in a compatible manner, or whether it requires breaking changes to these underlying protocols.</blockquote>
</div></blockquote><div><br></div><div>I think it is very clear that it builds upon AX. Whether additional message portion goes into AX 2.0 or CX depends on how AX2.0 (as the AX 2.0 charter being drafted, it goes in there) evolves.&nbsp;</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="Ih2E3d"><blockquote style="border-left:1px solid rgb(204, 204, 204);margin:0pt 0pt 0pt 0.8ex;padding-left:1ex" class="gmail_quote">
</blockquote>
</div><div><br>While you have clarified that you don&#39;t intend to create a new XML signature mechanism, OAuth describes a mechanism to use public keys to sign these sorts of parameters.&nbsp; Signatures aside, as Mike said other aspects of the charter seem quite broad and it is unclear how it will build upon AX 1.0 and other underlying existing OpenID technologies.</div>
</blockquote><div><br></div><div>I am expecting OAuth style signature is coming into AuthN 2.1. Then, CX would use it. OAuth signature per se has to be profiled into OpenID to be used in OpenID message signing anyways, so just referencing OAuth is not quite adequate.&nbsp;</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div><br>
<br>Given the draft charter at <a href="http://wiki.openid.net/Working_Groups%3AContract_Exchange_1" target="_blank">http://wiki.openid.net/Working_Groups%3AContract_Exchange_1</a>:<br>1) The purpose of producing a series of extensions seems too broad.&nbsp; OpenID was born on the idea of doing one simple thing and we&#39;ve seen success with OpenID and related technologies when they are made up of small pieces loosely joined.&nbsp; OpenID Authentication 2.0 broke this rule in some areas and we&#39;re now seeing the repercussions of doing so.</div>
</blockquote><div><br></div><div>&quot;Series of &quot; is there to allow the possibility of modularization. It might become clear at a later day when WG work progressed more that it could be refactored into more than one specification. (For example, I believe that AuthN 2.0 could have been modularized into Discovery, Assertion format, Signature, and Messaging protocol, and PAPE could have been into two modules.) It is hard to know if such modularization is really desirable at the outset. Thus, I have thrown in the word &quot;series of.&quot; Not allowing it would tend to build a monolithic spec., which is exactly what you are trying to avoid now.&nbsp;</div>
<div>&nbsp;</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div><br>
<br>2) In what jurisdictions are these contracts legally binding?&nbsp; Is &quot;arbitrary parties to create and exchange a mutually-digitally-signed legally binding &#39;contract&#39;&quot; a justifiable statement or should it be toned down?&nbsp; It should also be kept in mind that since OpenID&#39;s creation it has been very clear that OpenID does not provide trust, but rather trust can be built on top of identity.&nbsp; I&#39;m not saying that OpenID should never deal with trust, just trying to understand if this Working Group intends to change how OpenID currently does not create this form of trust.<br>

<br>3) The purpose says that the Working Group intends to possibly extend AX and create a series of specifications.&nbsp; </div></blockquote><div><br></div><div>&nbsp;Extending AX actually was what was suggested at IIW with Dick. Subsequently, it was moved to AX 2.0 WG proposal.&nbsp;</div>
<div>See Out of scope section. It states:&nbsp;</div><div><span class="Apple-style-span" style="color: rgb(68, 68, 68); font-family: &#39;Segoe UI&#39;; line-height: 19px; "><br></span></div><div><span class="Apple-style-span" style="color: rgb(68, 68, 68); font-family: &#39;Segoe UI&#39;; line-height: 19px; ">OpenID AX 2.0 was moved out to another WG, which includes the following pre-requsite for this WG.</span></div>
<span class="Apple-style-span" style="color: rgb(68, 68, 68); font-family: &#39;Segoe UI&#39;; line-height: 19px; "><ul style="padding-top: 0px; padding-right: 0px; padding-bottom: 0px; padding-left: 0px; border-top-width: 0px; border-right-width: 0px; border-bottom-width: 0px; border-left-width: 0px; border-style: initial; border-color: initial; font-weight: inherit; font-style: inherit; font-size: 100%; font-family: inherit; vertical-align: baseline; margin-top: 0px; margin-right: 0px; margin-left: 3em; margin-bottom: 1.2em; ">
<li style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; padding-top: 0px; padding-right: 0px; padding-bottom: 0px; padding-left: 0px; border-top-width: 0px; border-right-width: 0px; border-bottom-width: 0px; border-left-width: 0px; border-style: initial; border-color: initial; font-weight: inherit; font-style: inherit; font-size: 100%; font-family: inherit; vertical-align: baseline; ">
Request/Response type message &quot;Exchange&quot;</li><li style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; padding-top: 0px; padding-right: 0px; padding-bottom: 0px; padding-left: 0px; border-top-width: 0px; border-right-width: 0px; border-bottom-width: 0px; border-left-width: 0px; border-style: initial; border-color: initial; font-weight: inherit; font-style: inherit; font-size: 100%; font-family: inherit; vertical-align: baseline; ">
Direct Communication method in both direction (OP&lt;-&gt;RP)</li></ul></span><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div>It does not seem prudent to give a Working Group the ability to arbitrarily extend an existing extension or create an unlimited number of specifications.</div>
</blockquote><div><br></div><div>It is not. The WG is bound by the scope. The WG may decide to break up its scoped output into smaller pieces for modularity purpose (that&#39;s what is routinely done in OASIS etc.), but overall output is MUST be TIGHTER than the scope.&nbsp;</div>
<div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div><br>
<br>4) The Scope section is still not clear as to what the Working Group will actually be producing.&nbsp; I would prefer to see the section rewritten, maybe mimicking the structure currently being considered for the specification.<br>

<br>As to if you wish to force this proposal forward, I do not believe that it currently has sufficient support within the OpenID community to succeed and that its broad scope contravenes the community&#39;s purpose.&nbsp; This is why I&#39;m really hoping that the proposal can be refined to something which will be successful that a broad community can get behind!<br>
<font color="#888888">
<br>--David<br></font></div><div><div></div><div class="Wj3C7c"><br><div class="gmail_quote">On Tue, Dec 30, 2008 at 9:03 PM, Nat Sakimura <span dir="ltr">&lt;<a href="mailto:sakimura@gmail.com" target="_blank">sakimura@gmail.com</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="border-left:1px solid rgb(204, 204, 204);margin:0pt 0pt 0pt 0.8ex;padding-left:1ex">
<div>Hi Josh,&nbsp;</div><div><br></div><div>To which statement did you agree?</div><div><br></div><div>There has been a several things that has been pointed out, but I think I have answered to them.&nbsp;</div><div><br></div><div>

For example, for XML Sig, I have stated that this spec is not for XML, etc.&nbsp;</div>
<div>For modularization, yes, that is a possibility but a scope needs to be able to cover a field that it requires, even if it ends up not covering that field.&nbsp;</div><div>It is impossible to widen the scope though narrowing it down at a later date is easy.&nbsp;</div>


<div><br></div><div>Unfortunately, I have not heard back any concrete response for&nbsp;amendments. It would be more constructive to have those.&nbsp;</div><div><br></div><div>Also, if you are giving advise to the membership an recommendation for not approving it, you need to state the reasons concretely.&nbsp;</div>

<div>
<div><br></div><div>It needs to be one of&nbsp;</div><div><br></div></div><div><span style="border-collapse:collapse;color:rgb(80, 0, 80)"><div><div dir="ltr"><font face="Arial" size="2">(a)&nbsp;&nbsp;&nbsp; an incomplete Proposal (i.e., failure to comply with §4.1);<br>


(b)&nbsp;&nbsp;&nbsp; a determination that the proposal contravenes the OpenID community&#39;s purpose;<br>(c) &nbsp; &nbsp;a determination that the proposed WG does not have sufficient support to succeed</font></div><div dir="ltr"><font face="Arial" size="2"><font face="arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</font>or to deliver proposed deliverables within projected completion dates; or<br>


(d)&nbsp;&nbsp;&nbsp; a&nbsp; determination that the proposal is likely to cause legal liability for the OIDF or others.&nbsp;<br></font></div><div><br></div></div><div>and should state why the proposal falls into one of the criteria concretely and accountably.&nbsp;</div>


<div><br></div><div>Regards,&nbsp;</div><div><br></div><font color="#888888"><div>=nat</div></font></span></div><div><div></div><div><span style="border-collapse:collapse"><div style="color:rgb(80, 0, 80)">
<div dir="ltr"><br></div>
</div></span><div class="gmail_quote">On Wed, Dec 31, 2008 at 7:58 AM, Josh Hoyt <span dir="ltr">&lt;<a href="mailto:josh@janrain.com" target="_blank">josh@janrain.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="border-left:1px solid rgb(204, 204, 204);margin:0pt 0pt 0pt 0.8ex;padding-left:1ex">


On Tue, Dec 30, 2008 at 12:17 PM, Mike Jones<br>
<div>&lt;<a href="mailto:Michael.Jones@microsoft.com" target="_blank">Michael.Jones@microsoft.com</a>&gt; wrote:<br>
</div><div>&gt; I realize it was Christmas week but it&#39;s been a week and we&#39;ve heard nothing<br>
&gt; from any of the other specs council members on this proposal (or the other<br>
&gt; one as well).<br>
<br>
</div>I agree with the statement that you made about this proposal.<br>
<font color="#888888"><br>
Josh<br>
</font></blockquote></div><br><br clear="all"><br></div></div><div><div></div><div>-- <br>Nat Sakimura (=nat)<br><a href="http://www.sakimura.org/en/" target="_blank">http://www.sakimura.org/en/</a><br>
</div></div></blockquote></div><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>Nat Sakimura (=nat)<br><a href="http://www.sakimura.org/en/">http://www.sakimura.org/en/</a><br>
</div>