- From: Konstantin Isaev via GitHub <sysbot+gh@w3.org>
- Date: Sat, 23 May 2020 23:21:15 +0000
- To: public-webauthn@w3.org
I surprised that WebAuthn has ONLY javascript API, without a pure html version. But I supsect that this is because a lot of aspects is required to be defined, especially at scope like "developers taste". For me, this can be done with using these: 1. link with rel="auth/webauthn" href="url-to-config" name="relPartyConfigurationName"> 2. script type="application/json+webauth.relPartyConfiguration" id "relPartyConfigurationName" that can be used by sites who prefer to pre-render this kind of settings. 3. script type="application/json+webauth.registrationOptions" id="registrationOptions" to store al this pack of options that necessary for webauth registration API call 4. script type="application/json+webauth.loginOptions" id="registrationOptions" to store al this pack of options that necessary for webauth registration API call 5. in webforms the input of type="authentication" scheme="webauthn" verb="register" configuration="registrationOptions" and similar for "authentication" verb, but with "maxage" attribute to represent how old last user attestation can be for authentication for form send request. What I wanted to avoid or make optional, is having JSON blobs at attribute values, and allow prerendering old dynamic stuff, like challenge for registration forms. using unsupported type for input will allow to fallback to js scenario in case if html-only form auth does not supported. In the "authentication" input attribute "scheme" can be various, in case if e. g. scheme like webauthn/2.0 will emerge, or even "basic" if it is suitable for context/project. Any no-js solution for advanced authentication require following - work with W3C to get consensus on how represent complicated auth schemes, like webauthn in html. Another question - how to guarantee for example, that anything that has been considered as non-public, downloaded since registration/authentication flow successfully completed, would be authenticated with this public key auth? 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 as body for 401 response? Ultmate flexibity is not just avoiding JS, but option to not having even html at all, and use the public key created in webauthn flow to authenticate all or "protected" requests within session regardless of usage of JS or even html. Webauthn concept actually allow to introduce the ability to register user without JS and html in general but this may be beyond the scope of discussion. -- GitHub Notification of comment by konstardiy Please view or discuss this issue at https://github.com/w3c/webauthn/issues/1255#issuecomment-633153034 using your GitHub account
Received on Saturday, 23 May 2020 23:21:17 UTC