You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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?
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
proofsincluded in credential-request and with client scopes having switchkey attestations requiredenabled. The possibilities are:1.a) Successful scenario with the
proofinjwtformat where the attestation element haskidin the header. Key is looked up bykid(or eventually byalgor so) and checked against the key from trust material identity provider (possiblyDefaultTrustIdentityProviderorOIDCIdentityProvider), which is configured for the client1.b) Same like above for
attestationproof2.a) Successful scenario with the
proofinjwtformat where the attestation element hasx5cin the header. Key is checked against the root CA configured on the identity provider (possiblyDefaultTrustIdentityProvider), which is configured for the client2.b) Same like above for
attestationproof.key_attestations_requiredis true? AFAIK we haveOID4VCJWTIssuerEndpointTest.testCredentialScopeKeyAttestationRequirementRejectsMissingAttestationintroduced 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?
proof. AFAIK this might be tested forjwtproof. Not 100% sure ifkey_bindingis supposed to be forattestationproof as well or not?