Clarify valid response_type values

The June 22 draft of OIDC4VP says this in section 5:

response_type: REQUIRED. this parameter is defined in [RFC6749]. The possible values are determined by the response type registry established by [RFC6749]. This specification introduces the response type "vp_token". This response type asks the Authorization Server (AS) to return only a VP Token in the authorization response.

The IANA considerations in appendix B is still TBD and so the only thing in the referenced registry are token, code, and the multi-response type values.

Section 6 goes on to say:

If only vp_token is used as the response_type, the VP Token is provided in the authorization response. If the id_token is used as the response_type alongside vp_token, the VP Token is provided in the OpenID Connect authentication response along with the ID Token. In all other cases, the VP Token is provided in the token response.

The second sentence seems to be saying that response_type=id_token vp_token is valid and I've seen references to that in the issue tracker. The last sentence is harder to understand, however. Is this saying that all of the following combinations are valid or only some of them?

code vp_token
code id_token vp_token
code id_token token vp_token
code token vp_token

Those would require a call to the token endpoint to redeem the code, and the first quoted section above says that the VP token is only returned from the “authorization response” which I take to refer to section 4.1.2 or RFC 6749 (i.e., the reply from the authorize endpoint prior to calling the token endpoint in the code flow).[1] Does this mean that the above response type values are invalid or that the token endpoint should not issue a VP token?

The example in 8.2.3.1 further confuses me. This example says that the client is registering only with the code response type but it is registered with VP token formats. Does this mean that a VP token can be issued as a part of a normal code flow? If so, I suppose this is dependent on the client’s registered metadata or the AS’s policy. Is that right?

Also, what about these response types? Are these valid?

id_token token vp_token
token vp_token
none vp_token

The last one is interesting. The multi-response type spec says in section 4:

Authorization Server SHOULD NOT return an OAuth 2.0 Authorization Code, Access Token, Access Token Type, or ID Token in a successful response to the grant request

It doesn’t say anything about VP token, however, so one could interpret none vp_token as valid and meaning the same thing as a response_type of just vp_token.

Section 2 of the multi-response type spec also says:

Each Response Type value also defines a default Response Mode mechanism to be used, if no Response Mode is specified using the request parameter.

What response mode is the default for any of the above that are valid? What about a response_type of just vp_token? What is the default response mode of that? OIDC4VP defines a new response mode (post), but it doesn't say that's the default for the vp_token response type. Quoting section 6 again which says:

If only vp_token is used as the response_type, the VP Token is provided in the authorization response.

Does this mean the default response mode for response_type=vp_token is fragment? If so, it would be good to spell that out IMO.

From all this, it seems evident that the response_type values should be clarified or that I'm just too literal / daft. Not sure which it is but hope it's the former

[1] Maybe I’m being too literal, but the hybrid flow defines this as an Authentication Response and the implicit flow in RFC 6749 doesn’t use this “authorization response” wording; it’s only used for the code flow (that I found).

Comments (4)