Re: Recommendations for Storing VC-JWT

Thanks for the quick reply!

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

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.

Regards,

OS

ᐧ

On Thu, Feb 17, 2022 at 8:28 AM Marty Reed <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>
> *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
>
>
>
> <https://www.transmute.industries/>
>
> ᐧ
>


-- 
*ORIE STEELE*
Chief Technical Officer
www.transmute.industries

<https://www.transmute.industries>