├── .gitignore ├── CODE_OF_CONDUCT.md ├── GOVERNANCE.md ├── LICENSE ├── Moderation_Policy.md ├── README.md ├── TIP_GETTING_STARTED.md ├── TIP_LIFECYCLE_MANAGEMENT.md ├── TIP_LIST.md ├── _images └── tip-gap-legos.png ├── _proposals └── saturn-v-tip.md └── _templates └── tip_proposal.md /.gitignore: -------------------------------------------------------------------------------- 1 | .DS_Store 2 | -------------------------------------------------------------------------------- /CODE_OF_CONDUCT.md: -------------------------------------------------------------------------------- 1 | # Code of Conduct 2 | 3 | The membership of the [ToIP Foundation](http://trustoverip.org) pledge to act and interact in ways that contribute to an open, welcoming, diverse, inclusive, and healthy community. 4 | 5 | The Technical Stack Working Group ("TSWG") is committed to upholding the [ToIP Code of Conduct](https://lfprojects.org/policies/code-of-conduct/) and contributors agree to act according to a standard set of behaviors that contribute to a positive environment. 6 | -------------------------------------------------------------------------------- /GOVERNANCE.md: -------------------------------------------------------------------------------- 1 | ## Technical Stack Working Group ("TSWG") 2 | 3 | >THIS DOCUMENT HAS YET TO BE REVIEWED 4 | 5 | The ToIP TSWG is jointly governed by the ToIP Steering Committee ("SC") which is responsible for high-level guidance of the project. 6 | 7 | The SC has final authority over this project including: 8 | 9 | * Technical direction 10 | * Project governance and process (including this policy) 11 | * Contribution policy 12 | * GitHub repository hosting 13 | * Conduct guidelines 14 | * Maintaining the list of additional Collaborators 15 | 16 | ### Mission and Scope 17 | The scope of the TSWG is to define (directly or by reference) the technical standards, test suites, and interoperability certification standards for the Trust over IP architecture stack as defined in Hyperledger Aries RFC 0289 (or its successor as identified in the RFC document itself). 18 | 19 | ### WG Administration 20 | Please refer to the [WG Wiki](https://wiki.trustoverip.org/display/HOME/Technical+Stack+Working+Group) for adminstrative details. 21 | 22 | ### Collaborators 23 | 24 | The *technical-stack-wg* GitHub repository is 25 | maintained by the TSWG and additional Collaborators who are added by the 26 | WG on an ongoing basis. 27 | 28 | Individuals making significant and valuable contributions are made 29 | Collaborators and given commit-access to the project. These 30 | individuals are identified by the WG and their addition as 31 | Collaborators is discussed during the weekly WG meeting. 32 | 33 | _Note:_ If you make a significant contribution and are not considered 34 | for commit-access log an issue or contact a WG member directly and it 35 | will be brought up in the next WG meeting. 36 | 37 | Modifications of the contents of the *technical-stack-wg* repository are made on 38 | a collaborative basis. Anybody with a GitHub account may propose a 39 | modification via pull request and it will be considered by the project 40 | Collaborators. All pull requests must be reviewed and accepted by a 41 | Collaborator with sufficient expertise who is able to take full 42 | responsibility for the change. In the case of pull requests proposed 43 | by an existing Collaborator, an additional Collaborator is required 44 | for sign-off. Consensus should be sought if additional Collaborators 45 | participate and there is disagreement around a particular 46 | modification. See _Consensus Seeking Process_ below for further detail 47 | on the consensus model used for governance. 48 | 49 | Collaborators may opt to elevate significant or controversial 50 | modifications, or modifications that have not found consensus to the 51 | WG for discussion by assigning the ***WG-agenda*** tag to a pull 52 | request or issue. The WG should serve as the final arbiter where 53 | required. 54 | 55 | For the current list of Collaborators, see the project 56 | [README.md](./README.md#current-project-team-members). 57 | 58 | ### WG Membership 59 | 60 | WG seats are not time-limited. There is no fixed size of the WG. 61 | However, the expected target is between 6 and 12, to ensure adequate 62 | coverage of important areas of expertise, balanced with the ability to 63 | make decisions efficiently. 64 | 65 | There is no specific set of requirements or qualifications for WG 66 | membership beyond these rules. 67 | 68 | The WG may add additional members to the WG by unanimous consensus. 69 | 70 | A WG member may be removed from the WG by voluntary resignation, or by 71 | unanimous consensus of all other WG members. 72 | 73 | Changes to WG membership should be posted in the agenda, and may be 74 | suggested as any other agenda item (see "WG Meetings" below). 75 | 76 | If an addition or removal is proposed during a meeting, and the full 77 | WG is not in attendance to participate, then the addition or removal 78 | is added to the agenda for the subsequent meeting. This is to ensure 79 | that all members are given the opportunity to participate in all 80 | membership decisions. If a WG member is unable to attend a meeting 81 | where a planned membership decision is being made, then their consent 82 | is assumed. 83 | 84 | No more than 1/3 of the WG members may be affiliated with the same 85 | employer. If removal or resignation of a WG member, or a change of 86 | employment by a WG member, creates a situation where more than 1/3 of 87 | the WG membership shares an employer, then the situation must be 88 | immediately remedied by the resignation or removal of one or more WG 89 | members affiliated with the over-represented employer(s). 90 | 91 | ### WG Meetings 92 | 93 | The WG meets weekly on a Google Hangout On Air. A designated moderator 94 | approved by the WG runs the meeting. Each meeting should be 95 | published to YouTube. 96 | 97 | Items are added to the WG agenda that are considered contentious or 98 | are modifications of governance, contribution policy, WG membership, 99 | or release process. 100 | 101 | The intention of the agenda is not to approve or review all patches; 102 | that should happen continuously on GitHub and be handled by the larger 103 | group of Collaborators. 104 | 105 | Any community member or contributor can ask that something be added to 106 | the next meeting's agenda by logging a GitHub Issue. Any Collaborator, 107 | WG member or the moderator can add the item to the agenda by adding 108 | the ***WG-agenda*** tag to the issue. 109 | 110 | Prior to each WG meeting the moderator will share the Agenda with 111 | members of the WG. WG members can add any items they like to the 112 | agenda at the beginning of each meeting. The moderator and the WG 113 | cannot veto or remove items. 114 | 115 | The WG may invite persons or representatives from certain projects to 116 | participate in a non-voting capacity. 117 | 118 | The moderator is responsible for summarizing the discussion of each 119 | agenda item and sends it as a pull request after the meeting. 120 | 121 | ### Consensus Seeking Process 122 | 123 | The WG follows a [Consensus Seeking][] decision-making model. 124 | 125 | When an agenda item has appeared to reach a consensus the moderator 126 | will ask "Does anyone object?" as a final call for dissent from the 127 | consensus. 128 | 129 | If an agenda item cannot reach a consensus a WG member can call for 130 | either a closing vote or a vote to table the issue to the next 131 | meeting. The call for a vote must be seconded by a majority of the WG 132 | or else the discussion will continue. Simple majority wins. 133 | 134 | Note that changes to WG membership require unanimous consensus. See 135 | "WG Membership" above. 136 | 137 | 138 | ## Developer's Certificate of Origin 1.1 139 | 140 | *Note*: The DCO is mandatory for all ToIP Foundation projects. 141 | 142 | By making a contribution to this project, I certify that: 143 | 144 | * (a) The contribution was created in whole or in part by me and I 145 | have the right to submit it under the open source license 146 | indicated in the file; or 147 | 148 | * (b) The contribution is based upon previous work that, to the best 149 | of my knowledge, is covered under an appropriate open source 150 | license and I have the right under that license to submit that 151 | work with modifications, whether created in whole or in part 152 | by me, under the same open source license (unless I am 153 | permitted to submit under a different license), as indicated 154 | in the file; or 155 | 156 | * (c) The contribution was provided directly to me by some other 157 | person who certified (a), (b) or (c) and I have not modified 158 | it. 159 | 160 | * (d) I understand and agree that this project and the contribution 161 | are public and that a record of the contribution (including all 162 | personal information I submit with it, including my sign-off) is 163 | maintained indefinitely and may be redistributed consistent with 164 | this project or the open source license(s) involved. 165 | 166 | ### Moderation Policy 167 | 168 | The [ToIP Moderation Policy](https://github.com/trustoverip/admin/blob/master/Moderation_Policy.md) applies to this WG. 169 | 170 | ### Code of Conduct 171 | 172 | The [ToIP Code of Conduct][https://github.com/trustoverip/admin/blob/master/CODE_OF_CONDUCT.md] applies to this WG. 173 | -------------------------------------------------------------------------------- /LICENSE: -------------------------------------------------------------------------------- 1 | 2 | Apache License 3 | Version 2.0, January 2004 4 | http://www.apache.org/licenses/ 5 | 6 | TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION 7 | 8 | 1. Definitions. 9 | 10 | "License" shall mean the terms and conditions for use, reproduction, 11 | and distribution as defined by Sections 1 through 9 of this document. 12 | 13 | "Licensor" shall mean the copyright owner or entity authorized by 14 | the copyright owner that is granting the License. 15 | 16 | "Legal Entity" shall mean the union of the acting entity and all 17 | other entities that control, are controlled by, or are under common 18 | control with that entity. For the purposes of this definition, 19 | "control" means (i) the power, direct or indirect, to cause the 20 | direction or management of such entity, whether by contract or 21 | otherwise, or (ii) ownership of fifty percent (50%) or more of the 22 | outstanding shares, or (iii) beneficial ownership of such entity. 23 | 24 | "You" (or "Your") shall mean an individual or Legal Entity 25 | exercising permissions granted by this License. 26 | 27 | "Source" form shall mean the preferred form for making modifications, 28 | including but not limited to software source code, documentation 29 | source, and configuration files. 30 | 31 | "Object" form shall mean any form resulting from mechanical 32 | transformation or translation of a Source form, including but 33 | not limited to compiled object code, generated documentation, 34 | and conversions to other media types. 35 | 36 | "Work" shall mean the work of authorship, whether in Source or 37 | Object form, made available under the License, as indicated by a 38 | copyright notice that is included in or attached to the work 39 | (an example is provided in the Appendix below). 40 | 41 | "Derivative Works" shall mean any work, whether in Source or Object 42 | form, that is based on (or derived from) the Work and for which the 43 | editorial revisions, annotations, elaborations, or other modifications 44 | represent, as a whole, an original work of authorship. For the purposes 45 | of this License, Derivative Works shall not include works that remain 46 | separable from, or merely link (or bind by name) to the interfaces of, 47 | the Work and Derivative Works thereof. 48 | 49 | "Contribution" shall mean any work of authorship, including 50 | the original version of the Work and any modifications or additions 51 | to that Work or Derivative Works thereof, that is intentionally 52 | submitted to Licensor for inclusion in the Work by the copyright owner 53 | or by an individual or Legal Entity authorized to submit on behalf of 54 | the copyright owner. For the purposes of this definition, "submitted" 55 | means any form of electronic, verbal, or written communication sent 56 | to the Licensor or its representatives, including but not limited to 57 | communication on electronic mailing lists, source code control systems, 58 | and issue tracking systems that are managed by, or on behalf of, the 59 | Licensor for the purpose of discussing and improving the Work, but 60 | excluding communication that is conspicuously marked or otherwise 61 | designated in writing by the copyright owner as "Not a Contribution." 62 | 63 | "Contributor" shall mean Licensor and any individual or Legal Entity 64 | on behalf of whom a Contribution has been received by Licensor and 65 | subsequently incorporated within the Work. 66 | 67 | 2. Grant of Copyright License. Subject to the terms and conditions of 68 | this License, each Contributor hereby grants to You a perpetual, 69 | worldwide, non-exclusive, no-charge, royalty-free, irrevocable 70 | copyright license to reproduce, prepare Derivative Works of, 71 | publicly display, publicly perform, sublicense, and distribute the 72 | Work and such Derivative Works in Source or Object form. 73 | 74 | 3. Grant of Patent License. Subject to the terms and conditions of 75 | this License, each Contributor hereby grants to You a perpetual, 76 | worldwide, non-exclusive, no-charge, royalty-free, irrevocable 77 | (except as stated in this section) patent license to make, have made, 78 | use, offer to sell, sell, import, and otherwise transfer the Work, 79 | where such license applies only to those patent claims licensable 80 | by such Contributor that are necessarily infringed by their 81 | Contribution(s) alone or by combination of their Contribution(s) 82 | with the Work to which such Contribution(s) was submitted. If You 83 | institute patent litigation against any entity (including a 84 | cross-claim or counterclaim in a lawsuit) alleging that the Work 85 | or a Contribution incorporated within the Work constitutes direct 86 | or contributory patent infringement, then any patent licenses 87 | granted to You under this License for that Work shall terminate 88 | as of the date such litigation is filed. 89 | 90 | 4. Redistribution. You may reproduce and distribute copies of the 91 | Work or Derivative Works thereof in any medium, with or without 92 | modifications, and in Source or Object form, provided that You 93 | meet the following conditions: 94 | 95 | (a) You must give any other recipients of the Work or 96 | Derivative Works a copy of this License; and 97 | 98 | (b) You must cause any modified files to carry prominent notices 99 | stating that You changed the files; and 100 | 101 | (c) You must retain, in the Source form of any Derivative Works 102 | that You distribute, all copyright, patent, trademark, and 103 | attribution notices from the Source form of the Work, 104 | excluding those notices that do not pertain to any part of 105 | the Derivative Works; and 106 | 107 | (d) If the Work includes a "NOTICE" text file as part of its 108 | distribution, then any Derivative Works that You distribute must 109 | include a readable copy of the attribution notices contained 110 | within such NOTICE file, excluding those notices that do not 111 | pertain to any part of the Derivative Works, in at least one 112 | of the following places: within a NOTICE text file distributed 113 | as part of the Derivative Works; within the Source form or 114 | documentation, if provided along with the Derivative Works; or, 115 | within a display generated by the Derivative Works, if and 116 | wherever such third-party notices normally appear. The contents 117 | of the NOTICE file are for informational purposes only and 118 | do not modify the License. You may add Your own attribution 119 | notices within Derivative Works that You distribute, alongside 120 | or as an addendum to the NOTICE text from the Work, provided 121 | that such additional attribution notices cannot be construed 122 | as modifying the License. 123 | 124 | You may add Your own copyright statement to Your modifications and 125 | may provide additional or different license terms and conditions 126 | for use, reproduction, or distribution of Your modifications, or 127 | for any such Derivative Works as a whole, provided Your use, 128 | reproduction, and distribution of the Work otherwise complies with 129 | the conditions stated in this License. 130 | 131 | 5. Submission of Contributions. Unless You explicitly state otherwise, 132 | any Contribution intentionally submitted for inclusion in the Work 133 | by You to the Licensor shall be under the terms and conditions of 134 | this License, without any additional terms or conditions. 135 | Notwithstanding the above, nothing herein shall supersede or modify 136 | the terms of any separate license agreement you may have executed 137 | with Licensor regarding such Contributions. 138 | 139 | 6. Trademarks. This License does not grant permission to use the trade 140 | names, trademarks, service marks, or product names of the Licensor, 141 | except as required for reasonable and customary use in describing the 142 | origin of the Work and reproducing the content of the NOTICE file. 143 | 144 | 7. Disclaimer of Warranty. Unless required by applicable law or 145 | agreed to in writing, Licensor provides the Work (and each 146 | Contributor provides its Contributions) on an "AS IS" BASIS, 147 | WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or 148 | implied, including, without limitation, any warranties or conditions 149 | of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A 150 | PARTICULAR PURPOSE. You are solely responsible for determining the 151 | appropriateness of using or redistributing the Work and assume any 152 | risks associated with Your exercise of permissions under this License. 153 | 154 | 8. Limitation of Liability. In no event and under no legal theory, 155 | whether in tort (including negligence), contract, or otherwise, 156 | unless required by applicable law (such as deliberate and grossly 157 | negligent acts) or agreed to in writing, shall any Contributor be 158 | liable to You for damages, including any direct, indirect, special, 159 | incidental, or consequential damages of any character arising as a 160 | result of this License or out of the use or inability to use the 161 | Work (including but not limited to damages for loss of goodwill, 162 | work stoppage, computer failure or malfunction, or any and all 163 | other commercial damages or losses), even if such Contributor 164 | has been advised of the possibility of such damages. 165 | 166 | 9. Accepting Warranty or Additional Liability. While redistributing 167 | the Work or Derivative Works thereof, You may choose to offer, 168 | and charge a fee for, acceptance of support, warranty, indemnity, 169 | or other liability obligations and/or rights consistent with this 170 | License. However, in accepting such obligations, You may act only 171 | on Your own behalf and on Your sole responsibility, not on behalf 172 | of any other Contributor, and only if You agree to indemnify, 173 | defend, and hold each Contributor harmless for any liability 174 | incurred by, or claims asserted against, such Contributor by reason 175 | of your accepting any such warranty or additional liability. 176 | 177 | END OF TERMS AND CONDITIONS 178 | 179 | APPENDIX: How to apply the Apache License to your work. 180 | 181 | To apply the Apache License to your work, attach the following 182 | boilerplate notice, with the fields enclosed by brackets "[]" 183 | replaced with your own identifying information. (Don't include 184 | the brackets!) The text should be enclosed in the appropriate 185 | comment syntax for the file format. We also recommend that a 186 | file or class name and description of purpose be included on the 187 | same "printed page" as the copyright notice for easier 188 | identification within third-party archives. 189 | 190 | Copyright [yyyy] [name of copyright owner] 191 | 192 | Licensed under the Apache License, Version 2.0 (the "License"); 193 | you may not use this file except in compliance with the License. 194 | You may obtain a copy of the License at 195 | 196 | http://www.apache.org/licenses/LICENSE-2.0 197 | 198 | Unless required by applicable law or agreed to in writing, software 199 | distributed under the License is distributed on an "AS IS" BASIS, 200 | WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. 201 | See the License for the specific language governing permissions and 202 | limitations under the License. 203 | -------------------------------------------------------------------------------- /Moderation_Policy.md: -------------------------------------------------------------------------------- 1 | # Moderation Policy 2 | 3 | Please refer to the project-wide [Moderation Policy]( 4 | https://github.com/trustoverip/admin/blob/master/Moderation_Policy.md). 5 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # ToIP Technology Stack Working Group ("TSWG") 2 | 3 | The ToIP Technology Stack Working Group. 4 | -------------------------------------------------------------------------------- /TIP_GETTING_STARTED.md: -------------------------------------------------------------------------------- 1 | ## TIP Getting Started 2 | 3 | ### Starting a TIP 4 | TBD - Define Proposal / Application Process 5 | 6 | ### Participating in a TIP 7 | TBD - Define Participation Proposal 8 | 9 | #### Templates 10 | 11 | Describe the TIP templates and how they are used 12 | 13 | ### Graduation Process 14 | Describe the key adoption indicators and how they are measured. 15 | -------------------------------------------------------------------------------- /TIP_LIFECYCLE_MANAGEMENT.md: -------------------------------------------------------------------------------- 1 | # TIP Lifecycle Management 2 | 3 | ## Concept 4 | 5 | ### What is a TIP? 6 | As we seek solutions for an interoperable digital trust marketplace, we must recognize that market dynamics will often drive solution incubation and adoption. In the context of a ToIP, *Market Dynamics* are the market forces that impact the validation and adoption behaviors of producers and consumers of a specific solution architectures. 7 | 8 | A **ToIP Interoperability Profile (TIP)** is a specific type of specification produced by members of the Technical Stack WG ("TSWG"). Analogous to how cooking recipes are composed of specific ingredients, a TIP describes a target solution architecture that is based on a specific set of standards, protocols and technologies. 9 | 10 | A TIP represents a solution architecture that once matured can be the basis for a market proven solution specification. TIPs can be designed, refined and supported by interoperable vendors. 11 | 12 | A TIP definition will: 13 | 14 | * articulate the motivating design principles behind the solution profile 15 | * clearly position standards, protocols and software components (collectively, "technologies") against each layer of the [ToIP Technical Stack](). 16 | * demonstrate incubation activity towards the market adoption of the architecture using a set of *key adoption indicators (KAI)*. 17 | 18 | As a TIP is incubated in the marketplace, several work-products will provide evidence of its maturation. TIPs can be designed, refined and supported by multiple vendors and customers wishing to collaborate on interoperability. A TIP typically includes the following elements critical to industry success: 19 | 20 | * **Use cases**: Descriptive application scenarios capturing the specific requirements of customers in one or more digital trust ecosystems. 21 | * **Design Principles**: Market requirements are necessary when combining technology to formulate a solution architecture. Yet technology alone does not make a solution. Design Principles help to clearly define how the combination of technology and business policies formulate a solution architecture. 22 | * **White-paper**: Documentation that clearly communicates the design, architecture, features, and benefits of a TIP to a digital trust ecosystems targeted for adoption. 23 | * **Market Dynamics**: 24 | 25 | * **Adoption Metrics**: Case study references that provide quantifiable evidence of the real market impact. 26 | * **Interoperability Testing**: Community driven certification of test cases and results. 27 | * **Vendor Support**: Vertical integration of the technical stack must be supported by vendors that can demonstrate the interoperability between multiple vendor solutions that support the TIP. 28 | 29 | * **Best Practices**: Implementation guidance for adoption of a TIP, including how to incorporate policies from the ToIP governance stack. 30 | 31 | TIPs harness market forces to drive convergence on interoperability 32 | 33 | As technology evolves, TIPs will also evolve. This implies that during the lifecycle of a TIP, the various underlying components required to enable a solution will be comprised of an array of standardized and customized components. As depicted by the conceptual “lego block” picture below of a complete four-layer TIP—showing how it is constructed from a combination of of ToIP Deliverables (including ToIP Standard Specifications (TSS)) and custom TIP-specific components. 34 | 35 | ![lego-gaps](./_images/tip-gap-legos.png) 36 | 37 | * Fully-standardized components of the ToIP stack. These components are ToIP deliverables that have already gained Foundation-wide approval. 38 | * Custom components that are specific to a TIP. Some places in the ToIP stack do not yet have agreed-upon specifications. For these gaps, a TIP must specify how it fills the gap via an open community specification that can be implemented by any vendor or open source project. 39 | 40 | ### Why do we need TIPs? 41 | 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. 42 | 43 | ### Who would use a TIP? 44 | As Ecosystem Projects (See Ecosystem Foundry WG) evolve they will need to define governance frameworks and select a TIP. 45 | 46 | ### What is the scope of interoperability for a TIP? 47 | 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. 48 | 49 | 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. 50 | 51 | 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. 52 | 53 | ## TSWG Responsibilities 54 | The Technical Stack WG is responsible for the processes and procedures of the WG as well as the lifecycle of TIP incubation. 55 | 56 | * **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. 57 | * **TIP Criteria**: What are the requirements for proposing a TIP to the WG? 58 | * **TIP Incubation**: Establishment and Management of the TIP Lifecycle Process 59 | * **TIP Graduation**: Review and approval process for the formalization of a TIP into a recommendation (TSS?) 60 | 61 | ## Lifecycle Management Process 62 | The ToIP Foundation, which is technology agnostic, represents a collaborative forum where solution “recipes” can be matured and vetted in the market. 63 | 64 | * **Proposed**: Using a predefined template, propose a TIP to the TSWG to get the approval to establish a ToIP TIP repo. 65 | * **Demonstrated**: incubate the TIP within the community to address the maturation criteria outlined by the TSWG. 66 | * **Accepted**: The TSWG believes a TIP is worthy of a recommendation as a specification and the community has decided to formalize it as a recommendation. 67 | * **Adopted**: The TIP has graduated to a formal recommendation. 68 | * **Retired**: The proposers of the TIP have determined that the maturation process has failed or permanently stalled. 69 | 70 | ## Getting Started 71 | [Discover exiting TIPs or learn how to create your own](./TIP_GETTING_STARTED.md). 72 | -------------------------------------------------------------------------------- /TIP_LIST.md: -------------------------------------------------------------------------------- 1 | # ToIP Interoperability Profile List 2 | 3 | ## TIP Overview 4 | See [TIP Lifecycle Management](./TIP_LIFECYCLE_MANAGEMENT.md) 5 | 6 | ## Getting Started 7 | [Discover exiting TIPs or learn how to create your own](./TIP_GETTING_STARTED.md). 8 | 9 | ## TIP Directory 10 | 11 | | TIP Name | Status| 12 | | --- | --- | 13 | | [Saturn V](https://github.com/trustoverip/technical-stack-wg/blob/master/_proposals/saturn-v-tip.md) | Proposed | 14 | -------------------------------------------------------------------------------- /_images/tip-gap-legos.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/trustoverip/technology-stack-wg/6b764990653b0ffbf41afc14595b14e604d8f07e/_images/tip-gap-legos.png -------------------------------------------------------------------------------- /_proposals/saturn-v-tip.md: -------------------------------------------------------------------------------- 1 | 2 | ## Saturn-V TIP Proposal 3 | 4 | ### Name 5 | * `Saturn-V` 6 | * Repo Name: `saturn-v-tip` 7 | 8 | This is the first TIP proposal under the TSWG and it represents the next evolutionary step towards the *moon shot* known as decentralized identity. Acknowledging the [recently successful NASA/Space-X mission](https://www.cnet.com/news/spacex-splashdown-replay-see-nasa-astronauts-safely-return-to-earth-from-iss/) that has revitalized attention to space exploration, history reveals that our early success in space was significantly aided by the **Saturn V** multi-stage rocket platform. The *Saturn V* three-stage rocket served as a *Heavy Lift Vehicle* for space exploration. It was the most powerful rocket that had ever flown successfully. The  *Saturn V* was used in the Apollo program in the 1960s and 1970s. It also was used to launch the Skylab space station. Containing three (3) powerful fuel-stages, this massive rocket was used to propel man to the moon. Since we are in the early stages of the technology adoption lifecycle for decentralized identity and we seek a technical recipe to bootstrap an interoperable digital trust marketplace. Analogous to the first three layers of the ToIP Stack, this initial TIP represents an exemplar of a technical collaboration to help propel decentralized identity into mainstream adoption. In fact the *Saturn V* project required that three separate companies, each responsible for a separate fuel-stage, collaborated to integrate their fuel-engines into [a single interoperable rocket platform](https://www.space.com/18422-apollo-saturn-v-moon-rocket-nasa-infographic.html) that would propel Appolo and Skylab missions. Today, we seek to integrate technology for three ToIP Layers to achieve a common goal -- help propel the adoption of digital credentials. 9 | 10 | ### Purpose 11 | Today, the decentralized identity community continues the *moon shot* started by the *Sovrin Foundation* towards self-sovereign identity. This proposal is unique as it represents a vertical interoperable stack that is already familiar to most industry participants. This proposal is effectively receiving the baton that began with the Sovrin Network and will focus on evolving that effort into a network of networks model. 12 | 13 | ### Convener(s) 14 | 15 | * Stephen Curran (*nominated*) 16 | * Richard Esplin (*nominated*) 17 | * Dan Gisolfi 18 | 19 | ### Stakeholders 20 | The following vendors are [activity working on interoperability](https://docs.google.com/presentation/d/1WkqSpFERc8now-f-Pz7PsRg9NMywSiZb92rTqJx5y00/edit#slide=id.g8d58b271ca_2_17) in support of this TIP: 21 | 22 | * esatus 23 | * Evernym 24 | * IBM 25 | * Main-Incubator (R&D Unit of Commerzbank Group) 26 | * Telus/ATB-Financial 27 | * Trinsic 28 | 29 | ### Key Motivators 30 | List the reasons that triggered the proposal. 31 | 32 | 1. We need to describe an example TIP that is of interest to many in the ToIP Foundation. 33 | 2. As the Sovrin Community transitions under the broader umbrella of the ToIP Foundation, we need a description of the architecture in which the community desires to embrace. 34 | 3. We need a methodology that will allow alternative TIPs to be compared to the one most familiar with many in the ToIP Foundation. 35 | 4. We need a forum for the 36 | [Indy Interop-athon](https://wiki.hyperledger.org/pages/viewpage.action?pageId=36734079) events that are focused on making the network of networks concepts reality of public identity utilities based on Hyperledger Indy. 37 | 38 | ### Core Principles 39 | The stakeholders believe that the proposed technical stack is purpose built to provide the foundational infrastructure necessary to support the [10 Core Principles](https://docs.google.com/document/d/1WqUOqdTBc3JACIlRviJoWJRcJHTNTNzk9_As9v-jwrY/edit#heading=h.ws45zwyr4hfb) that were adopted by the [Sovrin Foundation](http://sovrin.org). As the decentralized identity community evolves into a network of networks model, these principles will help shape the applicability of solutions. 40 | 41 | | Principle | Description | 42 | | --- | --- | 43 | | Existence | Users must have an independent existence. | 44 | | Control | Users must control their identities. | 45 | | Access | Users must have access to their own data. | 46 | | Transparency | Systems and algorithms must be transparent. | 47 | | Persistence | Identities must be long-lived. | 48 | | Portability | Information and services about identity must be transportable. | 49 | | Interoperability | Identities should be as widely usable as possible. | 50 | | Consent | Users must agree to the use of their identity. | 51 | | Minimization | Disclosure of claims must be minimized. | 52 | | Protection | The rights of users must be protected. | 53 | 54 | ### Technical Stack Proposal 55 | Identify the technologies associated with each layer of the ToIP Stack that will help to define this TIP. 56 | 57 | | ToIP Technical Stack Layer | TIP Technology | 58 | | --- | --- | 59 | | Three | Hyperledger Aries | 60 | | Two | Hyperledger Aries | 61 | | One | Hyperledger Indy | 62 | 63 | ### Use cases to be validated 64 | In addition to the common business patterns associated with decentralized identity, namely `password-less auth` and `digital onboarding`, this TIP proposal will [build on existing proof-points](https://sovrin.org/category/use-cases/) to establish a generalized list of uses-cases that will help to demonstrate cross-industry adoption. 65 | -------------------------------------------------------------------------------- /_templates/tip_proposal.md: -------------------------------------------------------------------------------- 1 | ## TIP Template 2 | 3 | This document provides a basic outlined for the proposal and incubation of a TIP under the TSWG. 4 | 5 | This template is to be used by the TIP Proposal Process. 6 | 7 | ### Name 8 | * `xxxxx` 9 | * Repo Name: `xxxxx-tip` 10 | * Reasoning: 11 | This name will be how this profile will be used in the industry. Provide some background context for why the name was chosen. 12 | 13 | ### Purpose 14 | Describe the concepts behind this TIP proposal and specifically what makes this TIP unique. 15 | Required for TIP Proposal 16 | 17 | ### Convener(s) 18 | List the organizers who will work to incubate this TIP through the maturation process. There will often be several. 19 | Required for TIP Proposal 20 | 21 | ### Stakeholders 22 | List the interested parties willing to be named in association with this incubation endeavor. Over time, stakeholders will be added/removed. This list should focus on the initial sponsors at the time of the proposal. 23 | Required for TIP Proposal 24 | 25 | ### Key Motivators 26 | List the reasons that triggered the proposal. 27 | Required for TIP Proposal 28 | 29 | ### Differentiation 30 | List the reasons why this TIP differs from others. 31 | Required for TIP Proposal 32 | 33 | ### Core Principles 34 | Technology alone does not make a TIP unique. List here one or more core principles that will help shape the applicability of the profile. Details behind each listed principle will be addressed in the incubation process not here. For simplicity, this section SHOULD reference existing Design Principle recommendations. 35 | Required for TIP Graduation 36 | 37 | ### Technical Stack Proposal 38 | Identify the technologies associated with each layer of the ToIP Stack that will help to define this TIP. 39 | Required for TIP Proposal 40 | 41 | ### Use cases to be validated 42 | List one or more use cases where this profile may be applicable. 43 | Required for TIP Graduation 44 | 45 | ### Solution Architecture 46 | Documentation that clearly communicates the design, architecture, features, and benefits of a TIP to a digital trust ecosystems targeted for adoption. This section MUST include all artictecturhe decision records associated with the various underlying components required to enable a solution. For example, why certain standardized and customized components are used and where some gaps still may exist. It is suggested that [proven templates for architecture decision records](https://github.com/adr/madr/blob/master/template/template.md) are used. 47 | Required for TIP Graduation 48 | 49 | ### Market Dynamics 50 | Required for TIP Graduation 51 | 52 | #### Adoption Metrics 53 | Case study references that provide quantifiable evidence of the real market impact. 54 | 55 | #### Interoperability Testing 56 | Evidence of community driven certification of test cases and results. 57 | 58 | #### Vendor Support 59 | Vertical integration of the technical stack must be supported by vendors that can demonstrate the interoperability between multiple vendor solutions that support the TIP. 60 | 61 | #### Best Practices 62 | Implementation guidance for adoption of a TIP, including how to incorporate policies from the ToIP governance stack. For simplicity, this section SHOULD reference existing ToIP recommendations. 63 | 64 | ## References 65 | List of links to applicable resources. 66 | Required for TIP Graduation 67 | --------------------------------------------------------------------------------