Proposal 5: Withdraw Proposal 1, Proposal 2, and Proposal 3 #39
Replies: 6 comments 12 replies
-
|
Trust Protocol Profile-Trust Spanning Layer Framework: Proposal 4 Assessment Trust Protocol Profile-Trust Spanning Layer Framework: Assessment of Other Proposals UPDATE: @dhh1128 I've clarified the title of the 3rd column - changing it to "Messaging Network Stack" from "Messaging Protocol Stack". |
Beta Was this translation helpful? Give feedback.
-
|
I think it is true, @mwherman2000 , that proposals 1-3 have different kind of details than your proposal does. However, we did not say when we started the proposal phase that each proposal had to provide a specific answer to the questions you are enumerating (messaging protocol stack, message format, identity system, message payloads). Thus, what we got was legitimate proposals -- but proposals that focus on and address different issues from the ones you care about. Sam's focuses on how we get authenticity out of the system, and on some principles and approaches for layering. Wenjing's focuses on what should be in and out of scope, and on how we might adapt existing technologies to use TSP as a foundation. Mine focuses on which questions the TSP has to answer, and on a way to rationalize those answers into clumps of functionality. Yours is wonderfully concrete (it avoids some of the theoretical arguments that the other 3 are making). It focuses on a mental model for trusted communication, a repeatable pattern that can glue everything together, and how we can deliver this with existing approaches. In my view, all of these are valid proposals, but they are proposals about partially different things. The purpose of a consolidation phase would be to identify ways that these proposals are compatible and ways that they are fundamentally at odds with each other -- and then to begin working through the points of contention. Your matrix provides some useful points of comparison, and it might be one helpful way to tackle some consolidation work. Because I think that, I will provide some answers to your questions re. my proposal and the others, as I understand them. However, I am not doing this to make proposals 1 to 3 worthy peers of proposal 4 -- I claim they already are -- only to further dialog.
Of course, @SmithSamuelM and @wenjing are authoritative about their own minds; what I put in that table was my own understanding only. I thought it might be interesting to share another spreadsheet that I prepared, that examines the implications of one of your questions (identifier system) in greater detail: https://docs.google.com/spreadsheets/d/1K7UqQMjL7L5l28LFjXz74YfjAVXuoC5Wt5cchPauEWE/edit#gid=0 I would also like to suggest that your proposal fails to answer some questions that some other proposals do address. I will give some examples below -- again, not to demand that your proposal be upgraded to answer them, but to simply show that all of us have things to learn from one another, and to support my contention that the consolidation phase as it's been proposed is the right way to make progress. Please don't feel like I'm picking on you -- my own proposal doesn't answer any of these questions, either.
|
Beta Was this translation helpful? Give feedback.
-
@dhh1128 I think but I'm not sure if this is primarily dependent on which "crypto suite" is chosen for signing DID Documents and VCs? ...or does question 4 have broader impact? ... message protocol stacks, message formats (aside from the content of the proof which is still a "crypto suite" issue, choice of DID method for the Identity System (answer: yes?), Payload (attachment) formats (yes?, dependent on the attachment type), ... |
Beta Was this translation helpful? Give feedback.
-
|
Re. Q 3: I realize that I was very unclear. Sorry. The "setup" I was referring to is setup of interaction dynamics between the two parties. It is all very well to send a message from Alice to Bob, and to talk about the properties of that message transmission. But before Alice sends a message to Bob, what preconditions must be met that are specific to that situation (as opposed to preconditions that are generally true of the universe, the internet, etc.)? For example, how did Alice get Bob's identifier (DID) in the first place, and does she think of it as belonging to a human named Bob, or to an arbitrary entity with no known properties? If she assumes a human named Bob, on what basis? What privacy, authenticity, or confidentiality (PAC) assumptions can Alice make, or must Alice make, about how or when that precondition (prior knowledge) was achieved? Are the PAC properties of the subsequent message transmission dependent in any way on certain preconditions being true? Are any of the possible preconditions mutually dependent or mutually exclusive? What corresponding process might have or must have taken place on Bob's side (if any) that allows Bob to receive a message from Alice's identifier and reason about her or about the PAC properties that apply in the other direction? Different DID methods allow slightly different setup strategies, so DIDComm has a fuzzy answer to this question. Sam's AID mechanism from KERI is crisper, but also has setup implications. Wenjing's proposal that we accept any VID as the basis for authentic comms introduces the most setup questions. |
Beta Was this translation helpful? Give feedback.
-
|
Re. making Q1 more clear: Sam defined "appraisable" in his presentation. I would summarize it by saying that it is desirable (whether it is required is debatable, but surely desirable) that parties using the TSP be able to reason very robustly about the security properties of the interaction they are having. Diffie Hellman has formal security proofs that guarantee that a third-party observer cannot know the shared session key that the two main parties negotiate, even if the channel between them is insecure. We have attempted to model DIDComm with a formal security proving tool, Tamarin, to derive similar guarantees. However, this has proved elusive. Partly this is because our community expertise (or mine, at least) may not be adequate. But I believe this is also partly attributable to the lack of precision in some of DIDComm's formal spec. Imprecision in the language does not prevent reasonable implementations from being built and achieving interop, but it does prevent formal models from providing rigorous analysis and proofs. I have encountered several governments and other large orgs who, upon reading the DIDComm spec, have asked for such proofs. "Can you tell me exactly what can be guaranteed, formally, by DIDComm's DID rotation strategy, or by DIDComm v2's 'zero round-trip' mechanism?" they ask. So I think the question about appraisability is: do we agree that parties must have it -- and if so, how will we deliver it? |
Beta Was this translation helpful? Give feedback.
-
Your column heading wasn't "network protocol stack"-- it was "message protocol stack". So I thought you were asking about how messages were built and layered, and how those layers corresponded to layers of processing. However, I see now, after re-reading your description of proposal 4, that my answers don't fit into the same category. You are right about them being for a different column heading. Sorry about that. Here's (perhaps) a better attempt at your column:
|
Beta Was this translation helpful? Give feedback.
-
|
@dhh1128 See the UPDATE comment at the bottom of #39 (comment). The above subtable (second set of responses) doesn't match the intent of column 3 (which I've tried to clarify). |
Beta Was this translation helpful? Give feedback.
-
This is a solved problem in the Web 7.0 Global DIDComm Network. It's a Layer 1 Trust Foundation Services Subprotocol discussion. |
Beta Was this translation helpful? Give feedback.
-
|
Ah, yes. I knew that at one point but it had slipped out of my brain. You are correct that your proposal addresses this one. |
Beta Was this translation helpful? Give feedback.
-
|
Thank you again @dhh1128 ...back to Amsterdam, my inflight movie. 😉🙂 |
Beta Was this translation helpful? Give feedback.
-
|
I am weighing in here as I find this discussion item quite troubling. I have watched, over the past year, some incredible efforts from amazing people, move the bar forward for Trust Over IP. This work, I believe, is forming the foundation for truly world-changing capabilities to be developed. I include your efforts in that. The exploration of the new domain that we are working on has been some of the most fulfilling work of my career. Seeing the deep thinking that has gone into the efforts as well as the sharing and feedback loops that have formed is incredibly rewarding. What I have not seen is the active tearing down of other people's ideas. Perhaps I am misinterpreting your statements, but I fail to understand what requesting withdrawal of incredibly value input accomplishes. Information, ideas, and knowledge are being openly shared and that is done in a realm of trust. We all know just how valuable and fragile trust is. I suggest you reconsider your ask here. |
Beta Was this translation helpful? Give feedback.
-
I've taken the weekend to ponder your request and I'm standing firm on my point-in-time assessment of Proposal 1, Proposal 2, and Proposal 3 ...based on the content of the 3 proposals and their recordings and the stated Mission and Deliverables of the TSL Task Force. More importantly, I have never cast any personal aspersations on the individuals behind these proposals as yourself (and @talltree) have accused me of. Never. @darrellodonnell It is only yourself and @talltree who have engaged in personal attacks. @darrellodonnell (and @talltree), you are the two people who have turned this into a very ugly discussion based on personalities. It is the two of you are the most guilty for leading the TSL task force in this direction. It is the two of you who are the most guilty of any Code of Conduct violations. My proposal assessments were based solely on objective criteria (and again, I stand my ground based on the facts behind my findings):
It was fair and reasonable to assess each of the proposals (including Proposal 4) against these goal posts. In effect, what we have are 3 research-like proposals and one concrete proposal (the latter laser-focused on the Deliverables). If the TF leadership had been clear that they were more focused on "hosting a research symposia" vs. "a consolidation of concrete proposals", we wouldn't collectively be in this mess. @darrellodonnell This isn't first time you have unjustifiably attacked me, my contributions, and my proposal:
@darrellodonnell IMO I believe you need to reconsider your ongoing role in the task force as a result of the above.
The attitude and posture of yourself (and Drummond) hasn't changed. Hence, rather than completely withdrawing Proposal 4 from further consideration (i.e. removing each and every post related to Proposal 4), I've chosen to take the high road:
In light of the above decisions, over the weekend, I have updated all of my contributions in the task force Discussions to reflect the version 0.31 of Proposal 4. All of the diagrams in these Discussions are the most current versions from Proposal 4 version 0.31. Best wishes, p.s. Highlighting a different approach, @dhh1128 took the assessment framework table and used it to highlight where Proposal 1, Proposal 2 and Proposal 3 fit in as concrete protocol-based proposals as well as where more work is needed. It's been a good conversation based on Daniel's 5 questions/observations and his respect for my work. |
Beta Was this translation helpful? Give feedback.
-
|
Where do crypto suites (cryptography services) belong in the Trust Spanning Layer Base Protocol model? |
Beta Was this translation helpful? Give feedback.
-
Proposal 5: Withdraw Proposal 1, Proposal 2, and Proposal 3 because they don't meet the bar with respect to defining an actual protocol ...let alone a Trust Spanning Layer Protocol.
"These 3 proposals are examples of a bird's leg, a fish's tail, and a mosquito's nose ...when the basis of every proposal needs to be at least an example of a mammal." Proposal 4 is a "mammal" aka a concrete protocol.
If each of the initial proposers chooses to, each proposal can be updated and re-released as Proposal 6, Proposal 7, and/or Proposal 8, respectively.
See below...
Beta Was this translation helpful? Give feedback.
All reactions