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

[Breno de Medeiros]

Let me make the point more explicit:
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.

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.

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

On Wed, Jul 15, 2009 at 9:05 AM, Breno de Medeiros <breno at google.com> wrote:

> 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 sign
> 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 subset
> 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 of
> concept. It is useful in that demonstrates some of the functional aspects of
> 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 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
>>
>> _______________________________________________
>> general mailing list
>> general at openid.net
>> http://openid.net/mailman/listinfo/general
>>
>
>
>
> --
> --Breno
>
> +1 (650) 214-1007 desk
> +1 (408) 212-0135 (Grand Central)
> MTV-41-3 : 383-A
> PST (GMT-8) / PDT(GMT-7)
>



-- 
--Breno

+1 (650) 214-1007 desk
+1 (408) 212-0135 (Grand Central)
MTV-41-3 : 383-A
PST (GMT-8) / PDT(GMT-7)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20090715/7f0a1838/attachment.htm>