TOIP Trust Spanning Layer Framework: Web 7.0 DID Communications/HTTP (DIDComm-ARM/HTTP) Profile (Example)

[mwherman2000]

IMO, every TOIP TAS-compliant platform can define its own TOIP Trust Spanning Framework Profile.

NOTE: There is actually no need to standardize each platform (i.e. document it on the TOIP website). It's up to each individual platform release to demonstrate that it is TOIP TAS compliant. This is powerful.

Below is a copy of Web 7.0 DID Communications/HTTP (DIDComm-ARM/HTTP) TOIP Trust Spanning Framework Profile...

NOTE: The (Li) annotations refer to the specific source layer in the 7-Layer Web 7.0 DIDComm-ARM model.

Hopefully, no further narrative is required.

CC: @dhh1128

[dhh1128]

Allowing multiple profiles that all exhibit the same hourglass shape is absolutely possible, and has even been worked on to some extent. I believe the different components of layer 1, along with the stuff at layers 2 and 3 that tend to fit well with that, have been called a "profile" in ToIP circles. So I'm not hostile to the idea.

However, I'm also not super energized by the idea, because a proliferation of profiles doesn't add adoption/interop all that much. Each profile has certain things in common, as an abstraction, but doesn't necessarily have the ability to talk to other profiles. The profiles become silos.

That's not a disaster; maybe one silo becomes dominant and others fade away. But I just don't have energy to push for the profiles concept. I want to work on the one profile that I like the best (which is pretty similar to the example you provided).

[mwherman2000]

@dhh1128 like your reply right up to... :-)

proliferation of profiles doesn't add adoption/interop all that much

Please don't conflate adoption with interop. They are related but in a very orthogonal way.

For example, having multiple profiles actually encourages more innovation and hence, more adoption. It gives systems designers more options and hence increases adoption.

Interoperability only becomes a factor once we have adoption and deployment of multiple platforms, systems, and applications. Until there is 3-4 significant applications out there that need to interoperate, focusing on interop now IMO is a waste of time and resources.

In addition, until several proven (implemented) profiles exist, no one can predict what the most effective common denominator will be. ...let the stew simmer for a while before singling out a particular protein or vegetable to make your stew from.

[mwherman2000]

NOTE: The 2-party Raw Credential Sender-Receiver Model (see https://github.com/trustoverip/TechArch/issues/84) is generic enough to be included in Layer 2. See the diagrams below as well as at the top of this issue.

[mwherman2000]

Updated Web 7.0 DID Communications/HTTP (DIDComm-ARM/HTTP) TOIP Trust Spanning Framework Profile (the diagram at the top of the issue) to include artifacts from all 7 layers of the Web 7.0 DIDComm-ARM: https://hyperonomy.com/2022/12/12/welcome-to-web-7-0/

Updated "the 100 slides" to include the 7 layers of the Web 7.0 DIDComm-ARM (slides 96-113): https://docs.google.com/presentation/d/14YPhH66yfOetrSfuycuFOgQqxzGZ0b7H22EZDhilphU/edit#slide=id.g1447f0ca66d_0_0

[darrellodonnell]

The 2-party Credential Sender-Receiver Model (see #84) is generic enough to be included in Layer 2.

In my world all of the credential activity is fully in Layer 3. Layer 2 is much narrower - creating the addressing and comms pipe, with a bare minimum of protocol that Layer 3 requires (commonly) to build upon.

[mwherman2000]

If we're going to be serious about this, we also have to include and specify all of the different transports that DIDComm Communications can possibly run on. There isn't just HTTP (REST/HTTP). I've changed the title of this issue and the diagram at the top of this issue to reflect this.

This is further evidence of why it is futile (in the real world) to try to standardize a particular profile. The goal of the TAS specification should be to standardize the criteria/requirements for what defines a TOIP TAS-compliant profile ...and let developers/vendors create their own TOIP TAS-compliant implementations.

Here's the full Web 7.0 Layer 6 Web 7.0 DIDComm Agent Model from the Web 7.0 DIDComm-ARM (https://hyperonomy.com/2022/12/18/web-7-0-didcomm-agent-architecture-reference-model-didcomm-arm-0-40-december-18-2022/)...

The green box presents a detailed view of Web 7.0 DIDComm Network running over HTTP: Web 7.0 DIDComm Network Router Agents, etc.

The blue box is a sampling of all of the other potential transports that can support a Web 7.0 DIDComm Network ...just a sampling. Each one of these needs its own TOIP TAS-compliant profile documented.

Is TOIP going to undertake the documenting/specification of each one of these? I don't think so.

[mwherman2000]

In my world all of the credential activity is fully in Layer 3. Layer 2 is much narrower - creating the addressing and comms pipe, with a bare minimum of protocol that Layer 3 requires (commonly) to build upon.

@darrellodonnell This is exactly what the Raw Credential Sender-Receiver Model is all about ...the simple sending by a Sender and receiving by a Receiver of a credential ...any credential. This is Layer 2.

[darrellodonnell]

and when I don't want a credential? (e.g. voice)

[mwherman2000]

and when I don't want a credential? (e.g. voice)

Depends on your definition of a credential. In Web7.0, a credential is a collection of properties/attributes - i.e. a collection of name-value pairs.

[dhh1128]

In Web7.0, a credential is a collection of properties/attributes - i.e. a collection of name-value pairs.

If that is your definition, then I feel like you are correct to place it at layer 2. However, I suggest that the word "credential" is a bad one to use for your definition. A credential is fundamentally evidence of entitlement (to status, to access). Your more generic concept is closer to what Sam Smith has been calling "verifiable data." It subsumes the specific type of verifiable data that is about evidence of entitlement, but it is quite a bit broader. That might be a good thing for the concept, insofar as it fits into a larger vision, but I suggest that it's a bad thing for the word "credential" -- it will create confusion.

[mwherman2000]

I believe it is best to characterize the TOIP 4-Layers as an architectural framework and not as an architectural model.

From the perspective of a software architect or developer and using the Web 7.0 DIDComm/HTTP Hourglass Profile as a working example, the 4 layers of the TOIP 4-Layer diagram aren't granular enough to be used as an architectural model/architectural reference model. It's a framework.

However, compliant architectural models like the Web 7.0 DIDComm-ARM can be mapped onto the TOIP 4-Layer architectural framework as illustrated at the top of this issue via the Web 7.0 DIDComm/HTTP Hourglass Profile (as an example).

[mwherman2000]

Your more generic concept is closer to what Sam Smith has been calling "verifiable data."

A (Raw) Credential is just a collection of properties/attributes... nothing more...a serialization of a collection of name-value pairs. ...with no implication that it is verifiable ...so Sam's term Verifiable Data is not synonymous with a Credential.

[darrellodonnell]

and a data stream?

[mwherman2000]

and a data stream?

?? (stream is loaded word ... aka streaming) data stream implies a stream or sequence or series of data (stream of datums/credentials).

[mwherman2000]

I believe it is best to characterize the TOIP 4-Layers as an architectural framework and not as an architectural model.

From the perspective of a software architect or developer and using the Web 7.0 DIDComm/HTTP Trusted Spanning Layer Framework Profile as a working example, the 4 layers of the TOIP 4-Layer diagram aren't granular enough to be used as an architectural model/architectural reference model. It's a framework.

However, compliant architectural models like the Web 7.0 DIDComm-ARM can be mapped onto the TOIP 4-Layer architectural framework as illustrated at the top of this issue via the Web 7.0 DIDComm/HTTP Trusted Spanning Layer Framework Profile (as an example).

Here's a recording where I describe the mapping of the Web 7.0 DIDComm-ARM to the TOIP Trusted Spanning Layer Framework Profile Mapping Web 7.0 DIDComm/HTTP Architecture Reference Model (DIDComm-ARM/HTTP) to TOIP Trusted Spanning Layer Framework (https://www.youtube.com/watch?v=o0GjoDTfxZw&list=PLU-rWqHm5p44AsU5GLsc1bHC7P8zolAAf&index=3).

@dhh1128

[mwherman2000]

Re: Raw Credential Sender-Receiver Model

In Web 7.0, the following are equivalent:

• Raw Credential
• Collection of Properties where one property is an identifier
• Collection of Attributes where one attribute is an identifier
• Collection of Name-Value Pairs where one pair is an identifier
• Collection of Claims where where one claim is an identifier
• Collection of Assertions where one assertion is an identifier

UPDATE: None of these are verifable unless, separately, there a verifiable proof associated with the Raw Credential (or it's Collection-based definitions).

Cc: @dhh1128

[mwherman2000]

I created a new tutorial that summarizes the latest information from issues https://github.com/trustoverip/TechArch/issues/83 and https://github.com/trustoverip/TechArch/issues/84.
If you have been following either thread, there is also some new data and graphics. Check out Web 7.0 Trust Spanning Layer Framework 0.57 (https://www.youtube.com/watch?v=rrFfuUHHmr4) NOTE: It may be a few hours before YouTube has finished post-processing the video.

With this note, I'm closing both of the issues: https://github.com/trustoverip/TechArch/issues/83 and https://github.com/trustoverip/TechArch/issues/84.