W3C home > Mailing lists > Public > public-webauthn@w3.org > October 2017

[webauthn] Allow RPs to choose between "required" and "optional" attestation in credentials.create()

From: balfanz via GitHub <sysbot+gh@w3.org>
Date: Wed, 11 Oct 2017 19:36:31 +0000
To: public-webauthn@w3.org
Message-ID: <issues.opened-264709581-1507750576-sysbot+gh@w3.org>
balfanz has just created a new issue for https://github.com/w3c/webauthn:

== Allow RPs to choose between "required" and "optional" attestation in credentials.create() ==
TL;DR: When/if a client platform uses the Privacy CA model described in the spec, it would be beneficial for the RP to specify if they want an attestation from the Privacy CA. We should introduce an (optional) parameter in credentials.create() for this.

Details:

Some platforms/clients may opt into using Privacy CAs to address potential issues with poorly-implemented on-Authenticator attestation (e.g., small batch sizes). This does not change the syntax of the attestation, and is transparent to the RP.

What it *does* mean, however, is the following:

1. The platform may prompt the user about information being sent to the Privacy CA (since that information potentially reveals aspects about the Authenticator that the user is using)

2. Obtaining information from the Privacy CA introduces latency.

3. The Privacy CA learns certain aspects about the login to the RP, such as timing, and Authenticator used.

The RP might not wish to be exposed to these drawbacks, and not want to use a Privacy CA. In that case, a platform that normally uses a Privacy CA could instead use "self attestation" (i.e., replace the Authenticator's attestation data with client-generated self-attested attestation data). It's faster, and has no privacy concerns. 

We should give the RP an option to select between these two modes when calling credentials.create(). In one mode, the RP requests a "full" attestation, but acknowledges extra latency, potential user drop-off due to users not wanting to reveal information about their Authenticators to the Privacy CA and/or the RP, and potential leakage of some information to the Privacy CA. In the other mode, the RP signals to the client platform that they're not interested in attestation, and that the client platform should feel free to replace Authenticator attestations with a "self-attested" attestation data. (**TODO**: or should we just drop the attestation data in this case?)

Proposal:

Let's add an optional parameter `attestation` to `credentials.create`, with possible values `optional` and `required` (default being `optional`).

When the platform sees the `optional` value, it doesn't have to contact the Privacy CA, and can do whatever it sees fit to protect the user's privacy. When the value is set to `required`, then the client should ensure that the Authenticator's attestation is used to create a meaningful attestation for the RP, even if that means extra latency to contact the Privacy CA, obtaining extra consent from the user, etc.


Please view or discuss this issue at https://github.com/w3c/webauthn/issues/628 using your GitHub account
Received on Wednesday, 11 October 2017 19:36:21 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 5 July 2022 07:26:28 UTC