I think the exts extension does in fact say the client is supposed to list its supported extensions in the client extension output, while the authenticator lists its supported extensions in the authenticator extension output.

@emlun RP can get such information implicitly in case where both client and authenticator support requested extensions.
But, RP has no idea and cannot differentiate following cases:

• Client supports the extension and the authenticator does not support it
• Client and authenticator do not support the extension

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.
But, it will not work as expected since the client does not support the extension although the authenticator can handle it.

So, RP will see an error or unexpected results and then understand that the client does not support requested extensions.
RP will be happy if it can provide smooth and concrete UX for the users. So, the RP will provide user flow by checking whether the user's client supports extensions that RP wants to leverage or not.

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.

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.
In WebAuthn spec, except isUVPAA(), RP cannot get any information without explicit create or get ceremony.
RP would like to know such information including supported features or extensions of the client before doing something then decide the UX flow for helping to users to avoid unhappy situation.

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.