[DOCUMENTATION BUG] JwtProof2020 and VC1.1's credential/verifiable-credential distinction

There have been some grumblings in the W3C VCWG and in the DIF JWS Test Suite work item about JwtProof2020 – doing an editorial pass to more clearly identity the “intermediate representation” (i.e., deserialized and expanded credential as JSON) as such, to avoid confusion with the JWT-VC itself (attached to the intermediate representation in the proof section that isn’t a proof section in the VCWG sense). I am happy to do this editorial pass unless anyone else has cycles or reason to do it for me 😄

[kimdhamilton]

@bumblefudge I agree that, at most, an editorial pass is needed. Per the JWT Test Suite results, the problems raised our only with the expanded/intermediate forms – not the “normative” (scare quotes intended) results

[OR13]

Specifically the documentation should address this section of the W3C TR.

https://www.w3.org/TR/vc-data-model/#proofs-signatures

This specification identifies two classes of proof mechanisms: external proofs and embedded proofs. An external proof is one that wraps an expression of this data model, such as a JSON Web Token, which is elaborated on in Section § 6.3.1 JSON Web Token. An embedded proof is a mechanism where the proof is included in the data, such as a Linked Data Signature, which is elaborated upon in Section § 6.3.2 Linked Data Proofs. When embedding a proof, the proof property MUST be used.

This implies that you are attempting to define Linked Data Proof. But that also implies that it would have integrity protection.

Make it clear if you are intending for this to be a “Linked Data Proof” and thats why you are using “proof.type == JwtProof2020”… or are you just trying to show a credential …the decoded part of a VC-JWT, aka a credential with external proof.

Warn folks about trusting the JSON members, or transmitting the JSON, since it is not protected by proof.jwt.