Add JwtProof2020 to the charter

[OR13]

See circlefin/verite#373

I think there are 3 potentially valuable outcomes with respect to this item.

1. Informative mapping between VC-JWT and "JwtProof2020" for the purpose of database queries

This would be adding a section to the VC-JWT item, where we define the need to "query over claims", and describe a "decoded representation" that supports this objective, while clearly distinguishing it from the normatively defined comact JWT form of VC-JWT.

2. A linked data integrity crypto suite for "JwtProof2020"

This would define a verification and signature process that combined aspects of VC-JWT with aspects of Linked Data Integrity Proofs... And most importantly, would address the security issues associated with "JwtProof2020" JSON members vs JWT claims.... since thee JSON Members are not integrity protected, a linked data suite would need to be defined to protect them.

3. Acknowledge that "JwtProof2020" is a "internal json reprepresentation" of a "VC-JWT" and is not a standard Verifiable Credential with embedded or external proof... this would be acknowledging that "JwtProof2020" is neither a JWT nor a LD Proof VC.

cc @bumblefudge @mprorock @awoie @msporny

[Sakurann]

where in the charter would you like to see? As in input document to the data integrity deliverable?

[OR13]

@Sakurann I gave 3 options, which one would you prefer?

[selfissued]

Am I right that this new format is neither a conformant VC nor a conformant JWT? If so, I'm pretty skeptical of trying to inject it into the set of VC-like data formats that we already have. I can't see interoperability among implementations being improved by doing so.

[brentzundel]

It isn't clear to me what changes should be made to the charter text to resolve this issue

[msporny]

I'm not sure I agree that any of the 3 items are valuable outcomes. We already have VC-JWT and JsonWebSignature2020 -- why do we need yet another JOSE format? Going through the options:

1. Feels like you could do this anyway w/o taking JwtProof2020 as input, but doing so would just be pointing out why storing JWTs is fraught (maybe that has value?).
2. It's not clear what benefits this would have over VC-JWT and JsonWebSignature2020.
3. Feels like this would be standardizing yet another JOSE/JWT format.

All three feel like disadvantages if standardized, with 1 being the most benign one.

[bumblefudge]

AFAIK Verite isn't intending to pass this off as a VC: see
circlefin/verite#373 (comment)

[msporny]

@OR13 to write a PR for this once we have enough feedback in this issue.

[OR13]

Specifically, the charter should include language that allows us to describe credential and verifiable credential as JSON, regardless of assertion format, and at a minimum warn about the security implications of mistaking one for another... including providing examples such as JwtProof2020 and explaining why they are harmful in this regard.

[iherman]

The issue was discussed in a meeting on 2022-03-02

• no resolutions were taken

View the transcript

5.3. Add JwtProof2020 to the charter (issue vc-wg-charter#84)

See github issue vc-wg-charter#84.

Brent Zundel: next up #84.
… add JwtProof2020 to charter.

Orie Steele: There is an implementation of jwt-vc at DIF that is really an "internal" format, but it looks like an external one..
… so I raised this to help resolve the issues. We also want to be able to find JWTs in a database.
… we could say this is not our business, but clearly the folks behind JWT-proof thought it might be useful to be explicit.

Manu Sporny: A couple ways to address Orie's issues. If folks want to talk about storage, maybe that can be done in the VC-JWT spec.
… the way the spec is constructed now feels like noise. It'd probably be better to just shut that down..
… I hesitate to pull it in when it isn't really a cryptosuite.
… My suggestion is DIF should shut it down or rename it to remove the confusion.
… Not likely effective to depend on DIF to fix this.

Dave Longley: btw, ignoring how people may use VCs entirely can lead to mistakes wrt priority of constituencies (e.g., making it easy for someone to write a spec or implement signing/verifying a VC, but harder for end users to use the verified data in a variety of ways).

Juan Caballero: there is no ongoing work to shut down.

Orie Steele: you got part of it right, but one of the suggestions is the JWT part of the spec could comment on this to make it intelligible..

Juan Caballero: it's a historical document.

Manu Sporny: it should be marked as such.

Juan Caballero: it should!.

Manu Sporny: W3C got in serious trouble over the years by not marking old documents as historical or rescinded.
and thus had to put that process in place..

Orie Steele: So maybe we talk about this as an implementation guide. That kind of comment, clarifying how not to do what the DIF spec is interpreted as..

Orie Steele: the best thing we could do is to comment on this format in a way that instructs and encourages contribution and removes security risks.
… I suggest that we do that in the JWT cryptosuite.
… alternatively we could take a harsh stance and decide we recommend AGAINST the DIF approach. In any case, we need to talk about storing JWTs to avoid the security issues from misunderstanding.

Brent Zundel: I appreciate the conversation. My read of the charter doesn't prohibit what has been proposed, so are we asking for changes to the charter, or just anchoring future discussions..

Manu Sporny: I won't be opposed to a sentence in the charter saying that we are going to talk about storage formats..
… but we probably don't need it. The desire is on record and we can refer back to this discussion..
… DIF needs to mark such specs as historical. W3C learned this the hard way and we need DIF to up its process to do something similar.

Orie Steele: FWIW I would avoid looking at DIF documents in any way other than you look at CCG docs..

Juan Caballero: +1.

Orie Steele: +1.

Michael Prorock: Adding an explicit sentence just to clarify... maybe not "storage formats" per se, but we do need to clarify how JWTs and VCs relate and the implications of that.
… "What happens if you do X".
… just because JWTs are out there, widely used for very similar operations..
… Clarifying how these things actually work and what you should do there is valuable for us to tackle.

Juan Caballero: to mike's point about documenting the JWT<--->VC relationship in the JSON section of the spec2.0.

Orie Steele: what Mike said that I think is the important highlight for interoperability, there's the credential and there is a verifiable credential..
… in v1 the credential is JSON with a separate proof. The JWT-proof breaks that model, but it does it for a good reason, so we have to consider that usage (querying in a data store).

Dave Longley: +1 to the idea that we need to consider how VCs will be used, stored, etc. -- vs. only focusing on integrity proofs directly..

Orie Steele: in some ways this could be solved by the VC-JWT clarifying its credential format is different from VCs..
… I do think the charter should clarify we will normatively defined what a credential and verifiable credential in the context of a VC-JWT.
… If we are good about using those terms correctly and educating those who use it poorly, everyone is going to be better off.
… we can't allow people to refer to other things as if they were the normatively defined thing. We should address the difference between embedded and separated proofs..
… Big +1 to Mike's comment.

Brent Zundel: would you be willing to raise a PR so we can continue the conversation more concretely..

Orie Steele: I would if we have engagement on the issue itself. Once we get that, i'll draft a PR.

[OR13]

Per the call today, the WG will address these concerns in the VCDM2.o VC-JWT Specification.

[iherman]

The issue was discussed in a meeting on 2022-03-23

• no resolutions were taken

View the transcript

2.1. Add JwtProof2020 to the charter (issue vc-wg-charter#84)

See github issue vc-wg-charter#84.

Brent Zundel: Is there anything that needs to be done to the charter to address #84?.

Orie Steele: Resulting from conversation in CCG.
… People will base64url-decode the VC-JWT. You only see a decoded VC-JWT..
… Someone decoded one, added something looking like a linked data proof, and called it something else..
… We need to define the JSON representation of a credential..
… We need to define the serialized representations - either as a compact JWT or a linked data proof.
… We need to make sure we're defining things correctly.
… We need to include examples that can be cut-and-pasted by implementers.
… If we need to add specific capabilities to the charter to enable this, we should do so..
… We need to gather more feedback. There's been no feedback in the last 21 days..

Manu Sporny: It's a good point that Orie raises..
… I expect the work to be done in the VC-JWT spec..
… I expect us to pull that out and make it its own specification..
… We have 1.1 VC-JWT examples..

Manu Sporny: See example for the id property in the current spec.

Orie Steele: Those examples are from v1.1 not 1.0.

Orie Steele: but +1 to what manu is saying..

Manu Sporny: We have examples of VC-JWTs through the spec - both unencoded and encoded.

Brent Zundel: I don't think the charter needs to be changed for this to happen.

Ivan Herman: +1 to brentz.

Brent Zundel: People can raise issues to ensure this is tracked..

Manu Sporny: +1 to close issue, we can address it per the current VCWG charter..

Orie Steele: I closed the issue and left a comment on it..