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. 

  1. 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. 
  2. TIP Criteria: What are the requirements for proposing a TIP to the WG? 
  3. TIP Incubation: Establishment and Management of the TIP Lifecycle Process
  4. 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. 

  1. Proposed: Using a predefined template, propose a TIP to the TSWG to get the approval to establish a ToIP TIP repo. 
  2. Demonstrated: incubate the TIP within the community to address the maturation criteria outlined by the TSWG.
  3. 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.
  4. Adopted: The TIP has graduated to a formal recommendation. 
  5. 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 minReview of action items from the previous meetingChairs
  • ACTION: Drummond Reed will: a) send an email to the TSWG mailing list proposing to move our TSWG Plenary meeting to every fourth Tuesday with two meeting slots: NA/EU at 08:00-09:00 PT / 15:00-16:00 UTC, and APAC at 18:00-19:00 PT / 02:00-03:00 UTC, b) coordinate with W3C VC WG co-chair Brent Zundel to schedule those meetings so they don't conflict with W3C VC WG special meetings that happen at that same time every two weeks.
  • ACTION: Drummond Reed will contact the proposers of the DID WebS Method Task Force to clarify the licensing listed in the charter.
  • ACTION: Drummond Reed to send an email to the TSWG mailing list notifying all TSWG members of a 7 day review period for the proposed DID WebS Method Task Force, followed by a 7 day email vote seeing if there are any objections.
5 minReminder of IPR Mode Transition & Call for ExclusionsChairs

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:

  1. Send an announcement to the TSWG mailing list and the ToIP All-Members mailing list of a revision to the TSWG charter together with a 60 day notice of a Call for Exclusions for all current TSWG deliverables as specified in the W3C Patent Policy.
  2. At the end of the 60 day period, send an announcement to the same mailing lists of an official closure of the current TSWG, terminating all work on deliverables under the current IPR terms.
  3. On the 61st day, send an announcement to the same mailing lists of the official opening of a new TSWG operating under the new IPR terms.
  4. The TSWG shall then officially accept any previous deliverable that will continue under the new Working Group.

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 minNomination of new TSWG Co-ChairChairs

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.







  • No labels

3 Comments

  1. 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.

  2. 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:

    • The type of consensus algorithm used (if any...)
    • If a blockchain, whether it requires a cryptocurrency/token (as this seems to be the dominant model for many)
    • The level of trust expected among stakeholders (public/private)
    • Does it handle revocation
    • etc...

    I can see the potential for a deep rabbit hole here. What's the right balance?

    1. 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).