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

Clarification on supported proof types #78

Closed
awoie opened this issue Feb 23, 2022 · 6 comments
Closed

Clarification on supported proof types #78

awoie opened this issue Feb 23, 2022 · 6 comments
Labels

Comments

@awoie
Copy link

awoie commented Feb 23, 2022

The charter currently says:

Concrete serializations will be provided based on VC-JWT, the Ed25519 Cryptosuite, the Secp256k1 Cryptosuite, and for JSON Web Signature 2020. Concrete serializations based on the BBS+ Cryptosuite might be provided, if an IETF BBS+ RFC is published in time.

I just want to make sure that this is not an exhaustive list and other proof types might be supported (even though they won't be standardised under this charter). We should probably add some language to the charter that clarifies that the above ^^ are concrete examples for proof types and their serializations but other are considered valid as well.

@brentzundel
Copy link
Member

The VCDI deliverable description is quite different now that a few PRs have been merged.
After review of the current language, do you still feel there is an issue that may be resolved with changes to the charter text?

@kdenhartog
Copy link
Member

It's worth pointing out that even if things are not standardized under this charter I believe there's an understanding that additional proof suites can be defined and registered under the extension registry as well

@brentzundel
Copy link
Member

@awoie I believe this issue will be addressed in PR #85, do you agree?

@awoie
Copy link
Author

awoie commented Mar 2, 2022

I just want to make sure that the charter itself does not say all allowed verification methods / proofs will be produced by the working group and I want to make sure the charter still allows room for innovation through a registry (process). So I guess the PR #85 should address this.

@Sakurann
Copy link
Contributor

Sakurann commented Mar 8, 2022

Current charter states as follows (emphasis are mine). Will this address your concerns (that I agree with)?

This family of specifications consists of documents that each define how to express proofs of integrity for verifiable credentials using a number of concrete serializations for each of the defined syntaxes. The specific set of concrete serializations included will be determined by the Working Group. The following are a non-exhaustive selection of expected input documents:

  • Container Formats: VC-JSON Web Token (JWT), Data Integrity
  • Cryptosuites: JSON Web Signature 2020, EdDSA, NIST ECDSA, Koblitz ECDSA

@brentzundel
Copy link
Member

The associated PRs which reflect the consensus of the group (and lack thereof) have been either merged or closed. Closing this Issue.

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

No branches or pull requests

4 participants