add redirect_uri to Credential Offer#759
Open
paulbastian wants to merge 2 commits into
Open
Conversation
paulbastian
commented
Jun 22, 2026
paulbastian
commented
Jun 22, 2026
Comment on lines
+394
to
+403
| * `authorization_code`: OPTIONAL. Object for the Authorization Code Grant type. | ||
| * `issuer_state`: OPTIONAL. String value created by the Credential Issuer and opaque to the Wallet that is used to bind the subsequent Authorization Request with a context set up during previous process steps. If the Wallet decides to use the Authorization Code Flow and received a value for this parameter, it MUST include it in the subsequent Authorization Request to the Authorization Server as the `issuer_state` parameter value. | ||
| * `authorization_server`: OPTIONAL string that the Wallet can use to identify the Authorization Server to use with this grant type when `authorization_servers` parameter in the Credential Issuer metadata has multiple entries. It MUST NOT be used otherwise. The value of this parameter MUST match with one of the values in the `authorization_servers` array obtained from the Credential Issuer metadata. | ||
| * `urn:ietf:params:oauth:grant-type:pre-authorized_code`: OPTIONAL. Object for the Pre-authorized Code Grant type. | ||
| * `pre-authorized_code`: REQUIRED. The code representing the Credential Issuer's authorization for the Wallet to obtain Credentials of a certain type. This code MUST be short lived and single use. If the Wallet decides to use the Pre-Authorized Code Flow, this parameter value MUST be included in the subsequent Token Request with the Pre-Authorized Code Flow. | ||
| * `tx_code`: OPTIONAL. Object indicating that a Transaction Code is required if present, even if empty. It describes the requirements for a Transaction Code, which the Authorization Server expects the End-User to present along with the Token Request in a Pre-Authorized Code Flow. If the Authorization Server does not expect a Transaction Code, this object is absent; this is the default. The Transaction Code is intended to bind the Pre-Authorized Code to a certain transaction to prevent replay of this code by an attacker that, for example, scanned the QR code while standing behind the legitimate End-User. It is RECOMMENDED to send the Transaction Code via a separate channel. If the Wallet decides to use the Pre-Authorized Code Flow, the Transaction Code value MUST be sent in the `tx_code` parameter with the respective Token Request as defined in (#token-request). If no `length`, `description`, or `input_mode` is given, this object MAY be empty. | ||
| * `input_mode` : OPTIONAL. String specifying the input character set. Possible values are `numeric` (only digits) and `text` (any characters). The default is `numeric`. | ||
| * `length`: OPTIONAL. Integer specifying the length of the Transaction Code. This helps the Wallet to render the input screen and improve the user experience. | ||
| * `description`: OPTIONAL. String containing guidance for the Holder of the Wallet on how to obtain the Transaction Code, e.g., describing over which communication channel it is delivered. The Wallet is RECOMMENDED to display this description next to the Transaction Code input screen to improve the user experience. The length of the string MUST NOT exceed 300 characters. The `description` does not support internationalization, however the Issuer MAY detect the Holder's language by previous communication or an HTTP Accept-Language header within an HTTP GET request for a Credential Offer URI. | ||
| * `authorization_server`: OPTIONAL string that the Wallet can use to identify the Authorization Server to use with this grant type when `authorization_servers` parameter in the Credential Issuer metadata has multiple entries. It MUST NOT be used otherwise. The value of this parameter MUST match with one of the values in the `authorization_servers` array obtained from the Credential Issuer metadata. |
Contributor
Author
There was a problem hiding this comment.
for reviews: this part is only moved upwards
|
|
||
| If the Credential Issuer requires more time to issue a Credential, the Credential Issuer may return a Transaction ID and a time interval in the Credential Response. The Wallet may send a Deferred Credential Request with the Transaction ID to obtain a Credential after the specified time interval has passed, as defined in (#deferred-credential-issuance). | ||
|
|
||
| (7) If the Credential Offer contained a `redirect_uri` parameter (#credential-offer-parameters), the Wallet should offer the End-User to navigate the User Agent back to the Credential Issuer, for example, to return to the Credential Issuer's website. This redirect is OPTIONAL, is performed only upon explicit End-User interaction, and happens regardless of whether the issuance succeeded or failed. |
Contributor
There was a problem hiding this comment.
Suggested change
| (7) If the Credential Offer contained a `redirect_uri` parameter (#credential-offer-parameters), the Wallet should offer the End-User to navigate the User Agent back to the Credential Issuer, for example, to return to the Credential Issuer's website. This redirect is OPTIONAL, is performed only upon explicit End-User interaction, and happens regardless of whether the issuance succeeded or failed. | |
| (7) If the Credential Offer contained a `redirect_uri` parameter (#credential-offer-parameters), the Wallet Wallet SHOULD navigate the User Agent to this URL after it has finished processing the Credential Offer, e.g. to return to the Credential Issuer's website. The Wallet SHOULD do this regardless of whether the issuance succeeded, failed, was cancelled or entered a pending state. The Issuer MUST NOT rely on the redirect occurring for successful issuance. |
| * `length`: OPTIONAL. Integer specifying the length of the Transaction Code. This helps the Wallet to render the input screen and improve the user experience. | ||
| * `description`: OPTIONAL. String containing guidance for the Holder of the Wallet on how to obtain the Transaction Code, e.g., describing over which communication channel it is delivered. The Wallet is RECOMMENDED to display this description next to the Transaction Code input screen to improve the user experience. The length of the string MUST NOT exceed 300 characters. The `description` does not support internationalization, however the Issuer MAY detect the Holder's language by previous communication or an HTTP Accept-Language header within an HTTP GET request for a Credential Offer URI. | ||
| * `authorization_server`: OPTIONAL string that the Wallet can use to identify the Authorization Server to use with this grant type when `authorization_servers` parameter in the Credential Issuer metadata has multiple entries. It MUST NOT be used otherwise. The value of this parameter MUST match with one of the values in the `authorization_servers` array obtained from the Credential Issuer metadata. | ||
| * `redirect_uri`: OPTIONAL. String that is a URL using the `https` scheme. If present, the Wallet SHOULD navigate the User Agent to this URL after it has finished processing the Credential Offer, e.g. to return to the Credential Issuer's website. The Wallet SHOULD do this regardless of whether the issuance succeeded or failed. The Wallet MAY ask the End-User for consent. Because the Credential Offer is not authenticated (see (#credential-offer-security)), the Wallet MUST validate this value against the `expected_redirect_origin` Credential Issuer metadata parameter as defined in (#credential-issuer-parameters) and MUST ignore the `redirect_uri` if the validation fails. |
Contributor
There was a problem hiding this comment.
Suggested change
| * `redirect_uri`: OPTIONAL. String that is a URL using the `https` scheme. If present, the Wallet SHOULD navigate the User Agent to this URL after it has finished processing the Credential Offer, e.g. to return to the Credential Issuer's website. The Wallet SHOULD do this regardless of whether the issuance succeeded or failed. The Wallet MAY ask the End-User for consent. Because the Credential Offer is not authenticated (see (#credential-offer-security)), the Wallet MUST validate this value against the `expected_redirect_origin` Credential Issuer metadata parameter as defined in (#credential-issuer-parameters) and MUST ignore the `redirect_uri` if the validation fails. | |
| * `redirect_uri`: OPTIONAL. String that is a URL using the `https` scheme. If present, the Wallet SHOULD navigate the User Agent to this URL after it has finished processing the Credential Offer, e.g. to return to the Credential Issuer's website. The Wallet SHOULD do this regardless of whether the issuance succeeded, failed, was cancelled or entered a pending state. The Issuer MUST NOT rely on the redirect occurring for successful issuance. The Wallet MAY ask the End-User for consent. Because the Credential Offer is not authenticated (see (#credential-offer-security)), the Wallet MUST validate this value against the `expected_redirect_origin` Credential Issuer metadata parameter as defined in (#credential-issuer-parameters) and MUST ignore the `redirect_uri` if the validation fails. |
Comment on lines
+1933
to
+1934
|
|
||
| Because the Credential Offer is not signed and its origin is not authenticated, an attacker could inject or manipulate the `redirect_uri` Credential Offer parameter (#credential-offer-parameters) to direct the End-User to an attacker-controlled website, for example, to conduct a phishing attack while leveraging the End-User's trust that they are returning to the Credential Issuer. |
Contributor
There was a problem hiding this comment.
Can probably just say
Suggested change
| Because the Credential Offer is not signed and its origin is not authenticated, an attacker could inject or manipulate the `redirect_uri` Credential Offer parameter (#credential-offer-parameters) to direct the End-User to an attacker-controlled website, for example, to conduct a phishing attack while leveraging the End-User's trust that they are returning to the Credential Issuer. | |
| Because the parameter values in the Credential Offer are not trustworthy, an attacker could inject or manipulate the `redirect_uri` Credential Offer parameter (#credential-offer-parameters) to direct the End-User to an attacker-controlled website, for example, to conduct a phishing attack while leveraging the End-User's trust that they are returning to the Credential Issuer. |
to link it directly to the above section.
|
|
||
| To mitigate this, the Wallet relies on the `expected_redirect_origin` Credential Issuer metadata parameter (#credential-issuer-parameters). Unlike the Credential Offer, the Credential Issuer metadata is retrieved by the Wallet directly from the Credential Issuer over a TLS-protected connection (#credential-issuer-wellknown) and is therefore authenticated. Before offering the End-User the option to follow the `redirect_uri`, the Wallet MUST verify that the origin of the `redirect_uri` matches one of the origins listed in `expected_redirect_origin`, and MUST discard the `redirect_uri` otherwise, including when `expected_redirect_origin` is absent. | ||
|
|
||
| The Wallet MUST NOT navigate to the `redirect_uri` automatically; the redirect MUST be performed only upon explicit End-User interaction. The Wallet SHOULD NOT include any information about the issued Credentials or the outcome of the issuance in the request to the `redirect_uri` beyond what the Credential Issuer encoded in the URL itself. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Replaces #723