Re: [spec-reviews] Review FIDO spec (#97)

People were asking for a rationalization of the rule that an Authenticator should scope keys by eTLD+1:

I agree that from a “purity” point of view, it makes sense to scope keys by origin. In practice, we (Google) have found however, that that doesn’t quite work.

Here are all the origins at Google that need access to a user’s FIDO key, for example:
```javascript
[
  "https://accounts.google.com",
  "https://accounts.sandbox.google.com",
  "https://myaccount.google.com",
  "https://ac-autopush-myaccount.corp.google.com",
  "https://ac-daily-0-myaccount.corp.google.com",
  "https://ac-daily-1-myaccount.corp.google.com",
  "https://ac-daily-2-myaccount.corp.google.com",
  "https://ac-daily-3-myaccount.corp.google.com",
  "https://ac-daily-4-myaccount.corp.google.com",
  "https://ac-daily-5-myaccount.corp.google.com",
  "https://ac-daily-6-myaccount.corp.google.com",
  "https://security.google.com",
  "https://ac-autopush-security.corp.google.com",
  "https://ac-daily-0-security.corp.google.com",
  "https://ac-daily-1-security.corp.google.com",
  "https://ac-daily-2-security.corp.google.com",
  "https://ac-daily-3-security.corp.google.com",
  "https://ac-daily-4-security.corp.google.com",
  "https://ac-daily-5-security.corp.google.com",
  "https://ac-daily-6-security.corp.google.com"
]
```
There are two reasons that we need to access a user’s key from multiple origins. First, many of them are origins used by our services as they “soak” during a staged rollout process, and where we test functionality before it is released more widely. The second reason is related to site security architecture. We use security.google.com (Security) for users’ account management, including coaching users through the process of creating FIDO credentials. This site hosts a lot of material aimed at helping users, including tutorials and so on. User login is performed by accounts.google.com (Accounts). Accounts is at the top of our security hierarchy; it does not load pages from any other origin and it is intentionally architected to have the smallest possible attack surface. 
We want the FIDO authenticator (which may be a physically separate device from the client running the browser) to help protect user privacy, by making any one site’s credentials invisible to other sites. This is what we are currently using the rpId eTLD+1 mechanism for. In addition, the actual web origin of the caller is incorporated into the signature that the authenticator produces, so the site can make fine-grained decisions (similar to CORS credentialed requests) on whether to accept or reject it.

>From the site perspective, login is a very common and performance-sensitive operation, so we would like to do it as efficiently as possible. The suggested alternatives seem to be slower and complex to implement. For instance, the login page on Accounts could load Security in an iframe and make calls to it through postMessage, but this would be undesirable for performance and security reasons.

---
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/spec-reviews/issues/97#issuecomment-175766580