- From: Brent Shambaugh <brent.shambaugh@gmail.com>
- Date: Fri, 23 Apr 2021 21:12:43 -0500
- To: Orie Steele <orie@transmute.industries>
- Cc: Credentials Community Group <public-credentials@w3.org>
- Message-ID: <CACvcBVrpbCmeuW1oS=U7NG2dn+zOfHeTas+uOk=ZuBMy_tnEhw@mail.gmail.com>
Thanks Orie. As I am a bit tired, I'll leave a link for now and think more later. This link references a pull request that I made with the ceramic network (formerly 3box). https://github.com/ceramicnetwork/js-ceramic/pull/1261 This is an exploratory project where I have a remote cryptographic coprocessor, and this is intended for the resolution part on the ceramic side. I agree with this statement: "we believe Linked Data should work with JOSE seamlessly". I hope more magic happens in this thread, and the whole community is somehow benefited. For now the pillow. "UnsupportedVerificationMethod2020" << very descriptive :) -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 Fri, Apr 23, 2021 at 8:09 PM Orie Steele <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 > > <https://www.transmute.industries> >
Received on Saturday, 24 April 2021 02:14:09 UTC