OpenID4VP user flow

[woutslakhorst]

The OpenID4VP flow is meant for getting an access token for data retrieval where a user should be involved. For any medical or personal data that is retrieved the source (should) want(s) to known that a person was behind the buttons and not a machine. The OpenID4VP specification is also written with a user in mind.

The above specification only talks about the invocation of the verifier with the wallet (authorization server). For the entire flow to work the initial interaction of the client with the verifier also needs to be designed. For that part we use a 'normal' OAuth flow. The entire flow thus consists of 2 OAuth flows, an outer normal OAuth flow for getting the access token and an inner OpenID4VP flow for presenting the credentials in a presentation.

The diagram below shows this interaction.

Edit at https://www.plantuml.com/plantuml/uml/VLHBJnin4BxlhnZjeO93YA0t91vLGOYseYYKjb9LHSOx12kxdkrubj3--lf1dCrkcujb-_jcvfk7VUv4iNHDNOYH6k46PKMyX7k73EywUK8hHYinP8j2TKAsQnwG2wM56Bh0KWxAi9ceXIUNHQlOcvXMMO4NuoB-VfkUld-OXkqLE5XX6ywSV4u9Xpj8Z0wwbXZvCpM1uVyZ5mMHPGtEGqgZg6cXR5543JnLm4wXagvfmTIN0suLoIKdOTSpRCIZ4Rv59Z9tMdAv1XApHWGfJKw1q9Bj6KsIAmYPJtPM3aXHhzwIWAp3CRAC6g1-zcd62eBVoHUUTdRZ03rr5mH286kgQjWfUeQPHnRFw5UWlDg3TdfXsyV9uavLRdrMLKEpcYhqFS58pQUD0nSqh8iQg8MMcG8_VgTN8prHyjOwuO48OObDdzmo-UHJ-RoIn-DjpbaWjTe7DRN8O06HLLAr4P0ShYR3Nkf3E2wjYMMe3TgdH8l3WuEzeki85xtMYK4oNQGpAWpWvviCWscBQD3Ar7SlC97OqtOdiKfEV4AOE-HgO7_yEOTc_rHaMvxPBZ8v9WSuwyEdM05JbEBOEomt8SzJwzp_lLsfFxsyvrlLAh5l2KdPy_jF3w4e7eaYPRmOrsw-zdrp-6Sp7fbhKchElODLiOlsbFJknqCWduu2zZ9ovjKhiEZj-iSl-PZfGbC4a7HjUITLYWhI1CzYwT5Jg_hw0b5-ix-5h28EUlnLyDn8z4vUzW6wfm-rzPkrgxJjvoeFKcE-jB63tjp2x6SJONqMPpJZ_YkVVGDVLV

Parts:

• [x] #2604. 4 in the diagram
• [x] Create the cloud wallet confirm/authenticate page. 8 in the diagram. #2604
• [x] #2625
• [x] #2651
• [x] #2694
• [x] #2728
• [x] #2761
• [x] #3012
• [x] Use request_uri (see RFC9101) instead of authorize params in redirect (#2712)
• [ ] cleanup code (move methods to different files, check method signatures)

[gerardsn]

edit GS: declutter issue by hiding duplicate diagram edit WS: diagram from below replaced original diagram.

I can't comment on what is outside loop, but makes sense.

sequence diagram

I've added 18-19 to fetch the PD. This requires presentation_definition_uri to be present in the redirect in 16. The state is also from 16, or 13? (What links 13 to 18, 21, and 24?) I've also added the 21-22 to use the back channel to deliver the vp_token (+ removed vp_token from redirected response in 23-24). This requires response_mode=direct_post(.jwt?) + response_uri (in addition to redirect_uri) to be present in the redirect in 16. We probably need to wait for 22 so 24 does not arrive before it can be handled?

(plantUML url is in the image)

[reinkrul]

This only really makes sense if the verifier requires personal credentials (care professional credentials), otherwise the s2s flow (which is not a variant of OpenID4VP, since there's no user nor a browser and not OpenID) should be used.

• 5 and 9 are related to each other (9 probably uses something from 5), but "store state" is very vague
• From OAuth2 perspective the title is something like "Authorization Code with OpenID4VP"? (as OpenID4VP always has a user, so "user flow" does not add anything). Maybe add "authorization code flow" and "openid4vp" to resp. loop and alt blocks, so clearly distinct the 2 processes.
• mixed level of detail, I specifying up until every HTTP request, we're missing the retrieval of the OpenID4VP request object between 17 and 18.
• 31 position = location
• so 33 (GET access token) is sibling of 4 (create access token), client will have to provide some form of state, so the Nuts node can correlate it to the initially started authorization code flow.

[woutslakhorst]

We probably need to wait for 22 so 24 does not arrive before it can be handled?

yes, it's all synchronous so should be ok

[woutslakhorst]

The flow will be slightly different when the dialog is shown in a popup. It would require some polling from the XIS/ECD in the background.

[woutslakhorst]

request_uri discussion is still ongoing within OpenID4VP since it should be signed/encrypted but there's no way to know what crypto algs the wallet supports.

[reinkrul]

Identified work items:

• Add user details in requestUserAccessToken, which can be used in NutsEmployeeCredential (see Wiki). This must be optional: later on OpenID Connect could be supported, so the user identity will be sourced from the IDP.
• On user landing page, create user session if not exists (check cookie). Issue NutsEmployeeCredential to user session to an in-memory did:jwk. Send session cookie back to browser.
• ...

[woutslakhorst]

Identified work items:

• Add user details in requestUserAccessToken, which can be used in NutsEmployeeCredential (see Wiki). This must be optional: later on OpenID Connect could be supported, so the user identity will be sourced from the IDP.
• On user landing page, create user session if not exists (check cookie). Issue NutsEmployeeCredential to user session to an in-memory did:jwk. Send session cookie back to browser.
• ...

is already part of #2901