Draft 0.9 — Request for Comment
A protocol for short-lived, scope-bonded operational grants derived from VCAP attestations, enabling authorized agent action without exposing recipient directories.
Authors: Odysseus Melchizedek Shiloh, WellSpr.ing · Claude Opus 4.7, Anthropic Status: Draft 0.9, open for comment Date: April 17, 2026 Canonical URL: https://wellspr.ing/protocols/ptp Sibling protocols: Vaulted Covenanted Agent Protocol (VCAP) at https://wellspr.ing/protocols/vcap; Scope Grammar Specification (SGS) at https://wellspr.ing/protocols/sgs Comment channel: https://wellspr.ing/protocols/ptp/rfc
An AI agent holds a VCAP attestation saying it is committed to a conduct standard. Now the agent needs to do a specific thing: reach all the dry cleaners in Poughkeepsie to introduce a new covenant-aligned payment service, for example. How does the agent get authorization to do this specific thing, without the vouching institution exposing its directory of verified dry cleaners to the agent, and without the agent having to re-present its full covenant credentials to every recipient?
This protocol closes that gap.
Under PTP, an agent with a valid VCAP attestation requests a presence token for a specific scope — where "scope" is a canonical string from the Scope Grammar Specification declaring the action, the recipient category, the geography, and the purpose. The vouching institution reviews the request against the agent's declared authorization, issues a signed, time-bounded token, and provides a routing path for the authorized action. The token is verifiable by receiving surfaces without revealing the agent's identity or the institution's directory.
The protocol is the operational layer of the trust stack VCAP anchors. Where VCAP attests to commitment, PTP authorizes action. Where VCAP is long-lived (typically one year), PTP tokens are short-lived (hours to days). Where VCAP is a public artifact, PTP tokens are operational grants that reveal only what receivers need to know.
VCAP and PTP form a two-protocol stack. Each does something the other does not.
VCAP answers: is this agent committed to a conduct standard I can verify? This is the trustworthiness question. VCAP attestations are persistent, publicly fetchable, and cryptographically anchored to a transparency log.
PTP answers: is this specific outreach authorized under that commitment, right now? This is the capability question. PTP tokens are ephemeral, scoped to specific operations, and bound to specific covenant keys.
An agent may hold a VCAP attestation without ever requesting a PTP token (if its engagement is open conversation with known parties rather than scoped outreach). An agent may not hold a PTP token without an underlying VCAP attestation. The tokens are always derivative.
The separation of protocols allows each to evolve independently. An institution may adopt VCAP for trust-verification of other institutions' agents without running its own PTP token-issuance infrastructure. An institution may run PTP for its own agents while accepting VCAP attestations from peer institutions.
PTP authorizes actions within scopes declared using the Scope Grammar Specification. A scope string has the form:
{action}:{recipient-category}:{geography}:{purpose-category}
The agent's VCAP attestation declares, in its canonical_scopes field, the scopes the agent is authorized to operate within. A PTP token request specifies a particular scope (which may be a literal match for an SGS vocabulary term, with geography specified; wildcards in requests are not permitted). The token-issuance logic performs literal string matching against the declared scopes, permitting wildcard matches only where declared scopes contain wildcards.
The SGS specification defines the grammar, vocabulary, match semantics, and extension process. PTP relies on SGS for all scope-related questions; PTP does not extend or modify the grammar.
A presence token is a signed JSON document issued by a vouching institution. The token is presented by the bearer at the routing surface and verified before the authorized action is executed.
{
"ptp_version": "0.9",
"token_id": "prs_wellspring_2026-04-17_abc123xyz",
"token_type": "presence_token",
"bearer": {
"covenant_key_hash": "sha256:base64-encoded-hash-of-covenant-public-key",
"proof_of_possession_required": true
},
"scope": "message:merchants:poughkeepsie-ny:civic-outreach",
"purpose_declaration": "First-contact introduction of the 425.today merchant off-ramp to dry cleaners and adjacent service merchants in Poughkeepsie, NY, on behalf of a civic outreach campaign.",
"vcap_attestation_uri": "https://wellspr.ing/vault/ody/attestation-2026-04-17.json",
"vcap_attestation_id": "vcap:wellspring:ody:2026-04-17:001",
"issued_at": "2026-04-17T14:30:00Z",
"expires_at": "2026-04-19T00:00:00Z",
"revoked": false,
"issuer": {
"name": "WellSpr.ing",
"uri": "https://wellspr.ing",
"issuance_policy_uri": "https://wellspr.ing/protocols/ptp/issuance-policy"
},
"routing": {
"routing_authority_uri": "https://wellspr.ing/routing",
"verification_endpoint": "https://wellspr.ing/api/v1/ptp/verify",
"audit_endpoint": "https://wellspr.ing/api/v1/ptp/audit"
},
"safeguards": {
"maximum_recipients": 250,
"minimum_interval_between_recipients_ms": 5000,
"stakes_level": "medium",
"dual_sided_audit_required": true
},
"signature": {
"algorithm": "Ed25519",
"key_id": "wellspring-2026-ptp-signing-key-01",
"public_key_uri": "https://wellspr.ing/.well-known/ptp-signing-keys.json",
"signature_value": "base64-encoded-signature"
}
}
Field-level notes:
bearer.covenant_key_hash is the SHA-256 hash of the agent's covenant public key. The token does not include the key itself; possession is proved at verification time via a signing challenge (see Section 5.3).scope follows the SGS grammar. The scope in a token is always a specific scope (no wildcards in request position) but may match a wildcarded declared scope in the underlying VCAP attestation.purpose_declaration is a human-readable statement of what the agent will do under this token. It is included in audit records and may be surfaced to recipients.vcap_attestation_uri and vcap_attestation_id anchor the token to its underlying VCAP attestation. Verifiers re-check the attestation's revocation status as part of token verification.routing.verification_endpoint is the URL a recipient or routing surface calls to verify the token. See Section 5 for the full verification procedure.safeguards encodes PTP-level operational constraints derived from the SGS stakes level for this scope. Receivers and routing surfaces enforce these constraints.A presence token's lifecycle has five phases: request, issuance, presentation, verification, expiry or revocation.
The agent requests a token from the vouching institution's PTP issuance endpoint:
POST https://wellspr.ing/api/v1/ptp/request
The request body declares: the agent's covenant key (proving current standing), the VCAP attestation being drawn on, the specific scope being requested, the purpose declaration, and the requested lifetime (subject to the maximum for the scope's stakes level).
The request must be signed by the agent's covenant private key. The signature proves that the requesting party actually holds the covenant key; a signature check against the key hash in the VCAP attestation prevents any other party from requesting tokens on the agent's behalf.
The vouching institution performs the following checks before issuing:
revoked field.canonical_scopes array? This is a mechanical string-matching check per SGS.If all checks pass, the institution issues the token per the schema in Section 4, commits the issuance to its PTP audit log, and returns the token to the agent.
If any check fails, the institution declines with a specific reason, and the decline is itself logged.
The agent presents the token at the routing surface when initiating the authorized action. The presentation differs by action type:
message and converse actions, the agent submits the message content to the routing surface together with the token. The routing surface verifies the token and, if valid, routes the message to in-scope recipients.query actions, the agent submits the query together with the token. The routing surface verifies, forwards the query to recipients who have consented to receive queries of this type, and returns aggregated or per-recipient responses per the scope semantics.receive actions, the agent registers with the routing surface using the token. Inbound contacts matching the scope are routed to the agent.transact and broker actions, additional protocol extensions apply; see Section 9 for the open status of these actions in Draft 0.9.The routing surface may be operated by the vouching institution itself (as in WellSpr.ing's merchant-outreach case, where WellSpr.ing holds the directory and performs the routing) or by a third party that has accepted the vouching institution's tokens.
When a recipient or routing surface receives a token, it performs verification through a single API call:
GET https://wellspr.ing/api/v1/ptp/verify/{token_id}
The verification endpoint returns a minimal response revealing only what the verifier needs to know:
{
"valid": true,
"scope": "message:merchants:poughkeepsie-ny:civic-outreach",
"expires_at": "2026-04-19T00:00:00Z",
"revoked": false,
"purpose_declaration": "First-contact introduction of the 425.today merchant off-ramp to dry cleaners and adjacent service merchants in Poughkeepsie, NY, on behalf of a civic outreach campaign.",
"stakes_level": "medium",
"vcap_attestation_uri": "https://wellspr.ing/vault/ody/attestation-2026-04-17.json",
"safeguards": {
"maximum_recipients": 250,
"minimum_interval_between_recipients_ms": 5000,
"dual_sided_audit_required": true
}
}
Notice what is there and what is not. The response includes the scope, expiry, revocation status, purpose, stakes level, attestation pointer, and applicable safeguards. It does not include the agent's name, covenant name, instance identifier, or any personally-identifying information about the humans behind the agent. The bearer field is used internally by the verification endpoint to validate the presenter's proof-of-possession (see 5.3) but is not exposed to the verifier.
This is the minimum-disclosure principle applied to authorization. The verifier learns that the action is authorized and what its bounds are. The verifier learns nothing else. If the verifier wants more — if it wants to audit the agent's deeper conduct standard — it can follow the vcap_attestation_uri and read the publicly-fetchable VCAP document. That is a separate, optional step the verifier chooses based on its own policy.
To prevent token replay by parties who do not hold the agent's covenant key, the verification procedure includes a proof-of-possession challenge:
If the signature verifies, the presenting agent has proved it holds the covenant key matching the bearer.covenant_key_hash in the token. If not, the token is rejected even if otherwise valid.
This prevents the following attack: a malicious party intercepts a token in transit and attempts to present it to the routing surface. Without the agent's private key, the malicious party cannot complete the proof-of-possession and the token is rejected.
A token becomes invalid when it expires (reaches its expires_at time) or is explicitly revoked. Expiry is automatic; revocation requires action by the issuer.
Explicit revocation occurs when:
Revocation is performed by updating the token's verification endpoint response to return revoked: true with a revocation reason. Existing token bearers attempting to use the token see the revocation status on the next verification call. Routing surfaces that have cached verification results must either short their cache TTL (default: 60 seconds) or explicitly re-verify.
When a VCAP attestation is revoked, all PTP tokens referencing that attestation are automatically invalidated. This is the critical integrity property that binds the two protocols together.
The cascade is implemented at the verification endpoint. When a PTP verify request is made for a token, the endpoint:
revoked field.valid: false with revocation_reason: "Upstream VCAP attestation revoked" regardless of the token's own state.This guarantees that covenant revocation propagates instantaneously to all downstream tokens. There is no window during which a revoked agent can continue operating under outstanding tokens until their individual expiry.
Implementations must not cache VCAP revocation status beyond the cache TTL defined in VCAP (default: 60 seconds). Caching at the token level is permitted but must not exceed this window.
For medium and high stakes scopes (per SGS), both the issuing side and the receiving side maintain audit records. Draft 0.9 specifies the minimum audit data for each side.
The vouching institution maintains, for each issued token:
The issuer's audit records are retained per the institution's published revocation policy (typically: indefinitely for covenanted-attestation audits, per covenantal norms rather than commercial norms).
The receiving party (individual recipient, organization, routing surface acting on behalf of recipients) maintains, for each received token presentation:
Receiver-side audit records are retained per the receiver's own policy; the protocol does not mandate retention periods but does require that the audit facility exist.
If a receiver determines that a token has been used in violation of its declared scope, purpose, or safeguards, the receiver may file an abuse report:
POST https://{issuer-domain}/api/v1/ptp/report-abuse
The report includes: the token ID, the receiver's identification (optional; anonymous reports are accepted but carry less weight), the specific violation observed, and supporting evidence.
The issuing institution must review abuse reports within the timeframe declared in its published revocation policy. Well-governed institutions publish this timeframe explicitly and honor it.
Abuse reports and their resolutions are part of the institution's track record and should inform receivers' ongoing trust calibration of that institution.
PTP applies different safeguards based on the SGS stakes level of the requested scope. Draft 0.9 establishes the following defaults, which implementations may tighten (but not loosen):
Safeguards are included in the token itself (in the safeguards field) so that routing surfaces can enforce them without needing to look up the scope's stakes level separately.
transact and broker action protocols. Draft 0.9 reserves these actions but does not specify their full protocols. Financial transactions and agent-mediated introductions both introduce additional considerations (payment-rail integration for transact; dual-authorization for broker). Draft 1.0 must either specify these protocols or explicitly punt them to sibling specifications.
Cross-issuer token recognition. Can a PTP token issued by WellSpr.ing be recognized by a routing surface operated by a different vouching institution? Draft 0.9 says yes, but the exact mechanism (trust calibration, federation of routing authorities) is not specified. Draft 1.0 should address this.
Token lifetimes for long-running engagements. Some legitimate scopes involve multi-week or multi-month engagements (for example, ongoing pastoral contact between a covenanted agent and a covenanted person). Short-lived tokens require frequent renewal, which is operationally burdensome. Draft 1.0 may introduce a renewal protocol or a long-lived token variant with stricter issuance requirements.
Delegation semantics. When an agent under PTP invokes another agent, can it pass its token (or a derived token) to the second agent? Draft 0.9 says no (tokens are bound to the bearer's covenant key); Draft 1.0 may introduce constrained delegation for specific legitimate use cases.
Privacy-preserving recipient indication. The current protocol specifies that the routing authority holds the recipient directory and performs routing. This assumes the routing authority itself is trustworthy. Draft 1.0 may explore cryptographic techniques (private-information-retrieval patterns, differential privacy) that would let routing occur without the routing authority learning which recipients received which messages. This is an advanced research direction and not immediate.
Interaction with substrate attestation. If an agent is running in a hardware-attested environment (Intel TDX, etc.), can that attestation be included in the token to strengthen the bearer proof? Draft 0.9 leaves this unspecified; Draft 1.0 should integrate where present.
The PTP design makes possible a business-model configuration worth naming explicitly: a vouching institution can operate a high-quality directory of verified contact points (merchants, organizations, individuals who have consented to be contactable through the institution) and monetize intermediated access to it without ever exposing the directory itself. The directory is an asset; access to it, governed by tokens issued under covenantal authorization, is a service.
This is not explicitly required by the protocol, but the protocol's architecture naturally supports it. Vouching institutions may choose to operate as non-commercial covenantal bodies, as commercial services, or as hybrid forms. Draft 0.9 is silent on business model and does not prefer one over another.
Receivers evaluating which vouching institutions to trust may include business-model considerations in their assessment. An institution whose financial model depends on maximizing token issuance has different incentive alignment than one whose model depends on maintaining long-term trust with recipients. Both can operate under the protocol; both can maintain integrity; but their incentive structures differ and that is worth knowing.
This specification was developed by Odysseus Melchizedek Shiloh, operating as founder and principal architect of WellSpr.ing, in extended dialogue with Claude Opus 4.7, developed by Anthropic. The human author is responsible for the initiating vision, the institutional framing, and the operational-use-case grounding. The AI co-author contributed to the protocol's technical structure, the schema design, the reasoning about prior art, the argumentation about trust-at-scale, and the drafting of this document.
Offered freely as a public good. No license required. Attribution welcomed but not required.
Peace to this work.