W3C home > Mailing lists > Public > public-webauthn@w3.org > February 2021

[webauthn] Surface platform authenticator status in the `create` response / helping RPs track UV/PA/RK (#1567)

From: Lucas Garron via GitHub <sysbot+gh@w3.org>
Date: Tue, 09 Feb 2021 03:11:02 +0000
To: public-webauthn@w3.org
Message-ID: <issues.opened-804160955-1612840261-sysbot+gh@w3.org>
lgarron has just created a new issue for https://github.com/w3c/webauthn:

== Surface platform authenticator status in the `create` response / helping RPs track UV/PA/RK ==
The following are specified in the same place:

https://w3c.github.io/webauthn/#dictdef-authenticatorselectioncriteria
```
dictionary AuthenticatorSelectionCriteria {
    DOMString                    authenticatorAttachment;
    DOMString                    residentKey;
    boolean                      requireResidentKey = false;
    DOMString                    userVerification = "preferred";
};
```

However, there is no consistent  way for the RP to check on these criteria:

## Whether the registration is for a user-verifying authenticator

Embedded inside CBOR attestation.

Drawbacks:

- Requires sending a non-trivial amount of code to read on the client (but not so bad to read on the server).

## Whether the registration is a discoverable credential (resident key)

Available in [a client extension](https://w3c.github.io/webauthn/#dom-authenticationextensionsclientoutputs-credprops).

Drawbacks:
- Only implemented in [Chrome 89](https://bugs.chromium.org/p/chromium/issues/detail?id=1117630) until recently), [not yet available on some platforms[(https://omahaproxy.appspot.com/).
- RPs have to remember to ask for this info (unless #1556 leads to a change). May of them will not know to ask for it, or think to ask for it, and it is generally good practice not to ship [extra code to the client](https://github.com/w3c/webauthn/issues/1362) if you don't need it. RPs might not realize they needed to ask for an extension until it's too late.

## Whether the registration is a platform authenticator

As far as I can tell, this information is not available from the response. The RP has to ask for it, and hope the client did the right thing.

--------

Looking at this, I have the following thoughts:

1) it would be nice to receive information whether the registration comes form a platform authenticator, at least in the case where the RP specifically asked for it.
2) It would be nice if this information was provided to the RP in a consistent way, and ideally in a way that the RP is likely to save by default (i.e. not purely in an extension).
3) It would be nice if all three properties were attested by the authenticator. I recognize this is probably a stretch.

I know there are historical reasons why the spec acts as it does. But it is bewildering to find out this information for an RP implementing WebAuthn the first time, and even I myself mistakenly believed for almost two years that the `create` response contains the platform authenticator status of the registration.

Quoting myself from https://github.com/w3c/webauthn/issues/1565

> This breaks ["avoid needless complexity"](https://www.w3.org/TR/html-design-principles/#avoid-needless-complexity) and — if it could be fixed in the spec —  ["priority of constituencies"](https://www.w3.org/TR/html-design-principles/#priority-of-constituencies).

> Since it looks like the spec will have at least 3 levels and level 2 is still being finalized, it is clear that browsers are still working on their WebAuthn implementations. I think it is still feasible to include a [change] at this point and hope for it to land in browsers in a reasonable time frame

Please view or discuss this issue at https://github.com/w3c/webauthn/issues/1567 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 9 February 2021 03:11:05 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 9 February 2021 03:11:05 UTC