Re: Recommendations for Storing VC-JWT

Clearly, we can do a better job of supporting database integrations with
VC-JWT in the future.

The solution I am leaning towards now is simply to store the data in
decoded form, and then re-encode it before calling verify.

This assumes that the data store will not tamper with the JSON member
order... With this assumption the possible solutions become much more
elegant and space efficient.

If you stored the decoded JSON in postman for example, you can re-encode it
before calling a verify endpoint in postman.

This is how we handle VC-JWT in the VC-API today.

This allows for JSON document based queries over any verifiable credential,
regardless of the proof type used (LD or JWT).

Regards,

OS



ᐧ

On Tue, Feb 22, 2022 at 1:19 AM David Waite <dwaite@pingidentity.com> wrote:

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



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

<https://www.transmute.industries>