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.

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

Remove credential status from Status Attestation error #85

Closed
marinaado opened this issue Sep 25, 2024 · 2 comments · Fixed by #86
Closed

Remove credential status from Status Attestation error #85

marinaado opened this issue Sep 25, 2024 · 2 comments · Fixed by #86
Assignees
Milestone

Comments

@marinaado
Copy link
Collaborator

In relation to the discussion in #61, the Status Attestation error values should not contain the credential status. The status of the credential, it being revoked, suspended or invalid, should not be considered an Status Attestation error.

The text needs to be revised to remove all mention of using errors for this purpose.

@pietroACN
Copy link

The actual response HTTP Status Codes do not provide any feedback on the Status Attestation status but only the request status, this is a proper behavior.

From the other side for each request, the Status Assertion Error object includes the following list of possible Error Codes:

  • invalid_request
  • credential_revoked
  • credential_updated
  • credential_invalid
  • invalid_request_signature
  • credential_not_found
  • unsupported_hash_alg

The invalid_request is described as "The request is not valid due to the lack or incorrectness of one or more parameters" and requires details in the error_description field: this looks overlapping with 'unsupported_hash_alg' and with 'invalid_request_signature' errors as they represent incorrectness in the relative parameters ( as in the invalid_request case).

The credential_updated response brings potential issues from several aspects:

  1. the credential to be revoked is not provided in the revocation_assertion_requests claim as it contains only its HASH, thus is not clear how a hash-verification can distinguish the case of provisioning a wrong credential vs the case of update on some existing fields: there is no possibility for the Credential Issuer to ensure that the provided Hash differs from the stored one only due to updates of its content or because of any other reason
  2. as the Credential Issuer is forbidden to store details of the issued credential, it cannot keep information about specific information changed within it as it could be used to track its contents.

My suggestion here is:

  1. Remove the unsupported_hash_alg and invalid_request_signature statuses as they are part of invalid_request
  2. Remove the credential_updated status

@marinaado marinaado linked a pull request Oct 2, 2024 that will close this issue
@peppelinux
Copy link
Owner

peppelinux commented Oct 2, 2024

The actual response HTTP Status Codes do not provide any feedback on the Status Attestation status but only the request status, this is a proper behavior.

Since we use multiple requests within a single array (json object) and obtain array of status assertion responses, we have decided to not use a single http status code describing the status of the response, since clientA may ask 3 status assertions about 3 different credentials, and obtain 2 status assertions and one status assertion error object within the response array.

@fmarino-ipzs worked a lot in this field, if is there something else to say it would be great to get his perspective too.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
3 participants