{{INSTRUCTIONS ABOUT THE USE OF THIS TEMPLATE: All editorial instructions are enclosed in {{double curly braces}} and MUST be either removed from or replaced in the specification document. All other text MUST be included in the specification document. NOTE: As of 2026, ToIP specifications are required to use Spec-Up-T. It will automatically generate a table of contents for the entire specification document.}}

§ {{Document Title}}

Version: {{MUST be in X.X or X.XX format}}
Document Status: {{MUST be one of: Working Draft, Working Group Approved Deliverable, ToIP Approved Deliverable}}
ToIP Permalink: {{REQUIRED see this ToIP wiki page for instructions}}
DOI: {{see this wiki page for instructions about how to add a DOI}}

Editors: {{MUST list the full names, optional OrcID and official LF affiliations of each editor.}}

• {{Editor 1, Org A}}
• {{Editor 2, Org B}}

Contributors: {{MUST list the full names and official LF affiliations of each substantial contributor — all other acknowledgements go in the Acknowledgements Appendix at the end.}}

• {{Contributor 1, Org C}}
• {{Contributor 2, Org A}}

Abstract

{{REQUIRED. MUST be a concise summary of the specification written so someone without domain-specific knowledge can quickly understand what it covers.}}

Intellectual Property Rights

This specification is provided under the Joint Development Foundation (JDF) charter for Trust Over IP (ToIP) and is subject to the intellectual property rights policy of the {{insert name of}} Working Group:

{{modify the following bullets to reflect the IPR terms of the Working Group}}
Copyright: Creative Commons Attribution 4.0 International (CC BY 4.0)
Patent: W3C Mode (based on the W3C Patent Policy)
Source Code: Apache License, Version 2.0

THESE MATERIALS ARE PROVIDED “AS IS.” The parties expressly disclaim any warranties (express, implied, or otherwise), including implied warranties of merchantability, non-infringement, fitness for a particular purpose, or title, related to the materials. The entire risk as to implementing or otherwise using the materials is assumed by the implementer and user. IN NO EVENT WILL THE PARTIES BE LIABLE TO ANY OTHER PARTY FOR LOST PROFITS OR ANY FORM OF INDIRECT, SPECIAL, INCIDENTAL, OR CONSEQUENTIAL DAMAGES OF ANY CHARACTER FROM ANY CAUSES OF ACTION OF ANY KIND WITH RESPECT TO THIS DELIVERABLE OR ITS GOVERNING AGREEMENT, WHETHER BASED ON BREACH OF CONTRACT, TORT (INCLUDING NEGLIGENCE), OR OTHERWISE, AND WHETHER OR NOT THE OTHER MEMBER HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

§ Introduction

{{REQUIRED. This is the first numbered section and SHALL be written so a layperson can quickly get an overview of the purpose and structure of the specification.}}

§ Requirements Language

The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in IETF RFC 2119.

§ Terminology

{{This section SHOULD include the most important terms required for a reader to understand the specification. These terms SHOULD be managed using the Spec-Up-T glossary features. This glossary MAY include terms that are in the referenced glossaries above if those terms are essential to understanding the specification—in that case those terms SHOULD use the Spec-Up-T transclusion (tref) feature. Alternatively, in the judgement of the editors, this section MAY be either: a) replaced, or b) supplemented with a separate glossary included as an Appendix.}}

Any hyperlinked term not included in this section is referenced from one of the following glossaries:

• ToIP Main Glossary
• ToIP General IT Glossary
• {{any other external glossary included in Spec-Up-T xrefs}}

verifiable credential (VC)

A verifiable credential is a tamper-evident credential that has authorship that can be cryptographically verified.

See the credential specification for more details.

verifiable trust community (VTC)

A VTC uses a verifiable credential.

§ {{First Level Section Name}}

{{Every top-level section MUST include exactly one of the following two sentences immediately after the section header: This section is normative. This section is informative. The first sentence MUST be used if the section contains any normative requirements expressed using RFC keywords. The second sentence MUST be used if the section does NOT contain any normative requirements (and therefore MUST NOT contain any RFC keywords). As a general best practice, all normative sections SHOULD be grouped together.}}

{{Each new section or subsection SHOULD begin with at least a sentence or paragraph introducing the purpose of that section.}}

§ {{Second Level Section Name}}

{{Each new section or subsection SHOULD always begin with at least a sentence or paragraph introducing the purpose of that section.}}

§ {{Third Level Section Name}}

{{Each new section or subsection SHOULD always begin with at least a sentence or paragraph introducing the purpose of that section.}}

{{A bit about the VTC for your info… (just showing an example glossary reference here in the text)}}

{{When nesting sections it is RECOMMENDED to go no more than three levels deep. Use as many sections as is necessary to cover all the requirements of the specification, but keep the text and diagrams as concise as possible. See this IETF guidance.}}

§ Security Considerations

{{REQUIRED for all ToIP specifications. This section SHOULD be formatted as either a numbered list or numbered subsections. See this IETF guidance and also the Security Considerations sections in DID Core and W3C VC.}}

§ Privacy Considerations

{{REQUIRED for all ToIP specifications. This section SHOULD be formatted as either a numbered list or numbered subsections. See this IETF guidance and also the Privacy Considerations sections in DID Core and W3C VC.}}

§ Governance Considerations

{{RECOMMENDED for most ToIP specifications. This section SHOULD be formatted as either a numbered list or numbered subsections. This section SHOULD include any relevant references to the ToIP governance metamodel. See also this IETF guidance.}}

§ Internationalization Considerations

{{RECOMMENDED for most ToIP specifications. This section SHOULD be formatted as either a numbered list or numbered subsections. See this IETF guidance.}}

§ Accessibility Considerations

{{RECOMMENDED for most ToIP specifications. This section SHOULD be formatted as either a numbered list or numbered subsections. See this IETF guidance and also the Accessibility Considerations section in W3C VC.}}

§ Conformance

{{REQUIRED. This section should state what normative requirements (expressed using “MUST” or “SHALL” keywords) apply to which conformance targets. See the Guidelines to Writing Conformance Clauses from OASIS Open.}}

§ Conformance Targets

§ Conformance Tests

§ References

{{Required. See the IETF guidance on how to add normative references and informative references.}}

§ Normative References

§ Informative References

§ Appendices

§ Appendix A: {{Name}}

§ Appendix B: {{Name}}

§ Appendix C: Acknowledgements

{{The final appendix should contain any additional acknowledgements}}