- From: Firstyear via GitHub <sysbot+gh@w3.org>
- Date: Mon, 04 Jul 2022 00:57:31 +0000
- To: public-webauthn@w3.org
> @Firstyear I have a draft ready, but I haven't yet opened a pull request because it builds on PR #1746 and a few more larger restructurings which I'd like to have reviewed on their own first. But you can take a look on the [branch in my fork](https://github.com/w3c/webauthn/compare/editorial-fixes...emlun:webauthn:wip/uv-guidance?expand=1) if you're curious. There's no preview and diff automatically available, but you can build the spec yourself (see the README) if you want to. > Thanks, I'll take a look soon. > > CTAP2.0, which forces UV=1 under discouraged but then won't apply UV during authentication under discouraged. Is this why you mention that you have to trust-on-first-use the UV from authentication? > > No, it's because UV=1 does not identify the user to the RP, it only tells the RP it's the _same_ user (PIN sharing etc. notwithstanding) as the last time UV=1 was seen on that credential. So UV=1 does not suffice as a second factor if UV=1 has never been seen with that credential before, because there's no guarantee that it's the same user operating the authenticator as before. Ahh yes. That's also true. But that's a bigger issue with the attitude that credentials are "ceremony bound" rather than being something that persists and has a longer lifespan. Humans don't think about a set of "keys to their house" as having ceremonies with the lock, they consider that the key and that lock are intertwined and matched. The same way that a password to a website is a specific identity to that site. The entire notion that UV can change between registration and authentication (like ctap2.0 does under discouraged) really undermines this human approach to credentials, as does the fact that UV=1 can "suddenly" appear during the lifecycle of a credentials existence. -- GitHub Notification of comment by Firstyear Please view or discuss this issue at https://github.com/w3c/webauthn/issues/1510#issuecomment-1173219216 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Monday, 4 July 2022 00:57:33 UTC