This is the slide people should photograph. Nodes are identifiers you control; edges are signed claims about relationships. Everything in Act VI depends on it.

Do not say "no registry needed" — it is wrong and it undercuts our own architecture. The fragment draws the line that matters: a signature settles authenticity and needs nobody's permission; a trust registry settles current status, and we actively advocate one per community and per network. TRQP is a first-class part of this stack, not a fallback.

"Reciprocal" surprises people — say it explicitly: a relationship here is two credentials, not one. That kills the whole class of "I'll just assert I know them" attacks.

Deliberately no DID methods yet. Identifiers are enough at this altitude; the methods get a proper slide in Act II.

Be genuinely honest about generation one. Half the room will have lived through it, and a deck that pretends SSI succeeded loses them in thirty seconds. The failure was not cryptographic — it was that the model required an ecosystem to exist before anyone could use it.

The pivot in one line: generation one asked "who will issue the credentials?" This asks "who do you already know?" A community of two is a working system; a credential nobody issues is not.

Say the credit out loud rather than leaving it on screen. Drummond Reed's First Person Project white paper is where the argument comes from — being clear about which ideas you originated and which you implemented is the fastest way to be trusted on everything else for the next two hours. He is also among the editors of the DTG Core Credentials spec, so the paper and the ToIP standardisation are one lineage.

End on the last line and mean it — "we are at the very start". It sets expectations honestly and it is more exciting than claiming to be finished.

Ninety seconds to two minutes. Never cut this slide.

This slide exists to buy you the next two hours. A room being shown an architecture wants to know whether it is real. Show them, then move on — do not narrate the numbers.

The shape is the message: a flat 2025 while we built identifiers, credentials and messaging primitives, then a hockey stick from February when the agent and the community service started. Point at the cliff, say "that is when it stopped being a research project", and go.

If you want one line of swagger, it is the last one: none of it is a mock-up and none of it is behind a login. Everything on the QR wall at the end is public.

Counted from local git history on 2026-08-30. August is a near-complete month. Recount before reusing — the script is in the README.

Two build-outs. Walk the whole left column first — let the room sit in the passport world, which is the one they know. Then reveal VTI and walk the same five rows in the same order, so the comparison lands row by row. Then the closing fragment.

The parable does real work: a passport is trustworthy because of who issued it; a letter of introduction is trustworthy because of who wrote it and whether they still stand behind it. Both are legitimate. Only one of them scales to communities that no state has heard of.

Accuracy guard — do not soften. Never present VTI's registries as an implementation of trusted lists. They are a different mechanism answering a different question, and the comparison it invites is one VTI loses on the only axis that would then matter: accreditation.

Anchor slide. Come back here whenever anyone loses the thread, including in Q&A. Name the layer you are entering at the start of each act.

The hourglass is the whole argument. TCP/IP has one IP layer and thousands of link layers below and applications above. ToIP copies that shape deliberately: agree narrowly at layer 2, and let layers 1, 3 and 4 be plural. If someone asks "why not just standardise everything" — that is why.

Say explicitly that TSP and DIDComm are both layer-2 citizens here. Anyone who has seen an earlier version of this material will expect DIDComm to be privileged; it is not, and the transport is now chosen per peer from the DID document.

The governance column is dashed because it is not a protocol layer — it runs alongside every layer. If nobody asks, do not explain it.

The most important slide in Act I. The old version of this slide was four unrelated maxims with act numbers on them; this one is a single idea and a chain of consequences, which is what the deck actually argues.

Correct the "keys never move" instinct out loud. The VTA is not a prison for key material. It is custody with policy: by default nothing leaves and it signs on your behalf, but you can deliberately release material to your own applications and services. The choice is the operator's, and that is the feature.

The ladder is the spine of the next four acts — Trust Tasks (Act IV), ceremonies (also IV), DTTE (Act V). Say the numbers as a progression: name the work → sequence the work → delegate the work safely.

The closing fragment is the honest and the exciting part: this was emergent. Nobody set out to build delegated execution; it became available once operations had stable, published names.

Good place for the first Q&A pause — two minutes, no more.

Lead with the notary and let it breathe. It answers three questions before they are asked: how do I back it up, how do I get keys out, what happens if it is stolen.

Do not go into derivation schemes. The implementation is a standard hierarchical-derivation design; what matters on this slide is the consequence — one recoverable root, deterministic derivation, so recovery is a phrase rather than a key export. If someone wants the BIP-32 path spec it is in docs/04-reference/bip32-paths.md.

The comparison table is the point of the slide. People arrive assuming "VTA" is a rebranded KMS. The five rows on the right are the difference, and four of them have nothing to do with keys.

"It can refuse" is the seed for Act V. Plant it here.

Do not read the nine boxes. Pick three the room will not expect — agent memory, application state and approval policy — and say why each belongs in a custody root rather than in an app.

The argument for memory and app-state living here: they are the parts of your digital twin that are most revealing and least protected today. They sit behind the same ACL, the same audit trail and the same backup as the keys.

Vault and credential store are separate on purpose, gated on different capabilities. Say that if anyone asks why there are two.

The closing fragment is the structural claim, and it sets up Act IV: one uniform way in, for all nine.

Open with the three yous. Work, club, stranger. Then the uncomfortable bit: in every system they use today, those three are the same row in the same database, and the only thing stopping them being joined up is a product decision somebody else made.

“Folders” is the whole explanation. Everyone has the intuition already — a folder tree, permissions that inherit downward, nothing leaking sideways. Do not reach for a better metaphor; there isn't one.

The delegation point is the one operators react to. Admin of a parent context administers the entire subtree — create sub-contexts, manage their access, their keys, their data — and has no reach outside it. That is how you hand a team their own corner of your agent without handing them yours.

If asked how the isolation is enforced: the context's identifier is its path, so the authorisation check is a segment comparison on data already inside the verified token — no lookup, nothing that can fail open, and acme deliberately does not match acme-evil. Keys nest the same way, so a sub-context's keys derive underneath its parent's. Eight levels maximum.

Status: this is done on the agent — the model, the nesting, the derivation and the authorisation gate all shipped. The community service never held contexts in the first place; it only references them.

The brands are illustrative. If the room is enterprise, swap them for two customers and a regulator and the point lands harder.

The colour just went gold — we have moved from custody to community. Call it out once and the rail does the rest.

The line that matters: admission is a policy decision the community writes. We supply the evaluator and the inputs. Their rules, their community, their call — that is the entire difference between this and every "join our ecosystem" pitch they have sat through.

The enclave point gets misread constantly. It is not "no secure hardware in this architecture". It is: the community service is not enclaved, and the agent holding its root keys is. One layer down, exactly where the secrets are.

The provisioning handshake used to have its own slide. It does not need one — "provisioned once, then independent" is the whole story, and the detail is in the docs.

Three jobs, in this order: a globally unique name nobody had to assign; a public-key directory you publish yourself; and a set of service endpoints that say how to reach you. The third is the one people forget and the one the whole next act depends on.

The analogy that works: a phone number that carries its own directory entry — and its own switchboard address.

The interoperability point is a real position, not modesty. Say it plainly: a short, well-tested method list is a choice. Anyone who needs a chain method can turn one on.

Do not go deep on did:webvh here; it comes back in Act V when a third party edits one. If asked: self-certifying so it survives moving domain, signed history you can replay, and pre-rotation so a stolen current key cannot take the identity over.

Colour goes lime — we are on the wire now, and stay there for the rest of the act.

Give TSP and DIDComm equal billing, deliberately. Anyone who has seen earlier material will expect DIDComm to be the default; it is not. Preference order is TSP, then DIDComm, then REST, and the choice is per peer.

"One shared operations layer" is a correctness claim, not a diagram. Say it that way.

The libp2p door usually gets one question: no, nothing is committed to it. The point is the cost of adding one — and that cost is low precisely because the Trust Task document never names a transport.

The post box parable does the whole job. Poste restante, a PO box, a pigeonhole — pick whichever the room will recognise. Nobody needs to be home; nobody publishes their home address.

Sender proof for free is worth slowing down on. In an HTTP world "who sent this" is a token you check separately and can forget to check. Here you cannot read the message without learning who sent it.

Say relay and mediator are the same role under two protocol vocabularies. Then nobody spends the next slide wondering whether TSP has one.

If asked "isn't that a central point of failure?" — it is a point of availability failure, never of confidentiality failure. You can run your own, and you can use several. That distinction is the whole answer.

Draw it with your hands. Four nested boxes, opened by four different parties, and only the innermost one contains meaning. Once the room has this picture, the next slide costs nothing to explain.

The one thing to emphasise: the sealed layer both hides and authenticates. Two properties, one operation — which is why there is no separate signature to verify and no token to steal.

TSP and DIDComm build these layers differently — that difference is exactly what the next-but-one slide is about — but the shape is the same in both, and so is the innermost box.

Run it as a story. Alice wants to reach Bob without either of them publishing an address. Left: she writes “for Bob” on one envelope and every post office along the way reads it. Right: she nests envelopes so each office sees only the next one — but the parcel she has to carry to the first office is enormous.

The thinning lines on the right are load-bearing — the message shrinks as layers are peeled, which means the worst point is the sender. Point at them.

The blow-up is an encoding artifact, not a law of routing. That framing is what makes the next slide's answer possible, so plant it here.

Do not overstate it: at one or two hops the onion overhead is only ~1.8–3×. It only bites past a few hops. And only the lazy path is implemented today.

Do not sell TSP as a performance win. The guard is on the slide because it is easy to overstate: the honest claim is metadata privacy at bounded size. We deferred TSP once for exactly this reason, and reversed it when the mediator gained TSP routing and bridging — not because anything got faster.

"A send that lies is worse than a send that fails" is the transferable lesson in the room. Everyone who has wrapped a queue in a synchronous-looking client has shipped that bug.

Status: the delivery layer is built and live-validated against a real mediator; cutting every service over to it is in progress. Say "built and validated, being cut over".

Two slides used to live here — a routing-rules list and an operator-surface tour. Neither survived the "would a first-timer care?" test.

The third card is the one that matters and the one people skip. Everything in Act IV depends on operations having names you can put in a policy and in a consent prompt. Plant that here so the payoff lands later.

If the room is API-heavy, acknowledge OpenAPI honestly: it describes an HTTP surface very well. It just isn't a description of the work, and it doesn't travel off HTTP.

Land the fourth bullet. Everything in Act V exists because operations have stable, published names that a policy engine and a human can both read. Plant it here and the payoff lands later without a recap.

Exact-match at start-up is the detail engineers respect: the service refuses to boot if a handler and its spec disagree.

"You can verify one on paper" gets a laugh and it is a real claim — the document is meaningful with no network, which is why it can be signed, archived and audited.

Counts were taken from the working tree the day this deck was written and they move weekly. Recount before reusing: find specs -name spec.md | wc -l in dtgwg-trust-tasks-tf. For context on velocity: in mid-June the registry held 126 task-versions.

The retirement story is the credibility half of this slide. Lead with it if the room looks unimpressed by counts.

Governance, licensing and the maturity ladder are deliberately not on this slide — that work is genuinely in progress and putting it up invites a conversation the material cannot yet finish. If asked: it is an open ToIP working group, specs are versioned in public, and the process is being firmed up.

The wedding analogy carries the whole slide. Roles, order, the moment it becomes binding, and the certificate. Everyone has the intuition already.

Walk the diagram in three beats: the applicant applies (lime, it opens the clock); the administrator decides (gold, terminal — a rejection is a complete ceremony, which surprises people and is the right design); then the reciprocal half closes the two-way membership edge, because a membership is two credentials.

Dashed steps are optional. discover can be skipped by an applicant who already knows the criteria, and the enactment is still complete without it — that is what "prev-less and optional" buys.

Honest note if pressed: the definition itself flags a gap — the registry has no task by which an applicant supplies further evidence, so "deferred" is currently a reachable state with no defined exit. It is written into the published ceremony rather than hidden. That is the process working.

The old version of this slide described our own codebase's plumbing and meant nothing to a newcomer. This one compares what everyone in the room already does — OAuth, API keys, passwords — with what we want instead. Stay on that ground.

The sharpest way to say it: OAuth asks "may this app act as you?" This asks "may this app do this one specific thing, right now?" Those are completely different questions and only one of them is answerable honestly.

If someone raises scoped tokens or short-lived credentials: they narrow the standing invitation, they do not remove it. Nothing in that world shows the human what will actually change before it changes.

Read it aloud, slowly, and then stop talking. It is deliberately one sentence, and every mechanism on the following slides exists to make one clause of it true.

The formal version, if anyone wants it: no state-mutating Trust Task executes unless the agent has verified a single-use consent decision, signed by a currently-enrolled approver device, whose payload digest equals the digest of the exact payload about to execute, against the exact prior state used to compute the effects the human was shown — and unless policy and device enrolment still permit it at the moment of execution. Every one of those bold phrases is a separate attack it closes.

Then walk the corollaries and name which clause each comes from. That turns a wall of text into a structure.

If you only have time for one slide of this act, it is this one.

This is the anchor for the whole act. Come back here whenever anyone loses the thread, including in Q&A. If you are short on time, keep this slide and skip 31 and 33.

It builds in three clicks — one per word in the title. Propose, decide, execute. Do not click ahead: the empty lanes at the start are doing work.

Walk it in exactly three beats, left to right: the site can only ask · the agent works out the truth and shows a human · the agent re-checks and does exactly that, once.

Point at the far-left arrow and say: that is the entire attack surface the website has. One name, one payload, no ability to write anything a human reads.

"Read from the caller, never from the message" — the page cannot claim to be a different origin, because the device knows who called it.

The thirteen numbered protocol steps behind this picture are in the design note; nobody in a first-exposure room needs them, and the old version of this slide that showed them as ASCII did not render reliably.

The strongest slide in the deck. Give it room.

Zero trust is the frame for the whole act — the agent assumes the website is hostile, the browser is hostile and the registry is compromised, and still reaches a correct answer. Every mechanism here is one of those assumptions made concrete.

The key-rotation example is real and it lands every time. Say it slowly: the request said "add a line" and the truthful answer includes rotating your keys.

Do not let anyone soften the four-character match into a tap. A tap proves the device was present, which is exactly the thing you assumed was compromised. It is also why approval must be able to go to a different device than the one asking.

Two slides folded in here: the five-check list and the argument about where "is this destructive?" comes from. If someone pushes on the registry question, the answer is one sentence — the registry describes, the compiled-in code decides, and unknown versions fail closed.

Tone goes ember — this slide is about being wrong, and it should look different.

Both of these were found by reviewing the design, not by an incident. Say that: it is the argument for writing the invariant down as one sentence in the first place — you can audit a sentence.

The privacy one generalises well beyond this system: a hash of a low-entropy input is not a blinding, it is an index. That is a lesson people take back to their own work.

Q&A pause here — end of Act V, ~4 minutes. This is where the sharpest questions come.

The three answers are the whole pitch. Say them slowly. Almost every wallet and hosting product in the market is answer one or answer two, and the room will recognise both immediately.

"Sleep well" is a joke — land it dry and move on.

Pre-flight if you ever demo this live: two settings fail silently in opposite directions. Enforcement is off by default with a permissive baseline, so the update just succeeds and looks like it worked; approver sets are empty by default, so a rule naming an unknown set can never be satisfied and looks like a hang. Rehearse the full loop. And the requesting and approving identities must genuinely differ.

The hosting service — server, witness, watcher, control plane — used to have its own slide. The last paragraph is all a first-timer needs; the architecture is in the repo.

Lead with the unchanged host. "We integrated a security model into a third-party service and that service needed no changes" is the single most persuasive sentence available about this design, and it is true.

Accuracy guards — do not soften. Dedicated agent-name/set and agent-name/remove Trust Tasks exist, but only the document-update handler has a dry-run, so the explicit verb shows a match code with no itemised effects. Demo the document edit; mention the verb.

Agent-name resolution cost: the one-round-trip path is the WebSocket resolver and is off by default; a cold miss over plain HTTP is one to five hops. Say "usually one hop", never "always".

The impure-plan bug is the best possible closing note for the act: the dry-run principle is not theoretical hygiene, it caught a real, silent, fully-signed lie.

The VMC-vs-VRC distinction is the thing to land: membership is vertical, relationship is lateral. Once someone has that, they can read any part of the graph without help.

Reciprocity is the second callback to slide 3. Say it out loud — a claimed relationship with only one signature is not an edge, it's an assertion.

Note the VTN tier exists but is the least exercised part of the model. Don't oversell networks-of-networks; the community tier is where the running code is.

Read the plain-English column, not the acronyms. Seven sentences is the whole taxonomy and it is far more memorable than the class names.

The VDC is the one to spend time on, because it is where the AI-agent story becomes a credential rather than a config file. Frame it as the letter of authority from the guild example: a stranger can check it, and the guild can tear it up.

Status guard: the VDC is proposed — it is in a spec pull request and not yet in the published catalogue, so nothing downstream can claim conformance to it yet. Our own design note argues the draft should be cut down hard for privacy reasons. Say "in the pipeline, and we are arguing about it in public".

The single-hop argument is genuinely interesting and worth thirty seconds: chaining is the thing people reach for, and it is the case where chaining is worst — you cannot revoke what you cannot enumerate.

Also mention taskContext if there is time: a credential can name the exchange that produced it, but context is not outcome — knowing which conversation made a credential says nothing about whether that conversation succeeded.

If a laptop is on the projector, open the real thing instead of talking about it. dtg-demo → ./build.sh → open the generated page, then trace a path between two random communities. It lands harder than any slide.

Generation is deterministic, so the same seed gives the same graph — you can rehearse the exact demo you will give. It signs the whole set in seconds.

Guard: this is a generated exemplar, not a production network. The credentials are real; the people are not. Say that plainly so nobody quotes the entity count back at you as users. The counts in the panel come from this particular run — the generator is configurable, so do not treat them as fixed numbers.

Tell all three as stories — the workshop, the house, the guild. They are memorable, they are genuinely different, and they kill the assumption that privacy always means anonymity. The workshop wants to be correlatable.

Land the guild hardest, because most real communities are it, and because Sofia is the argument for scope-per-relationship. One person carrying three different correlation postures simultaneously is not an edge case.

Sofia's letter of authority is the VDC from the previous slide. Point back at it explicitly — it is the same object.

This is the fourth of the deck's community layouts. If someone asks which one we recommend: none. The system's job is to let a community declare its posture and then hold it.

Every layer of the stack shows up in these four steps. Call them out as you go: Trust Tasks carry the messages, the VP is DTG credentials, the policy is the community's governance, the registry is the federation.

Step 3's auto-admit is the useful nuance: an invitation is not a shortcut past policy, it is an input to policy. The community can still refuse.

Multi-community membership is supported — one persona can belong to many VTCs at once.

Use the scope words, not the old acronyms. Public, community, pairwise — the same three from the previous slide, now as the thing a developer actually configures. Anyone who has read older material will know them as persona and relationship DIDs; the scope vocabulary is clearer and it is what the specs use.

The collapse point is the one to land: thirty relationships under thirty identifiers are thirty disconnected fragments. Reuse a single identifier across them and they become one five-armed star with you at the centre. It is not traffic analysis — it is a lookup.

Scoped personhood: people hear "proof of personhood" and assume both global uniqueness and a government identity. It is neither. Be precise.

End the applied section on this because it is not an identity product. It is supply-chain integrity, delivered by everything in the previous six acts, and it solves a problem the room already has.

Walk the diagram anticlockwise: agent signs → commit carries the signer → the check resolves it → the check asks the community. Two identifiers on a command line, and nothing in the repository.

The crate split is deliberate and worth a sentence for the security-minded: the CI verifier cannot sign — it never opens an agent session or touches a keyring, so a pull-request run has no signing capability at all.

The picture is the pitch. Three agents on three machines, one memory, one owner. Today each of those agents has its own private, unexportable notion of you.

This is also the payoff for Act III. Nobody wrote transport code for this plugin — it gets TSP-or-DIDComm-or-REST selection for free, per agent, because the dispatcher and the identifier documents decide. Point back explicitly.

The rotate-on-first-use rule generalises well beyond this tool: the identity you paste into a ticket should stop working once it has been used.

Two boundaries drawn on purpose, if asked: memory is not application state — "forget everything" has to stay safe to ask — and memory is not a secret store; those are different capabilities in the agent.

Say the headline as written and mean it. Six MCP tools is an afternoon. The skill — the written judgement about what is worth remembering and what must never be written down — is the part that decides whether the feature helps or quietly poisons every future session.

The description-not-bodies rule usually gets a nod from anyone who has built retrieval. It is the difference between memory that helps and memory that eats the context window.

Both boundaries were arrived at by nearly getting them wrong. "Forget everything must stay safe to ask" is a user-facing property that dictates an architectural one.

Cost note if asked: recall reads the whole context, because memory/list has no prefix or cursor. Fine at the hundreds of memories a person accumulates — and the fix, if it stops being fine, starts with a spec PR to the public registry, because the VTA's dispatcher refuses URIs the registry has no schema for. That constraint is Act IV doing its job.

"An MCP host approves a tool, not a call" is the line to leave the room with if they build agent integrations. It is a general property of the protocol, not a criticism of any host, and almost nobody has designed for it.

The purple card is the answer to the obvious objection — that local flags are only as trustworthy as the machine enforcing them. Say it plainly: local policy is advisory, agent policy is not. That is why the step-up ceremony matters more for AI agents than for browsers, not less.

The two named exceptions are the credibility move again. A security boundary with two documented holes beats one with two undocumented ones.

Five seconds on this slide, then go. It is a map so the room can place themselves, not a thing to read out.

Credit Geoff and Vincent by name on stop one. It is their service, the room should know the stack has more than one pair of hands on it, and it makes the whole thing feel like a team rather than a slide deck.

The arc is deliberate: infrastructure exists → a community exists → a person joins it → their agent remembers them → they use it somewhere real → something asks permission → and then the technology vanishes. Do not reorder it. Stop seven only lands because six earned it.

Pre-flight the delegated-execution stop especially — enforcement off and empty approver sets both fail silently, in opposite directions. Rehearse the full loop on the machine you will present from.

Come back to this slide immediately after the demo, while it is still warm. Each row ties a stop to the act that explained it, so the room gets the "oh, that is what that was" moment.

Land the last line properly. Every other stop is impressive because you can see the machinery. Stop seven is impressive because you cannot. That is the actual bar for infrastructure, and it is a good note to hand back to the closing slides.

If a stop failed during the demo, say which one and move on — the row is still true, and the deck already told them how it works.

Never cut this slide for time. A workshop that oversells gets found out in week two, and then nothing else you said counts.

The spec-versus-code split is the honest frame. "Is it ready?" is the wrong question; "which part, and ready for what?" has a real answer. The code has been live-validated; the specs are drafts being argued in public — which is what a draft is for.

If someone asks what would change your mind about the design: the consent-matching ceremony is the piece most likely to be defeated by real user behaviour, and it is the one we watch hardest.

Close by repeating the through-line from slide 8 — the idea and the three things it unlocked. Bookending them is what makes them stick.

Push people at vti-setup over the documentation tree: it is role-organised and it is the only door that ends with something running on their own machine.

Then the QR slide, and open the floor. Anchors for Q&A: 7 (the ToIP stack), 30 (the delegated-execution flow), 42 (the join ceremony).

Leave this on screen for the whole Q&A. It is the most useful thing in the room while people are asking questions, and it saves you reading URLs out.

If you only point at three: the white paper for the argument, trusttasks.org for the registry, and verifiable-trust-infrastructure for the code.

Everything here is public and needs no account. Say that — it is the difference between a workshop and a sales pitch.