Can you describe a concrete use case for this that is currently not possible to implement?

having an authenticator uniquely identify itself via attestation.

Yes, of course - what I meant to ask is what would be a concrete use case for that capability? In what circumstance would an RP need to know the identity of an authenticator before registering a credential with it (after which it can be identified by the credential ID)?

@agl Need more info on why we need to do this

I'm particularly interested in whether it would be OK if such a feature were gated on a group policy for "enterprise mode" -- Firefox, for example, gates enterprise PKI features on the pref security.enterprise_roots.enabled being set. So if we supported this, could we make it a thing that isn't generally for consumers but instead for enterprises?

on 27-Feb-2019, @christiaanbrand replied in email rather than here:

MS made a case for not doing that. The idea was:

1. Token contains some blob which says "for which" RPs individual
   attestation might be required
2. Upon registration, token sends blob to browser. Browser interprets it.
   Might show additional UI telling user what they're about to do.
3. If browser is happy, it'll set the "ep" bit in CTAP.

Maybe we want that in conjunction with the "EP" flag in WebAuthn too.
Dunno. We have a use case where for the same RPID, sometime we want ep, and
sometimes we don't.

@leshi to come back with validation of this or other proposals

@agl reports on call 20-mar-2019 that unique/individual attestation approach is preferred by enterprises rather than the pre-registration approach. Leave open as this is firmed up in CTAP2-land.

I'm a bit confused as to the purpose still. Is this meant to be a way for organizations to do some subset of:

1. attest that an authenticator was supplied by them
2. attest that an authenticator is co-located on a platform managed by them
3. allow for an organization to associate additional attributes with authenticators supplied/managed by them
4. retrieve a unique identity of an authenticator (aka serial #)
5. short circuit the user user consent within zones configured by policy on the client platform
6. represent the concept of an organization's zone (as sanctioned RPIDs) within a supplied/managed authenticator

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.
2. 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.

This issue is pending "config management" PR in FIDO land

@agl to create PR