- From: Konstantin Isaev via GitHub <sysbot+gh@w3.org>
- Date: Mon, 25 May 2020 22:17:45 +0000
- To: public-webauthn@w3.org
> > prerendering old dynamic stuff, like challenge for registration forms. > > You should never reuse a [`challenge`](https://www.w3.org/TR/2019/WD-webauthn-2-20191126/#dom-publickeycredentialcreationoptions-challenge), it should be uniquely generated for each registration/authentication ceremony. See [ยง13.4.1. Cryptographic Challenges ](https://www.w3.org/TR/2019/WD-webauthn-2-20191126/#sctn-cryptographic-challenges) (and pardon me if I misinterpreted what you meant). Nice catch! The options object can have not "challenge", but "challengeSource (url), expected to return e. g. `application/octet-stream` with raw bytes for challenge, and can have some restrictions like request CORS restrictions must apply, and require some rule for presense of `referrer` within same domain.. What do you think about "webauthn without html" scenario, especially `Like if user requests a protected page, server returns 401, and what server must say in challenge details to kick in webauthn flow? Should server send that fancy JSON need to kick webauth login flow as body for 401 response?` Of course this will require sending public key generated from credentials to work in full "no-html" scenario after login via webauthn was made, for all requests within related origin.... Which can replace cookies used for keeping login sessions today.... -- GitHub Notification of comment by konstardiy Please view or discuss this issue at https://github.com/w3c/webauthn/issues/1255#issuecomment-633730474 using your GitHub account
Received on Monday, 25 May 2020 22:17:47 UTC