W3C home > Mailing lists > Public > public-credentials@w3.org > February 2022

Recommendations for Storing VC-JWT

From: Orie Steele <orie@transmute.industries>
Date: Thu, 17 Feb 2022 08:21:18 -0600
Message-ID: <CAN8C-_Kx8GE-oscmXrqTwwaZXex8hd=3duJaf_Zn8u4VveoLAw@mail.gmail.com>
To: "W3C Credentials CG (Public List)" <public-credentials@w3.org>, Mike Jones <Michael.Jones@microsoft.com>, David Waite <dwaite@pingidentity.com>
Hey Folks,

As you know JWT compact representations are base64url encoded, making them
impossible to query over from a database like Cosmos, Neo4j, MongoDB etc.

A natural solution is to store the JWT in flattened form, like this:

However, it's not clear to me from the RFC what these actually look like...
this is what I want:

      "header": {
        "alg": "EdDSA",
      "payload": {
        "iss": "did:key:z6MkneEzjgD4Rerd14F62MmcKXY5LQsLQeY6UntTQmtSKwFh",
        "sub": "did:example:123",
        "vc": {
          "@context": [
          "id": "urn:uuid:494",
          "type": ["VerifiableCredential"],
          "issuanceDate": "2010-01-01T19:23:24Z",
          "credentialSubject": { "id": "did:example:123" }
        "jti": "urn:uuid:494",
        "nbf": 1262373804

If I can't represent a VC-JWT as JSON in a database, then I can't query
over its contents, which is important for many public credential use cases.

It would seem the rational thing to do is:

1. to store them decoded
2. store a decoded version next to the encoded version.

I would still avoid transmitting them decoded since JSON member order might
not be preserved, and reordering would break signatures.

My question are:

1. What is the name for the representation I gave above in JSON (is this
what flattened looks like), or is there a better way?
2. Which of the 2 storage options should JWT developers take, when planning
to query over JWT verifiable credentials?



Chief Technical Officer

Received on Thursday, 17 February 2022 14:21:43 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 24 March 2022 20:25:28 UTC