[OpenID] google cloud openid, XRD tenants; attributes, origination and mapping

Wed Aug 10 21:35:53 UTC 2011

One thing Ive noticed is that the Microsoft gatewayto openid providers  (ACS v2) is leaking SP downstream information to the upstream IDP. I dont want Google (the upstream IDP) knowing anything about theURis used by application/party requesting Microsoft gateway to bridge (to Google). Google will (being their nature) store it, crawl it, hand it over to US authorities without warrant, etc. To be fair, they are not alone. As it stands, such information is being leaked (badly) - in the context field of the openid request. In the SAML2 world, this topic and the associated security issue was properly addressed - for the world of chained IDPs (idp proxies) and SP/IDP interactions. The relayState information held by the SP (in order to resume the conversation with the requesting application on the assertion return path) was/is masked from the IDP: only a nonce is released to the IDP, in the equivalent of the openid context field. On the return path, this value is mapped to state stored in the - IDP proxy or SP  ...ready for to drive onward communication with the downstream party (usually the final webapp).
 From: home_pw at msn.com
To: openid-general at lists.openid.net
Subject: google cloud openid, XRD tenants; attributes, origination and mapping
Date: Mon, 8 Aug 2011 11:09:59 -0700

If someone with knowhow can help, I want to play with the next level of google integration. I want to play with the reality of host-metas, in an multi-vendor theatre. I want to determine if the meta world is still at the research stage, or its more mature. SHould I go away and wait for a couple of more years, is my dilemma?

The context is this:

The Microsoft-run gateway to Google's version of the openid protocol talks to the traditional google endpoint; it works fine. I want to now configure references to the unique tenants of the google cloud. I hope to then configure the microsoft gateway's claim mapping, so it uses the TENANT identity to drives its attribute sourcing/origination/mapping rules.

If I recall back 1-2 years, Google had some kind of XRD file hosted on each tenant's domain, whose values would orchestrate the main Google endpoint actingFor the tenant. As a result, the tenant was an IDP in its own right distinct from Google (the brand), where the endpoint services of Google would actually deliver the services on the wire - albeit customized now with per IDP keying and naming.

I may have my openid terms for cloud-tenant-virtualization world wrong. The "generic," multi-tenant google service may be known as the IDP, and the (virtualized) tenants as OPs - in much the same way as the generic cloud endpoint is sometimes known as the SP, whereas the tenants with (virutalized) per-tenant assertion consuming endpoints are known as RPs. This all corrupts traditional terms, but does at least characterize the cloud-ness - ready for mass virtualization.

Im hoping that the Microsoft gateway can now do the orchestration dance, using the XRD files of the IDP/OP, fixing up the "virtual endpoint" to "real endpoint" mappings on the fly, acting as the party processing inbound assertions. At the same time, such a gateway will need to be _validating_ the tenant/cloud metadata that drives this (security critical) process, somehow; and presumably be doing it PER OP (virtual tenant of the Google IDP). 

I'm interested to see how this is done for real, and how its all been packaged. Is it really on PKI and required validation of signed XRD streams? Or, will it be derived from the https trust model, requiring that the tenant's XRD(s) (with the security critial mapping info) be delivered over a particular https channel, perhaps? What is the formal name for such a bridging proxy (e.g. the Microsoft ACS service), and what is the name for its "per-OP" (virtual Google endpoint) configuration that controls the attribute origination/mapping process

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20110810/8b0ddc2b/attachment.html>