Skip to content
Merged
Changes from 7 commits
Commits
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
18 changes: 16 additions & 2 deletions 1.1/openid-4-verifiable-credential-issuance-1_1.md
Original file line number Diff line number Diff line change
Expand Up @@ -1162,13 +1162,16 @@ The following additional clarifications are provided for some of the error codes

`invalid_grant`:

- The Authorization Server expects a Transaction Code in the Pre-Authorized Code Flow but the Client provides the wrong Transaction Code.
- The End-User provides the wrong Pre-Authorized Code or the Pre-Authorized Code has expired.
- The End-User provides the wrong Pre-Authorized Code or the Pre-Authorized Code has expired or is no longer valid.

`invalid_client`:

- The Client tried to send a Token Request with a Pre-Authorized Code without a Client ID but the Authorization Server does not support anonymous access.

`invalid_tx_code`:
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.

I believe it makes sense to differentiate error codes, where the AS allows for a retry of sending Token Request with a new Transaction Code or whether this terminates the issuance session. Is the intention to allows retry for invalid_tx_code?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

@paulbastian It is expected that invalid_grant would terminate the issuance session. Does this address your concern?

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.

So is the intention to send invalid_tx_code as long as retry of transaction code is allowed and send invalid_grant if too many tries have been made due to brutr force prevention?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

@paulbastian Yes, that is the idea. Do you have any concerns?

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.

No, I would just phrase it more explicitly


- The Authorization Server expects a Transaction Code in the Pre-Authorized Code Flow but the Client provides the wrong Transaction Code.

Below is a non-normative example of a Token Error Response:

```
Expand Down Expand Up @@ -1908,6 +1911,16 @@ An attacker might leverage the Credential issuance process and the End-User's tr

In order to cope with that issue, the Wallet is RECOMMENDED to interact with trusted Credential Issuers only. In that case, the Wallet would not process a Credential Offer with an untrusted issuer URL. The Wallet MAY also show the End-User the endpoint of the Credential Issuer it will be sending the Transaction Code to and ask the End-User for confirmation.

### Transaction Code Guessing

When the Pre-Authorized Code Flow is used together with a Transaction Code (`tx_code`), the Transaction Code is typically short, low-entropy, and intended for one-time use. As a result, it may be susceptible to online guessing or brute-force attacks if an attacker can repeatedly submit Token Requests using the same Pre-Authorized Code.

To mitigate this risk, the Authorization Server SHOULD limit the number of failed Transaction Code verification attempts associated with a Pre-Authorized Code or issuance transaction. Once a configurable maximum number of failed attempts is exceeded, the Authorization Server SHOULD invalidate the Pre-Authorized Code and reject further Token Requests for that transaction.
Comment thread
awoie marked this conversation as resolved.

Transaction Codes SHOULD be short-lived and SHOULD be treated as single-use. Upon successful verification, a Transaction Code SHOULD NOT be accepted again.
Comment thread
awoie marked this conversation as resolved.

When a valid Pre-Authorized Code is presented with an incorrect Transaction Code, the Authorization Server SHOULD return the `invalid_tx_code` error. If the Pre-Authorized Code has expired, has been invalidated (including due to too many failed attempts), or is otherwise no longer valid, the Authorization Server SHOULD return the `invalid_grant` error.

## Credential Lifecycle Management

The Credential Issuer is supposed to be responsible for the lifecycle of its Credentials. This means the Credential Issuer will invalidate Credentials when it deems appropriate, e.g., if it detects fraudulent behavior.
Expand Down Expand Up @@ -3461,3 +3474,4 @@ The technology described in this specification was made available from contribut
* Add back Interactive Authorization Endpoint text that was removed from the 1.0 draft
* add require_interactive_authorization_request to AS metadata
* add interactive_authorization_endpoint to AS metadata section
* add invalid_tx_code to Pre-Authz Code Flow