On 17/02/2022 17:01, Orie Steele wrote:
Thanks for the reply!

So you're suggesting something like this:

originalVerifiableCredential = JWT as String
recoveredCredential = decodeAndRestructure(JWT) as JSON
db.save({ originalVerifiableCredential, recoveredCredential })

Yes something like this (only in our approach I stuck a proof property into the credential and put the JWT in there. Non-standard I know, but its only our internal representation of a JWT proofed credential. (I did argue for JWT proof types to be added to the VC data model v1, but this was not accepted).



The problem with this approach is the ambiguity regarding the shape of "recoveredCredential"..

Yes I know we discussed this regarding properties that don't fully transpose such as the timestamps. Your solution was to duplicate the properties rather than replace them. Duplication means that you would simply throw away the JWT timestamps when creating the credential for storage. Then you would remove any ambiguity. (Of course if you were getting a JWT VC from an issuer who is not using your software then this would not work if they were using replace rather than duplication. Hopefully we can fix this in v2.0)


. but I agree that if that ambiguity were removed via  VCDM 2.0 spec text, this would probably be optimal... because it would allow you to query credential claims regardless of proof format, from a common JSON structure.

Exactly. This is my ultimate objective.



I suppose I could implement this even on top of v1.1... do you think that's the best approach for now?

In my opinion yes.

Kind regards

David


OS


On Thu, Feb 17, 2022 at 10:34 AM David Chadwick <d.w.chadwick@verifiablecredentials.info> wrote:
Hi Orie

as you know we spent quite some time on the text in the VC Data Model v1.1 to differentiate between a credential and a verifiable credential, and to highlight that regardless of the proof format (JWT, LD-Proof etc) the credential is always the same once the proof has been removed.

Therefore the obvious way to me to store any type of VC in a wallet is to store the credential as JSON, along with the proofed VC,  then the same wallet will be able to receive any type of proofed VC and store the embedded credential in the same way. I have also been highlighting this model in the DIF PE group, so that the same Presentation Definition can be used by any wallet to select any type of credential, regardless of the proof type.

Kind regards
David


On 17/02/2022 15:40, Marty Reed wrote:


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

 


 

--

ORIE STEELE

Chief Technical Officer

 




--
ORIE STEELE
Chief Technical Officer