Beginning the Consolidation Stage with TSP Workshops

[talltree]

Tomorrow's 2023-03-22 TSPTF meeting is our final call for proposals. If any other TSPTF member wishes to make a proposal for the design of the TSP, please contact @talltree (Drummond Reed) ASAP.

Otherwise, we are ready to begin our consolidation stage. As we note on the referenced ToIP wiki page, this is the stage at which "Members identify common elements and seek to develop a consolidated proposal" with the goal of reaching "Consensus on contents of first Working Draft".

@neiljthomson and others have suggested that, to make serious forward progress at this stage, we need to hold several longer "workshop" sessions of at least 2 hours in length. The task force co-leads agree and suggest that we aim to start holding several of these TSP Workshops starting in early April.

The purpose of this discussion is to seek your input on these questions:

1. Assuming these are virtual Zoom meetings, what's the ideal length? 2 hours? 3? 4?
2. How often should we hold them? Weekly? Biweekly?
3. What is the best time to maximize global attendance? (There is no "perfect time" for the whole globe, but @dhh1128 has suggested starting around 11AM or noon PT (18:00 or 19:00 UTC) will split the pain equally between the EU and APAC. Is their rough consensus about this?)
4. What day of the week is best? (The suggestions so far are Thursdays or Fridays.)

Feel free to post your answers to these questions just using a four point numbered list.

[vikyTM]

2hours, biweekly, Thursdays

[Willem-de-kok]

Agree with vikyTM!

[mwherman2000]

The Consolidation phase needs (a) a separate sub-mission, (b) set of goals, and (c) a set of more detailed requirements - else we will be totally at risk IMO of running around in circles. Nobody has time for the latter.

[mwherman2000]

Also checkout #35 ...this is closely related.

[mwherman2000]

I want to avoid raising #39 as a formal objection but I believe we need to address #39 before proceeding into the Consolidation phase.

[talltree]

Michael, this isn't the W3C. We don't have "formal objections" here. We operate by consensus. I don't see anything even approaching consensus about #39; it represents the opinion of a single TSPTF member.

Furthermore, #39 appears to be directly contradictory to the spirit of the consolidation phase. I counsel you to be patient and work with the rest of the TF members to seek out the points of alignment between the four proposals.

[mwherman2000]

#39 appears to be directly contradictory to the spirit of the consolidation phase

@talltree My point is that there is nothing to base the Consolidation phase on (except Proposal 4) when 3 of the so called "proposals" represent "a bird's leg, a fish's tail, and a mosquito's nose".

See my analysis here: #39 (comment)

Unless there is a demonstrated will to correct this before the Consolidation phase, I'm afraid I'll have to withdraw Proposal 4 (as both a proposal and a Contribution). Proposal 4 the only actual protocol proposal we've seen so far.

I don't have the time nor energy for muddling around in quicksand.

[talltree]

@mwherman2000 Although other members of the task force are welcome to share their own views, I personally disagree strongly with your assessment. In fact my assessment is exactly the opposite — that the first three proposals have laid very fertile ground for the consolidation phase. I can confirm that the other three co-leads of the task force (and presenters of those proposals) feel the same way.

You are of course welcome to withdraw your proposal at any point.

[mwherman2000]

IMO, the first 3 are primarily disconnected philosophical conceptual discussions...not tangible protocol proposals.

If this is what the TF wanted/expected, I'm out.

[dhh1128]

IMO, the first 3 are primarily disconnected philosophical conceptual discussions...not tangible protocol proposals.

I addressed this here.

If this is what the TF wanted/expected, I'm out.

Perhaps this is simply a matter of timing, and you would find the conversations getting progressively more interesting as we leave the theory behind and dig into the practical details. I think that's a process though, not a binary event.

[jospencer-460]

My view (as I articulated on the APAC call (23/3) is that:

We need an agreed description of the Level 1 TSP technical architecture (given that the Tech Arch is Level 0), so that we can

• articulate a mental model of the terms used and their relationships
• agree capabilities to be included and features to be provided in the TSP
• define sub-layers and their interdependencies inside the TSP
• dependencies outside the TSP
• etc.

The purpose is to develop a common architecture / design that allows coexistence or equivalent development of various solutions, rather than only supporting one solution. This process can consider various solutions as input but should not skew to any one solution in particular.

The next stage is to identify and apply various practical solutions (DIDcom, KERI, ISO18013, OIDC4VC etc.) and assess the trust implications of each. This will identify

• levels or degrees of alignment between different interaction protocols and the cryptography used to provide trust
• the change implications necessary or possible to make better alignment to the TSP
• identify specific interaction scenarios that need to be catered for (in-person, online, supportive etc) and those solutions that
• limitations and benefits of various solutions and therefore the appropriate use of these in practice (not all solutions require the same levels of trust)
• implementation considerations and guidelines for the design, build and operational management (and governance) of TSP related solutions. This should result in the development of an implementation guideline for the TSP.

The point is that the TSP should be an anchor that supports the coexistence and co-development of new solutions, not an alignment to only one solution.

One other point... All those involved should not try to impose / frustrate this process by looking to justify existing solutions which may not be totally aligned with the logical architecture. We need to "take off our personal-interest hats" in these discussions.

[dhh1128]

I have completely cast off Layer 2 and Layer 3 (because they are protocols derived from the Trusted Spanning Layer Base Protocol) - they are protocols (Super Protocols and Subprotcols) - not (software) layers.

I may have had a different mental model than others in this discussion, but I never thought of layers 1, 3, and 4 as being software layers. They certainly use software, but they consist of lots of stuff, of which software is only a part. A simple example is that I have said that the role of human beings in layer 3 trust tasks is important to recognize -- making layer 3 part software, and part not software. Layers 1 and 4 seem even more clearly to not be wholly software, IMO. This doesn't mean I disagree with your characterization, Michael, that these layers are very protocol-oriented. But I thought layers in the ToIP model were supposed to be about differences in abstraction and responsibility, with software laying only one of several clues of where a boundary might fall.

[talltree]

In case there is any confusion, the heart of the ToIP Technology Stack is a protocol stack — exactly the same way TCP/IP is a protocol stack. The job of this task force is to specify the protocol at Layer 2 in that stack — the protocol at the neck of the hourglass just like IP is the protocol at the neck of the TCP/IP hourglass. Full stop.

[mwherman2000]

In case there is any confusion, the heart of the ToIP Technology Stack is a protocol stack

@talltree It's a very technical point: the ISO OSI model is a stack of software (and hardware) components glued together by protocols. It's a (popular) misnomer/misconception to assume it is a "stack of protocols". Extending the jelly-peanut butter-honey sandwich metaphor, the ISO OSI Model is a stack of multiple slices of bread (software and hardware components) glued together by protocols...

[mwherman2000]

The natural evolution of the 7-Layer ISO OSI Model is the Web 7.0 9-Layer Authentic Conversations Model depicted below...didn't even have to sleep on it ;-) :-)

Reference: Proposal 4 version 0.32 Appendix D Slide 125

Reference: Proposal 4 version 0.32 Appendix D Slide 126

[mwherman2000]

I think this might address a larger goal: the ability to add security, privacy, and authenticity to the Internet - based on an easy-to-understand 9-layer adaptation of the ISO Open Systems Interconnection (OSI) Model.

Reference: https://twitter.com/mwherman2000/status/1640757364507955200

[dhh1128]

I am very unexcited about articulating just a logical architecture that can have many solutions. IP (the one that's half of TCP/IP) isn't a logical architecture, it's concrete, and although there can be many alternative implementations, it would be misleading to call them different "solutions". They're far more similar than that. There is really only one "solution" to the narrow waist of internet transport. I believe there should be only one solution to the narrow waist of trust over IP, else interop WRT trust is largely theoretical. OIDC4VC is not the same kind of thing as DIDComm and KERI. That is not a critique, just a request that we not confuse people by enumerating them in a list as if they were alternatives. OIDC4VC is solving a logging-humans-into-orgs problem. That's important and valuable, but it is quite different from, and much more specific than, solving general trust. If the scope of our concerns is equal to the scope of OIDC4VC's concerns, then KERI and DIDComm should not be on the list as examples of "solutions". If the scope of our concerns is general trust between any two parties, whatever their nature and regardless of whether credentials are involved, then OIDC4VC should not be on the list as a "solution."

…

On Sat, Mar 25, 2023, 2:42 AM Jo Spencer ***@***.***> wrote: I would see DIDcom, KERI, ISO18013, OIDC4VC etc. as different solutions, that would ideally align to a common logical design, as articulated in the TSP. I think that consolidation down to one is an impractical expectation. With the TSP defining the logical definition of a common protocol. This is visible in the eIDAS ARF in that different protocol choices have been selected as options in the context of the EUDI wallet... [image: image] <https://user-images.githubusercontent.com/50346531/227679014-f612c83e-b271-41d3-b88e-0c38f64417e5.png> — Reply to this email directly, view it on GitHub <#34 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAQ3JCFPJVFTAXWYUQXA2P3W5ZEPHANCNFSM6AAAAAAWDEIDNY> . You are receiving this because you were mentioned.Message ID: <trustoverip/trust-spanning-protocol/repo-discussions/34/comments/5424135@ github.com>

[dhh1128]

@wenjing

In return, all three get a level of interoperability

I have been pondering this claim (which you also made in your follow-up presentation the other day). I'm not sure whether I agree or not. If Bob and Alice both decide that mail is authentic in the same way (e.g., using the same certified mail mechanism), but Bob uses the mail exclusively to talk about topic X and Alice uses it exclusively to talk about topic Y, is it really meaningful to say they have "interoperability"? Sure, there is a point of commonality, but they aren't really going to talk to one another...

Now, in my question just now I posited that topics X and Y are mutually exclusive. I don't think it's quite that bad if we analyze the problem domains of DWN, OIDC4VC, DIDComm, and KERI. However, because these talk at different levels, with different mental models, I'm not sure how valuable the interop would be that they would achieve. Further, the trust models of these technologies are different ON PURPOSE -- meaning they don't want to trust one another. KERI doesn't actually want to carry on a conversation with someone who is using an arbitrary VID, because KERI aims for trust guarantees that arbitrary VIDs don't provide. So what does it mean to say that KERI and an arbitrary VID are "interoperable"? Maybe it would be more valuable than nothing. Maybe not. I'm still thinking. But I don't yet accept your assertion that ITDP would give interoperability in any meaningful form, or the implied assertion that this interoperability is valuable enough to tout as a benefit here. I think you need to make a stronger and more detailed argument.

[dhh1128]

If by being "concrete" you meant that the meaning of "trust" is all identical in all endpoints, no way. I will say it is neither possible nor necessary. I think this might be the crux of the problem...Insisting the sameness of all endpoints would be a direct contradiction to what we set out in the Technology Architecture spec. There are infinite variations in the meaning of "trust", we could try to capture a common minimum, but we will never be able to agree on the same exact trust meaning without pushing a large swath of Internet out of the possibility of benefiting from our work

I don't want trust to be identical in all endpoints. I want the subset of trust issues that the TSP concerns itself with to be defined by the TSP itself, using concepts that are clear and basic and that can be useful in building the infinite variety of higher-level trust constructs you're talking about. I think that's the "common minimum" you're talking about, so I think we agree on the desirability of that much. I don't think we agree on what the minimum is, though. And I think our disagreement on this manifests in at least 2 separate ways:

• We may not agree on the properties that are worthy of inclusion in the minimum. I proposed some properties that must be defined for every message, and you are suggesting that the properties are "mainly authenticity." I'll be interested to explore whether these amount to the same thing or not.

• More seriously, we may not agree on what can constitute proof of authenticity. You are saying that any VID that satisfies the authenticity interface of ITDP ought to be good enough, regardless of the robustness of the evidence it can provide to justify its claims on the subject. I admit that this is wonderfully inclusive, but I don't think it actually helps the world much. In my mind, the trust problems we observe are not caused by a lack of claims about authenticity, but rather by a lack of justification for claims about authenticity. Thus, an ITDP that demands nothing of implementations other than a conformant claim is not doing enough.

[wenjing]

@dhh1128 I got similar questions quite common and let me follow your train of thoughts and examples.

It is common that we like to jump to the Alice and Bob role play examples. I accept that and they are very useful. However, these examples ignore the protocol stack and the reference architecture. Alice and Bob - as roles that use authentic emails - will never even know the existence of ITDP or TSP, because they will be users of an application layer software. And most of the questions you may be pondering will and should be implemented by higher layers: Trust Tasks and Apps. If an App's goal is to provide more similar trust understandings among all of its users so that they have similar intuitive feelings to trust their fellow users, then they could. They will most likely invent another layer 3 protocol on top of ITDP - say, trustworthy email protocol or a much better name. They could say their app requires real identities that are VC's. They could even say it must be based KERI and GLEIF. They choose who their customers and use cases are. They don't have to be universal nor have to be stick with choices made in ITDP - because ITDP tries to make as little as possible. On the flip side, they could also choose to support more than one types of communications in their App, they may, e.g., you must use KERI and GLEIF for payments over 100 dollars, but for casual messaging or for less dollar amount, an OIDC based VID is fine (or more precisely OIDC by OP's in an acceptable list is fine as EUDI is pondering). This flexibility is extremely important. Now the benefits of ITDP start to show up, you don't have to invent two Apps, the same App can support both serious transaction and casual communication needs based on the same layer 2. In fact, you can have Green App and Blue App users talking to each other for casual messaging or for less dollar amount payments. You could also have not just GLEIF, but ALEIF, BLEIF,... other acceptably strong IDs that Green App and Blue App will agree on and their customers can interact with more than 100 dollar transactions as well. Users are not aware of ITDP. But ITDP provide the basic common ground where developers of Green App and Blue App can work with to achieve interoperability in a fashion as they see fit. I do not dictate how they should do it or what/who they should trust. That's End-to-End decision - ultimately it's the user (and apps who try to satisfy users) to decide.

Let me then respond to the PURPOSE problem. I am sure designers of a particular scheme/protocols have some purpose in their minds, and MAYBE part of that purpose is "exclusionary" - i.e. to restrict communication rather facilitate, to keep bad actors out they always say. First of all, I will say that this type of "exclusionary" purpose is against the principle of the Internet. We have such technologies such as firewalls. I don't believe they work very well. We also have "walled gardens". We also have softer methods such as EUDI or ToIP's trust registry etc. So maybe a more fine grain balance can be found. But as a principle, once that illusive boundary is drawn, people will push it to its limit, and more often than not, find a way to pass it. Sometimes way pass it to render it meaningless. Because connectivity is a reward worth some risk - the benefits often out-weight the risk. We will always have risks - it's the question of how users/parties assess their risks vs. rewards. Riskless internet is an oxymoron. I'm not saying we shouldn't try to establish the multifaceted mechanisms of trust, quite the opposite, I'm saying risk assessment (therefore trust) is end to end. As much as we can do in layer 2, that decision should be in higher layers. Second, about "KERI doesn't actually want to carry on a conversation with someone who is using an arbitrary VID". I think what you meant is that you think KERI is designed not to do that. KERI is a protocol who can't "want". The designers of KERI can "want". That's a meaningful difference. Once KERI is a spec or code, other implementors can use it in any way they "want". The App developers can "want". Their users can "want". They would want an app that is useful, fun, can do a lot of things. CEOs may "want" to use Blueberries - the rest of us "want" iPhones. I'm not suggesting which one is better, I'm saying users /use cases' needs are very diverse. As I said before above, I, as an app developer, may want to adopt KERI because I want my app to be able to transact more than 100 dollars. But also, my app want to attract new users and casual users, it is not A or B. It's both. If KERI insists not talk to casual users, then I as a developer will have to not use KERI. As I have shown, there's no real conflict at all, accepting VID in layer 2 does not prohibit you from refusing any VID in layer 3 or layer 4! There is no reason why I can't have both. My third point, ITDP or a minimalistic spanning protocol, allows freedom of choice. Take KERI, I have strong respect and interest to KERI, but if someone in the future comes up a new method PERI - equally good or better etc etc. How would PERI enter the market with interoperability so it has a chance to gain market adoption (at the expense of KERI and all others of course). I believe that is very valuable. This comes to the word I actually learned from you "pressure". Interoperability leads to this pressure and also the freedom (I call it liquidity and forward freedom) to compete in an open market. This is clearly the case for IP (the protocol) - it allows us to replace both beneath of it (from slow dial up to 5G) and above it (from email to YouTube, blockchain, ChatGPT). I bet you agree on this benefit too. To your last point, I hope my continuing efforts can sway your views on Connectivity or Interoperability (which I see it, for the purpose of trust spanning layer, as the main goal).

[jospencer-460]

I think this brilliant "discussion" illustrates exactly the challenge we have. I wasn't suggesting that a logical architecture is the end-goal, but it's a critical component of the consolidation stage.

Once we've got a good description of the common view of the protocol design components and requirements, we should then use this to assess different proposals, understand their equivalence and define the appropriate use of solutions for particular use cases / interaction types.

Like you, @dhh1128, I'm not a fan of some of these proposed solutions (e.g. OIDC4VCI/VP) for broad adoption. I have the view that we need to be able to have different levels of trust in our interaction protocol, a bit like Level of Assurance in the NIST etc. data definitions.

Unfortunately, we're not developing in a green field. It's brown, muddy and mucky....!

I think we need a view of what we want to end up with and how we're going to get there. Looking forward to the continued discussion.

[mwherman2000]

I wasn't suggesting that a logical architecture is the end-goal, but it's a critical component of the consolidation stage.

Agreed. Call it a reference architecture or baseline architecture. This is what you see here:

1. Why Mediators (or equivalent) must be part of the Trust Spanning Protocol #37 (reply in thread) , and here:
2. Proposal 5: Withdraw Proposal 1, Proposal 2, and Proposal 3 #39 (comment)

[talltree]

Just to return to the original subject of this thread, the first TSP Workshop — a two-hour deep-dive — will be held this coming Thursday April 6 at 1:00-3:00PM PDT / 20:00-22:00 UTC / 22:00-24:00 CEST / 06:00-08:00 AEST. This is in addition to our normal NA/EU and APAC meetings this Wednesday at their normal times.

Please check the ToIP Calendar for the Zoom link.

The agenda for this meeting will be discussed in tomorrow's TSPTF meeting.