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

I appreciate Orie’s sentiment about real decentralization but I'm a total
lamer when it comes to cryptography.

We have yet to find a wallet for the licensed practitioner in the HIE of
One demonstration. There’s no significant privacy issue because a licensed
fiduciary, like a doctor, almost always has to have a non-repudiable and
deduplicated identity to sign with.

(The patient in the HIE of One demo should not need a wallet any more than
they need one to see a doctor today.)

Even though the doctor is accountable and lacks some privacy, they should
be self-sovereign. Decentralization suggests that the doctor should not be
tied to any hospital or to a particular jurisdiction that may want to issue
them a credential. This implies standards constraints their choice of SSI
wallets.

Can folks help me understand the relationship between decentralization in
the use-case above and the technologies being discussed in this thread?

Adrian

On Sat, Apr 24, 2021 at 11:30 AM Orie Steele <orie@transmute.industries>
wrote:

> 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>
>