Signal API - changes to Authenticator / Credential managers stored credentials and potential necessity for signaling RP of changes. #26
-
|
I have some question about the Signal API - When a RP can signal changes has happened to the Authenticator / credentials manager will or can the API give signaling in reverse if changes happen at the Authenticator / Credentials manager side? Will an authenticator / Credentials manager be able to inform of updates to metadata and revocation (deletion) of a credential to the RP? Can the RP or authenitcator / credentials manager trust and confirm the other party has updated or revoked deleted credentials and metadata associated or affected by the change in the scope of the rpid? What are your thoughts? |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment 1 reply
-
No. This opportunistic API is fire and forget. There are no guarantees made. From the spec:
No, there is no direct connection between an RP and a credential manager in the passkey ecosystem, by design (with a small exception for same party credential managers, but that isn't relevant here).
This information is not necessary for the RP. This functionality is primarily to improve user experience (e.g. so a deleted passkey doesn't show up in the autofill UI).
There is no traditional credential revocation in the FIDO2/WebAuthn ecosystem. By removing / unlinking the passkey from the account server side, it is effectively revoked, regardless of whether the passkey still exists in a credential manager. |
Beta Was this translation helpful? Give feedback.
No. This opportunistic API is fire and forget. There are no guarantees made. From the spec:
No, there is no direct connection between an RP and a credential manager in the passkey ecosystem, by design (with a small exception for same party credential managers, but that isn't relevant here).