Introduce a configuration option to enforce the use of key_attestation

[babisRoutis]

According to HAIP v1 and ETSI TS 119 472-3, proofs of type jwt cannot be used, unless they include a key_attestation and signed with the first of the attested keys (found in the key_attestation).

This means that the wallet for device-bound attestations must use either:

• Proof of type attestation
• Proof of type jwt + key_attestation

That is, Proof of type jwt (without key_attestation) is not allowed

In addition, HAIP v1 allows issuance of non-device-bound attestations, where Proofs are not used, but to my knowledge this is not included in the ETSI TS 119 472-3.

The above rules are not being taken into account by the present library when processing a credential offer.
Library should reject a credential configurations that require Proof of type jwt without key_attestation

For this reason we should

• Introduce a new option to allow caller define its policy with regards to device-bound attestations.This could be a data class describing the algorithms supported for signing the KA and/or the Proof of type JWT+KA.

• Depending on the option, library should validate the credential configuration.

[babisRoutis]

An update:

The configuration should provide the following options:

• To support (or not) issuance with no Proofs. This could be a boolean flag named allowNonDeviceBound with default value false
• To support (or not) issuance with JWT Proofs (simple with key_attestation). Again this can be a boolean value with default false
• How to support proofs with key attestations

The later could be a data class with two attributes

• SupportedSigningAlgorithms : A non-empty list of JOSE sign algorithms
• an enumerated value JwtProofWithKA and/or AttestationProof

That is the caller would have to specify a single way to provide proofs for attested keys.

Indicative

data class ProofRequirements(
   val enableNonDeviceBound : Boolean = false,
   val enableJwtProofsWithoutKA: Boolean = false,
   val deviceBoundRequirements: DeviceBoundRequirements?
  )

data class DeviceBoundRequirements(
   val algs: List<String>,
   val deviceBoundProof:  DeviceBoundProof
)

enum class DeviceBoundProof {  JwtProofWithKA, AttestationProof }

As an alternative, we can introduce three distinct uses

sealed interface ProofRequirments {
   data object NonDeviceBound: ProofRequirments
   data class JwtProofsWithoutKA(val algs: List<String): ProofRequirments
   data class DeviceBound(val algs: List<String>, type: DeviceBoundProof): ProofRequirments
}

In this variant, caller is forced to choose a single behavior