W3C home > Mailing lists > Public > public-credentials@w3.org > July 2017

Re: creator prefix scheme in Koblitz signature specification

From: Kim Hamilton Duffy <kim@learningmachine.com>
Date: Wed, 19 Jul 2017 02:01:46 +0000
Message-ID: <CAB=TY87Tb1BzPxm_oRbdsRFma1E-CKx5hHZ9G7qJF=BGAirivQ@mail.gmail.com>
To: Christopher Allen <ChristopherA@blockstream.com>, Manu Sporny <msporny@digitalbazaar.com>, Harlan T Wood <harlan@comakery.com>, Dave Longley <dlongley@digitalbazaar.com>, "W3C Credentials CG (Public List)" <public-credentials@w3.org>, "W3C Digital Verification CG (Public List)" <public-digital-verification@w3.org>, Nate Otto <nate@ottonomy.net>
Looping back to this, if one wanted to use actual bitcoin addresses, it
seems there is precedent for "bitcoin:" as a URI prefix.

It's more compact and immediately grokable (to laypeople) than
“ecdsa-koblitz-pubkey-hash-base58check", but not as precise I realize.

On Fri, Jul 7, 2017 at 5:30 PM Christopher Allen <
ChristopherA@blockstream.com> wrote:

> There are some errors in the ecdsa-koblitz-pubkey as we are using it in
> our signature format and playground. Not sure where to put the issues.
>
> The playground currently generates:
>
> {
>   "@context": [
>     "https://schema.org/",
>     "https://w3id.org/security/v1"
>   ],
>   "claim": {
>     "id": "did:btc1:298347982739",
>     "name": "Jane Doe",
>     "jobTitle": "Professor",
>     "telephone": "(425) 123-4567",
>     "url": "http://www.janedoe.com"
>   },
>   "signature": {
>     "type": "EcdsaKoblitzSignature2016",
>     "created": "2017-07-07T23:46:14Z",
>     "creator": "ecdsa-koblitz-pubkey:1LGpGhGK8whX23ZNdxrgtjKrek9rP4xWER",
>     "signatureValue":
> "H1ngGC22jRP1P1XDNvanxzILATbbLo2SpqcseDHKyuY+KbBqYLk/KlKnP+SePVv3cPH+pIoXzPxuc32W8rZI7aY="
>   }
> }
>
> However, in fact the value under creator, currently specified as
>
>     “creator": "ecdsa-koblitz-pubkey:1LGpGhGK8whX23ZNdxrgtjKrek9rP4xWER",
>
> Is in fact not a public key, but base58-check hash of the public key.
>
> The private key for our demo is also a base58check encoded value of the
> full private key: L4mEi7eEdTNNFQEWaa7JhUKAbtHdVvByGAqvpJKC53mfiqunjBjw
>
> However, there is no standard base58-check for public keys (a prefix such
> that the value starts with 4 was proposed but never implemented), but there
> are tools you can see that the compressed public key (we don’t used
> uncompressed anymore) for that private in hex
> 020d79074ef137d4f338c2e6bef2a49c618109eccf1cd01ccc3286634789baef4b and the
> base58check is 1LGpGhGK8whX23ZNdxrgtjKrek9rP4xWER
>
> Thus to correct, this means that the default example should look like:
>
>     “creator":
> "ecdsa-koblitz-pubkey:020d79074ef137d4f338c2e6bef2a49c618109eccf1cd01ccc3286634789baef4b",
>
> or possibly:
>
>     “creator”:
> “ecdsa-koblitz-pubkey-hex:020d79074ef137d4f338c2e6bef2a49c618109eccf1cd01ccc3286634789baef4b”,
>
> I’d actually prefer to use bech32 public key, which need some thinking
> about prefix but something like (not a correct value like the other ones as
> I don’t have a bech32 encoder working yet but just for reference):
>
>     “creator”:
> “ecdsa-koblitz-pubkey-bech32:1qw508d6qejxtdg4y5r3zarvary0c5xw7kv8f3t4”
>
> The current way we are doing could be useful if a hash of the public key
> is useful for blinding purposes (I’m not sure if it actually is, as at best
> it should be memory hard like SCRYPT), but if it is supported, it would be
> something like:
>
>      “creator”:
> “ecdsa-koblitz-pubkey-hash-base58check:1LGpGhGK8whX23ZNdxrgtjKrek9rP4xWER”,
>
> There may be some way to specify encoding type in JSON-LD differently, but
> I’m not sure.
>
> Another problem with the playground it is that it doesn’t have an issuer,
> and I’m confused on what the ID values should.
>
> Here is a test with real bitcoin values that should validate with the
> current tools (if we had a working validator), and a real bitcoin key that
> I’m playing around with for my first real DID with a DDO (which will reside
> in my github at
> https://raw.githubusercontent.com/ChristopherA/self/master/ddo.jsonld )
>
> {
>   "@context": [
>     "https://schema.org/",
>     "https://w3id.org/security/v1"
>   ],
>   "id": "DID:BTCR:TBD#SOMEVALUE",
>   "type": [
>     "Credential",
>     "WebOfTrustCredential"
>   ],
>   "issuer": "DID:BTCR:TBD#SOMEOTHERVALUE",
>   "claim": {
>     "id": "DID:BTCR:TBD#SOMETHIRDVALUE",
>     "alternatename": "ChristopherA",
>     "url": "
> https://raw.githubusercontent.com/christophera/self/master/ddo.jsonld",
>     "publicKey":
> "02c490e19e936efab022bd9fc12833db082706473fd96cec14c4a8dac058a0dbee"
>   },
>   "signature": {
>     "type": "EcdsaKoblitzSignature2016",
>     "created": "2017-07-08T00:21:53Z",
>     "creator": "ecdsa-koblitz-pubkey:1P8BWgokGDiqPYc3kgDDgn5Vm9XD1YUjEe",
>     "signatureValue":
> "H/2e5KiopVH3glkoDf/yP/dwScEP0HPZioxNffvalkyUFYDX7OJ/4uKs6gPqjCISpR3DUe1PKTOVE6MSSTS8AeE="
>   }
> }
>
> — Christopher Allen
>
> --
Kim Hamilton Duffy
Principal Engineer | Learning Machine + MIT Media Lab
Co-chair W3C Credentials Community Group
400 Main Street Building E19-732, Cambridge, MA 02139
12001 N. Central Expy, Suite 1025, Dallas, TX 75243

kim@learningmachine.com | kimhd@mit.edu
425-652-0150 | LearningMachine.com
Received on Wednesday, 19 July 2017 02:02:27 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 24 March 2022 20:24:44 UTC