c++ based json-ld signing https://github.com/digitalbazaar/rdf-canonize-native

Longley did mention that we do have a C++ implementation of the RDF Dataset Canonize function, which means that if you got a C++ implementation of JSON-LD .expansion() and .toRdf(), that's all you'd need to do native BTCR and native mobile development... that's more like possibly a lot of work.

This affects code samples, libraries and method spec

When txout is 0, the short form of the btcr did (with testnet, this yields the x prefix) should be used.

BIP136 supports both forms for index 0, but we are making the decision that BTCR supports only the short form when index==0.

Reason: shorter, and it's a potential security risk to allow 2 formats

• txref "x"/"8" issue, need playground javascript to do right thing #5
• Update this code https://github.com/WebOfTrustInfo/btcr-did-tools-js
• Note that btcr-did-tools-js gets browserified and copied into playground

to: @danpape
cc: @mattcollier @kimdhamilton @rxgrant

Daniel,

I thought the txref magic code for testnet would mean that it would always begin with x. How does one differentiate between mainnet and testnet now? Is this a bug in the playground txref code?

You have my testnet DID in the playground now as: 

DID: did:btcr:8yv2-xzpq-qqqq-9yce-nk

• TRANSACTION:

• TxRef: 8yv2-xzpq-qqqq-9yce-nk
• Block Height: 1152194
• Position: 0
• Tx Output: null
• TxId: f8cdaff3ebd9e862ed5885f8975489090595abe1470397f79780ead1c7528107
  https://blockstream.info/testnet/tx/f8cdaff3ebd9e862ed5885f8975489090595abe1470397f79780ead1c7528107
• OP_RETURN: https://raw.githubusercontent.com/ChristopherA/self/master/ddo.jsonld
• Public Key Hex: 02b97c30de767f084ce3080168ee293053ba33b235d7116a3263d29f1450936b71
• Private Key WIF: ASK ME

• TIP:

• Unspent Tip Address: mqkvMtYfTufj3iEXjYHmnopZrsowMFxrKw
• https://blockstream.info/testnet/address/mqkvMtYfTufj3iEXjYHmnopZrsowMFxrKw
• Public Key: Undisclosed
• Private Key WIF: ASK ME

This should eventually our canonical DID reference from things like our implicit DID Document, and ultimately our Extended DID Document.

-- Christopher Allen

Satoshi audit trail should be part of DID resolution metadata. How should this be represented?

One of our goals for this hackathon was to have everyone create a BTCR DID and have simple web of trust "know" claims between all of us (knows being available in https://w3id.org/identity/v1)

@mattcollier could you help us get a valid VC template (for your -cli tool) that expresses a simple knows claim? Maybe a couple of others that use other non-personal data items from https://w3id.org/identity/v1 ?

The best example we have is from @dlongley last year: w3c/vc-data-model#32 (comment) but there is more debate on what these should look like in that issue:

// This credential states that Alice knows Bob, and Bob has a public key X
{
"@context": [ "https://w3id.org/identity/v1" ],
"id": "did::Alice#CREDENTIAL1",  // this credential lives in the DDO (although, this is not necessary)
"type": ["Credential", "WoTRelationshipCredential"],
"issuer": "did::Alice",
"issuanceDate": "2010-01-01T19:23:24Z",
"credentialSubject": {
  "id": "did::Alice",  
  "knows": {
    "id": "did::Bob" // Alice is claiming that she knows Bob
    "publicKey": {
      "type": "EcdsaKoblitzPublicKey",
      // Alice is claiming that Bob's public key  SHA-256 fingerprint is this
      "sha256Fingerprint": "25FE3932D9...8B9316" 
    }
  }
},
"proof": {
    "type": "EcdsaSecp256k1Signature2019",
    "created": "2019-08-08T15:10:01Z",
    "jws": "eyJhbGciOiJFUzI1NksiLCJiNjQiOmZhbHNlLCJjcml0IjpbImI2NCJdfQ..MEUCIQCGMSkRuXUe-1mgj2WCR_bcfAXeAmb3rGoszNDgqy-ecQIgBdvJaYj4cprhpF892dcZ-7q3J54GrIhWNGin3bIzh18",
    "proofPurpose": "assertionMethod",
    "verificationMethod": "did::Alice#key-1"
  }
}

I've compromised myself 🥇

I added a leaked private key to my brand new BTCR DID :(

Its for testing purposes for decentralized-identity/.well-known#2

Since I'm new to BTCR, I understand that I can just commit to: https://github.com/OR13/self/blob/master/ddo.jsonld

And remove the public key, should I be aware of anything else?

The private key used to create the DID has not (to my knowledge) been stolen.

Let's kick it off here. Many of our names are outdated. What should they be now?

Naming discussion

• continuation/final/constructed DID Document
• implicit DID Document
• service/proof purpose
• audit trail generic vs specific (aka satoshi)

I get the following build errors when running through the instructions https://github.com/kulpreet/btcr-service

specifically, go build

# github.com/kulpreet/btcr-service src/github.com/kulpreet/btcr-service/decodeTxref.go:40:47: assignment mismatch: 6 variables but util.Decode returns 5 values src/github.com/kulpreet/btcr-service/resolvetodid.go:54:41: assignment mismatch: 6 variables but util.Decode returns 5 values src/github.com/kulpreet/btcr-service/tip.go:51:41: assignment mismatch: 6 variables but util.Decode returns 5 values src/github.com/kulpreet/btcr-service/txref2txid.go:43:41: assignment mismatch: 6 variables but util.Decode returns 5 values The command '/bin/sh -c go get github.com/kulpreet/btcr-service' returned a non-zero code: 2

Discussion

• What about colons in query part of DID string?
• Kim: this is a broader question. Need to check in with Markus
• ChristopherA: what about hyphens?
• Ryan: we need to decide consistent way to handle. Will check with Dan Pape
• bech32 BIP ?? & txref BIP 136 ignores hyphens

Decisions? (Note that some of this seems inconsistent with tx output 0 handling, where we treat as error)

• This be defined as part of the method-specific separator
• BTCR DIDs will have a technique to be canonicalized
• Use the BTCR method's DID canonicalization when comparing BTCR DIDs.

• Need library/tool to convert WIF to base58
• Many tools don't work with mainnet
• Must work with testnet

The only implicit capability currently provided is Auth. We need to add a VC signing capability. How should this be represented?

We need to have a canonical BTCR 'implicit' DID Document.

This is the one I'm playing with now — but I believe all the values are correct.

@mattcollier: there is no btcr @context schema yet, but does it look basically correct?

@peacekeeper: are the key types correct now?

@rxgrant, @kimdhamilton: does this look like a good minimal satoshi audit trail set?

all: Looking for a better name for the tip, currently unspent-tip-address-base58

@peacekeeper, @msporny: Instead of the tip being in the satoshi audit block, should it instead be in a standard control proof DID block? It isn't the public key, it is hash of the public key.

{
    "@context": ["https://w3id.org/did/v0.11", "https://w3id.org/btcr/v1"],
    "id": "did:btcr:xyv2-xzpq-q9wa-p7t",
    "publicKey": [
        {
            "id": "did:btcr:xyv2-xzpq-q9wa-p7t#keys-1",
            "owner": "did:btcr:xyv2-xzpq-q9wa-p7t",
            "type": "EcdsaSecp256k1VerificationKey2019",
            "publicKeyHex": "02b97c30de767f084ce3080168ee293053ba33b235d7116a3263d29f1450936b71"
        }
    ],
    "authentication": [
        {
            "type": "EcdsaSecp256k1AuthenticationKey2019",
            "publicKey": "#keys-1"
        }
    ],
  "service": [
    {
      "id": "did:btcr:xyv2-xzpq-q9wa-p7t#DCS",
      "type": "DIDDocumentContinuationService",
      "serviceEndpoint": "https://github.com/ChristopherA/self/blob/master/ddo.jsonld"
    },
    {
      "id": "did:btcr:xyv2-xzpq-q9wa-p7t#CRS",
      "type": "CredentialRepositoryService:BTCR",
      "serviceEndpoint": "https://github.com/ChristopherA/self/blob/master/ddo.jsonld"
    }
  ],
}

The audit trail for this (to be sent as optional data by the DID Resolver) is:

{
"SatoshiAuditTrail": [
        {
            "blockhash": "00000000b3487880b2814da8c0a6b545453d88945dc29a7b700f653cd7e9cdc7",
            "blockindex": 1,
            "outputindex": 1,
            "blocktime": "2019-08-07T08:20:50Z",
            "burn-fee": -0.05,
            "bond-value": 1.3,
            "unspent-tip-address-base58": "mqkvMtYfTufj3iEXjYHmnopZrsowMFxrKw"
        }
    ]
}

It was requested that we need a BTCD backend which accepts RPC calls for use with the playground.

BTCR DID Method spec and libraries/samples will need to be updated

See #4 for type reference

• Decision 1: per #9, Satoshi audit trail is not part of the DID document; instead it is DID resolver metadata.
  • this metadata should only be returned for implicit DDOs
• Decision 2: OP_RETURN clarification
  • OP_RETURN points to a URL that returns a JSON object (or array of JSON objects)
  • It's possible that none of these objects are a continuation DDO (id'd by type ContinuationService; see #4 )
• Decision 2a: There are 2 cases that may lead to implicit DDOs
  • Case 1: TX no OP_RETURN (no change here)
    • Verification/Auth key is signing key
    • Resolver must create/return Satoshi audit trail as resolver metadata
  • Case 2: TX with OP_RETURN and is URL. But the URL returns no JSON object with type ContinuationService
    • Same as Case 1 + Verification/Auth key is signing key of every object at that location
• Decision 4: if JSON object returned from OP_RETURN has type CredentialRepositoryService:BTCR (see #4) then that is a VC repo
  • these must be signed by implicit DDO key
• Decision 5: Resolver Failfast behavior
  • can't replace key-1 (must exist and be the same)

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"
  }
}

https://github.com/WebOfTrustInfo/btcr-did-tools-js#create-btcr-did-with-ddo1-ref

I get:

Error: Invalid network version

maybe i generated my wif wrong...

For whatever reason, this has been percolating in the back of my head over the past several weeks and I wanted to write it down before it disappeared again.

Perhaps BTCR has registration backwards? I'm sure I'm missing something, but...

The way Veres One works is you create/import the public/private Ed25519 keypair first, then sign a transaction, and send it to the ledger.

BTCR kinda does it in reverse, where you create a primordial DID document that doesn't have an identifier, anchor something to the Bitcoin chain pointing to an external document, and then create the final DID document.

The problem that this creates is this weird primordial DID document that doesn't have an identifier and then this complicated UTXO mechanism to crawl the UTXO spent/unspent transactions to get to the latest DID Document.

What if you just started w/ a did:btcr:ENCODED_PUBLIC_KEY, that is your DID. You can create your DID Document w/ that and sign the whole thing (putting the value in proof). So, at this point, you have a fully formed DID Document, that is digitally signed w/ the PRIVATE_KEY. It's valid, but not anchored in the Bitcoin blockchain yet.

Now, to anchor it in the public chain, you do a transaction w/ the PRIVATE_KEY, staking some Bitcoin and putting the URL (a hashlink, because you want cryptographic certainty) to where you publish your DID Document. You can then take that Satoshi Audit Trail and tack it on to your DID Document proof, meaning you now have two proofs. The first proof is a regular Secp256k1 signature on the DID Document, and the other proof is a SatoshiAuditTrail2019 proof on the DID Document. You verify the Secp256k1 using regular crypto. You verify the SatoshiAuditTrail2019 using that proof verification algorithm (get the transaction described by the proof, make sure it points back to the document you have, follow the UTXO stuff to discover any updates, etc.).

Have the BTCR folks considered this option before? It feels cleaner than what is being done right now (from my very limited knowledge of how BTCR works). I also haven't thought through the details, so there may be something lurking in here that's unworkable.

Thoughts?