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

Concerning semantics. type names here [1] don't appear to mean anything.
sure I can trick out what they mean because I know what the words mean, but
there is no taxonomy or ontology I know of that relates to them. [1]
https://w3c.github.io/did-spec-registries/

-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 Sat, Apr 24, 2021 at 4:00 PM Brent Shambaugh <brent.shambaugh@gmail.com>
wrote:

> I started looking at this a bit more, and I think it comes to whether you
> want human readable semantics.
>
> Here is what I found today:
>
>
>
>
>
>
>
>
> Human Readable Is the type name unique?
>
>
>
>
> publicKeyBase58 No Yes
>
>
>
>
> did:key formatting (multiformats/multicodec) No Unknown
>
>
>
>
> JsonWebKey2020 Yes No
>
>
>
>
> ASN One No Unknown
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Some Links I found while browsing:
>
>
>
>
>
>
> https://github.com/PeculiarVentures/ASN1.js PeculiarVentures/ASN1.js:
> ASN1js is a pure JavaScript library implementing a full ASN.1 BER decoder
> and encoder.
>
>
>
>
>
> https://en.wikipedia.org/wiki/ASN.1 ASN.1
>
>
>
>
>
> https://asn1.io/asn1playground/ ASN.1 Playground: ASN.1 compiler,
> encoder, decoder
>
>
>
>
>
> http://luca.ntop.org/Teaching/Appunti/asn1.html A Layman's Guide to a
> Subset of ASN.1, BER, and DER
>
>
>
>
>
> https://letsencrypt.org/docs/a-warm-welcome-to-asn1-and-der/
> A Warm Welcome to ASN.1 and DER - Let&#39;s Encrypt
>
>
>
>
> https://powerdns.org/hello-dns/ A warm welcome to DNS
>
>
>
>
>
> https://powerdns.org/hello-dns/basic.md.html A warm welcome to DNS
>
>
>
>
>
> https://tools.ietf.org/html/rfc5280 Internet X.509 Public Key
> Infrastructure Certificate and Certificate Revocation List (CRL) Profile
>
>
>
>
>
> https://www.rfc-editor.org/rfc/rfc3279.html Algorithms and Identifiers
> for the Internet X.509 Public Key Infrastructure Certificate and
> Certificate Revocation List (CRL) Profile
>
>
>
>
>
> https://tools.ietf.org/html/rfc5912 New ASN.1 Modules for the Public Key
> Infrastructure Using X.509 (PKIX)
>
>
>
>
>
> https://tools.ietf.org/html/rfc6025 ASN.1 Translation
>
>
>
>
>
> https://github.com/multiformats/multicodec/blob/master/table.csv
>
>
>
>
>
>
> https://github.com/YuryStrozhevsky/asn1-test-suite
>
>
>
>
>
>
> https://github.com/YuryStrozhevsky/C-plus-plus-ASN.1-2008-coder-decoder
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> In my journey with the distributed web I found proto school useful.
>
> https://proto.school/content-addressing
>
> https://proto.school/anatomy-of-a-cid   (includes multiformats)
>
> -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 Sat, Apr 24, 2021 at 12:31 PM Adrian Gropper <agropper@healthurl.com>
> wrote:
>
>> 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>
>>>
>>