Passkey settings migration - Dfns documentation

This migration is nearing completion. The rpId and origin properties will be removed from all Dfns Applications after the transition period ends. Update your client-side code now if you haven’t already.

What changed

Passkey domain configuration (rpId and origin) has moved from Dfns Applications to a dedicated Settings > Passkeys page in the dashboard. The relying party ID is no longer returned in challenge payloads. Your client-side code must specify it explicitly. For full details on rpId rules, domain whitelisting, and mobile app setup, see WebAuthn configuration.

Required code change

Stop relying on the rpId returned in challenge payloads. Instead, specify the relying party explicitly when initializing your signer.

Web (TypeScript SDK)
Web (no SDK)
React Native
Flutter
iOS (Swift)

Upgrade to @dfns/sdk and @dfns/sdk-browser v0.6.0+:

// before
const signer = new WebAuthnSigner()

// after
const signer = new WebAuthnSigner({
  relyingParty: { id: 'acme.com', name: 'Acme' }
})

Provide the relying party in navigator.credentials.create() and navigator.credentials.get():

// passkey creation
const cred = await navigator.credentials.create({
  publicKey: {
    ...,
    rp: { id: 'acme.com', name: 'Acme' }
  }
})

// passkey usage
const cred = await navigator.credentials.get({
  publicKey: {
    ...,
    rpId: 'acme.com'
  }
})

Upgrade to @dfns/sdk-react-native v0.6.0+:

// before
const signer = new PasskeySigner()

// after
const signer = new PasskeySigner({
  relyingParty: { id: 'acme.com', name: 'Acme' }
})

Upgrade to dfns_sdk_flutter v0.0.5+:

// before
final passkeysSigner = PasskeysSigner()

// after
final passkeysSigner = PasskeysSigner(
  relyingPartyId: 'acme.com',
  relyingPartyName: 'Acme'
);

// before
let signer = PasskeysSigner()

// after
let signer = PasskeysSigner(relyingPartyId: "acme.com")

Dashboard setup

Whitelist your domains in Settings > Passkeys. All rpIds previously configured on your Applications have been pre-filled with origins = *. You no longer need separate Applications per domain. If all your Applications have the same permissions, you can use a single Application ID everywhere.

Configure WebAuthn

rpId rules, domain setup, mobile apps, and troubleshooting

Applications deprecation

Broader changes to the Application model

Documentation Index

​What changed

​Required code change

​Dashboard setup

​Related

Configure WebAuthn

Applications deprecation

What changed

Required code change

Dashboard setup

Related