Attestation conveyance is the way in which SKFS requires the attestation to be created. Any combination of the following may be chosen. It might beneficial to only allow a subset of conveyances to guarantee a certain level of security or to guarantee such functionality and maintain anonymity. By having all conveyances present in this option it allows for the largest number of possible registration options, but sacrifices control over the registration process.

Allowed values:

• none: SKFS does not want an attestation to be sent. By having this conveyance present it signifies that SKFS will accept if the RP does not return an attestation during registration. This option nullifies the security given by the attestation, so it is not recommended unless the alternative registration response format has been thoroughly understood and trusted.
• indirect: SKFS prefers receiving Authenticator generated attestation statement but can use anonymization CA generated attestation statement. By allowing this option it gives the RP the ability to generate the attestation while maintaining the user’s anonymity. This could be useful if maintaining the privacy of personal data is of top priority.
• direct: SKFS expects to receive an attestation generated by the Authenticator. This is the most recommended option because it ensures all the expected functionality of the attestation. Since the attestation is created directly by the Authenticator and then processed by SKFS, only two parties must be trusted. This is different from the indirect option. Using an indirect conveyance requires the process to trust the RP and a separate Certificate Authority along with the authenticator and FIDO2 Server; with the direct attestation it ensures that all expected FIDO2 functionality is preserved.
• enterprise: Signifies the use of uniquely identifying information in the attestation. This option is intended for use in a controlled deployment within an organization to tie registration to specific authenticators.