-
Notifications
You must be signed in to change notification settings - Fork 94
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Remove "Proof" property section. #26
Conversation
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. |
6bd156c
to
2014a47
Compare
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.
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? |
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. |
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. |
I believe the (I'm willing to bet there are other non-ledger methods (like IPLD?) that also have this use case.) |
I am aware of the following potential uses of a
|
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. |
Incidentally, there's another general category of arguments for including 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. |
That's it, exactly. Agreed. |
I think we have 3 separate sets of data we are dealing with:
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 |
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... |
@iherman Great point, I'll open a separate issue. |
Waiting on resolution to #65. |
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. |
This PR removes the proof property from the DID Document data model as I don't think anyone is using it.
Preview | Diff