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

RE: Recommendations for Storing VC-JWT

From: Marty Reed <Marty.Reed@randasolutions.com>
Date: Thu, 17 Feb 2022 15:40:52 +0000
To: Orie Steele <orie@transmute.industries>
CC: "W3C Credentials CG (Public List)" <public-credentials@w3.org>, Mike Jones <Michael.Jones@microsoft.com>, David Waite <dwaite@pingidentity.com>
Message-ID: <99a4cb283c5b4e09b5305e03d08ad4fa@randasolutions.com>

> Decode and extract each assertion in a multi-assertion JWT individually in the DB to handle queries and UI presentations.

This seems potentially very use case specific, and like your database will have to "know the shape" of all the credentials in wallets... I can see this leading to really beautiful UX, but challenging to maintain when new credential formats arise.
>> We’re using the IMS Global OpenBadges and CLR standards for the JSON assertions so the interpretations can be consistent.  Currently these standards are moving to a more directly VC compliant data model.

I am hoping for a solution that provides ok ux for arbitrary credential shapes... with minimal json transformation, and then leaving room for your approach at a higher level... something like:

credentials: [ { encoded, decoded }, { encoded, decoded }, ... ]

Where a query can be run over decoded that can power your app specific ui / ux considerations.

I am concerned that there might be a lot of variability in the "decoded" representation that would be harmful for interop... if we don't use a standard form for the decoded representation. It sounds like you don't have a standard form for it.

> Store the encoded version in a data lake for transmission to other platforms or consumers.

This seems to confirm my thoughts regarding the encoded version... it probably needs to be preserved exactly as it was received, along with some metadata.

>> We preserve the original authoritative issuer in this way but curious as to other approaches.

-M

ᐧ

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

On Thu, Feb 17, 2022 at 8:28 AM Marty Reed <Marty.Reed@randasolutions.com<mailto:Marty.Reed@randasolutions.com>> wrote:
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<mailto:orie@transmute.industries>>
Sent: Thursday, February 17, 2022 8:21 AM
To: W3C Credentials CG (Public List) <public-credentials@w3.org<mailto:public-credentials@w3.org>>; Mike Jones <Michael.Jones@microsoft.com<mailto:Michael.Jones@microsoft.com>>; David Waite <dwaite@pingidentity.com<mailto: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/>
ᐧ


--
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/>
Received on Thursday, 17 February 2022 15:41:12 UTC

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