[OpenID] Google discovery prototype: host-meta from Google
Breno de Medeiros
breno at google.com
Wed Jul 15 16:05:04 UTC 2009
--0015174c33f0e32936046ec0b727
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
Hi James,
Note that the XRI TC is discussing a delegation mechanism using XRD
signatures where a party could delegate to another party the ability to sig=
n
XRD to resources under its namespace.
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 subse=
t
of) its resources to another key.
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 o=
f
concept. It is useful in that demonstrates some of the functional aspects o=
f
the proposed architecture, but not all.
On Wed, Jul 15, 2009 at 12:20 AM, Manger, James H <
James.H.Manger at team.telstra.com> wrote:
> More on the proof-of-concept of an OpenID Provider for Google hosted
> domains (
> https://sites.google.com/site/oauthgoog/fedlogininterp/openiddiscovery)..=
.
>
>
> 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 doma=
in
> users' XRDS files -- Google also signs the XRDS files, with a certificate
> issued to hosted-id.google.com.
>
> 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.
>
> Trusting Google to sign XRDS files for arbitrary domains effectively make=
s
> Google a root CA -- but without the same processes and visibility of othe=
r
> root CAs. Using Google URIs for host-meta and XRDS files makes Google mor=
e
> 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.
>
> These aspects mean this proof-of-concept protocol does not seem viable
> beyond a demo as a generic solution for hosted OPs.
>
> I would like to understand which aspects can be changed to make it viable=
,
> without crippling adoption.
> Changes that could be sufficient include:
> 1. Removing 3rd-party URIs for a domain's host-meta file; or
> 2. Removing the <openid:URITemplate> element; or
> 3. Removing 3rd-party XRDS signers.
>
>
> 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.
>
>
>
> James Manger
> James.H.Manger at team.telstra.com
> Identity and security team =97 Chief Technology Office =97 Telstra
>
> _______________________________________________
> general mailing list
> general at openid.net
> http://openid.net/mailman/listinfo/general
>
--=20
--Breno
+1 (650) 214-1007 desk
+1 (408) 212-0135 (Grand Central)
MTV-41-3 : 383-A
PST (GMT-8) / PDT(GMT-7)
--0015174c33f0e32936046ec0b727
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
Hi James,<div><br></div><div>Note that the XRI TC is discussing a delegatio=
n mechanism using XRD signatures where a party could delegate to another pa=
rty 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' X=
RD (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 functiona=
l aspects of the proposed architecture, but not all.<br>
<div><br><div class=3D"gmail_quote">On Wed, Jul 15, 2009 at 12:20 AM, Mange=
r, James H <span dir=3D"ltr"><<a href=3D"mailto:James.H.Manger at team.tels=
tra.com">James.H.Manger at team.telstra.com</a>></span> wrote:<br><blockquo=
te class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc so=
lid;padding-left:1ex;">
More on the proof-of-concept of an OpenID Provider for Google hosted domain=
s (<a href=3D"https://sites.google.com/site/oauthgoog/fedlogininterp/openid=
discovery)." target=3D"_blank">https://sites.google.com/site/oauthgoog/fedl=
ogininterp/openiddiscovery).</a>..<br>
<br>
<br>
As well as Google URIs supplying another domain's host-meta file, the d=
omain's XRDS file, the domain's <openid:URITemplate> value, a=
nd the domain users' XRDS files -- Google also signs the XRDS files, wi=
th a certificate issued to <a href=3D"http://hosted-id.google.com" target=
=3D"_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 nev=
er 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 beyo=
nd 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 class=3D"im"><br>
<br>
<br>
James Manger<br>
<a href=3D"mailto:James.H.Manger at team.telstra.com">James.H.Manger at team.tels=
tra.com</a><br>
Identity and security team =97 Chief Technology Office =97 Telstra<br>
<br>
</div><div><div></div><div class=3D"h5">___________________________________=
____________<br>
general mailing list<br>
<a href=3D"mailto:general at openid.net">general at openid.net</a><br>
<a href=3D"http://openid.net/mailman/listinfo/general" target=3D"_blank">ht=
tp://openid.net/mailman/listinfo/general</a><br>
</div></div></blockquote></div><br><br clear=3D"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></div>
--0015174c33f0e32936046ec0b727--
More information about the general
mailing list