- 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