- From: Alan Karp <alanhkarp@gmail.com>
- Date: Thu, 17 Feb 2022 09:09:26 -0800
- To: Orie Steele <orie@transmute.industries>
- Cc: "W3C Credentials CG (Public List)" <public-credentials@w3.org>, Mike Jones <Michael.Jones@microsoft.com>, David Waite <dwaite@pingidentity.com>
- Message-ID: <CANpA1Z2Ucz4jb40SbPQ0sc+09QeuzrfM_-f+Jb-HNhYN-Zk-=g@mail.gmail.com>
On Thu, Feb 17, 2022 at 6:24 AM Orie Steele <orie@transmute.industries>
wrote:
>
> I would still avoid transmitting them decoded since JSON member order
> might not be preserved, and reordering would break signatures.
>
It is possible to preserve signatures when member order changes by using a
set hash, as we did in
https://www.hpl.hp.com/techreports/2003/HPL-2003-235R1.html. I'm not
necessarily recommending doing that, just point out that reordering isn't a
total showstopper.
--------------
Alan Karp
On Thu, Feb 17, 2022 at 6:24 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>
> ᐧ
>
Received on Thursday, 17 February 2022 17:09:52 UTC