W3C home > Mailing lists > Public > public-webauthn@w3.org > April 2019

Re: [webauthn] add notion of "enterprise" attestation (#1147)

From: Adam Langley via GitHub <sysbot+gh@w3.org>
Date: Sat, 27 Apr 2019 16:58:14 +0000
To: public-webauthn@w3.org
Message-ID: <issue_comment.created-487302407-1556384293-sysbot+gh@w3.org>
> I'm a bit confused as to the purpose still.

Roughly: batch attestation is too strong for consumer uses and too weak for enterprise cases.

Enterprises want:

1. Stronger identity assurance than is provided by batch attestations.
1. Individual asset tracking.

The individual attestation certificates, in U2F devices that support them, are based on the private key that's established in the trusted factory that makes the chips. When these chips are made it's not predetermined what device they'll end up in, and only a fraction are destined for security keys. But, by basing the individual attestation on that initial identity, the chain of trust can be rooted at manufacture time.

Preregistration of credentials has been suggested as a solution but the location that puts FIDO firmware on the chip and packages it up into a security key may not be so trusted. Since preregistration is a FIDO concept, that means that the trust doesn't stretch as far.

Perhaps the preregistered credential could also be based on that initial identity? But then we lose flexibility: one can challenge the preregistered credential, but trust can never be extended to any other credentials as attestation can do. So we would depend on never needing extra credentials to be trusted (which fails once we start looking at including SSH), and that the RP ID for a customer never change (which is a large assumption).

Enterprises also want to bypass any permissions prompts for their internal registrations, but that's a user agent-specific concern.

GitHub Notification of comment by agl
Please view or discuss this issue at https://github.com/w3c/webauthn/issues/1147#issuecomment-487302407 using your GitHub account
Received on Saturday, 27 April 2019 16:58:16 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:59:04 UTC