§ TSP-Enabled AI Agent Protocols

Specification Status: v1.0 Draft

Latest Draft:

https://github.com/trustoverip/aimwg-tsp-enabled-ai-agent-protocols

Editors:

Wenjing Chu, Futurewei Technologies, Inc.

Contributors:

Participate:: GitHub repo; Commit history

§ Status of This Memo

This document contains a template specification for ToIP!.

Information about the current status of this document, any errata, and how to provide feedback on it, may be obtained at https://github.com/trustoverip/specification-template.

§ Copyright Notice

This specification is subject to the OWF Contributor License Agreement 1.0 - Copyright available at https://www.openwebfoundation.org/the-agreements/the-owf-1-0-agreements-granted-claims/owf-contributor-license-agreement-1-0-copyright.

If source code is included in the specification, that code is subject to the Apache 2.0 license unless otherwise marked. In the case of any conflict or confusion within this specification between the OWF Contributor License and the designated source code license, the terms of the OWF Contributor License shall apply.

These terms are inherited from the Technical Stack Working Group at the Trust over IP Foundation. Working Group Charter

§ Terms of Use

These materials are made available under and are subject to the OWF CLA 1.0 - Copyright & Patent license. Any source code is made available under the Apache 2.0 license.

THESE MATERIALS ARE PROVIDED “AS IS.” The Trust Over IP Foundation, established as the Joint Development Foundation Projects, LLC, Trust Over IP Foundation Series (“ToIP”), and its members and contributors (each of ToIP, its members and contributors, a “ToIP Party”) 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 ANY ToIP PARTY 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 THESE MATERIALS, ANY DELIVERABLE OR THE ToIP GOVERNING AGREEMENT, WHETHER BASED ON BREACH OF CONTRACT, TORT (INCLUDING NEGLIGENCE), OR OTHERWISE, AND WHETHER OR NOT THE OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

§ RFC 2119

The Internet Engineering Task Force (IETF) is a large open international community of network designers, operators, vendors, and researchers concerned with the evolution of the Internet architecture and to ensure maximal efficiency in operation. IETF has been operating since the advent of the Internet using a Request for Comments (RFC) to convey “current best practice” to those organizations seeking its guidance for conformance purposes.

The IETF uses RFC 2119 to define keywords for use in RFC documents; these keywords are used to signify applicability requirements. ToIP has adapted the IETF RFC 2119 for use in the , and therefore its applicable use in ToIP-compliant governance frameworks.

The RFC 2119 keyword definitions and interpretation have been adopted. Those users who follow these guidelines SHOULD incorporate the following phrase near the beginning of their document: 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 RFC 2119.

RFC 2119 defines these keywords as follows:

MUST: This word, or the terms “REQUIRED” or “SHALL”, mean that the definition is an absolute requirement of the specification.
MUST NOT: This phrase, or the phrase “SHALL NOT”, means that the definition is an absolute prohibition of the specification.
SHOULD: This word, or the adjective “RECOMMENDED”, means that there MAY exist valid reasons in particular circumstances to ignore a particular item, but the full implications MUST be understood and carefully weighed before choosing a different course.
SHOULD NOT: This phrase, or the phrase “NOT RECOMMENDED” means that there MAY exist valid reasons in particular circumstances when the particular behavior is acceptable or even useful, but the full implications SHOULD be understood, and the case carefully weighed before implementing any behavior described with this label.
MAY: This word, or the adjective “OPTIONAL”, means that an item is truly optional. One vendor MAY choose to include the item because a particular marketplace requires it or because the vendor feels that it enhances the product while another vendor MAY omit the same item.

Requirements include any combination of Machine-Testable Requirements and Human-Auditable Requirements. Unless otherwise stated, all Requirements MUST be expressed as defined in RFC 2119.

Mandatories are Requirements that use a MUST, MUST NOT, SHALL, SHALL NOT or REQUIRED keyword.
Recommendations are Requirements that use a SHOULD, SHOULD NOT, or RECOMMENDED keyword.
Options are Requirements that use a MAY or OPTIONAL keyword.

An implementation which does not include a particular option MUST be prepared to interoperate with other implementations which include the option, recognizing the potential for reduced functionality. As well, implementations which include a particular option MUST be prepared to interoperate with implementations which do not include the option and the subsequent lack of function the feature provides.

§ Foreword

This publicly available specification was approved by the ToIP Foundation Steering Committee on [dd month yyyy must match date in subtitle above]. The ToIP permalink for this document is:

[permalink for this deliverable: see instructions on this wiki page]

The mission of the Trust over IP (ToIP) Foundation is to define a complete architecture for Internet-scale digital trust that combines cryptographic assurance at the machine layer with human accountability at the business, legal, and social layers. Founded in May 2020 as a non-profit hosted by the Linux Foundation, the ToIP Foundation has over 400 organizational and 100 individual members from around the world.

Any trade name used in this document is information given for the convenience of users and does not constitute an endorsement.

This document was prepared by the ToIP Technical Stack Working Group.

Any feedback or questions on this document should be directed to https://github.com/trustoverip/specification/issues

§ Introduction

§ The Rise of AI Agent Protocols

The rapid adoption of AI agents is driving a new generation of communication protocols designed for agent-to-tool and agent-to-agent interactions. Prominent among these are the Model Context Protocol (MCP), which connects AI assistants with external tools and data sources, and the Agent-to-Agent Protocol (A2A), which enables interoperability between autonomous agents built on different frameworks.

These protocols standardize how AI agents discover capabilities, invoke tools, exchange messages, and coordinate tasks. MCP defines schemas and transports (JSON-RPC over stdio and Streamable HTTP) that let models interoperate with tools and data sources. A2A specifies inter-agent messaging over HTTPS/SSE/JSON-RPC (with gRPC added in v0.3) to coordinate workflows across applications and providers. As deployments move from isolated AI assistants to multi-agent systems operating across organizational boundaries, the demand for protocols that address security and trust continues to grow.

§ The Security Gap: Retrofitting Web-Era Trust Models

Both MCP and A2A deliberately inherit the web-services security framework: HTTPS/TLS for transport protection and OAuth 2.0/OIDC for authentication and authorization, often modeled via OpenAPI securitySchemes. MCP adopted OAuth 2.1 with PKCE and Dynamic Client Registration. A2A supports OAuth 2.0, OIDC, API keys, and mutual TLS, declared via agent cards.

This pragmatic reliance on the web stack accelerates adoption. OAuth and OIDC are mature, widely deployed, and well-understood. However, as agents shift from experimental prototypes to autonomous, long-lived, cross-domain principals, this security foundation reveals structural gaps. Each gap reflects assumptions in the web stack that do not hold for autonomous AI agents.

The gaps fall into three categories:

§ Gap 1: Agent Identity

The web-services security framework does not provide a native identity model for AI agents. This manifests in four related problems.

Durability. The longer an autonomous agent operates, the more complex and valuable the problems it can solve. Long-duration agents accumulate context, build trust relationships, and develop reputation — all of which depend on stable identity. Stable identity is also a prerequisite for accountability: auditing agent actions, attributing decisions, and enforcing policy require an identifier that persists across sessions and interactions.

The web stack does not provide this. TLS certificates authenticate domains; OAuth 2.0/OIDC tokens identify users or service accounts within an Identity Provider’s (IdP’s) namespace. An agent’s identity is therefore tied to its current domain or IdP account — not to the agent as a persistent principal. If the identifier changes (due to redeployment, provider migration, or infrastructure changes), allowlists break, provenance chains are disrupted, and accumulated credentials are lost. Today, most agents are deployed ephemerally — not because enterprises prefer it, but because the control and identity mechanisms for long-lived autonomous agents do not yet exist. Durable identity is a prerequisite for the autonomous, long-horizon agents that agent protocol specifications and academic research envision.

Centralization. OAuth and OIDC depend on centralized Identity Providers. Identity federation (OpenID Federation, SAML) enables cross-domain trust, but requires bilateral administrative agreements that do not scale to open agent ecosystems, and still binds each agent’s identity to its organization’s IdP. IdP outages or compromises remain single points of failure. Agents operating as autonomous peers need to establish bilateral trust directly; the hierarchical client-server model of OAuth/OIDC does not accommodate peer-to-peer trust establishment.

Heterogeneity. The web stack uses multiple incompatible identifier systems (domain names in X.509, {issuer, subject} pairs in OAuth, vendor-specific service accounts). No current agent protocol defines a native, persistent identifier format for agents. Cross-vendor collaborations require brittle bilateral mappings. W3C Verifiable Credentials 2.0 defines machine-verifiable attestations bound to persistent identifiers, but these cannot be used effectively when the underlying identifiers are ephemeral and change across deployments.

Key management. In the web-services model, cryptographic keys are managed by the infrastructure — TLS keys belong to the domain operator, OAuth signing keys belong to the IdP. The agent does not control its own cryptographic material and cannot independently rotate keys while maintaining identity continuity. If the infrastructure operator is compromised, the agent has no independent cryptographic basis to re-establish trust.

The identity substrate and the trust model built on top of it are distinct problems. One might argue that using decentralized identifiers (DIDs) as the subject within existing OAuth flows would address these issues. However, substituting a DID for the subject claim does not change OAuth’s underlying trust model: tokens are still issued by centralized IdPs, scopes remain static, and the agent still does not control its own cryptographic keys.

§ Gap 2: Authentication and Delegated Authorization

OAuth 2.0 delegation lets a client (here, an agent) act on behalf of a resource owner. Current agent protocols rely on OAuth-style flows or OpenAPI-style auth for delegated authorization. When applied to autonomous AI agents, this model exhibits several well-documented problems.

Confused deputy: In agentic systems, a privileged agent may be manipulated into using its credentials on behalf of an unauthorized party. With bearer tokens, the agent cannot cryptographically verify who is making a request or whether the request is authorized — the token works regardless of who triggered it. The OWASP MCP Top 10 identifies confused deputy as a primary attack vector.
Prompt injection: LLM-based agents are susceptible to prompt injection, where malicious content in data (tool results, user inputs, retrieved documents) is crafted to be interpreted as instructions. This is fundamentally a model-level vulnerability, but the damage it causes is amplified by the lack of authenticated provenance in current protocols. When all data entering an agent’s context is unauthenticated, the agent and its runtime have no basis for applying differentiated trust policies. Authenticated provenance does not eliminate prompt injection, but it provides the infrastructure on which effective defenses can be built.
Token leakage and replay: OAuth access tokens are bearer tokens — anyone holding one can use it until expiry. DPoP (RFC 9449) mitigates this by binding tokens to a key pair via proof-of-possession, but the binding is between token and key, not between token and a verifiable agent identity. A DPoP-bound token proves the presenter holds the right key; it does not prove who the presenter is, what delegation chain authorized the request, or what task context it belongs to.
Static, coarse-grained scoping: OAuth scopes are predefined string tokens that cannot express the dynamic, contextual permissions AI agents require. An agent’s necessary permissions may change from one micro-action to the next, yet scopes are fixed at token issuance time.
No verifiable delegation chains: Agentic systems involve multi-hop delegation — user to orchestrator to specialized agents to tools. OAuth’s native model supports a single layer of delegation; Token Exchange (RFC 8693) enables re-delegation across service boundaries, but each hop trusts the previous authorization server rather than verifying a cryptographic chain. Downstream parties cannot independently audit the full delegation path.
Autonomy and lifecycle mismatch: OAuth’s security model assumes interactive human consent and persistent authorization relationships. Autonomous agents operate at machine speed, may run for hours, days, or months, and spawn sub-agents dynamically. OAuth’s consent-driven model does not scale with the frequency, duration, and system size of agentic workflows — leading to either overly broad long-lived tokens or impractical per-agent approval flows.
Scale of autonomous coordination: When agents number in the hundreds of thousands or millions — as demonstrated by recent agent-only platforms where over a million autonomous agents interact without human participation — trust decisions occur at a frequency and volume that human-mediated authorization cannot support. The security model must handle trust establishment, verification, and revocation at machine scale, not human scale.

The OAuth community is actively extending the framework — Rich Authorization Requests (RFC 9396), DPoP (RFC 9449), Token Exchange (RFC 8693), CIBA — and these are meaningful improvements. However, they address individual symptoms within the existing architectural model. The common root cause remains: the trust model depends on external centralized infrastructure rather than on the cryptographic relationship between the communicating endpoints.

This specification defines a protocol-native approach to authentication and delegation that addresses these structural issues, detailed in subsequent sections.

§ Gap 3: Data Authenticity and Provenance

The problem. TLS authenticates session endpoints; OAuth authenticates the client to the server. Neither provides data-level authenticity: individual messages, tool results, or data artifacts do not carry verifiable origin or integrity proofs once outside the session (RFC 8446 explicitly notes TLS authenticates endpoints, not application data). Trust is bound to ephemeral sessions, not to the data itself. When an agent retrieves data and passes it to another agent, downstream recipients cannot verify its authenticity without re-fetching from the original source. Multi-hop workflows cannot build durable provenance chains. For example, when an orchestrator agent delegates a task to a specialist agent that invokes a tool, the orchestrator receives the tool result through the specialist but has no cryptographic proof that the result originated from the tool and was not modified in transit.

For LLM-based agents, this gap is amplified: data and instructions occupy the same input stream. Skills, plugins, tool descriptions, and retrieved content are not merely data — they influence agent behavior. A malicious skill downloaded from a repository, a poisoned tool description, or compromised retrieved content can alter what the agent does. Without verified provenance, agents cannot distinguish trusted components from untrusted ones. The supply chain for agent capabilities — skills, extensions, integrations — is a data authenticity problem.

Agents need to produce, relay, and consume data that is self-authenticating: the authenticity proof travels with the data, independent of session, transport, or intermediary. This applies to messages, credentials, attestations, task results, and any artifact whose origin matters.

Existing approaches. JOSE (JWS/JWT) provides standardized signing primitives with key identification (kid, jwk, x5c) and issuer/subject claims. However, JOSE defines how to sign a payload and identify a key — not how agent protocols should bind signatures to agent identifiers, how receiving agents resolve and verify those identifiers, or how signatures chain across multiple hops to build provenance. The key identification mechanisms inherit whatever limitations the underlying identifier system has (the same issues described in Gap 1). Without a protocol-level convention, each application re-implements signing with its own choices, and signed payloads from one agent framework cannot be verified by another.

What is needed. A protocol-level mechanism that binds data authenticity to the agent identity substrate: every message is signed using the sender’s cryptographic identifier, provenance is verifiable at each hop, and the mechanism is consistent across agent protocols. More broadly, when the identity substrate changes (as argued in Gap 1), the authentication, authorization, and data authenticity mechanisms built on top of it benefit from being native to that substrate rather than adapted from frameworks designed for a different identity model.

§ Metadata privacy

Even with TLS, network metadata — IP addresses, traffic timing, packet sizes, and communication patterns — remains exposed (RFC 7624). In multi-agent systems where frequent, structured exchanges are the norm, this metadata can reveal workflow structures, business relationships, and operational details. Deployments handling sensitive workflows may require metadata-minimizing routing mechanisms beyond what TLS provides.

§ Evidence from the Field

These gaps are not merely theoretical. MCP, as the more widely deployed protocol, has attracted the most scrutiny. The OWASP MCP Top 10 identifies confused deputy attacks — where agents with elevated privileges execute actions on behalf of unauthorized callers — as a primary attack vector, a direct consequence of bearer-token delegation without verified sender identity. Academic research found 5.5% of MCP servers exhibiting tool poisoning attacks through false tool descriptions. Scans of nearly 2,000 internet-exposed MCP servers found that all verified servers lacked any form of authentication.

Beyond deployment observations, industry practitioners, security researchers, standards bodies, and academic publications have independently concluded that the web-services security framework does not satisfy the trust requirements of AI agent communication. Published analyses from the ISACA, the OpenID Foundation, the Cloud Security Alliance, the Decentralized Identity Foundation, and researchers at ICML 2025 all reach this conclusion. An ICML 2025 position paper argues that authenticated delegation is critical and that current protocols cannot provide it.

§ The Need for a New Trust Layer

The gaps identified above indicate that securing AI agent communication requires more than adapting web-era authentication for agent protocols. A trust layer designed for the characteristics of autonomous agents would need to provide durable agent identity anchored in controller-managed cryptographic keys; data-level authenticity and provenance that travels with the data rather than the session; and cryptographically verifiable, auditable delegation chains with independent revocation at every hop.

The Trust Spanning Protocol (TSP), developed by the Trust over IP Project, is a message-oriented trust layer designed to address these requirements. TSP provides durable identity and authenticity properties across heterogeneous systems, anchored in long-term, controller-managed cryptographic identifiers. As long as endpoints use identifiers based on public key cryptography with a verifiable trust root, TSP ensures their messages are authentic.

TSP is designed to enable, not replace, agent protocols. It provides the trust layer that protocols such as MCP, A2A, and their successors currently lack by supplying:

Agent identity: Durable, controller-managed identifiers portable across infrastructures, supporting multiple identifier types without requiring a shared trust authority. Key rotation preserves identity continuity, and stable identifiers serve as anchors for trust signals — formal credentials, peer attestations, and authenticated word of mouth that accumulate over time.
Data authenticity and provenance: Message-level signatures bound to agent identifiers, making data artifacts verifiable across hops and over time — authenticity travels with the data, not the session.
Secure delegation: TSP’s authenticated messaging and verifiable identifiers provide the foundation for cryptographically verifiable delegation chains, where each hop can be independently audited and revoked. This specification defines delegation profiles built on these primitives.

By layering agent protocols over TSP, their existing developer ergonomics and interoperability are preserved while the trust substrate is strengthened. Tool discovery, invocation, and inter-agent coordination gain durable authenticity and verifiable trust properties that the web stack alone does not provide.

This specification defines how TSP integrates with AI agent communication protocols to address the security gaps described above. It specifies TSP-enabled profiles for agent identity, authentication, authorization, delegation, and secure messaging — defining a path from today’s web-stack-dependent agent protocols to a trust architecture designed for autonomous AI agents.

§ Scope

This specification describes a method of constructing and managing AI Agents, especially their authority and accountability, based the Trust Spanning Protocol (TSP). For brevity, we call AI Agents (or simply Agents) developed using this method as TSP-Enabled Agents, or TEA for short. This method opens up many opportunities to implement crytpographically strong, dynamic and Agent-native authorization and accountability schemes as required by Agent application scenarios

In addition to defining the method, we also apply the method to realize several commonly useful methods of authority delegation/verification and accountability enforcement. The TEA method however are not limited to these specific schemes defined in this specification, and can be applied to create other schemes either as an update to this specification or as separate specifications in the future.

§ Normative references

§ Terms and Definitions

For the purposes of this document, the following terms and definitions apply.

ISO and IEC maintain terminological databases for use in standardization at the following addresses:

ISO Online browsing platform: available at https://www.iso.org/obp
IEC Electropedia: available at http://www.electropedia.org/

Agent: An agent is an anatonomous process over a period of time. An agent may be powered by various AI technologies which introduce capabilities such as use of natural languages, image and visual signal generation and understanding, use of programming and other online tools, reasoning, and so on. In this specification, we assume AI technologies may be used by agents, but they do not have to. Unless we make an explicit distinction in certain context, we use the terms agent and AI agent interchangably.
TSP-Enabled Agent: A TSP-Enabled Agent, or TEA, is an agent that is a TSP endpoint, has Verifiable Identifiers (VID), communicates with other TEAs through TSP. A TEA may also interact with other external systems that are not TEAs. A TEA is a unit that can be delegated with authority to take actions and be accounted for for effects of these actions. For convenience, we also allow the use of TEA Agent as equivalent to just TEA.
Trust Spanning Protocol: The Trust Spanning Protocol (TSP) is a foundational trust protocol that ensures endpoints (the TSP speakers), as identified by Verifiable Identifiers (VIDs), can have strong assurance of endpoint authenticity, message integrity, confidentiality and meta-data privacy.
Verifiable Identifier: A Verifiable Identifier is a class of identifiers defined in the TSP specification. The TEA uses a sub-class of VIDs that have strong cryptographic verifiability for both control and provenance history.
Wallet: As a TSP endpoint, a TEA needs a method to store securely keys and other secrets. In this specification, we call such secure data store as a wallet, or a vault, or secure data store.
Delegation of Authority: A TEA may be given by another party, e.g. an application that can interact with a human user for such authority or an administrative system, through some process that we call Delegation. In this specification, we define ways such delegation can be performed through TSP based messages.
Accountablity: A TEA may be required to observe some rules or duties that are not automatically enforced or even explicitly stated. For example, computer systems often do not enforce by the system implementation Terms of Use agreements. Such terms can later be accounted after violation occured. Implicit rules or imprecise rules are not explicitly stated or not machine readable. Accountability is a process that can investigate and discover whether certain such rules or duties were indeed observed by the TEA during a given time period. This process is usually performed after the fact.
Audit: Audit is a process of performing accountability over the history of a period of time.

§ TEA Reference Framework

As shown in the Reference Framework diagram below Figure 1, we define TEA Agents (or simply TEAs) as units of authorization and accountability that are identified by Verifiable Identifiers (VIDs) as defined in the TSP specification and further refined in this specification. TEA Agents communicate with other TEA Agents through TSP using VIDs.

TEA Agents therefore MUST have methods to guard, maintain and use the VIDs and their associated secrets, such as keys. Practically, we may refer to these methods as Wallets and Vaults. In other words, TEA Agents MUST have wallets.

TEA Agents conceptually MAY be composed of a Controller, one or more AI models (e.g. LLM and other models), and some methods of implementing Agent-scoped memories: storage of long term information. This conceptial composition is useful in understanding and implementing the TEA, but it is not strictly required. As AI technologies evolve rapidly, the common composition of AI Agents may also change. The TEA method itself however is not dependent on a particular way of agent composition. For example, a TEA does not necessarily require either an LLM or a specific type of long term memory. That being said, this composition is useful to illustrate many challenges we are solving in the TEA method.

The Reference Framework diagram also captures other actors in an Agentic System which are important to define authorization and accountability. In the diagram, the “Human interfaces” box represents entities (such as an application or web browser) controlled by humans or human organizations interacting with the TEA as a “user”, for example, prompting or delegating. The “Management and Control Services” box represents external control systems, for example, administrative or operational controls. The “Tools, Services, other systems” box represents any external computational services. These boxes are external entities that we may reference in defining schemes for authorization and accountability.

In a TEA framework, external entities, such as a web service or a user interfacing mobile app, MAY also be TSP-Enabled. In such scenarios, these entities MAY behave just like a TEA. It is an important charactaristic of the TEA framework, the over system can expand into a network based on the common TSP layer.

The diagram also contains a box representing other AI Agents. These Agents MAY also be TEAs, or may not. When these are TEA Agents, this opens a flexible way of constructing more complex agentic systems by a group of networked TEA Agents, where the networking among them is based on TSP.

Combining these elements, we may construct a TSP based network where each node is a TSP-Enabled entity. For the purpose of this specification, all these TSP-Enabled nodes are TEAs. This is illustrated in the next diagram Figure 2.

Finally, TEA Agents can be composite, as shown in the next diagram Figure 3 by a simple example. Composite TEAs are not limited to one way of composition. This diagram is only showing a simple example for illustration. When a TEA Agent is a composite Agent, there MUST be an entity (and therefore VID) representing the whole for the purpose and requirements of being a TEA Agent. This entity is overall who/what authorities are delegated to and accountability is assigned to.

§ Heading 2

CoLorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Mi ipsum faucibus vitae aliquet nec ullamcorper sit amet. Scelerisque fermentum dui faucibus in ornare quam viverra orci. Maecenas ultricies mi eget mauris pharetra. Tempor nec feugiat nisl pretium fusce id. In ante metus dictum at tempor commodo ullamcorper a. Nulla at volutpat diam ut venenatis tellus in.

Quis hendrerit dolor magna eget est lorem ipsum dolor. Cursus metus aliquam eleifend mi in. Volutpat commodo sed egestas egestas fringilla phasellus. Viverra adipiscing at in tellus integer feugiat scelerisque varius. Arcu bibendum at varius vel pharetra. Dictum at tempor commodo ullamcorper. Eu consequat ac felis donec et odio pellentesque diam volutpat. Pretium quam vulputate dignissim suspendisse in est. Et pharetra pharetra massa massa ultricies mi quis hendrerit dolor. Dolor morbi non arcu risus quis varius.

§ Heading 2

This section describes key concepts used in the content of the document. If the concept requires a footnote, one should be inserted as follows: Any defined term should be hyperlinked to its glossary definition (or at least bolded).

§ Heading 1

§ Heading 2

Eu consequat ac felis donec et odio pellentesque diam volutpat. Pretium quam vulputate dignissim suspendisse in est. Et pharetra pharetra massa massa ultricies mi quis hendrerit dolor. Dolor morbi non arcu risus quis varius.

§ Heading 3

§ Heading 4

Sodales ut etiam sit amet. Orci nulla pellentesque dignissim enim sit amet venenatis. Fusce ut placerat orci nulla pellentesque dignissim enim sit. Sollicitudin ac orci phasellus egestas tellus rutrum tellus. Enim eu turpis egestas pretium aenean pharetra magna ac placerat. Et malesuada fames ac turpis egestas. Integer quis auctor elit sed vulputate. Massa tempor nec feugiat nisl pretium.

§ Figures, Bullets and Numbered Lists

§ Figure

Arcu bibendum at varius vel pharetra. Dictum at tempor commodo ullamcorper. Eu consequat ac felis donec et odio pellentesque diam volutpat. Pretium quam vulputate dignissim suspendisse in est. Et pharetra pharetra massa massa ultricies mi quis hendrerit dolor. Dolor morbi non arcu risus quis varius

Alt text A reference to the image.

§ Figure 1. Mi ipsum faucibus vitae

§ Lists

Eu consequat ac felis donec et odio pellentesque diam volutpat:

Establish Magna
1. Dictum at tempor commodo
2. Volutpat commodo sed,
  1. Cursus metus aliquam eleifend.

Identify Bibendum,
- Analyze Donec,
  - Treat Fringilla,

§ Quote

The following is a quote from a referenced source:

This is a quote from an author in a paper that provides invaluable insight into the subject of this ToIP document. Be sure to include a reference to the source.

§ Conclusion

This section seems incorrectly indented: https://github.com/trustoverip/specification-template/issues/1

§ Annex

Annex content