Clarify the protocol "forerunners" and their relationships

[andorsk]

For the candidates for TSP protocols:

Is it supposed to sit on “top” of DWNs, KERIs, and DIDComm or is it the responsibility of these protocols to figure out how to conform with TSP? How will it interact with these candidates. Looking for some clarification and discussion around this.

I.e

graph TD
    subgraph TSP
       DWN
       DIDComm
       KERI
    end

Loading

or

graph TD
   TSP
    subgraph Candidates
       DWN
       DIDComm
       KERI
    end

 
KERI --> KERIAdapter --> TSP
DIDComm --> DIDCommAdapter --> TSP
DWN --> DWNAdapter --> TSP

Loading

[sawhitmire]

The process of verifying an identifier requires message creation, routing, delivery, and interpretation. If a message originates in KERI, for example, it has to be routed and delivered to some endpoint somewhere. Routing and delivery are something that all layer one protocols share, and the mechanisms need to be shared as well (a good argument for the hourglass model). The differences between a KERI message and one from DWN or some other protocol matter only in the creation and interpretation operation which we can delegate to the end points. Intermediary systems need not, and should not, be aware of the contents of the payload, and that includes the protocol used to create it. The interface to the TSP can be very simple: give me a message with a destination and I'll make sure it all gets there. The answer to your question, then, is that (I believe) the TSP rides on top of the protocols you name in layer 1 and provides a very simple interface for a single operation, making the TSP layer very thin, but very flexible. IP, for example, doesn't even guarantee delivery, TCP in the next layer up does that.

[sawhitmire]

Rather than just a packing and routing protocol, perhaps the trust spanning layer should comprise the two operations that everyone will need to do: create a new ID, and verify a presented ID (with options to indicate the far end of a trust chain -- more later). This will alleviate the need to validate these two operations and will allow users to "trust the network" to perform the operations correctly and know that the results returned can be trusted (this is the "trusting the mechanism" part of a trust decision. On issue, the issuer's wallet will determine the level 1 utility to use for creating new VIDs. On verification, the VID for the presented claim will determine which level 1 utility to use. So, putting these two operations into the spanning layer makes some sense. Really, the spanning layer is these two operations, since TCP or UDP will use the IP layer to do the actual packing and routing.

[guru-barbes]

I think I understand and agree. If we're introducing the element of trust, don't we want to ensure that the messages being routed are verifiable? Does the TSP need to verify, or just make sure that the only messages that go through can be verified - before or once they reach their endpoint?

[dhh1128]

Neither of the diagrams above matches my mental model. I would say, rather, that each of the "forerunners" has that label because they have features that the final TSP needs. I also hope that each of these protocols evolves into TSP in the sense that people starting from one of those protocols ends up feeling like it was an easy, obvious evolution to arrive at the eventual TSP.

[andorsk]

I just watched @SmithSamuelM conversation on TSWG Plenary, and I think it's ironically aligning with some of the ideas I suggested in the TRTF, around building a logically thin model with maximal adoptability. Seems maybe there's two thin layers:

graph TD
    TSP[Trust Spanning Layer]
    TRSL[Trust Registry Routing and Discovery Protocol]
    TSPP[Trust Registry Protocol]
    TRSL --> TSP
    TSPP -->TRSL 

Loading

In this case: TSP is maximally thin, the "Trust Registry Routing and Discovery Protocol" is a thin a layer above it to talk to provide mechanics around discovery, attestation, and routing (possible, still defining scope here), then the TRP is the most "feature intense" and "logically strong" protocol, which is what @darrellodonnell has been focused on ( i think ) .

As you may recall from the TRTF, I'm particularly interested in the TR Thin Layer. Limited scope, widely adopted. I gave an example of similar to TCP. Maybe it's more like ICMP or another routing protocol instead of TCP.

As an analogy to the current internet:

graph TD
    IP[IP]
    TCP[TCP]
    HTTP[HTTP]
    TCP --> IP 
    HTTP --> TCP 

Loading

To that point though, DWN and DIDComm ( not going to discuss KERI here ), try to increase features, not limited features. I would argue that if TSP is trying to limit scope as a thin logical layer with maximal functionality, these are not good examples of "forerunners", in fact, these are contrary models and in conflict.

It's still unclear what the goal of TSP is related to scoping. How "strong" do the layers intend to be in TSP?

[talltree]

@andorsk You may well be right. We will be diving deep into that very conversation starting with @SmithSamuelM's presentation in our Wed Feb 8th meeting (at which I'm sure Sam will get into KERI and CESR).

As far as how "strong" the TSP layer needs to be (or any layer in the ToIP stack, for that matter) — making that decision is the whole essence of protocol stack design. In @SmithSamuelM's presentation on the Hourglass Model, he argued very hard for the TSP layer to be — in my words — "as thin as possible but no thinner". I'm sure he'll go into great detail about that in his presentation on Wednesday.

[andorsk]

@talltree You're correct about the orientation. Thanks for calling it out. I'll fix it.

@talltree my two cents on top of this is that if TSP is supposed to be a thin layer, then it's probably the bottom diagram of the original post.

graph TD
   TSP
    subgraph Candidates
       DWN
       DIDComm
       KERI
    end

 
KERI --> KERIAdapter --> TSP
DIDComm --> DIDCommAdapter --> TSP
DWN --> DWNAdapter --> TSP

Loading

That is most aligned this this. DWNs, DIDComm, etc need to comply with the thin layer of the TSP.

The point here I'm just trying to make sure is clear, is we currently have some pretty widely used implementations already on the market (DIDComm probably the most prevalent). Whatever the solution is, it would be great to keep in mind compatibility and transition models with an existing ecosystem.

[talltree]

@andorsk I could not agree more about the need to "keep in mind compatibility and transition models with an existing ecosystem". We didn't start ToIP with the intent of disrupting existing protocols for decentralized identity and trust. We started it because we believed the only successful path to global interoperability of decentralized identity and trust infrastructure was a layered protocol stack like the TCP/IP stack. So that's what we're designing — step by step — as fast as we can.

If we're right, all (or most) of the existing protocols will adapt to run over TSP just as your diagram suggests. If we're wrong...well, hopefully we'll have learned some valuable lessons in the process.

[JoOnGT]

I don't see various interaction mechanisms (KERI, DIDCom, mDL, DWN) interfacing to the TSP. I see them providing equivalent capabilities within, above and below the TSP. Is that so wrong?

[talltree]

In terms of evaluating the "forerunner" protocols, I want to highly recommend that TSPTF members read this Medium article by @dhh1128 called Sentries, Confessionals, Vaults, and Envelopes.

To quote from the opening paragraphs:

The decentralized identity / SSI space is troubled by persistent misunderstandings about the overlaps between important technologies: OpenID Connect (OIDC), CHAPI, Decentralized Web Nodes (DWNs) [and similar members of the secure storage family], and DIDComm.

Sometimes these are described as competing solutions. I think that’s unhelpful. They do compete for our time and attention, I suppose, but they solve different problems for different reasons — and a clear understanding of these differences would go a long way to resolving contention in our community. So I’d like to offer an extended metaphor to make sense of it all.

IMHO, Daniel's "extended metaphor" is a brilliant framework for understanding the different purposes and designs of these four protocols — and thus exceedingly helpful in helping us lay the conceptual foundation for the design of the TSP.

[talltree]

I have a second very strong recommendation for all TSPTF members: take a hour in the next few days (ideally before our next TSPTF meetings this coming Wednesday) to watch this presentation @SmithSamuelM made about the Hourglass Model at last Wednesday's APAC meeting of the Trust Registry TF.

Sam uses a series of diagrams to walks through the history of the Hourglass Model and show precisely how the IP spanning layer works in the TCP/IP stack — with a special emphasis on how the IP layer is — and is not — involved with discovery and routing.

Sam gave that talk to set the stage for the TSP proposal he will be presenting in this Wednesday's (Feb 8) TSPTF meetings. So it will be extremely helpful to anyone attending that meeting to have watched Sam's talk first.

(Note: I will be cross-posting this message in GitHub, Slack, and email to make sure everyone sees it.)

[SmithSamuelM]

@andorsk Your diagram showing trust registry protocol illustrates an important point about trust. I believe there are two fundamental types of trust that need to conveyed. I call these attributional trust and reputational trust. In my conception of a trust spanning layer the only trust in the spanning layer is attributional trust. A higher layer can convey reputational trust and a trust registry is a type of reputational trust. There are other mechanisms for conveying reputational trust. So these all would expand out above the spanning layer. This keeps the spanning layer thin while supporting reputational mechanisms.

[andorsk]

@JoOnGT if trust registries are an "architectural construct" then I think "reputational systems" would be too. The more I think about it, the more I believe a trust registry is just a special case of a reputation system. This lines up with the "attributional" vs. "reputational" trust that @SmithSamuelM describes.

[JoOnGT]

Careful @andorsk!

Reputational Trust is an outcome. Trust Registries are systems/services. Reputation is a combination of formal (external defined) and informal (internally agreed) definition. Trust registries may support the formal definitions, but are unlikely to support internal (history, network, or responsibility based) informal reputation building.

I see the internal orchestration of external solutions/services as something to be covered in the trust stack(at the application layer). We've not covered the internal trust application logic within an endpoint application which would then support reputational trust decisioning.

A mental model framing these concepts would help...

[andorsk]

@JoOnGT : I am being careful. What you have described to me does not convince me that a registry is simply a special case of a reputation system. Reputational trust isn't an outcome, it's an attribute of trust. Ditto with attributional trust ( not helpfully named ) is also an attribute of trust. An output of trust is a trust decision, which is out of scope. I am focused on generalizing past the implementation details, into a core mental model so we can align technical support across systems. My point is there's a fundamental model that describes both systems, albeit the actual implementation often diverges quite drastically in practice. That realization is important, as it enables us to conceive of technology that spans many types|flavors of implementations within a single common layer.

[JoOnGT]

We've drifted into the TR/VDR discussion and well away from the TSP.

A mental model that illustrates the combination of inputs into a trust decisioning would undoubtedly be useful. Without this as a guardrail, we'll be forever talking past each other. If we can put something together that frames the process and inputs into this, great.

I see a verifiable data registry is just that... My concern is that we should try to frame the endpoint business process so that it can develop consistent solutions at equivalent endpoints across an ecosystem of Relying Parties. The need for endpoint-specific logic may always be required, but the segregation of that from the generic solution processes must be possible.

If we need to frame consistent processing logic for a use case and supporting VDRs, we should. That's way more than the TR/VDR service definition and the TSP.

[andorsk]

Agreed this moved out of scope for the TSP, with the relevant question to the TSP being "how thin is the TSP logically". Thank you. I'll reference this discussion here to not distract this thread.

[SmithSamuelM]

@talltree your diagram showing KERI sitting above a TSP is incorrect. KERI is a concrete example of a TSP. Whereas DidComm is more about discovery and routing and transport than it is about a TSP. And DIDComm does many things and in my opinion is really protocols from different layers and different purposes. For example a routing stack has routing speciific protocols that sit above the TSP but only for router applications not trust applications. This is where much confusion exists.

[SmithSamuelM]

@dhh1128

So, I claim that the argument for pure authenticity is reductionist. Full of mostly true statements -- and I'm a big fan of authenticity as Sam has implemented it. I just think we need some nuance here, not just mathematical elegance.

So instead of hypotheticals propose something substantive that MUST be in the spanning layer besides authenticity where authenticity is limited to secure attribution to a cryptographic pseudonym via an identifier system security overlay.

I have yet to see anything substantive. And arguing over whether or not thinner is better is pointless unless we are using it to compare two different substantive design choices. I know you are working on such a proposal but I think you think that the proposal for the spanning layer I put forth is based on highly theoretical rather than practical considerations. I already implemented in 2013 a production (used by fortune 500 companies) cryptographic end-to-end protocol on top of UDP called RAET. It was way too thick. When I revisted the whole idea with KERI I needed a better approach so I found the hourglass principle very helpful and very practical.

The practical advice of the hourglass principle is that a stack should have many thin weak layers versus fewer stronger layers. So CESR is now its own protocol layer, SAID is its own protocol Layer. The CESR stream parser is its own protcool layer. KERI is getting thinner as a result. And there are applications that use SAIDs and CESR like ACDC that don't need to get those from KERI now. Other applications that don't need KERI will spring up that use CESR independent of KERI. Because we are converting one thicker layer into multiple thin layer.

So the TOIP stack has 4 layers and abstractly this is OK as a discussion point but its actually quite confusing to try to figure out which of the four layers some things go. We had numerous discussions in the architecture stack working group that tried to figure out which layer to place something.

In contrast, the hourglass principle says the number of layers is not pre-determined. It says look a the support sets of applicatoins and if they are additive spit off another thin layer to isolate the unique features to a given application support unless other considerations make is less adoptable. This means there is no fixed set of layers and one can support a new set of applications by adding an additive layer instead of shoehorning features into an arbitrarily fixed set of layers. I found not having to have a fixed set of layers very productive in terms of design decisions. And if I could image an additive layering that allowed me to add features later to support a potential application without thicking a given layer at the time that I needed to implement the given layer then its implementation was not blocked waiting to figure out the details of the imagined feature set with confidence that I could come back later when needed add the additonal feature using a new thin layer. And if adoptability requires that I merge thin layers later then I can also do that as well. But frankly I have yet to see that. Indeed more often than not I realize my layers were too thick to start with. Which is why I pointed out that IP is actually too thick because fragmentation as implemented is nearly useless and the feature of reliable fragmentation had to be reimplemented better in upper layers. This is not an indictment of the hourglass principle but confirmation that intentional use of the principle (as opposed to a serendipitous usage) should give even better results than IP had.

If the application layer can't leverage the support set below the spanning layer because the spanning layer is missing a feature and that feature can't be added in a layer above the spanning layer but below the application (interposed) then that feature becomes a strong candidate for joining the spanning layer.

If the feature can be interposed without thickening the spanning layer but putting it in the spanning layer increases adoptability then that feature is also a candidate for going in the spanning layer.

And these guidelines can be recursively applied to all the interposing layers between the spanning layer and the end user application.

A comparable set of rules guild the layering below the spanning layer. If I can broaden the support by adding a thin layer below the spanning layer then that should be done unless putting the feature directly in the spanning layer increases the adoptablity even more.

These are very practical guidelines.

[dhh1128]

So instead of hypotheticals propose something substantive that MUST be in the spanning layer besides authenticity where authenticity is limited to secure attribution to a cryptographic pseudonym via an identifier system security overlay.

First of all, I get that I need to provide specifics. I will. You had years to construct the mental model you're articulating. I have not been thinking about it as long, so if it takes me a few days, please be patient. I promise I am not ignoring your arguments. I am not going to propose something simplistic and fat like "DIDComm should be wholesale dumped into the same layer as authentic sources."

I largely agree with your guidelines. Not only do they match the hourglass theorem, they also match three decades of my experience doing architecture, which leads me to like narrow and simple interfaces over fat ones.

My assertion that your framing is too theoretical comes from the reductionist language that pervades the narrative. It's language that emphasizes one theory to the exclusion of all others, and that discourages an analysis of any tradeoffs besides strong/weak as Beck strictly defined them. I imagine this is because you passionately want people to see the profundity of the generalized principle, and that requires us to squint away some details -- but to me, it seems to come from a place of suspicion that unless the theory is tenaciously defended, nobody will truly believe the doctrine and apply it wisely.

I am not saying your language is always devoid of nuance; in fact, the long comment directly above has several important hedges that I agree with. And you said "the devil is in the details" and several other things like it that are wise and true and important. But I seem to have to push to get such hedges to surface; if I were silent, the discussion would become too simple. An example of reductionist language is the word "MUST" in the sentence I quoted above. Another example is the word "universal" as an inflexible criterion instead of a very, very suggestive and important one. Another example is the narrative framing that if there is any number >1 of things in the spanning layer, we can know by definition that the spanning layer is suboptimal. (I know, not all of this language comes from you.)

I feel like an old-and-not-especially-brilliant-but-crusty-and-hunch-driven physicist in 1907 who shares his colleague's thrill with special relativity, but who keeps saying, "This is awesome, and we should totally use it -- but let's not forget Einstein's frustration with gravity, or Planck's wrestle with blackbody radiation." Clark hinted as some reasons why the spanning layer wasn't the sumum bonum of design considerations, and so did Beck. Let's admit that, and work through it.

[SmithSamuelM]

@dhh1128 I appreciate the need for nuance and I will try to use language more accepting of nuance. I sometimes forget that I carry the baggage of pushing for these last few years against a wall of protocol designers that are adverse to anything but end-to-end principles. Sometimes to change someone's perspective its helpful to crystallize the discussion not with vague nuance but with stark contrasts. Schrodinger was roundly dismissed by the Copenhagen Cabal and had to fight for years to get his highly contrasting wave theory view of the electron accepted vis-a-vis the Bohr particle model. It was only by pointing out stark contrasts that other's could let go of their prior assumptions.

[SmithSamuelM]

@dhh1128 We are dicussing concrete specification proposals where the technical meanings of the words MUST, MAY ,SHOULD are intentionally reductionist because it's essential to specification design. Maybe we should have more preliminary discussion prior to postiting proposals, but there seemed to be consensus that we should start with proposals and so I though it proper to be more reductionist as a result, especially to criticisms that are vague with respect to the actual proposal.

[SmithSamuelM]

@dhh1129 Your defense of nuance is a valuable addition to the discussion its one reason you are a chair of the working group. I hope you find that when presented with practical considerations that require nuance and refinement that I am sufficiently accommodating.

[SmithSamuelM]

@andorsk The devil is in the details. The talk I gave that drummond references sets the stage and the talk I am about to give will go into details on how to answer these questions. Its not as simple as a yes or no (forerunner or not) and I think that we should be viewing the concept of a forerunner very loosely and not try to diagram them just yet. The nuances are too many.

[andorsk]

I'm fine with deferring for now and considering the concept of "forerunner" with a loose perspective, temporarily, or for the foreseeable future.

[andorsk]

To @SmithSamuelM point, even using the nomenclature "forerunners" might be problematic. It might make sense to just avoid that word entirely, until there is a set of proposals. It sounds like for the TSPTF, forerunners is overly reductionist, and likely to cause more confusion than good. We've seen how much nomenclature matters in the TRTF, so I'd advise to be careful about falling into that same challenge in the TSPTF. @talltree I know you can resonate with this challenge.

[talltree]

@andorsk That's why even the term "forerunners" is in quotes as the title of this overall discussion. I'm wide open to a better term — but as we get deeper into the actual work of the TSPTF, I think we'll have less and less need for a term for "the protocols that went before".

[andorsk]

"Prior art", "Inspirations", "Relevant work"?

[SmithSamuelM]

@andorsk

Reputational trust is a human decision that includes many things we can provide and a bunch we can't

The field of automated reasoning which is a subset of what many now call AI is all about converting human decision into something a computing machine can do. It requires what we in the field call "reasoning in an environment of uncertainty". But the decisions using appropriate techniques can be highly reasonable and highly certain. So it is not al all beyond the scope of "trust over the internet" to consider upper layers that mange and compute reputational trust.

Indeed, applying my expertise in automated reasoning to solve the reputation trust problem is what originally drew me to this field, now 8 years ago and counting.

But that said, its pointless IMHO to even consider automating reputational trust until one has solved the attributional trust problem. And the later is what a TSP is all about.

[sawhitmire]

@SmithSamuelM, that comment was mine. I'm with you on automating decisions when we can, and on the ability of some well-formed AIs to make many of our rule-based decisions. But the decision to ultimately trust someone also includes huge emotional and contextual elements. For example, under normal circumstances, I might trust you without question. But, say I was burned by someone with a similar reputation whom I also trusted; my trust in you has diminished through no action on your part, and no AI will be able to take that into account. At best, I can set conditions under which I trust your reputation ahead of time, and an AI or even just an expert system can determine whether those conditions have been met. This is similar to pre-vetting a new supplier before you start to order from them. For another example, I may again trust you implicitly under normal circumstances, but something happens in the chain of links between you and I and I no longer trust the chain. Even if I still trust you , I can't trust the verification chain, maybe only temporarily.

[andorsk]

@sawhitmire getting into this is a bag of worms. Personally, as my background is in AI/ML and I hate biased trust systems, so I believe lots of trust systems can be automated, however, my perspective on ways to better make trust decisions are irrelevant. I don't believe it's within the scope of ToIP to define how someone makes a trust decision. It's a very personal choice about what type of mechanic you want to use to create those judgements. What I think within scope though is the technological support for getting the right information to make an informed decision, whether based on AI/ML, heuristics, or just human judgment.

[sawhitmire]

I agree with you, but I feel like I'm hearing different things. We need to know enough about a trust decision to know what information is needed, but you're right, all we can do is provide it.

[andorsk]

We don't need to know about the trust decision itself. We just need the technology to support getting the information needed. So we need to have an underlying, descriptive model that defines a general, and not specific, trust decision and we need then technology to support the model (i.e in this particular model I've shared above, how to build $C$ with technology). We don't need to know what your $C$ is that is required for a particular decision (however, I could easily see non-normative guidelines around this), but there needs to be a way to represent $C$ such that you can make a trust decision, in whatever framework/methodology you choose.

Re: attributional vs. reputational trust. If TSP is "attributionally" designated, then I'm proposing another thin layer be involved to support a "reputational" support. This might be an effort outside the TSPTF, but is impacted by how thinly scoped the TSP is.

[SmithSamuelM]

@sawhitmire

good comments. For example the condition of being burned by someone with a “similar” reputation. I am not sure what you mean by “similar”. I can trust multiple people for being honest and in general if one of them proves to not be honest I don’t assume that all honest people are dishonest. Off course if I ascribe other attributes like race, age, cultural background as predictors of honesty then yes I could infer based on a false attribution that members of a class inherit or disinherit honesty by membership in the class. But that would be a poorly design reputation system in my view.

More realistic is reputation by reference. In this case I trust someone because someone else whom I trust referred them to me. In general good reputation systems are reflexive. That is anything I do to confer reputation on someone else simulataneously confers reputation on me. So there is no free lunch. If I refer someone to someone else and that referral does not live up to my referall reputation then my reputation as a referrer will suffer proportionately. This makes referals reflexive. This provides a self-normalizing feedback loop. If you think of a reputation more like a control system ( I am a published expert in intelligent control systems which merge automated reasoning and control theory) then you see reputation as a way to modulate interactions between persons and their actions adaptively train the modulation system via nested feedback loops. So yes AI modeled as controls systems can indeed take into account the reflexive nature of human class reputation systems. And like any real world system you have uncertaintly that must be properly modeled.

I have written on formal reputation system design (see the OpenReputation white papers and presentations in this repo https://github.com/SmithSamuelM/Papers).

My definition of a reputation is as follows:

a reputation is a contextual predictor of future behavior that modulates an interaction (transaction)

As a predictor is mesures the risk of engaging in a transaction. One might then weigh the cost benefit of such a transaction in light of the predictor.

A good rule of thumb would be don’t risk more in a transaction with an entity than that entity risks by losing its reputation should it cheat you. If loss of reputation is not enough then you have to make that entity put more skin in the game or you dont take the risk.

Human communities traditionally have very expensive reputation systems and loss of reputation can be extremely costly. Online we don’t yet have anything as good but not because we cant but because we need secure attribution first. When I can’t know you then I can’t trust you.

[sawhitmire]

@SmithSamuelM I actually wrote about a way to measure features and requirements in 1997 when I wrote about measuring object-oriented designs. The scheme I used is exactly the scheme you described above, which is gratifying.

One of the insights that the 3GPP group (mobile telecom protocols including 3G, LTE, 5G, and beyond) discovered is that the interfaces are what matter in an architecture. In their world, the interfaces consist of the messages between components including content, format, timing, and language. The specify message formats in great detail, but actions only in terms of the minimum necessary outcomes. The idea is that any actor that can understand and process the message will work in the network. IP takes that view as well, and so should we.

How does that relate to this conversation? Features in X and Y as we discuss them should be information, not actions. We should agree up front that the message content and format are what matters and that any actor that can understand and do its part is good enough. As long as the payload is not altered and we can trust the sender, we don't need to trust in intermediate actors. That allows for competition, for one thing, and flexibility in the chain for another.

[SmithSamuelM]

So for example, my proposal this morning that the TSP only includes an identifier security overlay where the overlay provides secure attribution to a cryptographically derived pseudonym which derivation includes the controlling public keys from the controlling digital signing keys. we could consider splitting that layer into two layers the lower layer is for ephemeral identifiers that do not need a keystate proof because the identifier is essentally the public key and a persistent identifier layer that sits above that uses identifiers derived from the incepting event of the key state proof. But the feature set is not X + Y. Becasue an ephemeral identifier derivation is different from a persistent identifier derivation. So the peristent identifiers have zero supporting features in the ephemeral identifier layer (in other words X supports ephemeral and Y supports persistent fully and no features from X are needd to support persistend. So neither X or Y span. and so the spanning layer is X + Y.

That said we could define crypto derivation as the spanning layer and then have layers above each for the different derivation process. So we could revise the spanning layer to be more layers. There may be a point of diminishing returns where splitting into thinner layers provides no practical benefit. If the split does not have any common concreate features and an abstract concept is the only thing that spans, then I would argue we have gone too far. Concrete features that are common i.e. in the intersection of the support sets for layers above are candidates for a spanning layer feature set.

The way i resolved this with KERI is that there is really only one type of identifier and that is a persistent identifier but as a special case if there is no unique information in the inception event that contributes to the identifier derivation other than the public key then we have a functionally ephemeral identifier because we have eliminated the need for a key state proof. We indicate this by prepending the derivation code to the identifier to know we don't need an inception event to determine key state. We shortcircuit the key state proof. This is like using 127.0.0.X for local ip addresses that short circuit routing by looping back at the IP layer instead of a lower layer. 127.0.0.x addresses are special IP addresses and ephemeral AIDs are special AIDs.

[SmithSamuelM]

@dhh1128 Did my response above help resolve the tension of what the hourglass principle means.

[dhh1128]

Your careful description of the principle matches what I got out of the Beck paper when I studied the formal logic myself, earlier this week. Perhaps it will save some other people the study time. Thank you.

I now understand what you intended by "universal," which is great. However, your comment does not resolve my concerns. In formal debate, there are direct challenges to an argument on logical or evidentiary grounds, and then there are challenges that step back and question what's called topicality -- whether we are even debating the same question, with compatible assumptions. My concerns are more along the latter lines. I promise I will explain, but I want to do it concisely and carefully; I don't have time for that today.

[SmithSamuelM]

It would be good to explore the topicality boundaries for the TSP. Looking forward to your presentation.

[darrellodonnell]

“ I promise I will explain, but I want to do it concisely and carefully; I don't have time for that today.” I have learned that the wait is always worth it Daniel. Thanks all for all of this excellent discussion.

On Wed, Feb 8, 2023 at 15:36 Daniel Hardman ***@***.***> wrote: Your careful description of the principle matches what I got out of the Beck paper when I studied the formal logic myself, earlier this week. Perhaps it will save some other people the study time. Thank you. I now understand what you intended by "universal," which is great. However, your comment does not resolve my concerns. In formal debate, there are direct challenges to an argument on logical or evidentiary grounds, and then there are challenges that step back and question what's called topicality -- whether we are even debating the same question, with compatible assumptions. My concerns are more along the latter lines. I promise I will explain, but I want to do it concisely and carefully; I don't have time for that today. — Reply to this email directly, view it on GitHub <#5 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAFHWBYOUXD4EVU6BHCQJUDWWP7UJANCNFSM6AAAAAAUGROZVI> . You are receiving this because you were mentioned.Message ID: <trustoverip/trust-spanning-protocol/repo-discussions/5/comments/4909386@ github.com>

-- *Darrell O'Donnell, P.Eng.* ***@***.***

[talltree]

I want to pile on to @darrellodonnell's reply and say I totally agree that this is a fantastic discussion — in fact the exact discussions that should be at the heart of this task force — and I'm thrilled that we are already this deep in our third meeting. (It also illustrates exactly why Github Discussions is such an essential tool for us.)

@SmithSamuelM Thank you for such a wonderful presentation and discussion today. @dhh1128, take the time you need — the more distillation of your thoughts you do, the faster everyone else will comprehend.

[talltree]

Also, as a suggestion, since this discussion is largely inspired by Sam's presentation today, I suggest trying to continue it in this discussion thread devoted to Sam's proposal.

[SmithSamuelM]

@sawhitmire

As long as the payload is not altered and we can trust the sender, we don't need to trust in intermediate actors. That allows for competition, for one thing, and flexibility in the chain for another.

This is a good way of describing the concept of "end-verifiabilty" a secure identifier system overlay provides. The path doesn't matter because the end can always verify that the data, message, or information came from the source so identified via the signature. This allows a TSP to use untrustable routing networks which expands the support and broadens adoption which is what the hourglass principle is telling us to do. That does not mean we can't also have trustable routing in the support as well. The more the better in the support of the TSP.

[darrellodonnell]

I will naively weigh in here with a thought that has been bubbling in my head. It hasn't fully formed (they rarely do in my skull) but I'll share my thinking. Given the communications layer has largely been settled over the internet as TCP or UDP, both over IP, I keep thinking the following: * TCP works well for most applications because it handles the hard stuff - retrying, packaging, etc. * UDP works for specialized use cases where the trade-offs of TCP impact the need that UDP solutions serve. In my mind I want a TCP equivalent that handles the main messaging, retry, etc. for the majority of things that I see us needing. However, I also recognize that UDP cases exist. So the question to me is this - what is the real "thin waist" of the internet. Given that an address is useless without a communication approach, I'd argue that the TCP/IP and UDP/IP components comprise the thin waist...

…

On Thu, Feb 9, 2023 at 11:54 AM Daniel Hardman ***@***.***> wrote: one could argue that the fragmentation feature of IP could be removed and make the layer thinner if it were not for backwards compatibility concerns So we have a winning spanning protocol that isn't pure and contains some pragmatic compromises, and it still won handily. Why? Because it was a noticeably better spanning protocol than its alternatives. *That* -- not perfection in alignment to a theoretical model -- is the true predictor of adoption. Insisting on a single feature is not only not what Beck or Clark advised, it is actually not validated by any history. Not by IP, and not by the Unix kernel. (It was the Unix kernel, not its shell, that Beck and Clark cited, BTW.) In his analysis of the relationship between the hourglass theorem, Beck himself points out (page 53) that reflexively pushing features out of the spanning layer into higher-level application constructs doesn't necessarily optimize weakness: Moving function upward in a layered system can have the effect of removing responsibility for particular functionality required by applications from lower layers. This leaves higher layers free to implement their true requirements without imposing costs or other artifacts due to inappropriate functionality being implemented by lower layer services. However, when applied to the spanning layer, end-to-end arguments do not necessarily lead to a design that is logically weaker, and thus has more possible supports. Instead of doubling down on the logical purity of authenticity, I invite you to consider a different question for a minute: *Given two spanning layers that span an identical set of supports, but which differ in strength (one supports more applications than the other), which one is better?* The answer, I submit, is NOT "whichever one is weaker." The whole point of making something weaker is to increase spannable supports, and I've just said that the difference between the two is irrelevant in this respect. The answer, I submit, is also NOT "whichever one is stronger." That's too simple. First we would have to evaluate whether the applications atop each one are actually the applications that we intend to support. Beck himself points this out: "The balance between more applications and more supports is achieved by first choosing the set of necessary applications N and then seeking a spanning layer sufficient for N that is as weak as possible. This scenario makes the choice of necessary applications N the most directly consequential element in the process of defining a spanning layer that meets the goals of the hourglass model."(p. 52) If we had a crisp idea of what kinds of applications we want to enable, then we would tend to say that the stronger of the two *within the set of applications we want* is better. But even THAT rule isn't quite right, because as Beck himself points out, there are other considerations, like simplicity, generality, resource limitation. Clark points out another consideration like this, which is political rather than technical... So, I claim that the argument for pure authenticity is reductionist. Full of mostly true statements -- and I'm a big fan of authenticity as Sam has implemented it. I just think we need some nuance here, not just mathematical elegance. I further claim that we need a deep discussion about what kind of applications we want to enable. Sam's proposal treats all possible applications as uninteresting and equal. That's not what Beck said to do. — Reply to this email directly, view it on GitHub <#5 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAFHWBZIX3XRPTR56PIESDDWWVDORANCNFSM6AAAAAAUGROZVI> . You are receiving this because you were mentioned.Message ID: <trustoverip/trust-spanning-protocol/repo-discussions/5/comments/4924371@ github.com>

[JoOnGT]

Let me have a crack (and then everyone else can have a laugh).

If IP is the basic transmission, TCP and UDP define the sync/recovery protocols on top of IP.

In the concept of the ToIP TSP - a "trust construct" over a basic interaction protocol (IP) provides the endpoint identification/verification and packet delivery trust (using cryptography). This is the basic "thin waist". Other concepts, such as data encoding agreement, data interpretation agreements, recovery protocol, etc. can be (very thin) layers within or above the TSP.

Go on... have a giggle.

[andorsk]

@JoOnGT this is the mental model on my head. Here's where I initially discussed this and here. I think you're spot on. That second layer is what I'm pretty interested in and that sits right above the TSP and spans multiple service types.

[JoOnGT]

When you've grown up with the OSI 7 layer model, it's difficult to shake...

Here's a start at the Trust layering

[andorsk]

@JoOnGT I'll need to think about it, but this is definitely a start IMO. Nice work putting this together! @SmithSamuelM said he viewed ACDC's going on top of the TSP, but yea, this is a good start for a mental model to discuss IMO. How many layers, the order, and scope of the layers, I think will need some time to flush out

[SmithSamuelM]

verification is up to the endpoint. Thus the. message must be verifiable (verifiable authenticity to the source cryptonym) or more explicity authenticatable. The sender can’t ensure that an receipient endpoint actually verified anything, unless someone wants to impose some very hard to build full duplex fully acked channel and a proof of verification sent back to the sender. Please no. We want async datagrams as the default.

@darrellodonnell Many protocols provide reliable datagram services on top of UDP (RAET for Reliable Async Event Transport) is one that I wrote for example). In my experience it is much easier to make UDP reliable than it is to make TCP scalable. But both are independent feature branches in the IP stack and therefore should not be combined to thicken the. IP layer. When we try to think of a protocol stack in the ISO OSI way we have a fixed set of layers and we have to then apportion all features to one of those 7 layers. A spanning layer protocol looks like a tree and some branches longer than others i.e. have more or less layers. some protocols sit at the top of many layers and some sit at the top of only one or two. the many thin layers gives a designer freedom to make each layer optimally thin rather than shoe-horning features because they have to go in one of a fixed set of layers. This allow the protocol stack to grow organically. This leads to more rapid adoption because its easier to add features as needs demand. Just add a thin layer usually. Instead of breaking an existing layer to thicken it.

[SmithSamuelM]

@JoOnGT

When you've grown up with the OSI 7 layer model, it's difficult to shake...

Amen!

I have spent the better part of the last 3 years trying to shake that OSI 7 layer model. I don't have to catch myself as much now when I get tempted to push features into slots in a rigid layering.

With regard your diagram. In the old days (circa IP), data in a layered protocol like IP consisted of C structs that provided self-framing headers. One of the fields in the C struct was the length of the header plus payload. Stacking layers meant nesting a layer-specific self-framing header. Upper layers nested inside lower layers. So when a protocol referred to data formatting and encoding it often meant the payload, not the headers. But with a Trust Protocol, cryptographic primitives need to be included in the "effective" headers. So CESR is used in the headers not just the payloads. That, coupled with CESR's grouping composition, means that CESR can provide self-framing payloads etc.

[JoOnGT]

I totally agree @SmithSamuelM - looking at the OSI model with the "trust lens" on, means you have to be flexible. But there's a lot of alignment with other messaging protocol design (including the format-content-context model of verification).

Of course, we have to be able to interpret the header to be able to carry out the base transmission processing. That needs decoding based on some pre-determined initial header interpretation and bilateral endpoint arrangement (I assume)

I had CESR predominantly at the payload interpretation, but it can be used at the TSP, once the bilateral processing mechanism has been agreed and the message header interpreted initially.

I'm not saying the picture is right, it might just be helpful. I'm working on my next one to articulate the input data retrieval and business logic for the "reputational trust" determination and endpoint decision modelling (all of that is built on top of the TSP)

[JoOnGT]

Thinking about your verification post @SmithSamuelM, maybe we should define a multi-state process for verification (like the validation process) - how about delivery-endpoint-contextual?

[SmithSamuelM]

@JoOnGT I am writing up an description of the header and payload model used by CESR enabled KER ,and ACDC protocol layers.

I think this will provide a very useful example as a point of departure for discussion and crytallize some of the design choices. If for no other reason than I can explicate in detail why we made those design choices.

These protocols are now in production so the design example is not theoretical but has been battle tested some what. Many of the features you are talking about can fit it layers above. AFAIK the header structure is flexible enough to allow anything we want or need to extend the functionality.

The unique features of the CESR encoding for packets including headers, payloads and attachments (signatures, receipts, references to anchors etc) include:

• multiple serialization support for message bodies (JSON, CBOR, MSPK, CESR) where each message body can have any number of composed attachments in CESR. This is done in such a way that bare metal TCP and eventually UDP are supported in addition to HTTP in a packet streaming format. IMHO this is the most general, performant, scalable approach with the broadest support practical which attempts to satisfy the maximize deployment scalability in accordance with the Hourglass paper.
• Not only does it support the most popular IP protocols but also the most popular modern serialization formats. CESR is a special case that covers the at scale optimization needs. Fixed field CESR messages have the potential to be more compact than CBOR or MGPK for over the wire because CESR text and binary can can be converted en-masse back and forth without loss of parseability or decomposeability.
• CESR streams also support pipelining so can be optimized for the most demanding applications in the data center (pipelining is essential for core affinity for 40 Gbps or higher backbones that exceed the ability of a core to parse and must be offloaded using the pipelined chunks.

[JoOnGT]

That sounds very sensible @SmithSamuelM. I'm looking forward to see that detail.

The interesting challenge that we have in the TSPTF is to define a standard message definition and message processing logic, such that the same (or equivalent) interactions and processing logic can be developed by different solutions/vendors and we can enable ecosystems to evolve and change over time (whilst at the same time being live).

I'm a dead-nuts-keen fan of the CESR approach and outcome. But I'm a novice. My naïve thinking is that we probably need a framework definition (as part of the TSP approach and modelling) that makes it possible for data definitions and other options to be used in conjunction with the different messaging protocols.

I'm starting to wonder where and how the technical and business processing logic (for a specific use case and actor-action-event) is defined and discoverable. Part of this is obviously the definition of payload interpretation.

[SmithSamuelM]

@JoOnGT One payload data layer sitting above the TSP is the ToIP fostered ACDC protocol. ACDC stands for authentic chained data containers. It is a container for payload data with some specific features like chaining and revocation registries and different types of disclosure including selective disclose ( it is a type of VC) but takes a layered approach (factual claims in whatever format (JSON-LD or JSON) that one wants to convey in an authentic manner can be referenced in the payload of an ACDC. ACDCs are opinionted about having very strong security. Using a container with strong authentication means that a less secure W3C v1.1 can be conveyed over-the-wire with strong security using an ACDC or in some cases replaced by an ACDC. The W3C VCWG2 (VC spec version 2) is this week the Miami face-to-face going to be considering a "big tent" approach to VCs that would open the door to a TSP approach to VCs. Hopefully the community supports it.

[JoOnGT]

I've read a lot about ACDC and I'm a supporter.

I'm totally convinced that ACDC, or the features it provides, is a trusted payload "layer". Time to update my diagram...