Something to hack on: vc-js-cli

[mattcollier]

Hello All,

I see that verifiable credentials are a topic of interest for this hackathon. This CLI tool described in this demo may be of interest: https://github.com/digitalbazaar/vc-demo

It is currently possible to:

• Generate a Secp256k1 keypair.
  • The public key material and a controller document will automatically be uploaded as a gist to your github.
• Sign a VC document of your own design.
• Verify the signed VC.
  • The verifier retrieves controller and key documents from public gists.

Possible hackathon projects:

• Implement a key import feature that allows for creating the public key document from an existing WIF encoded key.
• Integrate with the btcr DID method and integrate with a DID resolver for dereferencing public key material.

Node.js Source Code

• https://github.com/digitalbazaar/vc-js-cli
• https://github.com/digitalbazaar/vc-js/tree/node-12
• https://github.com/digitalbazaar/ecdsa-secp256k1-signature-2019
• https://github.com/digitalbazaar/secp256-key-pair
• https://github.com/digitalbazaar/jsonld-signatures/tree/node-12

A sample signed VC looks like this. You should be able to verify this credential yourself using the vc-js-cli tool.

{
  "@context": [
    "https://www.w3.org/2018/credentials/v1",
    "https://www.w3.org/2018/credentials/examples/v1"
  ],
  "id": "https://example.com/credentials/1872",
  "type": [
    "VerifiableCredential",
    "AlumniCredential"
  ],
  "issuanceDate": "2010-01-01T19:23:24Z",
  "credentialSubject": {
    "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
    "alumniOf": "Example University"
  },
  "issuer": "https://gist.githubusercontent.com/mattcollier/bbeb042136d8c6971ec162236f0a77f2/raw",
  "proof": {
    "type": "EcdsaSecp256k1Signature2019",
    "created": "2019-08-01T13:49:11Z",
    "jws": "eyJhbGciOiJFUzI1NksiLCJiNjQiOmZhbHNlLCJjcml0IjpbImI2NCJdfQ..MEQCIBjyUUdGaXJE1GRu91XOU4C1BjUDp_JyxMLSY8MzxKfxAiA9SEbcPnWZh045oLx5aPzZlZABdnApkrL5bAyev29fLA",
    "proofPurpose": "assertionMethod",
    "verificationMethod": "https://gist.githubusercontent.com/mattcollier/c0b673cef7a764a85c12c813d4ca76ad/raw"
  }
}

[ChristopherA]

@mattcollier

I've have your cli tool running now.

The trick is to not brew install docker but use the cask version instead.

The instructions are brew cask install docker then run the docker app and approve it adding tools with your system password. You do not need to have a docker account to use — you skip that part.

The problem I'm running into now is that I can't find any convenient tools to convert testnet WIF (the standard for P2PKH private key) to your base58 format, or visa versa. All of my example transactions I have tesnet WIF keys for, but I can't use them for claims, and I can't use the keys you generate with your tools to generate testnet transactions as I need a testnet WIF. I have found some online WIF tools but they only work with mainnet WIFs.

The reason why WIF was defined was to a) have a checksum, as private keys are lossy, and b) make sure people didn't reuse keys on different networks like mainnet and testnet.

I note that the JSON-LD playground has javascript support for both mainnet and testnet WIF keys in its JSON-LD signing tool.

As soon as I've got this annoying thing worked out, I want to issue some real BTCR DID based credentials with my test DIDs.

-- Christopher Allen

[ChristopherA]

@mattcollier

A bug in your implementation. It does create the gists in https://gist.github.com/christophera however, executing the issuance example in the README issues a verifiable claim has your info as issuer in it. I shouldn't have to change the templates, the tool should automatically substitute to the issuer in the my-key.json.

https://gist.githubusercontent.com/ChristopherA/da71b16b6806b7d903cbd12e49dfe0dd/raw

{
  "id": "https://gist.githubusercontent.com/ChristopherA/66d5f652e7f530da7e1dfd7807d584cb/raw",
  "type": "EcdsaSecp256k1VerificationKey2019",
  "publicKeyBase58": "s8gu1Xiew572SuGK3sQfN27BEue51MZPNotZguXf3JU2",
  "@context": "https://w3id.org/security/v2",
  "controller": "https://gist.githubusercontent.com/ChristopherA/da71b16b6806b7d903cbd12e49dfe0dd/raw"
}

resulting alumni-signed.jsonld:

{
  "@context": [
    "https://www.w3.org/2018/credentials/v1",
    "https://www.w3.org/2018/credentials/examples/v1"
  ],
  "id": "https://example.com/credentials/1872",
  "type": [
    "VerifiableCredential",
    "AlumniCredential"
  ],
  "issuanceDate": "2010-01-01T19:23:24Z",
  "credentialSubject": {
    "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
    "alumniOf": "Example University"
  },
  "issuer": "https://gist.githubusercontent.com/mattcollier/aa6423214db5f012b77f4d5a347ac616/raw",
  "proof": {
    "type": "Ed25519Signature2018",
    "created": "2019-08-07T23:16:04Z",
    "jws": "eyJhbGciOiJFZERTQSIsImI2NCI6ZmFsc2UsImNyaXQiOlsiYjY0Il19..E7If3JhsqwjxgYvlESH5y2lNfYLqBzVxPyGzrilRZ3wzl_IWZ3GysRapRnSaZgLVR9AGaf-HapdnrZLfOzFSAw",
    "proofPurpose": "assertionMethod",
    "verificationMethod": "https://gist.githubusercontent.com/mattcollier/dda0d5e8a80993571e816a0f29cc9c06/raw"
  }
}

[mattcollier]

@ChristopherA I wonder if you may have an older version of the docker image.

can you try the following command and see if it downloads an update?

docker pull digitalbazaar/vc-js-cli:latest

[ChristopherA]

@mattcollier

No, the document still has you as issuer after docker digitalbazaar/vc-js-cli:latest and vc issue --key my-key.json < credentials/alumni.jsonld > alumni-signed.jsonld

-- Christopher Allen

[mattcollier]

@ChristopherA that was a fun bug. Thanks for testing!

Please do:

docker pull digitalbazaar/vc-js-cli:latest
alias vc='docker run -i -v $(pwd):/home/node/app/key-file digitalbazaar/vc-js-cli'

And give it another go.

I've updated the alias command here as well: https://github.com/digitalbazaar/vc-demo#create-an-alias

[ChristopherA]

@mattcollier

The latest results in another bug. I don't have a ed25519 key, only a Ecdsa key in my-key.json, but when I updated the alias, and then did vc issue --key my-key.json < credentials/alumni.jsonld > alumni-signed.jsonld I get a ed25519 VC.

{
  "@context": [
    "https://www.w3.org/2018/credentials/v1",
    "https://www.w3.org/2018/credentials/examples/v1"
  ],
  "id": "https://example.com/credentials/1872",
  "type": [
    "VerifiableCredential",
    "AlumniCredential"
  ],
  "issuanceDate": "2010-01-01T19:23:24Z",
  "credentialSubject": {
    "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
    "alumniOf": "Example University"
  },
  "issuer": "https://gist.githubusercontent.com/mattcollier/aa6423214db5f012b77f4d5a347ac616/raw",
  "proof": {
    "type": "Ed25519Signature2018",
    "created": "2019-08-07T23:16:04Z",
    "jws": "eyJhbGciOiJFZERTQSIsImI2NCI6ZmFsc2UsImNyaXQiOlsiYjY0Il19..E7If3JhsqwjxgYvlESH5y2lNfYLqBzVxPyGzrilRZ3wzl_IWZ3GysRapRnSaZgLVR9AGaf-HapdnrZLfOzFSAw",
    "proofPurpose": "assertionMethod",
    "verificationMethod": "https://gist.githubusercontent.com/mattcollier/dda0d5e8a80993571e816a0f29cc9c06/raw"
  }
}

-- Christopher Allen

[mattcollier]

@ChristopherA I see the latest signed VC example you gave is still referencing my mattcollier github account. This indicates that you may still be running on the old image. If you do docker image ls you should have an Image ID of 03b2924bcd0c. If this is not the case then you'll want to run that docker pull command again.

Another thing you can try is renaming your key file to my-secp.json or something like that.

The issue from earlier is that there was a key my-key.json from my system being baked into the docker image. This is no longer the case. That's why I think you may still be using the old image.

[ChristopherA]

I refreshed the image again, and renamed my key file, and that seems to have done the trick.

{
  "@context": [
    "https://www.w3.org/2018/credentials/v1",
    "https://www.w3.org/2018/credentials/examples/v1"
  ],
  "id": "https://example.com/credentials/1872",
  "type": [
    "VerifiableCredential",
    "AlumniCredential"
  ],
  "issuanceDate": "2010-01-01T19:23:24Z",
  "credentialSubject": {
    "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
    "alumniOf": "Example University"
  },
  "issuer": "https://gist.githubusercontent.com/ChristopherA/da71b16b6806b7d903cbd12e49dfe0dd/raw",
  "proof": {
    "type": "EcdsaSecp256k1Signature2019",
    "created": "2019-08-08T15:10:01Z",
    "jws": "eyJhbGciOiJFUzI1NksiLCJiNjQiOmZhbHNlLCJjcml0IjpbImI2NCJdfQ..MEUCIQCGMSkRuXUe-1mgj2WCR_bcfAXeAmb3rGoszNDgqy-ecQIgBdvJaYj4cprhpF892dcZ-7q3J54GrIhWNGin3bIzh18",
    "proofPurpose": "assertionMethod",
    "verificationMethod": "https://gist.githubusercontent.com/ChristopherA/66d5f652e7f530da7e1dfd7807d584cb/raw"
  }
}

[ChristopherA]

I'm still stumbling trying to find a testnet WIF private key to base58 and back conversion function that is keeping me from testing some real BTCR Verifiable Credentials.

https://en.bitcoinwiki.org/wiki/Wallet_import_format

-- Christopher Allen

[ghost]

Cool @mattcollier, got it working for me too.

@ChristopherA, would bitcoinjs-lib work for you?

Using fromPrivateKey and then toWIF

It looks like it supports the network command.

[ChristopherA]

would bitcoinjs-lib work for you?

@AnthonyRonning I've really no experience myself with javascript tooling (more a C/C++ guy). I'm fine if there is a web page out there that does the conversion so I can hack in the value into the template. The cli tool wants base58 because there is a schema for that, but that is non-standard in the bitcoin world doesn't use base58 for private keys.

[mattcollier]

Related issue about encoding of keys: w3c-ccg/didm-btcr#19

Also related: digitalbazaar/jsonld-signatures#74

[ghost]

@mattcollier and I were able to get a little project going for signing/verifying btcr based vc's. https://github.com/AnthonyRonning/vc-testing

Right now just hardcoded values, keydocs, and test credentials, but this is one of the signed vc's we have so far:

{
  "@context": [
    "https://www.w3.org/2018/credentials/v1",
    "urn:web-of-trust:context"
  ],
  "id": "urn:uuid:4f66661a-d387-446e-bb73-34c8fe603b1a",
  "type": [
    "VerifiableCredential",
    "WoTRelationshipCredential"
  ],
  "issuer": "did:btcr:xg35-jzrx-qtyt-jqr",
  "issuanceDate": "2010-01-01T19:23:24Z",
  "credentialSubject": {
    "id": "did:btcr:xg35-jzrx-qtyt-jqr",
    "knows": {
      "id": "did:btcr:8jal-lzzq-qqqq-69f7-ac",
      "publicKey": {
        "id": "did:btcr:8jal-lzzq-qqqq-69f7-ac#vckey-0",
        "type": "EcdsaSecp256k1VerificationKey2019",
        "publicKeyBase58": "Pnq3wLmbvyHqXWrV36kdfKfaq1hu7itBMdWrGWXgr53RF"
      }
    }
  },
  "proof": {
    "type": "EcdsaSecp256k1Signature2019",
    "created": "2019-08-14T05:11:48Z",
    "jws": "eyJhbGciOiJFUzI1NksiLCJiNjQiOmZhbHNlLCJjcml0IjpbImI2NCJdfQ..MEQCIGaVmQlhZHKPRORkFbaezwm8VdaOmOjo8WLd_dnKhPTYAiAnf30q6ENuXpIJMc1sYepZbDJcTaSWZYVkSHTlUftrzw",
    "proofPurpose": "assertionMethod",
    "verificationMethod": "did:btcr:xg35-jzrx-qtyt-jqr#vckey-0"
  }
}

Just a little note that it's resolving with this branch of btcr-did-js (https://github.com/WebOfTrustInfo/btcr-did-tools-js/tree/vc-capable), and I had to change the resolved context url from https://w3id.org/btcr/v1 to https://w3id.org/did/v0.11 for now until https://w3id.org/btcr/v1 gets hosted.

[ChristopherA]

@mattcollier is this demo still available and running? How out of date is it with current JSON-LD signing schemes from Digital Bazaar.

Also, how to I succinctly explain to someone that the JWS value doesn't make this JWS? I'm confused, and people wanting JSON-LD signing are confused to.

/cc @msporny @rxgrant @kimdhamilton

[mattcollier]

Hello Christopher, @dmitrizagidulin should be able to assist you with this.

[ChristopherA]

@mattcollier thanks!

@dmitrizagidulin — @rxgrant and @danpape need some examples of bitcoin signed documents to test their C++ library against. We are trying to get BTCR working, so we initially need to sign some DID extension documents, and then some VCs.

[dmitrizagidulin]

@ChristopherA got it, let me see if I can find / write up some examples for you.

As far as your earlier question, about JWS - so, that field contains a valid detached payload JWS string, as per RFC https://tools.ietf.org/html/rfc7797. Does that help?

[ChristopherA]

@dmitrizagidulin but is that an example of the current thoughts on JSON-LD signatures, or is it the JWS compromise?

[dmitrizagidulin]

@ChristopherA That is an example of current thoughts on JSON-LD signatures, yes. (There were compromises involved in arriving there, but that's the current state.)