Intent to prototype: various features of WebAuthn level two and CTAP2.1

140 views
Skip to first unread message

Adam Langley

unread,
Jul 8, 2020, 4:50:18 PM7/8/20
to blink-dev

WebAuthn level two is now feature-frozen, as is CTAP 2.1, the accompanying protocol for communication with security keys. Specifications without implementations can harbour nasty omissions and mistakes, thus this is an intent to prototype notice for several features in these new documents.


For the vast majority of sites, WebAuthn is already fully capable and developers should not think that they need to wait for level two support!



Features adding to the Web Platform directly:


(These alter IDL and thus will be the subject of later intent-to-ship emails.)


  • getPublicKey and other helpers to make server-side implementation easier. Already the subject of an intent to ship and mentioned here for completeness. (chromestatus)

  • PRF extension support. Allows sites to encrypt data using a symmetric key that is kept on a security key, with provision for key rotation.

  • Credblob extension support (FIDO hasn’t published a recent enough review draft to include this yet). Allows for 32 bytes of additional information to be stored with credentials. Given the size limit, probably only useful for cases where security keys are used in both a web and native context.

  • Minimum PIN length support (FIDO hasn’t published a recent enough review draft to include this yet). Browser UI for setting and changing PINs will be aware of custom-configured minimum PIN lengths and it will be possible to report this length when creating credentials on sites that have been administratively configured on the security key. This is a compliance need in certain enterprise environments.

  • Large-blob extension support. Allows for larger blobs of data to be stored with a credential. (I.e. a kilobyte or more.) Sufficient to store certificates and thus to enable some smartcard-like use cases and SSH clients using certificates for authentication. Given the limited storage of security keys, we expect to only enable for extensions at first and to consider origin trials if specific sites wish to experiment.


Features extending security key support:


(These do not alter the Web Platform API and are part of our continuous process to improve the functionality of existing WebAuthn APIs. Thus they would not normally be part of the Blink intent process but are mentioned here because web developers may be interested.)


  • Support for getting pinUvAuthTokens using built-in user-verification. This permits security keys that can verify a user themselves, e.g. using a fingerprint reader, to function much more smoothly. (This is already substantially complete on Canary.)

  • Extending support for enterprise attestation to CTAP 2.1 authenticators. Previously, enterprise attestation was only supported for older, U2F-based authenticators.


This is not an exhaustive list of everything new in these specifications and some changes that do not impact web developers are not mentioned. Otherwise, support for other new, impactful items might come later but are currently scheduled after everything listed above.



Cheers


AGL


Reply all
Reply to author
Forward
0 new messages