Change proof reference from JWT to JWS.

[msporny]

Related to #609.

---

Preview | Diff

[awoie]

@msporny As far as I understood, this PR does not change the "Proof Format" from JWT to JWS. Only the reference was corrected? If this assumption is correct, then I'm ok with this PR although the spec already says:

If no JWS is present, a proof property MUST be provided.

[nadalin]

A JWT alone can't provide any proof, its the combination with JWS, this has not cleared up the issue

[TallTed]

Perhaps --
JSON Web Tokens [[RFC7519]] with JSON Web Signatures [[RFC7515]]; Linked Data Signatures [[?LD-SIGNATURES]]; and

[nadalin]

@TallTed Why LD-Signatures? its not a standard, it requires LD-C14N which is also not a standard? If these specs were in a standards track I would comment on them as the C14N aspects have serious issues.

[TallTed]

@nadalin - As the preceding text states, LD-Signatures is one of the proof mechanisms which have been used in verifiable credential implementations by members of the VCWG, and has been included in the spec since at least Apr 18, 2018.

I do not understand you objecting to LD-Signatures now, given that it was quoted in the text with which you raised your issue with JWT vs JWS.

To be quite clear, as it seems you did not understand @msporny's suggested revision in markup form, it reads:

At the time of publication, Working Group members had implemented verifiable credentials using at least three proof mechanisms: JSON Web Signature [RFC7515], Linked Data Signatures [?LD-SIGNATURES], and Camenisch-Lysyanskaya Zero-Knowledge Proofs [?CL-SIGNATURES].

(Note -- JWS is a normative reference; the other two are informative a/k/a non-normative references.)

I now think you had not understood that, and may in fact be fine with it, in which case my follow-on is moot. That said, because you objected to @msporny's revision, I suggested the following:

At the time of publication, Working Group members had implemented verifiable credentials using at least three proof mechanisms: JSON Web Tokens [RFC7519] with JSON Web Signatures [RFC7515]; Linked Data Signatures [?LD-SIGNATURES]; and Camenisch-Lysyanskaya Zero-Knowledge Proofs [?CL-SIGNATURES].

(Note -- JWS and JWT are normative references; the other two are informative a/k/a non-normative references.)

Hopefully you'll now be OK with one of the revisions above.

[nadalin]

@TallTed I think that to make it clear to the reader that there should be separate sentences.

At the time of publication, Working Group members had implemented verifiable credentials using at least three proof mechanisms: JSON Web Tokens [RFC7519] with JSON Web Signatures [RFC7515].

Alternatively Linked Data Signatures [?LD-SIGNATURES]; and Camenisch-Lysyanskaya Zero-Knowledge Proofs [?CL-SIGNATURES] specifications that are still in development have been used at various iterations have been used.

[TallTed]

@nadalin - How about --

At the time of publication, Working Group members had implemented verifiable credentials using at least three proof mechanisms: one based on a combination of the JSON Web Tokens [RFC7519] and JSON Web Signatures [RFC7515] standards; one based on the developing Linked Data Signatures [?LD-SIGNATURES] standard; and one based on the developing Camenisch-Lysyanskaya Zero-Knowledge Proofs [?CL-SIGNATURES] standard.

[nadalin]

@TallTed close but "developing" does not quite capture or stress the unstableness or fully thought-out aspects.

[msporny]

@awoie wrote:

As far as I understood, this PR does not change the "Proof Format" from JWT to JWS.

Yes, that's correct.

[msporny]

@nadalin wrote:

@TallTed close but "developing" does not quite capture or stress the unstableness or fully thought-out aspects.

I've added the following text:

... at least three proof mechanisms: JSON Web Tokens [[RFC7519]] secured using JSON Web Signatures [[RFC7515]]; ...

and this text:

Implementers are advised to note that not all proof mechanisms have been standardized as
of the publication date of this specification. The group expects some of these mechanisms, as well as new ones, to mature independently and become standardized in time.

That, coupled with the clear markers on each referenced spec (that they are or are not W3C/IETF standards) will give implementers more than enough of a warning to consider their implementation choices.

[msporny]

Please re-review @nadalin to see if you agree with the changes.

[burnburn]

From VCWG call on 11 June 2019:
RESOLUTION: The Working Group has confirmed that calling out the phase of standardization that any particular specification is in is not necessary as implementers can determine that information from the heading information in each specification as well as perusing the normative and non-normative reference section.

[nadalin]

@msporny This will come down to the discussion on interoperability and what is acceptable

[msporny]

Multiple positive reviews, non-normative, non-substantive, merging.