RE: Recommendations for Storing VC-JWT

In our open source project, we:


  1.  Decode and extract each assertion in a multi-assertion JWT individually in the DB to handle queries and UI presentations.
  2.  Store the encoded version in a data lake for transmission to other platforms or consumers.

https://opensource.ieee.org/ilr/ocp


Best,
Marty


Marty Reed | Chief Executive Officer
RANDA Solutions | 2555 Meridian Blvd | Suite 300 | Franklin, TN 37067
office 615 467 6387 | direct 615 915 5446 | fax 615 613 0517

Confidentiality Disclaimer: This email and any attached files are confidential and intended solely for the use of the individual or entity to which it is addressed. If you are not the person or entity to whom this is addressed, or the person responsible for delivery of this email to the intended recipient, you have received this email in error. Any use, dissemination, distribution, forwarding, printing or copying of this email including attachments is strictly prohibited. If you received this email in error, immediately delete it from your system without copying and notify the sender so that our records can be corrected.
From: Orie Steele <orie@transmute.industries>
Sent: Thursday, February 17, 2022 8:21 AM
To: W3C Credentials CG (Public List) <public-credentials@w3.org>; Mike Jones <Michael.Jones@microsoft.com>; David Waite <dwaite@pingidentity.com>
Subject: Recommendations for Storing VC-JWT

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: https://www.rfc-editor.org/rfc/rfc7515#section-7.2.2


However, it's not clear to me from the RFC what these actually look like... this is what I want:
{
      "header": {
        "alg": "EdDSA",
        "kid": "did:key:z6MkneEzjgD4Rerd14F62MmcKXY5LQsLQeY6UntTQmtSKwFh#z6MkneEzjgD4Rerd14F62MmcKXY5LQsLQeY6UntTQmtSKwFh"
      },
      "payload": {
        "iss": "did:key:z6MkneEzjgD4Rerd14F62MmcKXY5LQsLQeY6UntTQmtSKwFh",
        "sub": "did:example:123",
        "vc": {
          "@context": [
            "https://www.w3.org/2018/credentials/v1",
            "https://w3id.org/security/suites/jws-2020/v1"
          ],
          "id": "urn:uuid:494",
          "type": ["VerifiableCredential"],
          "issuer": "did:key:z6MkneEzjgD4Rerd14F62MmcKXY5LQsLQeY6UntTQmtSKwFh",
          "issuanceDate": "2010-01-01T19:23:24Z",
          "credentialSubject": { "id": "did:example:123" }
        },
        "jti": "urn:uuid:494",
        "nbf": 1262373804
      },
      "signature": "pRMwWUl1rjVpUIChduHosy2NeZfdeBo0jkWfLKVXfmVO8Q31PN3kcw0CGIG78hS0z9MdXnOV7L3mBQtKBslQDA"
    }

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?

Regards,

OS
--
ORIE STEELE
Chief Technical Officer
www.transmute.industries<http://www.transmute.industries>

[https://drive.google.com/a/transmute.industries/uc?id=1hbftCJoB5KdeV_kzj4eeyS28V3zS9d9c&export=download]<https://www.transmute.industries/>
ᐧ