FYI, see&nbsp;<div><br></div><div><a href="http://wiki.oasis-open.org/xri/XrdOne/SimpleSign">http://wiki.oasis-open.org/xri/XrdOne/SimpleSign</a></div><div><br></div><div>=nat<br><br><div class="gmail_quote">On Mon, Dec 1, 2008 at 10:41 PM, Ben Laurie <span dir="ltr">&lt;<a href="mailto:benl@google.com">benl@google.com</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><br><br><div class="gmail_quote">On Mon, Dec 1, 2008 at 1:23 PM, Peter Williams <span dir="ltr">&lt;<a href="mailto:pwilliams@rapattoni.com" target="_blank">pwilliams@rapattoni.com</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Xrd or xrds?</blockquote><div><br></div><div>XRD.</div><div class="Ih2E3d"><div>&nbsp;</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Interesting! if you go xrd. Then you can do dnssec-like namespace controls, much like the trusted resolution mode of xri.</blockquote>

<div><br></div></div><div>Not yet all that familar with fully blown XRD, so I&#39;ll have to take your word for this - but I am familiar with DNSSEC, so I&#39;m wondering what you mean by a &quot;namespace control&quot;?</div>
<div><div></div><div class="Wj3C7c"><div>
&nbsp;</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> Rather than be dnssec static, however, signatures on xrd could also serve as security tokens, citable on the peer (web) services (&quot;managed&quot; by the xri/uri). Butler lampson will be in heaven.<br>


<br>
________________________________<br>
From: Ben Laurie &lt;<a href="mailto:benl@google.com" target="_blank">benl@google.com</a>&gt;<br>
Sent: Monday, December 01, 2008 5:13 AM<br>
To: Peter Williams &lt;<a href="mailto:pwilliams@rapattoni.com" target="_blank">pwilliams@rapattoni.com</a>&gt;<br>
Cc: Eric Norman &lt;<a href="mailto:ejnorman@doit.wisc.edu" target="_blank">ejnorman@doit.wisc.edu</a>&gt;; OpenID List &lt;<a href="mailto:general@openid.net" target="_blank">general@openid.net</a>&gt;<br>
<div>Subject: Re: [OpenID] 2-Headed OpenID Auth for Increased Security?<br>
<br>
<br>
<br>
</div><div>On Sun, Nov 30, 2008 at 5:56 PM, Peter Williams &lt;<a href="mailto:pwilliams@rapattoni.com" target="_blank">pwilliams@rapattoni.com</a>&lt;mailto:<a href="mailto:pwilliams@rapattoni.com" target="_blank">pwilliams@rapattoni.com</a>&gt;&gt; wrote:<br>


Time to take the extension power of XRDS, and apply xmldsig &quot;detached signature(s)&quot;<br>
<br>
Signing XRD is pretty much what we&#39;re proposing for the next generation...<br>
<br>
<br>
<br>
This would be using similar mechanism as used in Authenticode, where designers applied 3rd-party countersigning and 4th-party timestamping to solve validity problems - at internet scale. Different parties (OP, discovery agents, validation) can then cooperate, in the inherently suspicious world of open systems.<br>


<br>
The Shib/Apache-xmltooling toolset has all the mechanisms required to make power-use of the flexibility of the xmldsig standard (as do many other tools). Being very, very flexible in its references, it&#39;s easy to screw up application of xmldsig, producing unwanted sideeffects tho.<br>


<br>
-----Original Message-----<br>
</div><div>From: <a href="mailto:general-bounces@openid.net" target="_blank">general-bounces@openid.net</a>&lt;mailto:<a href="mailto:general-bounces@openid.net" target="_blank">general-bounces@openid.net</a>&gt; [mailto:<a href="mailto:general-bounces@openid.net" target="_blank">general-bounces@openid.net</a>&lt;mailto:<a href="mailto:general-bounces@openid.net" target="_blank">general-bounces@openid.net</a>&gt;] On Behalf Of Eric Norman<br>


Sent: Sunday, November 30, 2008 9:50 AM<br>
To: OpenID List<br>
Subject: Re: [OpenID] 2-Headed OpenID Auth for Increased Security?<br>
<br>
<br>
On Nov 30, 2008, at 9:35 AM, Andrew Arnott wrote:<br>
<br>
&gt; I like the idea.... but the XRDS would have to mandatorily not be<br>
&gt; hosted by either OP (which right now is commonly done), since that OP<br>
&gt; would still ultimately have total assertion power by temporarily<br>
&gt; manipulating the XRDS file to point to two OP endpoints that were both<br>
&gt; controlled by the evil party.<br>
<br>
Be careful. &nbsp;&quot;Hosted by&quot; does not necessarily imply &quot;content<br>
controlled by&quot;.<br>
<br>
Eric Norman<br>
<br>
_______________________________________________<br>
general mailing list<br>
</div><a href="mailto:general@openid.net" target="_blank">general@openid.net</a>&lt;mailto:<a href="mailto:general@openid.net" target="_blank">general@openid.net</a>&gt;<br>
<div><a href="http://openid.net/mailman/listinfo/general" target="_blank">http://openid.net/mailman/listinfo/general</a><br>
_______________________________________________<br>
general mailing list<br>
</div><a href="mailto:general@openid.net" target="_blank">general@openid.net</a>&lt;mailto:<a href="mailto:general@openid.net" target="_blank">general@openid.net</a>&gt;<br>
<div><div></div><div><a href="http://openid.net/mailman/listinfo/general" target="_blank">http://openid.net/mailman/listinfo/general</a><br>
<br>
</div></div></blockquote></div></div></div><br>
<br>_______________________________________________<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>
<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>
</div>