-
Notifications
You must be signed in to change notification settings - Fork 117
Clarify that multiple proof mechanisms are supported. #531
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
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -559,6 +559,26 @@ <h3>Use Cases and Requirements</h3> | |
or <a>verifiers</a>, because the conformance of ecosystem roles are highly | ||
application, use case, and market vertical specific. | ||
</p> | ||
|
||
<p> | ||
Digital proof mechanisms, a subset of which are digital signatures, are required | ||
to ensure the protection of a <a>verifiable credential</a>. Having and | ||
validating proofs, which may be dependent on the syntax of the proof | ||
(for example, using the JWS of a JWT for proofing a key holder), are | ||
an essential part of processing a <a>verifiable credential</a>. At the time | ||
of publication, Working Group members had implemented | ||
<a>verifiable credentials</a> using at least three proof mechanisms: | ||
JSON Web Tokens [[JWT]], Linked Data Signatures [[?LD-SIGNATURES]], and | ||
Camenisch-Lysyanskaya Zero-Knowledge Proofs [[?CL-SIGNATURES]]. The group | ||
expects some of these mechanisms, as well as new ones, to mature independently | ||
and become standardized in time. Given that there are multiple valid | ||
proof mechanisms, this specification does not standardize on any | ||
single digital signature mechanism. One of the goals of this specification is to | ||
provide a data model that can be protected by a variety of current and future | ||
digital proof mechanisms. Conformance to this specification does not | ||
depend on the details of a particular proof mechanism; it requires clearly | ||
identifying the mechanism a <a>verifiable credential</a> uses. | ||
</p> | ||
</section> | ||
|
||
</section> | ||
|
@@ -3025,7 +3045,7 @@ <h4>Relation to the Verifiable Credentials Data Model</h4> | |
use of specific JWT-registered <a>claim</a> names and specific JWS-registered | ||
header parameter names to allow systems based on JWT to comply with this | ||
specification. If these specific <a>claim</a> names and header parameters are | ||
present, their respective counterpart in the standard | ||
present, their respective counterpart in the standard | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This looks like a spurious change There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Some of the folks that provide PRs don't have "strip trailing whitespace" turned on in their text editor. Rather than being super pedantic about it, I tend to just accept those PRs, knowing that my editor will eventually strip that trailing whitespace. It is unfortunate that doing so makes it look like there are spurious changes, but I have been unable to train everyone that produce PRs in proper trailing whitespace hygiene :). |
||
<a>verifiable credential</a> and <a>verifiable presentation</a> MAY be omitted | ||
to avoid duplication. | ||
</p> | ||
|
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 makes it sound like the proof doesn't matter, where in practice the proofing mechanism for the credential is what makes it trustable within a real system. This important aspect of VC's might get lost by someone reading this paragraph. I would recommend adding text that having and validating a proof are an essential part of processing a VC but that the details of validating or applying the proof/signature are outside the scope of this specification.
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.
Fixed in 56a7b6b.