Remove the numerical error codes to be in sync with the VCDM specification #327
There are no files selected for viewing
This file contains 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
| Original file line number | Diff line number | Diff line change | ||||
|---|---|---|---|---|---|---|
|
|
@@ -2366,7 +2366,7 @@ <h3>Processing Errors</h3> | |||||
| The algorithms described in this specification, as well as in various cryptographic | ||||||
| suite specifications, throw specific types of errors. Implementers might find | ||||||
| it useful to convey these errors to other libraries or software systems. This | ||||||
| section provides specific URLs and descriptions for the errors, | ||||||
| such that an ecosystem implementing technologies described by this | ||||||
| specification might interoperate more effectively when errors occur. | ||||||
| </p> | ||||||
|
|
@@ -2384,38 +2384,34 @@ <h3>Processing Errors</h3> | |||||
| below. | ||||||
| </li> | ||||||
| <li> | ||||||
| The `title` value MUST be present and SHOULD provide a short but specific human-readable [=string=] for | ||||||
| the error. | ||||||
| </li> | ||||||
| <li> | ||||||
| The `detail` value MUST be present and SHOULD provide a longer human-readable [=string=] for the error. | ||||||
|
There was a problem hiding this comment. This should match what's in the other specs and not add a new MUST: https://w3c.github.io/vc-bitstring-status-list/#processing-errors
Suggested change
There was a problem hiding this comment. See comment here: https://github.com/w3c/vc-data-integrity/pull/327/files#r1912460821 |
||||||
| </li> | ||||||
| </ul> | ||||||
|
|
||||||
| <dl> | ||||||
| <dt id="PROOF_GENERATION_ERROR">PROOF_GENERATION_ERROR</dt> | ||||||
| <dd> | ||||||
| A request to generate a proof failed. See Section [[[#add-proof]]], and Section | ||||||
| [[[#add-proof-set-chain]]]. | ||||||
| </dd> | ||||||
| <dt id="PROOF_VERIFICATION_ERROR">PROOF_VERIFICATION_ERROR</dt> | ||||||
| <dd> | ||||||
| An error was encountered during proof verification. See Section [[[#verify-proof]]]. | ||||||
| </dd> | ||||||
| <dt id="PROOF_TRANSFORMATION_ERROR">PROOF_TRANSFORMATION_ERROR </dt> | ||||||
| <dd> | ||||||
| An error was encountered during the transformation process. | ||||||
| </dd> | ||||||
| <dt id="INVALID_DOMAIN_ERROR">INVALID_DOMAIN_ERROR</dt> | ||||||
| <dd> | ||||||
| The `domain` value in a proof did not match the expected value. See Section | ||||||
| [[[#verify-proof]]]. | ||||||
| </dd> | ||||||
| <dt id="INVALID_CHALLENGE_ERROR">INVALID_CHALLENGE_ERROR</dt> | ||||||
| <dd> | ||||||
| The `challenge` value in a proof did not match the expected value. See Section | ||||||
| [[[#verify-proof]]]. | ||||||
|
|
||||||
This file contains 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
Oops, something went wrong.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This should match what's in the other specs and not add a new MUST: https://w3c.github.io/vc-bitstring-status-list/#processing-errors
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well, actually... I have added the "MUST be present and" statement exactly to be consistent with the VCDM spec, see https://www.w3.org/TR/vc-data-model-2.0/#problem-details
I do not really care either way, we have to decide whether we align with the VCDM or we align the VCDM with this...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Right, I think we should align the VCDM with this more flexible approach (no MUSTs) that is also closer to the RFC.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am neutral on this. But this should be a decision of the WG, probably to be discussed on a call.
@brentzundel
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm, looks like we have a consistency mismatch between VCDM, DI, and BSL :(. VCDM says each property MUST be present (this language). DI and BSL say SHOULD. RFC9457 says SHOULD as well.
I think we were trying to make the error messages useful by using MUST for certain properties existing (
type,title, anddetail). I still think that's a good idea, that is -- if you are going to raise an error, you MUST include at least those properties for the error to be immediately useful for a developer).Let's discuss during the next WG call.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The
typeproperty is a MUST everywhere (in all the specs already) and should stay that way. It's only the properties that are advisory from the RFC (e.g.,titleanddetail) that I believe should be SHOULDs. I think onlytypeis really necessary for interoperability and is what software should be using to make any branching decisions. But, these other fields are useful for developers -- and the fact that they are will drive whether or not they are included, i.e., the SHOULD provides flexibility but systems will probably include them for the best DX without us having to demand it for interop, which doesn't make sense, IMO.