Replies: 8 comments 27 replies
-
|
Question: To what extent should the spec(s) that we write be opinionated about what constitutes "good" trust? Justification for including this question on the list: Wenjing suggested that we should only expose and communicate clearly about whatever trust already existed in a given trust domain -- not try to create new trust of any kind. Sam has taken the opposite tack, suggesting that systems that do not provide certain trust guarantees are not appropriate foundations at all. Seems like an issue ripe for fertile debate. |
Beta Was this translation helpful? Give feedback.
-
|
I have an allergic reaction to the term "good trust" because it seems to violate the "dry" principles in the Design Principles for the ToIP Stack. There we define trust as being: human, directional, contextual, limited, etc. So it seems that trust can only be defined relative to any party who needs to make a trust decision of some kind. In other words, there is no "good trust" or "bad trust", there is only a specific trust decision a specific party needs to make about a specific entity in a specific context at a specific point in time. I feel the same way about the idea of "building trust". IMHO, of course a trust spanning protocol helps parties build trust across trust domains — that's one of its primary purposes. It may or may not help parties build trust within a particular trust domain. I'm not trying to answer the question, rather I'm trying to clarify the question before I can provide feedback about whether it should be pursued or ignored. |
Beta Was this translation helpful? Give feedback.
-
|
Considering how Daniel frames and constructs the question, is there a fundamental difference between the two (Sam and Wenjing) approaches? Service end-points expose clearly, completely and concisely what the state of trust assurances are. |
Beta Was this translation helpful? Give feedback.
-
|
As i understand it, Sam is advocating that we build on the narrowest and most cryptographically robust form of identifier -- AIDs. This would mean that most DID methods cannot participate in the TSP, but participants operate with dramatically stronger guarantees. On the other hand, Wenjing proposed we build on the broadest possible identifier type, a VID, which would allow you to participate in TSP with a Twitter handle. Very different outcomes. There are other examples |
Beta Was this translation helpful? Give feedback.
-
|
In thinking about this question this morning, I came to that same conclusion that what @dhh1128 was really asking is: given the three categories of ToIP identifiers defined in section 6.4 of the ToIP Technology Architecture Specification V1.0 (TAS), should the TSP design support only AIDs (the narrowest category), or VIDs (the broadest category)? Strictly speaking, our charter is to design the TSP against the 18 requirements in the TAS for ToIP Layer 2, and currently those requirements specify the TSP MUST support VIDs, but the VIDs SHOULD be DIDs and the DIDs SHOULD be AIDs. So—in the spirit of this discussion being about deciding about the question rather than answering the question—I would propose that the restated question should be: Should the TSP support all VIDs? Or only DIDs? Or only AIDs? Note that either of the latter choices would result in our proposing feedback to the Technology Architecture TF that the Layer 2 requirements in TAS V1.0 should be changed. |
Beta Was this translation helpful? Give feedback.
-
|
Drummond's reformulation is excellent. However, I can imagine other dimensions to the question besides VIDs vs. AIDs. Another dimension might be: do we allow people to use the TSP with weak crypto (e.g., 1024-bit RSA or SHA2)? Another dimension might be: do we allow people to return error messages that might compromise privacy? Etc. |
Beta Was this translation helpful? Give feedback.
-
|
Question: What kind of adoption costs are we willing to impose on which different groups who are considering implementing or deploying support for TSP? Justification: Whether something is easy to adopt will depend on who is doing the work, and how close they are to compatibility with our mental models and techniques. Not all possible adopters are equally valuable. Knowing whether we want to have theoretical excellence and long-term robustness versus easy agreement and casual usage in the short term will help us make more informed tradeoffs. |
Beta Was this translation helpful? Give feedback.
-
|
I do feel this question is important. My assumption has always been that we are designing the TSP to be to decentralized digital trust infrastructure what IP is to decentralized digital network infrastructure, i.e., we want it to be as stable and foundational as we can for decades, if not centuries. So I haven't much contemplated what kind of "short term tradeoffs" we might consider. So I guess that's why the question is indeed quite important. |
Beta Was this translation helpful? Give feedback.
-
|
@dhh1128 Please enumerate examples of what you consider adoption costs? This is too abstract as written. |
Beta Was this translation helpful? Give feedback.
-
|
Question: What is the timeframe over which our design should be evaluated for optimum goodness? Justification: A design that is really good today but that falls apart when NIST's quantum recommendations are finalized is obviously a bad choice. Do we think we'll be writing a spec for 2 years, then doing implementations for 5, then seeing benefits in a decade -- or are we imagining a much quicker payback? |
Beta Was this translation helpful? Give feedback.
-
|
This question seems closely associated with the previous one, so +1 to the importance of asking it. Myself, I've been hoping we write and implement a spec in one year, do implementations for 2-3 years, then probably do one major revision after that implementation experience (similar to HTTP 1.1). Then it lasts for decades because it must be very stable to serve as a trust spanning layer. |
Beta Was this translation helpful? Give feedback.
-
|
I'm prepared to deliver a stretch goal of delivering a DIDComm-based poly-specification this year or early 2024 ...fully spec'ed, implemented, tested, and operational. |
Beta Was this translation helpful? Give feedback.
-
|
Question: To what extent should we bind the tech to specific algorithms, versus defining logical interfaces that can be swapped in and out? Justification: Wenjing proposed a very flexible model that would allow a lot of plugins and have less strong opinions about which ones are better, I think Sam and I and Michael are imagining being a bit more opinionated -- but I could be wrong. I am not super wedded to my first assumption. It just seems to me that whichever answer you choose, there are tradeoffs -- so I would like to make the tradeoffs knowing where we come down on this question. |
Beta Was this translation helpful? Give feedback.
-
|
+1 to this being a very important question to ask. I have some gut feelings, but I truly do not know the answer. |
Beta Was this translation helpful? Give feedback.
-
|
In Web 7.0, we're following the Linux Standard Base (LSB) example of defining a spec set: a common core specification plus a distribution (implementation) specific specification. The latter is for handling details like chosen, compliant crypto suites. In reality, recreating the Linux Standard Base and Distributions model. Reference: https://www.iso.org/standard/77865.html https://twitter.com/mwherman2000/status/1620428932385484800?t=iJxMyJ-QyNtV3hYGNd17hA&s=19 Also watch https://youtu.be/1XnPWmpkGro?t=1995s
|
Beta Was this translation helpful? Give feedback.
-
|
Question: Are non-technical requirements valid? If so, how do we decide which ones to accept? Justification: Some requirements that are not technical include things like power dynamics, whether a spec is likely to "sell" well to a particular audience, whether we are framing things in a way that is likely to ease is standardization, when and where we intend to standardize outside ToIP, cost to implement, time to implement, endorsements by legal jurisdictions, endorsements by academic or cryptographic communities, etc. |
Beta Was this translation helpful? Give feedback.
-
|
+1 to this being another important question to answer. (I personally believe non-tech requirements have a major bearing on a trust spanning layer — but not to the extent they erode its ability to have a long life. Therein lies the tension.) |
Beta Was this translation helpful? Give feedback.
-
|
This sounds to me a bit like the Web 7.0 8-sided ecosystem marketplace model.
|
Beta Was this translation helpful? Give feedback.
-
|
Question: Do we want a set of use cases that help us decide what is in and out of scope? Justification: I feel like "trust" is an incredibly broad, ambiguous, and charged word. I really appreciated Wenjing's careful attempt to narrow the focus of TSP. I agree with his conceptual boundaries, but I wonder if concrete examples would help a lot. |
Beta Was this translation helpful? Give feedback.
-
|
I am very much torn about this question. I believe use cases are valuable in reverse proportion to the generality of the solution being developed. For example, the discussion about use cases for the ToIP Technology Architecture Specification V1.0 (TAS), I compared for the use cases for the ToIP stack to the use cases for the TCP/IP stack. The are so many as to be nearly infinite. That said, we agreed that for the TAS, a set of concrete canonical use cases would be very helpful to readers new to the spec (and we still have an open issue to finish that task). I believe the same will be true here. However I caution us to keep this canonical set as small as possible to avoid the temptation to rathole on specific use cases for a protocol designed for very general usage (again, like the IP protocol). |
Beta Was this translation helpful? Give feedback.
-
|
Agreed. I am not thinking that it's a good idea to try to enumerate all the use cases for TSP. Rather, I was wondering if 2 or 3 test cases (maybe we all them that, instead of "use" cases) would be helpful to refer to, because they would let us narrate the protocol from beginning to end to illustrate key properties. |
Beta Was this translation helpful? Give feedback.
-
|
Here's a few use cases:
|
Beta Was this translation helpful? Give feedback.
-
|
Question: What are the participants in this protocol -- systems or identity owners? Is it: "Alice sends a message to Bob" -- or "Alice's device 2 sends a message to Bob's device 3"? Justification: Sam and Wenjing both talk in terms of systems being the source and destination. I don't think that maps onto identity correctly; Alice wants to send to Bob without regard to his devices. The scope of identifiers is identities, not their devices. I'm not sure where Michael comes down on this. I suspect our whole community could benefit from exploring this question carefully. |
Beta Was this translation helpful? Give feedback.
-
|
I was trying to write a question that teases out the distinction between a person and the devices that a person uses when engaging in TSP interactions, not between a person and IoT devices that participate as peers. Of course we want to support machine identity -- but when the machine doesn't have an identity (there is no conception in the mind of Alice that she is talking to Bob's tablet, only that she is talking to Bob) -- what gets modeled in the TSP? Maybe that is a distinction without a difference? |
Beta Was this translation helpful? Give feedback.
-
|
It's neither a person nor a device. It's agent to agent-based communications (and their associated personifications). The key concepts here are: i) anthropomorphism and ii) personification. These are at the core of the Web 7.0 DIDComm-ARM. Watch https://youtu.be/AFmCv8cfkm0?t=2673s especially https://youtu.be/AFmCv8cfkm0?t=2936s Watch https://youtu.be/1XnPWmpkGro?t=2321s
|
Beta Was this translation helpful? Give feedback.
-
|
I agree that its agent to agent, if we're being precise. However, that nuance isn't what I was trying to hilight with my question. Whether you use the bad term, "device" or the better term "agent", the fact is that there is a 1-to-many relationship between identity owners and this construct. Alice has many devices. Alice has many agents. So when Bob sends her a message, does the TSP model her as a single destination or as many destinations? |
Beta Was this translation helpful? Give feedback.
-
|
@dhh1128 What the video segments linked to above to learn about personification.
What I think you're really asking about is:
Adding specific capbilities/methods/functionality to support the multiple multiple x multiple scenarios are just convenience methods when there is no upfront justification to specify them and hence, require developers to implement them. Leave it to developers to create their own convenience methods ...at least in the V1 specification ...unless there is more actual hands-on experience to dictate otherwise IMO. |
Beta Was this translation helpful? Give feedback.
-
|
@dhh1128 wrote:
Got it. So I would propose a restatement of the question: Should the design of the TSP reflect the model that a single ToIP controller (person, org, thing) may need to communicate over multiple ToIP endpoint systems each with their own ToIP identifiers? @dhh1128 does that capture it? |
Beta Was this translation helpful? Give feedback.
-
|
Question: What assumptions do we want to make about the SETUP of a TSP-facilitated channel? (Out-of-band vs. in-band, one-way vs. two-way, what guarantees must we provide, etc.) Justification: Making assumptions about setup without stating them explicitly is going to lead to a lot of confusion. Further, I think a lot of the imperfections in our current alignment are actually caused by different setup assumptions and priorities. |
Beta Was this translation helpful? Give feedback.
-
|
+++1 to the importance of this question as well. (Again, I would rephrase the question to: "Should the design of the TSP accommodate different setups, e.g., Out-of-band vs. in-band, one-way vs. two-way, guarantees provided, etc.?" I expect we could reach consensus on that answer pretty quickly (though I may be wrong). Then we could move our focus to WHICH setups and HOW they should work.) |
Beta Was this translation helpful? Give feedback.
-
|
I intentionally didn't ask a yes/no question; I was assuming the answer to your first question variant is yes, and jumping directly to your second variant of the question. |
Beta Was this translation helpful? Give feedback.
-
|
A key related question is: how does a service agent architecture support the automatic startup of agents that don't have a UI i.e. don't support any human interaction at startup. |
Beta Was this translation helpful? Give feedback.
-
...or do we limit the V1 specification to message routing with the assumption that the Sender knows the address of the Receiver (including how to dereference an address into the Receiver's service endpoint URL). |
Beta Was this translation helpful? Give feedback.
-
|
...in addition is identifier (DID) to service endpoint URL resolution considered in-scope or out-of-scope? |
Beta Was this translation helpful? Give feedback.
-
This is an attempt to distill, from all 4 of the proposals we've seen so far, important points where there is not yet alignment about the framing of the problem -- that is, proper scope, legitimate versus unreasonable requirements, etc. I don't want to discuss and resolve the questions here -- only capture them carefully so we have a list that will serve as fodder for the next stage of our TF's work.
Discussions are organized by an overarching theme, then by individual posts that can have clusters of replies. I suggest we use individual posts in this discussion to propose a single question, and let the replies suggest refinements or reasons why the question should be split / abandoned / rephrased / ignored. But let's NOT try to answer the questions here -- only list them.
Beta Was this translation helpful? Give feedback.
All reactions