[has-PR] Static metadata for the authz server

[David W Chadwick]

Currently there is no simple way for the RP to determine the endpoint of the authorization server that is protecting the wallet when the same device flow is used in OIDC4VPs (and when SIOPv2 is not being used. When SIOPv2 is being used the meta data has been defined). It is proposed that we define the static metadata for the authorization server analagous to the way that Static Self-Issued OpenID Provider Discovery Metadata has been defined in the SIOPv2 spec.

It is proposed that the static metadata might look something like this

{
"authorization_endpoint": "oidc4vps:",
"response_types_supported": [
"vp_token"
],
"presentation_definitions_types_supported": [
"presentation_definition_uri"
],
"presentation_submission_locations_supported": [
"separate_response_parameter"
],
"vp_formats_supported": [
"jwt_vp"
],
"vc_formats_supported": [
"jwt_vc"
],
"vp_signing_alg_values_supported": [
"ES256"
],
"vc_signing_alg_values_supported": [
"ES256"
]
}

[David W Chadwick]

One issue that will need to be resolved (in the absence of dynamic metadata discovery) when static metadata is being used, is how can the RP determine whether the wallet supports OIDC4VPs on its own, or supports OIDC4VPs in conjunction with SIOPv2, or SIOPv2 on its own. i.e. should the endpoint be "oidc4vps:" or "openid:".

The only solution I can think of (in the absence of any pre-configured knowledge) is to let the RP try either endpoint, and it will get an error if the wallet does not support the one it has chosen. It can then use the other endpoint.

Note that "oidc4vps:" will return a vp_token whilst "openid:" will return an id_token.

‌

[David W Chadwick]

The alternative to defining an alternative authz endpoint is to use the same wallet endpoint for both SIOPv2 and Authz and for the requested token type to be the determinant. i.e. if a vp_token is requested then it the Authz server that the request should be directed to, and if it is id_token then it is SIOPv2 that the request should be directed to.

[Kristina Yasuda]

“presentation_definitions_types_supported”, “presentation_submission_locations_supported", “vc_formats_supported“, “vp/vc_signing_alg_values_supported“, etc. are not parameters standardized in the specification.

[Kristina Yasuda]

This specification being decoupled from credential formats, I am reluctant to add vp_formats_supported: jwt_vp and jwt_vc, but guess we have to since otherwise this static metadata will not be helpful.

[Kristina Yasuda]

vp_signing_alg_values_supported is currently not defines, but might be worth exploring adding this server metadata

[Kristina Yasuda]

Aug 11 SIOP call discussed to move to appendix/implementation considerations - PR updated

[Kristina Yasuda]

an example from Mike on MTI features adopted in OIDC Core Final: OpenID Connect Core 1.0 incorporating errata set 1

[David W Chadwick]

Most of the metadata items mentioned in this issue have now been addressed in PR #265 apart from those that specify presentation definition items. The OIDC4VP AS server has two CONDITIONAL choices for receiving PDs, and two choices for returning presentation submissions. Therefore we should indicate which is the preferred choice for each one in this metadata.

The presentation definition can be transferred by value or by reference.

The presentation submission can be inserted into the VP or be a separate response parameter along with the vp_token.

Since many RPs can point to the same PD by reference, this option should be chosen as it makes the RP implementation simpler.

Since some credential syntaxes e.g. mDL are not able to insert the PS into the VP, then the separate response parameter option should be chosen.

[Kristina Yasuda]

PR merged