You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Vert.x supports this, but the Quarkus equivalent classes WebAuthnSecurity and WebAuthnController, which have a copy of some code from WebAuthnHandlerImpl and WebAuthnImpl do not (this was added after we copied the logic).
Implementation ideas
We can support it, but that means setting an empty username cookie, or just not setting it, and figuring out how to turn this into a valid QuarkusPrincipal in WebAuthnIdentityProvider, which is a bit harder, since that relies on having a username.
I suppose we might fetch the username from the WebAuthnUserProvider since it's required for registration?
Also this would need tests, and requires setting the requireResidentKey option, which I'm not sure what it does.
The text was updated successfully, but these errors were encountered:
The spec mandates a username is required when creating credentials (register) on the client side JS API
We have two lookup methods to find credentials from the DB : using username, or using credID. The credID one is only used ATM on login if resident-key is set to true
Technically, during the login challenge, we need to pass a set of allowed credentials to the client-side JS API, so it can find a suitable authenticator. This means we need to find them from the DB, which means we need a way to find them. ATM we pretty much need a username to find them, since at this point, we don't have a credentialID yet.
Description
Vert.x supports this, but the Quarkus equivalent classes
WebAuthnSecurity
andWebAuthnController
, which have a copy of some code fromWebAuthnHandlerImpl
andWebAuthnImpl
do not (this was added after we copied the logic).Implementation ideas
We can support it, but that means setting an empty
username
cookie, or just not setting it, and figuring out how to turn this into a validQuarkusPrincipal
inWebAuthnIdentityProvider
, which is a bit harder, since that relies on having a username.I suppose we might fetch the username from the
WebAuthnUserProvider
since it's required for registration?Also this would need tests, and requires setting the
requireResidentKey
option, which I'm not sure what it does.The text was updated successfully, but these errors were encountered: