- From: Charles E. Lehner <charles.lehner@spruceid.com>
- Date: Sun, 25 Apr 2021 23:25:10 -0400
- To: public-credentials@w3.org
Hello,
There is an existing verification method type which I believe is for use with P-256: EcdsaSecp256r1VerificationKey2019.
EcdsaSecp256r1VerificationKey2019 and EcdsaSecp256r1Signature2019 have term definitions in CCG's Security Vocabulary JSON-LD context files [1, 2].
These two types are not listed in the Security Vocabulary's HTML page. I have not found a specification for them.
EcdsaSecp256r1Signature2019 is also defined in the Verifiable Credentials Data Model 1.0 Base Context [3, 4].
Spruce's ssi/DIDKit libraries [5, 6] implement EcdsaSecp256r1Signature2019, including publicKeyJwk, assuming parameters similar to those of other linked data signatures suites [7, 8], namely, URDNA2015 canonicalization [9] and SHA-256. I am unable to confirm, however, end-to-end interoperability with other implementations of this suite.
For P-384, JsonWebKey2020 could be used, according to its table [10, 11].
I think an ASN.1-based signature suite could be interesting, as an alternative to JWK and multiformats.
For decentralization vs. jurisdictions requiring certain standards: if verifiable credentials/presentations are to be used between parties with differing cryptographic requirements, I think they may need multiple signatures/proofs to satisfy the different requirements. A single issuer/holder could use multiple linked data proofs on a single document (verifiable credential or verifiable presentation). Verifiers with different requirements would verify the credential (and/or presentation) using the proof and verification method (public key) that they support. If a holder only needs to present with one type of key/signature, they could use an existing wallet. If they need to be able to present to different verifiers requiring different key/signature types, they would need the wallet to support the different types.
Regards,
Charles E. Lehner
[1] https://github.com/w3c-ccg/security-vocab/blob/938344d/contexts/security-v2.jsonld#L9
[2] https://github.com/w3c-ccg/security-vocab/blob/e230280/contexts/security-v3-unstable.jsonld#L449-L510
[3] https://www.w3.org/TR/vc-data-model/#base-context
[4] https://github.com/w3c/vc-data-model/blob/cd28fa0/contexts/credentials/v1#L124-L161
[5] https://github.com/spruceid/ssi/
[6] https://github.com/spruceid/didkit/
[7] https://w3c-ccg.github.io/lds-ecdsa-secp256k1-2019/
[8] https://github.com/w3c-ccg/lds-ed25519-2018/
[9] https://json-ld.github.io/rdf-dataset-canonicalization/spec/
[10] https://w3c-ccg.github.io/lds-jws2020/#jose-conformance
[11] https://github.com/w3c-ccg/lds-jws2020/blob/7f2458f/docs/index.html#L379
On Sat, 24 Apr 2021 16:25:30 -0500
Brent Shambaugh <brent.shambaugh@gmail.com> wrote:
> 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'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>
> >>>
> >>
Received on Monday, 26 April 2021 03:25:29 UTC