Enterprise Attestation Conveyance Preference

[arshadnoor]

Level-2 provides a definition for "enterprise" in the AttestationConveyancePreference. There is guidance on what the browser must do when this is specified - but its not clear what Authenticators and FIDO Servers are required to do here. Is there any document or detail on that somewhere? TIA.

[agl]

https://fidoalliance.org/specs/fido-v2.1-ps-20210615/fido-client-to-authenticator-protocol-v2.1-ps-20210615.html#sctn-feature-descriptions-enterp-attstn

The “enterprise” either causes ep=1 to be sent, or ep=2 if the browser additionally has local policy blessing the RP.

[agl]

(Closing because hopefully that answered the question? If you have further questions, please follow up here.)

[arshadnoor]

(Sorry for the delayed response @agl - just catching up to this thread).

Thanks for link. So, it seems clear what the Authenticator must do. But, is there anything a FIDO Server must do with the results sent by the Authenticator?

For example, AttestationConveyancePreference for enterprise says:

This value indicates that the Relying Party wants to receive an attestation statement that may include uniquely identifying information.

and

"... and convey the resulting AAGUID and attestation statement, unaltered, to the Relying Party.

Is the AAGUID expected to be the "uniquely identifying information"? If so, is there an expectation that the FIDO Server must match the AAGUID against a predetermined list? While business applications can choose to program anything they want to address business needs, I would expect FIDO Server responsibilities for enterprise attestation would be abstracted and defined in https://www.w3.org/TR/webauthn-2/#sctn-registering-a-new-credential - but I don't see anything different mentioned for "enterprise" attestations.

Additionally, is the attestation statement for enterprise attestations expected to be different from the ones defined in the spec?

[dwaite]

@arshadnoor I believe this alludes to how - when you strip attestations off - you can also clear the AAGUID as there is no longer anything cryptographically protecting it.

[agl]

But, is there anything a FIDO Server must do with the results sent by the Authenticator?

The enterprise attestation conveyance is for the case where an RP also controls the authenticators. E.g. a corporate environment where employees are issued authenticators for signing in. While the AAGUID is very unlikely to be uniquely identifying, the attestation statement itself is allowed to be—which is unique to the enterprise case.

Since this was designed for bespoke environments it's difficult to give rules about what they might do. Probably the attestation statement would be in a standard format, but the RP may wish to verify it against custom trust roots. They may wish to parse out bespoke parts of the attestation and check that the authenticator was issued to the account that is trying to register it etc.

[arshadnoor]

Thanks for that, Adam; I suspected that but needed clarification from the people who're defining the API.

I wish FIDO Alliance or the W3C had established - or at least, strongly recommended - a standard for the certificate profile of the Attestation certificate for enterprise attestations. Having built many bespoke PKIs in my career, I don't look forward to having to deal with custom certificate profiles with custom OIDs for attestations in different organizations. Our efforts to standardize a FIDO Server are designed to make FIDO deployments as simple and easy as possible; but when the spec is sufficiently vague to allow RPs to do what they want on the back-end, it just makes our job more difficult to make a standard solution that includes bespoke attestation certificates that might have to search for specific OIDs, attributes, etc.

What are the chances of using a unique OID chained to a private FIDO Alliance registered OID, years ago (1.3.6.1.4.1.45724) and making that a standard for enterprise attestations? RPs can put what they want in the usual DN attributes, but if they want a custom enterprise OID (as I sense some very large RPs will), they can put the child of the standard FIDO Alliance OID in their attestation certificate, and FIDO Servers can just search for specific DNs with this specific OIDs within specific truststores (or AIA extension URLs) to validate the chain? This would allow for some flexibility for RPs using enterprise attestations while enabling standardized FIDO Servers to serve many RPs?

I'm happy to create such a certificate profile as an example as long as some of the RPs that wanted this enterprise attestation confirm they're willing to use such a standard OID. If they insist on using something of their own, then they're simply making the total cost of ownership (TCO) of their FIDO deployment high by complicating life for the OAM (Operations, Administration & Maintenance) folks responsible for this infrastructure.