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

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