- From: Shane Weeden via GitHub <sysbot+gh@w3.org>
- Date: Wed, 27 Mar 2024 19:14:24 +0000
- To: public-webauthn@w3.org
> @sbweeden I agree with you, #2021 is preferable from the RP's perspective. But going that route re-opens the can of worms that is, "add in ways to let RP's pre-fail a ceremony." Historically those proposals have gotten squashed pretty quickly in the name of maintaining user agency in these ceremonies. Should not #2021 be rejected for similar reasons? i.e. we can't let RP's fail the ceremony here if UV happened too long ago because then we'd have to allow other proposals for RP's to require more properties of a credential or authenticator be asserted by the client before the RP receives a response. Assuming this was a user _privacy_ concern, I don't think a UV recency policy is a privacy concern, nor does it imply that an RP can pre-fail a ceremony since all authenticators should support UV in some way. It's simply the RP saying that UV caching has its acceptable limits, and this is what they are, such that the client+authenticator can choose to satisfy them without the RP failing the assertion post-ceremony. -- GitHub Notification of comment by sbweeden Please view or discuss this issue at https://github.com/w3c/webauthn/pull/2052#issuecomment-2023779635 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 27 March 2024 19:14:25 UTC