Re: [w3ctag/design-reviews] Web Authentication Level 2 (#577)

Hi @torgo,

with regards to use cases, I think the issue is that Level 2 features are all minor tweaks/additions to certain aspects of the spec and need to be looked at individually. I tried pointing out in each individual section under "WebAuthn Level 2 Additional Features" what motivates the addition of that particular feature, in particular:

- ResidentKeyRequirement + credProps: Improve API ergonomics to account for users that may not yet have security keys that support password-less sign-in
- largeBlob: support SSH authentication on the web
- credBlob: support association of WebAuthn credentials with short secret blobs for the purpose of authenticating machines in a non-web context
- Enterprise Attestation: support security keys that can attest a unique serial number when registering a WebAuthn credential enterprise-managed context
- Apple Anonymous Attestation: compatibility with Apple devices
- AuthenticatorAttestationResponse Accessors: API ergonomics

Is there any use case in particular that you would like us to expand on in more depth?

Re fingerprinting implications of Apple-specific attestation, note that the thing being added is just another attestation statement _format_. The general mechanism for requesting authenticator attestation has been there since L1, and its purpose is to provide provenance information about the authenticator that created a WebAuthn credential, which usually includes the authenticator vendor. As far as I'm aware, all browser gate attestation behind a separate permission prompt, regardless of whether the user is in an Incognito browsing context or not.  

Lastly, with regards to why vendor-specific attestation statement formats are necessary, the answer is that different authenticator vendors have different requirements on what is being attested. Physical FIDO2 security keys all generally attest a batched serial number using a vendor-specific certificate (https://w3c.github.io/webauthn/#basic-attestation) under the same format that FIDO prescribes. The platform authenticators provided by operating systems on the other hand each work differently. For example, Windows is sending an attestation generated by a TPM, while Apple's is generated by an online Anonymization CA and Android uses SafetyNet. Even if something like a unified "operating system attestation" format were technically feasible, all these platform authenticator implementations have shipped in their respective OSes, which means we will need to live with them for the foreseeable future, I think.


-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/577#issuecomment-809737874