Clarify that multiple proof mechanisms are supported. #531
Conversation
Related to issue #482.
|
Tagging @jricher for a review of this PR. |
index.html
Outdated
| While digital proofs, a subset of which are digital signatures, are required | ||
| to ensure the protection of a <a>verifiable credential</a>, this specification | ||
| does not standarize on any single digital signature format. At the time of | ||
| publication, the Working Group included members that had implemented using |
There was a problem hiding this comment.
"...Working Group members had implemented verifiable credenitals using at least three..." ?
index.html
Outdated
| to ensure the protection of a <a>verifiable credential</a>, this specification | ||
| does not standarize on any single digital signature format. At the time of | ||
| publication, the Working Group included members that had implemented using | ||
| at least three proof mechanisms. These implementations utilized |
There was a problem hiding this comment.
"...proof Mechanisms: JSON Web Tokens [ref]; Linked Data Signatures [ref]..." ?
index.html
Outdated
| publication, the Working Group included members that had implemented using | ||
| at least three proof mechanisms. These implementations utilized | ||
| JSON Web Tokens, Linked Data Signatures, and Camenisch-Lysyanskaya | ||
| Zero-Knowledge Proofs. It is expected that each of these mechanisms will mature |
There was a problem hiding this comment.
s/It is expected that each of these/The group expects these/ ?
index.html
Outdated
| protected by a variety of current and future digital proof approaches. | ||
| Conformance with respect to digital proofs in this specification is focused | ||
| on the clear identification of each digital proof mechanism and not the details | ||
| of any particular proof mechanism. |
There was a problem hiding this comment.
"Conformance to this specification does not depend on the details of a particular proof mechanism; it requires clearly identifying the mechanism a verifiable credential uses."?
|
Multiple independent reviews and approvals are in. Holding this merge on @jricher. |
| @@ -3025,7 +3041,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.
This looks like a spurious change
There was a problem hiding this comment.
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 :).
index.html
Outdated
| @@ -559,6 +559,22 @@ <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> | |||
| While digital proofs, a subset of which are digital signatures, are required | |||
There was a problem hiding this comment.
This could be worded to also explain that processing of the proof may be dependent on the syntax, such as using the JWS of a JWT for proofing a key holder. Some of the text of #539 tries to address this.
| and become standardized in time. 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 |
There was a problem hiding this comment.
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.
|
Reviewed by 3 independent parties, all suggestions applied to spec text, non-normative, merging. |
|
I would agree with Justin's comments, what is he is not enough information |
Related to issue #482.