from email/domain delegation to name-based accreditation

[Peter Williams]

If one looks at Google's cloud-class IDP service (a mixing of openid protocols with XRD-formatted metas files, with public keys within), one notes how any 1 of the million tenants (any google apps customer) can already be its own IDP in the logical sense - where Google's own endpoints do the real work, per-tenant, of satisfying the IDP protocols (to each tenant's constraints, obviously). Alternatively, the files with all the discoverable logical name controls can be hosted on one's own domain and on-premise ( and still have a Google endpoints do the work of the IDP protocols, morphing to emulate the tenant as required). Assuming each one of those Google Apps tenants is running a cloud-instance of a mail server, its a "primary IDP for email names" as much as anyone else running an SMTP server. Once upon a time, there was just 10 huge email providers (aol.com and co) and 10 root certs (ok that become 300... as the browser vendors let almost anyone into the pay-to-play CA club). Now anyone can be running an cloud-based SMTP server (trivially) - where the number seems potentially "large" is browserid assuming a world with 10, a 100, thousand, a million or 10 million or a 100 million IDPs (issuing distinct names and associated certs, and well known discovery resources)? Call the answer: N. As an RP write I have to care. Each one has a cert (which the spec implies is RSA signed). Each cert (regardless of its bit format) has a lifecycle and rollover issues - that are unrelated to the SSL server cert(s) supporting its endpoint. AS a good RP, Id probably want to ensure no one is the same as any other, for distinct domains. Any one of the N can put me on notice of a crypto/site/key compromise that might affect thousands of federated accounts. And then, we can someone enterprising will start running a reputation service for the N discovery URIs, playing the role of a revocation/validation service and inviting RP sites to opt-in to check them out aagainst some reputation model's criteria (allowing one to outsource the IDP-accreditation function of the better relying party site). If you think about it, as an RP (thinking quality) you really dont want to prompt a user to mint a token (whose signature and cert will only LATER be checked by the RP) if you already have full knowledge that you, as that RP, no longer accredit some subset of IDPs' certs/URIs. One really wants the UI NOT to arm-for-selection (for this RP) those names in its card/name-store that the RP indicates are incompatible ...with the RPs list of accredited IDPs. Or... at least deliver some warning (name is not accredited, at the site inducing the UI to display) This is what SSL client cert dialogues do in general - having a received a positive list of naming authorities via the SSL handshake, whose associated certs can impose hierarchical naming controls on subscriber/subject naming domains. I.e. dont now list those user certs in the users store that are "out of accreditation scope" on the picker dialog... just list those WOULD be acceptable.