Problem
POST /internal/auth/v2/{subjectID}/request-credential today requires the EHR to construct an authorization_details array with OpenID4VCI internals (type: \"openid_credential\", credential_configuration_id, optional format). The EHR shouldn't need OpenID4VCI/RFC 9396 knowledge to ask for a credential, and the issuer's preferred wire form (scope vs authorization_details) is something the node can negotiate from AS metadata.
Proposal
- Hoist
credential_configuration_id (and optionally format) to the root of the request body.
authorization_details becomes optional — kept only as an escape hatch for advanced cases (full RFC 9396 control). Default flow uses the hoisted field.- Node-side dispatch on the Authorization Request, driven strictly by metadata (no probing/retry):
- AS metadata
authorization_details_types_supported contains openid_credential → put authorization_details with credential_configuration_id in the Authorization Request. Credential Request later uses credential_identifier (details-flow, per §8.2 + Token Response credential_identifiers).
- Else if issuer credential metadata's
credential_configurations_supported[<id>].scope is in AS scopes_supported → put that scope in the Authorization Request. Credential Request uses credential_configuration_id (§8.2 scope-flow branch).
- Else → omit credential identification from the Authorization Request entirely. Put
credential_configuration_id in the Credential Request body (§8.2 allows this independently of how authorization was scoped).
Branch 3 is spec-fuzzy at the AS side — §3.4 says the Authorization Request "MUST include scope or authorization_details" — so the issuer has to authorize credential issuance via some other context (pre-arranged client privileges, user identity, etc.). We expose it as a best-effort fallback and let the issuer reject if it really won't work.
Out of scope
- No changes to the OpenID4VCI wire protocol with issuers — only the internal EHR ↔ Nuts API.
Pros
- Caller surface stops leaking OpenID4VCI/RFC 9396 internals.
- Issuer-flow negotiation lives in the node, where AS metadata is fetched anyway.
- API stays stable across issuer spec drift (scope-flow ↔ details-flow ↔ credential-request-only).
Cons / open questions
authorization_details carries more than just credential_configuration_id (format, claims, locations, …). Keeping it as an escape hatch handles advanced cases; decide whether format deserves promotion to a root field.- Breaking change on an experimental API.
- Implementation cost: metadata dispatch + scope-flow path + branch-3 fallback + tests for each branch.
Problem
POST /internal/auth/v2/{subjectID}/request-credentialtoday requires the EHR to construct anauthorization_detailsarray with OpenID4VCI internals (type: \"openid_credential\",credential_configuration_id, optionalformat). The EHR shouldn't need OpenID4VCI/RFC 9396 knowledge to ask for a credential, and the issuer's preferred wire form (scope vs authorization_details) is something the node can negotiate from AS metadata.Proposal
credential_configuration_id(and optionallyformat) to the root of the request body.authorization_detailsbecomes optional — kept only as an escape hatch for advanced cases (full RFC 9396 control). Default flow uses the hoisted field.authorization_details_types_supportedcontainsopenid_credential→ putauthorization_detailswithcredential_configuration_idin the Authorization Request. Credential Request later usescredential_identifier(details-flow, per §8.2 + Token Responsecredential_identifiers).credential_configurations_supported[<id>].scopeis in ASscopes_supported→ put that scope in the Authorization Request. Credential Request usescredential_configuration_id(§8.2 scope-flow branch).credential_configuration_idin the Credential Request body (§8.2 allows this independently of how authorization was scoped).Branch 3 is spec-fuzzy at the AS side — §3.4 says the Authorization Request "MUST include scope or authorization_details" — so the issuer has to authorize credential issuance via some other context (pre-arranged client privileges, user identity, etc.). We expose it as a best-effort fallback and let the issuer reject if it really won't work.
Out of scope
Pros
Cons / open questions
authorization_detailscarries more than justcredential_configuration_id(format,claims,locations, …). Keeping it as an escape hatch handles advanced cases; decide whetherformatdeserves promotion to a root field.