[OpenID] Google discovery prototype: host-meta from Google

[Manger, James H]

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 domain 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 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.

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 — Chief Technology Office — Telstra