From 83338b326e85b662fc09c98bf06f59a22ced32f4 Mon Sep 17 00:00:00 2001 From: Micha Kraus Date: Wed, 18 Mar 2026 14:47:14 +0100 Subject: [PATCH 01/10] add text from issue --- ...penid-4-verifiable-credential-issuance-1_1.md | 16 +++++++++++++--- 1 file changed, 13 insertions(+), 3 deletions(-) diff --git a/1.1/openid-4-verifiable-credential-issuance-1_1.md b/1.1/openid-4-verifiable-credential-issuance-1_1.md index 4b61753e..376cab5b 100644 --- a/1.1/openid-4-verifiable-credential-issuance-1_1.md +++ b/1.1/openid-4-verifiable-credential-issuance-1_1.md @@ -1384,6 +1384,7 @@ The following parameters are used in the JSON-encoded Credential Response body: * `transaction_id`: OPTIONAL. String identifying a Deferred Issuance transaction. This parameter is contained in the response if the Credential Issuer cannot immediately issue the Credential. The value is subsequently used to obtain the respective Credential with the Deferred Credential Endpoint (see (#deferred-credential-issuance)). It MUST not be used if the `credentials` parameter is present. It MUST be invalidated after the Credential for which it was meant has been obtained by the Wallet. * `interval`: REQUIRED if `transaction_id` is present. Contains a positive number that represents the minimum amount of time in seconds that the Wallet SHOULD wait after receiving the response before sending a new request to the Deferred Credential Endpoint. It MUST NOT be used if the `credentials` parameter is present. * `notification_id`: OPTIONAL. String identifying one or more Credentials issued in one Credential Response. It MUST be included in the Notification Request as defined in (#notification). It MUST not be used if the `credentials` parameter is not present. +* `redirect_uri`: OPTIONAL. String containing a URI. When this parameter is present, the Wallet SHOULD give the user the option to redirect the user agent to this URI once the wallet issuance is completed, been deferred or failed. This allows the Issuer to continue the interaction with the End-User. If the Wallet sends multiple consecutive Credential Requests and receives multiple `redirect_uri` values, the Wallet SHOULD at least provide the option to redirect at the end to one of the received `redirect_uri` addresses at the end. See implementing considerations in (#redirect-uri-ambiguity) to resolve ambiguity. Additional Credential Response parameters MAY be defined and used. The Wallet MUST ignore any unrecognized parameters. @@ -1422,7 +1423,7 @@ Content-Type: application/json } ``` -Below is a non-normative example of a Credential Response in a deferred flow: +Below is a non-normative example of a Credential Response in a deferred flow with `redirect_uri`: ``` HTTP/1.1 202 Accepted @@ -1431,7 +1432,8 @@ Cache-Control: no-store { "transaction_id": "8xLOxBtZp8", - "interval" : 3600 + "interval" : 3600, + "redirect_uri" : "https://server.example.com/deferred-landing?id=a2e1bda3-cf2a-4e3e" } ``` @@ -1458,6 +1460,7 @@ If the Wallet is requesting the issuance of a Credential that is not supported b * `invalid_encryption_parameters`: This error occurs when the encryption parameters in the Credential Request are either invalid or missing. In the latter case, it indicates that the Credential Issuer requires the Credential Response to be sent encrypted, but the Credential Request does not contain the necessary encryption parameters. * `credential_request_denied`: The Credential Request has not been accepted by the Credential Issuer. The Wallet SHOULD treat this error as unrecoverable, meaning if received from a Credential Issuer the Credential cannot be issued. * `error_description`: OPTIONAL. The `error_description` parameter MUST be a human-readable ASCII [@!USASCII] text, providing any additional information used to assist the Client implementers in understanding the occurred error. The values for the `error_description` parameter MUST NOT include characters outside the set `%x20-21 / %x23-5B / %x5D-7E`. +* `redirect_uri`: OPTIONAL. as defined in (#credential-response) The usage of these parameters takes precedence over the `invalid_request` parameter defined in (#authorization-errors), since they provide more details about the errors. @@ -1525,7 +1528,7 @@ A Deferred Credential Response may either contain the requested Credentials or f * If the Credential Issuer is able to issue the requested Credentials, the Deferred Credential Response MUST use the `credentials` parameter as defined in (#credential-response) and MUST respond with the HTTP status code 200 (see Section 15.3.3 of [@!RFC9110]). * If the Credential Issuer still requires more time, the Deferred Credential Response MUST use the `interval` and `transaction_id` parameters as defined in (#credential-response) and it MUST respond with the HTTP status code 202 (see Section 15.3.3 of [@!RFC9110]). The value of `transaction_id` MUST be same as the value of `transaction_id` in the Deferred Credential Request. -The Deferred Credential Response MAY use the `notification_id` parameter as defined in (#credential-response). +The Deferred Credential Response MAY use the parameters `notification_id` and `redirect_uri` as defined in (#credential-response). Additional Deferred Credential Response parameters MAY be defined and used. The Wallet MUST ignore any unrecognized parameters. @@ -1573,6 +1576,8 @@ The following additional error code is specified in addition to those already de * `invalid_transaction_id`: The Deferred Credential Request contains an invalid `transaction_id`. This error occurs when the `transaction_id` was not issued by the respective Credential Issuer or it was already used to obtain a Credential. +The Deferred Credential Error Response MAY use the parameter `redirect_uri` as defined in (#credential-response). + This is a non-normative example of a Deferred Credential Error Response: ``` @@ -2027,6 +2032,11 @@ Implementers should be aware that this specification uses several specifications While breaking changes to the specifications referenced in this specification are not expected, should they occur, OpenID4VCI implementations should continue to use the specifically referenced versions above in preference to the final versions, unless updated by a profile or new version of this specification. +## Redirect Uri Ambiguity {#redirect-uri-ambiguity} + +To resolve redirect_uri ambiguity in multi-credential issuance flows the Credential Issuer should use the same `redirect_uri` for all requests with the same Access Token, or should consider to breaking the flow in several single-credential issuance flows instead. The Credential Issuer should not rely on the user opens `redirect_uri`. + + # Privacy Considerations When [@!RFC9396] is used, the Privacy Considerations of that specification also apply. From 4518944c22067275088111e3e95c1760acfb6fd7 Mon Sep 17 00:00:00 2001 From: Micha Kraus Date: Wed, 18 Mar 2026 15:32:17 +0100 Subject: [PATCH 02/10] improve the wording --- 1.1/openid-4-verifiable-credential-issuance-1_1.md | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/1.1/openid-4-verifiable-credential-issuance-1_1.md b/1.1/openid-4-verifiable-credential-issuance-1_1.md index 376cab5b..cc5ecb56 100644 --- a/1.1/openid-4-verifiable-credential-issuance-1_1.md +++ b/1.1/openid-4-verifiable-credential-issuance-1_1.md @@ -1384,7 +1384,9 @@ The following parameters are used in the JSON-encoded Credential Response body: * `transaction_id`: OPTIONAL. String identifying a Deferred Issuance transaction. This parameter is contained in the response if the Credential Issuer cannot immediately issue the Credential. The value is subsequently used to obtain the respective Credential with the Deferred Credential Endpoint (see (#deferred-credential-issuance)). It MUST not be used if the `credentials` parameter is present. It MUST be invalidated after the Credential for which it was meant has been obtained by the Wallet. * `interval`: REQUIRED if `transaction_id` is present. Contains a positive number that represents the minimum amount of time in seconds that the Wallet SHOULD wait after receiving the response before sending a new request to the Deferred Credential Endpoint. It MUST NOT be used if the `credentials` parameter is present. * `notification_id`: OPTIONAL. String identifying one or more Credentials issued in one Credential Response. It MUST be included in the Notification Request as defined in (#notification). It MUST not be used if the `credentials` parameter is not present. -* `redirect_uri`: OPTIONAL. String containing a URI. When this parameter is present, the Wallet SHOULD give the user the option to redirect the user agent to this URI once the wallet issuance is completed, been deferred or failed. This allows the Issuer to continue the interaction with the End-User. If the Wallet sends multiple consecutive Credential Requests and receives multiple `redirect_uri` values, the Wallet SHOULD at least provide the option to redirect at the end to one of the received `redirect_uri` addresses at the end. See implementing considerations in (#redirect-uri-ambiguity) to resolve ambiguity. +* `redirect_uri`: OPTIONAL. String containing a URI. When this parameter is present, the Wallet SHOULD give the user the option to redirect the user agent to this URI once the wallet issuance is completed, been deferred or failed. This allows the Issuer to continue the interaction with the End-User. If the Wallet sends multiple consecutive Credential Requests and receives multiple `redirect_uri` values, the Wallet SHOULD provide the option to redirect to at least one of them after the last response has been processed. See implementing considerations in (#redirect-uri-ambiguity) to resolve ambiguity. + +When a wallet receives multiple redirect_uri values, it SHOULD return at least one of them to the Credential Issuer Additional Credential Response parameters MAY be defined and used. The Wallet MUST ignore any unrecognized parameters. @@ -2034,7 +2036,7 @@ While breaking changes to the specifications referenced in this specification ar ## Redirect Uri Ambiguity {#redirect-uri-ambiguity} -To resolve redirect_uri ambiguity in multi-credential issuance flows the Credential Issuer should use the same `redirect_uri` for all requests with the same Access Token, or should consider to breaking the flow in several single-credential issuance flows instead. The Credential Issuer should not rely on the user opens `redirect_uri`. +The `redirect_uri` parameter as defined in (#credential-response) and used in Credential (Error) Response and Deferred Credential (Error) Response enables the Credential Issuer to interact with the End-User after issuance is completed, been deferred or failed. To eliminate the `redirect_uri` ambiguity in multi‑credential issuance flows, the Credential Issuer should either use the same `redirect_uri` for all requests that share the same Access Token, or split the process into several single‑credential issuance flows. In any case, the Credential Issuer must not rely on the End-User to open the `redirect_uri`. # Privacy Considerations From 3db52f72c85caa60925c971f2d62741465f2ea54 Mon Sep 17 00:00:00 2001 From: Micha Kraus Date: Wed, 18 Mar 2026 15:35:07 +0100 Subject: [PATCH 03/10] remove name duplicate in Acknowledgments --- 1.1/openid-4-verifiable-credential-issuance-1_1.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/1.1/openid-4-verifiable-credential-issuance-1_1.md b/1.1/openid-4-verifiable-credential-issuance-1_1.md index cc5ecb56..8455d33e 100644 --- a/1.1/openid-4-verifiable-credential-issuance-1_1.md +++ b/1.1/openid-4-verifiable-credential-issuance-1_1.md @@ -3660,7 +3660,7 @@ The following is a non-normative example of a signed Wallet Attestation: # Acknowledgements {#Acknowledgements} -We would like to thank Patrick Amrein, Masayoshi Arakawa, Richard Barnes, Paul Bastian, Vittorio Bertocci, Christian Bormann, John Bradley, Brian Campbell, Lee Campbell, Tim Cappalli, Lenah Chacha, David Chadwick, Stefan Charsley, Gabe Cohen, Thomas Darimont, Andrii Deinega, Giuseppe De Marco, Rajvardhan Deshmukh, Mark Dobrinic, Daniel Fett, Pedro Felix, George Fletcher, Christian Fries, Timo Glasta, Mark Haine, Martijn Haring, Fabian Hauck, Roland Hedberg, Joseph Heenan, Bjorn Hjelm, Alen Horvat, Andrew Hughes, Jacob Ideskog, Lukasz Jaromin, Edmund Jay, Michael B. Jones, Tom Jones, Judith Kahrer, Micha Kraus, Takahiko Kawasaki, Niels Klomp, Ronald Koenig, Micha Kraus, Markus Kreusch, Philipp Lehwalder, Adam Lemmon, Dave Longley, Hicham Lozi, David Luna, Daniel McGrogan, Jeremie Miller, Mirko Mollik, Kenichi Nakamura, Andres Olave, Gareth Oliver, Nemanja Patrnogic, Dima Postnikov, Rolson Quadras, Helen Quinn, Sami Rosendahl, Babis Routis, Nat Sakimura, Sudesh Shetty, Peter Sorotokin, Oliver Terbu, Dimitri James Tsiflitzis, Mike Varley, Niels van Dijk, Arjen van Veen, Jan Vereecken, David Waite, Jacob Ward, David Zeuthen for their valuable feedback and contributions to this specification. +We would like to thank Patrick Amrein, Masayoshi Arakawa, Richard Barnes, Paul Bastian, Vittorio Bertocci, Christian Bormann, John Bradley, Brian Campbell, Lee Campbell, Tim Cappalli, Lenah Chacha, David Chadwick, Stefan Charsley, Gabe Cohen, Thomas Darimont, Andrii Deinega, Giuseppe De Marco, Rajvardhan Deshmukh, Mark Dobrinic, Daniel Fett, Pedro Felix, George Fletcher, Christian Fries, Timo Glasta, Mark Haine, Martijn Haring, Fabian Hauck, Roland Hedberg, Joseph Heenan, Bjorn Hjelm, Alen Horvat, Andrew Hughes, Jacob Ideskog, Lukasz Jaromin, Edmund Jay, Michael B. Jones, Tom Jones, Judith Kahrer, Takahiko Kawasaki, Niels Klomp, Ronald Koenig, Micha Kraus, Markus Kreusch, Philipp Lehwalder, Adam Lemmon, Dave Longley, Hicham Lozi, David Luna, Daniel McGrogan, Jeremie Miller, Mirko Mollik, Kenichi Nakamura, Andres Olave, Gareth Oliver, Nemanja Patrnogic, Dima Postnikov, Rolson Quadras, Helen Quinn, Sami Rosendahl, Babis Routis, Nat Sakimura, Sudesh Shetty, Peter Sorotokin, Oliver Terbu, Dimitri James Tsiflitzis, Mike Varley, Niels van Dijk, Arjen van Veen, Jan Vereecken, David Waite, Jacob Ward, David Zeuthen for their valuable feedback and contributions to this specification. # Notices From 45de848f96219db544919f26b8249bf2394b5857 Mon Sep 17 00:00:00 2001 From: Micha Kraus <7931215+mickrau@users.noreply.github.com> Date: Thu, 19 Mar 2026 09:00:21 +0100 Subject: [PATCH 04/10] Update 1.1/openid-4-verifiable-credential-issuance-1_1.md Co-authored-by: Paul Bastian --- 1.1/openid-4-verifiable-credential-issuance-1_1.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/1.1/openid-4-verifiable-credential-issuance-1_1.md b/1.1/openid-4-verifiable-credential-issuance-1_1.md index 8455d33e..599fc250 100644 --- a/1.1/openid-4-verifiable-credential-issuance-1_1.md +++ b/1.1/openid-4-verifiable-credential-issuance-1_1.md @@ -2036,7 +2036,7 @@ While breaking changes to the specifications referenced in this specification ar ## Redirect Uri Ambiguity {#redirect-uri-ambiguity} -The `redirect_uri` parameter as defined in (#credential-response) and used in Credential (Error) Response and Deferred Credential (Error) Response enables the Credential Issuer to interact with the End-User after issuance is completed, been deferred or failed. To eliminate the `redirect_uri` ambiguity in multi‑credential issuance flows, the Credential Issuer should either use the same `redirect_uri` for all requests that share the same Access Token, or split the process into several single‑credential issuance flows. In any case, the Credential Issuer must not rely on the End-User to open the `redirect_uri`. +The `redirect_uri` parameter as defined in (#credential-response) and used in Credential (Error) Response and Deferred Credential (Error) Response enables the Credential Issuer to interact with the End-User after issuance is completed, been deferred or failed. If an access token contains authorization for multiple Credential Configurations or multiple Credential Datasets, the wallet may send multiple Credential Requests. However, the Credential Issuer may not be able to anticipate how many Credential Requests will be received. To eliminate any ambiguity for the wallet about which `redirect_uri` to use in such multi‑credential issuance scenarios, the Credential Issuer should either use the same `redirect_uri` for all requests that share the same Access Token, or split the process into several single‑credential issuance flows. In any case, the Credential Issuer must not rely on the End-User to open the `redirect_uri`. # Privacy Considerations From c5b010a0ec8c818d707e417a5c9b59594c4db831 Mon Sep 17 00:00:00 2001 From: Micha Kraus <7931215+mickrau@users.noreply.github.com> Date: Thu, 19 Mar 2026 09:00:45 +0100 Subject: [PATCH 05/10] Update 1.1/openid-4-verifiable-credential-issuance-1_1.md Co-authored-by: Paul Bastian --- 1.1/openid-4-verifiable-credential-issuance-1_1.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/1.1/openid-4-verifiable-credential-issuance-1_1.md b/1.1/openid-4-verifiable-credential-issuance-1_1.md index 599fc250..dc5c63fb 100644 --- a/1.1/openid-4-verifiable-credential-issuance-1_1.md +++ b/1.1/openid-4-verifiable-credential-issuance-1_1.md @@ -1384,7 +1384,7 @@ The following parameters are used in the JSON-encoded Credential Response body: * `transaction_id`: OPTIONAL. String identifying a Deferred Issuance transaction. This parameter is contained in the response if the Credential Issuer cannot immediately issue the Credential. The value is subsequently used to obtain the respective Credential with the Deferred Credential Endpoint (see (#deferred-credential-issuance)). It MUST not be used if the `credentials` parameter is present. It MUST be invalidated after the Credential for which it was meant has been obtained by the Wallet. * `interval`: REQUIRED if `transaction_id` is present. Contains a positive number that represents the minimum amount of time in seconds that the Wallet SHOULD wait after receiving the response before sending a new request to the Deferred Credential Endpoint. It MUST NOT be used if the `credentials` parameter is present. * `notification_id`: OPTIONAL. String identifying one or more Credentials issued in one Credential Response. It MUST be included in the Notification Request as defined in (#notification). It MUST not be used if the `credentials` parameter is not present. -* `redirect_uri`: OPTIONAL. String containing a URI. When this parameter is present, the Wallet SHOULD give the user the option to redirect the user agent to this URI once the wallet issuance is completed, been deferred or failed. This allows the Issuer to continue the interaction with the End-User. If the Wallet sends multiple consecutive Credential Requests and receives multiple `redirect_uri` values, the Wallet SHOULD provide the option to redirect to at least one of them after the last response has been processed. See implementing considerations in (#redirect-uri-ambiguity) to resolve ambiguity. +* `redirect_uri`: OPTIONAL. String containing a URI. When this parameter is present, the Wallet SHOULD suggest the End-User to redirect the user agent to this URI once the Credential issuance is completed, been deferred or failed. This allows the Issuer to continue the interaction with the End-User. If the Wallet sends multiple consecutive Credential Requests and receives multiple `redirect_uri` values, the Wallet SHOULD provide the option to redirect to at least one of them after the last response has been processed. See implementing considerations in (#redirect-uri-ambiguity) to resolve ambiguity. When a wallet receives multiple redirect_uri values, it SHOULD return at least one of them to the Credential Issuer From 75713843d8e8add14389fc26a68d7567bbddf44f Mon Sep 17 00:00:00 2001 From: Micha Kraus Date: Thu, 19 Mar 2026 09:05:38 +0100 Subject: [PATCH 06/10] remove left-over sentence --- 1.1/openid-4-verifiable-credential-issuance-1_1.md | 2 -- 1 file changed, 2 deletions(-) diff --git a/1.1/openid-4-verifiable-credential-issuance-1_1.md b/1.1/openid-4-verifiable-credential-issuance-1_1.md index dc5c63fb..f3a56b76 100644 --- a/1.1/openid-4-verifiable-credential-issuance-1_1.md +++ b/1.1/openid-4-verifiable-credential-issuance-1_1.md @@ -1386,8 +1386,6 @@ The following parameters are used in the JSON-encoded Credential Response body: * `notification_id`: OPTIONAL. String identifying one or more Credentials issued in one Credential Response. It MUST be included in the Notification Request as defined in (#notification). It MUST not be used if the `credentials` parameter is not present. * `redirect_uri`: OPTIONAL. String containing a URI. When this parameter is present, the Wallet SHOULD suggest the End-User to redirect the user agent to this URI once the Credential issuance is completed, been deferred or failed. This allows the Issuer to continue the interaction with the End-User. If the Wallet sends multiple consecutive Credential Requests and receives multiple `redirect_uri` values, the Wallet SHOULD provide the option to redirect to at least one of them after the last response has been processed. See implementing considerations in (#redirect-uri-ambiguity) to resolve ambiguity. -When a wallet receives multiple redirect_uri values, it SHOULD return at least one of them to the Credential Issuer - Additional Credential Response parameters MAY be defined and used. The Wallet MUST ignore any unrecognized parameters. Below is a non-normative example of a Credential Response in an immediate issuance flow for a Credential in JWT VC format (JSON encoded): From 9a14ea78d20a17791722d74526317109256f76e5 Mon Sep 17 00:00:00 2001 From: Micha Kraus <7931215+mickrau@users.noreply.github.com> Date: Mon, 23 Mar 2026 11:03:59 +0100 Subject: [PATCH 07/10] Apply suggestions from code review Co-authored-by: Frederik Krogsdal Jacobsen --- 1.1/openid-4-verifiable-credential-issuance-1_1.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/1.1/openid-4-verifiable-credential-issuance-1_1.md b/1.1/openid-4-verifiable-credential-issuance-1_1.md index f3a56b76..e3479185 100644 --- a/1.1/openid-4-verifiable-credential-issuance-1_1.md +++ b/1.1/openid-4-verifiable-credential-issuance-1_1.md @@ -1384,7 +1384,7 @@ The following parameters are used in the JSON-encoded Credential Response body: * `transaction_id`: OPTIONAL. String identifying a Deferred Issuance transaction. This parameter is contained in the response if the Credential Issuer cannot immediately issue the Credential. The value is subsequently used to obtain the respective Credential with the Deferred Credential Endpoint (see (#deferred-credential-issuance)). It MUST not be used if the `credentials` parameter is present. It MUST be invalidated after the Credential for which it was meant has been obtained by the Wallet. * `interval`: REQUIRED if `transaction_id` is present. Contains a positive number that represents the minimum amount of time in seconds that the Wallet SHOULD wait after receiving the response before sending a new request to the Deferred Credential Endpoint. It MUST NOT be used if the `credentials` parameter is present. * `notification_id`: OPTIONAL. String identifying one or more Credentials issued in one Credential Response. It MUST be included in the Notification Request as defined in (#notification). It MUST not be used if the `credentials` parameter is not present. -* `redirect_uri`: OPTIONAL. String containing a URI. When this parameter is present, the Wallet SHOULD suggest the End-User to redirect the user agent to this URI once the Credential issuance is completed, been deferred or failed. This allows the Issuer to continue the interaction with the End-User. If the Wallet sends multiple consecutive Credential Requests and receives multiple `redirect_uri` values, the Wallet SHOULD provide the option to redirect to at least one of them after the last response has been processed. See implementing considerations in (#redirect-uri-ambiguity) to resolve ambiguity. +* `redirect_uri`: OPTIONAL. String containing a URI. When this parameter is present, the Wallet SHOULD suggest the End-User to redirect the user agent to this URI once the Credential issuance is completed, been deferred or has failed. This allows the Issuer to continue the interaction with the End-User. If the Wallet sends multiple consecutive Credential Requests and receives multiple `redirect_uri` values, the Wallet SHOULD provide the option to redirect to at least one of them after the last response has been processed. See implementing considerations in (#redirect-uri-ambiguity) to resolve ambiguity. Additional Credential Response parameters MAY be defined and used. The Wallet MUST ignore any unrecognized parameters. @@ -1460,7 +1460,7 @@ If the Wallet is requesting the issuance of a Credential that is not supported b * `invalid_encryption_parameters`: This error occurs when the encryption parameters in the Credential Request are either invalid or missing. In the latter case, it indicates that the Credential Issuer requires the Credential Response to be sent encrypted, but the Credential Request does not contain the necessary encryption parameters. * `credential_request_denied`: The Credential Request has not been accepted by the Credential Issuer. The Wallet SHOULD treat this error as unrecoverable, meaning if received from a Credential Issuer the Credential cannot be issued. * `error_description`: OPTIONAL. The `error_description` parameter MUST be a human-readable ASCII [@!USASCII] text, providing any additional information used to assist the Client implementers in understanding the occurred error. The values for the `error_description` parameter MUST NOT include characters outside the set `%x20-21 / %x23-5B / %x5D-7E`. -* `redirect_uri`: OPTIONAL. as defined in (#credential-response) +* `redirect_uri`: OPTIONAL. As defined in (#credential-response). The usage of these parameters takes precedence over the `invalid_request` parameter defined in (#authorization-errors), since they provide more details about the errors. @@ -2032,9 +2032,9 @@ Implementers should be aware that this specification uses several specifications While breaking changes to the specifications referenced in this specification are not expected, should they occur, OpenID4VCI implementations should continue to use the specifically referenced versions above in preference to the final versions, unless updated by a profile or new version of this specification. -## Redirect Uri Ambiguity {#redirect-uri-ambiguity} +## Redirect URI Ambiguity {#redirect-uri-ambiguity} -The `redirect_uri` parameter as defined in (#credential-response) and used in Credential (Error) Response and Deferred Credential (Error) Response enables the Credential Issuer to interact with the End-User after issuance is completed, been deferred or failed. If an access token contains authorization for multiple Credential Configurations or multiple Credential Datasets, the wallet may send multiple Credential Requests. However, the Credential Issuer may not be able to anticipate how many Credential Requests will be received. To eliminate any ambiguity for the wallet about which `redirect_uri` to use in such multi‑credential issuance scenarios, the Credential Issuer should either use the same `redirect_uri` for all requests that share the same Access Token, or split the process into several single‑credential issuance flows. In any case, the Credential Issuer must not rely on the End-User to open the `redirect_uri`. +The `redirect_uri` parameter as defined in (#credential-response) and used in Credential (Error) Response and Deferred Credential (Error) Response enables the Credential Issuer to interact with the End-User after issuance is completed, been deferred or has failed. If an access token contains authorization for multiple Credential Configurations or multiple Credential Datasets, the wallet may send multiple Credential Requests. However, the Credential Issuer may not be able to anticipate how many Credential Requests will be received. To eliminate any ambiguity for the wallet about which `redirect_uri` to use in such multi‑credential issuance scenarios, the Credential Issuer should either use the same `redirect_uri` for all requests that share the same Access Token, or split the process into several single‑credential issuance flows. In any case, the Credential Issuer must not rely on the End-User opening the `redirect_uri`, since the End-User may choose not to do so. # Privacy Considerations From 647899cac3821356e55ff8de1bbeb2a28ff4674c Mon Sep 17 00:00:00 2001 From: Micha Kraus <7931215+mickrau@users.noreply.github.com> Date: Wed, 25 Mar 2026 18:28:19 +0100 Subject: [PATCH 08/10] Apply suggestions from code review Co-authored-by: Christian Bormann --- 1.1/openid-4-verifiable-credential-issuance-1_1.md | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/1.1/openid-4-verifiable-credential-issuance-1_1.md b/1.1/openid-4-verifiable-credential-issuance-1_1.md index e3479185..9249ff43 100644 --- a/1.1/openid-4-verifiable-credential-issuance-1_1.md +++ b/1.1/openid-4-verifiable-credential-issuance-1_1.md @@ -1384,7 +1384,7 @@ The following parameters are used in the JSON-encoded Credential Response body: * `transaction_id`: OPTIONAL. String identifying a Deferred Issuance transaction. This parameter is contained in the response if the Credential Issuer cannot immediately issue the Credential. The value is subsequently used to obtain the respective Credential with the Deferred Credential Endpoint (see (#deferred-credential-issuance)). It MUST not be used if the `credentials` parameter is present. It MUST be invalidated after the Credential for which it was meant has been obtained by the Wallet. * `interval`: REQUIRED if `transaction_id` is present. Contains a positive number that represents the minimum amount of time in seconds that the Wallet SHOULD wait after receiving the response before sending a new request to the Deferred Credential Endpoint. It MUST NOT be used if the `credentials` parameter is present. * `notification_id`: OPTIONAL. String identifying one or more Credentials issued in one Credential Response. It MUST be included in the Notification Request as defined in (#notification). It MUST not be used if the `credentials` parameter is not present. -* `redirect_uri`: OPTIONAL. String containing a URI. When this parameter is present, the Wallet SHOULD suggest the End-User to redirect the user agent to this URI once the Credential issuance is completed, been deferred or has failed. This allows the Issuer to continue the interaction with the End-User. If the Wallet sends multiple consecutive Credential Requests and receives multiple `redirect_uri` values, the Wallet SHOULD provide the option to redirect to at least one of them after the last response has been processed. See implementing considerations in (#redirect-uri-ambiguity) to resolve ambiguity. +* `redirect_uri`: OPTIONAL. String containing a URI. When this parameter is present, the Wallet SHOULD suggest the End-User to redirect the user agent to this URI once the Credential issuance is completed, has been deferred or has failed. This allows the Issuer to continue the interaction with the End-User. If the Wallet sends multiple consecutive Credential Requests and receives multiple `redirect_uri` values, the Wallet SHOULD provide the option to redirect to at least one of them after the last response has been processed. See implementing considerations in (#redirect-uri-ambiguity) to resolve ambiguity. Additional Credential Response parameters MAY be defined and used. The Wallet MUST ignore any unrecognized parameters. @@ -2034,7 +2034,8 @@ While breaking changes to the specifications referenced in this specification ar ## Redirect URI Ambiguity {#redirect-uri-ambiguity} -The `redirect_uri` parameter as defined in (#credential-response) and used in Credential (Error) Response and Deferred Credential (Error) Response enables the Credential Issuer to interact with the End-User after issuance is completed, been deferred or has failed. If an access token contains authorization for multiple Credential Configurations or multiple Credential Datasets, the wallet may send multiple Credential Requests. However, the Credential Issuer may not be able to anticipate how many Credential Requests will be received. To eliminate any ambiguity for the wallet about which `redirect_uri` to use in such multi‑credential issuance scenarios, the Credential Issuer should either use the same `redirect_uri` for all requests that share the same Access Token, or split the process into several single‑credential issuance flows. In any case, the Credential Issuer must not rely on the End-User opening the `redirect_uri`, since the End-User may choose not to do so. +The `redirect_uri` parameter as defined in (#credential-response) and used in Credential (Error) Response and Deferred Credential (Error) Response enables the Credential Issuer to interact with the End-User after issuance is completed, has been deferred or has failed. If an access token contains authorization for multiple Credential Configurations or multiple Credential Datasets, the wallet may send multiple Credential Requests. +However, the Credential Issuer may not be able to anticipate how many Credential Requests will be received. To eliminate any ambiguity for the wallet about which `redirect_uri` to use in such multi‑credential issuance scenarios, the Credential Issuer should either use the same `redirect_uri` for all requests that share the same Access Token, or split the process into several single‑credential issuance flows. In any case, the Credential Issuer must not rely on the End-User opening the `redirect_uri`, since the End-User may choose not to do so. # Privacy Considerations From 4d4952fbd5617708e478932e2709ea0a7ee8023f Mon Sep 17 00:00:00 2001 From: Micha Kraus Date: Wed, 1 Apr 2026 14:38:34 +0200 Subject: [PATCH 09/10] redirect_uri using https scheme --- 1.1/openid-4-verifiable-credential-issuance-1_1.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/1.1/openid-4-verifiable-credential-issuance-1_1.md b/1.1/openid-4-verifiable-credential-issuance-1_1.md index 9249ff43..0c008ed1 100644 --- a/1.1/openid-4-verifiable-credential-issuance-1_1.md +++ b/1.1/openid-4-verifiable-credential-issuance-1_1.md @@ -1384,7 +1384,7 @@ The following parameters are used in the JSON-encoded Credential Response body: * `transaction_id`: OPTIONAL. String identifying a Deferred Issuance transaction. This parameter is contained in the response if the Credential Issuer cannot immediately issue the Credential. The value is subsequently used to obtain the respective Credential with the Deferred Credential Endpoint (see (#deferred-credential-issuance)). It MUST not be used if the `credentials` parameter is present. It MUST be invalidated after the Credential for which it was meant has been obtained by the Wallet. * `interval`: REQUIRED if `transaction_id` is present. Contains a positive number that represents the minimum amount of time in seconds that the Wallet SHOULD wait after receiving the response before sending a new request to the Deferred Credential Endpoint. It MUST NOT be used if the `credentials` parameter is present. * `notification_id`: OPTIONAL. String identifying one or more Credentials issued in one Credential Response. It MUST be included in the Notification Request as defined in (#notification). It MUST not be used if the `credentials` parameter is not present. -* `redirect_uri`: OPTIONAL. String containing a URI. When this parameter is present, the Wallet SHOULD suggest the End-User to redirect the user agent to this URI once the Credential issuance is completed, has been deferred or has failed. This allows the Issuer to continue the interaction with the End-User. If the Wallet sends multiple consecutive Credential Requests and receives multiple `redirect_uri` values, the Wallet SHOULD provide the option to redirect to at least one of them after the last response has been processed. See implementing considerations in (#redirect-uri-ambiguity) to resolve ambiguity. +* `redirect_uri`: OPTIONAL. String containing a URI using the `https` scheme. When this parameter is present, the Wallet SHOULD suggest the End-User to redirect the user agent to this URI once the Credential issuance is completed, has been deferred or has failed. This allows the Issuer to continue the interaction with the End-User. If the Wallet sends multiple consecutive Credential Requests and receives multiple `redirect_uri` values, the Wallet SHOULD provide the option to redirect to at least one of them after the last response has been processed. See implementing considerations in (#redirect-uri-ambiguity) to resolve ambiguity. Additional Credential Response parameters MAY be defined and used. The Wallet MUST ignore any unrecognized parameters. From bb227fd663bf83d5a54dabf60aa962550e527e3b Mon Sep 17 00:00:00 2001 From: Micha Kraus Date: Wed, 1 Apr 2026 14:38:49 +0200 Subject: [PATCH 10/10] add history entry for redirect_uri --- 1.1/openid-4-verifiable-credential-issuance-1_1.md | 1 + 1 file changed, 1 insertion(+) diff --git a/1.1/openid-4-verifiable-credential-issuance-1_1.md b/1.1/openid-4-verifiable-credential-issuance-1_1.md index 0c008ed1..b63a87ad 100644 --- a/1.1/openid-4-verifiable-credential-issuance-1_1.md +++ b/1.1/openid-4-verifiable-credential-issuance-1_1.md @@ -3685,3 +3685,4 @@ The technology described in this specification was made available from contribut * add interactive_authorization_endpoint to AS metadata section * add URNs for IAE type identifiers * add iana registration for an openid foundation urn + * add redirect_uri to (Deferred) Credential (Error) Response