Re: Recommendations for Storing VC-JWT

Thanks for the reply!

So you're suggesting something like this:

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

The problem with this approach is the ambiguity regarding the shape of
"recoveredCredential"... 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.

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

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
>
> www.transmute.industries
>
>
>
> <https://www.transmute.industries/>
>
> ᐧ
>
>
>
>
> --
>
> *ORIE STEELE*
>
> Chief Technical Officer
>
> www.transmute.industries
>
>
>
> <https://www.transmute.industries/>
>
>
>

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

<https://www.transmute.industries>