Codecov Report

Merging #440 into master will increase coverage by 0.06%.
The diff coverage is 89.18%.

@@            Coverage Diff             @@
##           master     #440      +/-   ##
==========================================
+ Coverage   89.63%   89.69%   +0.06%     
==========================================
  Files          56       56              
  Lines        3271     3271              
==========================================
+ Hits         2932     2934       +2     
+ Misses        183      182       -1     
+ Partials      156      155       -1

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 238da0b...cd1abb7. Read the comment docs.

The DIDs created by the framework are (typically) Peer DIDs.

Do we know the use case for DID Document proofs? @llorllale @sandrask

@troyronda

Do we know the use case for DID Document proofs? @llorllale @sandrask

The argument for removal of proof is convincing, but I suggest we press forward with the DID spec as it exists today. I doubt w3c/did-core#26 will be merged any time soon (look at w3c/did-core#28 for example).

I'd rather focus on the changes coming to did-exchange in hyperledger/aries-rfcs#243 (which also has an out-of-band proof mechanism).

@llorllale The Peer DID spec is a bit unclear on this point.
https://openssi.github.io/peer-did-method-spec/index.html#namestring-generation-method

The genesis version MUST include enough keys and authorization that the genesis version of the doc can be signed (see Binding of Identity in the DID spec), to prevent man-in-the-middle attacks during initial DID exchange.

By basing the numeric value of the DID on the genesis version of the DID doc, the DID can begin its lifecycle with any number of keys and endpoints, and when the doc is signed or auth-encrypted by one of the keys, the recipient can know it has not been modified since creation. This guarantees the initial integrity of the DID's chain of custody.

i.e., @llorllale I see that "doc can be signed" - are you saying that implementations have been populating Proof with that signature?

Even though it is mentioned in the paragraph above the reference implementation (dotnet and python) are not signing did doc. I suggest to park this issue for now.

Even though it is mentioned in the paragraph above the reference implementation (dotnet and python) are not signing did doc. I suggest to park this issue for now.

Neither is the protocol test suite. I also think we're safe by parking this one.

Interesting summary of pros and cons for removing metadata from DDOs in general: w3c/did-core#65

Closing issue, will reopen in case we need it.