Change `owner` to `publicKey`

[msporny]

The owner field really holds a list of public keys. We should call it publicKey. We may have a problem with publicKey as well as there seems to be "ambient authority" associated w/ that term. We may want to move to a capabilities model for all of this sort of stuff.

[ChristopherA]

We have had many insights on the DID spec from the BTCR hackathon, so public key isn't what we recommend.

Personally I think owner and control need to be completely refactored and renamed. Both terms are repeatedly not working and are being confused. (In addition, a number of parts of the spec maybe should be moved the the Sovrin Method instead of being in the DID spec.)

We will be moving these to separate issues later, but for now so that we can close this proposal:

Insights:

• We should rarely talk about keys, but instead proofs, of which a signature using a key is only one kind of proof (but very common). See: https://github.com/WebOfTrustInfo/btcr-hackathon/issues/39

• The DDO object may in fact be composed of multiple parts, with different parts having different proofs. See: https://github.com/WebOfTrustInfo/btcr-hackathon/issues/37

• The first part of the DDO may be deterministic based on the root of trust transaction (and in BTCR is in effect "signed" or "proven" by the "SatoshiBlockchainSignature" or "SatoshiBlockchainProof" . See example at https://github.com/WebOfTrustInfo/btcr-hackathon/issues/37#issuecomment-315289776

• We may even want to go back to all the JSON-LD signature schemas and replace the semantics consistent as proofs rather than signatures.

• If there is a link from the deterministic DDO to the extended DDO (in BTCR the op_return pointer), we maybe should allow that to continue to be extended (especially useful the IPFS case). We need a better name for these links. See https://github.com/WebOfTrustInfo/btcr-hackathon/issues/40

• Additional parts must be proven by the owner proof (typically a key) and likely in effect are self-signed verifiable claims that extend the deterministic DDO: see https://github.com/WebOfTrustInfo/btcr-hackathon/issues/8 — This is particular important in some cases like IPFS and some future multisig possibilities where you can't put the DID identifier or proof into the DDO as you have to confirm the transaction in order to get that value — a catch 22. Instead, the IPFS record extends the deterministic DDO with additional values, and doesn't have to have the DID identifier or DID proof as they come from the deterministically created root part of the DDO.

• The owner list is overloaded. It should only be for associating any additional DDO parts or updates with the the DID root of trust transaction. See: https://github.com/WebOfTrustInfo/btcr-hackathon/issues/38

• We need a separate list of proofs (which are typically keys) that are allowed to issue claims under this DID, which may include (or not) an owner proof. In the BTCR case, the owner proof is always a key, and it always is also an issuer key. See: https://github.com/WebOfTrustInfo/btcr-hackathon/issues/38

• We have some better understanding of the roles of https://github.com/WebOfTrustInfo/btcr-hackathon/issues/33 and in particular the short summary at https://github.com/WebOfTrustInfo/btcr-hackathon/issues/33#issuecomment-314608959

• Rather than using control proofs for revocation, this may need to be a separate list of proofs also. This is our same problem with overloading owner. See more thoughts on revocation starting at https://github.com/WebOfTrustInfo/btcr-hackathon/issues/33#issuecomment-314618077

cc: @talltree @kimdhamilton @msporny @joaosantos15 @positronicbrain @rxgrant

[msporny]

The group has settled on publicKey and has explored the design space pretty thoroughly. I'm closing this issue, please raise a new, more specific one if there are still concerns.