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

[Peter Williams]

________________________________
From: general-bounces at openid.net [general-bounces at openid.net] On Behalf Of Manger, James H [James.H.Manger at team.telstra.com]
Sent: Monday, July 13, 2009 11:16 PM
To: general at openid.net
Subject: [OpenID] Google discovery prototype: host-meta from Google

It is good to see Google trying new ideas with OpenID, such as their proof-of-concept for an OpenID Provider for Google hosted domains (https://sites.google.com/site/oauthgoog/fedlogininterp/openiddiscovery).


That spec (which should be posted to specs) clearly lays out 6 sets of signals:

1. the forwarding service that faciliate location of the metalinks, from an (optional) google-hosted forwarder

2. XRDS streams with an xmldsig

3. an HTTP response-borne signature, when retrieving an XRDS stream

4. the role of the custom SEP in the domain's XRDS, which facilitates subseqent location of user-level XRDS streams (using similar forwarder/redirector processes)

5. concerning 2, PKI/cert-based signals that inevitably will impose relying party agreements on RPs when using certificates (and thus signed XRDS, by extension)

6. the google issuing authority minting a cert attesting to the authoritativeness of the domain-XRDS to speak for the OP-hosting relationship, and a hosted-domain's user XRDSs.

it doesnt articulate the role or function of 2.

The host-meta and the forwarding service to locate the given domain's host-meta are only hints, I suspect, in the security model.

All namespace and delegated namespace authoritiveness comes from the dig sigs and the cert path. This is  just like an SSL X.509 EE cert's multi-valued naming extension attests to the authority of a single, 1996-era site-hosting domain/cert to offer MULTIPLE https endpoints for virtual sites on third party domains for which the site-hoster is NOT the registered owner.

There doesnt seem any reason why a NON-Google managed XRDS at some NON-Google i-name cannot have in an SEP a XRDS- reference to the Google XRDS stream. Another SEP can point to the "domain's" XRDS stream at Microsoft's hosting point. This all assumes the RP can follow and select between XRDS references to different hosting parties service busses, of course - or the RP simply purchases a non-Google/non-Microsoft "XRI-proxy service" - which does all that logic for them to retain independence.


The protocol documentation offers a Google URI for starting discovery about a hosted domain. That is, start at https://www.google.com/accounts/o8/host-meta?hd=example.com to discovery the OpenID details for an example.com user (by getting a pointer to an XRDS doc that contains an OP URI to send an auth request to).

This doesn’t scale. If Google, Yahoo, Microsoft, Xxx, Yyy… all ran OPs for hosted domains then an RP would have to try many discovery requests (and each RP would try a different subset).
This is probably not secure. Google could lie that is was the OP for a domain that it did not host (though I assume this is unlikely).

Perhaps Google URIs for other domains host-meta files are only a temporary hack for a demo.
Alternatively, there might be a significant number of groups who would like to use a hosted OP, but for whom it is still quite awkward to add even a single host-meta file to their web server.

Q. Are the Google host-meta URIs a temporary hack for a demo, or a required feature for OpenID adoption?
Q. Will the reported changes to JanRain’s RPX service to support the Google proof-of-concept mean that the Google URIs for host-meta are used by production RPs (such as Sears)?


P.S. The protocol doc mentions http://example.com/.well-known/host-meta and http://example.com/host-meta (for IdP and user discovery respectively. I guess one of these is a typo.


James Manger
James.H.Manger at team.telstra.com<mailto:James.H.Manger at team.telstra.com>
Identity and security team — Chief Technology Office — Telstra