Re: Building a did:key document with a publicKeyJwk

Thanks Nikos and David. fwiw, my progress:

There is a test vector for p-256. I'll have to try.
https://github.com/transmute-industries/did-key.js/blob/master/packages/test-vectors/src/did-core-conformance/p-256/p-256.json#L4

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

"publicKeyBase58"

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.

[1] https://gist.github.com/bshambaugh/cd24355a5d40f8688a70353f64b0413b

-Brent Shambaugh

GitHub: https://github.com/bshambaugh
Website: http://bshambaugh.org/
LinkedIN: https://www.linkedin.com/in/brent-shambaugh-9b91259
Skype: brent.shambaugh
Twitter: https://twitter.com/Brent_Shambaugh
WebID: http://bshambaugh.org/foaf.rdf#me


On Fri, Mar 12, 2021 at 5:41 AM David Chadwick <D.W.Chadwick@kent.ac.uk>
wrote:

> So why dont we just go ahead and define did:jwt?
>
> Kind regards
>
> David
> 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 https://github.com/w3c-ccg/did-method-key/issues/26 but I
> didn’t receive any response. In retrospect, probably this was not the best
> place to discuss this issue 😊
>
>
>
> *From:* David Chadwick <D.W.Chadwick@kent.ac.uk> <D.W.Chadwick@kent.ac.uk>
> *Sent:* Friday, March 12, 2021 11:33 AM
> *To:* public-credentials@w3.org
> *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.
>
> Thoughts?
>
> Kind regards
>
> David
>
> 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.
>
> https://gist.github.com/bshambaugh/0996f89023b54aababe1d5ff48a6ca2b
>
> 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
> https://w3c-ccg.github.io/lds-jws2020/ is missing the
>
> prefix u from https://github.com/multiformats/multibase I need to remove
> it.
>
>
>
> Thanks,
>
>
>
> Brent
>
>
>
>

Received on Friday, 12 March 2021 20:24:03 UTC