Could you name the test module(s) that this fixes. Perhaps also worth mentioning the conformance suite git rev that you are using.

Could you name the test module(s) that this fixes. Perhaps also worth mentioning the conformance suite git rev that you are using.

This addresses oid4vci-1_0-issuer-happy-flow.

We validated against conformance-suite master after merge of MR : https://gitlab.com/openid/conformance-suite/-/merge_requests/1904

Observed suite build during validation: 5.1.41.

Yes, oid4vci-1_0-issuer-happy-flow passes in both variations

• vci_credential_encryption=encrypted
• vci_credential_encryption=plain

with keycloak/suite master (as of now)

Yes, oid4vci-1_0-issuer-happy-flow passes in both variations

• vci_credential_encryption=encrypted
• vci_credential_encryption=plain

with keycloak/suite master (as of now)

Perfect, please also notice it solves this issue raised #46274.
Will need your feedback with respect to that and spec alignment too

Will need your feedback with respect to that and spec alignment too

sure, what do you need? It was probably fixed by this #47674
generally, everything I fixed is referenced from #47149

Will need your feedback with respect to that and spec alignment too

sure, what do you need? It was probably fixed by this #47674

Probably but you see we have extra checks inlcuded which are spec aligned and should definitely handle and close this issue #46274

Unreported flaky test detected

If the flaky tests below are affected by the changes, please review and update the changes accordingly. Otherwise, a maintainer should report the flaky tests prior to merging the PR.

org.keycloak.testsuite.authz.PolicyEvaluationTest#

Keycloak CI - Base IT (3)

org.opentest4j.AssertionFailedError: expected: <PERMIT> but was: <null>
	at org.junit.jupiter.api.AssertionFailureBuilder.build(AssertionFailureBuilder.java:151)
	at org.junit.jupiter.api.AssertionFailureBuilder.buildAndThrow(AssertionFailureBuilder.java:132)
	at org.junit.jupiter.api.AssertEquals.failNotEqual(AssertEquals.java:197)
	at org.junit.jupiter.api.AssertEquals.assertEquals(AssertEquals.java:182)
...

org.opentest4j.AssertionFailedError: expected: <PERMIT> but was: <null>
	at org.junit.jupiter.api.AssertionFailureBuilder.build(AssertionFailureBuilder.java:151)
	at org.junit.jupiter.api.AssertionFailureBuilder.buildAndThrow(AssertionFailureBuilder.java:132)
	at org.junit.jupiter.api.AssertEquals.failNotEqual(AssertEquals.java:197)
	at org.junit.jupiter.api.AssertEquals.assertEquals(AssertEquals.java:182)
...

org.opentest4j.AssertionFailedError: expected: <PERMIT> but was: <null>
	at org.junit.jupiter.api.AssertionFailureBuilder.build(AssertionFailureBuilder.java:151)
	at org.junit.jupiter.api.AssertionFailureBuilder.buildAndThrow(AssertionFailureBuilder.java:132)
	at org.junit.jupiter.api.AssertEquals.failNotEqual(AssertEquals.java:197)
	at org.junit.jupiter.api.AssertEquals.assertEquals(AssertEquals.java:182)
...

Report flaky test

@forkimenjeckayang @tdiesler Thanks for the PR and review and additional comments.

Added few comments inline. Can you check them? Besides that, few other points:

1. The admin console UI is unsynced after those changes. There is single attribute in the UI Require Encryption , which has tooltips mentioning request encryptions (which is not the case with your changes, as it is effectively changed to the "response encryption"). Is it possible to update UI to have Require Request Encryption and Require Response Encryption and update the tooltips accordingly? Also I hope that additional attribute for the "Signature" will not be needed (otherwise will be good to re-add that to the UI as well, but hopefully not...)
2. Nitpick: Is it possible to rename method OID4VCIssuerWellKnownProvider.buildJwks maybe to something like buildJwksForEncryption ? So it is a bit more clear that it is intended for encryption
3. It seems that when require request encryption is configured to true, it is not enforced at the credential-request that credential request is really encrypted? Per my understanding, if encryption is required for the request, we should reject credential request to the credential-endpoint in case that it is not encrypted. Is it correct? Feel free to do this point as a follow-up if you prefer (as I guess it may need some additional tests etc)

Thank you for taking out time to review @mposolda
All comments addressed. Please have another look when you are chanced

Besides that: It can be good that there is built-in support for encrypted requests/responses in the OAuthClient/OID4VCClient framework, so that OID4VCIssuerEndpointEncryptionTest does not need to directly use Apache HTTP client. But that might be OK to do as a follow-up, so that this PR can be merged asap.

Thank you @mposolda , I created a follow up PR #48462 from this branch. to address this.
Once this is merged will rebase . Please take a look when chanced.