Skip to content

Add redirect_uri to (Deferred) Credential (Error) Response to continue interaction with end user #723

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
mickrau wants to merge 10 commits into
base: main
Choose a base branch
from
Open

Add redirect_uri to (Deferred) Credential (Error) Response to continue interaction with end user #723

Changes from all commits
Commits
Show all changes
10 commits
Select commit Hold shift + click to select a range
83338b3
add text from issue
mickrau Mar 18, 2026
4518944
improve the wording
mickrau Mar 18, 2026
3db52f7
remove name duplicate in Acknowledgments
mickrau Mar 18, 2026
45de848
Update 1.1/openid-4-verifiable-credential-issuance-1_1.md
mickrau Mar 19, 2026
c5b010a
Update 1.1/openid-4-verifiable-credential-issuance-1_1.md
mickrau Mar 19, 2026
7571384
remove left-over sentence
mickrau Mar 19, 2026
9a14ea7
Apply suggestions from code review
mickrau Mar 23, 2026
647899c
Apply suggestions from code review
mickrau Mar 25, 2026
4d4952f
redirect_uri using https scheme
mickrau Apr 1, 2026
bb227fd
add history entry for redirect_uri
mickrau Apr 1, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
20 changes: 16 additions & 4 deletions 1.1/openid-4-verifiable-credential-issuance-1_1.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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 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.

Expand Down Expand Up @@ -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
Expand All @@ -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"
}
```

Expand All @@ -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.

Expand Down Expand Up @@ -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.
Expand Down Expand Up @@ -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:

```
Expand Down Expand Up @@ -2027,6 +2032,12 @@ 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}

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.

@GarethCOliver GarethCOliver Apr 2, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In my opinion this doesn't make any sense and shows the problem with the current proposal.

There should be sufficient semantic information included with the redirect_uri for the Wallet to understand the purpose. Without this, it is impossible to reasonably render this to the user. Overloading a single 'redirect_uri' parameter provides none of that context and will lead to broken user experiences (or it being simply ignored).

To give some examples:

Error case:

  • Is this a url relevant to a transient error message?
  • Is this a url relevant to the state of the credential?

Deferred:
This is the most well defined, but being explicit that this is about the status of the deferred credential request. But knowing what this means when the user has existing successfully provisioned credentials is necessary.

Success:
Is this a one-off warm welcome? Does it get shown once to the user then never again? What about subsequent responses? In general, this would better belong in well-defined field in per-instance credential metadata rather than in the credential response.

Regarding the problem of credential datasets and whether this is the same or different: if we provided more semantic structure we could include an indicator in the response as to whether this is a 'top-level' usable redirect (applying to the access token and applicable to all credentials) or if it is specific to this instance. Making the user go through multiple issuance processes to allow for granular issuer redirects seems pretty broken.

@fkj fkj Apr 22, 2026

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just to clarify, do you see problems only when there are multiple credentials issued in one process or also when it's just a single credential being issued? My thinking is that this is only a problem for issuing multiple credentials at once, and I agree that the semantics of that are weird here.
Though I think the current text in this PR is still an improvement, and I think issuers could intelligently provide a single redirect_uri for the entire process, even though it is strange that it would need to repeat it in each credential response.

@GarethCOliver GarethCOliver Apr 22, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's less problematic in a single, one-shot credential use case though it is still unclear what exactly it should mean in the case of success. What context should I, as a wallet, provide to the user as to why they should navigate to this URL?

In general I think most these use cases are probably better covered putting these urls into credential display data, that way they can have the actual semantic information for a wallet to know how to use them (especially now we have per-credential display data).

If we do have transient urls, they should be tightly coupled to their meaning in the response (e.g. a url specifically for more information on an error), again so that Wallets can actually properly know how to use them.

@fkj fkj Apr 23, 2026

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks. I agree that it would be useful to have some context for the wallet. But I'm not sure we will be able to enumerate all of the options, which would IMO be necessary for interoperability. Obviously there's "success" and "error", but anything beyond that seems less likely to be taxonomizable.



# Privacy Considerations

When [@!RFC9396] is used, the Privacy Considerations of that specification also apply.
Expand Down Expand Up @@ -3648,7 +3659,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

Expand All @@ -3674,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
Loading