§ Verifiable Trust Infrastructure (VTI) Specification

Version: 1.0
Document Status: Working Draft 0.1.0
DOI: {{see this wiki page for instructions about how to add a DOI}}
GitHub: https://github.com/trustoverip/dtgwg-vti-spec
Published: https://trustoverip.github.io/dtgwg-vti-spec/

Editors:

• Glenn Gore, Affinidi

Contributors:

• Geoff Turk, First Person Project

Abstract

Decentralized Trust Graph (DTG) specifications are deliberately modular: each defines one component — an identifier, a credential, a message, a task, a registry — and each can be conformed to on its own. A working trust system is none of those things individually. It is a set of running nodes that hold keys, grant and revoke authority, admit and remove members, delegate to software agents, and act on evidence produced elsewhere.

This specification defines that infrastructure. It specifies the nodes of a Verifiable Trust Infrastructure — the Verifiable Trust Agent (VTA), the Verifiable Trust Community (VTC), their clients and supporting hosts — together with the model of trust contexts and authority they share, the way a client is enrolled and operated against them, and the requirements that apply to the composed system rather than to any one component. That last part matters because some properties a relying party depends on cannot be established by inspecting a single specification: they are properties of the composition, and this document is where they are owned.

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 Trust over IP - Decentralized Trust Graph 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

This section is informative.

§ The idea in plain terms

Imagine a company where every employee has a keyring. One key opens the stationery cupboard, another the server cabinet, another the safe. Nobody carries a master key, because a master key is one lost keyring away from a disaster. When someone joins a team they get the keys that team needs, and when they leave, those keys stop working — not because they hand them back, but because the locks stop recognising them.

Now imagine the same company has to work with a hundred other companies, none of whom share a building, a keyring, or a security desk. Someone from another firm arrives and says they are authorised to collect a document. How do you check? You can look at their card. You can ring their office. What you cannot do is assume that because their card is genuine, they still work there, or that the person holding it is the person it was issued to.

That is the problem this specification is about. The keys are cryptographic, the buildings are organisations, and the cards are credentials — but the questions are the old ones: who is this, what are they allowed to do, who says so, and is that still true right now?

§ The three things that go wrong

Almost everything in this document exists to prevent one of three failures, and each is easier to understand than the machinery that prevents it.

A key that opens too much. The simplest failure and the most common. An application is given access to everything because giving it access to exactly what it needs was harder. This specification’s answer is the trust context: a boundary you put things inside, so that authority is always authority over something in particular rather than authority as such.

A credential that says more than it knows. A signature proves who wrote a document and that nobody changed it. It does not prove that the writer was entitled to write it, that they still are, or that the thing they described is still the case. A letter signed by a manager who left last year is perfectly genuine and completely worthless. Much of this document is about keeping this was signed by them and they are allowed to do this as separate questions, because systems that merge them fail in ways that look like success.

A system that works in pieces and fails as a whole. Every component can be correct and the arrangement still be wrong. A privacy-preserving proof, carried under a name that never changes, is not private. A task that completes exactly as specified has not necessarily achieved what it was invoked to achieve. This is the hardest of the three, because there is nobody to blame: each part is doing its job. The Composition Requirements chapter exists for it.

§ Why the writing is careful

Several requirements here prohibit something that is easy to build, widely done, and wrong only under conditions you will not meet during testing. Those requirements are written as prohibitions rather than recommendations, and each carries a Rationale paragraph saying what goes wrong without it — usually because the obvious simpler version has already been built somewhere and has already failed.

If a requirement seems fussy, the rationale is where to look before deciding it is.

§ What this specification covers

A VTI is the running infrastructure in which Decentralized Trust Graph (DTG) components are composed into an operating trust system. This specification defines:

• the common model every node shares — trust contexts, the authority model built over them, identity and keys, transports and delivery, sessions, the client lifecycle, the operation surface, and credential handling;
• the nodes themselves — the VTA, the VTC, the VTN and the supporting hosts — and, where two of them could each plausibly own an authority decision, which one actually does;
• the composition requirements — properties that must hold across a complete interaction and that no single component specification can establish.

§ What this specification does not cover

VTI does not define identifier methods, credential data models, trust task definitions, transport protocols, or governance frameworks. It references those specifications and states how they compose. Where a requirement belongs to a component specification, this document says so rather than restating it.

§ The vocabulary in one paragraph

A principal — a person, an organisation or a software agent — is represented by a VTA, which holds their keys and organises what it holds into trust contexts. A client acts under authority the VTA granted it, recorded in an access control entry; so does any other delegate. A client with no standing yet begins with a bootstrap identity and rotates off it. Authority in a context may be unrestricted, in which case the entry is a super-administrator, or scoped to part of the tree, in which case it is a context administrator of that subtree. Sensitive operations may additionally require the caller to re-prove control — step-up — or require a different party, an approver, to give consent. Nodes reach each other through a mediator and depend on host services, and each node and client is run by an operator — the boundary within which two services are one trust domain. A VTC decides who is a member of a community and publishes to a trust registry so that other communities can extend recognition. A VTN aggregates communities and other networks into a curated set, where an entry — a listing — is the network’s to make and need not be agreed to by the party listed. Everything above is a component or a node; what happens when they are operated together is composition, and a property that no component can establish on its own is a composition-owned requirement. Where the evidence does not settle a question, the answer is indeterminate, which is a result rather than an error.

§ This specification is written first

This document states how a Verifiable Trust Infrastructure is to work. It is not a description of any existing implementation, and where a running system behaves differently, it is the system that diverges.

That direction matters more here than it does for a specification written after the fact. Several requirements in this document prohibit an encoding or a default that is easy to implement, widely used, and wrong in a way that only appears under adversarial conditions — an authority inferred from an empty collection, a query direction supplied by default, a send reported as successful because nothing objected. A specification written to describe such an implementation would record the behaviour and add a warning. This one states the behaviour that is correct and treats the difference as work to be done.

Known divergences between this specification and implementations are recorded in Appendix F. The register exists so that the difference is visible and tracked rather than argued about, and so that a reader evaluating an implementation knows which requirements to ask about. An entry in it is a statement about the implementation, never a qualification of the requirement.

§ Structure of this document

The specification is in four parts.

A node type’s chapter in Part C states what it adds to the common model, not what it replaces in it. The Conformance chapter states which parts each target implements.

§ How requirements are stated

Normative statements carry stable identifiers of the form VTI-<AREA>-<nnn> — for example VTI-CTX-016. The area is a three-letter code for the subject matter, listed in the Conformance chapter, and the number is allocated in order within its area.

Identifiers are permanent. A withdrawn requirement is marked withdrawn rather than renumbered, and an identifier is never reused for different text. This is what allows a conformance test, an implementation’s conformance claim, and an independent assessment to cite the same requirement without any of them having to agree on the document’s structure.

Paragraphs marked Rationale record why a requirement is written as it is. They carry no normative force. They are kept in the document because the common failure mode for these requirements is a reader reasonably concluding that the obvious simpler formulation would do — and in most cases the simpler formulation is one that has already been implemented, and has already failed.

§ Reading this document for a purpose

§ Specification Versioning

This specification distinguishes two version numbers that read as if they mean the same thing but do not:

• _Version:_ states the version of VTI that the working group is converging toward — the number a wider ratifying body confirms when this specification reaches Working Group Approved Deliverable or ToIP Approved Deliverable status. It changes only when the specification is re-targeted, not with each Working Draft revision.
• _Document Status:_ carries the semantic version of this Working Draft — Working Draft MAJOR.MINOR.PATCH — and is what editors and implementers use to coordinate day-to-day while the specification converges.

Document Status follows Semantic Versioning 2.0.0:

• MAJOR — a change that breaks conformance for existing implementations, such as removing or tightening a MUST requirement, changing the semantics of an existing requirement, or withdrawing a conformance target or profile.
• MINOR — a backward-compatible addition, such as a new OPTIONAL or MAY requirement, a new profile, or a new informative chapter.
• PATCH — an editorial or clarifying change with no effect on conformance.

Before this specification’s first ratification, a breaking change MAY be released as a MINOR increment instead of a MAJOR one, and Document Status’s MAJOR component MUST NOT advance past 0 until ratification — SemVer 2.0.0 §4 already treats 0.y.z as carrying no compatibility guarantee, so there is no need to spend a MAJOR increment confirming that. See Ratification and the Stable Release Line below for what happens to Document Status and _Version:_ at and after ratification.

Note on cross-specification versioning: VTI composes companion specifications — including [DTG-CRED] and [TRUST-TASKS] (see References) — that are versioned independently of VTI and of each other, each using the same _Version:_ / _Document Status:_ split; a MAJOR release of one does not imply, require, or correspond to any particular release of another. Where this specification’s conformance requirements depend on a mechanism defined by a companion specification, this specification states the minimum Document Status of that companion specification with which VTI’s stated Document Status is compatible, and the companion specification is expected to do the same in reverse. Implementers integrating multiple specifications MUST check the stated minimums rather than assuming that matching or adjacent version numbers imply compatibility. The [DTG-CRED] and [TRUST-TASKS] citations are marked (pending) in References; minimum-version notes against them will be added once the working group fixes those citations.

_Version:_ is set to 1.0, the release VTI is converging toward; it is not yet ratified.

§ Ratification and the Stable Release Line

At the moment a wider body ratifies this specification as a Working Group Approved Deliverable or ToIP Approved Deliverable, Document Status’s MAJOR component crosses from 0 to 1, the header’s status label changes from Working Draft to the ratified label, and _Version:_ is confirmed at the matching MAJOR.MINOR. From that point on, _Version:_ and Document Status’s MAJOR.MINOR carry the same value — they differ only in the status label — until a breaking change resumes drafting toward the next MAJOR: Document Status advances to the new MAJOR.0.0 immediately, but _Version:_ stays at the last-ratified release until that new line is itself ratified. This is the same convention adopted across the DTGWG’s specifications; see Ratification and the Stable Release Line in the Trust Tasks specification for the full rationale.

This section governs the version of this document. Compatibility between peers at the operation level — negotiating a common operation version, refusing one that is unsupported, and maintaining a version floor — is a separate, already-specified concern: see VTI-OPS-005 and VTI-OPS-043 through VTI-OPS-047 in Operation Surface, and the conformance-claim rules VTI-CNF-002 and VTI-CNF-008 in Conformance.

§ 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 is informative.

The terms below are used precisely throughout this specification. A term defined in a referenced glossary is transcluded rather than redefined here.

Two distinctions are worth stating before the list, because conflating either has produced defects in running systems:

• Delegation is not authority. That a party is able to execute an operation — it holds a key, it can reach the endpoint, its message is well-formed — is evidence about capability and none about whether the authority to do so was granted. See the Composition Requirements chapter.
• An attribute is an attribute. Where an implementation’s internal vocabulary uses a different word for a subject’s attributes, that word means something else at another layer. This specification says attribute and means the thing a credential asserts about its subject.

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

• ToIP Main Glossary
• ToIP General IT Glossary

The glossaries of the DTG component specifications this document binds are added to that list as the normative references to them are settled.

ACL entry (access control entry)

The artefact in which authority is held. An entry names a subject and states the role it holds, the trust contexts it is scoped to, any narrowed capability set, its approve scope, its expiry and its provenance.

Authority is derived from an entry and from nothing else: configuration, deployment position and possession of a transport credential confer none.

act scope

The axis of an access control entry that answers: in which trust contexts may this subject make a change?

Act scope takes three values — none, unrestricted, or a named set of contexts — and is derived from the pair of role and scoped contexts rather than from either alone. An empty context set means everywhere for an administrative role and nowhere for every other.

approve scope

The axis of an access control entry that answers: in which trust contexts may this subject bless a change made by someone else? Independent of act scope, and defaulting to none.

approver

A subject that satisfies a consent requirement on behalf of the community or the principal, by virtue of its approve scope.

A least-privilege approver holds act scope none and a non-empty approve scope: it carries authority to authorize and none to act.

assurance level

The strength of the authentication behind a session. Assurance level is recorded in the session, is preserved across refresh, and determines the lifetime of the credential issued.

bootstrap identity

The ephemeral identifier a client mints for itself before it has any standing, and which is conveyed out-of-band to an administrator for enrolment.

A bootstrap identity is low-trust by construction: it has crossed a channel outside the trust system. A client should rotate off it on first successful authentication, and an entry naming one that is not rotated must carry an expiry.

capability

A single power that can be gated separately from the role that ordinarily implies it. An entry’s capability set narrows what its role permits.

The capability set is an extensible registry, which is safe because an implementation must not treat a capability it does not recognise as granted.

client

Anything acting under granted authority rather than its own — an interactive operator client, a headless application, an AI-agent runtime, or a mobile authorizer.

A client’s authority is an artefact held by the node that granted it, revocable at that node, and never inferred from the client’s ability to execute a protocol.

composition

The operation of independently specified components together as a running trust system. Several properties a relying party depends on are properties of the composition rather than of any component within it.

composition-owned requirement

A requirement that no single component specification can establish, and that this specification therefore owns. A component’s conformance to its own specification does not satisfy one.

consent

A requirement that one or more parties other than the caller approve an operation, bound to the digest of the exact payload approved.

A consent requirement is never satisfied by elevating the requester’s session on the strength of another party’s approval: approving one action must not admit any other.

context administrator

An access control entry with an administrative role scoped to named trust contexts. A context administrator administers those contexts and every descendant of them, and may act nowhere else.

context path

The materialized path of a trust context within its tree, and the context’s identifier — for example acme/eng/team-a.

Segments are separated by a single solidus and compared octet by octet. Ancestry is evaluated over whole segments, never over the identifier as a string, so acme is an ancestor of acme/eng and is not an ancestor of acme-evil.

delegate

A subject acting for another — a client, a device or a software agent. Delegation is expressed as an access control entry and by no other means, and a delegate never holds authority its delegator lacks.

host service

Infrastructure a node depends on but does not embody — an identifier-log host, a witness, a push gateway, or a room host.

indeterminate

The outcome of a trust evaluation where the evidence is insufficient to determine whether a condition holds. Distinct from both success and failure, and never silently converted into either.

listed (listing)

An entry in a VTN's published set, naming a VTC or another

VTN. A listing is made by the network alone and does not require the listed

party’s agreement; it therefore carries whether the listed party has

acknowledged it, and any repudiation the network has received. A listing is

not evidence of current authority, and it is not transitive with

recognition.

mediator

A store-and-forward transport node. A mediator observes routing metadata, does not observe content, and confers no authority: a recipient authenticates the sender from the message itself.

member

A subject admitted to a VTC, and whose membership is evidenced by a credential the community issues. Admission is a decision made under community authority, not the completion of a join exchange.

operator

The human or organisation responsible for running a node or a client. The trust boundary of a deployment is drawn per operator rather than per service: two services run by one operator are inside one boundary.

principal

The person, organisation or software agent that a VTA exists to represent. Authority held by a client is always narrower than, and derived from, the authority of the principal it acts for.

re-authentication (step-up)

A requirement that the caller re-prove control with an additional factor before an operation runs, raising the assurance level of that caller’s session for a bounded window.

Step-up involves no third party. Where the requirement is that a different party agrees, the mechanism is consent.

recognition

The acceptance by one VTC of a member of another. Recognition requires proof of possession of the presented credentials, agreement of their subjects, a status check with the issuing community, and an explicit mapping from the foreign role to local authority. Recognition is not transitive.

role

A coarse position named by an access control entry, which determines the maximum set of capability values that entry can carry. A role is a ceiling rather than a grant: an entry may hold less than its role permits and never more.

subject

The party an access control entry names — the identifier whose authority the entry states. A subject is not necessarily a person: a client, a device and a software agent are each subjects of their own entries.

super-administrator

An access control entry with unrestricted act scope — an administrative role naming no trust context. A super-administrator may act in every context of the node.

trust context

The isolation boundary — a partition — within which a VTA holds keys, credentials, stored data, agent memory and delegations, and the unit in which authority is granted. Distinct from a data room, which is a shared space with its own membership; a trust context partitions what one node holds.

Compromise of a credential authorized in one trust context reaches what that context holds and nothing else. Contexts are nested: a context identifier is its context path, and authority over a context extends to every descendant of it.

trust registry

The authority lookup for issuers and communities. Presence in a trust registry is not evidence of current authority, and unavailability of a registry is not evidence of absence from it.

trust task

A canonically defined operation, identified by a versioned identifier, that a node exposes and a peer invokes. Where a canonical trust task exists for an operation, a conforming node exposes that operation as that task; a private interface is permitted only where no canonical task covers it.

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 agent (VTA)

The key, credential and authority root for a principal in a VTI deployment. A VTA holds the principal’s key hierarchy, organises what it holds into trust contexts, decides who may act in each of them, holds and presents credentials on the principal’s behalf, and delegates narrowed authority to the clients and software agents that act for the principal.

A VTA is the authority for its principal’s context tree and for key derivation within it. A VTC is provisioned on top of a VTA and derives its identity from it; the dependency is one-way.

verifiable trust community (VTC)

A community authority in a VTI deployment: the node that decides who

is a member of a community, what that membership means over time, and which

other communities it recognises. A VTC is provisioned on top of an existing VTA

and derives its identity from it. It is not a key authority — it creates no

trust contexts and derives no keys.

verifiable trust infrastructure (VTI)

The infrastructure layer at which DTG components are composed into an

operating trust system: the nodes that hold keys, grant and revoke authority,

admit and remove members and delegate to software agents, together with the

requirements that apply to their composition rather than to any single

component.

verifiable trust network (VTN)

A curation authority in a VTI deployment: the node that aggregates

VTCs and other VTNs into a published set, under an identified owner

and a governance framework. A VTN sits above the VTC in aggregation and not

in authority — it creates no trust contexts, derives no keys, and does not

decide the membership state of any community’s members. Unlike

recognition, a VTN’s relationship to a listed party may be

one-sided: a VTN may list a party that has not agreed to be listed, and the

entry is published as unacknowledged.

§ Architecture and Conformance Targets

This section is informative.

This chapter describes the shape of a VTI and names the node types that the normative chapters bind requirements to. It defines no requirements of its own: it fixes the vocabulary those requirements are written in.

§ The problem this specification addresses

A DTG component specification can be conformed to on its own. An identifier method, a credential data model, a task definition, a transport — each is implementable and testable in isolation, and that isolation is what allows them to evolve independently.

An operating trust system is not any of those things. It is a set of running nodes that hold keys on behalf of people and organisations, grant and revoke authority over parts of what they hold, admit and remove members, delegate to software agents, and act on evidence produced somewhere else by someone else. Several properties that a relying party depends on are properties of that running arrangement rather than of any component within it. A credential can be cryptographically impeccable and issued by a party that no longer holds the authority it asserts. A task can complete exactly as specified while the outcome it was invoked to achieve remains unestablished. Two components, each privacy-preserving, can compose into an interaction that is not.

Those properties need an owner. This specification is that owner, and the architecture below exists to give the ownership somewhere to attach.

§ Conformance targets

Every normative requirement in this specification binds to at least one of the following targets. The Conformance chapter states which profiles each target implements.

§ Verifiable Trust Agent

A VTA is the root of everything else. It holds the key hierarchy for its principal, organises what it holds into trust contexts, decides who may act in which of them, holds and presents credentials on the principal’s behalf, and delegates narrowed authority to the clients and software agents that act for the principal. A principal with no VTA has no way to be represented in a VTI deployment; a VTA with no principal is not a thing this specification describes.

§ Verifiable Trust Community

A VTC is a community authority rather than a personal one. It decides who is a member, what membership means over time, and which other communities it recognises. It is provisioned on top of an existing VTA and derives its identity from it, which makes the dependency one-way: a VTA operates with no VTC anywhere in sight, and a VTC without its underlying VTA has no identity to act with.

The division of authority between the two is a recurring source of confusion, so this specification states it rather than leaving it to be inferred: the VTA is the key and context authority, and the VTC is the membership authority. A VTC references context identifiers as membership metadata; it does not create contexts and does not derive keys.

§ Verifiable Trust Network

A VTN aggregates communities. It curates a published set of VTCs and of other VTNs, under an identified owner and a governance framework, so that a relying party can discover many communities through one list rather than through a relationship with each of them. The Internet comparison is deliberate: a VTN is to communities roughly what an autonomous system is to networks — the unit at which a set is aggregated, announced and found.

It sits above the VTC in aggregation and not in authority. A VTN is not a parent of the communities it lists: it creates no contexts, derives no keys, and does not decide who is a member of any community in it. Removing a community from a network’s list removes nothing from that community’s members.

One difference from the VTC is structural rather than a matter of degree. A listing may be one-sided — a network may list a party that never asked to be listed, where community membership requires both parties to agree — so an entry carries whether the listed party has acknowledged it. Networks are expected to nest (state, national, global) and to overlap (several networks curating the same subject, with different owners and criteria), and neither nesting nor overlap changes what an entry establishes.

No implementation exists at the time of publication, and whether a VTN is a distinct node type or a VTC operating in a curation role is an open question recorded in that chapter. The target is therefore marked provisional.

§ Client

A client is anything acting under granted authority rather than under its own. The category deliberately spans an operator typing at a terminal, a headless process running unattended, an AI-agent runtime acting between human interactions, and a phone used to approve something. What varies across them is who holds the private key, whether a human is present at the moment of action, and whether the thing can be woken. What does not vary is that a client’s authority is an artefact held by the node that granted it, revocable at that node, and never wider than what that artefact says.

§ Mediator, host, registry

These are infrastructure a deployment depends on. They are named as conformance targets because requirements attach to them — a mediator observes routing metadata and therefore has privacy obligations; a host holds an identifier log and therefore has integrity and availability obligations; a registry answers authority questions and therefore has currency obligations — and because a deployment’s properties depend on their behaviour even though they are typically operated by someone else.

§ The trust boundary

The trust boundary in a VTI deployment is drawn per operator, not per service.

Two services run by the same operator sit inside one boundary: compromise of one is, for threat-modelling purposes, compromise of both, and a security argument that depends on them being separate is not sound. Two instances of the same software run by different operators sit in different boundaries even though they share every line of code.

This has a consequence that runs through the whole specification. A property enforced by a node about itself is worth less than a property a relying party can check, because the first is inside a boundary the relying party does not control. Where this specification can require the checkable form, it does.

§ Layering

                 governance frameworks
                          |
    +---------------------+---------------------+
    |     this specification (VTI)              |
    |  contexts and authority | nodes | composition |
    +---------------------+---------------------+
                          |
   identifier methods · credential data models · task
   definitions · transports · registries · proof mechanisms

Components below define what an artefact is and what a message means. Governance frameworks above define what a particular ecosystem expects of its participants. This specification occupies the layer between: it defines the infrastructure the components run inside, and it is where a requirement lands when it belongs to the composition of components rather than to any one of them.

The layering also settles where a requirement is edited when it turns out to be wrong. A requirement about what a credential contains belongs to the credential specification even when it was discovered here. A requirement about what must remain true when that credential is presented over a transport, by a delegate, in a context whose authority changed since issuance, belongs here.

§ The common model

Every node type shares one model, defined in Part B:

• trust contexts — the isolation boundary that keys, credentials, data, delegations and grants are organised into, and the unit in which authority is granted;
• the authority model built over contexts — access control entries, roles, capabilities, the separation between acting and approving, and the approval and step-up requirements that sit in front of sensitive operations;
• identity and keys — the identifier methods each node uses and the cryptography behind them;
• transports and delivery — how nodes reach each other, and what a sender is entitled to conclude when a send returns;
• sessions — how a client’s authority is established for a period of use;
• the operation surface — the task catalogue that is the API, and the transport bindings of it;
• credentials and presentations — what a node issues, holds and presents, and what verifying one of them establishes.

A node type’s own chapter in Part C says what it adds to this model, not what it replaces in it.

§ A request, end to end

The following walkthrough orients the chapters that follow. It describes a single ordinary operation — an AI-agent runtime asking its principal’s VTA to sign something on the principal’s behalf — and names the chapter that governs each step.

1. The agent holds granted authority. Some time earlier it minted its own identifier, an administrator recorded an access control entry naming a role, a context and a narrowed capability set, and the agent rotated onto a long-term identifier. Client onboarding and lifecycle.
2. The agent opens a session. It answers a challenge from the VTA, which resolves its authority from the entry at that moment rather than from anything cached. Sessions and authentication.
3. The agent sends the operation. It uses the canonical task for signing if one exists, over whichever transport both ends support, and the request is authenticated by the transport. Operation surface; transports.
4. The VTA locates the authority. It resolves the entry again, computes the effective capability set from the role’s ceiling and the entry’s own narrowing, and checks that the target key is in a context the entry’s scope covers. Trust contexts and the authority model.
5. The VTA evaluates approval rules. If a rule names this operation, the VTA requires either re-authentication of the caller or consent from a different party, and does so before the operation’s handler runs. Trust contexts and the authority model.
6. The operation runs, or is refused. Either outcome is audited, and a refusal names the rule that produced it so the agent can distinguish “not permitted” from “not yet approved” from “failed”. Trust contexts; operation surface.
7. The reply reaches the agent, or does not. The agent concludes delivery only on the evidence the transport chapter says counts as delivery, and retries under the idempotency contract. Transports, messaging and delivery.
8. A relying party later evaluates the result. What it may conclude from a valid signature, a valid credential and a registry entry — and what it may not — is governed by the composition requirements. Composition requirements.

Every step above is where at least one real system has gone wrong, which is why each one has a chapter.

§ How requirements are stated

Normative statements carry stable identifiers of the form VTI-<AREA>-<nnn>. Identifiers are permanent: a withdrawn requirement is marked withdrawn rather than renumbered, and an identifier is never reused for different text. Areas in use are listed in the Conformance chapter.

Paragraphs marked Rationale record why a requirement is written the way it is. They carry no normative force, and they are kept in the document because the common failure mode for the requirements in this specification is a reader reasonably concluding that the obvious simpler formulation would do.

§ Trust Contexts and the Authority Model

This section is normative.

§ In plain terms

A trust context is a partition. Everything a node holds — keys, credentials, data, the authority it has delegated — belongs to one of them, and a grant is always a grant over particular partitions rather than over the node.

Think of the bulkheads in a ship. They are not there to keep things tidy; they are there so that a breach floods one compartment instead of the hull. The payoff comes on the bad day: a credential that leaks reaches what its partitions hold and nothing else, so “how bad is this?” is a question you answer from the grant itself rather than by auditing everything its holder ever touched.

Partitions nest, and authority over one reaches everything beneath it. That is why the way a partition’s name is compared matters so much: acme contains acme/eng, and must not be read as containing acme-evil, which merely starts with the same letters. One careless string comparison hands an organisation’s authority to anyone who can register a similar-looking name — which is why the first requirement in this chapter is written as a prohibition.

Two other ideas run through what follows. A role is a ceiling, not a grant: it says the most an entry could be allowed, and the entry can hold less. And acting is separate from approving — the person who writes the cheque and the person who countersigns it are doing different jobs, and an approver who can also act is not a control.

§ What this chapter defines

This chapter defines the boundary a VTI node organises everything it holds into, and the model by which authority over those boundaries is granted, narrowed, exercised, approved and withdrawn. The Sessions, Client, Verifiable Trust Agent and Verifiable Trust Community chapters express their requirements in the terms defined here.

§ Trust contexts

A trust context is the isolation boundary within which a VTA holds keys, credentials, stored data, agent memory and delegations, and it is the unit in which authority is granted. A single VTA holds many contexts. Compromise of a credential authorized in one context reaches what that context holds, and nothing else.

VTI-CTX-001 — Every key, credential, stored datum and delegation held by a VTA MUST be associated with exactly one trust context.

VTI-CTX-002 — A VTA MUST NOT perform an operation on a resource except under authority whose scope covers the trust context that resource belongs to.

Rationale. Making the context the unit of grant, rather than the node or the individual key, is what makes least privilege expressible: a purpose gets a context, a client gets authority over that context, and the blast radius of that client is legible without enumerating the resources it can reach.

§ Context identifiers

A context identifier is the materialized path of the context within its tree — acme, acme/eng, acme/eng/team-a. There is no separate parent pointer, and no identifier that has to be resolved to discover where a context sits.

VTI-CTX-010 — A context identifier MUST be a non-empty sequence of segments separated by U+002F SOLIDUS (/). SOLIDUS is the only separator.

VTI-CTX-011 — Each segment MUST be non-empty, MUST NOT exceed 64 bytes, and MUST consist only of the characters A–Z, a–z, 0–9, FULL STOP (.), LOW LINE (_) and HYPHEN-MINUS (-).

VTI-CTX-012 — A context identifier MUST NOT contain a leading separator, a trailing separator, or two consecutive separators.

VTI-CTX-013 — A context identifier MUST NOT exceed 8 segments.

Note. The depth and segment-length limits are fixed by this specification rather than left to implementations, so that an identifier valid at one node is valid at every node. A limit chosen per deployment would make a context creatable in one place and unaddressable in another, which is a failure that appears only once the two are federated.

VTI-CTX-014 — An implementation MUST NOT assign relative-path semantics to any segment. A segment consisting of . or .. is an ordinary segment naming an ordinary context and MUST NOT be interpreted as a reference to the context itself or to its parent.

VTI-CTX-015 — Segments MUST be compared for equality octet by octet. An implementation MUST NOT apply case folding, Unicode normalization or any other transformation before comparison.

§ Ancestry

Ancestry is the predicate the authorization gate is built on. For identifiers a and d, a is an ancestor-or-self of d when the segment sequence of a is a prefix of the segment sequence of d.

VTI-CTX-016 — Ancestry MUST be evaluated over whole segments. An implementation MUST NOT decide ancestry with a byte-prefix or string-prefix comparison over the complete identifier.

VTI-CTX-017 — Authority over a context MUST extend to every descendant of that context, and MUST NOT extend to any context of which it is not an ancestor-or-self.

Rationale. A byte-prefix comparison reports acme as an ancestor of acme-evil, which hands authority over one organisation’s subtree to anyone who can name a context whose first segment merely begins with it. This is the single most consequential rule in the chapter, and it is stated as a prohibition rather than as a definition because the incorrect implementation is the shorter one.

§ Purity of the authorization gate

VTI-CTX-018 — The decision whether a caller’s authority covers a target context MUST be computable from the caller’s verified authority and the target identifier alone. An implementation MUST NOT require the resolution of stored context records to reach that decision.

Rationale. Path-encoded identifiers are chosen over parent pointers precisely to make this possible. A gate that has to traverse a store to resolve ancestry acquires, inside the security check, a question about what to do when the store errors — which is a fail-open waiting to be written — along with a denial-of-service surface, the possibility of a cycle in the parent graph, and a gap between the moment ancestry is resolved and the moment it is used. A pure gate has none of these. The price is that a context cannot be moved (VTI-CTX-024), and it is worth paying.

The grammar for a context identifier is given in Appendix D.

§ Context lifecycle

VTI-CTX-020 — Creating a context MUST require that the creator holds act authority covering the parent under which it is created. Creating a root context MUST require unrestricted act authority.

VTI-CTX-021 — A context MUST be bound at creation to a key-derivation base, and that base MUST NOT change for the lifetime of the context.

VTI-CTX-022 — The derivation base of a child context MUST nest under the derivation base of its parent.

VTI-CTX-023 — Deleting a context MUST either refuse when the context has descendants, or delete the entire subtree. An implementation MUST document which behaviour it implements, and MUST NOT delete a context while leaving any descendant reachable.

VTI-CTX-024 — A context identifier MUST be stable for the lifetime of the context. A node MUST NOT support re-parenting a context, and MUST NOT rewrite an existing context’s identifier.

Rationale. Identifier stability is what allows a grant, an audit record and a derived key to refer to the same context years apart without a translation step. Re-parenting is not deferred for want of effort: moving a subtree rewrites every descendant identifier and every grant that names one, which means an authority statement written yesterday no longer resolves, and the window during which it resolves to the wrong thing is exactly the window an attacker would choose. A deployment that needs a different shape creates the new context and migrates into it, where each step is an audited grant rather than a silent rewrite.

VTI-CTX-025 — A context identifier MUST NOT be reused for a new context while any access control entry names it. Reuse of an identifier after deletion is NOT RECOMMENDED in any case.

Rationale for VTI-CTX-025. An identifier that comes back into use inherits every grant that named it and was not cleaned up, which converts an administrative convenience into a silent restoration of authority.

§ The access control entry

Authority is held in access control entries. An entry names a subject and states what that subject may do.

VTI-ACL-001 — A node MUST derive every authorization decision from an access control entry. Configuration, deployment state, network position and possession of a transport credential MUST NOT confer authority.

VTI-ACL-002 — An entry MUST carry at least: the subject identifier; the role; the set of contexts the entry is scoped to; and provenance sufficient to establish who created it and when. An entry MAY additionally carry: a narrowed capability set; a narrowed set of key identifiers; an approve scope; a step-up requirement; an expiry; a human-readable label; and ecosystem-defined extension members.

VTI-ACL-003 — Every field of an entry MUST default to the interpretation that grants least authority, except where this chapter states otherwise.

VTI-ACL-004 — An expired entry MUST confer no authority. Expiry MUST be evaluated at every authorization decision, and MUST NOT be evaluated only when a session is established.

VTI-ACL-005 — A node MUST NOT interpret an ecosystem-defined extension member as conferring authority.

§ Every grant is stated, never inferred from a shape

VTI-ACL-006 — Where an entry narrows the keys its subject may reach, the narrowing MUST be stated explicitly as one of all, none, or a non-empty list of key identifiers.

VTI-ACL-007 — A node MUST NOT infer a key grant from the absence of a member or from an empty list. An entry carrying neither an explicit key narrowing nor an explicit statement that it is unnarrowed MUST be refused.

VTI-ACL-008 — More generally, a node MUST NOT derive any element of authority from the absence of a member, the emptiness of a collection, or a default applied by a serializer.

Rationale. Omitting an empty collection is a common and usually harmless serialization convention. Applied to a grant it is not harmless: it converts the narrowest authority expressible into the widest, silently, on the wire, with both ends conforming to their own understanding of the shape and neither in a position to notice.

The general form is VTI-ACL-008, and it is the rule the two specific ones are instances of. A grant is a statement about authority; a shape is a property of an encoder. Where the second is allowed to imply the first, the authority a deployment holds depends on a library’s configuration.

§ Storage of subject identifiers

VTI-ACL-009 — A node SHOULD store the subject identifier of an entry under a one-way function rather than in the clear, and MUST be able to answer an authorization question without disclosing the set of subjects it holds entries for.

§ Roles

A role names a coarse position — administrator, initiator, application, reader, monitor — and determines the maximum set of capabilities an entry can carry.

VTI-ACL-010 — A role MUST be treated as a ceiling and MUST NOT be treated as a grant. What an entry may do is the role’s set narrowed by the entry’s own, never widened by it.

VTI-ACL-011 — A node that encounters a role it does not recognise MUST treat the entry as conferring no authority, and MUST NOT fall back to a default role.

The role set and the capability ceiling of each role are recorded in the annex in Appendix C.

§ Act scope: super-administrators and context administrators

The act scope of an entry answers: in which contexts may this subject make a change? It takes exactly three values: none, all, or a named set of contexts.

VTI-ACL-020 — An entry MUST state its act scope explicitly, as one of none, all, or a non-empty list of context paths.

VTI-ACL-021 — An implementation MUST NOT infer act scope from the presence, absence or emptiness of a list. In particular, an empty list MUST NOT be read as all, and MUST NOT be read as none: it is not a valid act scope and MUST be refused.

VTI-ACL-022 — An entry whose act scope is all is a super-administrator, and MUST be able to act in every context of the node. An entry whose act scope names contexts, and whose role is administrative, is a context administrator of those contexts: it MUST be able to administer them and every descendant of them, and MUST NOT be able to act anywhere else.

VTI-ACL-023 — Act scope and role are independent members. A node MUST NOT compute either from the other, and MUST refuse an entry that omits either.

Rationale. Authority is the thing this model exists to state, so it is stated rather than encoded. An encoding in which the same empty list means “everywhere” for one role and “nowhere” for another cannot be read correctly without knowing both members, which means every call site is one omission away from inverting a grant — and the two readings are not adjacent errors, they are opposites.

Requiring the explicit form removes the class rather than warning about it: a reader that sees "act": "all" cannot mistake it for "act": "none", and a reader that sees an empty list has encountered a malformed entry rather than a grant it must interpret. Appendix F records the encoding a current implementation uses instead, and the migration that follows from this requirement.

§ Capabilities

A capability names a single power that can be gated separately from the role that ordinarily implies it.

VTI-ACL-030 — The effective capability set of an entry MUST be the intersection of the role’s ceiling with the entry’s own set, together with any additive capability explicitly granted to the entry.

VTI-ACL-031 — A grant naming a capability outside the role’s ceiling MUST be refused when it is written. An implementation MUST NOT accept such a grant and silently omit the capability.

VTI-ACL-032 — A node MUST NOT treat a capability it does not recognise as granted.

VTI-ACL-033 — An additive capability is one that no role implies. Granting an additive capability MUST require unrestricted act authority, and an entry MUST NOT acquire one by virtue of its role.

VTI-ACL-034 — Where an entry carries a narrowed set of key identifiers, that set MUST intersect the authority conferred by the entry’s context scope, and MUST NOT widen it.

The capability set is an extensible registry. The capabilities registered at the time of publication are listed in Appendix C.

Rationale for VTI-ACL-031. Silently dropping an unauthorized capability produces an entry that does not say what its author believed it said. Refusing it by name sends the author back to the role, which is the decision that actually needs revisiting.

Rationale for VTI-ACL-032. A registry that can grow means a node will eventually read an entry naming a capability defined after that node was built. The capability a node has never heard of is precisely the one it has no basis for granting, and requiring the refusal to be explicit means the decision is written down rather than arrived at by whichever way the parser happens to fail.

§ Approve scope

The approve scope of an entry answers a question independent of the act scope: in which contexts may this subject bless a change made by someone else?

VTI-ACL-040 — Approve scope MUST be represented independently of act scope, MUST take the same three values, and MUST default to none.

VTI-ACL-041 — An entry with act scope none and a non-empty approve scope — a least-privilege approver — MUST be expressible, and MUST be able to satisfy an approval requirement in the contexts its approve scope covers while being unable to initiate any change.

VTI-ACL-042 — A subject MUST NOT confer approve authority wider than the approve authority it holds itself.

Rationale. Separating the two axes is what makes an approver account safe to hand out. An approver whose authority to approve implies authority to act is not a control; it is a second way to do the thing the control exists to gate.

§ Visibility and management of entries

VTI-ACL-050 — A caller MUST be able to modify an entry only where the caller’s act scope overlaps the entry’s act scope.

VTI-ACL-051 — A caller MUST be able to read or list an entry where VTI-ACL-050 permits modification, and additionally where the entry’s approve scope reaches the caller.

VTI-ACL-052 — A subject MUST NOT modify its own entry, except by the self-service rotation defined in the Client Onboarding chapter, which moves an entry to a new subject identifier while preserving its authority exactly.

Rationale for VTI-ACL-051. Reading an entry and managing it are different powers. An approver needs to see the grants it is being asked to bless decisions about; it does not thereby need to be able to change them.

§ Listing entries by context

A filter over a context expresses one of two opposite questions, and a caller that cannot say which one it means will sometimes be given the other.

VTI-ACL-060 — A listing filtered by context MUST support an explicit direction with the following values:

VTI-ACL-061 — A node MUST refuse a listing that filters by context without stating a direction. A node MUST NOT apply a default direction.

VTI-ACL-062 — A node MUST refuse a direction value it does not recognise, and the refusal MUST name the valid values. A node MUST NOT substitute a default for an unrecognised direction.

VTI-ACL-063 — A node MUST refuse a direction given without a context.

VTI-ACL-064 — An entry with unrestricted act scope MUST NOT appear in a subtree answer, and MUST appear in an acting-in or any answer.

VTI-ACL-065 — An entry naming contexts both inside and outside the queried subtree MUST appear in the subtree answer.

VTI-ACL-066 — Where a listing is paginated, the pagination cursor MUST bind the direction it was minted under, and a node MUST refuse to resume a cursor under a different direction.

Rationale. A caller sweeping a subtree in order to revoke it needs the second question. Asked with the first, it receives precisely the entries that are not being revoked — the ancestors keeping their authority — and none of the leaf-scoped grants the sweep exists to cut. The answer is short rather than empty, so it looks complete. Once nested contexts exist the natural least-privilege layout is a leaf context per purpose, which is exactly the layout that makes the omission total.

There is no default direction because there is no safe one. Either default answers a question the caller did not ask, in a form indistinguishable from the question they did ask, and the caller most likely to be harmed is the one performing a revocation. Requiring the direction costs a parameter; supplying one costs a containment failure. Appendix F records that a current implementation defaults to acting-in.

The two edges in VTI-ACL-064 and VTI-ACL-065 are deliberate. An unrestricted entry names no context, so it is not a grant of the branch; including it would hand a caller revoking a compromised branch its own super-administrator to delete. An entry straddling the boundary does hold a grant inside the branch, so omitting it would under-report exactly the case the direction exists to surface.

§ Delegation

A delegate is a subject acting for another — a client, a device, a software agent. Delegation in a VTI deployment is expressed as an access control entry and by no other means.

VTI-ACL-070 — Delegated authority MUST be expressed as an access control entry. A node MUST NOT infer authority from the fact that a subject is able to execute a protocol, hold a key, or reach an endpoint.

VTI-ACL-071 — A delegate MUST NOT hold authority the delegator does not hold at the moment the delegation is created, and MUST NOT retain authority the delegator has since lost.

VTI-ACL-072 — A node MUST be able to determine, for any action taken by a delegate, the entry that authorized it and the subject that created that entry.

VTI-ACL-073 — Re-delegation MUST be refused unless the delegating entry explicitly permits it, and a re-delegated entry MUST NOT be wider in any axis than the entry it derives from.

Rationale. Protocol capability is not authority. An agent that can construct a well-formed request, reach the node, and authenticate has demonstrated exactly that and nothing about whether the action was granted to it. This requirement is the local form of the composition requirement on delegation lineage.

§ Revocation

VTI-ACL-080 — Removing or narrowing an entry MUST take effect at the next authorization decision made under it. A node MUST NOT defer the effect to the expiry of an existing session, token or cached decision.

VTI-ACL-081 — A sweep intended to revoke authority over a context MUST enumerate entries using the subtree direction, and MUST therefore include every entry scoped to a descendant of that context.

VTI-ACL-082 — A node MUST NOT report a revocation as successful while any entry granting authority within the revoked scope remains effective. Where a sweep cannot remove such an entry, the node MUST report the revocation as incomplete and MUST identify the entries that remain.

Rationale for VTI-ACL-082. A containment control that reports success without having contained anything is worse than no control, because it ends the response that would otherwise have found what it missed. The failure mode is specific: a grant scoped one level beneath the swept context is not returned by a query that reads up the tree, so a sweep built on that query removes the ancestors and leaves the leaves — and reports the removals it performed. This requirement makes the report answer the question the operator asked, which is whether authority within the scope still exists, rather than the question the implementation happened to answer, which is whether the entries it found were deleted.

§ Approvals, consent and step-up

Some operations are not safely authorized by a single credential. A node expresses that with approval rules, evaluated before the operation runs.

There are two kinds of requirement, and they are not interchangeable.

VTI-APV-001 — An approval rule MUST name the operation it applies to, and MAY additionally name the contexts it applies in. Where both a context-scoped and an unscoped rule name the same operation, the context-scoped rule MUST apply in the contexts it names.

VTI-APV-002 — A node MUST evaluate applicable approval rules before the operation’s handler runs, and MUST reach the same decision on every transport.

VTI-APV-003 — A re-authentication requirement MUST be satisfied only by the caller, MUST raise the assurance level of the caller’s session for a bounded window, and MUST NOT be treated as evidence that any party other than the caller agreed to anything.

VTI-APV-004 — A consent requirement MUST be bound to the digest of the exact payload approved. An approval MUST NOT be redeemable for a payload other than the one approved, and MUST NOT be redeemable more than once.

VTI-APV-005 — A node MUST NOT implement a consent requirement by elevating the requester’s session on the strength of another party’s approval. Approval of one action MUST NOT admit any other action.

VTI-APV-006 — A party satisfying a consent requirement MUST hold approve authority covering the context the operation acts in.

VTI-APV-007 — Where a rule excludes the requester, the requester MUST NOT count toward the threshold. A single subject MUST NOT count more than once toward a threshold.

VTI-APV-008 — A consent request MUST expire, and an expired approval MUST NOT be redeemable.

VTI-APV-009 — A node MUST refuse, at the time it is written, an approval rule that cannot be satisfied. At minimum this includes: a rule naming an approver set that does not exist or is empty; a threshold larger than the set it draws on; approver configuration on a re-authentication rule; and two rules for one operation whose context scopes overlap.

VTI-APV-010 — A node MUST be able to report, for a given operation and context: which rule applies, what it requires, which subjects can satisfy it, and whether it can be satisfied at all.

VTI-APV-011 — The description presented to an approver MUST identify the operation, the party requesting it, the context it acts in, and the effect of approving it.

VTI-APV-012 — A node MUST provide a means of removing an approval rule that has rendered itself unsatisfiable, and the use of that means MUST be audited.

VTI-APV-013 — What is presented to an approver MUST be derived from the same octets that are digested under VTI-APV-004. A node MUST NOT present a rendering produced from a different source than the one it commits to.

VTI-APV-014 — Creating an entry with unrestricted act scope, or widening an entry to unrestricted act scope, MUST require consent from a party other than the requester.

Rationale for VTI-APV-013. An approval is only as good as the correspondence between what the human saw and what the system committed to. Where the display is rendered from one structure and the digest computed over another, the approver’s decision is about a document that need not exist — and every part of the ceremony still functions, which is what makes the gap hard to notice.

Rationale for VTI-APV-014. Unrestricted authority is the one grant from which every other grant can be made, including the removal of the controls that governed it. Requiring a second party is not a statement about the requester’s trustworthiness; it is the recognition that a single compromised credential should not be able to end the deployment’s ability to constrain anything.

Rationale for VTI-APV-005. A design in which a third party ratifies an action and the requester’s session is then elevated for a period is consent with the binding removed: the approver believes they approved one change, and what they actually granted was a window in which every gated change passes. The distinction is invisible in the approval interface and decisive in effect.

Rationale for VTI-APV-009. An unsatisfiable rule is a lockout that has not happened yet. Refusing it when it is written costs the author one error message; discovering it at the moment it blocks an operator costs an incident, and the error at that point names a condition the operator cannot act on.

Rationale for VTI-APV-011. Several requirements in this specification depend on a human understanding what they are approving. An approval a person cannot comprehend is not consent, and a control built on it provides assurance to everyone except the person exercising it. See also the Accessibility Considerations.

§ Audit

VTI-AUD-001 — A node MUST record an audit event for: the creation, modification, removal and rotation of an access control entry; the creation and deletion of a context; the creation, modification and removal of an approval rule; and every approval decision.

VTI-AUD-002 — An audit event MUST identify the subject that acted, the authority that permitted the action, the resource acted on, the time, and the outcome.

VTI-AUD-003 — A node MUST audit refusals as well as successful actions.

VTI-AUD-004 — The audit trail MUST be tamper-evident: an observer MUST be able to detect the modification or removal of a previously recorded event.

VTI-AUD-005 — An audit record MUST NOT embed personal data in a form that cannot later be erased. Where a record must refer to personal data, it MUST do so by reference or by a salted commitment, such that erasing the data leaves the record’s integrity verifiable.

VTI-AUD-006 — Access to the audit trail MUST itself be authorized, and MUST itself be audited.

Rationale for VTI-AUD-005. Tamper-evidence and erasure are in genuine tension: a chain that cannot be altered cannot have a name removed from it. The tension is resolved at write time or not at all. A record that commits to a reference rather than embedding the data can honour an erasure without breaking the chain; a record that embedded the data leaves an operator choosing between two obligations, and whichever they choose they will be in breach of the other.

Rationale for VTI-AUD-006. The audit trail is the most complete description of a principal’s activity that a deployment holds. Reading it is a privileged act, and a control that records everything except who read it has a gap exactly where an insider would stand.

Rationale for VTI-AUD-003. The refused attempts are the half of the record that answers whether a control is working, and a trail containing only successes cannot distinguish a system nobody attacked from one whose gate is open.

§ Where authority decisions live

Two node types could each plausibly own several of the decisions in this chapter. This section states which one does, so that an implementer is never left to infer it.

VTI-ACL-090 — The VTA MUST be the authority for the context tree and for key derivation within it. A VTC MUST NOT create contexts and MUST NOT derive keys.

VTI-ACL-091 — Where a VTC references context identifiers, it MUST evaluate them using the ancestry predicate defined in this chapter.

VTI-ACL-092 — A node MUST NOT infer ownership of an authority decision that this specification does not assign. Where this specification is silent, an implementation MUST refuse rather than assume.

Rationale. A decision with two plausible owners and no assigned one is a decision that gets made twice, differently, and the disagreement surfaces as an authorization gap rather than as an error. The purpose of VTI-ACL-092 is that the gap is closed by refusal rather than by whichever implementation happens to be more permissive.

§ Identity, DIDs and Key Management

This section is normative.

This chapter specifies the identifiers a VTI node uses, the cryptography behind them, and the lifecycle of both.

§ Identifier methods

VTI-KEY-001 — The durable identity of a VTA, a VTC or a host service MUST be a did:webvh identifier.

VTI-KEY-002 — A client bootstrap identity MUST be a did:key identifier, as required by VTI-CLT-003.

VTI-KEY-003 — A node MAY support further identifier methods, and MUST NOT require a peer to support a method other than those named in VTI-KEY-001 and VTI-KEY-002.

VTI-KEY-004 — An identifier method serving the durable position MUST provide: resolution by a party with no prior relationship to the subject; a verifiable history of the identifier’s updates; rotation of key material without change of the identifier; and deactivation.

Rationale. The two positions have opposite requirements, which is why two methods are required rather than one. A node’s identity outlives its keys and has to be resolvable by strangers, so it needs a log and a history. A client’s bootstrap identity is minted before the client has standing, network access or anywhere to publish, so it has to be derivable from a key and nothing else. VTI-KEY-004 states what the durable position depends on, so that a future method can be evaluated against the requirement rather than against the name.

§ Correlation and identifier reuse

VTI-KEY-005 — A node SHOULD use a distinct identifier for each relationship it holds, where that relationship does not require a publicly resolvable identity.

VTI-KEY-006 — A client identifier MUST NOT be reused across trust contexts.

VTI-KEY-007 — A durable node identifier is publicly resolvable and therefore inherently correlatable. A node MUST NOT use its durable identifier for interactions in which correlation of the parties is not intended.

Rationale. The context boundary is the deployment’s primary privacy control, and an identifier that spans contexts defeats it without touching a single credential: the observer does not need to read anything, only to notice the same name in two places. This is the identifier-layer form of the composition requirement on privacy — a set of unlinkable credentials presented under one stable identifier composes into a linkable interaction.

§ Cryptography

VTI-KEY-010 — Ed25519 for signatures and X25519 for key agreement are mandatory to implement. Every conforming node MUST support both.

VTI-KEY-011 — A node MAY support further algorithms, and MUST NOT assume a peer supports any algorithm other than those in VTI-KEY-010.

VTI-KEY-012 — A node MUST identify the algorithm of every key it publishes, and MUST NOT infer the algorithm of a peer’s key from context.

VTI-KEY-013 — A node MUST maintain a set of accepted algorithms, MUST refuse a proof whose algorithm is outside it, and MUST be able to retire an algorithm from that set without a software change.

Rationale for VTI-KEY-013. An algorithm is retired at the moment it is broken, which is not a moment anyone schedules. A deployment that can only retire an algorithm by shipping a release will keep accepting it for as long as the release takes, and the decision will be made by whoever owns the build rather than by whoever owns the risk.

Rationale. One mandatory suite is what makes two conforming nodes interoperable without negotiation. Everything else is a local optimisation that a peer is entitled not to have.

§ Key purposes

VTI-KEY-020 — Every published key MUST state the purposes it is authorized for.

VTI-KEY-021 — A key authorized for one purpose MUST NOT be used for another.

VTI-KEY-022 — A verifier MUST check that the key used is authorized for the purpose the material is being relied on for, and MUST refuse where it is not.

§ Derivation

VTI-KEY-030 — A key belonging to a context MUST be derived from that context’s derivation base.

VTI-KEY-031 — A context’s derivation base MUST be immutable, as required by VTI-CTX-021, and a child context’s base MUST nest under its parent’s, as required by VTI-CTX-022.

VTI-KEY-032 — Derivation MUST NOT permit a key belonging to one context to be derived from the base of a context that is not its ancestor.

VTI-KEY-033 — Root derivation material MUST NOT leave the node’s protection boundary except through the backup mechanism specified in the Verifiable Trust Agent chapter.

§ Rotation

VTI-KEY-040 — Rotation of a durable identity’s key material MUST NOT change the identifier.

VTI-KEY-041 — Rotation MUST be recorded in the identifier’s verifiable history.

VTI-KEY-042 — A verifier that observes a rotation MUST verify subsequent material against the current key, and MUST NOT accept material created after the rotation’s effective time under the retired key.

VTI-KEY-043 — An identifier method that supports commitment to the next key SHOULD be used with that commitment made.

§ Service endpoints

VTI-KEY-050 — An identifier document MUST carry the transports at which its subject can be reached.

VTI-KEY-051 — A peer MUST NOT assume a single transport, and MUST select from what the document offers.

§ Resolution, caching and deactivation

VTI-KEY-060 — A resolver MUST respect the validity period stated by a resolution result, and MUST NOT extend it.

VTI-KEY-061 — A resolver MUST NOT cache a negative resolution result beyond a short bounded period, and MUST NOT cache one at all where the failure was a transport failure rather than an authoritative statement that the identifier does not exist.

VTI-KEY-062 — A node MUST provide a means of forcing re-resolution of an identifier.

VTI-KEY-063 — A deactivated identifier MUST be treated as conferring nothing.

Rationale for VTI-KEY-061. A negative cache entry outlives the condition that produced it, and the symptom is an identifier that cannot be resolved long after it can — indistinguishable, from the caller’s side, from one that does not exist. A newly published identifier is the common case: it is looked up before it exists, and the answer is then remembered for as long as the cache holds it.

Caching a transport failure is the specific error the second half prohibits. A timeout is evidence about the network and none at all about the identifier, so recording it as a fact about the identifier converts a transient condition into a durable wrong answer.

§ Transports, Messaging and Delivery

This section is normative.

§ In plain terms

The post office accepting your letter is not the recipient reading it.

Most of this chapter is that sentence applied carefully. A send that returns without error has, at best, handed the message to something that promised to carry it. Treating that as delivery is how a system ends up confident that something happened when it did not — and the failure is silent, because everything reported success.

So this chapter is exact about what counts as evidence that a message arrived, and requires a sender to record which evidence it has. It also requires a node’s health signal to answer “can I send right now?” rather than “did I manage to once, when I started”.

§ What this chapter defines

This chapter specifies how VTI nodes reach each other, and — the harder half — what a sender is entitled to conclude when a send returns successfully.

§ Transport independence

VTI-TRN-001 — A node MUST support at least one of the transports defined by the referenced transport specifications, and MUST state which.

VTI-TRN-002 — An authorization decision MUST NOT depend on the transport a request arrived over. The same request under the same authority MUST produce the same decision on every transport a node exposes.

VTI-TRN-003 — A node MUST NOT expose an operation on one transport that it refuses on another for any reason other than the caller’s authority.

Rationale. Where transports carry different decisions, the weakest one is the node’s real policy, and which transport that is will not be recorded anywhere.

§ Liveness

VTI-TRN-010 — A node MUST retain at least one working transport. A configuration change that would remove the last one MUST be refused.

§ Mediators

VTI-TRN-020 — A mediator MUST NOT be able to read the content it forwards.

VTI-TRN-021 — A recipient MUST authenticate the sender of a message from the message itself, and MUST NOT rely on an assertion by the mediator.

VTI-TRN-022 — A node MUST NOT treat the ability to reach it through a particular mediator as conferring authority.

§ Metadata and correlation

VTI-TRN-025 — A sender MUST NOT place outside the encrypted envelope any metadata that reveals the nature of the operation being performed.

VTI-TRN-026 — Routing identifiers SHOULD differ per relationship, such that an intermediary cannot link two of a principal’s contexts by their routing alone.

VTI-TRN-027 — Where a deployment’s threat model includes traffic analysis, a node SHOULD apply padding, batching or cover traffic, and MUST document whether it does.

VTI-TRN-028 — A wake or push notification delivered through a third-party service MUST NOT carry content, and MUST NOT carry identifiers that reveal to that service the nature of the pending action or the parties to it.

Rationale. A mediator is trusted to route and not to read, and the routing is the part it necessarily sees. What it must not be able to do is reconstruct a principal’s activity across contexts from routing alone, which is what shared routing identifiers hand it for free. VTI-TRN-028 addresses the same hazard one layer out: a push service is an intermediary nobody in the trust system chose, and a notification that says what is waiting tells it more than the mediator learns.

§ Resource bounds

VTI-TRN-029 — A node MUST bound the resources any one subject can consume, and MUST bound those available to unauthenticated peers separately.

§ Truthful send

VTI-TRN-030 — A send operation MUST NOT report success unless the message has been transmitted or durably queued for transmission.

VTI-TRN-031 — Acceptance of a message by a hop MUST NOT be reported as delivery to the recipient.

Rationale. A send that resolves successfully for a frame that was dropped makes every layer above it wrong in the same direction: the application believes the message is gone, the retry machinery has nothing to retry, and the health signal agrees with both. Nothing in the system disagrees, so nothing raises an alarm.

The requirement is stated at the send because that is the only place the truth is still available. A layer above can observe that no reply came, which is consistent with delivery; only the sending layer knows whether anything left.

§ Delivery confirmation

VTI-TRN-040 — A sender MUST NOT treat a message as delivered except on one of the following classes of evidence, listed in descending strength:

1. A receipt from the recipient’s delivery layer, acknowledging durable receipt. This is the only class that is end-to-end and does not rest on trusting an intermediary’s durability.
2. A protocol reply correlated to the message.
3. Transport evidence that the recipient collected the message, where the transport provides it.

VTI-TRN-041 — A sender MUST record which class of evidence a delivery was confirmed by.

VTI-TRN-042 — Where a stated delivery window passes without evidence, a sender MUST NOT assume delivery. It MUST escalate: re-resolve the recipient and attempt an alternate binding offered by the recipient’s identifier document where one exists; otherwise mark the delivery failed and surface it to the operator.

VTI-TRN-043 — A receiver MUST deduplicate redelivered messages by their idempotency key, as required by VTI-OPS-061.

Rationale for VTI-TRN-040. Store-and-forward transports are at-least-once buses. Acceptance by a mediator means durably queued, which is a genuine property and not the one the application needs: the mediator can still lose the message, and the recipient may never collect it. The three classes are kept distinct rather than collapsed because they close different windows, and a sender that records only “delivered” cannot later tell which window its claim rests on.

Rationale for VTI-TRN-042. A dead mediator is not a dead peer. Re-resolving before failing is what distinguishes the two, and doing it in that order is what prevents a transport outage from being recorded as a peer that will not answer.

§ Bounded waits and honest health

VTI-TRN-050 — Every network operation MUST be bounded by a timeout.

VTI-TRN-051 — A failure to establish a transport MUST fail closed.

VTI-TRN-052 — A node’s determination of its own reachability MUST be re-falsifiable. A node MUST NOT latch a reachability determination made at start-up.

VTI-TRN-053 — A health signal MUST reflect the node’s current ability to send, and MUST NOT report the last known good state.

Rationale for VTI-TRN-052 and VTI-TRN-053. A connection state decided once at boot is a claim about a moment that has passed, and a health endpoint built on it reports success for as long as the process survives. The failure mode is specific and expensive: the operator’s dashboard is green, the messages are not arriving, and the signal designed to detect exactly that is the reason nobody is looking.

§ Sessions and Authentication

This section is normative.

§ In plain terms

Signing in is a conversation of three steps: the node sends a number nobody can guess, the caller signs it with the key only they hold, and the node hands back something that stands in for that proof for a while.

The last part is where the care goes. That stand-in — a session — is a convenience, not a grant. It says this caller proved who they were a moment ago; it does not say they are still allowed to do anything. So the node looks up what they are allowed to do again every time the session is extended, which is what makes withdrawing someone’s access take effect in minutes rather than whenever their session happened to end.

One rule in this chapter looks pedantic and is not: the node must not tell an unauthenticated caller whether it has ever heard of the subject they named. Otherwise anyone who can guess identifiers can ask a node which of them it holds authority for, which is the first step in targeting the people behind them.

§ What this chapter defines

This chapter specifies authentication once, for every transport: challenge, authenticate, refresh. Each is an operation of the auth family in the required catalogue (VTI-OPS-080), and every requirement here binds that operation on every binding of it. A session is a period during which a node accepts a subject’s requests without repeating the proof of control that opened it, and every requirement here exists to bound what that period can be relied on to mean.

§ The challenge

VTI-SES-001 — A challenge MUST be generated from a cryptographically secure random source and MUST carry at least 128 bits of entropy.

VTI-SES-002 — A challenge MUST be bound to the subject it was issued for.

VTI-SES-003 — A challenge MUST expire, and a node MUST enforce the expiry.

VTI-SES-004 — A challenge MUST be redeemable at most once.

VTI-SES-005 — A node MUST limit the number of outstanding challenges per subject.

VTI-SES-006 — A node MUST refuse to issue a challenge to a subject with no effective access control entry.

VTI-SES-007 — The refusal required by VTI-SES-006 MUST NOT be distinguishable, by an unauthenticated caller, from the other refusals a challenge request can produce. A node MUST NOT disclose whether an entry exists for a subject to a caller that has not authenticated as that subject.

Rationale for VTI-SES-007. A challenge endpoint that answers differently for a known and an unknown subject is an enumeration oracle: an attacker who can guess identifiers learns which ones a node holds authority for, which is the first step in targeting the humans behind them. The refusal is uniform, and the client’s own signal — that it has repeatedly failed to obtain standing — is what reaches its operator (VTI-CLT-016), because a client knows it enrolled and an attacker probing identifiers does not.

§ Authentication

VTI-SES-010 — The signer of an authentication response MUST be the subject the challenge was issued to. A node MUST refuse a response signed by any other subject.

VTI-SES-011 — A node MUST compare the presented challenge to the issued challenge in constant time.

VTI-SES-012 — Where the transport carries a creation time, a node MUST enforce a freshness window on it.

VTI-SES-013 — A node MUST record, in the session it establishes, the means by which the subject authenticated and the assurance level reached.

Rationale for VTI-SES-010. Without this binding, a challenge that leaks becomes a credential: any subject able to sign can redeem it. It is stated separately from the challenge’s binding to its subject (VTI-SES-002) because the two are enforced at different moments, and an implementation that has done the first still has to do the second.

§ Resolving authority

VTI-SES-020 — A node MUST resolve the subject’s authority from its access control entry at authentication, and again at every refresh.

VTI-SES-021 — A node MUST NOT establish or continue a session for a subject whose entry has been removed, has expired, or no longer confers any authority.

VTI-SES-022 — A node MUST NOT rely on authority captured at authentication when performing an operation later in the session, where this specification requires the authority to be current.

Rationale. A session is a convenience over repeated proof of control, and it is not a grant. Re-resolving at every refresh is what makes a revocation take effect on the timescale of a refresh rather than on the timescale of whatever the longest-lived session happens to be.

§ Refresh

VTI-SES-030 — Claiming a refresh credential MUST be atomic: for a given credential, exactly one concurrent caller MUST succeed.

VTI-SES-031 — A refresh MUST invalidate the session it replaces.

VTI-SES-032 — The assurance level of a session MUST be preserved across refresh. A session that was elevated MUST NOT silently return to a lower level.

VTI-SES-033 — The lifetime of an access credential MUST be a function of the assurance level of the session, and an elevated session’s credential MUST NOT be longer-lived than an unelevated one’s.

VTI-SES-034 — A node MUST enforce a maximum total session lifetime that refresh cannot extend.

Rationale for VTI-SES-030. Without atomic claiming, a refresh credential replayed concurrently across replicas yields two live sessions from one, and the second is invisible to anything that assumes the first replaced it.

Rationale for VTI-SES-032. Silently dropping the assurance level at refresh converts an elevation into something that expires without saying so: the caller continues, the node continues, and the requirement that produced the elevation is no longer being met by anything.

§ Session lifecycle

VTI-SES-040 — A node MUST be able to terminate a session, and MUST be able to invalidate an issued access credential before its expiry.

VTI-SES-041 — A node MUST audit the establishment, refresh, termination and failed establishment of a session.

VTI-SES-043 — A node MUST be able to enumerate the sessions active for a subject, and MUST be able to terminate them collectively.

VTI-SES-042 — Where the transport supports binding a session to a key held by the client, a node SHOULD bind it, and MUST refuse a request under a bound session that does not demonstrate that key.

§ Client Onboarding and Lifecycle

This section is normative.

§ In plain terms

A new client is a contractor arriving at reception with no pass.

It makes its own temporary pass — the node never sees the key behind it, so a compromised node cannot impersonate its own clients. It reads out the pass number to an administrator, who writes it into the register with the partitions it reaches and the hours it is good for. That number travelled by whatever channel was handy: chat, email, a photograph of a screen. It has been seen by people whose interest in it nobody checked.

So on first arrival the contractor trades the temporary pass for a permanent one and the temporary number stops working. The order matters more than it looks: the new pass is checked at the door before the old one is cancelled, because a pass that has been cancelled in favour of one that does not work leaves someone standing outside with no way back in. Everything in Step 3 is about that sequence.

The threat this does not solve is worth naming. If someone alters the message carrying the pass number, the administrator enrols an impostor — and rotation does not help, because the impostor simply rotates onto another pass of their own. What helps is confirming the number by a second route, and noticing that the real contractor never got in.

§ What this chapter defines

This chapter specifies how a client obtains standing against a VTA, and how it holds that standing over time. The onboarding sequence has four steps, and the order carries the security properties, so the chapter is written in that order.

Throughout this chapter, the node means the VTA or VTC the client obtains standing against, and the operator means the human responsible for the client.

§ Client classes

A client is anything acting under granted authority rather than its own. Four classes recur, and they differ in ways this chapter accounts for:

What does not vary across them: the client’s authority is an artefact held by the node, narrower than the node’s own, revocable at the node, and never inferred from the client’s ability to execute a protocol.

§ Step 1 — mint an ephemeral identifier client-side

VTI-CLT-001 — A client MUST generate its own key pair, using a cryptographically secure random source.

VTI-CLT-002 — The private key MUST NOT leave the client. A client MUST NOT transmit it to the node, to an administrator, or to any third party, and a node MUST NOT require its disclosure as a condition of enrolment.

VTI-CLT-003 — The resulting identifier MUST be a did:key identifier.

VTI-CLT-004 — A client MUST record the identifier minted in this step as a bootstrap identity, distinguishable in its local state from a long-term identity.

VTI-CLT-005 — This step MUST NOT require the node to be reachable.

VTI-CLT-006 — A client SHOULD hold its private key in storage protected by the platform — an operating-system keychain, a secure element, or equivalent — and MUST NOT hold it in storage readable by other principals on the host.

Rationale. Client-side minting is what allows the node never to hold a client’s private key: a compromised node can revoke its clients, impersonate none of them, and cannot repudiate what it signed by pointing at a key it also held. did:key is required here because this step happens before the client has any standing, any network, or anywhere to publish — an identifier that requires a host or a registration is not mintable at this point in the sequence.

§ Step 2 — enrol the identifier

The bootstrap identifier is conveyed out-of-band to an administrator — a chat message, an email, a scanned code — who records an access control entry for it.

VTI-CLT-010 — Enrolment MUST result in an access control entry as defined in the Trust Contexts chapter. A node MUST NOT grant a client standing by any other means.

VTI-CLT-011 — The enrolling administrator MUST hold act authority covering the context the entry is scoped to.

VTI-CLT-012 — The entry created at enrolment MUST be scoped to the narrowest context and capability set the client’s purpose requires.

VTI-CLT-013 — A bootstrap identifier MUST be treated as low-trust: it has crossed a channel outside the trust system, and the node has no evidence of which party controls it beyond the assertion of the person who relayed it.

VTI-CLT-014 — The entry created at enrolment SHOULD carry a short expiry. Where the client does not perform the rotation in Step 3, the entry MUST carry an expiry.

VTI-CLT-015 — The enrolling administrator SHOULD confirm the identifier with the client’s operator over a channel distinct from the one that delivered it.

VTI-CLT-016 — A client that repeatedly fails to obtain standing after enrolment MUST report that condition to its operator distinguishably from a transport failure. A client MUST NOT rely on the node disclosing whether an entry exists, which VTI-SES-007 prohibits: the signal is the client’s own knowledge that it enrolled and has not obtained standing.

Rationale for VTI-CLT-015 and VTI-CLT-016. The enrolment channel is the weak point of the sequence, and the threat is substitution rather than disclosure: an attacker who can modify the message that carries the identifier can have the administrator enrol an identifier the attacker controls. Rotation in Step 3 does not address this — the substituted identifier would simply rotate onto another identifier the attacker controls. What addresses it is confirming the identifier over a second channel, and noticing that the legitimate client never obtained standing. VTI-CLT-016 exists so that the second signal reaches a human instead of appearing as an ordinary failure to connect.

Rationale for VTI-CLT-012. Enrolment is where scope is decided. Widening it afterwards is a separate act with its own audit record, whereas a grant that starts wide is rarely narrowed at all.

§ Step 3 — connect, then roll the key

VTI-CLT-020 — A VTA MUST implement the rotation operation specified in this section — the acl family’s key-swap operation in the required catalogue (VTI-OPS-080) — so that the decision whether to rotate belongs to the deployment rather than to the implementation.

VTI-CLT-021 — On its first successful authentication, a client SHOULD rotate off its bootstrap identifier onto a newly minted identifier and cause the bootstrap identifier to lose standing.

Rationale. The strength of this recommendation tracks the exposure of the bootstrap identifier. A deployment that delivered the identity inside a sealed provisioning bundle has a defensible reason not to rotate. A deployment whose identifier was pasted into a chat channel, forwarded, and quoted in a ticket does not: that identifier is known to parties whose interest in it is unknown, and it remains the name of a live grant until it is replaced.

Where rotation is performed, it MUST follow the sequence in this section.

§ Mint the replacement

VTI-CLT-022 — The replacement key pair MUST be generated under the same requirements as Step 1 (VTI-CLT-001, VTI-CLT-002, VTI-CLT-006).

§ Prove reachability before committing

VTI-CLT-023 — Where the client will reconnect over a mediated transport, the client MUST establish that the replacement identifier can be reached over that transport before the rotation is committed, within a bounded timeout.

VTI-CLT-024 — A client MUST NOT commit the rotation when reachability under VTI-CLT-023 has not been established.

Rationale. This is not an authorization check: before the rotation the replacement identifier has no entry and cannot authenticate at all. It is a liveness check, and it is placed before the commit because that is the last moment at which failure is free. A rotation committed to an identifier that cannot be reached is unrecoverable — the bootstrap entry is already gone, and the client holds a key nothing will accept. Before the commit, the same failure costs a retry.

§ Swap atomically

VTI-CLT-025 — The rotation MUST be a single operation that moves the existing entry to the new subject. An implementation MUST NOT compose it from a separate grant and revocation.

VTI-CLT-026 — The request MUST carry a proof of control of the replacement identifier that is bound to the node as its audience, is short-lived, and is not replayable.

VTI-CLT-027 — The node MUST verify that the authenticated caller is the current subject of the entry being moved.

VTI-CLT-028 — The node MUST verify that the declared new subject is the holder proven by the accompanying proof.

VTI-CLT-029 — The node MUST preserve the entry’s role, context scope, capability set, key-identifier narrowing, approve scope and expiry exactly. A rotation request that would alter any of them MUST be refused.

VTI-CLT-030 — The node MUST refuse a rotation of an entry whose current subject is not the authenticated caller.

VTI-CLT-031 — On completion, the bootstrap identifier MUST have no standing. A node MUST NOT retain it as a grace-period credential.

VTI-CLT-032 — The node MUST audit the rotation, identifying both the previous and the new subject.

Rationale for VTI-CLT-029 and VTI-CLT-030. A rotation is a change of name, not a change of authority. Together these two make the operation safe to expose to the subject itself — which it has to be, since the point is that the client performs it unattended — by ensuring that the most a caller can do with it is rename its own grant. Without VTI-CLT-029 the operation is a self-service escalation; without VTI-CLT-030 it is a way to take over someone else’s.

§ Commit, then persist, before anything else

VTI-CLT-033 — After the rotation is committed and before performing any other operation, the client MUST persist the replacement key material.

VTI-CLT-034 — A client MUST destroy the bootstrap private key once the rotation has completed and the replacement key material has been persisted.

VTI-CLT-035 — A failure occurring before the commit MUST leave the bootstrap entry authoritative, and the sequence MUST be retryable in full.

Rationale for VTI-CLT-033. Between the commit and the persist, the previous identifier has lost standing while the replacement key exists only in volatile memory. Any work performed in that window — reporting, registration, discovery, anything that can block or crash — risks leaving the operator with no usable credential and no way back. The window cannot be eliminated, so the requirement is that nothing optional is placed inside it.

§ Step 4 — steady-state use

VTI-CLT-040 — A client MUST maintain standing by refreshing its session as specified in the Sessions chapter, and MUST NOT re-enrol as a means of recovering from an expired session.

VTI-CLT-041 — A client MUST NOT treat a previously successful authorization as evidence that a later request is authorized.

VTI-CLT-042 — Where an operation requires re-authentication, a client with a human operator present MUST surface the demand to that operator. A client MUST NOT attempt to satisfy a consent requirement on its own behalf.

VTI-CLT-043 — A client MUST distinguish a refusal from a transport failure, and MUST NOT retry a refusal as though it were one.

VTI-CLT-044 — For an operation classified as requiring an idempotency key, a client MUST hold that key stable across every attempt at the same logical operation, and MUST NOT wrap the retrying layer in a retry loop of its own. See the Operation Surface chapter.

VTI-CLT-045 — A client MUST tolerate bounded clock skew when evaluating credential and token validity, and MUST NOT extend that tolerance to material it produces.

Rationale for VTI-CLT-042. A client that can satisfy a consent requirement is a client for which the requirement does not exist. The requirement’s purpose is that a party other than the caller agreed, and a delegate acting for the caller is not that party.

§ Lifecycle

VTI-CLT-050 — A client MUST support rotating its identifier again at any time, under the requirements of Step 3.

VTI-CLT-051 — A client that discovers its authority has been withdrawn or narrowed MUST stop attempting the affected operations, MUST report the condition to its operator, and MUST NOT attempt to re-enrol automatically.

VTI-CLT-052 — A client identity belongs to exactly one client instance. Key material MUST NOT be shared between instances, copied to another device, or included in a machine image, template or backup from which further instances are created.

VTI-CLT-053 — Removing a client’s entry MUST be sufficient to offboard it, and MUST take effect as required by VTI-ACL-080.

VTI-CLT-054 — A node MUST NOT move an entry to a new subject without a proof of control from that subject. Recovery of a lost client key MUST be performed by enrolling a new identifier.

Rationale for VTI-CLT-052. A shared identity cannot be revoked per instance: withdrawing it stops every instance that holds it, so the operator facing one compromised host is choosing between an outage and leaving the compromise in place. It is also a durable correlator across every device carrying it, which defeats the context boundary the rest of this model rests on.

Machine images are named explicitly because sharing is rarely a decision. An image captured after enrolment carries the key, and every instance started from it is the same subject as far as the node is concerned.

Rationale for VTI-CLT-054. An administrative move without proof of control is a way to hand a grant to a subject that never asked for it and cannot be shown to control it, which is the same power as forging the client. Deleting the entry and enrolling the replacement produces the same operational outcome with an audit trail that says what actually happened.

§ Client conformance checklist

An implementer of a client target satisfies this chapter by implementing, in order:

A node target additionally implements VTI-CLT-010 – VTI-CLT-012, VTI-CLT-014, VTI-CLT-020, VTI-CLT-027 – VTI-CLT-032, VTI-CLT-053 and VTI-CLT-054.

Sequence diagrams, a worked example and test vectors — including the failure cases either side of the commit point — appear in Appendix A.

§ Operation Surface

This section is normative.

§ In plain terms

A node has one front door.

Every operation it offers is a defined task with a name, a shape and a stated authority, and the different transports — a web request, a message, whatever comes next — are doors into the same building rather than separate premises with separate rules. When a node grows a second, private way in, everything written about the first has to be written again about the second, by someone who may not know it exists.

That is also why the pieces tasks are built from are defined once: a page cursor, a refusal, a timestamp. Left to themselves they start identical and drift apart, and a rule stated about “the cursor” quietly becomes true of four cursors out of six.

§ What this chapter defines

Everything a VTI node exposes, it exposes as a trust task. This chapter defines that surface: the catalogue as the API, the components every task is built from, how transports bind to it, how versions are selected, and what a caller may conclude when a reply does not arrive.

§ The catalogue is the API

VTI-OPS-001 — Every operation this specification requires of a node MUST be exposed as a Trust Task drawn from the canonical catalogue.

VTI-OPS-002 — A node MUST NOT expose a second, parallel interface for an operation the catalogue already defines. There is no REST API, DIDComm protocol or TSP protocol beside the task catalogue; each is a binding of it.

VTI-OPS-003 — A node MAY define a private task for an operation only where no canonical task covers it.

VTI-OPS-004 — Where a node carries both a private task and a canonical task for the same operation, the canonical task MUST be authoritative and the node MUST publish a retirement path for the private one.

VTI-OPS-005 — A node MUST make the tasks and versions it serves discoverable, and the discovery response MUST itself be a task.

VTI-OPS-006 — Where a privately defined operation is of general applicability, its definer SHOULD propose it to the canonical catalogue.

Rationale. One API surface is worth more than the sum of three good ones. Where a node grows an endpoint beside a task, the two acquire separate authorization paths, separate error vocabularies, separate versioning and separate tests — and the security argument then has to be made twice, by two people who do not necessarily agree. Every requirement in this specification about authorization, approval, idempotency and refusal is written once, against the task; making the task the only surface is what causes those requirements to hold on every path into the node rather than on the paths somebody remembered.

The consequence for implementers is deliberate. Adding an operation means adding it to the catalogue, and adding it to the catalogue means writing down its payload, its refusals, its retry class and the authority it needs. An operation that is not worth that is not worth exposing.

§ Requirements on a private task

VTI-OPS-007 — A private task MUST be identified within a namespace its definer controls, so that it cannot collide with a canonical task defined later.

VTI-OPS-008 — A private task MUST use the shared components defined below, and MUST follow the envelope, refusal, versioning and retry requirements of this chapter.

VTI-OPS-009 — A private task MUST be discoverable under VTI-OPS-005, so that a peer can determine what a node offers without attempting each operation.

Rationale. A private task is a staging post, not a destination. The requirements above are what make it one: it is visible, it behaves like everything else, and its name cannot become an obstacle to the canonical definition that replaces it.

§ Extension rather than divergence

VTI-OPS-010 — A node MUST NOT add a member to a canonical task payload. A canonical payload is closed, and a member outside the definition MUST be refused.

VTI-OPS-011 — Where a canonical task defines an extension slot, a node MAY carry ecosystem-defined content in that slot, and a receiving node MUST NOT refuse a document solely because the slot is populated.

VTI-OPS-012 — A node MUST NOT derive authority from the content of an extension slot. See VTI-ACL-005.

Rationale. Keeping the payload closed while admitting a declared extension slot preserves the property that a misspelled member is refused rather than ignored, which is the guard the closure exists for. Adding a top-level member locally has the opposite effect on both counts: it is invisible to the peer that does not know it, and it makes the misspelling of it indistinguishable from a deliberate extension. Where a canonical task is nearly right, the correct response is a proposal to the catalogue, not a local member — and the difference is not stylistic: a member added locally means the two ends no longer agree about what a conforming document is.

§ The operation document

VTI-OPS-020 — An operation document MUST identify the operation, the issuer, the intended recipient, and the time of issue, and MUST carry a proof by the issuer.

VTI-OPS-021 — A node MUST apply the same document requirements on every transport. A transport that authenticates its sender MUST NOT be treated as relieving a producer of addressing or signing the document it sends.

VTI-OPS-022 — A receiving node MUST verify that the proof covers every member it acts on, and MUST refuse a document where it does not.

VTI-OPS-023 — A receiving node MUST verify that it is the intended recipient, and MUST refuse a document addressed elsewhere.

VTI-OPS-024 — A node MUST refuse a document whose time of issue lies outside its acceptance window.

Rationale for VTI-OPS-021. Transport-level sender authentication and document-level proof answer different questions. The first says who opened this connection; the second says who authored this document, what it covers, and to whom it was addressed. Only the second survives the message being stored, forwarded, replayed on another transport, or produced in evidence afterwards.

Making the requirement uniform across transports is what keeps the security argument uniform. Where a document is signed on one transport and merely authenticated on another, the deployment’s real guarantee is the weaker of the two, and which transport carries it is not recorded anywhere. See Appendix F.

§ Replay

VTI-OPS-025 — Every operation document MUST carry an identifier unique to that document.

VTI-OPS-026 — A node MUST refuse a document whose identifier it has already accepted within the acceptance window of VTI-OPS-024.

VTI-OPS-027 — The record of accepted document identifiers MUST be shared across every binding a node exposes. A document accepted on one binding MUST NOT be acceptable on another.

Rationale. Signing a document makes it durable evidence of intent, and durable evidence is replayable unless something remembers it. The acceptance window bounds how long the record must be kept; the identifier is what makes the record possible.

VTI-OPS-027 closes the case a per-binding implementation misses. A document captured from one binding — a log, a proxy, a stored message — is a well-formed, correctly signed, correctly addressed document, and the second binding has no reason to doubt it. Where the two bindings do not share a record, the node’s replay protection is exactly as good as its least-used transport.

§ Responses and refusals

VTI-OPS-030 — A response MUST conform to the response definition of the task it answers.

VTI-OPS-031 — A conformance assessment MUST validate responses as well as requests.

VTI-OPS-032 — A refusal MUST carry a machine-readable reason drawn from the defined set for the operation.

VTI-OPS-033 — Where a condition has no defined code, the refusal MUST carry a machine-readable discriminator in its details rather than being reported only as a generic failure.

VTI-OPS-034 — A refusal MUST be distinguishable by a caller from a transport failure and from a delivery failure.

VTI-OPS-035 — A refusal MUST NOT disclose information the caller is not authorized to learn. In particular, a refusal MUST NOT reveal the existence of a subject, a context, a credential or an entry to a caller with no authority over it.

Rationale for VTI-OPS-035. A refusal is an answer, and a pair of refusals that differ tells the caller something even when neither says anything. The common form is a lookup that distinguishes not found from not permitted, which turns an authorization boundary into a directory.

Rationale for VTI-OPS-031. A conformance check that validates only what an implementation sends measures its own fixtures rather than the service under test: the requests were built by the same codebase the check is meant to assess, so agreement between them establishes nothing. A response is the half a peer depends on, and it is the half no producer-side test exercises.

Rationale for VTI-OPS-033. “Not found” is the recurring example: a framework that defines no code for it leaves an implementation reporting it as a generic failure, which a caller cannot distinguish from a genuine error, so callers either treat a normal condition as an outage or paper over real ones.

§ Shared components

A task definition is assembled from components defined once and referenced by every task that needs them:

VTI-OPS-070 — A task definition MUST express these concepts by reference to the shared component, and MUST NOT restate or redefine one.

VTI-OPS-071 — A node MUST NOT accept a task-local variant of a shared component. A document carrying one MUST be refused.

VTI-OPS-072 — A concept that appears in more than one task MUST be promoted to a shared component before the second task is published.

VTI-OPS-073 — A change to a shared component is a change to every task that references it, and MUST be versioned as such.

Rationale. The failure this prevents is silent divergence between two definitions of one idea. Where each task carries its own notion of a cursor, a refusal or a time, they begin identical and drift: one gains a binding rule, another gains a timezone, a third gains a member the others treat as unknown. Consumers then need per-task handling for concepts that are not per-task, and a security rule stated about “the cursor” turns out to hold for four cursors out of six.

VTI-OPS-072 is what keeps the component set honest. The second occurrence is the moment a concept is shown to be general, and the last moment at which promoting it is cheap.

§ The required catalogue

VTI-OPS-080 — A conforming node MUST expose the operations listed for its profile below. The canonical identifier and payload of each is defined by the catalogue specification; this table states which operations a node is required to have.

Core — every node:

Delivery — every node that sends:

Community — a VTC:

VTI-OPS-081 — A node MUST refuse an operation it does not serve using the refusal component, naming the condition. It MUST NOT fail silently and MUST NOT allow the request to fail by timeout.

VTI-OPS-082 — A node MAY expose further catalogue tasks beyond those required for its profile.

VTI-OPS-083 — Every operation in the catalogue MUST state, as part of its definition, the authority its caller needs: the capability or role, and the context that authority must cover.

VTI-OPS-084 — Every operation MUST state its retry class, per VTI-OPS-060.

Rationale for VTI-OPS-083. An operation whose authority requirement lives only in an implementation cannot be reviewed, cannot be tested by a party without the source, and cannot be relied on by a peer. Stating it in the definition makes the authorization surface of a node readable from the catalogue it claims to serve — which is also what allows VTI-OPR-050’s questions to be answered without reading code.

§ Transport bindings

VTI-OPS-090 — A transport binding MUST define how the envelope, the refusal and the payload map onto that transport, and MUST NOT define operations of its own.

VTI-OPS-091 — A binding MUST NOT add, remove or rename a member of a task’s payload or response.

VTI-OPS-092 — The same task invoked under the same authority MUST produce the same authorization decision and the same refusal on every binding, as required by VTI-TRN-002.

VTI-OPS-093 — A binding MUST NOT weaken the document requirements of this chapter on the basis of a property of the transport, as required by VTI-OPS-021.

VTI-OPS-094 — Where a binding cannot represent a component faithfully, the binding MUST be documented as not supporting the tasks that use it, rather than representing it approximately.

Rationale. A binding is a mapping, not a dialect. Once a binding may add a parameter, that parameter exists only for callers of that binding: it either carries no authority, in which case it is noise, or it carries authority peers on other bindings cannot express, which makes a node’s behaviour depend on how its caller arrived.

§ The catalogue and its registries

Task identifiers, capability names and refusal codes are extension points. Extensibility without a registration policy produces collisions and private forks, so each has one.

VTI-OPS-100 — A canonical task identifier, capability name or refusal code MUST be registered before use. Registration MUST record the name, its meaning, the specification defining it, and its status.

VTI-OPS-101 — Registration of a canonical name MUST require a published specification of the thing named.

VTI-OPS-102 — A private name MUST be namespaced under a domain its definer controls, and MUST NOT be registered as canonical.

VTI-OPS-103 — A registered name MUST NOT be reused with a different meaning. A name that falls out of use MUST be marked retired and MUST retain its meaning.

VTI-OPS-104 — A consumer MUST NOT treat an unregistered name as equivalent to a registered one, and MUST NOT grant authority on the strength of an unrecognised capability name, per VTI-ACL-032.

Rationale. The registries are where this specification’s extension points either stay coherent or quietly stop meaning anything. Requiring a specification for a canonical name keeps the catalogue reviewable; requiring a namespace for a private one lets an implementation move quickly without taking a name someone else will need; and prohibiting reuse means a consumer built years after a producer can still rely on what a name meant.

§ Versioning and negotiation

VTI-OPS-040 — An operation identifier MUST carry a major and a minor version.

VTI-OPS-041 — A change that alters what a conforming peer accepts or produces MUST increment the major version. This applies at every version number: there is no exemption for versions below 1.0.

VTI-OPS-042 — A change to the permitted values of a member is a change of the kind described in VTI-OPS-041, whether or not the shape of the payload changes.

VTI-OPS-043 — A node MUST publish the versions of each operation it serves.

VTI-OPS-044 — A caller MUST select a version served by both peers, and where several are available SHOULD select the highest.

VTI-OPS-045 — A node that receives an operation at a version it does not serve MUST refuse it explicitly, naming the versions it does serve. It MUST NOT allow the request to fail by timeout.

VTI-OPS-046 — A caller MUST NOT select a version on the basis of an unauthenticated discovery response.

VTI-OPS-047 — A node MUST maintain a minimum acceptable version for each operation, MUST refuse a version below it, and MUST NOT negotiate below it on the request of a peer.

Rationale for VTI-OPS-046 and VTI-OPS-047. Negotiation selects the version both parties can speak, which means an attacker who can influence what a peer appears to speak selects it instead. Authenticating the discovery response removes the first half; a floor that a peer cannot argue a node below removes the second. Without the floor, retiring a version is advisory: every peer that claims not to have upgraded is served anyway, which is precisely the claim an attacker makes.

Rationale for VTI-OPS-041 and VTI-OPS-042. Negotiation is tractable only where a version number carries a promise. Semantic versioning below 1.0 makes no promise — correctly, by its own definition — so a catalogue following it faithfully can ship a breaking wire change as a minor increment, and a peer that trusted the increment has no way to discover this except by failing.

VTI-OPS-042 exists because the compatibility question is about accepted values, not about shapes. Renaming the permitted values of a member leaves the payload structurally identical: no schema comparison flags it, and every peer built against the previous set fails on it. A contract that covers only structure covers the easy half.

Rationale for VTI-OPS-045. Where the unsupported version is not refused explicitly, an asynchronous transport turns it into a timeout with no explanation — an outcome the caller cannot distinguish from an unreachable peer, and the most expensive way to learn that two versions did not match.

§ The policy gate

VTI-OPS-050 — A node MUST evaluate the approval and step-up rules that apply to an operation before the operation’s handler runs, and MUST reach the same decision on every transport. See VTI-APV-002.

VTI-OPS-051 — A node MUST NOT rely on a handler to enforce a requirement that the policy gate is specified to enforce.

Rationale. A requirement enforced in the handler is enforced once per handler, which means it is enforced everywhere it was remembered. Moving it in front of the dispatch makes the enforcement structural, so a new operation is gated because of where it sits rather than because its author recalled the rule.

§ Retry, idempotency and the cost of a lost reply

A request that times out has usually not arrived, and retrying is correct. Sometimes it arrived, was performed, and only the reply was lost — and there a retry produces a second durable effect that nobody is watching for.

VTI-OPS-060 — Every operation MUST be classified by what a repeat of it costs, using at least the following distinctions: no durable effect; a durable effect whose repeat is harmless; and a durable effect whose repeat leaves a second artefact that persists and matters.

VTI-OPS-061 — An operation in the third class MUST accept an idempotency key, and a node MUST perform such an operation at most once per key.

VTI-OPS-062 — An operation that is not classified MUST be treated as belonging to the third class.

VTI-OPS-063 — Exactly one layer MUST own retry for a given failure domain. Application code above a retrying client MUST NOT add a retry loop of its own.

VTI-OPS-064 — Every attempt at one logical operation MUST carry the same idempotency key.

VTI-OPS-065 — A node MUST be able to return the result of a completed keyed operation to a caller that repeats it with the same key, rather than refusing the repeat.

Rationale for VTI-OPS-062. Classification is a judgement made when an operation is defined, and an unclassified operation is one whose author did not make it. Treating it as the most costly class is the direction whose error is cheap: over-classifying costs one deduplication record, and under-classifying loses the protection in exactly the rare case the classification exists for.

Rationale for VTI-OPS-063 and VTI-OPS-064. Uncoordinated retry layers multiply — three application attempts over three transport attempts is nine executions — and a hand-written loop at the application layer is worse than redundant, because it cannot hold a key stable. It re-invokes a client method, which builds a fresh document with a fresh key, which is a different operation as far as the node is concerned. It converts one operation retried into several operations performed, which is the precise failure the key exists to prevent.

§ Composing an operation

The requirements above compose into one rule worth stating on its own: a new operation is defined by naming it in the catalogue, assembling its payload from shared components, stating the authority it requires and its retry class, and publishing the versions a node serves. Nothing about it is decided at the transport, and nothing about it is decided in an implementation.

VTI-OPS-110 — A node MUST NOT expose behaviour that is not attributable to a defined operation. An input that changes what a node does MUST be part of a task’s payload, and MUST be documented, versioned and authorized as such.

Rationale. Undocumented inputs — a header a proxy adds, a query parameter one binding accepts, an environment variable that changes an authorization outcome — are the surface no review covers, because they belong to no definition. This requirement puts them inside the model or removes them, and the configuration form of the same hazard is covered by VTI-CMP-090.

§ Credentials and Presentations

This section is normative.

§ In plain terms

A credential is a letter someone signed about somebody else.

Checking the signature tells you the letter is genuine and unaltered. It does not tell you three things you probably wanted to know: whether the signer was entitled to write it, whether they still are, and whether the person handing it to you is the person it was written about.

The last of those is why presenting a credential is a conversation rather than a delivery. The verifier picks a fresh number, the holder proves control of the subject over it, and only then does the letter count for anything. Without that step a credential is a bearer token: whoever picks it up — from a log, a relayed message, a stolen laptop — can present it as their own.

§ What this chapter defines

This chapter binds the DTG VC specifications to VTI’s requirements. It does not restate credential data models: it states what a VTI node does when it issues, holds, presents or verifies one.

§ Issuance

VTI-CRD-001 — An issuer MUST hold authority to issue in the context the credential belongs to.

VTI-CRD-002 — A credential MUST identify its issuer by a resolvable identifier, and a verifier MUST resolve it rather than relying on a name carried in the credential.

VTI-CRD-003 — A credential MUST identify its subject in a form that permits a verifier to establish, at presentation, that the presenter controls it.

§ Status and revocation

VTI-CRD-010 — A credential whose validity can change during its lifetime MUST carry a status mechanism.

VTI-CRD-011 — A verifier MUST check status before relying on such a credential.

VTI-CRD-012 — Where status cannot be determined, the outcome MUST be indeterminate as required by VTI-CMP-080, and MUST NOT default to valid or to revoked.

VTI-CRD-013 — A status mechanism MUST NOT require a query that identifies the individual credential or its subject to the party answering it.

VTI-CRD-014 — The set a status query is answered over MUST be large enough that observing the query does not identify the subject, and an issuer MUST NOT allocate that set in a way that reconstructs the identification — by issuing a set per subject, per cohort, or in an order that follows issuance.

Rationale for VTI-CRD-013. A status check that names the credential tells the issuer, on every use, which of its subjects is transacting and roughly with whom. The privacy cost is paid by the subject and collected by the issuer, and it accrues precisely because the verifier did the responsible thing.

§ Presentation

VTI-CRD-020 — A presentation MUST name its audience, and the audience MUST be the party the presentation is made to.

VTI-CRD-021 — A verifier MUST establish that the presenter controls the subject of each credential presented. A binding declared in the payload MUST NOT be accepted in place of one established by the protocol.

VTI-CRD-022 — The verifier MUST issue a single-use challenge bound to itself, and MUST refuse a presentation whose holder proof does not commit to that challenge.

VTI-CRD-023 — A credential or set of credentials MUST NOT be accepted as evidence of the presenter’s identity without the proof of possession required by VTI-CRD-021 and VTI-CRD-022.

Rationale. Without proof of possession, a credential is a bearer token: anyone who captures it — from a relayed exchange, an audit log, a compromised device — holds a replayable impersonation of its subject. The credential formats do not make this mistake; compositions do, by treating a valid signature over a valid credential as though it were an authenticated session.

§ What verification establishes

VTI-CRD-030 — Successful verification MUST be treated as establishing the provenance and integrity of the credential at the time it was issued, and nothing further. See VTI-CMP-030.

VTI-CRD-031 — Where a relying decision depends on the issuer’s authority at the time of the decision, the verifier MUST establish that separately, as required by VTI-CMP-032.

§ Minimisation

VTI-CRD-040 — A verifier MUST NOT require disclosure beyond what the relying decision needs.

VTI-CRD-041 — Where a credential supports selective disclosure, a holder SHOULD present only the attributes the decision requires, and a verifier MUST NOT refuse a presentation solely because it was selectively disclosed.

VTI-CRD-042 — A verifier MUST NOT retain presented attributes beyond what the decision and its audit record require.

VTI-CRD-043 — A verifier MUST NOT disclose presented attributes, or the fact of a presentation, to a third party except where the decision requires it and the holder was told so before presenting.

Rationale for VTI-CRD-014. A status list is a privacy measure only while the crowd is real. An issuer that allocates a list per subject, or allocates sequentially so that position implies issuance time, has built a mechanism with the shape of herd privacy and the behaviour of a unique identifier — and the verifier doing the responsible thing is the one generating the signal.

§ The Verifiable Trust Agent

This section is normative.

§ In plain terms

A VTA is the safe, and the person who operates it on your behalf.

It holds the keys, so the first rule is that the keys do not leave: a caller asks it to sign something rather than asking for the key to sign with. That difference is what makes withdrawing access mean anything — take away a key someone is holding and they still have it, while taking away permission to ask takes effect immediately.

It also delegates. An assistant acting for you gets its own identity, its own narrow permissions and its own record, rather than borrowing yours. An assistant using your credentials is not a delegate; it is a copy of you, and you cannot revoke it without revoking yourself.

§ What this chapter defines

This chapter specifies what a VTA does beyond the common model. It is the key, credential and authority root for its principal, and every requirement here follows from something else in a deployment depending on that.

§ Custody

VTI-VTA-001 — A VTA MUST hold its root derivation material within a protection boundary, and MUST NOT export it other than through the backup mechanism specified in this chapter.

VTI-VTA-002 — A VTA MUST perform key operations on behalf of an authorized caller rather than exporting the key for the caller to use.

VTI-VTA-003 — Where a VTA supports exporting derived key material, that export MUST be gated by a capability distinct from the capability to use the key, and MUST be audited.

Rationale. The distinction in VTI-VTA-002 is what makes revocation meaningful. A caller that holds a key retains it after its authority is withdrawn; a caller that can ask for an operation loses the ability at the moment the entry changes.

§ The signing oracle

A VTA signs on behalf of its principal at the request of a delegate. What it agrees to sign is therefore an authorization decision, not a cryptographic one.

VTI-VTA-004 — A VTA MUST NOT sign material whose structure it cannot parse and constrain. A request to sign opaque octets MUST be refused.

VTI-VTA-005 — Before signing, a VTA MUST verify that the material is well-formed for its stated type, that its stated issuer is the principal, and that its audience and subject are within what the requesting entry authorizes.

VTI-VTA-006 — A VTA MUST record what it signed, for which caller, under which authority.

VTI-VTA-007 — A capability to request signing of a constrained document type MUST be distinguishable from a capability to request signing generally, and a node MUST NOT satisfy a request of the second kind under a grant of the first.

Rationale. A signing oracle that will sign anything is a general-purpose forgery service for its principal, reachable by whichever delegate holds the capability. The constraint is what makes delegation to an agent survivable: a compromised agent can produce documents of the shapes it was authorized to produce, addressed to the parties it was authorized to address, and nothing else. Blind signing removes every one of those bounds at once, and does so invisibly, because the resulting signature is indistinguishable from an intended one.

§ Credentials held for the principal

VTI-VTA-010 — Every credential a VTA holds MUST belong to a trust context.

VTI-VTA-011 — The ability to receive a credential and the ability to remove one MUST be separately gated.

VTI-VTA-012 — A VTA MUST NOT present a credential on the principal’s behalf except under authority that covers both the credential’s context and the act of presenting.

Rationale for VTI-VTA-011. Receiving a credential adds to what a principal holds; removing one destroys evidence the principal may need. A consumer that should be able to do the first is not thereby a consumer that should be able to do the second.

§ Context and key authority

VTI-VTA-020 — A VTA MUST be the only node that creates trust contexts and derives keys for its principal, as required by VTI-ACL-090.

§ Provisioning integrations

A VTA provisions the identities of the infrastructure its principal depends on — mediators, hosts, agents — and hands each one its key material.

VTI-VTA-030 — Private key material for a provisioned identity MUST be delivered sealed to the holder, such that a party relaying it cannot read it.

VTI-VTA-031 — A provisioning bundle MUST be accompanied by a verification value transmitted over a channel distinct from the bundle, and the holder MUST verify it before use.

VTI-VTA-032 — Provisioning MUST NOT confer authority. Any authority the provisioned identity is to hold MUST be recorded as an access control entry.

Rationale for VTI-VTA-031. Sealing protects the material from the relayer; it does not tell the holder that the bundle they opened is the one that was sealed for them. The second channel is what closes that, and it is required rather than recommended because the relaying party is precisely the party in a position to substitute.

§ Delegation to software agents

VTI-VTA-040 — A software agent acting for the principal MUST have its own identifier and its own access control entry, and MUST NOT operate under the principal’s own credential.

VTI-VTA-041 — An agent SHOULD be scoped to a trust context of its own.

VTI-VTA-042 — A VTA MUST provide a means of immediately withdrawing an agent’s authority, and that means MUST cover every grant within the agent’s scope, as required by VTI-ACL-081 and VTI-ACL-082.

VTI-VTA-043 — Every action a VTA performs at an agent’s request MUST be recorded such that the principal’s operator can observe what the agent did.

Rationale for VTI-VTA-040. An agent operating under the principal’s own credential cannot be revoked without revoking the principal, cannot be distinguished from the principal in any audit trail, and cannot be narrowed. It is not a delegate; it is a copy.

§ Backup, restore and succession

VTI-VTA-050 — A backup MUST be encrypted, and MUST NOT be usable without material held separately from it.

VTI-VTA-051 — A restore MUST be recorded in the audit trail, and a node MUST be able to report that its current state derives from a restore and from when.

VTI-VTA-052 — Where a VTA supports succession — the transfer of control to another party on the principal’s incapacity — the process MUST require authority at least equal to the authority it confers, and MUST be auditable after the fact by the receiving party.

Rationale for VTI-VTA-051. A restore silently reinstates authority as it stood at the time of the backup, including entries revoked since. Recording the restore is what allows the difference to be reconciled deliberately rather than discovered later as a grant nobody remembers making.

§ The operator surface

VTI-VTA-060 — An operator MUST be able to enumerate every access control entry, every delegated agent and every active session on their VTA.

VTI-VTA-061 — An operator MUST be able to terminate any session and withdraw any entry.

VTI-VTA-062 — Every action a VTA performs on the principal’s behalf MUST be recorded such that the operator can observe it.

Rationale. An action that cannot be observed cannot be governed, and a control the operator cannot reach is a control that belongs to whoever operates the software rather than to the principal it acts for.

§ The Verifiable Trust Community

This section is normative.

§ In plain terms

A community is a club, and a VTC is its membership secretary.

It decides who joins, records who is currently in good standing, and tells other clubs what it will vouch for. What it deliberately does not do is hold the members’ keys: those belong to each member’s own agent. A compromised secretary can wrongly admit someone, wrongly expel someone, and wrongly vouch for a stranger — all serious, and all recoverable. A secretary who held everyone’s keys would be a different kind of disaster.

That division is the reason this chapter spends its time saying which decisions belong to the community and which to the agent underneath it. A decision with two plausible owners is a decision that gets made twice, differently.

§ What this chapter defines

This chapter specifies the community node: what it is, how it is stood up, and which authority decisions belong to it rather than to the VTA beneath it.

§ Provisioning and dependency

VTI-VTC-001 — A VTC MUST be provisioned on an existing VTA and MUST derive its identity from it.

VTI-VTC-002 — The dependency MUST be one-way. A VTA MUST NOT require a VTC in order to operate.

VTI-VTC-003 — A VTC’s identifier MUST be resolvable by a party with no prior relationship to the community, using a method satisfying VTI-KEY-001.

§ Which authority lives where

VTI-VTC-010 — A VTC MUST NOT create trust contexts and MUST NOT derive keys. See VTI-ACL-090.

VTI-VTC-011 — Where a VTC references context identifiers, it MUST evaluate them using the ancestry predicate defined in the Trust Contexts chapter.

VTI-VTC-012 — A VTC owns the following decisions and no others in this specification: admission to the community; the membership state of a member; recognition of another community; and what the community publishes.

VTI-VTC-013 — A VTC MUST NOT make key-custody decisions for its members. A member’s keys are the concern of that member’s VTA.

Rationale. The division is not arbitrary: the VTA holds the material whose compromise is unrecoverable, and the VTC holds the relationships that can be re-established. Keeping the two apart means a compromised community can wrongly admit, wrongly remove and wrongly recognise — all serious, all recoverable — and cannot take a member’s keys.

§ The community authority model

VTI-VTC-020 — A VTC MUST express its own roles, capabilities, approve scope and approval rules using the model defined in the Trust Contexts chapter, and MUST NOT define a parallel model.

VTI-VTC-021 — An administrative action on the community MUST be subject to the approval requirements of that chapter.

§ Governance binding

VTI-VTC-030 — A governance framework MAY impose requirements stricter than this specification, and MUST NOT reduce any requirement of it.

VTI-VTC-031 — Where community policy is expressed as a credential or other verifiable artefact, a VTC MUST verify it before applying it, and MUST record which version of it governed a decision.

VTI-VTC-032 — A change to community policy that alters trust, privacy, authority or security semantics is subject to VTI-CMP-090.

Rationale for VTI-VTC-031. Policy is the input that decides every other decision, and a deployment that cannot say which policy governed a past admission cannot explain that admission afterwards. Recording the version is what turns “the policy allowed it” from an assertion into a checkable claim.

§ The Verifiable Trust Network

This section is normative, and specifies a node that has no implementation at the time of publication. The requirements are stated so that a first implementation has something to build against. One structural question — whether a VTN is a distinct node type or a VTC operating in a curation role — is open, and is recorded at the end of the chapter rather than settled in it.

§ In plain terms

A VTC is a club. A VTN is the association the clubs are listed in.

Two things separate the association from the club. It works at a coarser grain: a club decides about people one at a time, an association points at whole clubs. And it can point without being pointed back at — putting a club on the list is something the association does by itself, where joining a club is something two parties agree to.

The Internet has the same shape one layer down. An operator decides which machines are on its network. An autonomous system decides which networks it will carry and announce to everybody else, and the announcement is the operator’s to make. A VTN occupies the second position: it is the unit at which whole communities are aggregated, announced and found.

That is the whole of it. A VTN curates. Everything below is about what a curated list may and may not be taken to mean.

§ What this chapter defines

This chapter specifies the network node: what it aggregates, what its published set establishes and what it does not, how networks nest and overlap, and where the authority boundary runs between a network and the communities in it. An entry in a network’s published set is a listing, and most of what follows is about what one does and does not assert.

It defines no new authority model, publication mechanism or credential family. A VTN uses the model in the Trust Contexts chapter, publishes under the Trust Registries chapter, and issues and presents under the Credentials chapter.

§ Position in the architecture

A VTN sits above the VTC in aggregation, not in authority. It is not a parent of the communities it lists. It grants them nothing, and removing a community from its list takes nothing away from that community’s members. The two axes are independent, and everything a network is good for lives on the first one.

What it is good for is discovery at scale. Without a network layer, every relying party that wants to know about many communities keeps its own list, and a community that wants to be found is found only by parties that already know it. Cross-community recognition solves this pairwise, and pairwise does not scale: n communities is n² relationships, and VTI-REG-024 deliberately refuses the shortcut of making them transitive. A VTN is the other way to make it scale — one curated set, with an owner accountable for it — and it makes discovery cheap without making recognition transitive.

§ Ownership and governance

VTI-VTN-001 — A VTN MUST be provisioned on an existing VTA and MUST derive its identity from it.

VTI-VTN-002 — A VTN MUST have an identified owner, and MUST publish a governance framework stating the criteria for listing, the criteria for removal, and the means by which a listed party may contest an entry concerning it.

VTI-VTN-003 — A VTN’s identifier MUST be resolvable by a party with no prior relationship to the network, using a method satisfying VTI-KEY-001.

VTI-VTN-004 — A VTN MUST express its own roles, capabilities, approve scope and approval rules using the model defined in the Trust Contexts chapter, and MUST NOT define a parallel model.

VTI-VTN-005 — An administrative action on the network MUST be subject to the approval requirements of that chapter.

Rationale for VTI-VTN-002. A curated set is a published assertion about other parties, made without their agreement. The owner is what makes such an assertion contestable: a list nobody owns is a list nobody can be asked to correct, and an uncontestable assertion about a third party is one that party has no defence against. The criteria matter for the same reason — a removal that cannot be checked against a stated rule is indistinguishable from a removal made for any other reason.

§ Curation is one-sided

VTI-VTN-010 — A VTN MAY list a VTC or another VTN without the agreement of the listed party.

VTI-VTN-011 — Every published entry MUST state whether the listed party has acknowledged it. An entry that has not been acknowledged MUST be published as unacknowledged.

VTI-VTN-012 — A VTN MUST provide a means by which a listed party can acknowledge or repudiate an entry concerning it, and MUST publish a repudiation it has received alongside the entry.

VTI-VTN-013 — A VTN MUST NOT describe an unacknowledged entry as membership, and MUST NOT issue a membership credential to a party that has not acknowledged its entry.

VTI-VTN-014 — Where membership of a VTN is two-sided, it MUST follow the Membership Lifecycle chapter: admission is a decision, evidenced by a credential, with states, audit and departure dispositions as required there.

Rationale for VTI-VTN-011. One-sidedness is what makes a network useful — a curator who has to negotiate every entry curates nothing — and it is also what makes a network’s list easy to misread. They list us and we joined are different facts about different numbers of parties, and a consumer who cannot tell them apart will read the weaker as the stronger every time, because the stronger is what a list normally means. Publishing the distinction costs one field. Recovering it afterwards is impossible.

Rationale for VTI-VTN-012. A party listed against its wishes has two remedies: argue with the owner, or say publicly that it does not accept the entry. Requiring the network to publish repudiations keeps the second remedy inside the system, where a consumer resolving the entry will see it, rather than leaving it to be conducted in announcements that nobody resolving an entry ever reads.

§ What a listing establishes

VTI-VTN-020 — Presence in a VTN’s published set MUST NOT be treated as evidence of current authority. VTI-REG-010 binds a network’s answers as it binds any other registry answer.

VTI-VTN-021 — A consumer MUST determine whether an entry is acknowledged before relying on it, and MUST NOT treat an unacknowledged entry as an acknowledged one.

VTI-VTN-022 — Listing MUST NOT be transitive with recognition. A party that recognises a VTN MUST NOT thereby recognise the parties that VTN lists, and a party listed by a VTN MUST NOT thereby recognise the others it lists. See VTI-REG-024.

VTI-VTN-023 — A party MAY adopt a policy of extending recognition to the parties a VTN lists. Such a policy MUST be explicit, MUST name the network and the version of its governance framework relied on, and MUST NOT be inferred from the existence of the listing.

VTI-VTN-024 — A VTN’s answers MUST satisfy VTI-REG-002, VTI-REG-011 and VTI-REG-012: the framework identified, the determination time carried, and unavailability treated as indeterminate rather than as absence.

Rationale for VTI-VTN-022 and VTI-VTN-023. A network creates exactly the temptation that VTI-REG-024 refuses — one relationship standing in for a hundred. These two requirements keep the convenience and refuse the inference. A relying party may still decide, in a single act, to accept everything a network lists; the difference is that it is a decision, it names what it rests on, and it can be withdrawn when the network’s framework changes. An inference cannot be withdrawn, because nobody recorded making it.

§ Networks of networks

VTI-VTN-030 — A VTN MAY list other VTNs. This specification imposes no limit on the depth of nesting.

VTI-VTN-031 — Every entry MUST identify the kind of the listed party — community or network — so that a consumer can tell whether the entry points at members or at further entries.

VTI-VTN-032 — Nesting MUST NOT alter what an entry establishes. A consumer resolving through a chain of networks MUST evaluate the acknowledgement state of each entry in the chain, and MUST NOT infer the state of one entry from another.

VTI-VTN-033 — A VTN that lists another network MUST NOT represent that network’s entries as its own.

Rationale. Three levels — state networks aggregated nationally, national networks aggregated globally — is the obvious structure and probably the common one, and it is also where flattening happens. By the time an entry has been through three aggregations it reads as a single global assertion with one name on it, and the three owners, three frameworks and three acknowledgement states behind it have disappeared. Keeping each step’s own owner and own acknowledgement state visible is what keeps a global network a list of lists rather than a claim.

§ Overlapping networks

VTI-VTN-040 — A VTC or a VTN MAY be listed by any number of networks. A VTN MUST NOT require, as a condition of listing or of membership, that a party not be listed elsewhere.

VTI-VTN-041 — A consumer MUST NOT treat listing by more than one network as a conflict, and MUST NOT treat listing by several networks as stronger evidence than listing by one unless it has established that those networks are independent, as required by VTI-CMP-071.

Rationale. Overlap is the expected condition rather than a defect: nothing stops three parties each curating a set for the same subject, and the ordinary outcome is three networks with different criteria, different owners and substantially the same members. Counting them is where it goes wrong. Networks that list each other’s members, or that share a secretariat and a governance framework, are one opinion published three times, and a relying party that adds them up has manufactured corroboration out of duplication — the failure VTI-CMP-070 describes.

§ Credentials a network issues and receives

VTI-VTN-050 — A VTN MAY issue and receive DTG credentials, including membership and endorsement credentials, and MUST issue, hold and present them under the Credentials chapter.

VTI-VTN-051 — An endorsement credential MUST state what is endorsed, under which governance framework and version, and for what period.

VTI-VTN-052 — An endorsement MUST NOT confer authority. A consumer MUST NOT infer from an endorsement any capability, role or scope in the endorsing network or in any party it lists.

VTI-VTN-053 — Removal of a party from a network MUST be reflected in the status of any credential the network issued to evidence the entry, and MUST take effect for verifiers that check status.

Rationale for VTI-VTN-052. Endorsement is the credential most likely to be read as more than it says, because in ordinary language endorsing somebody is close to vouching for them. A conformance endorsement — this community passed our interoperability tests, on this date, against this version — is a statement about a test result. It says nothing about what the community is entitled to do today, and it is issued by a party that was never asked.

§ What a network is not

VTI-VTN-060 — A VTN MUST NOT create trust contexts and MUST NOT derive keys. See VTI-ACL-090.

VTI-VTN-061 — A VTN MUST NOT make key-custody decisions for a party it lists, or for the members of such a party.

VTI-VTN-062 — A VTN MUST NOT alter the membership state of a member of a VTC. Admission, suspension and removal of members belong to the community, as required by VTI-MEM-010.

VTI-VTN-063 — Removal of a community from a network MUST NOT be represented as a change to that community’s membership, and removal of a member from a community MUST NOT be represented as a change to any network entry.

Rationale. The pressure to collapse these comes from the thing that makes networks attractive to operate: a network that can remove a community has leverage, and leverage is easily mistaken for enforcement. It is not enforcement. It is a second membership decision, made about somebody else’s members, by a party that never admitted them and answers to nobody for it. A network’s remedy against a community it disapproves of is to stop listing it, publicly and under its stated criteria, and that remedy is sufficient.

§ The open question: one node type or two

This subsection is informative.

A VTN and a VTC share most of their surface. Both have an owner and a governance framework, both are provisioned on a VTA, both publish and answer lookups, both issue and receive credentials, and both have something that looks like joining. The differences are narrow: a VTN’s relationships may be one-sided, and it aggregates at a coarser grain.

Whether that is enough to make the VTN a distinct node type, or whether a VTN is better understood as a VTC operating in a curation role — one-sided listing enabled, per-subject admission unused — is not settled.

The requirements above are written so that either resolution is reachable: they state what a network must do, not what it must be built out of. The VTN requirement area is allocated, and the conformance target is marked provisional until the question is closed. Should the working group settle on the second answer, the requirements survive with their identifiers and bind a VTC operating in the curation role.

§ Illustrations

This subsection is informative. The organisations named are used to make the shapes concrete. Naming one here is neither recognition of it nor an endorsement by this specification or the Working Group.

• A software foundation’s communities. The communities working under one open-source foundation, curated into a single network. The foundation is in a position to list a community that has never asked to be listed, and often will be — which is the one-sided case of VTI-VTN-010, and the reason VTI-VTN-011 exists.
• Health services, three levels deep. State networks of healthcare communities, aggregated into a national network, aggregated into a global one. This is the nesting case, and the flattening it invites is what VTI-VTN-032 and VTI-VTN-033 are written against.
• Interoperability and conformance bodies. An organisation running interoperability and conformance testing — Ayra is working in this space — is a natural network owner: the tests produce exactly the endorsement credential of VTI-VTN-051, and the set of parties that passed them is the curated list. It is also the clearest case for VTI-VTN-052, since passing a test says nothing about authority to act.
• A network organised around people rather than institutions. The First Person Collective’s First Person Network illustrates that the curation criterion need not be a sector or a jurisdiction. A network’s criterion is whatever its governance framework says it is, which is why VTI-VTN-002 requires that the framework say so.

§ Membership Lifecycle and Community Credentials

This section is normative.

This chapter specifies how a subject becomes, remains and ceases to be a member of a community, and the credentials that evidence each state.

§ Lifecycle states

VTI-MEM-001 — A VTC MUST represent at least the following member states: applying; member; suspended; and departed. A transition between them MUST be the result of a decision by an authority entitled to make it.

VTI-MEM-002 — Every state transition MUST be audited, recording the subject, the acting authority, the time and the reason.

§ Admission

VTI-MEM-010 — An admission decision MUST be made under authority scoped to the community.

VTI-MEM-011 — Completion of a join exchange MUST NOT be treated as admission. Admission is the decision; the exchange is how it is requested and communicated. See VTI-CMP-020.

VTI-MEM-012 — A VTC MUST record the evidence relied on for an admission, sufficient for the decision to be reviewed afterwards.

VTI-MEM-013 — A VTC MUST NOT admit a subject on the basis of a presentation that does not satisfy VTI-CRD-021 and VTI-CRD-022.

§ Membership credentials

VTI-MEM-020 — Membership MUST be evidenced by a credential issued by the community to the member.

VTI-MEM-021 — Where membership is evidenced by a pair of credentials that commit to one another, each commitment MUST be computed over the exact transmitted form of the other credential.

VTI-MEM-022 — A verifier of such a pair MUST verify both commitments, and MUST refuse the pair where either fails.

Rationale for VTI-MEM-021. A commitment computed over a parsed and re-serialized form is a commitment to whatever survived the round trip. Members that a parser drops — a status member it does not recognise, an ordering it normalises — are outside the commitment, so an artefact can be altered in exactly those members without disturbing the proof. The requirement is stated in terms of the transmitted form because that is the only form both parties can agree on without agreeing on a parser.

§ Suspension and removal

VTI-MEM-030 — Suspension MUST be reflected in the status of the member’s credentials, and MUST take effect for verifiers that check status.

VTI-MEM-031 — A VTC MUST support a departure disposition that erases the member’s personal data, and MUST support at least one that retains the record for audit.

VTI-MEM-032 — A subject-initiated erasure MUST NOT be downgraded by community policy to a disposition that retains their personal data.

VTI-MEM-033 — A departure MUST propagate to whatever the community has published about the member.

VTI-MEM-034 — Where erasures are propagated in batches to reduce timing correlation, the batching interval MUST NOT delay the effect of the departure on the member’s credential status.

Rationale for VTI-MEM-034. Batching publication is a legitimate privacy measure: an erasure published the instant it is requested tells observers when a particular person left. It becomes a defect if the same delay is applied to status, because then the member’s credentials remain accepted after they have left. The two are separable, and this requirement says so.

§ Renewal and rotation

VTI-MEM-040 — Membership MUST expire unless renewed, and renewal MUST NOT extend membership beyond the maximum the community’s policy permits.

VTI-MEM-041 — Rotation of a member’s identifier MUST preserve their membership state, and MUST require proof of control of the new identifier.

VTI-MEM-042 — Rotation MUST NOT be usable to transfer membership to a different subject.

VTI-MEM-043 — A VTC MUST audit renewal and rotation, recording both the previous and the new identifier in the case of rotation.

Rationale for VTI-MEM-042. Rotation and transfer look identical on the wire — the same operation, a new identifier — and differ in whether the same person is on the other end of it. Requiring proof of control from the new identifier does not by itself distinguish them, so the prohibition is stated separately: a community that permits transfer by rotation has a membership that can be sold.

§ Trust Registries and Cross-Community Recognition

This section is normative.

This chapter specifies how communities publish, how they look each other up, and the limits of what a registry answer establishes. It applies equally to the answers a VTN publishes about the parties it lists; the network chapter states what it adds.

§ Publication

VTI-REG-001 — A community MUST NOT publish personal data beyond what recognition by other communities requires.

VTI-REG-002 — A published entry MUST identify the framework under which it is made, so that a consumer can determine what the entry asserts.

VTI-REG-003 — A consumer MUST NOT infer any authority from a registry entry beyond what the entry’s framework states it asserts.

§ What a registry answer establishes

VTI-REG-010 — Presence in a registry MUST NOT be treated as evidence of current authority. See VTI-CMP-032 and VTI-CMP-040.

VTI-REG-011 — A registry answer MUST carry the time at which it was determined, and a consumer MUST apply a freshness bound to it.

VTI-REG-012 — Where a registry cannot be reached, the outcome MUST be indeterminate as required by VTI-CMP-080. A consumer MUST NOT proceed as though the lookup had succeeded, and MUST NOT treat unavailability as absence.

VTI-REG-013 — A deployment MUST state its behaviour on registry unavailability for each class of decision, as required by VTI-CMP-082.

Rationale for VTI-REG-012. Unavailability and absence are different facts with opposite consequences: one means the registry has no entry for this party, the other means we do not know. Collapsing them either admits parties that were never recognised or refuses parties that were, and which of the two happens is decided by an error handler rather than by policy.

§ Cross-community recognition

VTI-REG-020 — A community recognising a foreign member MUST require the member to present their community credentials with proof of possession bound to a single-use challenge issued by the recognising community, as required by VTI-CRD-022.

VTI-REG-021 — The recognising community MUST verify that the presenter is the subject of every credential presented, and MUST refuse where the subjects do not agree.

VTI-REG-022 — The recognising community MUST check the status of the presented credentials with the issuing community, and MUST refuse a revoked credential.

VTI-REG-023 — The mapping from a foreign role to local authority MUST be explicit policy, and MUST NOT grant authority the recognising community would not grant to a local member of equivalent standing.

VTI-REG-024 — Recognition MUST NOT be transitive. A community that recognises another MUST NOT thereby recognise the communities that the second recognises.

Rationale for VTI-REG-020. Community credentials are bearer artefacts: the pair that evidences membership is, without proof of possession, a replayable impersonation of the member for anyone who obtains it — from a relayed join, an audit log, or a compromised device. Recognition is exactly the flow in which such a pair travels furthest from its holder.

Rationale for VTI-REG-024. Transitive recognition composes trust decisions that were each made about one counterparty into a reach nobody assessed, and it does so silently: the third community never appears in the second’s decision. A community that wants the transitive effect can recognise the third directly, which is the same outcome with someone accountable for it.

§ Composition Requirements

This section is normative.

§ In plain terms

Every part of a car can pass its own test and the car still be unsafe. The brakes work, the steering works, the tyres are within spec — and the combination understeers into a hedge. Nobody’s component is faulty; the assembly was never assessed.

That is this chapter. DTG components are specified separately so they can evolve separately, and the price is that some things a relying party depends on are true of the arrangement rather than of any part.

Three examples, each of which has a requirement below:

• A proof that reveals nothing about who presented it, carried under a name that never changes, is not anonymous. The proof is fine. The interaction is not.
• A message exchange that completes exactly as specified has not necessarily achieved what it was for. “The protocol succeeded” and “the thing you wanted is now true” are different claims, and only one of them is testable by the protocol.
• Several signatures from several parties may look like independent corroboration and be four copies of one opinion. Counting them does not make them independent; establishing that they are is separate work.

The last one is the hardest, because the fix is not “check more”. It is knowing what you have not established — and being willing to answer “we cannot tell” rather than rounding it to yes or no.

§ What this chapter defines

DTG component specifications are modular by design, and that modularity is what lets each of them evolve without waiting for the others. It also means that some properties a relying party depends on cannot be determined by inspecting any one of them. This chapter owns those properties.

Every requirement here is a property of the composed interaction. None can be established by a single component, and none of them implies a defect in the component specifications it spans: a component can be entirely correct and the composition still fail to hold the property, because the property was never anyone’s to hold.

§ How a composition requirement binds

VTI-CMP-001 — A requirement in this chapter binds the party making a relying decision and the deployment within which that decision is made. A component’s conformance to its own specification MUST NOT be treated as satisfying any requirement in this chapter.

VTI-CMP-002 — A conformance claim against the Composition profile MUST state, for each requirement in this chapter, the evidence relied on. Appendix E records the ownership classification and evidence for each.

Rationale. The failure this chapter exists to prevent is not a component behaving incorrectly. It is every component behaving correctly and the system built from them holding a property none of them held.

§ Composition integrity

VTI-CMP-010 — A property established by one component MUST NOT be assumed to survive composition with another.

VTI-CMP-011 — A deployment MUST be able to identify, for each property a relying decision depends on, whether that property is established by a component or by the composition.

§ Semantic completion

VTI-CMP-020 — Successful execution of a protocol MUST NOT be treated as establishing the trust outcome the protocol was invoked to achieve.

VTI-CMP-021 — An implementation MUST distinguish, in what it reports to a relying party, the completion of an exchange from the establishment of its intended outcome.

Rationale. A task can complete exactly as specified — every message well-formed, every signature valid, every state transition correct — while the authority, policy, relationship or evidence conditions it presupposed remain unresolved. An interface that reports only “completed” gives a relying party no way to tell the two apart, and the relying party will reasonably assume the stronger reading.

§ Authority is not verification

VTI-CMP-030 — Verification of a credential or a proof MUST be treated as establishing provenance and integrity, and MUST NOT be treated as establishing authority.

VTI-CMP-031 — A composed flow MUST keep the following distinguishable: identity; authentication; credential verification; authority; authorisation; and the trust decision itself. An implementation MUST NOT collapse one into another.

VTI-CMP-032 — Where a relying decision depends on the authority of an issuer or an actor, that authority MUST be established at the time of the decision from a source entitled to answer for it, and MUST NOT be inferred from the validity of a signature.

Rationale. A cryptographically impeccable credential can be issued by a party that never held, or no longer holds, the authority it asserts. Signature validity answers a question about the artefact; authority is a question about the world at the moment of relying, and only something entitled to answer for the world can answer it.

§ Currency of state

VTI-CMP-040 — Historical evidence of a relationship, an authority or a status MUST NOT be interpreted as evidence of its current state.

VTI-CMP-041 — Evidence of currency MUST carry the time at which currency was determined, and a relying party MUST apply a stated freshness bound to it.

VTI-CMP-042 — Where currency cannot be determined within the freshness bound, the outcome MUST be indeterminate as specified below, and MUST NOT default to the last known state.

Rationale. Every component in a composed flow may be reading a different vintage of the same fact: one has just resolved it, one is serving a cached answer, and one recorded it at issuance. Requiring the determination time to travel with the evidence is what lets a relying party notice that.

§ Delegation lineage

VTI-CMP-050 — An implementation MUST NOT derive broader authority from protocol capability than the applicable delegation granted.

VTI-CMP-051 — For any action taken by a delegate, the following MUST be determinable: the scope of the delegation, its lineage back to an authority that held what was delegated, its expiry, its revocation status, and any re-delegation in the chain.

VTI-CMP-052 — A delegate’s authority MUST be evaluated against the delegator’s authority as it stands at the time of the action.

VTI-CMP-053 — The identity of the acting delegate MUST reach the point of decision. A composed flow MUST NOT present a delegate’s action as the principal’s own without the delegation being determinable.

Rationale for VTI-CMP-053. An intermediate component that substitutes the principal for the delegate produces a flow in which every artefact is valid and the question “who actually did this” has no answer at the far end. The delegation may be entirely proper; the point is that the relying party cannot tell, and cannot apply any policy that depends on telling.

§ Privacy across composition

VTI-CMP-060 — Privacy properties MUST be evaluated over the complete interaction, and MUST NOT be evaluated at the level of an individual proof mechanism alone.

VTI-CMP-061 — An interaction MUST NOT be described as unlinkable where any layer of it carries a stable identifier or observable metadata sufficient to re-link it.

VTI-CMP-062 — A deployment MUST be able to identify the durable correlators it introduces, including those arising from naming, routing, lookup and session management rather than from credentials.

VTI-CMP-063 — A composed interaction MUST NOT require disclosure beyond what the relying decision needs.

Rationale. An unlinkable proof carried beside a stable agent name, over a route observable to a mediator, preceded by a registry lookup that reveals who is asking about whom, is a linkable interaction containing an unlinkable proof. The proof mechanism is not defective. The composition is where the property was lost, and the composition is where it has to be assessed.

§ False independence

Several distinct threat classes share one shape: something is observed multiple times, or at depth, or from apparently distinct sources, and that observation is upgraded into a conclusion about independence or completeness that it does not support.

VTI-CMP-070 — Apparent multiplicity, provenance depth, threshold satisfaction, actor distinctness or artefact validity MUST NOT be upgraded into evidence independence or evidence completeness.

VTI-CMP-071 — Where a relying policy depends on the independence of its inputs, that independence MUST be established by evidence, and MUST NOT be inferred from the inputs being separately identified.

VTI-CMP-072 — Where a relying decision depends on the completeness of the evidence presented, an implementation MUST consider whether the presentation is complete for that decision, and MUST NOT treat the validity of what was presented as an answer to that question.

VTI-CMP-073 — Where independence or completeness cannot be established, the outcome MUST be indeterminate. Uncertainty MUST NOT be converted into corroboration.

VTI-CMP-074 — Legitimate plurality, pseudonymity, shared infrastructure, transformation of evidence, coalitions, independent agreement, selective disclosure and privacy-preserving minimisation MUST NOT be treated as adversarial merely because they resemble one of the patterns above.

Rationale for VTI-CMP-074. This requirement is not a caveat on the others; it is half of the property. A system that reads every pseudonym as a sock puppet and every coalition as collusion has not become safer, it has become unable to serve legitimate participants, and the pressure to relax it will come from the cases where it is wrong rather than the cases where it is right. Both boundaries have to be specified or only one of them will be implemented.

§ Indeterminacy

VTI-CMP-080 — An implementation MUST support an indeterminate outcome as a first-class result of a trust evaluation, distinct from both success and failure.

VTI-CMP-081 — An indeterminate outcome MUST NOT be silently converted into corroboration, and MUST NOT be silently converted into failure.

VTI-CMP-082 — A relying policy MUST state what is to be done on an indeterminate outcome for each class of decision it governs. Where the policy is silent, the decision MUST be refused.

Rationale. Insufficient evidence is a different condition from evidence of absence, and collapsing the two loses information in whichever direction the implementation happened to choose. Requiring the policy to say what happens on indeterminate is what forces the choice to be made deliberately, once, by someone who can weigh it — rather than incidentally, per call site, by whoever wrote the error handling.

§ Configuration materiality

VTI-CMP-090 — A configuration change that alters trust, privacy, authority or security semantics MUST be treated as materially equivalent to an implementation change affecting those semantics, and MUST attract the same review and audit.

VTI-CMP-091 — A deployment MUST be able to reconstruct the effective configuration that governed a past decision.

VTI-CMP-092 — Configuration that alters the semantics named in VTI-CMP-090 MUST be identifiable as such, and MUST NOT be indistinguishable from configuration that does not.

Rationale. The nominal protocol is unchanged, every component remains conformant, and the trust behaviour of the deployment is different. Where the change is invisible to the review process that governs code, the composition’s properties can be altered by an edit that nobody assessed.

§ Component substitution

VTI-CMP-100 — Where one conformant implementation is substituted for another, the deployment MUST re-establish the composition properties this chapter requires. Conformance of the substituted component MUST NOT be treated as carrying them.

VTI-CMP-101 — A deployment MUST be able to state which trust, privacy, governance and lifecycle properties it requires to remain invariant across substitution.

§ Human control

VTI-CMP-110 — An action requiring the authorisation of a human principal MUST NOT complete without that authorisation having been given.

VTI-CMP-111 — The authorisation MUST be bound to the action it authorises. An authorisation MUST NOT admit actions other than the one presented.

VTI-CMP-112 — The information presented to the authorising human MUST be sufficient for them to understand what they are authorising.

VTI-CMP-113 — A delegate acting for a principal MUST NOT be able to satisfy that principal’s authorisation requirement.

Rationale. These are the composed-flow form of requirements that appear locally in the Trust Contexts and Client chapters. They are restated here because a flow can satisfy each node’s local rule and still complete without a human having meaningfully decided anything — the authorisation collected at one hop being reused, widened, or attributed to a principal by a component acting on their behalf.

§ Open propositions

The propositions in this chapter differ in how settled they are. Some are established requirements on the composition; others are supported by evidence but not yet resolved to an owner, and could belong to a component specification instead.

VTI-CMP-120 — A published version of this specification MUST record, for each requirement in this chapter, its ownership classification, the evidence supporting it, and the counter-cases considered. Appendix E carries that record.

Rationale. Publishing the unresolved propositions with their status visible is deliberate. A reader is entitled to know which requirements the working group considers settled and which it does not, and a backlog stated in public is worth more than a chapter withheld until it is complete.

§ Operational and Assurance Requirements

This section is normative.

§ In plain terms

This chapter is the questions somebody will ask during an incident, written down in advance.

Who can do what, right now? What has that agent been doing? If we take this credential away this minute, what stops working? Which version of which policy allowed that decision last March?

A deployment that cannot answer those does not acquire the ability while the incident is running. So they are requirements rather than advice: the interfaces that answer them have to exist before anyone needs them, and the record they read from has to still be there and still be trustworthy.

§ What this chapter defines

This chapter states what an operator of a VTI deployment is required to be able to do, and what a deployment is required to be able to demonstrate about itself.

§ Bootstrap

VTI-OPR-001 — Standing up a node MUST NOT require a shared secret transmitted in the clear.

VTI-OPR-002 — Where a node’s first administrative authority is established by an unauthenticated path, that path MUST be closed once the authority exists, and its use MUST be audited.

VTI-OPR-003 — A node MUST be able to report whether it is still in a bootstrap state.

§ Protection at rest

VTI-OPR-010 — Secret material MUST be encrypted at rest.

VTI-OPR-011 — The material protecting it MUST NOT be stored such that obtaining the protected data also obtains the means to decrypt it.

VTI-OPR-012 — Where a node runs in a hardware-attested environment, its attestation MUST be verifiable by a relying party, and the node MUST NOT represent an unattested deployment as attested.

§ Containment

VTI-OPR-020 — A deployment MUST provide a means of immediately withdrawing the authority of a delegated agent, covering every grant within that agent’s scope, as required by VTI-ACL-082.

VTI-OPR-021 — Containment MUST fail closed: where the containment action cannot be confirmed, the deployment MUST treat the subject as uncontained and say so.

VTI-OPR-022 — A containment action MUST NOT depend on the cooperation of the component being contained.

VTI-OPR-023 — Containment MUST be able to suspend a subject’s authority without destroying the audit record of what that subject did.

Rationale for VTI-OPR-023. The moment authority is withdrawn is the moment the record becomes evidence. A containment path that deletes the subject removes the account of the incident along with the access, and the deletion is irreversible at exactly the point where nobody yet knows what happened.

Rationale for VTI-OPR-022. An agent that must acknowledge its own kill switch is contained only while it is behaving, which is the state in which containment is not needed. Withdrawal of authority is enforced by the node that grants it, not by the party losing it.

§ Audit

VTI-OPR-030 — The audit trail MUST be tamper-evident, as required by VTI-AUD-004.

VTI-OPR-031 — A deployment MUST state its audit retention period, and that period MUST have a maximum. Records beyond it MUST be erased or reduced to a form carrying no personal data.

VTI-OPR-032 — An auditor MUST be able to reconstruct, for a past moment, which subjects held which authority.

Rationale for VTI-OPR-032. Reconstructing the authority state is what makes every other record interpretable: an action recorded without the authority that permitted it can be read but not assessed.

§ Time

VTI-OPR-040 — A node MUST obtain time from a source it can rely on, and MUST state the maximum skew it tolerates.

VTI-OPR-041 — Where time cannot be established within that tolerance, a node MUST refuse operations whose correctness depends on freshness rather than proceeding with an unverified clock.

§ What an operator must be able to answer

VTI-OPR-050 — A conforming deployment MUST be able to answer, about itself, at least:

1. which subjects hold authority, over which contexts, with which capabilities;
2. what each delegated agent is permitted to do, and what it has done;
3. which operations require an additional human decision, who can supply it, and whether that requirement can currently be satisfied;
4. what would cease to be possible if a given credential were withdrawn now;
5. which version of which policy governed a given past decision.

Rationale. Each of these is a question that is asked for the first time during an incident, and a deployment that cannot answer it then will not acquire the ability while the incident is running. They are stated as a requirement rather than as guidance because the interfaces that answer them have to be built before they are needed.

§ Security Considerations

This section is informative.

This section summarises the security reasoning behind the normative requirements, and records the threats they address. It introduces no requirements of its own; each item names the requirements that carry it.

1. The trust boundary is per operator, not per service. Two services run by one operator are one boundary. A security argument that depends on their separation is not sound. See the Architecture chapter.
2. Authority is data, not position. Nothing is authorized by configuration, deployment location, or possession of a transport credential (VTI-ACL-001). The recurring alternative — a service trusted because of where it sits — cannot be revoked, audited or scoped.
3. Ancestry is the security gate. The segment-wise comparison and the prohibition on string-prefix matching (VTI-CTX-016) are what keep authority over one subtree from reaching another that shares a leading substring.
4. Empty is not everywhere. The scope-and-role pairing (VTI-ACL-021) closes a defect class in which an entry authorized nowhere is read as authorized everywhere.
5. Enrolment is the exposed step. A bootstrap identifier crosses a channel outside the trust system, so the threat is substitution rather than disclosure; second-channel confirmation and a distinguishable no-entry failure (VTI-CLT-015, VTI-CLT-016) are what detect it.
6. Rotation is the recoverable direction. Reachability is proven before the commit (VTI-CLT-023) because a rotation onto an unreachable identifier cannot be undone, and the swap preserves authority exactly (VTI-CLT-029) so that a self-service operation cannot escalate.
7. Revocation must reach every grant beneath it. A sweep that reports success while a descendant grant survives (VTI-ACL-082) ends the incident response that would have found it.
8. Consent is bound to what was approved. Elevating the requester’s session on the strength of another party’s approval (VTI-APV-005) converts approval of one act into a window in which every gated act passes.
9. Sender authentication is not document authentication. A transport that authenticates its sender does not relieve a producer of signing what it sends (VTI-OPS-021); the two answer different questions.
10. A send that lies is worse than a send that fails. Reporting success for a dropped frame (VTI-TRN-030) makes every layer above it wrong in the same direction, including the health signal meant to detect it.
11. Credentials without proof of possession are bearer tokens (VTI-CRD-021 through VTI-CRD-023), and recognition is where they travel furthest from their holder (VTI-REG-020).
12. Verification is not authority (VTI-CMP-030). A cryptographically impeccable credential can be issued by a party that no longer holds the authority it asserts.
13. Containment cannot require cooperation (VTI-OPR-022), and cannot destroy the record of what it contained (VTI-OPR-023).
14. A signing oracle that signs anything is a forgery service. A VTA parses and constrains what it signs, checks that the issuer, audience and subject are within the requesting entry’s authority, and never signs opaque octets (VTI-VTA-004 through VTI-VTA-007). Blind signing removes every bound at once, and invisibly: the resulting signature is indistinguishable from an intended one.
15. A signed document is replayable unless something remembers it (VTI-OPS-025 through VTI-OPS-027) — and the record has to be shared across bindings, or the node’s replay protection is as good as its least-used transport.
16. Negotiation is an attacker’s lever. Discovery responses are authenticated and each operation has a version floor a peer cannot argue a node below (VTI-OPS-046, VTI-OPS-047); without the floor, retiring a version is advisory.
17. Refusals are answers. A refusal that distinguishes not found from not permitted turns an authorization boundary into a directory (VTI-OPS-035), and a challenge endpoint that answers differently for a known subject is an enumeration oracle (VTI-SES-007).
18. What the approver saw must be what was committed to (VTI-APV-013), and unrestricted authority — the grant from which every other grant can be made — requires a second party (VTI-APV-014).
19. An algorithm is retired at the moment it is broken, not at the next release (VTI-KEY-013).

§ Privacy Considerations

This section is informative.

1. The context boundary is the primary privacy control. A context per purpose limits both what a compromise reaches and what a single credential correlates.
2. Correlation is a property of the interaction, not of the proof mechanism (VTI-CMP-060, VTI-CMP-061). An unlinkable proof carried beside a stable name, over an observable route, after a revealing lookup, is a linkable interaction.
3. Correlators arise outside credentials (VTI-CMP-062): naming, routing, session identifiers and registry lookups each introduce them, and a deployment is required to be able to identify the ones it creates.
4. Status checking leaks by construction unless designed not to (VTI-CRD-013). The verifier acting responsibly is what generates the signal.
5. One identity per client instance (VTI-CLT-052). A shared client identity is a durable cross-device correlator, and it is usually created by cloning a machine image rather than by a decision to share.
6. Minimisation is normative, not aspirational (VTI-CRD-040 through VTI-CRD-042, VTI-CMP-063).
7. Erasure is a member’s right that policy cannot downgrade (VTI-MEM-032), and publication batching must not be repurposed to delay the effect of a departure (VTI-MEM-034).
8. The audit trail is itself personal data. Tamper-evidence and erasure are in genuine tension, and it is resolved at write time: a record refers to personal data rather than embedding it, so an erasure leaves the chain verifiable (VTI-AUD-005). Reading the trail is a privileged act and is itself audited (VTI-AUD-006), and retention has a stated maximum (VTI-OPR-031).
9. An identifier that spans contexts defeats the context boundary without touching a credential: the observer only has to notice the same name twice. Identifiers are per relationship where the relationship does not need a public identity, and a client identifier is never reused across contexts (VTI-KEY-005 through VTI-KEY-007).
10. Routing is the part the mediator necessarily sees. Routing identifiers differ per relationship so that an intermediary cannot reconstruct a principal’s activity across contexts from routing alone (VTI-TRN-026), and operation-revealing metadata stays inside the envelope (VTI-TRN-025).
11. A push service is an intermediary nobody chose. A wake notification carries no content and nothing that reveals what is waiting (VTI-TRN-028).
12. Herd privacy is only privacy while the crowd is real. A status list allocated per subject, or in issuance order, has the shape of a herd and the behaviour of a unique identifier (VTI-CRD-014).
13. A verifier learns things it may not pass on (VTI-CRD-043).

§ Governance Considerations

This section is informative.

1. Where governance attaches. A governance framework may impose stricter requirements than this specification and may not reduce any of them (VTI-VTC-030).
2. The context administrator is a governance role. Subtree authority (VTI-ACL-022) is how an organisational structure is expressed in the authority model, and the approver account (VTI-ACL-041) is how a separation of duties is.
3. Policy is an input to every decision, so its version is part of the record (VTI-VTC-031).
4. Configuration change is governance change (VTI-CMP-090). A change that alters trust semantics without altering the protocol is materially equivalent to a code change and attracts the same review.
5. Recognition is not transitive (VTI-REG-024). A community’s governance reaches the parties it recognises directly and no further.
6. Ownership of a requirement is recorded, not assumed (VTI-CMP-120, Appendix E). Where this specification is silent about who owns a decision, an implementation refuses rather than choosing (VTI-ACL-092).

§ Internationalization Considerations

This section is informative.

1. Identifiers are not human-facing text. Context path segments are restricted to a narrow ASCII set and compared octet by octet (VTI-CTX-011, VTI-CTX-015). Confusable-character attacks on an authorization boundary are prevented by the restriction rather than by normalization, which is itself a source of confusability.
2. Labels are human-facing. Where an entry, a context or a community carries a display name, it is presentation and carries no authority.
3. Anything a human approves must be presented in a language they read. A decision surface rendered in a language the approver does not read does not satisfy VTI-APV-011.

§ Accessibility Considerations

This section is informative.

Several normative requirements in this specification depend on a human understanding what they are being asked to authorise: the consent ceremony (VTI-APV-011), the step-up demand a client surfaces (VTI-CLT-042), and the composed-flow requirement on human control (VTI-CMP-112).

An approval a person cannot perceive or comprehend is not consent. A control built on one provides assurance to everyone except the person exercising it, and it fails in the direction that looks like success — the record shows an approval, and what happened was a person clicking past something they could not read. The decision surface is therefore within the scope of this specification rather than a matter for implementations alone, and it is subject to the accessibility requirements of the jurisdictions the deployment serves.

§ Conformance

This section is normative.

This chapter separates two questions that are routinely conflated: whether an implementation satisfies this specification, and whether a deployment holds its properties in composition. The first is conformance, and it is decided by tests. The second is assurance, and it is decided by evidence. This specification defines the first and defines an interface for the second.

§ Profiles

A profile is a named set of chapters. Requirements bind to targets; profiles group them so that a target can state what it implements without enumerating requirement identifiers.

§ Targets

Note on the VTN target. The Verifiable Trust Network has no implementation at the time of publication, and whether it is a distinct target or a role of the VTC is an open question stated in its chapter. The target is listed so that the Network profile has something to bind to and so that a first implementation can claim against it. Should the working group resolve the question the other way, the target is withdrawn and the Network profile binds a VTC claiming the curation role; no requirement identifier changes either way.

VTI-CNF-001 — A target MUST satisfy every requirement of every profile marked MUST for it that binds that target. A requirement that does not bind a target imposes nothing on it.

VTI-CNF-002 — An implementation claiming conformance MUST state: the version of this specification claimed against; the target or targets claimed; the profiles implemented; and any OPTIONAL behaviour it implements that a peer may rely on.

VTI-CNF-003 — An implementation MUST NOT claim conformance to a profile while implementing a subset of it.

§ Requirement identifier areas

Each normative statement carries an identifier of the form VTI-<AREA>-<nnn>. Areas allocated:

VTI-CNF-004 — An identifier MUST NOT be reused. A withdrawn requirement MUST be marked withdrawn and MUST retain its identifier.

Note. Identifier stability binds from the first Working Group Approved Deliverable. While this specification is a Working Draft, a requirement may still be revised in place as the working group settles its substance; each such revision is recorded in the change log. Implementers tracking a Working Draft should pin the version they built against.

VTI-CNF-005 — An area MUST NOT be renamed.

§ Coverage

VTI-CNF-006 — Every requirement in this specification MUST map to at least one conformance test. A requirement with no test MUST be recorded as a defect in this specification.

Rationale. A requirement nobody can test is a requirement nobody can be held to, and the gap is invisible from inside the document. Recording it as a defect in the specification — rather than as a shortcoming of an implementation — puts it where it can be fixed.

§ The test suite

VTI-CNF-007 — A conformance test MUST validate responses as well as requests, as required by VTI-OPS-031.

VTI-CNF-008 — Conformance MUST be claimed against a named version of this specification and a named profile set, and results MUST be published in a form that identifies which requirements were exercised.

The location of the suite, and who may change it, are not yet settled. Until they are, a conformance claim identifies the suite it was run against by revision, so that a reader can tell which tests a claim rests on.

§ The assessment interface

Assurance — whether a deployment’s properties hold in composition — is answered by evidence rather than by a test result, and more than one assessment programme is expected to exist. This specification therefore defines the interface and does not name an assessor.

VTI-CNF-010 — An assessment submission MUST cite the requirement identifier it concerns.

VTI-CNF-011 — A submission MUST state a disposition of supported, refuted or indeterminate.

VTI-CNF-012 — A submission MUST identify the method used, the artefacts the disposition rests on, the assessor, and the date.

VTI-CNF-013 — A submission concerning a composition property MUST identify the components composed and the versions assessed.

Submissions are recorded in the catalogue in Appendix E.

§ Divergence from implementations

VTI-CNF-014 — A divergence between this specification and an implementation MUST NOT be read as qualifying the requirement. An implementation that diverges does not conform to the requirement it diverges from, whatever the reason.

VTI-CNF-015 — An implementer MAY record a known divergence in the register in Appendix F, stating the requirement, the observed behaviour and the intended resolution. Recording a divergence MUST NOT be treated as an exemption from it.

Rationale. A register of known divergences is useful in two directions: it tells a reader evaluating an implementation which requirements to ask about, and it tells the working group where a requirement is being resisted — which is sometimes evidence that the requirement is wrong, and is always evidence worth having. It is stated as non-exempting because a register that grants exemptions becomes the specification.

§ What an assessment does not do

VTI-CNF-020 — No assessment programme holds normative authority under this specification.

VTI-CNF-021 — An assessment MUST NOT alter a conformance status. Conformance is decided by the tests in this chapter.

VTI-CNF-022 — Only the working group converts an open proposition into a requirement.

VTI-CNF-023 — Where two assessments reach different dispositions on the same requirement, both MUST be recorded. A disagreement MUST NOT be resolved by selecting one of them.

Rationale for VTI-CNF-023. Two competent assessments disagreeing about whether a property holds is information about the property, and usually about the conditions each assessment assumed. Recording only the preferred disposition destroys the more useful of the two facts.

§ References

The entries below name the specifications this document binds. An entry marked (pending) names one whose stable citation the working group has yet to fix; those, and the exact titles and locations of the rest, are confirmed against their current versions before this specification leaves Working Draft.

§ Normative References

Requirements language and notation

• [RFC 2119] Key words for use in RFCs to Indicate Requirement Levels. https://datatracker.ietf.org/doc/html/rfc2119
• [RFC 5234] Augmented BNF for Syntax Specifications: ABNF. https://datatracker.ietf.org/doc/html/rfc5234 — the notation used in Appendix D.

Identifiers

• [DID-CORE] Decentralized Identifiers (DIDs) v1.0. https://www.w3.org/TR/did-1.0/
• [DID-KEY] The did:key Method — the method required for client bootstrap identities by VTI-KEY-002.
• [DID-WEBVH] The did:webvh Method — the method required for durable node identities by VTI-KEY-001.

Credentials

• [VC-DATA-MODEL] Verifiable Credentials Data Model. https://www.w3.org/TR/vc-data-model/
• [DTG-CRED] DTG Credentials Specification — the credential families a VTI node issues, holds and presents. (pending)
• [STATUS] The credential status mechanism relied on by VTI-CRD-010 through VTI-CRD-013. (pending)

Operations and transports

• [TRUST-TASKS] Trust Tasks Specification — the canonical operation catalogue whose precedence is required by VTI-OPS-001. (pending)
• [DIDCOMM] DIDComm Messaging v2.
• [TSP] Trust Spanning Protocol. (pending)

Cryptography

• [RFC 8032] Edwards-Curve Digital Signature Algorithm (EdDSA) — Ed25519, as required by VTI-KEY-010. https://datatracker.ietf.org/doc/html/rfc8032
• [RFC 7748] Elliptic Curves for Security — X25519, as required by VTI-KEY-010. https://datatracker.ietf.org/doc/html/rfc7748

§ Informative References

• [RFC 6973] Privacy Considerations for Internet Protocols. https://datatracker.ietf.org/doc/html/rfc6973
• [TOIP-GOV] ToIP Governance Metamodel Specification. https://trustoverip.org/wp-content/uploads/ToIP-Governance-Metamodel-Specification-V1.0-2021-12-21.pdf
• [AS] Autonomous system (Internet) — the aggregation and announcement model the Verifiable Trust Network chapter draws its comparison from. https://en.wikipedia.org/wiki/Autonomous_system_(Internet)
• [AYRA] Ayra. https://ayra.forum/about/ — named in the Verifiable Trust Network chapter to illustrate a conformance and interoperability body in the position of a network owner.
• [FIRSTPERSON] First Person Network, First Person Collective. https://www.firstperson.network/ — named in the Verifiable Trust Network chapter to illustrate a curation criterion that is neither a sector nor a jurisdiction.
• [TOIP-GLOSSARY] ToIP Main Glossary. https://glossary.trustoverip.org
• [TOIP-IT-GLOSSARY] ToIP General IT Glossary. https://trustoverip.github.io/ctwg-general-glossary
• [COMPOSITION-EVIDENCE] Composition assurance evidence informing the Composition Requirements chapter and Appendix E, including the false-independence corpus recorded there. (pending — the working group is to fix a citable reference for each evidence family it admits.)

§ Appendices

§ Appendix A: Client onboarding

This appendix is informative. It illustrates the sequence specified in the Client Onboarding and Lifecycle chapter, and supplies test vectors for the parts of it that are decidable without a running node.

§ A.1 Enrolment

The out-of-band hop is the exposed step, and the threat there is substitution rather than disclosure — which is why step 5 exists, and why a client that authenticates and finds no entry has to say so distinguishably (VTI-CLT-016) rather than reporting an ordinary failure to connect.

§ A.2 First connection and the key roll

Nothing optional may be placed between the commit point and the persist. The window cannot be removed, so the requirement is that nothing is put inside it.

§ A.3 Worked example

An AI-agent runtime is to summarise documents in one team’s context and sign nothing else.

The context is a leaf of its own rather than acme/eng/team-a, because authority over a context reaches every descendant, and a grant at the team level would reach every purpose the team ever adds beneath it.

§ A.4 Failure cases around the commit point

§ A.5 Test vectors — context paths

Valid (VTI-CTX-010 – VTI-CTX-013):

Invalid:

§ A.6 Test vectors — ancestry

is_ancestor_or_self(a, d), per VTI-CTX-016:

An implementation that returns true for any row marked false has the defect VTI-CTX-016 exists to prevent.

§ A.7 Test vectors — act scope

Per VTI-ACL-020 and VTI-ACL-021, act scope is stated, not derived:

The last two rows are the ones a test suite is most likely to omit and most needs. An implementation that accepts either — resolving it to any scope at all — has reintroduced the inference this model removes.

§ Appendix B: Access control entry

This appendix is informative, and illustrates the requirements in the Trust Contexts and the Authority Model chapter.

A representative entry:

{
  "subject": "did:key:z6MkexampleClientIdentifier",
  "role": "reader",
  "act": ["acme/eng/team-a/summariser"],
  "capabilities": ["vault-read", "sign-trust-task"],
  "keys": ["key-3f2a"],
  "approve": "none",
  "stepUp": { "require": "consent", "approver": "acme-approvers" },
  "expiresAt": "2026-10-10T00:00:00Z",
  "label": "summariser agent, laptop",
  "createdAt": "2026-09-10T09:14:00Z",
  "createdBy": "did:webvh:example.com:acme-admin",
  "ext": {}
}

Every authority-bearing member is a three-valued statement rather than a collection whose emptiness carries meaning. "act": [] is not a narrower grant than "act": ["acme"]; it is a malformed entry, and so is an entry with no act member at all. The same holds for keys and approve.

This shape is deliberately more verbose than the encoding it replaces, in which authority was recovered by pairing a role with a possibly-empty list. The verbosity is the point: a member that says "none" cannot be mistaken for a member that says "all", and neither can be produced by a serializer’s default.

§ Appendix C: Role and capability annex

This appendix is informative. The contents are a proposal for working-group ratification; the normative requirements that reference it (VTI-ACL-010, VTI-ACL-011, VTI-ACL-030 through VTI-ACL-034) are written so that the annex can be settled without changing them.

§ C.1 Roles

§ C.2 Capability registry

holder is marked additive because no role implies it: it reaches above the context tree rather than within it, so deriving it from an administrative role would hand it to every context administrator on upgrade. Granting it requires unrestricted act authority (VTI-ACL-033).

The separations in this table are deliberate and each has a reason worth keeping: sign-trust-task exists so that an agent can sign an envelope without holding the generic oracle; credential-write exists so that a consumer can receive credentials without being able to destroy them; memory-read and memory-write are split so that a read-only consumer of a context cannot rewrite what it reads.

§ Appendix D: Context path grammar

This appendix is normative. It states the grammar referenced by VTI-CTX-010 through VTI-CTX-013.

context-path  = segment *7( "/" segment )
segment       = 1*64( segment-char )
segment-char  = ALPHA / DIGIT / "." / "_" / "-"

ALPHA and DIGIT are as defined in [IETF RFC 5234]. The repetition limits carry two of the constraints directly: a path holds between one and eight segments, and a segment holds between one and sixty-four characters. Because / cannot appear inside a segment, the grammar admits no leading, trailing or doubled separator, and no empty segment.

Ancestry. Let segments(x) be the ordered sequence of segments of a valid context path x. A path a is an ancestor-or-self of a path d exactly when segments(a) is a prefix of segments(d), where segments are compared octet by octet (VTI-CTX-015).

Note that ancestry is defined over the segment sequences and not over the strings: acme is an ancestor-or-self of acme/eng and of acme, and is not an ancestor of acme-evil, which shares a leading substring but not a leading segment. See VTI-CTX-016.

§ Appendix E: Composition proposition catalogue

This appendix is informative, and is the record required by VTI-CMP-120.

Each requirement in the Composition Requirements chapter is recorded here with its ownership classification, the evidence supporting it, the legitimate counter-cases considered, and a pointer to any executable pressure test.

§ Ownership classification

JOINTLY-OWNED carries most of the difficulty. A component specification may properly own the semantics of authority, delegation, lifecycle state, privacy, provenance or evidence, while the question of whether those semantics survive a multi-component interaction belongs here. Recording a requirement as jointly owned is not a step toward moving it into this specification.

§ Evidence families

Each family records a set of related propositions carried through the same path: threat proposition, falsifiable invariant, executable pressure test, legitimate counter-case, disposition. Families are added as the evidence is produced.

Family 1 — false independence. Seven threat classes sharing one unsafe inference, each with an executable test and a legitimate counter-case. Supports VTI-CMP-070 through VTI-CMP-074.

Corpus-level result: apparent multiplicity, depth, threshold satisfaction, actor distinctness or artefact validity is not evidence independence or evidence completeness. The corpus equally preserves the opposite boundary — legitimate plurality, pseudonymity, shared infrastructure, transformation, coalitions, independent agreement, selective disclosure and privacy-preserving minimisation are not failures merely for resembling an adversarial pattern (VTI-CMP-074).

Current disposition: UNRESOLVED, with strong COMPOSITION-OWNED evidence. Source material is cited in the Informative References.

§ Assessment submissions

Submissions received under the assessment interface defined in the Conformance chapter are recorded here, each citing a requirement identifier, a disposition of supported, refuted or indeterminate, the method and artefacts, and the assessor and date. Where two submissions disagree, both are recorded.

None have been received at the time of publication. An empty section here means no programme has submitted evidence, and not that evidence was sought and none found.

§ Appendix F: Divergence register

This appendix is informative. It records known differences between this specification and implementations, per VTI-CNF-015.

An entry states what the specification requires, what an implementation is reported to do instead, and the resolution. An entry is a statement about an implementation, never a qualification of a requirement (VTI-CNF-014): an implementation listed here does not conform to the requirement listed beside it. Entries are contributed by implementers and by the working group, and are removed when the divergence is closed.

The register is deliberately part of the specification rather than a separate document. A divergence that is written down is one an evaluator can ask about and a maintainer can plan against; a divergence that is only known is one that gets rediscovered by whoever is composing the system next.

Each entry states how it was established. An entry marked reported rests on a maintainer’s account; one marked observed rests on an inspection of a running implementation’s source at a stated point in time. An entry marked open records a requirement whose status has not been established, which is a different thing from a requirement that is met.

§ F.1 Authority encoding

§ F.2 Operations and versioning

§ F.3 Transports, sessions and resolution

§ F.4 Signing, audit and identifiers

§ F.5 Closed

An entry leaves the tables above when the divergence is closed, and is recorded here so that a reader can tell a register that is being worked from one that has been abandoned.

A closed entry says the divergence was addressed, not that the requirement can no longer be violated. Two of the entries below were closed by changes whose own limits are worth carrying: domain separation makes a signature unusable outside the domain it was requested in without making the signing of unparseable material safe, and a retention watermark restores verification across an honest sweep while resting on a record held in the same store as the log it vouches for.

§ F.6 How to add an entry

An entry needs the requirement identifier, how the behaviour was established, the behaviour itself, and the intended resolution. It does not need the implementation to be named — the register describes behaviour so that it is useful to every implementer facing the same question — and it does not need the divergence to be resolved before it is recorded.

Where a divergence is evidence that the requirement itself is wrong rather than the implementation, that is a change proposal against the requirement, not an entry here. Both are welcome; they are different things, and conflating them is how a register turns into a set of exemptions.

Correct an entry that turns out to be wrong, and mark it corrected. An entry is a factual claim about an implementation, and one made from a partial reading is worth exactly what it costs to check. Entries in this register have already been corrected: one reported a replay defence as absent when the mechanism existed and the gap was narrower, and one described a security parameter as accepted-and-ignored when the node in question never accepted it. A register that quietly drops such entries teaches its readers not to trust the ones that remain.

§ Appendix G: Acknowledgements

This specification draws on composition-assurance work carried out elsewhere in the DTG portfolio, recorded in Appendix E, and on operational experience from implementations of the infrastructure it describes, recorded in Appendix F.

Further acknowledgements are added here as the Working Group records them.

Copyright © 2026 Trust Over IP (ToIP) Contributors
This work is licensed under a Creative Commons Attribution 4.0 International License.