Update VC-JWT to harmonized DIF format

[kimdhamilton]

In advance of the VC 2.0, a DIF working group has focused on harmonizing the VC-JWT format. They've developed a test suite and attempted to prove interoperability with the LD Proof suite that also uses JWS.

This is the test suite: https://github.com/decentralized-identity/JWS-Test-Suite

This work item involves:

• Updating the VC signatures to use harmonized VC-JWT signatures
• Bonus points for adding this to the implementations in the test suite
• Even more bonus points for fixing the did-jwt-vc library (which we currently use). Tracked here: Add did-jwt-vc to the test suite decentralized-identity/JWS-Test-Suite#39

@OR13 would be delighted to answer any questions you have

[OR13]

There is also work underway to add VC-JWT support to the VC API, This postman collection: w3c-ccg/traceability-interop#104

shows how to request a VC-JWT be issued by the VC API.

[OR13]

The example Verifiable Credential looks like a blend of LD Proof and VC-JWT:

{
  "credentialSubject": {
    "KYCAMLAttestation": {
      "type": "KYCAMLAttestation",
      "process": "https://verite.id/definitions/processes/kycaml/0.0.1/usa",
      "approvalDate": "2021-09-14T02:00:07.540Z"
    },
    "id": "did:key:z6Mkjo9pGYpv88SCYZW3ZT1dxrKYJrPf6u6hBeGexChJF4EN"
  },
  "issuer": {
    "id": "did:web:verite.id"
  },
  "type": ["VerifiableCredential", "KYCAMLAttestation"],
  "@context": [
    "https://www.w3.org/2018/credentials/v1",
    { "@vocab": "https://verite.id/identity/" }
  ],
  "issuanceDate": "2021-09-14T02:00:07.000Z",
  "proof": {
    "type": "JwtProof2020",
    "jwt": "eyJhbGciOiJFZERTQSIsInR5cCI6IkpXVCJ9.eyJ...IifQ.xu8eUyPtDhAiHUhIszVtLvrlUJ6H9nGTEcZ1paXvqNolDXd0X3ORugCWjAWMTASaIJcPrmkpLoZzw9OXMYofCg"
  }
}

This part:

 "type": "JwtProof2020",

comes from https://github.com/decentralized-identity/did-jwt-vc

[peacekeeper]

I have never seen JwtProof2020 before. Is it essentially the same as JsonWebSignature2020?

[kimdhamilton]

Essentially yes, and it comes from https://github.com/decentralized-identity/did-jwt-vc. I'd like us to update that library directly if feasible (needs some investigation), but either way we want to bring verite in line with https://github.com/decentralized-identity/JWS-Test-Suite.

[OR13]

I think there are a few differences:

JsonWebSignature2020

• uses https://datatracker.ietf.org/doc/html/rfc7797
• uses URDNA2015 RDF DataSet normalization
• pairs with JsonWebKey2020

JwtProof2020

• uses https://datatracker.ietf.org/doc/html/rfc7519
• no linked data semantic checking
• supports ES256K-R which allows for use with etheruem addresses (which are not JWKs)

neither of these approaches are "standard" in the sense that both are "Linked Data Proofs".

A standard VC-JWT should be a compact JWT conforming to rfc7519, using algorithms registered here:

https://www.iana.org/assignments/jose

[OR13]

There is some value is storing the "decoded compact jwt" as json... because it allows for querying of VC-JWT, and LD Proof based VCs consistently... however the decoded vc-jwt is not a "standard JWT"... and neither is "JwtProof2020"...

[OR13]

What happens when the outer proof json members are changed, and the don't look at the jwt.

[OR13]

Where is the spec for "JwtProof2020" is it going to be in scope for the vc wg charter?

[OR13]

Looks like some details are here: https://github.com/decentralized-identity/did-jwt-vc#notes-on-verification-and-proof-properties

[clehner]

Hi, JwtProof2020 looks to me like it might be useful; I replied to CCG about this, and mentioned this thread, here: https://lists.w3.org/Archives/Public/public-credentials/2022Feb/0146.html

[bumblefudge]

There is some value is storing the "decoded compact jwt" as json...

I'd go one further, and say that in a secure dB accessed only within a security perimeter, it makes perfect sense to store the credential (in the "intermediary, representation-independent pre-encoding format sense), once VCWG2 can define that normatively... hoping that can be done early in the career of VCWG2 so that we have something concrete to target.

[OR13]

yeah, agreed but credential does not have a "proof" !

[bumblefudge]

Fersure-- maybe instead of calling that algo JwtProof2020 we should call it JwtInsecureDecodedCredential2022 to make it more obvious to someone stumbling across it that the JWT is the verifiable credential and the proof isn't really functioning as one, so much as tombstoning/placeholding for one 😉

[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.

[OR13]

I added some suggestions for the path forward here: w3c/vc-wg-charter#84

All of them involve disambiguating VCs, JWTs and LD Proofs, and not mixing and not reusing json structure or terms.

[kimdhamilton]

I don't know what this thread is doing anymore so let's simplify.

@OR13 claims: conforming to https://github.com/decentralized-identity/JWS-Test-Suite will ensure we conform to the new/approved in VC2.0 VC-JWT

Is that true? If so, then this issue simply tracks making that happen. If not, I will close this issue.

[OR13]

@kimdhamilton I think its possible for did-jwt-vc to pass those tests... We have an issue open here to track that: decentralized-identity/JWS-Test-Suite#39

but the "thing" that proves that is a "compact proof jwt" (the proof.jwt field), not the JSON object.

[kimdhamilton]

Yes, the JSON object is just a processing artifact -- that's part of the "internal use" aspect.

I think that, for this project, it's cleaner to fix the problem directly in this library. My understanding is that did-jwt-vc doesn't have a clear "owner", and any non-trivial changes to that library would require a significant investment of time.

For now, let's track that separately. To clarify the scope of this issue, I struck item 3 from the original description

[kimdhamilton]

I see a big source of confusion in this thread -- there's an assumption that JwtProof2020 is the final signature suite; that is incorrect. The did-jwt-vc library clearly documents that's an intermediate form with a decoded json payload

There's a convention in some DIF specs to show intermediate decoded json payloads but it's always well-documented, and I didn't notice that we slipped in that ambiguity in some docs. We need to clarify that.

No offense, but I don't trust anyone but myself to fix this issue, so I'm poaching it.

[kimdhamilton]

I went ahead and added did-jwt-vc to the JWT-Test-Suite: https://github.com/decentralized-identity/JWS-Test-Suite/pull/44/files.

What's needed for verite repo:

• Ensure the payload munging applied in the test suite is done here
• Update verite dev docs in the following ways:
  • ala DIF specs, put scare-comments around expanded JWTs, when visible
  • wherever JwtProof2020 appears, clarify it is intermediate only
  • clarify (pre-signed) Credential vs Verifiable Credential

[kimdhamilton]

Note: did-jwt-vc does fail on credential-0. Opened issue on that repo to track: decentralized-identity/did-jwt-vc#106

[OR13]

@kimdhamilton vc-jwt has a lot of optionality, right now we are trying capture all the variability in one place.

next step is to make that variability illegal in vcdm2.0 so that everyone builds the same output from inputs, at least with respect the "required" fields.

so tldr, don't worry about failures... we are just greatful we can see the differences.

[kimdhamilton]

This PR #377 addresses the first checkbox.

There is more work to do to get the did-jwt-vc JWS Test suites fully passing, but I think it's best (for the benefit of everyone) to start by updating the did-jwt-vc tests in the JWS Test suites repo. Then I can ensure any changes (as needed) are applied here. Lastly, at that time, we'll also add verite as an implementation to that repo (to ensure we stay in sync).

@bumblefudge feel free to take over the doc changes and let me know if you have questions.

[bumblefudge]

Hey @kimdhamilton I tried cleaning up the docs a bit and being very explicit about what was a credential and what was a JWT, but I had a few question:

1. The PresEx objects are also big JWTs, right? They had proof objects that were either abbreviated as ... or, in some cases, were typed as JwtProof2020, so I assumed they were signed as VP-JWTs. If I am wrong on that, most of the non-example descriptive changes need to be reconsidered, or perhaps just scrap the PR and start over.
2. There are still some proof objects (some including "type":"JwtProof2020") in the code, such as in the issuer tests. Not really sure what to do about this, a touch above my paygrade!
3. I'm not sure "scare quotes around expanded JWTs" is coterminous with what I did! Could you give me an example from a DIF Spec for me to double-check?

[kimdhamilton]

Thanks @bumblefudge, we are good to go! I merged it.