This post has been republished via RSS; it originally appeared at: Identity Standards Blog articles.
Hi everyone and welcome to chapter 14 of 2020! It’s been a little while since we talked about standards for passwordless so we’re excited to tell you about some new enhancements and features in FIDO2 land that you'll start seeing in the wild in the next few months!
The version 2.1 of the Client to Authenticator Protocol (CTAP) specification is a Release Draft at the FIDO Alliance. This means the spec is in a public review period before final publication.
These new draft versions are on their way to becoming the next wave of FIDO functionality (as of the writing of this blog, we support Level 1 of WebAuthn and CTAP version 2.0). We think you might want to hear about what we think is especially fun about WebAuthn L2 and CTAP 2.1.
Enterprise Attestation (EA)
Enterprise Attestation is a new feature coming as part of WebAuthn L2 and CTAP 2.1 that enables binding of an authenticator to an account using a persistent identifier, similar to a smart card today.
FIDO privacy standards require that "a FIDO device does not have a global identifier within a particular website" and "a FIDO device must not have a global identifier visible across websites". EA is designed to be used exclusively in enterprise-like environments where a trust relationship exists between devices and/or browsers and the relying party via management and/or policy. If EA is requested by a Relying Partying (RP) and the OS/browser is operating outside an enterprise context (personal browser profile, unmanaged device, etc), the browser is expected to prompt the user for consent and provide a clear warning about the potential for tracking via the persistent identifier being shared.
Authenticators can be configured to support Vendor-facilitated and/or Platform-managed Enterprise Attestation. Vendor-facilitated EA involves an authenticator vendor hardcoding a list of Relying Party IDs (RP IDs) into the authenticator firmware as part of manufacturing. This list is immutable (aka non-updateable). An enterprise attestation is only provided to RPs in that list. Platform-managed EA involves an RP ID list delivered via enterprise policy (ex: managed browser policy, mobile application management (MAM), mobile device management (MDM) and is enforced by the platform.
Authenticator Credential Management and Bio Enrollment
Credential Management is part of CTAP 2.1 and allows management of discoverable credentials (aka resident keys) on an authenticator. Management can occur via a browser, an OS settings panel, an app or a CLI tool.
Here's an example of how the Credential Management capability is baked into Chrome 88 on macOS (chrome://settings/securityKeys). Here I can manage my PIN, view discoverable credentials, add and remove fingerprints (assuming the authenticator has a fingerprint reader!) and factory reset my authenticator.
Clicking on "Sign-in data" shows the discoverable credentials on the authenticator and allows me to remove them. This security key has an Azure AD account and an identity for use with SSH.
Bio Enrollment allows the browser, client, or OS to aid in configuring biometrics on authenticators that support them. This security key has one finger enrolled. I can either remove the existing finger or add more.
Here's an example of authenticator credential management via a CLI tool, ykman from Yubico.
Set Minimum PIN Length and Force Change PIN
CTAP 2.1 allows an RP to require a minimum PIN length on the authenticator. If the existing PIN does not meet the RP’s requirements, a change PIN flow can be initiated.
An authenticator can also be configured with a one-time use PIN that must be changed on first use. This is an additional layer of protection when an authenticator is pre-provisioned by an administrator and then needs to be sent to an end user. The temporary PIN can be communicated to the end user out of band. We see this being used in conjunction with Enterprise Attestation to create a strong relationship between an authenticator and a user.
Always Require User Verification (AlwaysUV)
AlwaysUV is part of CTAP 2.1 and allows the user to configure their authenticator to always prompt for user verification (PIN, biometric, etc), even when the Relying Party does not ask for it. This adds an extra layer of protection by ensuring all credentials on the authenticator require the same verification method.
Virtual Authenticator DevTool
This one is not tied to updates of either specification but we love it and wanted to share! Chrome and Edge (version 87+) now include a virtual authenticator as part of DevTools. It started as a Chromium extension back in 2019 and is now native! Oh, and the code is on Github!
Enabling the virtual authenticator environment will allow you to create a new authenticator by picking a protocol (CTAP2 or U2F), transport (USB, Bluetooth, NFC or internal), resident key (discoverable) and user verification support.
As new credentials are created, you’ll see them listed and the sign count will increase as the credential is used.
Want to know more? Here’s an amazing blog by Nina Satragno from the Chrome team over at Google who created this amazing DevTool!
That rounds out the major features we believe will have the most impact. Here’s a few other enhancements and features that are important to mention!
- cross-origin iFrame usage
- Apple’s anonymous platform attestation format
- Large blob storage extension to support storing a small chunk of encrypted data with a credential to support use cases like SSH certificates
If you’d like to hear more about any of these enhancements/features (or anything else identity related, let's be honest), leave us a note in the comments.
Thanks for reading!
Tim Cappalli | Microsoft Identity | @timcappalli