Re: AW: Can I only use JsonWebKey2020 with NIST approved curves like P-256 in the specification?

https://github.com/multiformats/multicodec/blob/master/table.csv#L83

^ this is essential what you are suggesting without using ASN.1, and it is
used to power did:key today.

The problem is the varying opinions on how to convert a compact key
representation with byte prefix into a did document with verification
methods.

I know @Manu Sporny <msporny@digitalbazaar.com> has opinions on this, and
tends to prefer new labels for key type + signature suites, rather than the
approach JOSE took.

It really boils down to what are you trying to express by disclosing a
verification method....

And regardless of what you say, you are disclosing a way to support key
agreement / ECDH and a way to support signature verification / ECDSA /
EdDSA, etc...

In the JOSE world, we have
https://www.iana.org/assignments/jose/jose.xhtml#web-key-use

If we want to try and fix some challenges with JOSE we could put the key
type and use in the key name... for example
EcdsaSecp256k1VerificationKey2019 vs SchnorrSecp256k1VerificationKey2019

https://identity.foundation/SchnorrSecp256k1Signature2019/
https://identity.foundation/EcdsaSecp256k1RecoverySignature2020/
https://w3c-ccg.github.io/lds-ecdsa-secp256k1-2019/

^ technically all 3 of these suites could use this public key....

{
        "id": "#zQ3shjC95SHwQqxwaB5Sdn4TGn1Przvo49z718JfSH6Nf4L6h",
        "type": "JsonWebKey2020",
        "controller":
"did:key:zQ3shjC95SHwQqxwaB5Sdn4TGn1Przvo49z718JfSH6Nf4L6h",
        "publicKeyJwk": {
          "kty": "EC",
          "crv": "secp256k1",
          "x": "Q6OJ2JN-61NP8UQe-ibKlKylb-SbydU-vbl02GXxOC4",
          "y": "NAvWo8XRE_QSgvapHBVZ1C8h3unpy8PtCX8LQqa5mlM"
        }
}

The debate has been over what to put in the type field... Should key type
limit supported algorithms, or is that like telling rain not to be wet?

Clearly secp256k1 is a good example of how bad this can get...

There is logic to making it harder to use the same key for multiple algs...
But that logic introduces interoperability pain... For example, now you can
have the following possible key conversion issues:

JsonWebKey2020 (secp256k1) -> EcdsaSecp256k1VerificationKey2019
| SchnorrSecp256k1VerificationKey2019 | EcdsaSecp256k1RecoverySignature2020

You might assume that JOSE registry would be all we need and we could do a
mapping like this:

`kty.crv.use.alg.year` or `kty.crv.use.alg`

But that won't work if the registry doesn't contain these terms... should
we wait a few years for it to be updated before using Secp256k1 or BLS12381?

This was a major reason for the use of JSON-LD with DIDs... using
decentralised registries enables much better inclusivity, speed, agility...

If you want to use Schnorr / BLS12381 you don't have to ask for permission
from a bunch of companies making money in the space with an incentive to
say no, you can just express how folks who want to interoperate with you
can do so.

It's not that LD can't work with JOSE, we showed that's possible if you
want it, and we fought super hard for JOSE inclusivity in DID Core... it's
that some folks want JOSE to not work with LD, and they keep introducing
small proposals that ultimately lead to a 100% reliance on centralized
registries and governance / censorship issues...

If I could delete `did+json` from did core right now, I would.

`did+json` is a primary attack vector for limiting decentralization, and
every single supporter of it is tied to some centralized solution provider
that has a natural ability to control centralized registries due to their
existing industry reputation.

`did+json` gives folks the option to be non-interoperable... and then
offers centralized registries as the solution... I wonder who will control
those registries?

It's making this problem way worse, and it's a trojan horse for the kind of
slow, non-inclusive experience that IANA / JOSE already have problems
with... DIDs were supposed to feel different.

1. Backwards compatibility should not shackle innovation
2. Innovation shouldn't go out of its way to destroy backwards
compatibility.

^ W3C DID Core started with too much of 2 and currently has too much of 1.

Another view of this might be that true decentralization is always a lie,
especially if decentralization means increasing costs for incumbents (who
have a financial preference for backwards compatibility), I might also cite
Scale free networks as evidence of this assertion:
https://en.wikipedia.org/wiki/Scale-free_network

FWIW, I believe it is possible to innovate and provide backwards
compatibility, it just means having more skill and putting in more effort.

OS



On Sat, Apr 24, 2021 at 7:58 AM David Chadwick <D.W.Chadwick@kent.ac.uk>
wrote:

> I agree, we should build on the experience of previous technologies and
> experts and turn the ASN.1  below into an equivalent JSON object
>
> Kind regards
>
> David
> On 24/04/2021 11:52, detlef.huehnlein@ecsec.de wrote:
>
> Dear Brent, Orie, all,
>
>
>
> could it make sense to create a generic verification method type, which
>
> is parametrized by something like an ASN.1 AlgorithmIdentifier?
>
>
>
> AlgorithmIdentifier  ::=  SEQUENCE  {
>
>         algorithm               OBJECT IDENTIFIER,
>
>         parameters              ANY DEFINED BY algorithm OPTIONAL  }
>
>
>
> At least from an old school PKI-minded perspective it seems to be
>
> odd to create a completely new verification method type for each and
>
> every signature algorithm.
>
>
>
> What do you think about creating such a generic verification method, which
> would
>
> be able to handle all “standard” digital signature algorithms?
>
>
>
> BR,
>
> Detlef
>
>
>
> *Von:* Orie Steele <orie@transmute.industries> <orie@transmute.industries>
> *Gesendet:* Samstag, 24. April 2021 04:19
> *An:* Brent Shambaugh <brent.shambaugh@gmail.com>
> <brent.shambaugh@gmail.com>
> *Cc:* Credentials Community Group <public-credentials@w3.org>
> <public-credentials@w3.org>
> *Betreff:* Re: Can I only use JsonWebKey2020 with NIST approved curves
> like P-256 in the specification?
>
>
>
> I suppose the correct thing to do here would be:
>
> A. Allow JsonWebKey2020 to support none publicKeyJwk material expressions
> (not add new NIST curve key types)
> B. Create P256ES256VerificationMethod2020 (etc) for all NIST Curves, and
> then allow them all to be used with JsonWebSignature2020
>
> B would be in the style of EcdsaSecp256k1VerificationKey2019 and
> Ed25519VerificationKey2018... both of which are used to verify detached JWS.
>
> A would be less work, but might require some explaining... luckily...
>
> The suite could explain the history of the anti JWK holy war, and how it
> was ultimately made irrelevant by giving suite authors the ability to
> support whatever they needed to make developers happy :)
>
> Happy to take feedback on what would make developers the most happy here.
>
> OS
>
>
>
> On Fri, Apr 23, 2021 at 8:08 PM Orie Steele <orie@transmute.industries>
> <orie@transmute.industries> wrote:
>
> Thanks for your question Brent!
>
> TLDR I don't think there are any official suite names for multibase
> encoded NIST curves... UnsupportedVerificationMethod2020 is my not so
> subtle swipe at the strategy of requiring a unique name for every
> registered kty and alg in IANA :)
>
> We created JsonWebKey2020 and JsonWebSignature2020 because we don't
> think you should have to have a new key and signature type for every JWS
> alg.
>
> The questions you are asking are a major part of why we created these
> suites... in essence, we believe Linked Data should work with JOSE
> seamlessly.
>
> We thought "UnsupportedVerificationMethod2020" was too snarky, so we
> decided to just stop saying it, and to make `JsonWebKey2020` support base58
> as well.
>
> our libraries handle key conversion for you so you don't need to worry
> about which side of this war you are on.
>
> I'm actually working on updating the contexts to align the new did
> core structurers right now:
>
>
> https://github.com/transmute-industries/ns.did.ai/blob/master/suites/jws-2020/v1/index.json#L25
>
> We can very easily allow publicKeyJwk, publicKeyBase58, publicKeyMultibase
> or just publicKeyJwk.
>
> How do folks want this to work?
>
> OS
>
>
>
>
>
>
>
>
> On Fri, Apr 23, 2021 at 5:05 PM Brent Shambaugh <brent.shambaugh@gmail.com>
> wrote:
>
> I have this for a NIST approved curve in my DID document:
>
>     "publicKeyJwk":  {
>           "crv": "P-256",
>           "kty": "EC",
>           "x": "u-cNviWRiM3i9wGjUvOB-0XyPpIb5rAwmE8o8jDBte7Y",
>           "y": "uHNNnF7isXk_qitI9yNB4PCMY7krXqA224AJq0LByok8",
>         },
>         "type": "JsonWebKey2020"
>
> I thought that nist based keys like P-256, p-384, and p-521 did not have a
> supported name type so one had to use the  catch all JsonWebKey2020. I
> cannot remember if there is a link.
>
> I'm trying to replicate my reasoning. I believe I looked at:
> https://www.w3.org/TR/did-spec-registries/ ,
>
> https://github.com/w3c/did-spec-registries/blob/main/cddl/verificationMethodTypes.cddl
> ,
>
> https://github.com/transmute-industries/did-key.js/blob/e0b4facde18691f914bb184dbb64e678601f0a88/packages/test-vectors/src/did-core-conformance/p-256/p-256.json#L23-L29
> , and perhaps several others
> and concluded that I could not match the a type property with a
> publicKeyBase58 encoded key .
>
>
> The earlier Transmute commit uses "type":
> "UnsupportedVerificationMethod2020"  in conjunction with a publicKeyBase58
> encoding. I take it that Orie is a significant driver in the specification,
> so he would be in the know.
>
> For the record the new version of this file no longer contains this block
> of code
> https://github.com/transmute-industries/did-key.js/blob/master/packages/test-vectors/src/did-core-conformance/p-256/p-256.json
> .
>
> https://tools.ietf.org/html/rfc7517#section-3 told me that I could
> express a publicKeyJwk key as a P-256 key. This was supported by
> JsonWebKey2020. There may have been another place that I read that p-256
> was only supported by
> JsonWebKey2020.
>
> Am I correct that I can only use JsonWebKey2020 and Json web keys? Not
> JsonWebKey2020  or some mystery type and publickeybase58 based on the
> specification?
>
> Thanks for your time, i
>
>
>
> -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
>
>
>
>
> --
>
> *ORIE STEELE*
>
> Chief Technical Officer
>
> www.transmute.industries
>
>
>
> [image: Das Bild wurde vom Absender entfernt.]
> <https://www.transmute.industries/>
>
>
>
>
> --
>
> *ORIE STEELE*
>
> Chief Technical Officer
>
> www.transmute.industries
>
>
>
> [image: Das Bild wurde vom Absender entfernt.]
> <https://www.transmute.industries/>
>
>

-- 
*ORIE STEELE*
Chief Technical Officer
www.transmute.industries

<https://www.transmute.industries>