v13.3.1

Changes:

• [server] Fixed an issue with verifyRegistrationResponse() failing to verify some Packed and SafetyNet statements (#767)

v13.3.0

• [browser] startRegistration() and startAuthentication() will recognize punycode domains as valid domains when trying to identify why an error occurred (#750)
• [server] A new verifyMDSBlob() helper method has been added to verify and extract metadata statements from FIDO MDS blobs. See the docs here for more info (#752)

v13.2.3

Changes

• [server] Dependencies have been updated to fix a "Cannot get schema" error that may occur when verifying responses after upgrading to v13.2.0+ (#747)

v13.2.2

Changes

• [browser] [server] In the spirit of contributing to increased software supply chain transparency, both libraries are now published via GitHub Actions workflows. Package listings on JSR and NPM feature build transparency logs at the bottom of their respective pages (#725, #726, #727)

v13.2.1

Changes:

• [server] generateRegistrationOptions() will now correctly encoded the userID argument to base64url when it is an instance of Node's Buffer (#724)

v13.2.0

• [server] The return value from verifyRegistrationResponse() has been defined more strictly to communicate that registrationInfo will only ever be present if verified is true (#715)
• [server] verifyRegistrationResponse() can now verify attestations containing SHA256 hashes by using EC public keys with the P-384 curve (#721)
• [server] The Android SafetyNet "CTS profile match" system integrity check can now be disabled by setting attestationSafetyNetEnforceCTSCheck: false when calling verifyRegistrationResponse(). This check remains enforced by default (#722)
• [browser] [server] These libraries now have better support in Deno 2.2+ projects which use generic typing for Uint8Array via TypeScript 5.7. SimpleWebAuthn values of type Uint8Array_ are equivalent to Uint8Array in Deno 2.1 and earlier, and Uint8Array<ArrayBuffer> in Deno 2.2 and later. (#717)

v13.1.2

Changes

• [browser] [server] Exported the ResidentKeyRequirement type to help with type inference (#704)

v13.1.1

Changes:

• [server] "android-key" attestation statement verification has been modernized (#675)
• [server] More TPM manufacturers are recognized while verifying "tpm" attestation statements (#673)

v13.1.0

Changes:

• [server] The cross-fetch dependency has been removed from the project to silence in the console DeprecationWarning's about a "punycode" module (#661)
• [browser] startRegistration() and startAuthentication() will now warn about calls made using the pre-v11 call structure to encourage refactoring to use the current call structure, but still try to handle such calls the best they can (#664)

v13.0.0 - The one where they share a type

Hot on the heels of the last major release, v13 introduces support for registration hints! Refined types and improved attestation trust anchor verification are also included. Last but not least, we say goodbye to one of the project's packages for better docs and fewer dependencies to install. Read on for more information, including refactor advice for dealing with the retirement of @simplewebauthn/types.

Changes:

• [server] A new preferredAuthenticatorType argument can be set when calling generateRegistrationOptions() to generate options that encourage the browser to direct the user to register one of three types of authenticators: 'securityKey', 'localDevice', or 'remoteDevice' (a.k.a. opinionated WebAuthn hints support) (#653)
• [browser] startRegistration() will recognize hints if specified in optionsJSON (#652)
• [server] Attestation verification now recognizes intermediate certificates as trust anchors (#650)
• [browser] [server] The types previously maintained in the types package are now included within the browser and server packages. See Breaking Changes below for more info (#655)

Breaking Changes

@typescript/types is being retired.

Its types will now be included directly in @simplewebauthn/browser and @simplewebauthn/server.

To refactor existing imports from /types, simply import them from /browser or /server instead:

Before:

import type {
  AuthenticationResponseJSON,
  RegistrationResponseJSON,
  WebAuthnCredential,
} from '@simplewebauthn/types'; // <--

After:

import type {
  AuthenticationResponseJSON,
  RegistrationResponseJSON,
  WebAuthnCredential,
} from '@simplewebauthn/server'; // <--

---

[server] attestationType no longer accepts 'indirect'

The benefits of indirect attestation are too minimal to be useful for Relying Parties. In practice it is almost never used over ignoring the concept completely with 'none' or needing to be intentional and setting 'direct'.

RP's that have been specifying attestationType: 'indirect' when calling generateRegistrationOptions() will need to refactor their code to either omit attestationType (generateRegistrationOptions() will default to attestationType: 'none') or set attestationType: 'direct' instead:

Before:

const options = await generateRegistrationOptions({
  // ...
  attestationType: 'indirect'
});

After:

const options = await generateRegistrationOptions({
  // ...
});

-or-

const options = await generateRegistrationOptions({
  // ...
  attestationType: 'direct'
});