Difference between revisions of "WebAuthn 2"

From MgmtWiki
Jump to: navigation, search
(CTAP 2.1)
(CTAP 2.1)
 
Line 15: Line 15:
 
CTAP is a standard that allows a client application to communicate with a security key such as Google Titan or YubiKey over USB, near field communication (NFC), or [[Bluetooth]]. CTAP is a low level standard which is typically implemented at either the operating system or the browser level and engaged using a FIDO2 client.
 
CTAP is a standard that allows a client application to communicate with a security key such as Google Titan or YubiKey over USB, near field communication (NFC), or [[Bluetooth]]. CTAP is a low level standard which is typically implemented at either the operating system or the browser level and engaged using a FIDO2 client.
  
In addition, Enterprise Attestation features two approaches at the CTAP 2.1 layer - Vendor Facilitated EA and Platform Managed EA. Technically CTAP 2.1 is a security key extension that is designed to store a hash value (the BLOB) that can be used to authenticate externally provided data.
+
Enterprise Attestation features two approaches at the CTAP 2.1 layer - Vendor Facilitated EA and Platform Managed EA. Technically CTAP 2.1 is a security key extension that is designed to store a hash value (the BLOB) that can be used to authenticate externally provided data.
  
 
Vendor-Facilitated EA - Customers and authenticator vendors collaborate on configuring EA with the customer’s RP IDs. The authenticators are for the customer’s exclusive use, and the configured authenticators only return EA when requested by the RP IDs.
 
Vendor-Facilitated EA - Customers and authenticator vendors collaborate on configuring EA with the customer’s RP IDs. The authenticators are for the customer’s exclusive use, and the configured authenticators only return EA when requested by the RP IDs.

Latest revision as of 22:02, 18 November 2021

Full Title

WebAuthn 2 Specification is a series of fixes and enhancements to the original L1 spec. The focus for the Level 2 release is to expand functionality for specific use cases.

Context

  • WebAuthn 2 is near completion and should be issued as a W3C spec early in 2021. The W3C distinguishes their spec versions “Levels”, and as such the new specification released in early 2021 will be labeled Level 2 (L2).
  • WebAuthn 3 is the next version.

Enterprise Attestation

Enterprise Attestation (EA) is focused on device management within an enterprise, a familiar endeavor for any company. Enterprise Attestation is standardized in WebAuthn and FIDO CTAP2 and permits a relying party to request uniquely identifying information from authenticators during a registration event. This function was designed for controlled deployments within an enterprise where the organization wishes to tie registrations to specific authenticators, allowing management functions such as tracking key distribution and usage.

Usage tracking features supported with Enterprise Attestation do run counter to WebAuthn’s privacy principles on traceability. To address this concern, authenticators which support Enterprise Attestation are not available to consumers. Authenticator vendors must pre-load these attestations, with corporate management policies controlling if an site or service can request such an attestation. In short, only authenticators programmed with unique attestation by an organization can have their usage tracked on the same organization’s sites.

Note that WebAuthn Level 2 also will support an Apple Attestation format.

CTAP 2.1

CTAP is a standard that allows a client application to communicate with a security key such as Google Titan or YubiKey over USB, near field communication (NFC), or Bluetooth. CTAP is a low level standard which is typically implemented at either the operating system or the browser level and engaged using a FIDO2 client.

Enterprise Attestation features two approaches at the CTAP 2.1 layer - Vendor Facilitated EA and Platform Managed EA. Technically CTAP 2.1 is a security key extension that is designed to store a hash value (the BLOB) that can be used to authenticate externally provided data.

Vendor-Facilitated EA - Customers and authenticator vendors collaborate on configuring EA with the customer’s RP IDs. The authenticators are for the customer’s exclusive use, and the configured authenticators only return EA when requested by the RP IDs.

Platform-Managed EA - Platforms institute policy on whether an origin can request EA and if an EA-capable authenticator can return EA if requested. End-users can disable EA functionality with a hard reset, but enterprises can re-enable via management tools.

This is currently just targeted at Chrome, the discussion is here.

Cross-Origin iFrame Support

Cross-Origin iFrame Support is key for mixing Web Authentication with web payments and other flows. The feature allows only a get() command, does not permit credential creation, and can traverse origins. The feature, however, maintains the integrity of the specification’s single origin, providing capabilities for WebAuthn L1 and L2 that allow create() and get() with support for same-origin iFrames. This allows for generating signatures in situations where authentication speed is required but limited by bandwidth, such as when using Bluetooth Low Energy and Near-Field Communication.

New Extensions

Large Blob storage extension: This extension compresses data and allows the RP to store opaque data associated with a credential. This feature is useful in specific cases, such as a Relying Party that wishes to issue certificates rather than run a centralized authentication service. Large blobs stored on authenticators using CTAP will use that FIDO specification when storing large blobs.

Discoverable Credentials (residentKey) “preferred” and credProps Extension: When creating credentials, the RP can signal that creating a Discoverable Credential is “discouraged”, “preferred”, or “required”. Formerly known as Resident Credential or Resident Key, Discoverable Credentials help enable passwordless re-authentication flows. The credProps extension informs RPs if the credential was created as discoverable or not.

FIDO AppID Exclusion Extension: This extension provides for RPs a migration bridge between legacy U2F implementations and WebAuthn/FIDO2. Developers also will have the ability to exclude U2F credentials. This feature determines if a caller’s FacetID is authorized for an AppID.

Problems

  • Browser support is incomplete. Should be eliminated soon.
  • The separate keys are expensive.
  • Platform Authenticators are not widely deployed and do require user action to enable.
  • User Experience is not good. Users are more likely to lock themselves out of Windows than to successfully enable Web Authn.
  • While faster authentication, which is available from Web AuthN, does not mean a better user experience.
  • Account recovery with Web Authentication can be a big challenge.

Solutions

Authenticator Types: (See the wiki page Authenticator for a more detailed discussion'

  1. Platform Authenticator is building into the user device. Examples are Windows Hello, Apple Touch ID. and other biometric readers like fingerprint or Facial Recognition.
  2. Roaming Authenticator is located in an extern security device sometimes called a "key". Examples are Yubikey and Titan Security Key.

Client to authenticator Protocol. Originally. was FIDO U2f or universal second factor. Version 2 and later is the basis for WebAuth 2.

Registration is required before any Authenticator can be used.

Attestation is optional but discouraged by the key manufacturers.

Testing is supported on WebAuthn.io and browser testing at twin.io/webaurhn

quick JavaScript test

PublicKeyCredential.isUserVerifyingPlatformAuthenticatorAvailable().then(
   (available) => {
       console.log("Supported")
   } else { console.log("Not supported") })

Examples are available at: https://codelabs.developers.google.com/codelabs/webauthn-reauth#1

References

Other Material

Historical updates to the WebAuthn specification: