When you said 'removing 3rd party XRDS signers' this could be interpreted as saying that the final XRD for party A should be signed by party A (i.e., that delegation was impossible). The XRI TC is considering delegation where the initial signer must be trusted by the client as authoritative for party A, but the final XRD can be signed by any key to which A has delegated via a signature.<div>
<br></div><div>I don't think XRI TC will define what it means to be 'authoritative for party A' prior to any delegation (i.e., force a concept of a trusted root for each resource), because this logic could be application specific.<br>
<br><div class="gmail_quote">On Thu, Jul 16, 2009 at 6:14 AM, Manger, James H <span dir="ltr"><<a href="mailto:James.H.Manger@team.telstra.com">James.H.Manger@team.telstra.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<p><span style="font-size:11.0pt;color:#1F497D">It does not sound like the mismatch is a temporary kludge just for a demo. Breno included “removing 3<sup>rd</sup>-party XRDS signers” as one of the changes
that “would break adoption”.</span></p>
<p></p></blockquote></div><br><br clear="all"><br>-- <br>--Breno<br><br>+1 (650) 214-1007 desk<br>+1 (408) 212-0135 (Grand Central)<br>MTV-41-3 : 383-A <br>PST (GMT-8) / PDT(GMT-7)<br>
</div>