- From: David Waite via GitHub <sysbot+gh@w3.org>
- Date: Sat, 09 Sep 2023 17:05:44 +0000
- To: public-webauthn@w3.org
Summarizing toward a L3 go/no-go decision: When creation returns an attestation, there is a chance the RP will reject that credential. This creates a problem of distributed state that affects UX - the passkey manager continues to have the record, so the client will present that credential to the end-user as an option in the future, even if the RP has no intention of ever accepting it. The UX for the end-user to remove the credential manually is also likely non-intuitive. There is also the opportunity for this same sort of behavior to happen at a later point, e.g. policy changes or data loss may cause the RP to no longer recognize an established credential on get assertion. This would also be the case for credentials removed from the relying party's self-service authentication management interface (e.g. editable list of registered and accepted passkeys). It would be useful for the RP to hint via the credential object, or via an interface on CredMan, that a credential is invalid. The mechanism would need a way for a relying party to indicate a desired change, in the face of not having visibility into the client-side state. One possibility is a method on `PublicKeyCredential` to remove the credential, present if the feature is supported. Another possibility is a new method in CredMan itself, which might remove various types of credentials beyond `PublicKeyCredential`. If added to CredMan, a decision would need to be made as to whether the operation takes credential identifier/handles or credential objects. I would imagine both of these would need to be promise-based if they have a result, or fire-and-forget hints otherwise. The client may wish to get consent for removal outside of creation, or removal may require network or near-field access which add delays/user action. Credential objects may be useful if we want to only allow deletion after a create/get request. @emlun proposed earlier an interface which acted a bit more as a filter, which might enable removal of credentials outside of get/create, and enable opportunistic broadcast of changes. As an example, this may be useful to indicate edits from a relying party self-service page at submission time, and to continue to inform clients in the future since availability of authenticators may be transient (usb, nfc) and be client-specific (platform authenticators). As a relying party, this would be a very useful feature if it allowed for cleaning up credentials from UX such as conditionally mediated UI. I imagine viability for L3 would be based on feedback from browser/platform clients, and from CredMan (@nsatragno ?) on ergonomics. -- GitHub Notification of comment by dwaite Please view or discuss this issue at https://github.com/w3c/webauthn/issues/1560#issuecomment-1712556285 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Saturday, 9 September 2023 17:05:47 UTC