# BTCR DID Resolver and Sample

The BTCR resolver driver process:

* Get a DID to resolve (say from a verifiable claim).
* Confirms the method from DID is BTCR.
* Using method, constructs initial "implicit" DID Document from Bitcoin blockchain data.
* Supplementary information SatoshiAuditTrail values created here
* Goes to BTCREndpoint (from the BTC op_return if it exists), get first JSON type "DID Document".
* The DID "ID" value is not required to be in this JSON-LD. If this patch data is an immutable file named by content hash (for instance an IPFS endpoint) then it was comitted before any blockchain confirmations occurred. The DID "ID" value for an immutable DID document patch must be implicitly constructed by the method resolver presenting the valid DID document.
* Authenticates this JSON-LD fragment as valid:
* if BTREndpoint is in immutable content hash (say ipfs), it is considered valid and no signature is required on this JSON, as in effect, it is signed by the blockchain transaction
* otherwise, the JSON-LD at the BTCREndpoint must have signature matching Bitcoin transaction signing key
* The Resolver merges/patches in known JSON-LD values (additional keys, authorizations, etc) as appropriate into initial implicit DID documents values.
* errors out if continuation overwrites the Bitcoin key value. Additive only!
* Unknown JSON-LD values (in type "DID Document") are appended to the constructed DID Document.
* Loop for secondary (patch) DID Documents:
* Consider DoS limits of this loop
* Parse for secondary BTCREndpoint URL(s)
* Get secondary (patch) DID Documents
* Merge using above routine.
* Non-DID JSON-LD data types that may also be at BTCEndpoint (such as Verifiable Claims) are ignored by resolver.
* Returns final constructed JSON-LD DID Document to caller, which can use the keys to authenticate data such the signature on a verifiable claim, or perform other application tasks.

{
    "resolver-specific envelope": "blahblah", 
    "doesn't matter to DID spec": true,
    "resultDid": {
      "@context": "https://w3id.org/did/v1",
      "id": "did:btcr:mytxid",
      "publicKey": [ {
        "id": "did:btcr:mytxid#key-1",
        "owner": "did:btcr:mytxid"
        "type": "EdDsaSAPublicKeySecp256k1",
        "publicKeyHex": "02b97c30de767f084ce3080168ee293053ba33b235d7116a3263d29f1450936b71",
        "timestamp": "XXXX"
      }],
      "authentication": [{
        "type": "EdDsaSAPublicKeySecp256k1Authentication",
        "publicKey": "#keys-1"
      }],
      "service": {[
        "type": "BTCREndpoint",
        "serviceEndpoint": "https://github.com/myopreturnpointer"     
        "timestamp": "XXXX"
      ]},
      "SatoshiAuditTrail": {[
        "chain": "testnet3",
        "blockhash": "00000000b3487880b2814da8c0a6b545453d88945dc29a7b700f653cd7e9cdc7",
        "blockindex": 1,
        "outputindex": 1,
        "blocktime": 1499502050,
        "time": 1499501000,
        "timereceived": 1499501000,
        "burn-fee": -0.05
      ]},

      // fields found in BTCREndpoint marked using JSON type "DID Document"
      "future DID-spec term_a" : {
      },
      "future DID-spec term_b: : {
      }

      // Excluded from this diddoc are some other things allowed in
      // the files storing patches to the diddoc, when using it like a
      // "bag of keys".  One example would be verifiable claims stored
      // in the same github document as a BTCREndpoint.
    }

    // Here the method resolver, sometimes also called the method
    // driver, may add a signature (which is out of scope for the DID
    // spec), confirming that it looked these things up on the
    // blockchain then-current, and merged all applicable patches
    // found following the BTCREndpoint algorithm.  The resolver will
    // have stripped any signature from a BTCREndpoint file on a
    // mutable filesystem, since it MUST at minimum add its own
    // SatoshiAuditTrail section.
}

Open questions:
* how to represent updates?
* Ryan claims that proofs about update are not proper for the DID document, other than to require methods to provide a way to do updates. Why should a client app need to know about updates? The DID spec should not try to provide a signed DID Document that is JSON-LD self-complete. Instead, trust in the method resolver is needed.
This also means we can remove the following (which I have now removed from the above example):
"update": {[
// update is implicit
// Optional: txout index
"type": "BTCRTip",
"serviceEndpoint": "bitcoinaddress"
]},

* Should this be part of the audit trail? (Ryan thinks yes. Any objections?)
* At which layer is this happening? is it a requirement of the universal resolver? or is this simply returning info from which this can be determined? (Ryan doesn't know what a universal resolver does. halp.)
* How to represent timestamp?
* Some of the values (the DID ID itself, the bitcoin key, the BTREndpoint, and any immutable content hash items) are effectively timestamped by the Bitcoin transaction
* However, mutable values from the DID Document construction process may have been updated later.

* Should the BTCR spec demand that compliant method resolvers sign the returned DID Document (diddo), using a standard envelope? (This, even though it's out of scope for the DID spec.)

Assumptions:
- Content at BTCREndpoint has term separating out DID document "extensions".
- Under this are terms from DID specification.
- Known BTCR terms will be spliced into e.g. "service", "authentication", etc
- others will be included in DID returned by resolver
- everything not under that node is not part of DID Document.
- claims
- crypto-cats