search

EWC-consortium / ewc-wallet-conformance-backend

This is the EWC Interoperability Test Bed (ITB) and implements the conformance towards EWC RFCs; build towards the Large Scale Pilot (LSP) usecases. The project is co-funded by the European Union.
3 stars 1 forks source link

Client id scheme "redirect_uri" used with signed request object #12

Open astrom-b opened 3 months ago

astrom-b commented 3 months ago

Hi,

In utils/cryptoUtils.js the function buildVpRequestJwt sets up a signed JWT request object with a client id scheme of "redirect_uri". This is not allowed according to the standard.

From OpenID4VP draft 20:

redirect_uri: This value indicates that the Verifier's redirect URI is also the value of the Client Identifier. In this case, the Authorization Request MUST NOT be signed

endimion commented 2 months ago

Hey sorry for getting so long to get to this. This pull request should fix it. However, I think it is best not to merge until after pilots are completed (just so we are certain nothing breaks)

lalc commented 1 month ago

Next time we can formally release it similar to how we did for RFCs. This way, implementors can always adopt a compatible release. Also we needn't wait for correction merges.

astrom-b commented 1 month ago

No problem. I haven't had the time to look at the change yet myself.

astrom-b commented 1 month ago

@endimion The proposed fix in the "issue#12" branch doesn't completely fix the problem because the request parameter is still present. I get the following:

http://localhost:8080?state=undefined&client_id=abc&redirect_uri=http://localhost:3000/direct_post_vci&response_type=id_token&response_mode=direct_post&scope=openid&nonce=undefined&request=[object%20Object]

Observe that the request param has the value [object Object].

astrom-b commented 1 month ago

Another thing to note here is that the response_uri for direct_post is mistakenly set in the redirect_uri parameter. Should I report this separately?