search

WebOfTrustInfo / btcr-hackathon-2019

BTCR Hackathon 2019
https://weboftrustinfo.github.io/btcr-hackathon-2019/
MIT License
2 stars 0 forks source link

Something to hack on: vc-js-cli #1

Open mattcollier opened 5 years ago

mattcollier commented 5 years ago

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:

Possible hackathon projects:

Node.js Source Code

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 commented 5 years ago

@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 commented 5 years ago

@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 commented 5 years ago

@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 commented 5 years ago

@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 commented 5 years ago

@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 commented 5 years ago

@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 commented 5 years ago

@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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

Related issue about encoding of keys: https://github.com/w3c-ccg/didm-btcr/issues/19

Also related: digitalbazaar/jsonld-signatures#74

ghost commented 5 years ago

@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 commented 4 years ago

@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 commented 4 years ago

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

ChristopherA commented 4 years ago

@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 commented 4 years ago

@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 commented 4 years ago

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

dmitrizagidulin commented 4 years ago

@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.)