Add multikey 2021

[OR13]

This PR is sadly necessary to handle cases where there is no JSON-LD support for standard NIST curves like P256.

I did my best not to trigger you @msporny but we can't possible support did:key without this, hopefully its acceptable.

My sense is that the LD Sec WG Suite imp guide will have a large section on best practices in this regard, and we can elaborate on the pro's and con's of type there.

[davidlehn]

Should this be merged? This is ok as far as w3id procedures are concerned. @msporny was there some issue that needed to be resolved first? I'm not sure how this is being used, but the name "multibase-2021" seems off since the context looks to be a collection of key and signature types, not various base encodings. (Is there somewhere better to discuss technical details of this?)

[msporny]

This PR is sadly necessary to handle cases where there is no JSON-LD support for standard NIST curves like P256.

Isn't the only thing necessary there is to create an EcdsaSignature2021 suite (or similar) and a Secp256r1VerificationKey2021 (or similar)? We don't have to support all variations, do we?

we can't possible support did:key without this, hopefully its acceptable.

I don't understand this statement... isn't this conflating multibase/multicodec encoding w/ cryptosuite naming?

[OR13]

@msporny I took your proposed name change, the issue is a general one, for all these keys: https://www.iana.org/assignments/jose/jose.xhtml#web-key-elliptic-curve
which we support with JWK, we want to support did:key as well.

You are right that I could create a linked data suite per key type, but thats not how JOSE really works, and it's also not how JsonWebKey2020 works.

IMO we need to show that all variations can be supported, but we don't need to actually use all of them.

This is part of showing that we are improving things, its hard to argue that a subset of IANA / JWK is better than a superset, especially when it doesn't cover NIST / FIPs crypto.

[OR13]

Implemented the needed change on our side: transmute-industries/ns.did.ai@43a5cd3

This PR is blocking our ability to register our did key implementation in the did core test suite, and our ability to update the dicd core examples.

Related PR: transmute-industries/did-core#20

We can register without the w3id.org redirect, but it feels like bad form to do so, so we are considering it blocked.

[OR13]

@msporny this PR is blocking our did test suite registration but only for JSON-LD.

[OR13]

@davidlehn @msporny eta on merge for this? or are there more changes requested?

[msporny]

@davidlehn @msporny eta on merge for this? or are there more changes requested?

Apologies @OR13 -- I'm not getting these direct pings in my email for some reason. @davidlehn ping'd me. Looking now.