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

/cc @equalsjeffh to pull in the right Jeff Hodges, and also @leshi and @rlin1 who owned the signature and attestation docs respectively.

We'll definitely set up time with TAG once the WG gets under way, but let me answer a couple things here so you can have an idea of our direction.

Regarding no way to generate non-origin-specific credentials, this is by design. We were looking to do a simple thing well, rather than do a complicated thing badly. Even the desirability of a global cross-origin identity is controversial due to the privacy implications and we did not want to poke that hornet's nest. We did get a lot of feedback that we should not produce something that tilts the playing field towards mega-identity-providers, so we took some pains to ensure that the whole system would be usable even for small websites creating their own identities.

Regarding eTLD+1, this was a compromise. We got feedback that origin can be too strict for some RPs - for example login.foo.com may want to use the identities created by identity.foo.com. At some point FIDO created its own mechanism using facet lists in a text file at a particular well-known path under the origin that created the credential; this would say what other "facets" (i.e. origins or App IDs) should be considered equivalent to this origin for purposes of same-origin policy enforcement. This seemed really solid, but it also seemed like an extra complication that was not really part of our core mission as FIDO. So the eTLD+1 mechanism allows anyone with the same eTLD+1 as the credential creating origin to use the credential, but it also puts the actual origin of the caller in the signature so the replying party can choose whether it wants to accept this use of the credential or not. Ideally if we wanted to strengthen this mechanism, we would reuse something existing su
 ch as ma
 nifests and not invent yet another SOP - any guidance here would be welcome.

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