[Openid-specs-ab] Issue #1766: Response type `vp_token` does not stack well (openid/connect)

[Daniel Fett]

New issue 1766: Response type `vp_token` does not stack well
https://bitbucket.org/openid/connect/issues/1766/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](https://openid.net/specs/openid-4-verifiable-presentations-1_0.html#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.