New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
How to get supported client extension #1199
Comments
I think the |
@emlun RP can get such information implicitly in case where both client and authenticator support requested extensions.
So, RP cannot fully understand whether the authenticator or client supports extensions which the RP wants to leverage. As well as this, clients need to provide the way for RP to get the supported client extension separately like isUserVerifyingPlatformAuthenticatorAvailable method(). RP would like to know which extensions supported by the user's client (browser) before running create() or get() call. |
on 17-Apr-2019 call @agl expresses desire for concrete use case where this info re supported extensions is needed? |
RP may get supported extensions of a certain authenticator during registration. Then, RP stores such information within it's storage (DB) to leverage later authentication. This means that the client (browser) understands and supports exts extension or specific extensions that the RP has requested implicitly. After that, when the user tries to authenticate with the same authenticator on another client (which does not support such extensions), RP will set the supported extensions by investigating the storage and expect to be processed by the client and the authenticator. So, RP will see an error or unexpected results and then understand that the client does not support requested extensions. For example, RP does not want to make caBLE authentication flow when the client does not support it although caBLE registration was done before with another client. |
That's a concrete use case, but there's already enough places for the RP to enter this information for the platform to make a smart choice—i.e. the per-credential transports. If the platform finds that it just has a “cable” credential and doesn't support that transport it can display appropriate UI. |
@agl It's just one of example. If we trying to provide username-less flow (empty allowList), we don't have any hint or information for the authentication before getting the results. |
I am also thinking more about this recently although my case is slightly broader. Our MSA adoption has similar difficulties figuring out what is supported in which platform/browser combination. Not all browsers are writing code at same pace even if they agree to adopt the full spec. And every time a platform/browser comes into supporting something, asking RPs to update their logic for that combination is not sustainable. For example, certain browser may never support external authenticators. Another example, in one case, there are resource constraints somewhere in implementing the spec. Right now there is no way to know that. This is leading into unpleasant experience of the users and has really greater negative impact on RPs adoption. One case specific to extension is credProtect extension that we came up recently. If a browser don't support it, as an RP, he may not want to provide certain scenarios. I am thinking of clientGetInfo similar to authenticatorGetInfo where one can tell what it supports. We would really want to write RP code getting capabilities from the browser instead of figuring out which combination(detection of that is very fragile) works. We want to write RP code one time and not update it every time some platform/browser combination becomes available. |
As @akshayku said, for RP perspective, it is hard and clumsy to handle the difference among browsers/platforms. We don't want to inspect user agent from the client to get such information and write hard coded conditional statements. |
Handled by #1219 |
Removed pr-open label since #1219 was closed. |
On 2020-01-08 call: this needs some kind of feature detection, and since we closed #1219 that would imply we're closing this as well. |
Currently, the WebAuthn does not define the way for RP to get supported extension that the client supports.
For the authenticator extension support, there is a exts extension so that RP may obtain such information during the create() call.
Similarly, the RP would like to know which extensions are supported by user's client.
The text was updated successfully, but these errors were encountered: