Credential/Callback Endpoints lacking the information about the user session

[Sakurann]

there is an issuer_state parameter that can be passed in the Credential Offer to be used in the authorization code flow that the wallet is required to include in the authorization request when received.

It's functionality is somewhat similar to that of pre_authorization code. Torsten reminded me that the original use-case to add this parameter was: " if the user logs in prior to receiving a credential offer, when receiving issuer_state, the AS can offer an SSO experience while ensuring it is the same user. In cross device session, issuer_state can also be used to allow the AS to force login with the same identity.

In our implementation, there is also a need for the Credential Issuer to know the original session of the user because the issuer maybe issuing multiple credentials of the same type to different users and the Issuer need to know the original user session. Suggested way forward is to ask the wallet to pass the issuer_state in the credential request (in addition to the authorization request), when isser_state was received in the credential offer. Feedback appreciated!

[tlodderstedt]

Passing the issuer_state and an access token (which was issued based on the data in issuer_state) create raise conditions. The issuer_state might not match what was passed on the authorization request.
In my opinion, if the issuer needs to know data from the issuer_state, the AS should put them into the access token.

[peppelinux]

@tlodderstedt It makes sense, however the current specs doesn't require the access token in JWT format

[jogu]

It makes sense, however the current specs doesn't require the access token in JWT format

I presume Torsten meant either by value (e.g. JWT format) or by reference (e.g. accessible via token introspection).

I tend to agree with Torsten - if the Credential Issuer needs details that were passed originally to the authorization server then these should be made available (we don't need to say how) to the credential issuer by the authorization server - in the same way (in traditional OAuth) the AS has to convey to the RS what scopes were granted, for what user, etc.

Asking the wallet to pass issuer_state again raises all kinds of difficult questions (and potential security holes) about what should happen if the issuer_state passed to the credential issuer differs to the one passed to the authorization server.

[Sakurann]

Let me take a step back because I think me using the term issuer_state and jumping to a suggested solution caused confusion.

The problem we face is Credential Endpoint lacking the information about the user session that led to the generation of a Credential Offer. For example, when multiple credentials are being issued to the same user account but on different devices/browsers; or when copies of same credential (same type/format/schema) are being issued to the different user accounts. The information to differentiate these is opaque to the AS and cannot go into the Access token. It's close to a state generated by the service/RS that is opaque to the AS.

so the idea might be closer to something like a new user_session top-level claim in the credential offer that is agnostic to the grant type that is passed back to the Credential Endpoint as opposed to reusing the current authorization_code.issuer_state credential offer parameter.

[jogu]

The problem we face is Credential Endpoint lacking the information about the user session that led to the generation of a Credential Offer. For example, when multiple credentials are being issued to the same user account but on different devices/browsers; or when copies of same credential (same type/format/schema) are being issued to the different user accounts. The information to differentiate these is opaque to the AS and cannot go into the Access token. It's close to a state generated by the service/RS that is opaque to the AS.

I'm not sure these values can be opaque to the AS - if they're opaque to the AS how does the AS obtain user consent for the particular credential to be issued to this wallet?

I don't see how we can get away from the access token being used for the user session binding. If we rely on the client to tell the RS what credential needs to be issued then we open up the possibility for an attacker to ask for a credential that wasn't the one the user authorised the release of to this session?

[Sakurann]

if they're opaque to the AS how does the AS obtain user consent for the particular credential to be issued to this wallet?

using scopes. AS knows what consent to by looking at the scope value.

I don't see how we can get away from the access token being used for the user session binding. If we rely on the client to tell the RS what credential needs to be issued then we open up the possibility for an attacker to ask for a credential that wasn't the one the user authorised the release of to this session?

user_session does not tell RS what to issue. RS relies only on the access token for that.

[Sakurann]

the information that would go into into user_session is only about the browser session of the user, so that when the issuer finishes the issuance (sending credential response and optionally receiving a callback), it knows which browser session to update.

there could be multiple credentials of the same format/type being issued at the same time or same user having multiple issuance sessions for different credentials (on different devices or something), etc.

We are extending AS in production to be used in VCI authorization code flow, and there is no possibility to add additional parameters in the Access Tokens that AS already mints.
and besides it feels dangerous putting an information received from the wallet in the authorization_request (like current issuer_state) into the Access Token. and it also feels wrong to put a browser session into the Access Token

so to be transparent, we would like to return this user_session as a callback_id in the credential response because we need it at the callback endpoint, so that the backend can notify the frontend to refresh user experience with "Credential successfully issued!! here are next steps!!" or something

[Sakurann]

Discussed at IIW with @tlodderstedt @jogu @decentralgabe and others. I renamed the issue, because in the course of discussions, it boiled down to the Callback Endpoint being able to receive information about the user session that resulted in the Credential Offer, so that the Issuer backend can communicate that to its frontend after receiving a callback.

Current proposal would be to define a new parameter callback_session (placeholder name) in the Credential Offer, that the Wallet must pass in the callback alognside callback_ids. I can modify PR #70 accordingly if this sounds ok.

[Sakurann]

we talked internally with our engineers and for audit/logging purposes (e.g. to be able to know tie the sessions and the credential issuance), credential endpoint receiving callback_session in the credential request is important in addition to callback endpoint.

(apologies for changing the issuer title back end forth... this one is the final I believe)