Skip to content

[OID4VCI] Advanced integration tests with key_attestations_required #51348

Description

@mposolda

Description

This issue is about making sure that we have integration automated tests (Integration test is test for full flow with authentication, token endpoint, credential endpoint) for the scenarios with proofs included in credential-request and with client scopes having switch key attestations required enabled. The possibilities are:

1.a) Successful scenario with the proof in jwt format where the attestation element has kid in the header. Key is looked up by kid (or eventually by alg or so) and checked against the key from trust material identity provider (possibly DefaultTrustIdentityProvider or OIDCIdentityProvider), which is configured for the client

1.b) Same like above for attestation proof

2.a) Successful scenario with the proof in jwt format where the attestation element has x5c in the header. Key is checked against the root CA configured on the identity provider (possibly DefaultTrustIdentityProvider), which is configured for the client

2.b) Same like above for attestation proof.

  1. Might be good to have some error scenarios as well when key_attestations_required is true? AFAIK we have OID4VCJWTIssuerEndpointTest.testCredentialScopeKeyAttestationRequirementRejectsMissingAttestation introduced in [OID4VCI] Make key_attestations_required configurable in Admin Console #51261 . Do we need more tests for error scenarios or is this one sufficient?

If we already have tests for scenarios 1, 2, 3, then this issue can be just closed - with pointing on the tests for the mentioned scenarios. However it looks we may not have the tests yet at least for 1 and 2?

  • Tested scenarios would be ideal to test with sd-jwt credential and might be good to make sure that there is key_binding element included in the sd-jwt credential with verification that key looks as expected and it is correct key from the proof. AFAIK this might be tested for jwt proof. Not 100% sure if key_binding is supposed to be for attestation proof as well or not?

Metadata

Metadata

Type

Projects

No projects

Milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions