Remove "Proof" property section.

[msporny]

This PR removes the proof property from the DID Document data model as I don't think anyone is using it.

---

Preview | Diff

[TallTed]

There must have been reasons that the property was added in the first place.

It follows that all of these should be shown to no longer be relevant, before the property should be removed. "I don't think anyone is using it" does not seem sufficient, even if we cannot easily identify any such user.

[msporny]

There must have been reasons that the property was added in the first place.

Yes, I argued for its inclusion during a time where DID Documents may have had a signature directly on them. Specifically, when Veres One digitally signed DID Documents on ledger and before the DID Resolution work started.

This has since been removed from Veres One and the proper place to put the proof is on the transaction on the ledger (not the DID Document itself). If the resolver signs the DID Document response, the signature should be on the resolution response, not the DID Document itself. /cc @peacekeeper for his thoughts on this.

It is still possible to put a proof on a DID Document via LD Proofs/LD Signatures, but there are zero use cases for doing that that I'm aware of... which is why we should remove the feature until people find a use case for it.

It follows that all of these should be shown to no longer be relevant, before the property should be removed. "I don't think anyone is using it" does not seem sufficient, even if we cannot easily identify any such user.

Hopefully the above explains what I'm getting at... zero implementers of a feature probably means that the WGs time is better spent discussing features that implementers are willing to implement.

Does that help explain the thought process behind this PR, @TallTed?

[TallTed]

There apparently was at least one use case, which you had, and which you've since addressed through different methods. That doesn't mean that your current method is the only, nor necessarily "the proper", way to serve the need. (I am presuming that yours was not the only voice arguing for this feature, but even if it was, others may well have silently agreed with you, and not needed to speak up because the feature was included.)

Zero implementers doesn't necessarily mean much when there hasn't been a call for implementations. Certainly, the lack of OpenLink implementation of any feature at this stage should not be taken in itself as evidence of either unwillingness or inability to implement, and I daresay the same applies to other implementers.

I would say marking this "at risk" is the appropriate action to take here (assuming that no-one in the WG steps forward to say they have a use case and/or plan to implement), and that the implementation call could include particular call-outs of such features, where the original use case that caused the feature to be included is now moot -- but where there may be use cases of which we are unaware, which were not specifically raised previously, because that feature inclusion was sufficient to address the use case.

[dlongley]

Perhaps we need to be more clear in the spec that just because a property may not be described in the spec it does not mean that it can't appear in a DID Document (we support an open world assumption and full extensibility). Rather, those properties we do describe in the spec should have clear use cases and implementers saying they will implement to pass tests for them.

[dmitrizagidulin]

@msporny

It is still possible to put a proof on a DID Document via LD Proofs/LD Signatures, but there are zero use cases for doing that that I'm aware of

I believe the did:web method will be including a signature DID document itself. The use case is - the need to proof authorship and DID Doc control, without an underlying ledger mechanism.

(I'm willing to bet there are other non-ledger methods (like IPLD?) that also have this use case.)

[peacekeeper]

I am aware of the following potential uses of a proof property:

• A proof is added by a DID Resolver (see 'remote' vs 'local' DID Resolvers did-resolution#28). I agree with @msporny that it would be better to have this on the DID Resolution Result rather than on the DID Document.
• Proofs inherent to the DID method (e.g. Satoshi audit trail in "btcr", state proofs in "sov") should probably also be in the DID Resolution Result rather than the DID Document, or not even included at all, since those need to be verified during the DID Resolution process anyway.
• Perhaps the strongest argument for a proof on a DID Document is to link DIDs to already existing PKI such as X.509 or the E.U.'s eIDAS infrastructure. You could include an eIDAS signature (this is called "eSignature" or "eSeal") on a DID Document to link the DID to a legal identity. Yes this has privacy implications and may be better modeled as VCs, but just saying this may be a use case.

[ChristopherA]

The BTCR DID method has DID documents in 3 forms:

1 - a simple "derived" form that is purely from blockchain based data. Since it is effectively "signed" by the blockchain, no optional proof block is needed by the DID document.

2 - An immutable extension document (for instance an IPFS fragment) that is merged with the derived form to make a DID document that contains information that the blockchain does not support. This too is effectively "signed" by the blockchain as it commits to hash to the immutable extension as well. [Note that to update this form of BTCR DID document requires a full bitcoin transaction (more of a rotate operation) that would require a fee, making it not attractive in scenarios where the root DID document changes regularly.]

3 - The last BTCR form is mutable extension document, pointed to by the derived blockchain data (we use OP_RETURN). Unlike the immutable case, this form can be a complete DID Document — it does not necessarily need to be merged with the derived document (though there are some method specific rules you can't override one key). Due to the limitations of the size of OP_RETURNs, this URL is also limited — 80 characters max but recommended to avoid censorship by miners is 40 chars. This limitation means that we can't use signed or hashlink-style approaches for URLs. As the location this URL is pointing is mutable storage it means that it contents could change. Thus this mutable form of a DID document requires that it be signed with keys that match the derived version of the DID document, in order "prove" that its contents are valid. [Note that this form will be popular as it doesn't require a bitcoin transaction to update many of the values in it — only changing the single root key requires a full rotation.]

I could see that BTCR is a special case, and that our case of mutable DID documents that need to be signed and thus "proven" may be unique and that the proof section here should be moved into our BTCR specification. However, if there are any other DID methods that use mutable storage for DID Documents, they would need to solve the same problem we do, and they might do it different ways which could be good (for innovation) or bad (for security if they don't understand it well as our scenario is complicated).

I could support that this removal of the specification portion of this PR is acceptable, however, I would prefer that it is instead replaced by new text that mentions that DID methods that use mutable storage will have to define how the mutable storage is proven, and that hashlink and signed forms are possible solutions, and maybe refer them to the BTCR Method specification for some approaches.

[dmitrizagidulin]

Incidentally, there's another general category of arguments for including proof (as well as the created timestamps) in did DID Document data model itself:

The DID Document should be self-contained, in terms of critical metadata, in case it is archived or otherwise separated from its underlying ledger or storage medium.

[dmitrizagidulin]

@ChristopherA

However, if there are any other DID methods that use mutable storage for DID Documents, they would need to solve the same problem we do, and they might do it different ways which could be good (for innovation) or bad (for security if they don't understand it well as our scenario is complicated).

That's it, exactly. Agreed.

[peacekeeper]

I think we have 3 separate sets of data we are dealing with:

1. Metadata about the DID Subject (services, keys)
2. Metadata about a DID Document (proof added by the subject, proof added by a method, created, updated)
3. Metadata about a specific DID Resolution process (proof added by a resolver, caching data, what servers/nodes were used for resolution)

1 and 2 are the same every time a DID is resolved. 3 may be different each time a DID is resolved.

1 clearly goes into the DID Document. 3 clearly goes into the DID Resolution Result.

2 goes where??

[ChristopherA]

I think we have 3 separate sets of data we are dealing with:

1. Metadata about the DID Subject (services, keys)
2. Metadata about a DID Document (proof added by the subject, proof added by a method, created, updated)
3. Metadata about a specific DID Resolution process (proof added by a resolver, caching data, what servers/nodes were used for resolution)

1 and 2 are the same every time a DID is resolved. 3 may be different each time a DID is resolved.

1 clearly goes into the DID Document. 3 clearly goes into the DID Resolution Result.

2 goes where??

I like this analysis, but it may be missing one possible thought. #2 may include some assertions that are from the controller of the DID Document's keys. I feel the update date for mutable DID documents fall into being a controller assertion, making it more other type 1 assertions (keys, endpoints).

-- Christopher Allen

[iherman]

Admin comment: I wonder whether it wouldn't be better to raise a separate issue on 'document metadata' and move the discussion there. There lots of commonalities and we may end up repeating ourselves or missing out arguments...

[dmitrizagidulin]

@iherman Great point, I'll open a separate issue.

[dmitrizagidulin]

@iherman - I opened #65 to continue this discussion.

[msporny]

Waiting on resolution to #65.

[msporny]

Closing this w/o merging as there is a solid use case for this property now... which is, publishing a DID Document off-chain that extends the document in a way that you don't want to do on chain.