Browser capability detection. #1219

jafisher-microsoft · 2019-05-15T23:17:05Z

Fixes #1218. Fixes #1202. Fixes #1199.

…lient.

Kieun · 2019-05-16T07:47:13Z

index.bs

+[=[WRPS]=] use this method to determine what capabilities are supported by the [=client=].
+Upon invocation, the [=client=] employs a [=client platform=]-specific procedure to discover supported capabilities.
+The promise is resolved with the capabilities that are supported.
+Based on the result, the [=[RP]=] can take further actions to guide the user to create a credential.


RP may also invoke this method for getting a credential.

Agreed, this is also useful for login scenarios. I can update the text to reflect that.

Kieun · 2019-05-16T07:54:00Z

index.bs

+    :   <dfn>areResidentKeysSupported</dfn>
+    ::  This attribute indicates whether the [=client=] supports creating [=resident credentials=].
+
+    :   <dfn>isUserVerificationSupported</dfn>


Is this different from isUserVerifyingPlatformAuthenticatorAvailable()?

isUserVerifyingPlatformAuthenticatorAvailable currently indicates the enabled state of the UVPA, but the RP cannot distinguish between disabled/unavailable. I left isUserVerifyingPlatformAuthenticatorAvailable alone as RPs are currently using this API, but reflected the tri-state in this new API.

I was asking about the purpose of isUserVerificationSupported() function. We have userVerifyingPlatformAuthenticatorAvailability() and isUVPAA(). What is the difference?

Thanks for clarifying. The intention of isUserVerificationSupported is so that the client can covey whether it supports the UserVerificationRequirement enum. On the other hand, userVerifyingPlatformAuthenticatorAvailability is intended to indicate the specific state of the UVPA on the client platform. Does that make sense?

Make sense.
So, this method is for indicating the client supports userVerification option. IMO, it is better to refer userVerification member instead.

I suggest that the for this (and all other similar functionality detection), we remove these methods and say that if a particular capability is not part of the response from getSupportedCapabilities(), then it's not supported.

If I understand the comment of saying to remove isUserVerifyingPlatformAuthenticatorAvailable(), browsers already implement this function and RPs already depend on it. I don't think we should remove it.

I would prefer the way suggested by @leshi . WebAuthn spec will keep introducing new features. Returning the supported features as a list of string is better and easy to extend.

yes, IIUC, whatever we do, we need to leave isUserVerifyingPlatformAuthenticatorAvailable() nominally intact, and if we do decide to deprecate it in light of other new functionality we define, we ought to mark it (in the spec) as deprecated and point to the new functionality.

I have removed references to an updated UVPAA check, as we currently don't have scenarios to leverage this additional granularity. I have also adopted the style used by Transports to return the list of supported capabilities.

leshi · 2019-05-23T12:26:18Z

index.bs

+<xmp class="idl">
+    dictionary SupportedCapabilities {
+        boolean areU2FDevicesSupported;
+        boolean areCTAPDevicesSupported;


Can you explain the user flow for how you plan to use areU2FDevicesSupported and areCTAPDevicesSupported?

CTAP devices are not supported on every browser. RP will look into this field to decide what they want to support and what they want to show on their page. User Agent detection is too fragile to make these decisions and it requires constant monitoring of what browser/platform combination works.

But why do RPs care about CTAP2 vs CTAP1 (U2F)? They care about capabilities and features -- not transports. Both of which are covered below.

Agreed that we do not currently have a use case for such granularity. I have removed these particular capabilities.

leshi · 2019-05-23T12:31:29Z

index.bs

+    :   <dfn>areResidentKeysSupported</dfn>
+    ::  This attribute indicates whether the [=client=] supports creating [=resident credentials=].
+
+    :   <dfn>isUserVerificationSupported</dfn>


I suggest that the for this (and all other similar functionality detection), we remove these methods and say that if a particular capability is not part of the response from getSupportedCapabilities(), then it's not supported.

equalsJeffH · 2019-06-06T01:01:39Z

Here's an overall comment on "browser capability detection":

I asked Tab Atkins (CSS spec editor) about this (back in April), and he said that the

if (foo.bar()) /* do something */ else /* not there, go figure */

approach, colloquially known as "feature detection", often is the best one can do from JS within a user agent.

There are feature detection JS libraries — e.g., modernizr, yepnope — but results with them can be mixed. Tab says that SVG tried specifying feature label strings (i suppose one asked the svg impl 'what is supported?' and got a list of strings in return), and that sorta worked for a very short time and then implementations would lie about what they supported, then the number of features outgrew the set of strings, etc.

Tab asserts similar efforts occurred in various portions of the web platform with lousy results overall. In CSS, they have a @support <css stuff to test here> rule, which nominally works because CSS is a language, they have a parser, and the assumption is: if the @support rule can successfully parse the <css stuff to test here>, then it's supported.

WebAuthn/FIDO2 is an especially tough problem because we have a browser->protocols->authnr stack and the answer to "is foo feature supported" question may involve component answers from several layers in the stack.

dwaite · 2019-06-06T19:51:54Z

The transports result might need to be defined as what the client + operating system can support, and not what currently is supported by available hardware and settings. Examples what this may be appropriate:

CoreBluetooth on the Mac is available, but the user may have the radio turned off
NFC support is not built into the mac, but could hypothetically be provided by an external reader. Like above, this could mean NFC support comes and goes during authentication

I suppose the user might toggle the UVPA as well.

equalsJeffH · 2019-06-10T00:08:08Z

just fyi; @agl opened: issue w3ctag/design-reviews#383 with the TAG, regarding this here PR.

equalsJeffH

Let's see what the TAG has to say: #1219 (comment)

jcjones

I'd also want to add a section about what browsers should do when they want to limit the information they reveal. Perhaps we suggest that it be 'static' or hard-coded to a safe set of defaults?

jcjones · 2019-06-10T16:19:40Z

index.bs

+
+<xmp class="idl">
+    dictionary SupportedCapabilities {
+        boolean areU2FDevicesSupported;


Will this one ever be used? Can we imagine this being set to false and for RPs to code themselves to handle it?

Agreed, this has been removed.

jcjones · 2019-06-10T16:29:30Z

index.bs

+    ::  This attribute indicates whether the [=client=] supports communicating with [[FIDO-CTAP]] devices.
+
+    :   <dfn>areResidentKeysSupported</dfn>
+    ::  This attribute indicates whether the [=client=] supports creating [=resident credentials=].


If you support CTAP devices, isn't this always going to be true? Or are clients supposed to guess what users' devices in their pocket can do, and fuzzily adjust depending on what's been paired/plugged in of late?

Chrome at the moment (version 75) supports CTAP2 devices, but doesn't have support for account selection etc and so would return false for this because resident keys aren't actually usable. I.e. I think these fields are reporting on browser capabilities so it's “assuming that the user has an authenticator that does resident keys, will it actually work with this browser?”.

Resident key support is still being returned as we have a use case for this, and browsers do react differently today.

jcjones · 2019-06-10T16:31:44Z

index.bs

+<xmp class="idl">
+    dictionary SupportedCapabilities {
+        boolean areU2FDevicesSupported;
+        boolean areCTAPDevicesSupported;


Point of order: U2F == CTAP1, and CTAP2 is the new thing, right?

Seems like this should be areCTAP2DevicesSupported? Or maybe it should just be minimumCTAPVersionSupported and make it a float?

Agreed about saying “CTAP2”.

Minimum version might be a problem for Safari: don't they only support CTAP2 devices at the moment?

jcjones · 2019-06-10T16:33:52Z

index.bs

+    :   <dfn>userVerifyingPlatformAuthenticatorAvailability</dfn>
+    ::  This attribute indicates the availability of a [=user-verifying platform authenticator=] on the [=client=].
+
+    :   <dfn>transportsSupported</dfn>


We have to define the strict ordering of these two sequences to reduce fingerprinting opportunity.

Would it make sense to define them as ordered sets? I agree we should probably also explicitly define the order like we have for [[transports]].

For a list, I always default to saying that it should be ordered lexicographically and not contain duplicates. Looks like ordered sets imply the uniqueness condition, so that would work.

I have applied the same logic as was previously done for transports.

index.bs

emlun · 2019-06-11T16:17:21Z

index.bs

+
+<div link-for-hint="WebAuthentication/getSupportedCapabilities">
+
+[=[WRPS]=] use this method to determine what capabilities are supported by the [=client=].


s/client/client platform/

emlun · 2019-06-11T16:20:02Z

index.bs

+    :   <dfn>userVerifyingPlatformAuthenticatorAvailability</dfn>
+    ::  This attribute indicates the availability of a [=user-verifying platform authenticator=] on the [=client=].
+
+    :   <dfn>transportsSupported</dfn>


Would it make sense to define them as ordered sets? I agree we should probably also explicitly define the order like we have for [[transports]].

emlun · 2019-06-11T16:22:33Z

index.bs

+    };
+</xmp>
+
+This dictionary is used by [=[WRPS]=] to determine the supported capabilities of the [=client=].


Throughout this section: s/[=client=]/[=client platform=]/

emlun · 2019-06-11T17:06:40Z

As was discussed on recent WG calls, I think that isUserVerificationSupported is really getting at whether the client supports PIN entry - because on-authenticator UV such as a fingerprint scanner requires no special support from the client, and UV on a platform authenticator is supported if and only if isUVPAA() returns true.

However: suppose we rename isUserVerificationSupported to isPinEntrySupported. Is that actually useful to the RP? What if the user wants to use a biometric authenticator? Since there's no way for the RP to control whether to use PIN or other UV, won't the RP have to resort to userVerification: "preferred"/"required" anyway?

agl · 2019-06-11T21:32:12Z

index.bs

+<xmp class="idl">
+    dictionary SupportedCapabilities {
+        boolean areU2FDevicesSupported;
+        boolean areCTAPDevicesSupported;


Agreed about saying “CTAP2”.

Minimum version might be a problem for Safari: don't they only support CTAP2 devices at the moment?

agl · 2019-06-11T21:33:41Z

index.bs

+
+### Capability Support - PublicKeyCredential's `getSupportedCapabilities()` Method ### {#sctn-getSupportedCapabilities}
+
+<div link-for-hint="WebAuthentication/getSupportedCapabilities">


Will Microsoft's webauthn.dll export a reflection of this function for browsers running on >= 19H1? Some of the fields are browser specific, but some depend on the platform.

agl · 2019-06-11T21:34:19Z

index.bs

+        boolean areU2FDevicesSupported;
+        boolean areCTAPDevicesSupported;
+        boolean areResidentKeysSupported;
+        boolean isUserVerificationSupported;


As I think was mentioned in the call, isUserVerificationSupported seems odd and I think you might want isClientPINSupported.

I think isUserVerificationSupported is more about whether the client (browser) supports userVerification option for create() and get() call. Plus, it's better to have isClientPINSupported as well.

Do we have other forms of user verification that hte client can do besides clientPin? If not, I think isClientPINSupported is the correct name here.

Updated for clientPin as opposed to UV.

agl · 2019-06-11T21:36:21Z

index.bs

+    ::  This attribute indicates whether the [=client=] supports communicating with [[FIDO-CTAP]] devices.
+
+    :   <dfn>areResidentKeysSupported</dfn>
+    ::  This attribute indicates whether the [=client=] supports creating [=resident credentials=].


Chrome at the moment (version 75) supports CTAP2 devices, but doesn't have support for account selection etc and so would return false for this because resident keys aren't actually usable. I.e. I think these fields are reporting on browser capabilities so it's “assuming that the user has an authenticator that does resident keys, will it actually work with this browser?”.

agl · 2019-06-11T21:39:26Z

index.bs

+    :   <dfn>userVerifyingPlatformAuthenticatorAvailability</dfn>
+    ::  This attribute indicates the availability of a [=user-verifying platform authenticator=] on the [=client=].
+
+    :   <dfn>transportsSupported</dfn>


For a list, I always default to saying that it should be ordered lexicographically and not contain duplicates. Looks like ordered sets imply the uniqueness condition, so that would work.

emlun · 2019-06-12T19:46:14Z

Edited OP to add close macros for all related issues.

index.bs

akshayku · 2019-06-14T17:53:40Z

index.bs

+
+### Capability Support - PublicKeyCredential's `getSupportedCapabilities()` Method ### {#sctn-getSupportedCapabilities}
+
+<div link-for-hint="WebAuthentication/getSupportedCapabilities">


…have concrete use cases.

jafisher-microsoft · 2019-06-18T23:22:28Z

@emlun @leshi @Kieun @jcjones @agl , I have made changes based on feedback. In particular, the capabilities have been scoped down significantly to concrete use cases that our Microsoft RP (and other RPs) have requested to take advantage of. Namely whether the client platform will support Client PIN and whether or not it supports Resident Keys. Both of these currently have states where some platform + browser + version combinations will say true vs. false. Look forward to more discussions on this.

Kieun · 2019-06-19T01:24:18Z

@jafisher-microsoft Is extensionsSupported removed intentionally since there is no concrete usecase for this?

emlun · 2019-06-19T18:09:04Z

index.bs

+    ::  This attribute indicates whether the [=client platform=] supports [=user verification=] via client PIN.
+
+    :   <dfn>residentKeys</dfn>
+    ::  This attribute indicates whether the [=client platform=] supports creating [=resident credentials=].


This is also about whether the client supports resident credential selection (for external authenticators without their own display), right? Or should that be a separate capability?

+1, I agree with @emlun.

I would assume that "full resident key support" means: 1) clientPin, 2) creation of resident keys, 3) exercising resident keys, 4) account selection, and maybe 5) resident key management.

I suspect that we want this boolean to mean all of those things.

@leshi, what do you mean by "account selection" ?

(5), key management, isn't standardised in WebAuthn (yet?), so I'd say we can't make that requirement at this time.

emlun · 2019-06-19T18:09:31Z

index.bs

+<div dfn-type="enum-value" dfn-for="SupportedCapability">
+    Each enum value indicates a supported capability of the [=client platform=] for use by [=[WRPS]=].
+    :   <dfn>clientPin</dfn>
+    ::  This attribute indicates whether the [=client platform=] supports [=user verification=] via client PIN.


Suggested change

:: This attribute indicates whether the [=client platform=] supports [=user verification=] via client PIN.

:: This value indicates that the [=client platform=] supports [=user verification=] via client PIN.

emlun · 2019-06-19T18:09:49Z

index.bs

+    ::  This attribute indicates whether the [=client platform=] supports [=user verification=] via client PIN.
+
+    :   <dfn>residentKeys</dfn>
+    ::  This attribute indicates whether the [=client platform=] supports creating [=resident credentials=].


Suggested change

:: This attribute indicates whether the [=client platform=] supports creating [=resident credentials=].

:: This value indicates that the [=client platform=] supports creating [=resident credentials=].

rlin1 · 2019-06-19T19:21:24Z

What happens if
(1) the platform doesn't support clientPIN, but
(2) a connected roaming authenticator support user verification through a fingerprint sensor?

equalsJeffH · 2019-06-19T19:35:07Z

on webauthn call today:
@akshayku's described his use case (a primary one?): user logs in, is shown promo "want to add SK?" but wants to know what the browser supports in order to tailor the promo and not have the user go thru a bunch of the ceremony to then have the ceremony fail.

@leshi relates that in the google security key experience, they learned that users were really confused if they were offered to register a security key in one browser, but not even offered in another browser. the lesson was that it was more clear to users if they go thru part of the ceremony and if the browser does not support it then fail.

overall situation seems to be:
@akshayku is trying to work around the situation that different versions of different browsers support none, some, (nearly) all of the webauthn spec. and then deployers are trying to workaround these browser differences. observed that even if this PR is landed, it would be hopefully easier to impl than the features themselves, but there of course is the possibility that there'd be browser impl skew for even this feature-discovery facility.

sbweeden · 2019-06-19T20:56:01Z

In general I think an RP has to deal with the case that the browser doesn't even support this proposed API anyway, and potential variances in behaviour of this API, so I think it's better that the RP always deals with the error case rather than trying to pre-emptively render different UX based on what this API is proposing.

akshayku · 2019-07-17T17:00:47Z

@sbweeden has a very good point due to how the platforms implement the spec (only released published final version vs draft versions) and their support on various versions in different versions of the platform. And this API may not be present. Given this, I am not sure how much we are moving the needle and RPs has to manually be testing browser/platform combination for a while and this PR probably won't help that much.

@jafisher-microsoft, What do you think?

akshayku · 2019-07-31T19:11:47Z

Closing this down as right now things are not clear at this point in time..

Add feature detection for RPs to determine what is supported on the c…

ff791f6

…lient.

jafisher-microsoft added this to the L2-WD-02 milestone May 15, 2019

jafisher-microsoft requested review from agl, emlun and akshayku May 15, 2019 23:17

jafisher-microsoft self-assigned this May 15, 2019

Kieun reviewed May 16, 2019

View reviewed changes

emlun requested review from jcjones and equalsJeffH May 16, 2019 11:21

emlun added subtype:FeatureProposal type:technical subtype:algorithms/WebIDL labels May 16, 2019

leshi requested changes May 23, 2019

View reviewed changes

agl mentioned this pull request Jun 6, 2019

Web Authentication Feature Detection w3ctag/design-reviews#383

Closed

4 tasks

equalsJeffH reviewed Jun 10, 2019

View reviewed changes

jcjones requested changes Jun 10, 2019

View reviewed changes

emlun requested changes Jun 11, 2019

View reviewed changes

agl reviewed Jun 11, 2019

View reviewed changes

emlun mentioned this pull request Jun 12, 2019

How to get supported client extension #1199

Closed

akshayku requested changes Jun 14, 2019

View reviewed changes

Scope down the set of supported capabilities to ones which currently …

1d414c6

…have concrete use cases.

emlun requested changes Jun 19, 2019

View reviewed changes

emlun mentioned this pull request Jun 19, 2019

Provide API for indicating whether the platform has attached(bound) authenticator or not #1218

Closed

agl mentioned this pull request Jul 8, 2019

Add “appidExclude” extension. #1244

Merged

akshayku closed this Jul 31, 2019

emlun mentioned this pull request Jul 31, 2019

Supported features detection from the browser #1202

Closed

emlun deleted the jafisher-featuredetection branch June 22, 2022 22:00

Kieun mentioned this pull request Jul 18, 2023

Add new getClientCapabilities method #1923

Merged


		<div link-for-hint="WebAuthentication/getSupportedCapabilities">

		[=[WRPS]=] use this method to determine what capabilities are supported by the [=client=].


		### Capability Support - PublicKeyCredential's `getSupportedCapabilities()` Method ### {#sctn-getSupportedCapabilities}

		<div link-for-hint="WebAuthentication/getSupportedCapabilities">

	:: This attribute indicates whether the [=client platform=] supports [=user verification=] via client PIN.
	:: This value indicates that the [=client platform=] supports [=user verification=] via client PIN.

Browser capability detection. #1219

Browser capability detection. #1219

Conversation

jafisher-microsoft commented May 15, 2019 • edited by pr-preview bot

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

equalsJeffH commented Jun 6, 2019 • edited

dwaite commented Jun 6, 2019

equalsJeffH commented Jun 10, 2019 • edited

equalsJeffH left a comment

Choose a reason for hiding this comment

jcjones left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

emlun commented Jun 11, 2019

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

emlun commented Jun 12, 2019

Choose a reason for hiding this comment

jafisher-microsoft commented Jun 18, 2019

Kieun commented Jun 19, 2019

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

rlin1 commented Jun 19, 2019

equalsJeffH commented Jun 19, 2019

sbweeden commented Jun 19, 2019

akshayku commented Jul 17, 2019

akshayku commented Jul 31, 2019

jafisher-microsoft commented May 15, 2019 •

edited by pr-preview bot

equalsJeffH commented Jun 6, 2019 •

edited

equalsJeffH commented Jun 10, 2019 •

edited