Skip to content
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

Jump to bottom

Add support for a credential denial error #321

Merged
merged 4 commits into from
May 27, 2024
Merged

Add support for a credential denial error #321

Changes from 3 commits
Commits
Show all changes
4 commits
Select commit Hold shift + click to select a range
50d2783
add cred denied
May 16, 2024
32fcc00
Update openid-4-verifiable-credential-issuance-1_0.md
decentralgabe May 16, 2024
7984421
Update openid-4-verifiable-credential-issuance-1_0.md
decentralgabe May 16, 2024
907d975
Apply suggestions from code review
decentralgabe May 24, 2024
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
3 changes: 2 additions & 1 deletion openid-4-verifiable-credential-issuance-1_0.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -1007,7 +1007,7 @@ If the Credential Request does not contain an Access Token that enables issuance

#### Credential Request Errors {#credential-request-errors}

For the errors specific to the payload of the Credential Request such as those caused by `type`, `format`, `proof`, or encryption parameters in the request, the error codes values defined in this section MUST be used instead of a generic `invalid_request` parameter defined in Section 3.1 of [@!RFC6750].
For errors related to the Credential Request's payload, such as issues with `type`, `format`, `proof`, encryption parameters, or if the request is denied, use the specific error codes from this section MUST be used instead of the generic `invalid_request` parameter defined in Section 3.1 of [@!RFC6750].
decentralgabe marked this conversation as resolved.
Show resolved Hide resolved
Copy link
Collaborator

Choose a reason for hiding this comment

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

are the purpose of these changes clarification or do they have implication on the introduction of this new error code?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I do believe there's some implications since I'm not sure how implementers have represented such errors today (before this change)


If the Wallet is requesting the issuance of a Credential that is not supported by the Credential Endpoint, the HTTP response MUST use the HTTP status code 400 (Bad Request) and set the content type to `application/json` with the following parameters in the JSON-encoded response body:

Expand All @@ -1017,6 +1017,7 @@ If the Wallet is requesting the issuance of a Credential that is not supported b
* `unsupported_credential_format`: Requested Credential Format is not supported.
* `invalid_proof`: The `proof` in the Credential Request is invalid. The `proof` field is not present or the provided key proof is invalid or not bound to a nonce provided by the Credential Issuer.
* `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.
* `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`.

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
Loading