Appendix B — Consolidated Views of ToIP Arch (was Figure 4)

[wenjing]

1) Layer 1 depiction is not consistent the endpoint definition because it includes DID methods and registries - neither are in endpoints. 2) The term "co-protocol" is used for L2-L3 interface without prior definition - also in contradiction to the chosen term "trust tasks". 3) In Layer 3 - we should use "trust tasks". 4) The complicated color scheme will be very difficult to print/see in BW. It is also inconsistent with the style of other diagrams in the doc.

[neiljthomson]

Based on discussions in past weeks, this architecture, with intermediary systems, support systems, ToIP common systems, and external systems (Transport) does NOT fit in the current four-layer diagram.

See the attached as a crude tech arch overview diagram (3D)

[talltree]

I definitely see @wenjing's points about the Google doc version of the diagram. However that version also has a lot of explanatory power (I have used it with several audiences to great success).

I also see the clarity that @neiljthomson is seeking with his suggested diagram. However I don't find his version as easy to digest as the original.

Since this diagram is clearly very important to a number of us, this strikes me as a good example of where we need to assign it out to a special subgroup to come up with a proposed resolution.

Proposed labels: priority-1 needs-special-group

[neiljthomson]

Agree on handing over to a subgroup to hash out a collection of "useful" diagrams that are all views of the same underlying (possibly complex) model.

From concept to implementation, all Architectures become complex - ALL the relationships. I would suggest that attempting to find a single diagram that is both useful for discussion in one or more contexts and is simple is not achievable.

The ToiP Arch is an elephant, for which a (complex, as in my proposal) diagram is the anchor/reference diagram, but that other useful (simpler) views of that architecture are used in most circumstances- tailored for the audience and level of detail required to discuss a given topic.

Paraphrasing - "all models are wrong, but many are useful"

[andorsk]

A link would be useful, current reference: https://github.com/trustoverip/TechArch/blob/main/spec.md#62-the-four-layer-pattern

[andorsk]

Before:

After:

[jospencer-460]

Happy to get into the distinction here - Trust Support concepts/services defined by ToIP (Layer 1) and those that are external to ToIP and provide supporting services

[RieksJ]

Perhaps we should think about have different kinds of pictures for different kinds of audiences. At a higher level (not much details needed), it's ok to have pictures as shown in previous posts of this issue.

Grinding out details might require another way of representing stuff. It's a bit like designing terminology in the way advocated by the CTWG, except that it isn't terms and definitions, but rather images and definitions. Architects could use ArchiMate for that (there's at least one opensource tool). Note that since conceptually such tools are no different from powerpoint and such, the semantics of the various symbols should not be taken for granted, but curated (perhaps as carefully as terms in a terminology).

[darrellodonnell]

@RieksJ I fully agree that we will have many pictures for different audiences. We, as a community, seem to look for the "one picture to rule them all" but that's an impossible goal. Your earlier ISO architecture comments (different thread) are a perfect proof - it provides multiple viewpoints as it should. The same applies to TOGAF, DODAF, and many other architecture frameworks.

To me we need many diagrams. At a minimum, or perhaps as a starting point (i.e. this can certainly change):

• the overarching bigger picture - my early attempts provide a reasonably good 4-layer view that provides the bigger picture.
• the more detailed - @neiljthomson provides a "here is what two endpoints look like" starting point.
• the very specific views required for things like:
  • how does this work comms-wise? storage-wise? crypto-wise?
• more.

[darrellodonnell]

@andorsk the diagram change you noted is where the discussions went a bit sideways a month or two ago. I think my prior comment (to Rieks) may help in documenting the "why" we made decisions on an APAC call that helped clarify where we hat ToIP Layers and where we don't. @jospencer-460 will do a better job of explaining this, but I'll attempt it here.

The "below Layer 1" stuff are things that are very important, but from a ToIP perspective, we don't have strong opinions, nor particular guidance on what they are and how they do what they do. I'll pick a few examples:

• Communication transport is critical for any DIDComm activities where we are exchanging information, but we aren't defining what is required there. We may need to be aware of some key aspects about different types of transport protocols (e.g. very low bandwidth and other limitations) but we don't define these protocols.
• Cryptography - the various cipher suites, etc. that are used are important but are developed and evolve separately from the ToIP-influenced layers. At Layer 1 we may be very opinionated about the use (and rejection) of some cipher suites but we don't control the cryptography itself.
• Storage - we use it for various purposes up and down the ToIP 4-Layer stack but we don't particularly care beyond non-functional requirements but not in a ToIP-specific way.

We can point elsewhere for these requirements. Various standards groups define all of the above.

[allant0]

Another reason why the diagram tried to convey compute, storage & transport outside of the layering was that those 3 concepts/functions exist at all layers in some form and therefore to show them as layer 1 implies that for a higher layer to use compute, storage or transport it has to go through the lower layers to get to them. Thats not how it works. One suggestion was that these support/components be shown to the right hand side of the diagram instead of at the bottom to show they supported all layers but that was rejected during discussions. Fundamentally showing something at the bottom of a layered architecture implies (not strictly) that upper layers don't directly use the bottom layer itself without intervening layers. This is the problem we have been discussing. The solution proposed in the "before" diagram was acceptable to some but not all.

[talltree]

I agree with @allant0 's analysis of why both versions of this diagram (see above) have been problematic.

In trying to figure out a solution that we can all agree to, I went back to review exactly what we say in the spec about the requirements for Layer 1. The only actual requirement is in section 7.2:

7.2 Layer 1: Trust Support If a ToIP Endpoint System includes Trust Support Functions, then those functions MUST be included at Layer 1 of the Endpoint System. [REQ L1.1]

I recommend reading the rest of section 7.2 that discusses the different considerations and potential implementations of Layer 1 depending on the nature of the Endpoint System. For example:

The exact nature of the Trust Support Functions required by any particular Endpoint System may vary significantly depending on the Endpoint System’s physical manifestation and numerous other design goals (e.g. cost, location, convenience, power usage, reliability and so on). For example the Trust Support Functions required for a full-featured smartphone vs. a cloud server vs. an IoT thermostat may be very different.

This gets to the heart of why the diagram has been so controversial: the Trust Support Functions required at Layer 1 can vary tremendously depending on the type of Endpoint System being implemented.

Finally, in section 8.5 where we talk about the interface between Layer 2 and Layer 1, we say:

8.5 Interface to Layer 1 Given these requirements for the ToIP Trust Spanning Protocol at Layer 2, the Trust Support Function interfaces at Layer 1 should only need to include the following. Note that Layer 3 Trust Tasks or Layer 4 Trust Applications may also need to call these interfaces directly.

1. Key Management System (KMS) is the interface for generating cryptographic quality keys, random numbers, or other values required by the cryptographic primitives used by the protocol.
2. Secure storage is the interface through which Layer 2 can create, read, write, and delete confidential or secret data.
3. Transport consists of one primitive via which the sender’s Layer 2 implementation can submit a message for transmission and another primitive through which the receiver’s Layer 1 implementation can deliver a message up to Layer 2.
4. User binding is the interface via which a Layer 2 implementation can request and verify a biometric or other authentication information from a user.

This list suggests the following solution to me: what if Layer 1 includes the following four boxes:

[RieksJ]

I haven't followed this discussion, but it seems as if we are looking at an elephant from different perspectives (viewpoints in architecture speak). Figures serve a particular purpose, and different figures do not necessarily merge well. Rather than trying to cram square holes in round pegs (which is just another perspective on an English saying), it might help to

1. state a (clean) purpose that you're after in a chapter/section/subsection - i.e.: define its scope
2. only use texts and figures within that scope that somehow serve this purpose.
3. don't try to 'help' your readers by adding all kinds of things that make the reader's attention go away from the main purpose.

[darrellodonnell]

1. Key Management System (KMS) is the interface for generating cryptographic quality keys, random numbers, or other values required by the cryptographic primitives used by the protocol.
2. Secure storage is the interface through which Layer 2 can create, read, write, and delete confidential or secret data.
3. Transport consists of one primitive via which the sender’s Layer 2 implementation can submit a message for transmission and another primitive through which the receiver’s Layer 1 implementation can deliver a message up to Layer 2.
4. User binding is the interface via which a Layer 2 implementation can request and verify a biometric or other authentication information from a user.

This list suggests the following solution to me: what if Layer 1 includes the following four boxes:

This is fine with me. A key point then is that transport, when drawn to link endpoint systems, needs to be below the diagram not just horizontal. This is very nitpicky but going horizontal implies that the ToIP Layer 1 controls the transport, but it doesn't - it uses it.

[jospencer-460]

The current update (shown at the TATF APAC meeting of 20-10-2022) looks like to puts the "utility services" half-in and half-out of the layer 1 horizontal. That's ok by me, because there are some "aspects" of these services that fit within the ToIP "scope of influence" and some that don't. For example, DIDDocs definitions are "in", the DIDDoc storage solution won't be (i.e. "out").

I do suggest that we use the term "services" rather than "interfaces". There will be interfaces, but also more than interfaces. So we should use the definitions "trusted computing services", "secure storage services", "network transport services". "user binding services".

Every time we discuss Figure 4, I have a different "revelation"!

When looking at the Governance side of the stack, in a piece of work we're doing for a client, were very interested to see the "extension" concept - most helpfully defined in here) (section 6.12). In this (technical) context, the relationship between ToIP-aligned, governed ecosystems and other ecosystems occurs at layer one in the use of services outside of the ToIP "scope of influence". That's why, we can't put everything inside the ToIP scope of influence (and governance framework) but we need extensions to other technical stacks/solutions that become technical "extensions" (or solution dependencies). These extension points of the TA have to have agreed service levels and definitions to ensure that the selected dependent services are appropriate to the solution and the dependencies are clear.

So, to be clear... The "extensions" concept in the ToIP governance framework has a technical equivalence that we might articulate. This would be an technical external dependency (a service, I'd suggest) that is not under ToIP scope of influence. These "extensions" can be external services at any of the layers.

When I get a chance, I'll create an simple update to the "current" figure 4 to illustrate this.

[jospencer-460]

I had a crack at the picture here

[talltree]

@jospencer-460 I very much like the distinction you are drawing and how your diagram illustrates it. Given the wonderful cut-and-paste graphics function of GitHub issues, I'm putting a screen shot of you diagram here to encourage review and discussion by others:

[talltree]

More perspective on "the diagram currently known as Figure 4" (I describe it thus because in yesterday's TATF meeting, we agreed that this diagram might be best moved to a new section at the end of the spec where we discuss how all the requirements described in the spec add up to a few "big pictures").

This version of the diagram is another tweak to the version discussed in yesterday's APAC call. It incorporates feedback from @SmithSamuelM that we should break out verifiable data registries and other verifiable data services into its own box at Layer 1 and not lump them in with "secure storage". This also gives us a clear place to put the DID registries that have long figured prominently in our conceptual diagrams of the ToIP stack.

Note that this diagram and @jospencer-460 's diagram above actually fit together nicely. If we put them in a section at the end called something like, "Consolidated Views of the ToIP Stack", I would show this diagram to present a "big picture" followed by Jo's diagram that makes it clear what is and is not in scope for ToIP architecture.

[jospencer-460]

Some questions raised by @wenjing previously, should be adressed... Question 1 - is a Trust Registry an endpoint? Question 2 - is a DIDdoc a Utility Service? Question 3 - is a protocol a Utility Service, and when is it inside ToIP's influence? Question 4 - co-protocols was being used as a term previously. Has this now dropped off?

From a review of my picture Question 4 - we've seen the introduction of User Binding Interfaces and Services - is that at Layer 1 or Layer 3? Maybe both... (local biometric call-out service v external identity re-verification solution)?

[allant0]

I have a proposed diagram (I thought I took the action item to come back with a proposed diagram) but would prefer to share in the meeting to get feedback on whether it makes sense to use it.

[talltree]

In the 2022-10-27 TATF meeting, I took the action item to propose a new section in the spec with a "storyline" to explain all three of the ToIP architecture views that have been proposed in this thread (I loosely call them "Darrell's view", "Jo's view", and "Allan's view").

After studying the structure of the spec, and given that this is non-normative content, I propose that we add this section as Appendix B: Consolidated Views of ToIP Architecture. The current Appendix B would become Appendix C.

I have started a new Google doc in the ToIP/TSWG/TATF Google Drive with a brief intro and basic outline of this proposed Appendix B to review on the 2022-11-03 TATF calls.

If you are not able to attend one of those calls (or even if you are), feel free to share any feedback here. I will post again when a complete draft of the Google doc is ready.

[talltree]

Closed this issue as it was addressed by PR #70. Future revisions to Appendix B should be addressed by a new issue that references this one.