Well, yeah, but I think specs-committee is not talking about (d). <br><br>I also considered splitting it into dsig and cx, but current spec process is a kind of heavy lifting, so I was hoping that I could do it in one shot. Also, one of the beauty of OpenID specs were not being modularized so much, so that you do not have to go through so many specs. From the point of veiw of the modularity, I would split the authentication spec as well into (1) Discovery (of both canonical ID e.g., URI with fragment and services), (2) Assertion Format (3) Signature methods (4) Protocols. [I actually prefer this way, but I've got a feeling that this community wants a monolithic spec.]<br>
<br>=nat<br><br><div class="gmail_quote">On Wed, Dec 24, 2008 at 9:49 AM, Peter Williams <span dir="ltr"><<a href="mailto:pwilliams@rapattoni.com">pwilliams@rapattoni.com</a>></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;">
It will fail d.<br>
<br>
but so will almost any proposal. D is just an excuse used to shoot down the direction. Its subjective, and one simply hires any 2 bit lawyer to (always) say there exists liability greater than zero.<br>
<br>
Break your proposal down. Make it simpler.<br>
<br>
The scheme for symmetric signatures supported by the symmetrickey management regime in openid auth V2 will be augmented with a scheme based on public key signatures supported by asymmetric key management.<br>
<br>
Get that passed. then make another.<br>
<br>
An openid extension will be specified communicating text values that will allow entities to attach legal terms to openid auth messages, specially focussing on forming those private associations over which assertions may bear public key signatures.<br>
<br>
Get it passed.<br>
<br>
<br>
Then call for a merger: half way through, once the politics has died down a bit. Recognize its running straight into xmldsig signature's space.<br>
<br>
Each of those needs to be now defensible in its own right. The first is substantiated under the desire to sastify legal signature laws reqiring that qualified certificates support certain types of signed assertions (eu) . The second is substantiated on...<br>
<br>
<br>
Getting the propopsal passed has nothing to do with specifying the technical solution.<br>
<br>
<br>
<br>
________________________________<br>
From: Sakimura Nat <<a href="mailto:n-sakimura@nri.co.jp">n-sakimura@nri.co.jp</a>><br>
Sent: Tuesday, December 23, 2008 4:10 PM<br>
To: David Recordon <<a href="mailto:recordond@gmail.com">recordond@gmail.com</a>>; Mike Jones <<a href="mailto:Michael.Jones@microsoft.com">Michael.Jones@microsoft.com</a>><br>
Cc: <a href="mailto:general@openid.net">general@openid.net</a> <<a href="mailto:general@openid.net">general@openid.net</a>>; <a href="mailto:specs-council@openid.net">specs-council@openid.net</a> <<a href="mailto:specs-council@openid.net">specs-council@openid.net</a>><br>
Subject: Re: [OpenID] [OIDFSC] FW: Proposal to create the TX working group<br>
<div><div></div><div class="Wj3C7c"><br>
Thanks.<br>
<br>
I did not know that specs-council list is actually subscribable.<br>
I now have subscribed to it.<br>
<br>
From what I see from the archive, the biggest objection seems to be the signature.<br>
<br>
> "A Public Key Cryptography based digital signature method", but isn't it already<br>
> defined how to sign chunks of XML? Why would the working group be developing<br>
> a new signature mechanism?<br>
Let me explain on it.<br>
<br>
CX is not XML based. It is tag-value based. I do not think there is any generalized public key based signature algorithm that enables one to sign tag-value based on name spaces. What is defined in OAuth comes close, but it needs generalization as it is specific to OAuth. If there s a generalized such method, please point it to me. I understand that AuthN 2.1 would be looking at doing it. However, it is not there yet so it cannot be cited. Once it gets citable, I envision that it will be citing it instead of incorporating it into the CX spec.<br>
<br>
For other points, it would be appreciated very much if you could explicitly state the points. Then, I would be replying to them.<br>
<br>
By the way, from the process point, I believe that the specs council needs to be stating one of the reason stated in "4.2 Review". It needs to be one of<br>
<br>
(a) an incomplete Proposal (i.e., failure to comply with §4.1);<br>
<br>
(b) a determination that the proposal contravenes the OpenID community's purpose;<br>
<br>
(c) a determination that the proposed WG does not have sufficient support to succeed<br>
or to deliver proposed deliverables within projected completion dates; or<br>
<br>
(d) a determination that the proposal is likely to cause legal liability for the OIDF or others.<br>
<br>
On what point the current proposal falls into?<br>
<br>
Regards,<br>
<br>
=nat<br>
<br>
<br>
<br>
________________________________<br>
差出人: David Recordon [<a href="mailto:recordond@gmail.com">recordond@gmail.com</a>]<br>
送信日時: 2008年12月24日 2:54<br>
宛先: Mike Jones<br>
CC: Sakimura Nat; <a href="mailto:specs-council@openid.net">specs-council@openid.net</a><br>
件名: Re: [OIDFSC] FW: Proposal to create the TX working group<br>
<br>
I think that's a reasonable recommendation, though would like to first approach Nat to see if the charter can be made to address these concerns and then resubmitted for review.<br>
<br>
--David<br>
<br>
</div></div><div class="Ih2E3d">On Mon, Dec 22, 2008 at 9:20 PM, Mike Jones <<a href="mailto:Michael.Jones@microsoft.com">Michael.Jones@microsoft.com</a><mailto:<a href="mailto:Michael.Jones@microsoft.com">Michael.Jones@microsoft.com</a>>> wrote:<br>
<br>
I have to agree with David that this charter is far from minimal or specific in many respects. One of my concerns is the same as David's below – when XMLDSIG and other signature algorithms already exist, it is incumbent upon the proposers to justify the creation of yet another, incompatible signature algorithm.<br>
<br>
<br>
<br>
It is therefore my recommendation that the specifications council communicate something like this position to the membership to guide their vote about this working group:<br>
<br>
<br>
<br>
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.<br>
<br>
<br>
<br>
We, as a specs council, have an obligation to promptly produce a recommendation prior to the membership vote. My stab at our recommendation is above. Wordsmithing welcome. If you disagree, please supply alternate wording that you think we should use instead.<br>
<br>
<br>
<br>
-- Mike<br>
<br>
<br>
<br>
<br>
<br>
</div>From: David Recordon [mailto:<a href="mailto:recordond@gmail.com">recordond@gmail.com</a><mailto:<a href="mailto:recordond@gmail.com">recordond@gmail.com</a>>]<br>
<div class="Ih2E3d"><br>
Sent: Monday, December 22, 2008 10:20 AM<br>
To: Nat Sakimura<br>
</div>Cc: Mike Jones; <a href="mailto:specs-council@openid.net">specs-council@openid.net</a><mailto:<a href="mailto:specs-council@openid.net">specs-council@openid.net</a>><br>
<div class="Ih2E3d">Subject: Re: [OIDFSC] FW: Proposal to create the TX working group<br>
<br>
<br>
<br>
To update Nat's note, the proposal is actually at <a href="http://wiki.openid.net/Working_Groups%3AContract_Exchange_1" target="_blank">http://wiki.openid.net/Working_Groups%3AContract_Exchange_1</a> (the wiki doesn't like periods in URLs).<br>
<br>
While the number of specifications listed has been reduced, it still feels nebulous in terms of what will be produced as laid out by the purpose and scope. For example, the scope says that the working group will develop "A Public Key Cryptography based digital signature method", but isn't it already defined how to sign chunks of XML? Why would the working group be developing a new signature mechanism?<br>
<br>
--David<br>
<br>
</div><div class="Ih2E3d">On Thu, Dec 18, 2008 at 9:09 PM, Nat Sakimura <<a href="mailto:n-sakimura@nri.co.jp">n-sakimura@nri.co.jp</a><mailto:<a href="mailto:n-sakimura@nri.co.jp">n-sakimura@nri.co.jp</a>>> wrote:<br>
<br>
The most current version is here: <a href="http://wiki.openid.net/Working_Groups:Contract_Exchange_1.0" target="_blank">http://wiki.openid.net/Working_Groups:Contract_Exchange_1.0</a><br>
<br>
Since AX 2.0 WG is spinning up, I have removed it from the possible output of this WG.<br>
<br>
=nat<br>
<br>
Mike Jones wrote:<br>
<br>
Forwarding this note to the list to kick off the actual specs council work on this spec…<br>
<br>
<br>
[Deleted the rest of the thread to bring the message below the current 40K list size limit]<br>
<br>
<br>
<br>
</div>_______________________________________________<br>
general mailing list<br>
<a href="mailto:general@openid.net">general@openid.net</a><br>
<a href="http://openid.net/mailman/listinfo/general" target="_blank">http://openid.net/mailman/listinfo/general</a><br>
</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>