Let me make the point more explicit:<div><br></div><div>1. The design being discussed in the XRI TC allows sites to host their signed XRD documents anywhere in the Internet. It uncouples the trust elements of discovery from the path followed to perform discovery. This adds a lot of flexibility. It can be used for both RPs and OPs. For instance, if the OpenID scheme were to allow it, RPs could use unmatched realm and return_to URLs *securely*, allowing any site to become an OpenID RP using a hosted RP solution elsewhere.</div>
<div><br></div><div>2. The design being discussed at the XRI TC would allow sites to delegate trust to any other site of their choice, by signing delegation statements. This is necessary to really accomplish the vision in (1), because you can have a stub XRD that just effectively says 'party X is handling discovery on behalf of this set of resources in my namespace' and the other party can provide the XRD management which is an essential part of performing OpenID management.</div>
<div><br></div><div>Nothing in the above is Google-specific. The benefit would accrue largely to small players, including some that don't have technical expertise or resources to manage their own identity system, whether OpenID-based or otherwise. What we have deployed now does not fully realize this vision yet because it is not fully articulated (as you can imagine, it requires solving complex problems, and since everybody would prefer simple solutions to such complex problems, it requires some thought).</div>
<div><br><div class="gmail_quote">On Wed, Jul 15, 2009 at 9:05 AM, Breno de Medeiros <span dir="ltr"><<a href="mailto:breno@google.com">breno@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Hi James,<div><br></div><div>Note that the XRI TC is discussing a delegation mechanism using XRD signatures where a party could delegate to another party the ability to sign XRD to resources under its namespace.</div><div>
<br></div><div>In this scenario a hosted site could have a 'stub' XRD (signed with its own key) that simply delegates the ability to sign XRD for (potentially a subset of) its resources to another key.</div><div>
<br>
</div><div>The trust aspects of the proposed XRD-based discovery are still being defined, so there is no 'template' to implement it right now, and the current approach is about all that could be deployed right now as a proof of concept. It is useful in that demonstrates some of the functional aspects of the proposed architecture, but not all.<br>
<div><div><div></div><div class="h5"><br><div class="gmail_quote">On Wed, Jul 15, 2009 at 12:20 AM, Manger, James H <span dir="ltr"><<a href="mailto:James.H.Manger@team.telstra.com" target="_blank">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">
More on the proof-of-concept of an OpenID Provider for Google hosted domains (<a href="https://sites.google.com/site/oauthgoog/fedlogininterp/openiddiscovery)." target="_blank">https://sites.google.com/site/oauthgoog/fedlogininterp/openiddiscovery).</a>..<br>
<br>
<br>
As well as Google URIs supplying another domain's host-meta file, the domain's XRDS file, the domain's <openid:URITemplate> value, and the domain users' XRDS files -- Google also signs the XRDS files, with a certificate issued to <a href="http://hosted-id.google.com" target="_blank">hosted-id.google.com</a>.<br>
<br>
All together this means Google can masquerade as any OpenID in the world to an RP adopting this protocol. Google can masquerade not only as an OpenID for a domain for which it provides apps, but even for domains that have never had any relationship with Google. It could masquerade as an https OpenID without needing a certificate for that domain.<br>
<br>
Trusting Google to sign XRDS files for arbitrary domains effectively makes Google a root CA -- but without the same processes and visibility of other root CAs. Using Google URIs for host-meta and XRDS files makes Google more powerful than a root CA -- as they don't need to intercept a domain's network traffic or DNS records to exploit being a root CA.<br>
<br>
These aspects mean this proof-of-concept protocol does not seem viable beyond a demo as a generic solution for hosted OPs.<br>
<br>
I would like to understand which aspects can be changed to make it viable, without crippling adoption.<br>
Changes that could be sufficient include:<br>
1. Removing 3rd-party URIs for a domain's host-meta file; or<br>
2. Removing the <openid:URITemplate> element; or<br>
3. Removing 3rd-party XRDS signers.<br>
<br>
<br>
The protocol documentation says "hosting one simple file on their site should be enough..., while outsourcing the rest of the work". That is a decent objective. However the protocol can operate with ZERO files on a customer's site, which seems to break a core foundation of OpenID.<br>
<div><br>
<br>
<br>
James Manger<br>
<a href="mailto:James.H.Manger@team.telstra.com" target="_blank">James.H.Manger@team.telstra.com</a><br>
Identity and security team — Chief Technology Office — Telstra<br>
<br>
</div><div><div></div><div>_______________________________________________<br>
general mailing list<br>
<a href="mailto:general@openid.net" target="_blank">general@openid.net</a><br>
<a href="http://openid.net/mailman/listinfo/general" target="_blank">http://openid.net/mailman/listinfo/general</a><br>
</div></div></blockquote></div><br><br clear="all"><br></div></div>-- <br><div class="im">--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></div></div>
</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>