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

Update DataIntegrityProof proofValue admissible encodings #55

Closed
Wind4Greg opened this issue Jan 25, 2024 · 1 comment
Closed

Update DataIntegrityProof proofValue admissible encodings #55

Wind4Greg opened this issue Jan 25, 2024 · 1 comment
Assignees
Labels
CR1 normative This item is a normative change.

Comments

@Wind4Greg
Copy link
Collaborator

In Section 2.2.1 DataIntegrityProof the proof value is required to be "encoded using the base-58-btc header and alphabet", however for ECDSA-SD variants 3.4.2 serializeBaseProofValue and 3.4.7 serializeDerivedProofValue we require:

  • "baseProof to a string with the Multibase base64url-no-pad-encoding of proofValue..."
  • "derived proof as a string with the base64url-no-pad-encoding of proofValue..."

Hence it seems that section 2.2.1 needs to be updated to permit the base64url-no-pad-encoding as well as the base-58-btc.

@Wind4Greg
Copy link
Collaborator Author

This has been fixed, though I'm not sure which PR did it. See current draft: https://w3c.github.io/vc-di-ecdsa/#dataintegrityproof, i.e.,

"The value of the proofValue property is produced according to the cryptosuite type and is specified in either Section 3.2.1 Create Proof (ecdsa-rdfc-2019), or Section 3.3.1 Create Proof (ecdsa-jcs-2019), or Section 3.6.1 Create Base Proof (ecdsa-sd-2023), or Section 3.6.6 Add Derived Proof (ecdsa-sd-2023)."

And each of these subsections specify the encodings.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
CR1 normative This item is a normative change.
Projects
None yet
Development

No branches or pull requests

2 participants