Trust Over IP for a year try to solve the challenge of missed identity layers in internet. So lets take a look to a proposed trust architecture of future web together
It is corner stone architecture part of modern trust systems THE TOIP TRUST SPANNING PROTOCOL Lets go over review a major parts together
Types Of Systems
it is a paper that revisits and defines a structure of Trust over IP stack and layered protocols
Let’s take critical notes from a paper. I used some of the diagrams from the article itself.
Trust over IP defines the following types of systems
- Endpoint System — autonomous system with boundaries of concrete locus of control. Service, user-centric mobile app, institutions, etc. 2. Intermediary Systems — similar idea to Hyperladger mediators and relays help to facilitate and route messages via trust-spanning protocol
- Supporting Systems — utility systems for trust-specific needs like — key management,
transport, and secure storage. DID method implementation go to this bucket
The Layers
© Trust over IP founndation
Layer 4: Trust Applications
So concrete applications that will use a Layer 3 Trust task protocol and Layer 2 Spanning protocol enable to build of business logic and new services like payment, data economy exchangers, KYC stems, and new DeSoc and DeFi systems.
Layer 3: Trust Tasks
Families of Protocols that connect Endpoint Systems and players of Endpoint Systems.
- Credential and verifiable data exchange protocols
- payments protocol
- Data streaming protocols
- Asset exchange protocols
Layer 2: Trust Spanning
This is the main subject of our talk. An hourglass neck and a key part give a fundamental building block.
In a paper, ToIP defines an essential requirement. A significant part of a requirement is focused on Autonomic decentralized identifiers and a secured message exchange on top of identifiers. We have yet to have one concrete implementation or standard that satisfies all needs, but ToIP selects a few candidates.
- DIDcomm v2 — cover secure messaging in a pers to per way on top of DIDs https://identity.foundation/didcomm-messaging/spec/. You can read more in a short book https://didcomm.org/book/v2/
- KERI — Key Event Receipt Infrastructure and KERI-related infrastructure like ACDC https://wiki.trustoverip.org/display/HOME/ACDC+%28Authentic+Chained+Data+Container%29+Task+Force. Define key management needed for secure communication between DIDs
- DWN — Decentralized Web Node. https://identity.foundation/decentralized-web-node/spec/ Now part of Secure data storage group https://identity.foundation/working-groups/secure-data-storage.html. It is a combination of messaging between DIDs with a combination of storage on top of IPLD https://github.com/ipld/ipld and a permission layer.
I am disappointed that DWN ignored a DIDComm and built its own messaging. It is still unclear to me.
Layer 1: Trust Support.
Correlate with support systems set of network tools. secure storage and cryptographic tooling.
More detailed explanation