Re: Recommendations for Storing VC-JWT

The payload of a JWS is binary, so the JSON serialization of a JWS document
(such as a JWT) will have a payload object with a base64url encoded string
representation. Likewise, a compact serialization turned into the JSON
serialization would not have a header property, but a protected header
property with a base64url encoded representation. The header property is
not integrity protected, so it is represented as a JSON object - but there
is no header property in your use case, where you are starting from a JWT.

If the goal is to re-verify the integrity of the data again in the future,
you should be able to break the three components of a compact JWS into a
table where you store the base64url decoded values, as long as the "b64":
false flag was not present in the protected header. This process is
reversible. You would want binary fields for the protected header and the
JWT JSON payload unless you know for sure that the data store will not
attempt to normalize the contents.

If the goal is to extract and normalize the data from the JWT, keep in mind
that the operation is one-way. So to support both this and the ability to
verify the integrity of the normalized data, the application would likely
want to regenerate and compare the normalized form after integrity checking
to what is in the data store. This one way normalization process has two
advantages - you can take whatever application-specific liberties are
desired for normalizing the data (including throwing away data which is not
currently needed), and on regeneration of the normalized form you can
diagnose what the failure was, rather than just seeing mismatched hashes.

-DW

On Thu, Feb 17, 2022 at 7:21 AM Orie Steele <orie@transmute.industries>
wrote:

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

-- 
_CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
material for the sole use of the intended recipient(s). Any review, use, 
distribution or disclosure by others is strictly prohibited.  If you have 
received this communication in error, please notify the sender immediately 
by e-mail and delete the message and any file attachments from your 
computer. Thank you._