DDO as composite object

[kimdhamilton]

From @ChristopherA on July 13, 2017 18:19

One of the insights from this hackathon is that the DDO can be a composite object.

We have the deterministic part that is, in effect, signed by the blockchain. In BTCR this part verifies an persistent unique confirmed identifier (the txref that is an encoding of chain, block and index), another unique by unconfirmed identifier (the txid), one owner key (which signed the transaction), one control key identifier (the hash of a future key to be revealed), and a pointer out. But nothing more. However, in Sovrin, in effect everything is signed by the blockchain.

Since I don't think you can override anything in BTCR that is deterministic, that means having any there is redundant. So we can some some current problems with IPFS objects as we can create there DDOs that don't include the txref. All that is required is that it is singed by the owner key.

In a sense, the object pointed to on the op_return is a self-signed verifiable claim from the owner key in the deterministic part that appends more information to the deterministic part.

Copied from original issue: WebOfTrustInfo/btcr-hackathon-2017#37

[kimdhamilton]

From @ChristopherA on July 13, 2017 18:20

It can also be implied that if we can append one thing, we can append more. So one DDO object may add a link where to find more parts of the DDO object, just like the op_return points to the first object.

[kimdhamilton]

From @ChristopherA on July 14, 2017 7:18

cc: @kimdhamilton

Here is a deterministic DDO, based on my DDO transaction. Unfortunately I broke the JSON someplace in here but I think you can get the basic idea.

//deterministic DDO
{
    "@context":
    [
        "https://schema.org/",
        "https://w3id.org/security/v1"
    ],
    "ddo": // basically info that be deterministically created from the transaction alone
    {
        "txid": "f8cdaff3ebd9e862ed5885f8975489090595abe1470397f79780ead1c7528107",
        "funding-txid": "a2cb61283814f8e758f138260da0cccd367c43afead5458e13a7d058f5bc3f6a", //optional
        "funding-txref": "x?" //optional
        "hash": "f8cdaff3ebd9e862ed5885f8975489090595abe1470397f79780ead1c7528107", // normall same as txid but only needed for witness as it may be different from txid
        "more-ddo-hex": "6a4568747470733a2f2f7261772e67697468756275736572636f6e74656e742e636f6d2f4368726973746f70686572412f73656c662f6d61737465722f64646f2e6a736f6e6c64",
        "more-ddo-asm": "OP_RETURN 68747470733a2f2f7261772e67697468756275736572636f6e74656e742e636f6d2f4368726973746f70686572412f73656c662f6d61737465722f64646f2e6a736f6e6c64",
        "more-ddo-txt": "https://github.com/ChristopherA/self/blob/master/ddo.jsonld",
        {
            "owner": [{
            "type": "update-proof"
            "id": "did:example:21tDAKCERh95uGgKbJNHYp#key-1",
            "type": ["CryptographicKey", "EdDsaSAPublicKey"],
            "curve": "secp256k1",
            "publicKeyHex": "02b97c30de767f084ce3080168ee293053ba33b235d7116a3263d29f1450936b71"
            }]
        }
        {
          "control": 
          [{
              "control-bond": 1.25
              "rotate-proof": [{
                  "proof-type": "pubkeyhash",
                  "hash-base58check": "mvZ3MyLgsvYr87GGSbsPBWEDduLRptfzEU"
                  }]
            },{
            "revocation-proof": [{
                "bond-value": 1.25
                "proof-type": "pubkeyhash",
                "hash-base58check": "mvZ3MyLgsvYr87GGSbsPBWEDduLRptfzEU"
          }]
        }

    },
    "signature":
    {
        "type": "SatoshiBlockchainSignature2017",
        "id": "x?????" // the txref
        "chain": "testnet3",
        "blockhash": "00000000b3487880b2814da8c0a6b545453d88945dc29a7b700f653cd7e9cdc7",
        "blockindex": 1,
        "blocktime": 1499502050,
        "confirmations": 644,
        "time": 1499501000,
        "timereceived": 1499501000,
        "burn-fee": -0.05
    }
}
```

[kimdhamilton]

Cleaned up formatting; without comments this is valid JSON:

{
  "@context": [
    "https://schema.org/",
    "https://w3id.org/security/v1"
  ],
  "ddo": {
    "txid": "f8cdaff3ebd9e862ed5885f8975489090595abe1470397f79780ead1c7528107",
    "funding-txid": "a2cb61283814f8e758f138260da0cccd367c43afead5458e13a7d058f5bc3f6a",
    "funding-txref": "x?",
    "hash": "f8cdaff3ebd9e862ed5885f8975489090595abe1470397f79780ead1c7528107",
    "more-ddo-hex": "6a4568747470733a2f2f7261772e67697468756275736572636f6e74656e742e636f6d2f4368726973746f70686572412f73656c662f6d61737465722f64646f2e6a736f6e6c64",
    "more-ddo-asm": "OP_RETURN 68747470733a2f2f7261772e67697468756275736572636f6e74656e742e636f6d2f4368726973746f70686572412f73656c662f6d61737465722f64646f2e6a736f6e6c64",
    "more-ddo-txt": "https://github.com/ChristopherA/self/blob/master/ddo.jsonld",
    "owner": [
      {
        "id": "did:example:21tDAKCERh95uGgKbJNHYp#key-1",
        "type": [
          "CryptographicKey",
          "EdDsaSAPublicKey",
          "update-proof"
        ],
        "curve": "secp256k1",
        "publicKeyHex": "02b97c30de767f084ce3080168ee293053ba33b235d7116a3263d29f1450936b71"
      }
    ],
    "control": [
      {
        "control-bond": 1.25,
        "rotate-proof": [
          {
            "proof-type": "pubkeyhash",
            "hash-base58check": "mvZ3MyLgsvYr87GGSbsPBWEDduLRptfzEU"
          }
        ],
        "revocation-proof": [
          {
            "bond-value": 1.25,
            "proof-type": "pubkeyhash",
            "hash-base58check": "mvZ3MyLgsvYr87GGSbsPBWEDduLRptfzEU"
          }
        ]
      }
    ]
  },
  "signature": {
    "type": "SatoshiBlockchainSignature2017",
    "id": "x?????",
    "chain": "testnet3",
    "blockhash": "00000000b3487880b2814da8c0a6b545453d88945dc29a7b700f653cd7e9cdc7",
    "blockindex": 1,
    "blocktime": 1499502050,
    "confirmations": 644,
    "time": 1499501000,
    "timereceived": 1499501000,
    "burn-fee": -0.05
  }
}

[kimdhamilton]

I think we need to distinguish between pointers to immutable content (e.g. content addressable store) vs mutable content. If the address of immutable content is stored in the transaction, this can be considered signed by the transaction. If the content is mutable, we can't say the same.

For methods like BTCR, where the DID is only known afterward, this only works if we can use a scheme like @ChristopherA described, for a placeholder DID in the referenced content. (In BTCR we don't know the txref until the tx is confirmed.)

/cc @ChristopherA @msporny

[msporny]

The group seems to have settled on the following: "Boostrapping/interim/composite DID Documents are fine for implementers to use. However, the thing that the DID spec is about, and the thing that Resolvers do is return fully formed DID Documents to developers."

Closing this issue as it seems like this is stuff that the group seems to agree on these days. Please open a new, more specific issue if there are still concerns.