Re: Building a did:key document with a publicKeyJwk

And a Go one is here:

Extracting the public key bytes and the multicodec code:

Used in the did:key vdr:

From: Wayne Chang <>
Date: Friday, March 12, 2021 at 4:19 PM
To: Brent Shambaugh <>, David Chadwick <>
Cc: Nikos Fotiou <>, W3C Credentials CG <>
Subject: Re: Building a did:key document with a publicKeyJwk
CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.

Hi Brent, DIDKit has a P-256 implementation in Rust for did-key too in case it helps.

Here's the test:

- Wayne

On Fri, Mar 12, 2021, at 3:23 PM, Brent Shambaugh wrote:
Thanks Nikos and David. fwiw, my progress:

There is a test vector for p-256. I'll have to try.

Also, I found that digitalbazaar did work on a npmjs package for creating base64urls called base64url-universal. Performing an experiment [1] tells me the output of doing this on a uint8array gives the same output as the multibase minus the "u" prefix.

There is also a npmjs package called base64url. I actually found this before base64url-universal. Digging and questioning led me to believe that perhaps this wouldn't work since I was not feeding a string, however in the experiment [1] (now updated due to writing) it does and produces the same result so far. It is more in my comfort zone to
use "base64url-universal". I noticed that base64url did not include TypeScript. It could be an interesting  exercise to develop my TS chops seeing what I can do.
As this community is good about dogfooding, I am assuming that MAY be appropriate to omit the u. I'm sure I'll be spending more time reading. I developed the impression, perhaps by reading in some former day that

is not appropriate for NIST based keys, so one has to use publicKeyJwk, or at least my favorite curve for the time being, secp256r1 a.k.a P-256.
This group seems to be greatly in favor of Ed25519. I have this curve too, but due to legacy reasons I am using P-256.


-Brent Shambaugh




Skype: brent.shambaugh


On Fri, Mar 12, 2021 at 5:41 AM David Chadwick <<>> wrote:

So why dont we just go ahead and define did:jwt?

Kind regards

On 12/03/2021 10:45, Nikos Fotiou wrote:

We had a similar issue, we wanted to use base64url encoded ED25519 public keys directly with did:key  In theory this should be supported since did:key uses multibase and at the end this is what we did (internally). Nevertheless, the specifications seem to enforce base58 encoding. I created this issue but I didn’t receive any response. In retrospect, probably this was not the best place to discuss this issue 😊

From: David Chadwick <><>
Sent: Friday, March 12, 2021 11:33 AM
Subject: Re: Building a did:key document with a publicKeyJwk

Hi Brent

we already build DID keys using RFC 7517 and I documented this many months ago on the list when did:key was first proposed. I suggested did:key:jwt as the prefix to this method but this was rejected by the did:key authors. Nevertheless we went ahead anyway and we have been using this encoding method successfully in user trials for many months.

I am thinking of simply registering did:jwt as a separate method. The advantage of this method is that canonicalisation is not needed, base64 is used, human reading of the key is never needed or involved so base58 is not necessary.


Kind regards


On 12/03/2021 03:45, Brent Shambaugh wrote:

Dear all,

I am building a did:key document. The base64url for multibase puts a u prefix in front. In my publicKeyJwk I keep the prefix for the x and y coordinates of the key. I've attached some scratch code.

Would it be correct, or incorrect to remove the prefix? I am not sure what to make of RFC7518.

Perhaps since the example with P-256 is missing the

prefix u from I need to remove it.



This email and any attachments are for the sole use of the intended recipients and may be privileged, confidential or otherwise exempt from disclosure under law. Any distribution, printing or other use by anyone other than the intended recipient is prohibited. If you are not an intended recipient, please contact the sender immediately, and permanently delete this email and its attachments.

Received on Friday, 12 March 2021 21:26:41 UTC