- From: Adam Langley via GitHub <sysbot+gh@w3.org>
- Date: Fri, 24 Feb 2023 15:09:20 +0000
- To: public-webauthn@w3.org
I think dolda2000 has a reasonable point here. Challenges can be stored client-side, and contain something like HMAC(timestamp), but we want those challenges to be time-bounded otherwise the assertion turns into a password that, if leaked, can be reused. But a page using conditional UI could be open for days in a tab before use so the time bound would have to be equally long. Much better than forever, for sure, but hmm. Telling every site to abort and restart the request works, but how many will? (dolda2000 is applying supererogatory attention to this issue as it is, compared to an average site!) Having the site remember and reject used challenges is also good, but the same "how many will?" applies. > it would probably be nicer if conditional mediation were a two-stage process where the browser effectively requests the full challenge information from the page if and when the user actually decides to start using WebAuthn While the implementation challenge is non-trivial for the browser, a `challengeCallback` of type `() -> Promise<BufferSource>` as an alternative to `challenge` is interesting. -- GitHub Notification of comment by agl Please view or discuss this issue at https://github.com/w3c/webauthn/issues/1856#issuecomment-1443822151 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Friday, 24 February 2023 15:09:21 UTC