Align OpenID4VCI client with implementers draft

[gerardsn]

An Implementers Draft has been released for OpenID4VCI. This is the version that will be supported for a longer time by implementing parties for interoperability and is in the DIIP profile. We should align our implementation with this version of the spec. Since the Nuts node only implement the client side for OpenID4VCI this is even more relevant.

The summary below contains the points (using spec section numbering) where the Nuts node does not comply with the spec or where additional features could simplify things. This should be fixed when we have implemented and OpenID4VCI issuer, or see if we can collaborate with a party that has a DIIP compliant issuer.

---

5 Authorization Endpoint

Recommended to use PKCE (implemented) and PAR (not implemented. mostly useful for applications (mobile wallets) without a domain to host the request_uri of a JAR).
Credentials can be requested using authorization_details and scopes.

5.1.1 request credentials using authorization_details RFC9396

Only supported option. Supported credentials are listed in the credential issuer metadata. We currently require the authorization_details to be provided by the user, meaning that the user needs to figure out the details using some out of bound method. It would be better to only provide the credential issuer and then present the user with available options, but this works for now.

• user input is not validated
• credential issuer metadata lists authorization_servers: "the authorization detail's locations common data field MUST be set to the Credential Issuer Identifier value."
• should check the credential issuer metadata if the supported methods match the capabilities of the nuts node and requester/holder.
• authorization_details is currently sent as query param in the request. Browser redirects may fail if it contains too many chars. JAR/PAR may be needed.

5.1.2 request credentials using scopes

Not implemented, but is the simplest option. This may require a change to the API we provide for credential requests.

5.1.4 Pushed Authorization requests

Recommended, but not implemented.

6 Token Endpoint

For the authorized_code flow this the request is the default per RFC6749

• Should this use DPoP?

6.1 confusing. extensions mentioned probably not relevant to the authorization_code flow

6.2 Token response

RFC6749 + some extra response params:

• missing authorization_details: REQUIRED when authorization_details parameter is used to request issuance of a certain Credential type as defined in Section 5.1.1
• credential_identifiers: using this makes for a simpler credential request when using authorization_details, but is OPTIONAL.

7 Credential Endpoint

• Should this use DPoP?

7.2 credential request

• missing some required parameters (format or credential_identifier MUST be present)
• credential issuers metadata proof_types_supported (we only support jwt) and proof_signing_alg_values_supported are not checked.
• proof issues
  • header typ MUST be openid4vci-proof+jwt (currently jwt)
  • missing REQUIRED iat
  • contains non-specced jti
  • aud == credential issuer identifier: "11.2.1 A Credential Issuer is identified by a case sensitive URL using the https scheme that contains scheme, host and, optionally, port number and path components, but no query or fragment components." Currently contains a DID, should be did:web URL.

7.3 Credential Response

• may contain transaction_id if issuer is using deferred flow. This is currently not supported, but should be detected and return an appropriate error.

11 Metadata

11.2 credential issuer metadata: /.well-known/openid-credential-issuer

For correct interpretation of the issuers's capabilities and intentions we need to add the following parameters

• credential_identifiers_supported, but only if we want to use this in §6.2
• signed_metadata OPTIONAL just for convenience as it eliminates one call in the flow if present
• credential_configurations_supported which is REQUIRED and shows the capabilities of the issuer

11.3 authorization server metadata: /.well-known/authorization-server

• pre-authorized_grant_anonymous_access_supported==true is incorrectly added to our metadata since we do not support pre-authorized_code flow

4, 8-10 Credential Offer, Batch, Deferred, and Notification Endpoints are not supported