Disclaimer: The content herein represents preliminary brainstorming.
What is a TIP?
A ToIP Interoperability Profile (TIP) represents a specific combination of technologies that span each layer of the ToIP Technical Stack. TIPs can be designed, refined and supported by interoperable vendors. A TIP will often be applicable to specific design principles and use cases.
As we seek solutions for an interoperable digital trust marketplace, we must recognize that market dynamics will often drive solution incubation and adoption. Keeping with the cooking analogy, ingredients are to recipes as technology components are to solution architectures.
For example, we can imagine a TIP associated with the use of Hyperledger Indy and Hyperledger Aries at layers 1-3. But a TIP is more than the association of technology to layers of the technical stack; a TIP must address other market dynamics:
- Core Principles: Market requirements are necessary when combining technology to formulate a solution architecture.
- White-paper: Documentation outlining purpose, principles and architecture for the TIP.
- Adoption Metrics: Use case correlation backed by case study references demonstrate adoption.
- Interoperability Testing: Community driven certification of test cases and results.
- Vendor Support: Vertical integration of the technical stack must be supported by vendors that can demonstrate the interoperability between vendor solutions that adhere to a common vertical architecture.
- Best Practices: Implementation guidance for adoption as well as recommendations for interlock with the Governance Stack.
A TIP represents a descriptive solution outline that once matured can be considered a market proven solution specification.
Why do we need TIPs?
Ultimately, entities (business, governments, organizations) that seek to participate in an interoperable digital trust marketplace will need to assess (compare) solution architectures. Analogous to a Request for Proposal (RFP) process, entities should be able to align their requirements with the principles and expectations described by a TIP and use such a comparison exercise to make educated decisions. Allow when to compare apples-to-apples and when necessary enable clear articulation of apples-to-oranges activities.
Who would use a TIP?
As Ecosystem Projects (See Ecosystem Foundry WG) evolve they will need to define governance frameworks and select a TIP.
What is the scope of interoperability for a TIP?
In a utopian world solution architectures would be interoperable both vertically and horizontally across the Technology Stack. But this is not the goal of ToIP and in fact at some layers of the technology Stack, horizontal interoperability is not even necessary.
For clarity, TIPs needs to first focus on vertical interoperability where the connecting of the technology components at each layer is seamless and well understood. Horizontal interoperability across TIPs is not important until we have 2 or more TIPs with enough market adoption to necessitate community energy.
While horizontal interoperability at layer 3 (a wallet affiliated with TIP-A can exchange data with a wallet that supports TIP-B and both TIPs use different Layer 3 tech) would be important, the ability of a Layer 1 Utility based of on technology-A needing to exchange data with a Utility based on technology-B is less important.
Tech Stack WG Responsibilities
The Technical Stack WG is responsible for the processes and procedures of the WG as well as the lifecycle of TIP incubation.
- Stack Attributes: One of the deliverables of the Tech Stack WG (TSWG) is to provide guidance on the type of technology that can (could) be considered applicable at each layer of the Technology Stack. Additionally, what the architectural requirements are for vertical interoperability between the layers. This work effort MUST be technology neutral.
- TIP Criteria: What are the requirements for proposing a TIP to the WG?
- TIP Incubation: Establishment and Management of the TIP Lifecycle Process
- TIP Graduation: Review and approval process for the formalization of a TIP into a recommendation (TSS?)
TIP Lifecycle
The ToIP Foundation, which is technology agnostic, represents a collaborative forum where solution “recipes” can be matured and vetted in the market.
- Proposed: Using a predefined template, propose a TIP to the TSWG to get the approval to establish a ToIP TIP repo.
- Demonstrated: incubate the TIP within the community to address the maturation criteria outlined by the TSWG.
- Accepted: The TSWG believes a TIP has is worthing of a recommendation as a specification and the community has decided formalize it as a recommendation.
- Adopted: The TIP has graduated to a formal recommendation.
- Retired: The proposers of the TIP have determined that the maturation process has failed or permanently stalled.
Note: These lifecycle stages are derived from the Hyperledger Aries RFCs Process.
TEMPORARY CONTENT:
2 min | Review of action items from the previous meeting | Chairs |
|
5 min | Reminder of IPR Mode Transition & Call for Exclusions | Chairs | As announced by Judith Fleenor on 25 August 2023 in an email to all members, the TSWG is transitioning from its current IPR mode (Creative Commons Attribution 4.0 for copyright, W3C Mode for patents, Apache 2.0 for source code) to a new IPR mode (Open Web Foundation 1.0 for copyright and patent, Apache 2.0 for source code). On 23 August 2023, the ToIP Steering Committee passed a resolution approving this rechartering that directed the Executive Director and the TSWG Co-Chairs to take the following steps to carry out this resolution:
Any TSWG member who wishes to declare any patent claim exclusions on work contributed to existing TSWG deliverables must do so by midnight Pacific Time on 25 October 2023. |
5 min | Nomination of new TSWG Co-Chair | Chairs | Kevin Griffin has volunteered to join Darrell O'Donnell and Drummond Reed as a third co-chair of the TSWG. DECISION: Kevin Griffin ______ as co-chair of the Technology Stack Working Group. |
3 Comments
Scott Whitmire
If a TIP is basically the architecture for a solution, we should look to successful solution architecture descriptions to see what is required. In my experience, describing components in terms of external behaviors and interfaces is sufficient. External behaviors include events to which the component needs to respond, the pre-conditions under which a response is appropriate, the post-conditions that exist after a successful response, and any limitations. The interfaces are specified in great detail, including data format, timing, and protocol. The best example of this form of description is the 3GPP specs for GSM and LTE (and presumably 5G) mobile phone specs. The idea is that anyone who makes a component that meets the external behaviors (which can be implemented as a test suite) can participate in any solution that makes use of the respective component. It works very well based on my experience in the mobile phone industry.
Dave Bryson
How detailed should a TIP be for a given layer? For example, Layer 1 will in many cases be based on some form of DLT (e.g. a blockchain), which is already murky water for many. But, the details of that layer (IMO) are important to help user's evaluate their requirements against a given implementation. For example, should a given DID method registry TIP specify:
I can see the potential for a deep rabbit hole here. What's the right balance?
Drummond Reed
Dave Bryson Ironically, part of the whole rationale of the ToIP stack is that the higher layers should NOT need to care about the implementation details of a lower layer beyond a single consideration: can it be sufficiently trusted to support the requirements of the higher layer.
Of course the details of an implementation at the lower layer can all be factors in that trust decision. But the beauty of the TIP strategy is that any implementation that does not meet the business requirements of a majority of the a governance frameworks at a higher layer will quickly die off. Only those that do meet those requirements will survive. Classic Darwinian survival-of-the-fittest.
I believe this is true in spades for ToIP Layer One utilities. The only ones that will have a serious chance in the marketplace will have spent several years solving the problems you list (consensus algorithm, economic model, governance model, support for higher layer requirements like revocation, etc.)
I believe the same will apply to ToIP Layer Two wallets, agents, and agencies.
So as those emerge, layer 3 and 4 governance authorities will need to spend less and less time and effort worrying about the trustworthiness of layer 1 utilities and layer 2 wallets/agents/agencies and spend more effort on establishing trust at the human layers (verifiable credentials and digital trust ecosystems).