Adds a note about controllership and and ownership of the identifier #352
Conversation
Signed-off-by: Kyle Den Hartog <[email protected]>
|
Could you please add linebreaks to make a readable raw file? |
index.html
Outdated
| Through the use of digital signatures a controller can assert proof of control | ||
| which can be used in a variety of different contexts. By asserting proof of | ||
| control of the identifier, the controller is asserting proof of ownership of | ||
| the public key which may not be the same as the subject of the DID. However, |
There was a problem hiding this comment.
Public key is never subject of a DID. Is subject of a DID actually related in any way to the proof of control?
There was a problem hiding this comment.
This particular statement is confusing: "public key may not be the same as the subject of the DID." It does not really help to clarify the relationship between subject and controller. Public key and a thing identified by a DID are completely different entities. Perhaps you wanted to say that subject of a did may or may not have a control over did?
There was a problem hiding this comment.
Ahhh I see what you're pointing out now. I'll give an attempt to reword this a bit based on the way you put this.
index.html
Outdated
| which can be used in a variety of different contexts. By asserting proof of | ||
| control of the identifier, the controller is asserting proof of ownership of | ||
| the public key which may not be the same as the subject of the DID. However, | ||
| it's up to the verifier to determine if the usage of digital signatures is |
There was a problem hiding this comment.
Avoid use of contractions in official specifications; use more formal language. If you find yourself using a large number of contractions, it is typically a sign that your sentence needs to be reworded to be simpler.
There was a problem hiding this comment.
I would remove the language that proof of control is related to "proof of ownership". A major point of the language of "proof-of-control" is that ownership is a matter of law, not technology. So, only courts can establish actual ownership. Proof-of-control, on the other hand, is technically concrete. So, when someone steals your keys, they can generate proof-of-control, but they CANNOT establish proof of ownership. "Not your keys, not your coins" fails in the reverse: "Controlling the keys does not prove they are your coins." You can spend them--you have control--but you don't own them any more than the car thief who stole your keys to steal your car. They don't "own" your car, nor do they establish proof of ownership. They just control it.
index.html
Outdated
| <div class="note" role="note" id="issue-container-generatedID-8"> | ||
| <div role="heading" class="note-title marker" id="h-note-7" | ||
| aria-level="4"><span>Note</span></div><p class=""> | ||
| Through the use of digital signatures a controller can assert proof of control |
There was a problem hiding this comment.
"proof of control" needs to be defined somewhere... it's used a number of times in the specification without really going into what "proof of control" and "proof of ownership" mean... we need to be explicit about what we mean. It is effectively "Using private cryptographic material to generate a digital signature to prove that one is in control of the private cryptographic material."
|
Still waiting on that rewording @kdenhartog ... ETA on getting that done? |
Signed-off-by: Kyle Den Hartog <[email protected]>
Signed-off-by: Kyle Den Hartog <[email protected]>
|
Sorry was away on vacation for a bit and didn't get back to this until now. I made an attempt to cleanup the language based on this discussion. Please review and see if it clarifies better the intent.
I agree that this should be defined given the prevelance of usage in the specification, but it seems to fall a bit out of scope of what I was trying to get at with this issue/PR. Can we add that separately in a different PR to keep this PR small and focused? |
Up to you @kdenhartog ... those appendices have changed over the past several weeks of discussion. I do think they're probably going to cover what you have in this PR to some degree. You may want to keep this PR open until you feel like it's dealt with in #373. Again, your call. |
|
Looking for feedback here, @kdenhartog -- it's been 27 days. I'm going to mark this pending close if you don't engage in the next 7 days. |
|
Looks like the original comment 13 days ago in the issue should have been cross posted here as well:
I've been waiting to see the results of #373 . As far as I can tell the PRs for those are still in progress and if they're only discussing additional properties then I would want this PR to go in. However, if the PRs will add the aspects about the relationship of the DID Document, the Controller, and the DID Subject then I'm in favor of closing this. The notes on 8/13 left it at more discussion on the topic is needed with the closest point to consensus being some would end up in the spec and some would end up in a note. The notes on 8/25 seem to imply we'll be adding a So at this point, I'm waiting to see what goes into the DID Spec and what won't so I can decide if it's necessary to continue this PR to document that relationship or see if it's going to be covered in alternative PRs. Would you prefer that I add these aspects myself in this PR and then potentially have them stated elsewhere as well or would you prefer that this PR and issue wait until we see the end result of #373 ? I'm happy with either approach. As for the particular aspects that I'm looking to see this PR turn into. I'd like to see us address somewhere that a DID controller can change but a DID Subject cannot (surprising that's not mentioned anywhere). Additionally, what are the DID Document consumers expected to get from the DID Document that would help them decide if the the DID Controller is authorized to speak on behalf of the DID Subject, if the DID Controller "is" the DID Subject, if the DID Controller is speaking about the same DID Subject as all other DID Controllers have in the past, and if the DID Controllership has changed. For the 1st one, I think this PR already addresses it. For the 2nd question I think we've done a good job highlighting this topic. For the 3rd question I know of no way to programmatically test this so at best it can be a note in the DID Subject section that says something like "A DID may identify only a single DID subject for the entirety of the life of the identifier", and for the 4th question I think we've got quite a bit of tribal knowledge on the subject, but there's not much being stated in the spec about how consumers should deal with it. In some cases it's going to have to be left up to the reader what to do, but in most cases we should be helping them to identify the points of concern in the spec with a subsequent note. In my opinion the appendix document covered these different topics well enough that it made the blurry picture clearer. This is why I have been waiting to see what specific parts are going to be used from that document. If it's enough to cover the questions I listed above then I don't think this is necessary. However if that discussion is going to turn into only adding the Does that make it a bit clearer as to my goal with this PR at least and why I've let it linger? |
Neither :) -- I'd like you to work with @talltree to get the appendix in. Letting PRs like this ride w/ no end in sight isn't the way we're supposed to be using PRs. Either it's focused and the PR goes in relatively quickly (within a month a most), or it's not, it hasn't made progress, and it's closed. This PR seems to potentially conflict with @talltree's proposed appendices, so I'd rather you work with him on his PR... OR, you write the appendix PR. In other words - I'd like to see you do active work to move the PR forward that the group seems to have consensus on (@talltree's PR), merge this language into that PR, and drop this PR. Thoughts? |
I'll go ahead and close this PR and check in with @talltree to see where things are at with the appendix work. |
This is a first attempt at addressing issue #269
Signed-off-by: Kyle Den Hartog [email protected]
@jandrieu can you give it a read to see if it sums out point 1 well enough?
Preview | Diff