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

[ Note, fyi: we are concurrently using several names for essentially the same thing: [Privacy CA](https://www.w3.org/TR/2017/WD-webauthn-20170811/#privacy-ca), [Attestation CA](https://github.com/w3c/webauthn/issues/610) (see issue #610), [Attestation Proxy](https://github.com/w3c/webauthn/issues/628#issuecomment-335965456), [Blinding proxy](https://github.com/w3c/webauthn/issues/628#issuecomment-336202354), I'm going to use Attestation Proxy here. ]

@balfanz originally wrote in https://github.com/w3c/webauthn/issues/628#issue-264709581:
> When/if a client platform uses the Privacy CA model described in the spec [...]
> Some platforms/clients may opt into using Privacy CAs to address potential issues with poorly-implemented on-Authenticator attestation (e.g., small batch sizes [1]).

And further added in https://github.com/w3c/webauthn/issues/628#issuecomment-336191537:
> Using a Privacy CA (aka "attestation proxy") is not a change to webauthn. The spec already calls that out as a possible model.

With regard to the above claims/obervations:
* We originally included the [Privacy CA](https://www.w3.org/TR/2017/WD-webauthn-20170811/#privacy-ca) [attestation type](https://www.w3.org/TR/2017/WD-webauthn-20170811/#attestation-type) in the [webauthn spec](https://www.w3.org/TR/2017/WD-webauthn-20170811/) in anticipation of some **_authenticators_** being based on Trusted Platform Modules (TPMs), and to accommodate the possibility of vendors of such TPM-based authenticators wishing to employ the Attestation CA (nee Privacy CA) approach to attestation trust model. 
* The Attestation CA approach, as defined in the TPM specs (cf. [TPM-Rev-2.0-Part-1-Architecture-01.38](https://trustedcomputinggroup.org/wp-content/uploads/TPM-Rev-2.0-Part-1-Architecture-01.38.pdf)), is described as being implemented by the TPM itself, _not_ (AFAICT) as something the host platform would impose on authenticators regardless of the attestation said authenticators actually employ. 

**Thus it seems that the claim above that imposing an attestation proxy "is not a change to webauthn" is quite debatable**: i.e., our original design and intention was that authenticator attestation is a matter between the authenticator and the Webauthn Relying Party (RP), and _**if an authenticator chose**_ to utilize the Attestation proxy approach, it would be up to RPs whether to honor that authenticator or not. 

@balfanz [continues in the original post (OP)](https://github.com/w3c/webauthn/issues/628#issue-264709581) by listing some "disadvantages" to RPs and users of the Attestation CA approach, and then stating:
> 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).

Note that the above-described platform-imposed "self-attestation" would "_replace the Authenticator's attestation data_ with client-generated self-attested attestation data."

So, in summary, both options in this proposal "blinds" RPs to authenticator-generated attestation. As @ve7jtb (John Bradley)[notes above](https://github.com/w3c/webauthn/issues/628#issuecomment-336172682), this "effectively mak[es] multiple authenticators look like a single logical one from a attestation point of view."

We have concerns with such an approach:
1. While not worrying about attestation may be viable for the "long tail" of web applications/sites, various high-value websites (notably "financials") are regulated in various fashions and may need to have certain features in their user authentication processes in order to satisfy regulators, including access to authenticator-generated attestation data (as @ve7jtb (John Bradley) [also notes above](https://github.com/w3c/webauthn/issues/628#issuecomment-336202354)). 
2. A browser-vendor operated attestation proxy infrastructure is implied here, it seems. There are many implications; perhaps the most important being that if this approach is not adopted by all browser vendors, then the ecosystem will be fragmented. @akshayku [has very good questions regarding this](https://github.com/w3c/webauthn/pull/636#issuecomment-337391010) over in the accompanying PR #636. Also, it has been mentioned that at least one browser vendor may simply impose the Attestation Proxy approach in all cases, if this proposal is not adopted (e.g., PR #636), which would itself cause ecosystem fragmentation. 
3. There is no detailed specification for this attestation proxy protocol (discussions with @balfanz indicate it is imagined as being similar to, but not the same as, that specified by the TCG). Thus baking reliance on it into the webauthn spec at this time seems premature on this point alone. 
4. Both this issue and PR #636 do not address whether [ECDAA-based attestation](https://www.w3.org/TR/2017/WD-webauthn-20170811/#elliptic-curve-based-direct-anonymous-attestation) is a viable alternative approach. We have heard some arguments that ECDAA will suffer from the "small anonymity set" issues that it is alleged that [Basic Attestation](https://www.w3.org/TR/2017/WD-webauthn-20170811/#basic-attestation) (aka "batch attestation") suffers from. 
5. As @ve7jtb [notes](https://github.com/w3c/webauthn/issues/628#issuecomment-336172682): "It seems to me that this is a policy / adoption / marketing issue that has become a technical one. I don't know if this is the group that should be making that particular decision?"

Over in PR #636, @agl argues that "if many RPs all come up with their own policies for which tokens to accept and which to reject, we risk fragmenting the user experience." 

It sounds to me like there's risk of fragmenting the ecosystem and user experience with any and all of the options that are being presently proposed. 

I think if we make any changes to the status quo at this (late) time, that it needs allow RPs to opt to receive so-called direct attestation, and thus oppose this proposal as-written. 

=JeffH

[1] it is alleged that testing of various available authenticators has revealed evidence of "small batch sizes", aka "small anonymity set sizes". 




-- 
GitHub Notification of comment by equalsJeffH
Please view or discuss this issue at https://github.com/w3c/webauthn/issues/628#issuecomment-337662680 using your GitHub account

Received on Wednesday, 18 October 2017 17:16:36 UTC