<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Peter,<div><br></div><div>Yes some of us see the possibility of XRD as signed meta-data being a&nbsp;useful&nbsp;alternative&nbsp;to&nbsp;X.509 eventually.</div><div><br></div><div>If we have&nbsp;an&nbsp;signature&nbsp;method&nbsp;that&nbsp;supports&nbsp;enveloping&nbsp;signatures,&nbsp;&nbsp;XRD&nbsp;will&nbsp;be&nbsp;more&nbsp;useful&nbsp;for&nbsp;those&nbsp;applications.</div><div><br></div><div>We&nbsp;can&nbsp;opt&nbsp;for&nbsp;the&nbsp;simplest&nbsp;signing, that of signing the binary representation of the XRD and keeping the signature in a detached file.&nbsp;</div><div>This may make life simpler for scripting languages dealing with cannonicalization &nbsp;but at the cost of making it awkward to deal with in other environments where having the signature in the same document is very useful.</div><div><br></div><div>Full XMLDsig is ugly because of qnames and other issues. &nbsp; We are proposing a constrained implementation that eliminates most of the cannonicalization complexities, &nbsp;but is still compatible with existing libraries.</div><div><br></div><div>John B.<br><div><div>On 10-Jun-09, at 12:10 PM, <a href="mailto:general-request@openid.net">general-request@openid.net</a> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><span class="Apple-style-span" style="font-family: monospace; ">Date: Wed, 10 Jun 2009 09:10:44 -0700<br>From: Peter Williams &lt;<a href="mailto:pwilliams@rapattoni.com">pwilliams@rapattoni.com</a>&gt;<br>Subject: Re: [OpenID] Signing method for XRD<br>To: Santosh Rajan &lt;<a href="mailto:santrajan@gmail.com">santrajan@gmail.com</a>&gt;, "<a href="mailto:general@openid.net">general@openid.net</a>"<br><span class="Apple-tab-span" style="white-space: pre; ">        </span>&lt;<a href="mailto:general@openid.net">general@openid.net</a>&gt;<br>Message-ID:<br><span class="Apple-tab-span" style="white-space: pre; ">        </span>&lt;<a href="mailto:BFBC0F17A99938458360C863B716FE46398DCE8FDD@simmbox01.rapnt.com">BFBC0F17A99938458360C863B716FE46398DCE8FDD@simmbox01.rapnt.com</a>&gt;<br>Content-Type: text/plain; charset="us-ascii"<br><br><br>my first reaction was ugh - xml-dsig has its own inband mechanism for referencing keying material - and here is openid/xrd doing yet another standard for verifying signatures and validating the supporting keying material (probably poorly).<br><br>My second reaction on reflection was that xml-dsig is rarely used to its full potential. Its typically used as a PKCS7 signing and sealing emulation modes, with an XML centric view of the world - with no particular benefit. But, if xml dsig fully uses its external references, and the references are to a world of XRD files which are TRUSTED to act as a key distribution mechanism, things get rather more interesting. In that world, the XRD is becoming a certificate, as we know it - and one whose format and semantics would enable it to go beyond the staid ol X.509 cert chains and benefit the full expression power of xri queries and XRI resolution.<br><br>What the X.509 v3 format work took part (divorcing asymmetric key management from dap/ldap resolution), XRI/XRD may be putting back together: query-based named-key resolution supporting trust fabric meshes.<br><br></span></blockquote></div><br></div></body></html>