FIDO FIDO Credential Lifecycle & Key Management 2 — Questions and Answers
Question 1: What is the purpose of credential revocation management on the Relying Party side in a FIDO2 deployment?
- To notify the FIDO Alliance when a user account is suspended
- To remove or disable stored public key credentials so they can no longer authenticate a user (Correct answer)
- To rotate the RP's own signing keys used for challenge generation
- To revoke the authenticator's FIDO certification status globally
Correct answer: To remove or disable stored public key credentials so they can no longer authenticate a user
RPs manage revocation by deleting or flagging stored public key credentials, preventing their use in future authentication ceremonies.
Question 2: In the context of FIDO key lifecycle, what is 'attestation key' versus 'credential key'?
- They are the same key used for both purposes to reduce storage requirements
- The attestation key is a factory-burned device key used to prove authenticator provenance; the credential key is the per-RP key generated at registration (Correct answer)
- The attestation key is stored on the RP server; the credential key is stored on the authenticator
- The attestation key expires annually; the credential key never expires
Correct answer: The attestation key is a factory-burned device key used to prove authenticator provenance; the credential key is the per-RP key generated at registration
The attestation key (or batch key) is provisioned by the manufacturer to identify the authenticator model, while credential keys are unique per-registration key pairs generated by the authenticator.
Question 3: Why should Relying Parties store the 'aaguid' (Authenticator Attestation GUID) alongside each credential?
- The aaguid is required by law in US financial regulations for credential tracking
- It identifies the authenticator model, enabling future policy enforcement if a vulnerability is discovered in that model (Correct answer)
- It is used as the credential ID for fast lookup during authentication
- It enables the RP to auto-update the authenticator firmware remotely
Correct answer: It identifies the authenticator model, enabling future policy enforcement if a vulnerability is discovered in that model
Storing the aaguid lets the RP retroactively apply policies if a specific authenticator model is later found to be vulnerable, enabling targeted credential invalidation.
Question 4: What is the recommended practice when a user wants to rotate their FIDO2 credential (e.g., after a security incident)?
- Ask the FIDO Alliance to issue a new credential via the metadata service
- Have the user re-register a new credential after authenticating via an alternate verified method, then delete the old one (Correct answer)
- Modify the existing credential's public key in the RP database to a new value
- Increment the sign count to invalidate all previous assertion signatures
Correct answer: Have the user re-register a new credential after authenticating via an alternate verified method, then delete the old one
Credential rotation requires re-registration: authenticate the user through an alternate path, register a new credential, then revoke the old one from the RP's credential store.
Question 5: What does the 'backup eligibility' (BE) flag in FIDO2 authenticator data indicate?
- The credential is eligible to be backed up and synced to another device or cloud keychain (Correct answer)
- The authenticator passed the FIDO Alliance backup certification test
- The RP has approved this credential for use on backup authentication systems
- The user has enabled two-factor authentication as a backup to FIDO
Correct answer: The credential is eligible to be backed up and synced to another device or cloud keychain
The BE flag indicates the authenticator supports syncing this credential to other devices, letting RPs enforce policies around synced versus device-bound credentials.
Question 6: How should a FIDO2 Relying Party handle the scenario where the same credential ID is submitted by two different user accounts?
- Allow both users to share the credential for convenience
- Reject the second registration — credential IDs must be globally unique per RP and tied to one user (Correct answer)
- Contact the FIDO Alliance to arbitrate the conflict
- Assign the credential to the user who registered first and notify the second
Correct answer: Reject the second registration — credential IDs must be globally unique per RP and tied to one user
Credential IDs must be unique within an RP's system; if a duplicate appears, it signals a potential attack or data integrity issue and should be rejected.
FIDO FIDO Credential Lifecycle & Key Management 2
What is the purpose of credential revocation management on the Relying Party side in a FIDO2 deployment?