No subject
Fri Aug 15 23:49:43 UTC 2008
nature.
> "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 develo=
ping
> a new signature mechanism?
Let me explain on it.
CX is not XML based. It is tag-value based. I do not think there is any gen=
eralized 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 ne=
eds generalization as it is specific to OAuth. If there s a generalized suc=
h method, please point it to me. I understand that AuthN 2.1 would be looki=
ng 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 incorporatin=
g it into the CX spec.
For other points, it would be appreciated very much if you could explicitly=
state the points. Then, I would be replying to them.
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
(a) an incomplete Proposal (i.e., failure to comply with =1B$B!x=1B(B4.1=
);
(b) a determination that the proposal contravenes the OpenID community's=
purpose;
(c) a determination that the proposed WG does not have sufficient suppo=
rt to succeed
or to deliver proposed deliverables within projected completion dat=
es; or
(d) a determination that the proposal is likely to cause legal liabilit=
y for the OIDF or others.
On what point the current proposal falls into?
Regards,
=3Dnat
________________________________
=1B$B:9=3DP?M=1B(B: David Recordon [recordond at gmail.com<mailto:recordond at gm=
ail.com>]
=1B$BAw?.F|;~=1B(B: 2008=1B$BG/=1B(B12=1B$B7n=1B(B24=1B$BF|=1B(B 2:54
=1B$B08 at h=1B(B: Mike Jones
CC: Sakimura Nat; specs-council at openid.net<mailto:specs-council at openid.net>
=1B$B7oL>=1B(B: Re: [OIDFSC] FW: Proposal to create the TX working group
I think that's a reasonable recommendation, though would like to first appr=
oach Nat to see if the charter can be made to address these concerns and th=
en resubmitted for review.
--David
On Mon, Dec 22, 2008 at 9:20 PM, Mike Jones <Michael.Jones at microsoft.com<ma=
ilto:Michael.Jones at microsoft.com><mailto:Michael.Jones at microsoft.com<mailto=
:Michael.Jones at microsoft.com>>> wrote:
I have to agree with David that this charter is far from minimal or specifi=
c 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 signatu=
re algorithm.
It is therefore my recommendation that the specifications council communica=
te something like this position to the membership to guide their vote about=
this working group:
The OpenID Specifications Council recommends that members reject this propo=
sal to create a working group because the charter is excessively broad, it =
seems to propose the creation of new mechanisms that unnecessarily create n=
ew 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 br=
eaking changes to these underlying protocols.
We, as a specs council, have an obligation to promptly produce a recommenda=
tion prior to the membership vote. My stab at our recommendation is above.=
Wordsmithing welcome. If you disagree, please supply alternate wording t=
hat you think we should use instead.
-- Mike
From: David Recordon [mailto:recordond at gmail.com<mailto:recordond at gmail.com=
><mailto:recordond at gmail.com<mailto:recordond at gmail.com>>]
Sent: Monday, December 22, 2008 10:20 AM
To: Nat Sakimura
Cc: Mike Jones; specs-council at openid.net<mailto:specs-council at openid.net><m=
ailto:specs-council at openid.net<mailto:specs-council at openid.net>>
Subject: Re: [OIDFSC] FW: Proposal to create the TX working group
To update Nat's note, the proposal is actually at http://wiki.openid.net/Wo=
rking_Groups%3AContract_Exchange_1 (the wiki doesn't like periods in URLs).
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 s=
cope. For example, the scope says that the working group will develop "A P=
ublic Key Cryptography based digital signature method", but isn't it alread=
y defined how to sign chunks of XML? Why would the working group be develo=
ping a new signature mechanism?
--David
On Thu, Dec 18, 2008 at 9:09 PM, Nat Sakimura <n-sakimura at nri.co.jp<mailto:=
n-sakimura at nri.co.jp><mailto:n-sakimura at nri.co.jp<mailto:n-sakimura at nri.co.=
jp>>> wrote:
The most current version is here: http://wiki.openid.net/Working_Groups:Con=
tract_Exchange_1.0
Since AX 2.0 WG is spinning up, I have removed it from the possible output =
of this WG.
=3Dnat
Mike Jones wrote:
Forwarding this note to the list to kick off the actual specs council work =
on this spec=1B$B!D=1B(B
[Deleted the rest of the thread to bring the message below the current 40K =
list size limit]
_______________________________________________
general mailing list
general at openid.net<mailto:general at openid.net>
http://openid.net/mailman/listinfo/general
--
Nat Sakimura (=3Dnat)
http://www.sakimura.org/en/
--_000_C11F8A453DFFBE49A9F0D75873F554462A784D7721NAEXMSGC118re_
Content-Type: text/html; charset="iso-2022-jp"
Content-Transfer-Encoding: quoted-printable
<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=
//www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=3DContent-Type content=3D"text/html; charset=3Diso-2022-jp=
">
<meta name=3DGenerator content=3D"Microsoft Word 12 (filtered medium)">
<style>
<!--
/* Font Definitions */
@font-face
{font-family:PMingLiU;
panose-1:2 2 5 0 0 0 0 0 0 0;}
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
{font-family:"\@PMingLiU";
panose-1:2 2 5 0 0 0 0 0 0 0;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"PMingLiU","serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
span.EmailStyle17
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;}
@page Section1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.Section1
{page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang=3DEN-US link=3Dblue vlink=3Dpurple>
<div class=3DSection1>
<p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calibri",=
"sans-serif";
color:#1F497D'>If the different pieces are separately describable and
separately usable (and in particular, separately reusable), I, for one, bel=
ieve
that it would be far more advantageous to the community for these pieces to
actually be separate working group deliverables, each of which can be judge=
d on
their own merits.<o:p></o:p></span></p>
<p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calibri",=
"sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calibri",=
"sans-serif";
color:#1F497D'> =
&nb=
sp; =
&nb=
sp; =
--
Mike<o:p></o:p></span></p>
<p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calibri",=
"sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<div style=3D'border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in =
0in 0in'>
<p class=3DMsoNormal><b><span style=3D'font-size:10.0pt;font-family:"Tahoma=
","sans-serif"'>From:</span></b><span
style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'>
general-bounces at openid.net [mailto:general-bounces at openid.net] <b>On Behalf=
Of </b>Nat
Sakimura<br>
<b>Sent:</b> Tuesday, December 23, 2008 7:43 PM<br>
<b>To:</b> Peter Williams<br>
<b>Cc:</b> general at openid.net<br>
<b>Subject:</b> Re: [OpenID] [OIDFSC] FW: Proposal to create the TX working
group<o:p></o:p></span></p>
</div>
<p class=3DMsoNormal><o:p> </o:p></p>
<p class=3DMsoNormal style=3D'margin-bottom:12.0pt'>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 i=
s 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 th=
at
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) Discover=
y
(of both canonical ID e.g., URI with fragment and services), (2) Assertion
Format (3) Signature methods (4) Protocols. [I actually prefer this way, bu=
t
I've got a feeling that this community wants a monolithic spec.]<br>
<br>
=3Dnat<o:p></o:p></p>
<div>
<p class=3DMsoNormal>On Wed, Dec 24, 2008 at 9:49 AM, Peter Williams <<a
href=3D"mailto:pwilliams at rapattoni.com">pwilliams at rapattoni.com</a>> wro=
te:<o:p></o:p></p>
<p class=3DMsoNormal>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 managemen=
t
regime in openid auth V2 will be augmented with a scheme based on public ke=
y
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 a=
llow
entities to attach legal terms to openid auth messages, specially focussing=
on
forming those private associations over which assertions may bear public ke=
y
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 tha=
t
qualified certificates support certain types of signed assertions (eu) . Th=
e
second is substantiated on...<br>
<br>
<br>
Getting the propopsal passed has nothing to do with specifying the technica=
l
solution.<br>
<br>
<br>
<br>
________________________________<br>
From: Sakimura Nat <<a href=3D"mailto:n-sakimura at nri.co.jp">n-sakimura at n=
ri.co.jp</a>><br>
Sent: Tuesday, December 23, 2008 4:10 PM<br>
To: David Recordon <<a href=3D"mailto:recordond at gmail.com">recordond at gma=
il.com</a>>;
Mike Jones <<a href=3D"mailto:Michael.Jones at microsoft.com">Michael.Jones=
@microsoft.com</a>><br>
Cc: <a href=3D"mailto:general at openid.net">general at openid.net</a> <<a
href=3D"mailto:general at openid.net">general at openid.net</a>>; <a
href=3D"mailto:specs-council at openid.net">specs-council at openid.net</a> <<=
a
href=3D"mailto:specs-council at openid.net">specs-council at openid.net</a>><b=
r>
Subject: Re: [OpenID] [OIDFSC] FW: Proposal to create the TX working group<=
o:p></o:p></p>
<div>
<div>
<p class=3DMsoNormal style=3D'margin-bottom:12.0pt'><br>
Thanks.<br>
<br>
I did not know that specs-council list is actually subscribable.<br>
I now have subscribed to it.<br>
<br>
More information about the general
mailing list