Response type `vp_token` does not stack well

[Daniel Fett]

The spec currently says:

This specification can be used with all response types as defined in the registry established by [RFC6749].

However, the response type is somewhat underdefined right now and does not stack well with other response types.

E.g., in Section 6.1, there is the following text:

* If the response type value is vp_token or vp_token id_token, the vp_token is provided in the authorization response.

* In all other cases, such as when response type is code, and if the parameter presentation_definition is present in the authorization request, the vp_token is provided in the Token Response.

This definition means that when using vp_token code, for example, there is no vp token in the front channel. I assume that that is not the intention here.

Another example is in Section 6.2, where the text says

When response type is `vp_token`, response consists of the following parameters:

This rules out any other response parameters, for example an authorization code or an iss parameter.

There is also no description of what a token response containing a VP Token looks like.

I’ll file PR to attempt to address these issues.

[Daniel Fett]

A definition similar to the one for ID Tokens in OIDC means that two VP Tokens can be returned in one flow (responsee type code vp_token). My PR will allow for this. If that is not desired, we need to introduce a new rule to avoid that.

[Brian Campbell]

(While acknowledging that response types are pretty weird if you look closely) I’d suggest that consistency with the way other response type values work/stack would be preferable. So +1 to what it sounds like Dr. Fett’s PR will do.

‌

[Kristina Yasuda]

does not stack well with other response types

probably because anything other than vp_token, vp_token id_token, code are de facto not allowed.

My initial reaction is not to allow returning VP Token in both Authorization and Token Response.

[Kristina Yasuda]

Brian, what is so weird and inconsistent about response types vp_token, vp_token id_token, code ?

[Brian Campbell]

The weirdness I was trying to acknowledge is the original way OAuth defined response type extensibility https://www.rfc-editor.org/rfc/rfc6749?#section-8.4 because it’s a little different than what my intuition (and others too I suspect) would expect.

The consistency comment was reacting to Daniel’s statement that “when using vp_token code, for example, there is no vp token in the front channel.” Consistency-wise, the vp token would be in the front channel anytime there’s a vp_token in the response type. But if vp_token code isn’t allowed, then it’s moot.

‌

‌

‌

‌

‌

[Kristina Yasuda]

SIOP Jan-13 2023 call, recommendation would be to have a table or something to clairfy allowed response types. also no objection that code vp_token response type combination is not allowed.

[Takahiko Kawasaki]

The specification mentions only two combinations, namely, vp_token and vp_token id_token. However, I’m wondering how implementations behave when one of the following combinations is used as the value of the response_type request parameter.

1. vp_token code
2. vp_token token
3. vp_token code id_token
4. vp_token code token
5. vp_token code id_token token

Should implementations accept these combinations or reject them?

[Kristina Yasuda]

PR merged

[Kristina Yasuda]

@Takahiko Kawasaki the updated spec text says: The behavior with respect to the VP Token is unspecified for any other individual Response Type value, or a combination of Response Type values. Until combinations 1-5 get defined somewhere, implementations should reject them.