________________________________________
From: general-bounces@openid.net [general-bounces@openid.net] On Behalf Of Manger, James H [James.H.Manger@team.telstra.com]
Sent: Wednesday, July 15, 2009 12:20 AM
To: general@openid.net
Subject: Re: [OpenID] Google discovery prototype: host-meta from Google

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.

 

There is no "masquerading" in the architecture - that the wrong security term, I feel.

There is the case of the domain (tenant-OP) outsourcing to  a trusted "provider" of the XRDS/XRD-based discovery  service.

This is only like classical openid , where users MAY procure an XRI-form openid by "outsource" its discovery to a particular i-broker - rather than run their own openxri server. Now, domains/organizations get to do the same. For organizations, its more involved - exposing several layers of indirection.

Really, this is all no different in concept to todays world for organizationl "websites", which can opt to "host" their https website at a hosting site with an https wild-card cert (or a VeriSign https cert whose extension explicitly lists which domain names the hosting-ISP can speak for).

Rather than "hosting" a website's https endpoint on a wild-card https cert, Google are simply acting as an XRI "provider". But, they are apparently taking the option to run a community authority, rather than serve as an i-broker for organizations

Furthermore, when I take a good long look at the host-meta, its nothing more that a XRI "community" root hint. Also, the locator/redirector function of the initial lookup is just an XRI server offering to resolve two synonyms of a common entry- each name (the goolle path, or the domain path) allowing reoslution to a canonical entry whose (default) forwarding-SEP eventually redirects the RP to the discovery-endpoint hint file (host-meta) that locates the domain's choice of community authority. [2 levels of indirection, so far].

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.

Rather than finding the above 3 things which cripples the infrastructure vision, I find those 3 are THAT WHICH MAKE IT ACCEPTABLE in an UCI environment. These are the elements which allow the domain to break free of Google governance/provider - if they choose their own governance/provider/trust framework. Given the choice, they may choose a third party provider other than Google, or they can be their own provider.

This WILL be VERY threatening to the traditional hierarchical/military PKI crowd and its outsourcers, as it re-engineers PKI - reaching a new level. Its only threat is actually its disruptiveness to the established order - but in a conservative crowd that will be a significant issue.

To a forward-looking "opportunistic" PKI business, its really just more of the same "trust networking" business. The space is  better than that crafted in 1995, as now there is a much bigger market space to work in., The cloud concept adds n layers of indirection -- into which MORE [outsourced] trust management is required not less.

Given the whole indirection architecture based on XRD SEPs, Dirk was correct when he said that yet another level of indirection can be put on the front, to help an RP choose between cloud providers (Google endpoints vs Microsoft endpoints) for a given domain. The domain just has a third party provider of XRDs mint another set, whose SEPs point via SEP-level redirects/referrals to the Google-hosted XRDS (or the Microsoft-hosted XRDS). The initial locator use of synonyms showed clearly how the architecture allows - per domain - this additional indirection. Choose Google synonym, you are preselecting the Google cloud as a RP. Choose the domain path for its host-meta, you eigher default back to the Google cloud, or the domain sets up the additional pointer that allows for cloud selection.

I get it, and I get the big picture.

 I think the government/military politics is going to be horrendous. They will do anything and everything to kill this, or modify it so ONLY TRUSTED TTPs will be allowed to act as providers.

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.

I think that's a true statement. It allows and facilitates TOTAL outsourcing. But it also enables total UCI, when folks take more and more responsibility upon themselves.

 given that space of adoption, governments can also have a say, deciding how much of that space to authorize folks to operate in. China will demand total outsourcing, for example. AUS will force large corporates to only use TTP-based discovery. UK will bias towards TTPs, making UCI a disloyal act. US will first rig public services to force adoption TTPs, then give up and allow UCI -- if that's where the market takes adoption.

I ike this set of compromises, as there is a political space.

 Now, the temptation for a huge brand will be to MARKET the architecture, but rig the deliver so only the TOTAL outsourcing is viable in realty - or only certain alternate providers.

And that's our job: to show if and when they do that. As I was able to replicate in practice most of what they have done myself, in the last 2 days, if we can keep these mega-brands honest, I think we will be remembering "Google" for secure web discovery like we remember "VeriSign" for CA-based trust networks. if VeriSign can get its act together, this is a major opportunity!

James Manger
James.H.Manger@team.telstra.com
Identity and security team — Chief Technology Office — Telstra

_______________________________________________
general mailing list
general@openid.net
http://openid.net/mailman/listinfo/general