Device E2E

Before a release, test on real devices. Passkey ceremonies depend on platform accounts, app signing, associated domains, Digital Asset Links, credential providers, and user verification UI.

Use a real relying-party domain and a real development or production build.

Maintainers should complete this checklist before merging a release PR. Then follow Releasing for versioning, changelog review, npm publish, and post-publish verification.

Prerequisites

• A server that returns fresh WebAuthn registration and authentication options.
• Server-side verification for registration and authentication responses.
• iOS apple-app-site-association hosted at /.well-known/apple-app-site-association.
• Android assetlinks.json hosted at /.well-known/assetlinks.json.
• The app build signed with the certificate fingerprints listed in assetlinks.json.
• The server expected-origin allowlist contains the HTTPS origin and each trusted certificate's android:apk-key-hash: origin.
• A physical iOS or Android device with screen lock and passkeys enabled. For local Android emulator work before device E2E, sign in with a Google account and set a screen lock so Credential Manager can create and assert passkeys.

Builds

Run at least one iOS build and one Android build. If your Android debug and production builds use different signing certificates, add both fingerprints to Digital Asset Links and the server configuration, then verify both end to end.

iOS development build -> example.com AASA -> registration -> authentication
Android development build -> assetlinks.json debug fingerprint -> registration -> authentication
Android production build -> assetlinks.json production fingerprint -> registration -> authentication

Registration

1. Install a fresh app build.
2. Fetch a fresh registration challenge from the server.
3. Call createPasskey.
4. Confirm platform UI is shown.
5. Complete user verification.
6. Send RegistrationResponseJSON to the server.
7. Confirm server verification succeeds and stores the credential.

Authentication

1. Fetch a fresh authentication challenge from the server.
2. Call authenticateWithPasskey.
3. Complete user verification.
4. Send AuthenticationResponseJSON to the server.
5. Confirm server verification succeeds.

Negative cases

• Cancel platform UI and confirm ERR_PASSKEY_CANCELED.
• Use an unassociated domain and confirm platform failure is reported.
• Use an expired challenge and confirm server verification fails.
• Use a release-signed build against debug-only Android asset links and confirm association failure.

Release notes

Before publication, record real-device evidence that automated fixtures cannot prove:

• Association: AASA and Digital Asset Links paths exercised
• Signing: certificate fingerprints trusted by assetlinks.json and the server origin allowlist
• System UI: platform passkey presentation observed for registration and authentication
• User verification: biometric or device credential completion succeeded

Also record the device model, OS version, app build profile, relying-party domain, and server environment used for the final pass. Attach those notes when reviewing the release PR so publication evidence stays complete.