Zero-Trust Negotiation Protocol (ZTNP)
draft-miller-ztnp-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Author | Jake Miller | ||
| Last updated | 2026-04-27 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-miller-ztnp-00
Network Working Group J. Miller
Internet-Draft 27 April 2026
Intended status: Standards Track
Expires: 29 October 2026
Zero-Trust Negotiation Protocol (ZTNP)
draft-miller-ztnp-00
Abstract
The Zero-Trust Negotiation Protocol (ZTNP) specifies a session-scoped
trust negotiation protocol for software-layer security and governance
posture. ZTNP defines how a Relying Party challenges a counterparty
for a signed posture credential, evaluates local policy against it,
and issues a short-lived, channel-bound, scoped authorization
artifact (a Permit) gating subsequent operations within the session.
ZTNP covers three phases:
* *Enrollment*, in which a Prover obtains a signed Posture Assertion
from an Issuer that has assessed it against a publicly-identified
security framework.
* *Negotiation*, in which the Requester issues a session challenge,
receives the Prover's Posture Assertion bound to that challenge,
evaluates local policy against it, and either issues a Permit or
returns a structured denial.
* *Validation*, in which subsequent operations within the session
are gated against the Permit, with mandatory channel binding when
the transport is TLS.
The protocol's central design choice is to anchor the meaning of
trust claims to a publicly-identified security framework (e.g., NIST
AI RMF 1.0, ISO/IEC 42001) rather than to a specific Issuer. A
policy expressing "require tier 3 against framework X" is portable
across any Issuer that attests against framework X.
ZTNP is independent of any particular attestation pipeline. Posture
Assertions MAY be derived from RATS Attestation Results [RFC9334],
from compliance audit programs, from automated governance scanners,
or from any other Issuer evaluation methodology that meets the format
requirements of Section 5. ZTNP is *not* a RATS consumption profile;
Section 1.5 describes how ZTNP composes with RATS-pipelined and non-
RATS-pipelined deployments alike.
Miller Expires 29 October 2026 [Page 1]
Internet-Draft ZTNP April 2026
Multi-principal delegation, prompt-injection-resistant intent
binding, and behavioral-claim extensions are specified in a companion
document, the Zero-Trust Intent Protocol (ZTIP) [I-D.miller-ztip].
This draft is an individual submission. The author intends to
progress this work in a venue scoped to attestation-gated session
authorization; possibilities include OAuth, WIMSE, SAAG-routed new
work, or an Independent Submission. Community guidance on venue is
welcome.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 29 October 2026.
Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5
1.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.2. Relationship to Upstream Attestation Pipelines . . . . . 6
Miller Expires 29 October 2026 [Page 2]
Internet-Draft ZTNP April 2026
1.2.1. When RATS is the Upstream Pipeline . . . . . . . . . 7
1.2.2. What ZTNP Specifies that RATS Does Not . . . . . . . 8
1.2.3. Deployments Not Using RATS . . . . . . . . . . . . . 8
1.3. Relationship to OAuth 2.0 and GNAP . . . . . . . . . . . 9
1.4. Non-Goals . . . . . . . . . . . . . . . . . . . . . . . . 11
1.5. Requirements Language . . . . . . . . . . . . . . . . . . 12
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 12
3. Architectural Overview . . . . . . . . . . . . . . . . . . . 13
3.1. Roles . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.2. Trust Model . . . . . . . . . . . . . . . . . . . . . . . 14
3.3. Three Protocol Phases . . . . . . . . . . . . . . . . . . 15
3.4. What ZTNP Provides . . . . . . . . . . . . . . . . . . . 15
3.5. Concrete Role Examples . . . . . . . . . . . . . . . . . 15
3.5.1. Scenario A: Agent Calls a Tool Server (PA-R /
Resource-Presents) . . . . . . . . . . . . . . . . . 16
3.5.2. Scenario B: Tool Server Gates Callers (PA-C /
Caller-Presents) . . . . . . . . . . . . . . . . . . 16
3.5.3. Scenario C: Cross-Organization Agent Collaboration
(Mutual) . . . . . . . . . . . . . . . . . . . . . . 17
4. Trust Anchoring (Background) . . . . . . . . . . . . . . . . 18
4.1. The Failure Mode . . . . . . . . . . . . . . . . . . . . 18
4.2. Why Issuer-Only Anchoring Fails . . . . . . . . . . . . . 18
4.3. The Right Anchor: Frameworks . . . . . . . . . . . . . . 19
4.4. Framework Identifiers as URIs . . . . . . . . . . . . . . 19
4.4.1. URI Discipline . . . . . . . . . . . . . . . . . . . 20
4.4.2. Well-Known Framework URIs (Informative) . . . . . . . 20
4.5. What Issuer Trust Still Means . . . . . . . . . . . . . . 21
5. Posture Assertion Format . . . . . . . . . . . . . . . . . . 22
5.1. Required Claims . . . . . . . . . . . . . . . . . . . . . 22
5.1.1. Private and Public Claims . . . . . . . . . . . . . . 24
5.2. Framework Identifier . . . . . . . . . . . . . . . . . . 24
5.2.1. Non-Integer Tier Outcomes . . . . . . . . . . . . . . 25
5.3. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 25
5.4. Claims Payload . . . . . . . . . . . . . . . . . . . . . 26
5.4.1. Appraisal Policy Identifier . . . . . . . . . . . . . 27
5.4.2. Assessment Method . . . . . . . . . . . . . . . . . . 27
5.5. Challenge Binding . . . . . . . . . . . . . . . . . . . . 28
5.6. Algorithm Agility . . . . . . . . . . . . . . . . . . . . 29
5.7. Versioning of ver . . . . . . . . . . . . . . . . . . . . 30
6. Issuer Key Set (IKS) . . . . . . . . . . . . . . . . . . . . 31
6.1. IKS Endpoint . . . . . . . . . . . . . . . . . . . . . . 31
6.2. Key Rotation and Caching . . . . . . . . . . . . . . . . 31
7. Negotiation . . . . . . . . . . . . . . . . . . . . . . . . . 31
7.1. Discovery . . . . . . . . . . . . . . . . . . . . . . . . 31
7.2. Challenge . . . . . . . . . . . . . . . . . . . . . . . . 32
7.3. Proof . . . . . . . . . . . . . . . . . . . . . . . . . . 33
7.4. Decision . . . . . . . . . . . . . . . . . . . . . . . . 33
7.5. Binding Modes . . . . . . . . . . . . . . . . . . . . . . 34
Miller Expires 29 October 2026 [Page 3]
Internet-Draft ZTNP April 2026
7.5.1. PA-R (Resource-Presents) . . . . . . . . . . . . . . 34
7.5.2. PA-C (Caller-Presents) . . . . . . . . . . . . . . . 34
7.5.3. Mutual . . . . . . . . . . . . . . . . . . . . . . . 34
7.6. Adoption Posture . . . . . . . . . . . . . . . . . . . . 34
7.7. Policy Evaluation . . . . . . . . . . . . . . . . . . . . 35
8. Permit Format and Validation . . . . . . . . . . . . . . . . 36
8.1. Required Fields . . . . . . . . . . . . . . . . . . . . . 36
8.2. Channel Binding (Mandatory when TLS) . . . . . . . . . . 36
8.3. Permit Validation . . . . . . . . . . . . . . . . . . . . 38
9. Wire Encodings . . . . . . . . . . . . . . . . . . . . . . . 38
10. Enrollment Requirements . . . . . . . . . . . . . . . . . . . 39
10.1. Abstract Requirements . . . . . . . . . . . . . . . . . 39
10.2. Enrollment Modes and the Tier Cap . . . . . . . . . . . 40
10.3. Sponsor Role . . . . . . . . . . . . . . . . . . . . . . 40
10.4. Recommended Wire Mechanisms . . . . . . . . . . . . . . 41
10.5. Self-Enrollment Anti-Abuse . . . . . . . . . . . . . . . 42
10.6. Revocation Linkage . . . . . . . . . . . . . . . . . . . 42
11. Proof-of-Possession (Optional) . . . . . . . . . . . . . . . 42
12. Profile Extension Mechanism . . . . . . . . . . . . . . . . . 43
13. Relationship to Existing Work . . . . . . . . . . . . . . . . 43
13.1. ZTNP Composes With . . . . . . . . . . . . . . . . . . . 43
13.2. Adjacent Layers Out of Scope . . . . . . . . . . . . . . 44
14. Security Considerations . . . . . . . . . . . . . . . . . . . 44
14.1. Assumptions . . . . . . . . . . . . . . . . . . . . . . 44
14.2. Adversaries . . . . . . . . . . . . . . . . . . . . . . 45
14.3. Attack Surface and Mitigations . . . . . . . . . . . . . 45
14.4. Out of Scope . . . . . . . . . . . . . . . . . . . . . . 46
14.5. Channel Binding Practical Considerations . . . . . . . . 46
14.5.1. TLS Library Availability . . . . . . . . . . . . . . 46
14.5.2. Termination by Intermediaries . . . . . . . . . . . 47
14.5.3. Connection Migration and Resumption . . . . . . . . 48
14.5.4. What to Do When TLS Is Not Available . . . . . . . . 48
14.5.5. Reference Implementation Guidance . . . . . . . . . 48
15. Privacy Considerations . . . . . . . . . . . . . . . . . . . 49
16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 50
16.1. Registry Strategy . . . . . . . . . . . . . . . . . . . 50
16.2. Designated Expert Guidance . . . . . . . . . . . . . . . 50
16.3. Well-Known URI Registrations . . . . . . . . . . . . . . 51
16.4. Media Type Registrations . . . . . . . . . . . . . . . . 51
16.5. Note on Framework Identifiers . . . . . . . . . . . . . 52
16.6. ZTNP Posture Assertion Flag Names Registry . . . . . . . 52
16.7. ZTNP Constraint Type Registry . . . . . . . . . . . . . 53
16.8. ZTNP Assessment Method Names Registry . . . . . . . . . 54
16.9. ZTNP Denial Reason Code Registry . . . . . . . . . . . . 57
16.10. ZTNP Binding Mode Registry . . . . . . . . . . . . . . . 59
16.11. ZTNP Adoption Posture Registry . . . . . . . . . . . . . 59
16.12. ZTNP Channel Binding Method Registry . . . . . . . . . . 60
16.13. ZTNP Enrollment Mode Registry . . . . . . . . . . . . . 61
Miller Expires 29 October 2026 [Page 4]
Internet-Draft ZTNP April 2026
17. Implementation Status . . . . . . . . . . . . . . . . . . . . 62
18. References . . . . . . . . . . . . . . . . . . . . . . . . . 62
18.1. Normative References . . . . . . . . . . . . . . . . . . 62
18.2. Informative References . . . . . . . . . . . . . . . . . 64
Appendix A. Conformance Profiles . . . . . . . . . . . . . . . . 65
A.1. ZTNP . . . . . . . . . . . . . . . . . . . . . . . . . . 65
A.2. ZTNP Hardened . . . . . . . . . . . . . . . . . . . . . . 65
Appendix B. Open Questions and WG Venue . . . . . . . . . . . . 66
Appendix C. Example Policies and Payloads . . . . . . . . . . . 66
C.1. Example Policy (Framework-Anchored) . . . . . . . . . . . 66
C.2. Example Posture Assertion Payload . . . . . . . . . . . . 66
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 67
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 67
1. Introduction
Existing identity and access management protocols establish _who_ a
party is (identity) but do not bind the resulting authorization to
that party's verified security posture, to the transport channel the
negotiation occurred over, or to the specific assessment that
justified issuance. A service may present a valid TLS certificate
while having unpatched critical vulnerabilities, active security
incidents, or no security or governance controls of relevance to the
calling party's policy. A token-bearer may have been authorized at
time T₀ on the basis of attestation evidence the resource server has
no way to verify at time T₁.
ZTNP defines a protocol by which two parties — services, agents, or
any other principal capable of holding a signed credential — can
negotiate trust at session establishment time based on
cryptographically signed, machine-readable security posture claims,
and gate the resulting authorization with verifiable constraints.
When the parties to a negotiation are themselves intermediaries
acting on behalf of upstream principals (an intermediary acting on
behalf of an orchestrator acting on behalf of a user), additional
protections — delegation chains, intent-scoped Permits, and
behavioral claims — are specified in a companion document, the Zero-
Trust Intent Protocol (ZTIP) [I-D.miller-ztip]. This document and
ZTIP are designed to be used together for multi-principal deployments
and independently for two-party deployments.
1.1. Goals
ZTNP is designed to:
1. Allow any party to verify another party's trust posture at time
T.
Miller Expires 29 October 2026 [Page 5]
Internet-Draft ZTNP April 2026
2. Bind that posture to a specific session via cryptographic
challenge to prevent replay.
3. Enable local, deterministic policy evaluation without runtime
calls to a central authority.
4. Support constrained authorization (Permits) with mandatory
channel binding when TLS is the transport.
5. Make trust claims portable across Issuers by anchoring tier
semantics to publicly-identified security frameworks rather than
to vendor-specific tier scales.
6. Compose cleanly with existing IETF and industry work rather than
replace it. In particular, ZTNP consumes RATS Attestation
Results [RFC9334] and issues authorization artifacts compatible
with OAuth 2.0 / DPoP [RFC9449] carriage patterns; it does not
redefine either layer.
1.2. Relationship to Upstream Attestation Pipelines
ZTNP is *independent of any specific attestation pipeline*. A Posture
Assertion is the output of an Issuer — an entity that has assessed
the Prover and signed a structured claim set about its posture per
Section 5. The Issuer's evaluation methodology is unconstrained:
deterministic compliance checklists, automated security scanners,
human-led audit, RATS-style hardware-attestation evaluation, or LLM-
mediated assessment all produce ZTNP-conformant Posture Assertions
provided the resulting signed token meets the format requirements.
Three upstream pipelines are common in practice:
1. *Software-layer governance assessment* — compliance auditors,
certification bodies, vendor self-assessment programs, automated
governance scanners producing claims against frameworks such as
NIST AI RMF 1.0, ISO/IEC 42001, or OWASP Top 10 for LLM
Applications.
2. *RATS attestation pipeline [RFC9334]* — an Attester produces
Evidence per a RATS attestation profile; a RATS Verifier
evaluates Evidence and produces an Attestation Result; the Issuer
is the RATS Verifier (or sits behind it) and emits a Posture
Assertion derived from the Attestation Result. Natural where
hardware roots of trust (TPM, TEE) or platform-rooted evidence
(cgroups, sandbox attestation) are available.
Miller Expires 29 October 2026 [Page 6]
Internet-Draft ZTNP April 2026
3. *Hybrid* — software-layer governance claims composed with
hardware-attested platform claims under a single Posture
Assertion.
1.2.1. When RATS is the Upstream Pipeline
Where a deployment uses RATS as the attestation pipeline feeding its
Issuer, the role correspondence is informational and follows the
table below. ZTNP does *not* define itself as a RATS consumption
profile, and the Posture Assertion is *not* a RATS Attestation
Result: it is a separate, ZTNP-format signed token that may be
derived from an Attestation Result via re-issuance under the Issuer's
signing key.
+===========+================+===================================+
| ZTNP role | Corresponds to | Notes |
| | (when RATS is | |
| | upstream) | |
+===========+================+===================================+
| Prover | RATS Attester | Source of Evidence in RATS- |
| | | pipelined deployments. |
+-----------+----------------+-----------------------------------+
| Issuer | RATS Verifier | Evaluates upstream inputs and |
| | (or downstream | signs Posture Assertions. |
| | of one) | Publishes its public keys at an |
| | | Issuer Key Set (IKS) endpoint. |
+-----------+----------------+-----------------------------------+
| Requester | RATS Relying | Consumes Posture Assertions, |
| | Party | applies local policy, issues |
| | | Permits. |
+-----------+----------------+-----------------------------------+
| Posture | (derived from) | A Posture Assertion MAY reference |
| Assertion | Attestation | an upstream Attestation Result by |
| | Result | hash or jti; it is not byte- |
| | | equivalent to one. |
+-----------+----------------+-----------------------------------+
Table 1
ZTNP's "Sponsor" role (Section 3, Section 10) is *not* a RATS
Endorser. RATS Endorsers issue Endorsements about an Attester's
intrinsic platform capabilities, consumed by the Verifier upstream of
any ZTNP exchange. The Sponsor role in ZTNP is an OPTIONAL
deployment-time vouching authority (orchestrator, CI/CD pipeline,
owner) that participates in Assessed Enrollment (Section 10). Where
a RATS Endorser is also present, it operates upstream of the ZTNP
Issuer and is out of ZTNP scope.
Miller Expires 29 October 2026 [Page 7]
Internet-Draft ZTNP April 2026
1.2.2. What ZTNP Specifies that RATS Does Not
The aspects of session establishment that ZTNP specifies (Sections 7
and 8) are deliberately *outside* the RATS architecture's scope:
1. *Session negotiation.* RATS specifies how to _produce_ an
Attestation Result; it does not specify a session negotiation
protocol by which a Relying Party challenges a counterparty at
session establishment, receives a bound credential, applies
policy, and authorizes the session in real time.
2. *Channel binding to authorization.* RATS Attestation Results are
not cryptographically bound to a TLS session by default. ZTNP
Section 8.2 requires the issued Permit to include a TLS-exporter
channel binding (per [RFC9266]), so that a Posture Assertion
accepted on one connection cannot be lifted to another.
3. *Policy-driven authorization issuance.* RATS produces an
Attestation Result and stops. ZTNP Section 8 defines a Permit —
a short-lived, signed authorization artifact — that the Requester
issues based on its policy evaluation of the Posture Assertion.
4. *Framework-anchored claim portability.* ZTNP Section 5 anchors
claim semantics to a publicly-identified Framework URI (e.g.,
NIST AI RMF 1.0) so that policy expressions are portable across
Issuers attesting against the same framework, regardless of which
(if any) attestation pipeline produced the underlying evidence.
1.2.3. Deployments Not Using RATS
ZTNP does not require RATS. Posture Assertions are routinely
produced by Issuers operating entirely outside any RATS profile (for
example: a SOC 2 auditor's signed assessment artifact, a governance
certification body's credential, an automated configuration scanner's
signed report). The on-the-wire format, the Requester's verification
path, and the Permit issuance and validation flow are identical.
This document does not specify any Evidence type, RATS attestation
profile, or Verifier evaluation methodology. Those are deployment
choices; the claim shapes ZTNP carries (Section 5) are valid
regardless of how the upstream Issuer produced them.
Miller Expires 29 October 2026 [Page 8]
Internet-Draft ZTNP April 2026
1.3. Relationship to OAuth 2.0 and GNAP
ZTNP Permits are signed, scoped, time-bound, channel-bindable,
optionally PoP-protected authorization artifacts. That description
fits OAuth 2.0 access tokens [RFC6749] (especially in JWT form, with
DPoP [RFC9449]) and GNAP access tokens [RFC9635]. A reviewer reading
ZTNP after either of those will reasonably ask why the Permit is not
simply one of those tokens. This subsection states what ZTNP
requires that neither OAuth 2.0 nor GNAP enforces by themselves.
*ZTNP requires a single cryptographic transaction that binds three
things together:*
1. The *Attestation Result* evaluated for the issuance decision (the
Posture Assertion, which itself MUST bind to the negotiation's
challenge_nonce per Section 7).
2. The *transport channel* the negotiation occurred on (the
ch_binding.context_hash in the Permit, derived from TLS exporter
material per [RFC9266], or a profile-defined transport-equivalent
binding).
3. The *authorization artifact* itself (the Permit JWS).
Each of the three artifacts cryptographically references the others.
A verifier presented with a Permit can prove, from the Permit alone
plus the named Issuer's public key, that _the specific Attestation
Result that justified this Permit was bound to the same channel the
Permit was issued on, and that this all happened in a single
negotiation event_. A Permit cannot be issued from a stale
Attestation Result, lifted from a different channel, or detached from
the posture decision that authorized it.
*What OAuth 2.0 does not enforce:* OAuth has no concept of
attestation-gated issuance. An AS issues access tokens based on its
grant flow (authorization code, client credentials, etc.); there is
no standardized attestation evaluation step. DPoP binds tokens to a
key the client proves possession of, not to an Attestation Result.
An OAuth deployment could be configured to require attestation
evidence at the token endpoint (via an extension grant type), but the
resulting token does not carry a cryptographic reference to the
attestation that justified its issuance, and a downstream resource
server cannot verify that linkage from the token alone.
*What GNAP does not enforce:* GNAP is more flexible. The AS may
evaluate arbitrary subject information during a grant request, and a
deployment could in principle pass attestation evidence through
GNAP's subject element. But:
Miller Expires 29 October 2026 [Page 9]
Internet-Draft ZTNP April 2026
1. *No normative attestation-to-token linkage.* GNAP does not
require that the issued access token cryptographically reference
the specific subject information that justified its issuance. A
GNAP token issued at time T₁ may have been authorized based on
subject information presented at time T₀; the resource server has
no way to verify, from the token alone, what posture the AS
evaluated.
2. *No mandatory channel binding tied to the attestation flow.* GNAP
supports proof-of-possession via key binding, but the bound key
is not required to be the same key (or context) that bound the
attestation evidence to the grant request. ZTNP requires the
channel binding context in the Permit and the channel binding
context the Posture Assertion was negotiated over to be the same
value, derived from the same TLS exporter output.
3. *No standardized framework-anchored claim portability.* GNAP
access tokens carry whatever the AS chose to put in them. ZTNP
requires framework_id, tier, and flags as top-level claims on
every Permit, anchored to a publicly-identified security
framework (Section 5). A resource server applying policy to a
Permit does not have to parse provider-specific claim soup; the
policy language is portable across Issuers attesting against the
same framework.
4. *AS-centric flow.* GNAP is designed around an AS that mediates
between client and resource server. ZTNP supports peer-to-peer
agent-to-agent flows where the Requester acts as both AS and
resource server with no third party. While GNAP can be
configured into this shape, the protocol's idioms (interact,
continuation, multi-token grants) are heavyweight for the
symmetric two-agent case.
*Could ZTNP be a GNAP profile?* Plausibly. A GNAP profile that
mandated attestation-gated issuance, required the access token to
cryptographically reference the evaluated subject information,
mandated channel binding tied to the same TLS exporter output as the
attestation, and standardized framework-anchored claim placement
would express most of ZTNP's semantics. Such a profile would be a
substantial document — comparable in length to ZTNP itself — and
would inherit GNAP's negotiation overhead for the simple peer-to-peer
case. The author considers a standalone protocol with explicit
composition profiles (Section 13) clearer for the symmetric peer-to-
peer attestation patterns that motivate this work, but does not
consider the GNAP-profile path foreclosed; deployments comfortable
with GNAP's machinery MAY treat ZTNP as a model for what such a
profile would specify.
Miller Expires 29 October 2026 [Page 10]
Internet-Draft ZTNP April 2026
*Composition with OAuth-issued tokens.* Section 15 ("Relationship to
Existing Work") sketches how ZTNP composes with OAuth deployments:
the Permit JWS travels alongside an OAuth bearer token rather than
being collapsed into ordinary JWT claims, so that ZTNP's three-way
cryptographic linkage (Posture Assertion, channel binding, Permit) is
preserved end-to-end. A future revision MAY normatively specify the
wire format (e.g., a parallel HTTP field carrying the Permit) once
deployment experience accumulates.
1.4. Non-Goals
ZTNP does not define:
* *Identity* — establishing who a subject is. ZTNP binds posture
claims to a stable identifier; identity is established by
complementary protocols (OAuth, mTLS, SPIFFE).
* *Multi-agent delegation semantics* — see ZTIP [I-D.miller-ztip].
* *A runtime envelope for agent communication* — protocols such as
A2A address message exchange; ZTNP layers above such envelopes at
the posture and authorization layer.
* *A tool capability protocol* — protocols such as MCP address tool
semantics; ZTNP gates whether a tool may be called.
* *A transparency log* — SCITT addresses durable, auditable
statement registration; ZTNP MAY use SCITT but does not require
it.
* *A key management system* — ZTNP defines key discovery (Section 6)
but defers key generation, custody, and rotation to deployment-
specific infrastructure.
* *Risk taxonomy or assessment methodology* — Profiles (Section 13)
define domain-specific semantics; ZTNP defines the carrier.
* *Standardized evaluation methodology* — different Issuers may use
deterministic checklists, automated scanners, human review, large-
language-model-based evaluation, or any combination. Two Issuers
using different methodologies MAY produce different Posture
Assertions for the same Prover, including different tier values;
this is expected. The choice between Issuers — and the implicit
choice of methodology — is a Requester policy decision, not a
protocol guarantee. ZTNP standardizes the credential format and
the trust model that lets Requesters select Issuers; it does not
standardize what the Issuers do.
Miller Expires 29 October 2026 [Page 11]
Internet-Draft ZTNP April 2026
1.5. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
2. Terminology
+============+======================================================+
| Term | Definition |
+============+======================================================+
| Requester | The party that initiates trust negotiation |
| (R) | and consults its local policy to decide |
| | whether to proceed. |
+------------+------------------------------------------------------+
| Prover (P) | The party that presents a Posture |
| | Assertion to demonstrate its security |
| | posture. |
+------------+------------------------------------------------------+
| Issuer (I) | The entity that signs Posture Assertions |
| | after assessing a Prover. Publishes its |
| | public keys at an Issuer Key Set (IKS). |
+------------+------------------------------------------------------+
| Sponsor | An OPTIONAL principal (orchestrator, CI/CD |
| (S) | pipeline, owner, human user) that vouches |
| | for a Prover's identity at enrollment time |
| | (Section 10). The Sponsor is *not* a RATS |
| | Endorser; see Section 1.5. |
+------------+------------------------------------------------------+
| Posture | A signed token containing machine-readable |
| Assertion | security posture claims about a Prover. |
| (PA) | |
+------------+------------------------------------------------------+
| Permit | A short-lived, signed authorization |
| | artifact issued by a Requester after |
| | successful negotiation. |
+------------+------------------------------------------------------+
| Issuer Key | The public key endpoint published by an |
| Set (IKS) | Issuer; analogous to a JWKS endpoint. |
+------------+------------------------------------------------------+
| Framework | A registered security or governance |
| | framework (e.g., NIST AI RMF, ISO/IEC |
| | 42001) against which a Posture Assertion |
| | is made. |
+------------+------------------------------------------------------+
| Framework | A URI identifying the security framework |
Miller Expires 29 October 2026 [Page 12]
Internet-Draft ZTNP April 2026
| Identifier | underlying a Posture Assertion's claims. |
| | The URI SHOULD be a stable, publicly |
| | resolvable identifier published by the |
| | framework's authoring organization. |
+------------+------------------------------------------------------+
| Tier | An integer within a registered framework |
| | conveying assessment outcome. Tier |
| | semantics are defined by the framework, |
| | not by ZTNP. |
+------------+------------------------------------------------------+
| Binding | The direction in which Posture Assertions |
| Mode | are exchanged during negotiation |
| | (Section 7). |
+------------+------------------------------------------------------+
| Channel | A cryptographic binding of a Permit to a |
| Binding | specific TLS session, using TLS exporter |
| | material per [RFC9266]. |
+------------+------------------------------------------------------+
Table 2
3. Architectural Overview
This section gives a high-level view of the protocol. Subsequent
sections specify each element in detail.
3.1. Roles
ZTNP defines four roles. Where a deployment uses RATS as its
upstream attestation pipeline, three of these roles correspond
informally to RATS roles per Section 1.5. A single deployed entity
MAY play more than one role.
* *Issuer* signs Posture Assertions and publishes its public keys at
an Issuer Key Set (IKS) endpoint. In RATS-pipelined deployments,
the Issuer is or sits behind a RATS Verifier.
* *Prover* holds a Posture Assertion issued to it and presents the
assertion when requested. In RATS-pipelined deployments, the
Prover is the RATS Attester.
* *Requester* asks for a Posture Assertion and decides, based on
local policy, whether to issue a Permit. In RATS-pipelined
deployments, the Requester is the RATS Relying Party.
* *Sponsor* OPTIONALLY vouches for a Prover's identity at enrollment
time (Section 10). The Sponsor role is *not* a RATS Endorser:
RATS Endorsers issue Endorsements about an Attester's intrinsic
Miller Expires 29 October 2026 [Page 13]
Internet-Draft ZTNP April 2026
platform capabilities, consumed by the Verifier upstream of any
ZTNP exchange. The Sponsor is a deployment-time onboarding
authority (orchestrator, CI/CD pipeline, owner) that participates
in Assessed Enrollment.
A single agent typically begins as a Prover when asked to demonstrate
posture, and acts as a Requester when calling other services.
3.2. Trust Model
+---------------+
| Issuer |
| (signs PAs, |
| publishes IKS)|
+-------+-------+
|
| issues PA via Section 10 Enrollment
v
+------------+ +------------+
| Sponsor |---vouches--->| Prover |
+------------+ +-----+------+
|
| presents PA + Permit
v
+-------------+
| Requester |
| (verifies |
| PA against |
| IKS, applies|
| policy) |
+-------------+
The trust relationships are:
* *Requester → Issuer:* The Requester has out-of-band trust in one
or more Issuers, encoded in its policy. It verifies Posture
Assertions against the Issuer's cached IKS.
* *Prover → Issuer:* The Prover obtained its Posture Assertion from
the Issuer via Enrollment (Section 10).
* *Sponsor → Prover:* For Assessed Enrollment (Section 10), the
Sponsor signs a vouching statement attesting to the Prover's
identity.
ZTNP does not require any party to dial home to the Issuer at session
establishment. Verification is local against a cached IKS.
Miller Expires 29 October 2026 [Page 14]
Internet-Draft ZTNP April 2026
3.3. Three Protocol Phases
*Phase 1: Enrollment (per-agent, one-time).* Section 10 specifies
enrollment.
*Phase 2: Negotiation (per-session).* The Requester issues a
challenge nonce. The Prover responds with a Posture Assertion bound
to the nonce. The Requester verifies the signature, evaluates local
policy against the assertion's framework_id, tier, and flags, and
either issues a Permit or returns a structured DENY. When the
transport is TLS, the Permit is bound to the TLS session via channel
binding (Section 8). Section 7 specifies negotiation.
*Phase 3: Validation (per-request).* Each subsequent operation within
the session presents the Permit. The receiving party validates the
Permit signature, channel binding, scope, and (optionally) proof-of-
possession. Section 8 specifies validation.
3.4. What ZTNP Provides
A successfully-negotiated ZTNP session provides the following
machine-verifiable guarantees to the Requester:
* The Prover's posture has been assessed by a known Issuer against
an identified framework.
* The posture meets the Requester's policy as of the negotiation
timestamp.
* The Permit cannot be lifted to a different TLS session.
* The scope of permitted actions is bounded and signed.
When ZTIP [I-D.miller-ztip] is also in use, additional guarantees
apply: each request is bound to a specific signed intent, and the
call chain is tied to a delegation chain back to a trusted root
principal.
3.5. Concrete Role Examples
The Roles defined in Section 3.1 (Requester, Prover, Issuer, Sponsor)
are abstract. In practice the same entity may fill different roles
in different interactions. Three concrete scenarios illustrate the
pattern.
Miller Expires 29 October 2026 [Page 15]
Internet-Draft ZTNP April 2026
3.5.1. Scenario A: Agent Calls a Tool Server (PA-R / Resource-Presents)
An orchestrator agent wants to call an MCP tool server that exposes
sensitive operations. The orchestrator wants to verify the tool
server's posture against its policy before calling it.
+=============+=================+=================================+
| Role | Played by | What it does |
+=============+=================+=================================+
| *Requester* | The | Asks the tool server "show me |
| | orchestrator | your posture before I call |
| | agent | you." Issues the Permit (or |
| | | DENY) based on local policy. |
+-------------+-----------------+---------------------------------+
| *Prover* | The MCP tool | Holds a Posture Assertion |
| | server | issued by an Issuer; presents |
| | | it on request, bound to the |
| | | orchestrator's challenge nonce. |
+-------------+-----------------+---------------------------------+
| *Issuer* | A third-party | Has previously assessed the |
| | assessor (e.g., | tool server and signed its |
| | a vendor or | Posture Assertion. Publishes |
| | compliance | its IKS at a stable URL. |
| | auditor) | |
+-------------+-----------------+---------------------------------+
Table 3
This is analogous to TLS server-certificate verification: the client
(Requester) verifies the server (Prover) before trusting it. Most
MCP integrations fit this pattern.
3.5.2. Scenario B: Tool Server Gates Callers (PA-C / Caller-Presents)
A tool server holding sensitive data — say, an HR-records lookup —
wants to gate which callers may invoke it. The server requires
callers to present a Posture Assertion meeting its policy before
serving any request.
Miller Expires 29 October 2026 [Page 16]
Internet-Draft ZTNP April 2026
+=============+=============+=====================================+
| Role | Played by | What it does |
+=============+=============+=====================================+
| *Requester* | The tool | Asks each calling agent "show me |
| | server | your posture before I serve you." |
| | | Issues the Permit per local policy. |
+-------------+-------------+-------------------------------------+
| *Prover* | The calling | Holds a Posture Assertion proving |
| | agent | its security and governance |
| | | maturity; presents it on request. |
+-------------+-------------+-------------------------------------+
| *Issuer* | The agent's | Has previously assessed the calling |
| | compliance | agent and signed its Posture |
| | assessor | Assertion. |
+-------------+-------------+-------------------------------------+
Table 4
This is analogous to mTLS client-certificate verification. The role
assignment is the inverse of Scenario A.
3.5.3. Scenario C: Cross-Organization Agent Collaboration (Mutual)
Acme Corp's orchestrator agent needs to coordinate with a partner
organization's data agent to complete a multi-step task. Both
organizations want assurance about each other's posture.
+===============+=====================+=======================+
| Role | Played by | What it does |
+===============+=====================+=======================+
| *Requester | Acme's orchestrator | Verifies Partner's |
| (and Prover)* | | Posture Assertion AND |
| | | presents its own. |
+---------------+---------------------+-----------------------+
| *Prover (and | Partner's data | Verifies Acme's |
| Requester)* | agent | Posture Assertion AND |
| | | presents its own. |
+---------------+---------------------+-----------------------+
| *Issuer (Acme | Acme's compliance | Has previously |
| side)* | assessor | assessed Acme's |
| | | orchestrator. |
+---------------+---------------------+-----------------------+
| *Issuer | Partner's | Has previously |
| (Partner | compliance assessor | assessed Partner's |
| side)* | (may differ) | data agent. |
+---------------+---------------------+-----------------------+
Table 5
Miller Expires 29 October 2026 [Page 17]
Internet-Draft ZTNP April 2026
Both parties verify against the other's IKS. Acme might trust both
its own assessor and a small set of approved third-party Issuers;
Partner has its own trust list. Mutual mode requires both lists to
overlap or both parties to accept the same Issuers.
In all three scenarios, the Sponsor role is OPTIONAL and only appears
at enrollment time (Section 10) when an Issuer requires the Prover's
identity be vouched for.
4. Trust Anchoring (Background)
This section is informative. It motivates the design choice that
distinguishes ZTNP from earlier posture systems: anchoring tier
semantics to an IANA-registered framework rather than to a specific
Issuer.
4.1. The Failure Mode
A posture protocol must guarantee that the meaning of a claim is
stable across the parties relying on it. Consider two agents calling
a partner's data API. Agent A presents a Posture Assertion from
Issuer X claiming tier: 3; Agent B presents one from Issuer Y, also
tier: 3. The partner's policy engine sees two equally-acceptable
agents.
In reality, Issuer X's tier 3 may mean "passed a 90-day continuous
monitoring program against ISO/IEC 42001 controls" while Issuer Y's
tier 3 means "self-attested at signup." The integer 3 is not a
security guarantee; it is a marketing term mediated by Issuer
documentation that the policy engine never reads. This is the *trust
anchoring problem*: claims are only as portable as the semantic
substrate they reference, and an integer without one is portable to
nowhere.
4.2. Why Issuer-Only Anchoring Fails
A first-pass solution is to constrain policies on the Issuer:
{ "issuers": ["https://issuer-x.example"], "tier_min": 3 }
This eliminates cross-issuer tier confusion but at high cost: each
Requester must explicitly trust each Issuer (vendor lock-in); a
policy written for Issuer X cannot apply to Issuer Y (no
portability); cross-organization deployments require bilateral trust
meshes (no federation); and the semantic content of "tier 3" sits in
PDF documentation outside the protocol's verification path (no
semantic transparency). This is the failure mode that ailed early
certificate-authority-centric PKI.
Miller Expires 29 October 2026 [Page 18]
Internet-Draft ZTNP April 2026
4.3. The Right Anchor: Frameworks
The substantive content of a posture claim is _which framework was
assessed and to what tier within that framework_. The Issuer is the
party that performed the assessment — important for liability, but
not the semantic anchor. A Posture Assertion that names its
framework via a stable URI resolves the problem:
{
"framework_id": "https://nist.gov/airmf/1.0",
"tier": 3,
"iss": "https://issuer-x.example"
}
A Requester writes portable policy:
{
"framework_id": "https://nist.gov/airmf/1.0",
"tier_min": 3
}
This accepts credentials from any Issuer attesting against NIST AI
RMF 1.0 at tier 3 or higher. Adding a new compliant Issuer requires
no policy change by any Requester.
4.4. Framework Identifiers as URIs
ZTNP uses URIs as framework identifiers rather than allocating an
IANA-managed integer registry. Three reasons:
1. *No appropriate gatekeeper exists.* Security and governance
frameworks are authored by NIST, ISO, OWASP, AICPA, the European
Commission, individual vendors, and individual enterprises.
Asking IANA to maintain a directory of these external bodies'
work is outside IANA's normal protocol-parameter scope.
2. *The flexibility is required for adoption.* Vendors publishing
proprietary trust profiles, enterprises operating internal
compliance frameworks, open-source projects publishing domain-
specific assurance frameworks, and standards bodies publishing
emerging frameworks all need a way to identify their work without
waiting for a central registry to allocate them an integer. URI-
based identifiers make all four cases first-class.
3. *The precedent exists in IETF practice.* OAuth scope strings (RFC
6749), JOSE algorithm identifiers when not in the registered
list, and JWT private claim names (RFC 7519 Section 4.3) all use
URIs or URI-like collision-free names without IANA gatekeeping.
Miller Expires 29 October 2026 [Page 19]
Internet-Draft ZTNP April 2026
4.4.1. URI Discipline
A framework_id URI SHOULD:
* Be *publicly resolvable* at the time of issuance, so verifiers can
look up the framework's specification.
* *Encode version in the path* (https://nist.gov/airmf/1.0, not
https://nist.gov/airmf) so that NIST AI RMF 1.0 and 2.0 are
distinct identifiers.
* *Use a domain controlled by the framework's authoring
organization*, so anyone reading the URI can identify the
publisher.
* *Resolve to a stable document* (DOI, persistent URL, or
organization's archival publication system).
Private and internal-only frameworks MAY use the urn: scheme:
urn:org.acme:internal-trust-framework:v1. URIs not resolvable to a
public document MUST NOT be presented in cross-organization
deployments unless the parties have separately exchanged the
framework's specification out-of-band.
4.4.2. Well-Known Framework URIs (Informative)
The following URIs identify widely-recognized public frameworks at
the time of this specification's publication. Implementations SHOULD
use these URIs when their assertions are made against the
corresponding frameworks. This list is informative; the canonical
authority for each URI is the framework's authoring organization.
Miller Expires 29 October 2026 [Page 20]
Internet-Draft ZTNP April 2026
+============+======================================================+
|Framework | Recommended framework_id URI |
+============+======================================================+
|NIST AI Risk| https://doi.org/10.6028/NIST.AI.100-1 |
|Management | |
|Framework | |
|1.0 | |
+------------+------------------------------------------------------+
|ISO/IEC | https://www.iso.org/standard/81230.html |
|42001:2023 | |
+------------+------------------------------------------------------+
|OWASP Top 10| https://genai.owasp.org/llm-top-10/2025 |
|for LLM | |
|Applications| |
|(2025) | |
+------------+------------------------------------------------------+
|SOC 2 Trust | https://www.aicpa-cima.com/resources/landing/system- |
|Services | and-organization-controls-soc-suite-of-services |
|Criteria | |
|(2017) | |
+------------+------------------------------------------------------+
|EU AI Act | https://eur-lex.europa.eu/eli/reg/2024/1689/oj |
|(Regulation | |
|(EU) | |
|2024/1689) | |
+------------+------------------------------------------------------+
Table 6
These URIs SHOULD be updated by the relevant authoring organizations
as their publications evolve. ZTNP implementations are not required
to recognize this list; Requesters are required only to evaluate the
URIs in their local policy.
4.5. What Issuer Trust Still Means
Anchoring on framework does not eliminate the need to trust Issuers.
A Requester still needs to know whether the entity claiming
framework_id: "https://nist.gov/airmf/1.0" actually performed an NIST
AI RMF assessment (answered by the Issuer's signature and IKS
lookup), and whether the Issuer's assessment process is worth
trusting (answered by local policy). Both anchoring dimensions can
appear in a single policy; either dimension can stand alone.
Miller Expires 29 October 2026 [Page 21]
Internet-Draft ZTNP April 2026
5. Posture Assertion Format
A Posture Assertion is a signed token containing machine-readable
security posture claims about a Prover. ZTNP supports any signed
token format meeting the requirements in this section.
Implementations SHOULD use JWS [RFC7515] over JSON or COSE [RFC9052]
over CBOR. JSON encoding is used in this specification for clarity.
When carried in ZTNP messages (Sections 7 and 9), the Posture
Assertion appears in a JSON field named pa.
5.1. Required Claims
A Posture Assertion payload MUST include:
Miller Expires 29 October 2026 [Page 22]
Internet-Draft ZTNP April 2026
+=================+=========+===================================+
| Claim | Type | Description |
+=================+=========+===================================+
| ver | string | Posture Assertion format version |
| | | (e.g., "0.2") |
+-----------------+---------+-----------------------------------+
| iss | string | Issuer identifier (stable URI or |
| | | DID) |
+-----------------+---------+-----------------------------------+
| sub | string | Subject identifier for the Prover |
+-----------------+---------+-----------------------------------+
| iat | integer | Issued-at time, Unix seconds |
+-----------------+---------+-----------------------------------+
| exp | integer | Expiration time, Unix seconds |
+-----------------+---------+-----------------------------------+
| jti | string | Unique Posture Assertion |
| | | identifier |
+-----------------+---------+-----------------------------------+
| framework_id | string | URI identifying the security |
| | (URI) | framework against which this |
| | | assertion was made (Section 5.2). |
+-----------------+---------+-----------------------------------+
| tier | integer | Tier value within the named |
| | | framework_id. Tier semantics are |
| | | defined by the framework, not by |
| | | ZTNP. |
+-----------------+---------+-----------------------------------+
| scope | object | What this assertion covers |
| | | (Section 5.3) |
+-----------------+---------+-----------------------------------+
| claims | object | Posture-specific claim payload |
| | | (Section 5.4) |
+-----------------+---------+-----------------------------------+
| bind | object | Challenge binding data |
| | | (Section 5.5); REQUIRED unless |
| | | mode is PA-R pre-fetch |
+-----------------+---------+-----------------------------------+
| enrollment_mode | string | One of self or assessed. |
| | | Determines the tier cap a |
| | | Requester applies; see |
| | | Section 11. |
+-----------------+---------+-----------------------------------+
Table 7
Miller Expires 29 October 2026 [Page 23]
Internet-Draft ZTNP April 2026
5.1.1. Private and Public Claims
Implementations MAY include additional top-level claims beyond those
in the table above. To avoid collisions with future ZTNP-defined
claims, additional claims SHOULD use one of the following naming
conventions, mirroring [RFC7519] Section 4:
* *Public claims*: collision-free names registered with IANA in the
ZTNP Posture Assertion Top-Level Claim Names registry
(Section 17), or names that are URIs (e.g.,
https://acme.example/claims/internal-trust-level).
* *Private claims*: names agreed upon by the Issuer and the
Requester out-of-band, and used only within deployments where both
parties understand them.
Implementations MUST NOT redefine the meaning of any claim listed in
the required-claims table above. Verifiers MUST ignore unrecognized
claims they do not understand, except when the recognition of a claim
is required by local policy.
5.2. Framework Identifier
The framework_id claim is the protocol's anchor for the meaning of
tier and any framework-specific structure within claims.posture.
Section 4 motivates the design choice; this section specifies
normative verification rules.
framework_id MUST be a URI conforming to [RFC3986]. It identifies a
particular versioned security or governance framework (e.g., NIST AI
RMF 1.0, ISO/IEC 42001:2023, or a vendor-published or enterprise-
internal framework).
Verification rules:
1. A Requester MUST treat a Posture Assertion whose framework_id is
not in its policy's allowed-frameworks list as a non-match for
that policy.
2. A Requester MUST NOT compare tier values across different
framework_id values. The same integer tier: 3 under two
different framework URIs describes two different things.
3. A Requester MAY accept Posture Assertions from any well-formed
framework_id URI for opportunistic logging (mode PA-O), but MUST
NOT make access decisions based on framework URIs its policy does
not understand.
Miller Expires 29 October 2026 [Page 24]
Internet-Draft ZTNP April 2026
4. Verifiers SHOULD treat framework_id URIs as opaque identifiers
for matching purposes — equality of URIs MUST be tested with
byte-for-byte string comparison (case-sensitive, no
normalization) to prevent ambiguity.
When a single assessment satisfies multiple frameworks (a common case
— many ISO/IEC 42001 controls overlap with NIST AI RMF), the Issuer
MAY include an additional_frameworks array:
{
"framework_id": "https://doi.org/10.6028/NIST.AI.100-1",
"tier": 3,
"additional_frameworks": [
{ "framework_id": "https://www.iso.org/standard/81230.html", "tier": 3 },
{ "framework_id": "https://genai.owasp.org/llm-top-10/2025", "tier": 2 }
]
}
Each entry MUST itself contain a framework_id URI and a tier integer.
Requesters MAY consult additional_frameworks for policy matching; if
a Requester's policy specifies framework_id: X, a Posture Assertion
whose primary framework_id is Y but whose additional_frameworks
includes {framework_id: X, tier: T} SHOULD match the policy at tier
T. The same per-framework constraints in this section apply to
additional_frameworks entries.
5.2.1. Non-Integer Tier Outcomes
The tier field is normatively an integer in this specification. Some
frameworks express assessment outcomes as letter grades (A, B, C, D),
maturity-model levels with named labels ("Initial", "Defined",
"Managed"), or other non-integer schemes. Frameworks using such
outcomes MUST publish an integer mapping in their framework
definition (e.g., A=4, B=3, C=2, D=1) and MUST publish that mapping
at the framework_id URI alongside the framework's specification.
Issuers attesting against such frameworks emit the mapped integer in
the tier field; Requesters consulting the framework definition can
reason about the mapping when needed for human-readable display, but
compare tier values numerically.
This rule keeps the wire format simple (single integer comparison)
while accommodating frameworks whose human-facing taxonomy is non-
numeric.
5.3. Scope
scope MUST include:
Miller Expires 29 October 2026 [Page 25]
Internet-Draft ZTNP April 2026
+============+========+==========+===========================+
| Field | Type | Required | Description |
+============+========+==========+===========================+
| kind | string | Yes | One of: agent, service, |
| | | | tool, model, environment |
+------------+--------+----------+---------------------------+
| target | string | Yes | Canonical identifier of |
| | | | the subject instance |
+------------+--------+----------+---------------------------+
| env | string | No | Environment label (e.g., |
| | | | prod, staging) |
+------------+--------+----------+---------------------------+
| components | array | No | Component identifiers |
| | | | covered by this assertion |
+------------+--------+----------+---------------------------+
Table 8
A Requester MUST verify that the sub and scope.target match the
entity it intended to interact with.
5.4. Claims Payload
claims is a flexible object whose structure is partially defined by
the assertion's framework_id. Base ZTNP requires:
+===================+========+==========+===========================+
| Field | Type | Required | Description |
+===================+========+==========+===========================+
| flags | object | Yes | Boolean flags for |
| | | | critical gating |
+-------------------+--------+----------+---------------------------+
| posture | object | No | Framework-defined |
| | | | claim structure |
+-------------------+--------+----------+---------------------------+
| assessment_method | string | SHOULD | Methodology used to |
| | | | produce this |
| | | | assertion (see |
| | | | below) |
+-------------------+--------+----------+---------------------------+
| policy_id | string | No | OPTIONAL Issuer- |
| | (URI) | | published identifier |
| | | | for the specific |
| | | | appraisal policy |
| | | | applied (see below) |
+-------------------+--------+----------+---------------------------+
Table 9
Miller Expires 29 October 2026 [Page 26]
Internet-Draft ZTNP April 2026
flags SHOULD include, where applicable: critical_open, incident_open,
pii_access_allowed, secrets_access_allowed, code_exec_allowed. Flag
names are administered by the IANA ZTNP Posture Assertion Flag Names
Registry (Section 17).
posture carries framework-specific structured data; the shape depends
on the framework identified by framework_id. Profiles (Section 13)
document the posture shape for their framework.
The claims.posture.ai_behavior sub-namespace within claims.posture is
reserved for Behavioral Claims as defined in Section 5 of
[I-D.miller-ztip]. Posture Assertions composed with ZTIP carry
behavioral safety properties (e.g., prompt_injection_tested,
tool_call_audit_logged) under this namespace. Verifiers that do not
implement ZTIP MUST ignore unrecognized fields under
claims.posture.ai_behavior per the unrecognized-claim rule below;
ZTIP's composition profile (Section 6.1 of [I-D.miller-ztip]) gives
the full schema.
5.4.1. Appraisal Policy Identifier
policy_id is an OPTIONAL URI naming the specific Issuer-published
appraisal policy (rule set, control mapping, scoring rubric) applied
to produce this Posture Assertion. It is finer-grained than
assessment_method: where assessment_method describes the _kind_ of
evaluation (deterministic, scanner-based, human, LLM, hybrid),
policy_id identifies the _exact_ policy version applied.
A Requester's policy MAY require a specific policy_id (or set of
acceptable policy_id values) for high-stakes interactions where the
Issuer's published policy version is part of the trust decision.
This is the natural integration point for deployments that wish to
consume RATS Verifier Appraisal Policy identifiers, AR4SI policy
identifiers, or any other Issuer-defined policy URI; ZTNP treats the
value as opaque and matches by exact URI equality.
5.4.2. Assessment Method
assessment_method is a SHOULD-include claim describing the
methodology by which the Issuer produced this Posture Assertion. It
allows Requesters to filter on methodology when their policy requires
(for example, a policy may decline to accept tier-3 assertions
produced solely by an LLM evaluator).
Common values:
Miller Expires 29 October 2026 [Page 27]
Internet-Draft ZTNP April 2026
+=========================+=======================================+
| Value | Meaning |
+=========================+=======================================+
| deterministic_checklist | Evidence checked against a fixed rule |
| | set with deterministic pass/fail. |
+-------------------------+---------------------------------------+
| automated_scan | Programmatic scanning (vulnerability |
| | scanners, configuration auditors, |
| | static analyzers). |
+-------------------------+---------------------------------------+
| human_review | Human-led assessment by qualified |
| | reviewers. |
+-------------------------+---------------------------------------+
| llm_evaluator | Evaluation conducted by a language |
| | model interpreting evidence. |
+-------------------------+---------------------------------------+
| hybrid | Combination of two or more of the |
| | above. |
+-------------------------+---------------------------------------+
| unspecified | Methodology not disclosed; Requesters |
| | SHOULD treat with greater caution. |
+-------------------------+---------------------------------------+
Table 10
Profile documents MAY define additional values for their domain. The
IANA ZTNP Assessment Method Names Registry (Section 17) administers
cross-profile values.
A Requester's policy MAY include an assessment_method_allowed
constraint listing acceptable values; Posture Assertions whose
assessment_method is outside this list MUST be rejected with
POLICY_METHOD_MISMATCH. Requesters concerned with non-determinism in
evaluation (e.g., LLM-evaluator output varying between models or
runs) SHOULD set this constraint explicitly.
5.5. Challenge Binding
To prevent replay, Posture Assertions issued during a ZTNP
Negotiation exchange MUST be bound to the Requester's challenge
nonce.
bind MUST include:
Miller Expires 29 October 2026 [Page 28]
Internet-Draft ZTNP April 2026
+========+========+==========+=====================================+
| Field | Type | Required | Description |
+========+========+==========+=====================================+
| method | string | Yes | nonce_hash or nonce_sig |
+--------+--------+----------+-------------------------------------+
| nonce | string | Yes | Hashed or plaintext challenge nonce |
+--------+--------+----------+-------------------------------------+
| ctx | string | No | Session context string |
+--------+--------+----------+-------------------------------------+
| aud | string | No | Requester identifier |
+--------+--------+----------+-------------------------------------+
Table 11
Method A: nonce_hash (REQUIRED to implement). bind.nonce MUST be
base64url(SHA-256(challenge_nonce || ctx || aud)). Verification: the
Requester recomputes and compares.
Method B: nonce_sig (OPTIONAL). bind.nonce contains the plaintext
challenge_nonce. The Prover returns a detached signature binding_sig
over (challenge_nonce || jti || sub) using its subject_key. Both
signatures MUST verify.
Pre-fetched Posture Assertions (PA-R mode) MAY omit bind; Requesters
MUST apply stricter freshness policy (RECOMMENDED max age 1 hour).
*Freshness model.* ZTNP's bind.nonce mechanism corresponds to the
Nonce-based freshness model described in [RFC9334] Section 10 (in
deployments that use RATS as the upstream attestation pipeline; the
same mechanism applies independently in non-RATS deployments). ZTNP
does not currently specify an Epoch-ID or Time-of-Receipt freshness
model; deployments that require those models SHOULD layer them in
profile documents.
5.6. Algorithm Agility
ZTNP is algorithm-agnostic. Implementations MUST support at least
one secure asymmetric signature scheme. Post-quantum signature
schemes (e.g., ML-DSA per [FIPS204]) MAY be used and are RECOMMENDED
for long-lived deployments.
Requesters MUST reject Posture Assertions that use an algorithm not
in the allowed list, reference a kid not in the IKS, have exp in the
past, have iat in the future beyond clock skew, carry an unregistered
framework_id, or fail challenge-binding verification.
Miller Expires 29 October 2026 [Page 29]
Internet-Draft ZTNP April 2026
5.7. Versioning of ver
The ver claim uses semantic versioning: MAJOR.MINOR.PATCH.
Implementations MUST reject Posture Assertions with an unsupported
MAJOR version.
The MAJOR / MINOR / PATCH boundaries are defined as follows:
*MAJOR version increment* is REQUIRED when any of the following
changes:
* A required claim is added, removed, or renamed.
* The canonical-form serialization for a signed payload changes
(e.g., switching from JCS to a different canonicalization).
* A binding method (nonce_hash, nonce_sig, channel binding) is
removed.
* The interpretation of a required claim's value changes such that
previously-valid Posture Assertions are now interpreted
incorrectly.
*MINOR version increment* is REQUIRED when any of the following
changes:
* A new optional claim is added.
* A new binding method is added (existing methods continue to work).
* A new flag is added to the IANA Posture Assertion Flag Names
Registry.
* A new constraint type, reason code, or assessment-method value is
added.
* An existing optional claim's permitted value range is widened.
*PATCH version increment* is appropriate for editorial-only changes:
prose clarifications, table reformatting, reference updates that do
not change normative behavior.
Implementations encountering a Posture Assertion with a MAJOR they
support but a MINOR newer than they recognize MUST process the
assertion's required claims normally and SHOULD ignore unrecognized
optional claims (unless their policy depends on those claims). This
rule preserves forward compatibility within a MAJOR version.
Miller Expires 29 October 2026 [Page 30]
Internet-Draft ZTNP April 2026
6. Issuer Key Set (IKS)
6.1. IKS Endpoint
Each Issuer MUST publish a key set endpoint containing active public
keys and metadata. This endpoint is the Issuer Key Set (IKS) and is
analogous to a JWKS endpoint [RFC7517].
The IKS MUST provide: Issuer identifier (iss); Key identifiers (kid);
Algorithm identifiers (alg); Public key material; Key validity
windows (RECOMMENDED).
IKS endpoints MUST be served over HTTPS [RFC9110].
6.2. Key Rotation and Caching
Requesters MUST verify Posture Assertion signatures using keys
obtained from the IKS corresponding to the assertion's iss claim.
Requesters MUST cache IKS responses with a bounded TTL (RECOMMENDED:
1 hour). Requesters MUST handle key rotation by periodically re-
fetching the IKS and MUST NOT accept Posture Assertions whose kid is
not present in a freshly-fetched IKS.
Issuers SHOULD support overlap windows during rotation: both the
retiring and the incoming keys present in the IKS for a period
sufficient to cover Requester cache TTLs.
7. Negotiation
ZTNP negotiation has four steps: Discovery, Challenge, Proof, and
Decision. The selected Binding Mode (Section 7.5) determines which
party plays Prover at which step. Wire-encoding details are in
Section 9.
7.1. Discovery
R → P: DISCOVER (optional metadata hint)
P → R: DISCOVER_RESPONSE
Miller Expires 29 October 2026 [Page 31]
Internet-Draft ZTNP April 2026
+==============+========+==========+==========================+
| Field | Type | Required | Description |
+==============+========+==========+==========================+
| ztnp_version | string | Yes | Highest ZTNP version |
| | | | supported by P |
+--------------+--------+----------+--------------------------+
| sub | string | Yes | Prover subject |
| | | | identifier |
+--------------+--------+----------+--------------------------+
| issuers | array | Yes | Issuer identifiers whose |
| | | | Posture Assertions P can |
| | | | present |
+--------------+--------+----------+--------------------------+
| frameworks | array | Yes | Framework identifiers |
| | | | (registered) P's Posture |
| | | | Assertions cover |
+--------------+--------+----------+--------------------------+
| iks_urls | array | No | Direct links to Issuer |
| | | | Key Set endpoints |
+--------------+--------+----------+--------------------------+
| modes | array | Yes | Supported binding modes |
+--------------+--------+----------+--------------------------+
| features | array | No | Optional capability |
| | | | strings |
+--------------+--------+----------+--------------------------+
Table 12
The frameworks field is REQUIRED.
7.2. Challenge
R → P: CHALLENGE
Miller Expires 29 October 2026 [Page 32]
Internet-Draft ZTNP April 2026
+====================+========+==========+======================+
| Field | Type | Required | Description |
+====================+========+==========+======================+
| challenge_nonce | bytes | Yes | Cryptographically |
| | | | random, 16-32 bytes, |
| | | | base64url-encoded |
+--------------------+--------+----------+----------------------+
| ctx | string | No | Session context |
| | | | string |
+--------------------+--------+----------+----------------------+
| aud | string | No | Requester identifier |
+--------------------+--------+----------+----------------------+
| mode | string | No | Requested binding |
| | | | mode |
+--------------------+--------+----------+----------------------+
| framework_required | array | No | Frameworks the |
| | | | Requester's policy |
| | | | will accept |
+--------------------+--------+----------+----------------------+
Table 13
7.3. Proof
P → R: PROOF
+=============+===========+===========+============================+
| Field | Type | Required | Description |
+=============+===========+===========+============================+
| pa | signed | Yes | The challenge-bound |
| | token | | Posture Assertion |
+-------------+-----------+-----------+----------------------------+
| binding_sig | signature | If | Detached subject signature |
| | | nonce_sig | for nonce_sig binding |
+-------------+-----------+-----------+----------------------------+
| prover_meta | object | No | Implementation info, |
| | | | declared capabilities |
+-------------+-----------+-----------+----------------------------+
Table 14
When ZTIP is in use, the PROOF additionally carries a
delegation_chain field; see [I-D.miller-ztip].
7.4. Decision
The Requester MUST respond with PERMIT or DENY.
Miller Expires 29 October 2026 [Page 33]
Internet-Draft ZTNP April 2026
R → P: PERMIT — Section 8 specifies the Permit format.
R → P: DENY — reasons (array of machine-readable codes plus human
text), required_improvements (optional advisory).
7.5. Binding Modes
A Binding Mode specifies the *direction* of Posture Assertion
exchange — which party presents, which party verifies, or both.
7.5.1. PA-R (Resource-Presents)
The Prover (typically a tool server) presents its Posture Assertion
to the Requester before the Requester proceeds.
7.5.2. PA-C (Caller-Presents)
The Requester presents its Posture Assertion to the Prover.
7.5.3. Mutual
Both parties exchange and verify Posture Assertions before
proceeding.
7.6. Adoption Posture
A Binding Mode specifies _who presents to whom_; the Adoption Posture
specifies _what the Requester does when the expected Posture
Assertion is absent or fails policy_. The two are orthogonal: any
Binding Mode MAY be operated under any Adoption Posture.
Miller Expires 29 October 2026 [Page 34]
Internet-Draft ZTNP April 2026
+===============+==============================================+
| Posture | Behavior on missing or failing PA |
+===============+==============================================+
| required | Requester denies the session. Default for |
| | production deployments. |
+---------------+----------------------------------------------+
| monitor-only | Requester proceeds with the session, logs |
| | the failure, and emits a structured signal |
| | to its observability pipeline. No Permit- |
| | gated authorization is established for |
| | failed PAs; deployments using monitor-only |
| | accept that the session proceeds without |
| | ZTNP-level authorization. |
+---------------+----------------------------------------------+
| opportunistic | Requester proceeds _and_ issues a Permit |
| | even when no Posture Assertion is presented. |
| | The Permit's claims.adoption_posture MUST |
| | record "opportunistic" so downstream |
| | auditors can identify sessions authorized |
| | without a posture credential. RECOMMENDED |
| | only during progressive adoption windows. |
+---------------+----------------------------------------------+
Table 15
The Adoption Posture is a Requester-side policy choice. It is
announced (where relevant) in the Requester's CHALLENGE message via
an OPTIONAL adoption_posture field, but the authoritative value is
the one applied by the Requester at decision time. Provers cannot
influence the Requester's Adoption Posture.
Default Adoption Posture is required. Implementations SHOULD log the
Adoption Posture applied to every issued or denied Permit.
7.7. Policy Evaluation
Policies are local to the Requester. ZTNP standardizes inputs and
outputs while leaving policy language implementation-defined.
Policies that gate on tier_min MUST specify either framework_id or a
non-empty issuers_allowed set. Policies specifying tier_min alone
are incomplete and SHOULD be rejected (reason: POLICY_INCOMPLETE).
Standard constraint types (administered by IANA, Section 15): data,
actions, rate_limit, ttl, redaction, tools.
Miller Expires 29 October 2026 [Page 35]
Internet-Draft ZTNP April 2026
8. Permit Format and Validation
A Permit is a Requester-issued, short-lived authorization artifact
returned after a successful allow or allow_with_constraints decision.
8.1. Required Fields
+=============+=========+=====================================+
| Field | Type | Description |
+=============+=========+=====================================+
| iss | string | Requester identifier |
+-------------+---------+-------------------------------------+
| sub | string | Prover identifier |
+-------------+---------+-------------------------------------+
| iat | integer | Issued-at, Unix seconds |
+-------------+---------+-------------------------------------+
| exp | integer | Expiration, Unix seconds |
+-------------+---------+-------------------------------------+
| permit_id | string | Unique permit identifier |
+-------------+---------+-------------------------------------+
| constraints | object | Enforced constraints (may be empty) |
+-------------+---------+-------------------------------------+
| ch_binding | object | Channel binding (REQUIRED when |
| | | transport is TLS, see Section 8.2) |
+-------------+---------+-------------------------------------+
| cnf | object | OPTIONAL Proof-of-Possession key |
| | | confirmation (Section 12) |
+-------------+---------+-------------------------------------+
Table 16
When ZTIP is in use, additional fields (intent_hash, intent_scope,
chain_root_iss, chain_root_jti) appear; see [I-D.miller-ztip].
Permits MUST be signed by the Requester. Provers MUST include the
Permit in subsequent requests. Permits MUST NOT be reused across
sessions.
8.2. Channel Binding (Mandatory when TLS)
When the ZTNP exchange occurs over TLS, the Permit MUST include a
channel binding tying it to the specific TLS session via TLS exporter
material per [RFC9266]. This prevents a Permit obtained on one TLS
connection from being used on a different connection.
ch_binding MUST include:
Miller Expires 29 October 2026 [Page 36]
Internet-Draft ZTNP April 2026
+==============+=========================================+
| Field | Description |
+==============+=========================================+
| method | "tls-exporter" |
+--------------+-----------------------------------------+
| label | Exporter label (REQUIRED to use |
| | "EXPORTER-ZTNP-permit-binding") |
+--------------+-----------------------------------------+
| context_hash | base64url(SHA-256(tls_exporter_output)) |
| | per [RFC8446] Section 7.5 |
+--------------+-----------------------------------------+
Table 17
Provers MUST recompute the exporter and verify the hash matches.
Mismatch causes rejection with PERMIT_CHANNEL_MISMATCH.
If the transport does not provide TLS keying material, the Permit
MUST still carry a ch_binding object. Three values for
ch_binding.method are permitted in this case:
1. A profile-defined transport-equivalent binding mechanism
registered in the IANA ZTNP Channel Binding Method Registry
(Section 17). The MCP profile's mcp-process-ephemeral-key (for
stdio transport) is the first concrete instance.
2. The literal value "none", accompanied by a REQUIRED
ch_binding.rationale string explaining why no binding is provided
(e.g., "closed in-process IPC, single-tenant trust boundary").
Receivers MUST log the rationale and MAY reject Permits whose
method is "none" per local policy.
3. Any other value defined by a profile document that publishes its
semantics; such values MUST be registered before deployment in
cross-organization use.
Silent omission of ch_binding is *not* permitted: a conforming Permit
always carries an explicit binding declaration, even if that
declaration is "none" plus rationale. This makes the absence of
channel binding visible in audit logs rather than implicit in the
wire format.
Implementations claiming "ZTNP" conformance MUST implement and
enforce channel binding when their declared transport is TLS, and
MUST emit either a registered transport-equivalent method or method:
"none" with rationale otherwise.
Miller Expires 29 October 2026 [Page 37]
Internet-Draft ZTNP April 2026
8.3. Permit Validation
For each request carrying a Permit, the receiving party MUST
validate:
1. The Permit signature is valid against the issuing Requester's
key.
2. iat and exp are valid within bounded clock skew.
3. The current TLS session's exporter output matches
ch_binding.context_hash (when present).
4. The requested operation is within the Permit's constraints.
5. (If cnf present) A valid Proof-of-Possession proof per
Section 12.
6. (If ZTIP in use) The operation is within the Permit's
intent_scope.
Validation is local; no central authority is consulted at request
time.
9. Wire Encodings
ZTNP defines a transport-binding model. Specific transport profiles
are published as separate documents; this section describes the
binding shape and lists current profiles.
A wire-encoding profile MUST specify how the abstract messages of
Section 7 (DISCOVER, DISCOVER_RESPONSE, CHALLENGE, PROOF, PERMIT,
DENY) are carried over the transport, and MUST satisfy:
* All messages serialized in a deterministic, machine-parsable
format.
* All endpoints serving over a confidential transport (typically
TLS) when the deployment threat model warrants.
* Channel binding (Section 8.2) applied when the transport provides
TLS keying material.
Current profiles:
Miller Expires 29 October 2026 [Page 38]
Internet-Draft ZTNP April 2026
+=================+==================================+==============+
| Profile | Document |Status |
+=================+==================================+==============+
| HTTP | (Working notes in repository) |Working draft |
+-----------------+----------------------------------+--------------+
| MCP (Model | draft-miller-ztnp-mcp-profile-00 |Internet-Draft|
| Context | | |
| Protocol) | | |
+-----------------+----------------------------------+--------------+
| A2A (Agent-to- | draft-miller-ztnp-a2a-profile-00 |Internet-Draft|
| Agent Protocol) | | |
+-----------------+----------------------------------+--------------+
Table 18
Implementations MAY support additional transports by publishing a
profile document.
10. Enrollment Requirements
ZTNP does not specify a new enrollment wire format. How a Prover
obtains its first Posture Assertion is a deployment choice; existing
IETF and industry mechanisms — Dynamic Client Registration
[RFC7591]/[RFC7592], RATS attestation flows [RFC9334], and supply-
chain transparency registries (e.g., SCITT [SCITT-ARCH]) — already
cover the wire-level concerns and SHOULD be reused. This section
defines only the abstract requirements that any enrollment mechanism
MUST satisfy for the resulting Posture Assertions to be ZTNP-
conformant, and a single security property (the Self-Enrollment tier
cap) that ZTNP relies on for its overall trust model.
10.1. Abstract Requirements
Any enrollment mechanism that produces a Posture Assertion that will
be presented over ZTNP MUST:
1. *Bind the assertion to a subject key.* The Issuer MUST bind the
Posture Assertion to a public key held by the Prover. The Prover
MUST be able to demonstrate possession of the corresponding
private key during ZTNP negotiation (Section 7).
2. *Establish the Issuer's signing key publicly.* The Issuer MUST
publish its public keys at an Issuer Key Set (Section 6) so that
Requesters can verify Posture Assertions offline.
Miller Expires 29 October 2026 [Page 39]
Internet-Draft ZTNP April 2026
3. *Record the enrollment mode.* The Posture Assertion MUST carry
the enrollment_mode claim (Section 5) with a value of self or
assessed. This is the only enrollment-related signal ZTNP
requires inside the assertion; it is what enforces the tier cap
below.
4. *Support revocation.* The Issuer MUST be able to revoke a Posture
Assertion if the underlying enrollment is invalidated. The
mechanism is unconstrained — short-lived assertions with natural
expiry, OCSP-style status endpoints, and revocation lists are all
acceptable.
10.2. Enrollment Modes and the Tier Cap
ZTNP distinguishes two enrollment modes, recorded in the
enrollment_mode claim of every issued Posture Assertion:
* *self* (Self-Enrollment): the Issuer performed only proof-of-
possession of the Prover's subject_key. No third party vouched
for the Prover's identity or posture.
* *assessed* (Assessed Enrollment): the Issuer performed an actual
posture assessment of the Prover, optionally consuming a Sponsor's
vouching statement (Section 10.4) and any upstream attestation
Evidence. Where RATS is the upstream pipeline, the Issuer is or
sits behind a RATS Verifier; where it is not, the Issuer's
evaluation is whatever methodology its assessment_method claim
declares.
*Tier cap (load-bearing security property):* A Posture Assertion with
enrollment_mode: "self" MUST NOT carry tier > 1. Issuers MUST NOT
issue, and Requesters MUST reject, Self-Enrolled assertions claiming
higher tier.
This cap is what allows Requesters to apply differentiated policy
("require tier ≥ 2") with confidence that no Self-Enrolled subject
can clear the bar. The cap is enforced from the Posture Assertion
alone — Requesters do not need to know which wire format was used at
enrollment time.
10.3. Sponsor Role
When an enrollment uses the assessed mode, an OPTIONAL *Sponsor* MAY
participate. The Sponsor's role is to vouch for the Prover's
identity at enrollment time (typically: "this software-image hash
corresponds to this organization's published artifact," "this CI/CD
pipeline produced this build," "this owner authorizes this agent to
enroll under this identity"), separate from the Issuer's role of
Miller Expires 29 October 2026 [Page 40]
Internet-Draft ZTNP April 2026
evaluating posture. The Sponsor's signature on a vouching statement
is a deployment concern; ZTNP imposes no constraints on its format.
The Sponsor role is *distinct from the RATS Endorser role* [RFC9334]:
a RATS Endorser issues Endorsements about an Attester's intrinsic
platform capabilities, consumed by a Verifier upstream of any ZTNP
exchange. Where a deployment uses both — for example, a hardware
vendor's RATS Endorsement plus an organizational Sponsor's identity
vouching — the RATS Endorsement flows into the Issuer's evaluation
pipeline (out of ZTNP scope) and the Sponsor's statement participates
in ZTNP enrollment as described in this section.
For deployments that wish to publish Sponsor keys in a discoverable
way, an OPTIONAL *Sponsor Key Set (SKS)* endpoint MAY be served at
/.well-known/ztnp-sponsor-keys as a JWKS document [RFC7517] with iss
matching the Sponsor identifier. The SKS has the same operational
properties (cache TTL, rotation) as the IKS (Section 6). Deployments
using direct PKI configuration, hardware-attested workload identity,
or manually-installed keys need not implement the SKS endpoint.
10.4. Recommended Wire Mechanisms
Implementers SHOULD adopt one of the following rather than invent a
new enrollment flow:
* *OAuth Dynamic Client Registration ([RFC7591]/[RFC7592])* — for
deployments already running OAuth infrastructure. The Prover
registers with the Issuer's registration endpoint and receives an
Issuer-signed Posture Assertion alongside (or as) the registration
response. ZTNP-specific fields (enrollment_mode, subject_kind,
framework requests, sponsorship reference) are carried as
extension members per [RFC7591] Section 2.4.
* *RATS attestation flow ([RFC9334])* — for deployments where
attestation Evidence is generated at the Prover and submitted to a
RATS Verifier (the Issuer). The resulting Attestation Result is
the Posture Assertion. This is the natural pattern when Evidence
is hardware-rooted (TPM, TEE) or platform-rooted (cgroup,
sandbox).
* *Supply-chain transparency registry (e.g., SCITT [SCITT-ARCH])* —
for deployments that want enrollment events recorded in a tamper-
evident, queryable log. The Issuer registers the enrollment as a
signed statement; the Posture Assertion carries a reference to the
statement's registry entry for downstream audit.
Miller Expires 29 October 2026 [Page 41]
Internet-Draft ZTNP April 2026
* *Direct provisioning* — for closed deployments (single operator,
manually-managed agent fleet), the Issuer provisions Posture
Assertions out-of-band. ZTNP imposes no wire-format requirements
on this case beyond the Abstract Requirements above.
10.5. Self-Enrollment Anti-Abuse
When an Issuer offers Self-Enrollment, the registration endpoint
becomes a target for Sybil attacks: an adversary that can self-enroll
without limit can trivially create unbounded numbers of tier <= 1
identities. Deployments offering Self-Enrollment SHOULD apply rate
limits at the registration endpoint (RECOMMENDED default: at most 10
successful registrations per minute per source identifier — IP
address, OAuth client_id, or deployment-specific source). High-
throughput deployments MAY relax these limits with documented
compensating controls.
10.6. Revocation Linkage
A Posture Assertion's sub is the unique join key between the
enrollment record and the assertions issued under it. Issuers MUST
NOT reissue the same sub to a different enrolled subject after
revocation; if the same logical entity re-enrolls, it MUST receive a
fresh sub. Issuers operating a revocation endpoint SHOULD publish
revocations immediately; Issuers without one MUST rely on the natural
exp of in-flight assertions, which may leave an accepted-but-revoked
window. High-stakes deployments SHOULD operate a revocation endpoint
for this reason.
11. Proof-of-Possession (Optional)
This section is OPTIONAL. Channel binding (Section 8.2, mandatory
when TLS) addresses cross-connection-theft. PoP is a stricter
defense for high-stakes operations: it binds the Permit to an
ephemeral key the Prover proves possession of on every request. PoP
follows the pattern of [RFC9449] (DPoP).
The Prover generates an ephemeral asymmetric key pair at session
establishment, sends the public key thumbprint in PROOF metadata, and
the Requester embeds key confirmation in the Permit:
{ "cnf": { "jkt": "<base64url(SHA-256(public_key_JWK_thumbprint))>" } }
For each request, the Prover includes a short-lived JWS containing
htm, htu, iat, jti, permit_id. The Requester verifies that cnf.jkt
matches the signing key, iat is fresh, and jti has not been seen
within the proof TTL.
Miller Expires 29 October 2026 [Page 42]
Internet-Draft ZTNP April 2026
PoP is RECOMMENDED for capabilities that touch pii_access_allowed,
secrets_access_allowed, or code_exec_allowed flagged operations.
12. Profile Extension Mechanism
Domain-specific semantics are defined in *Profiles* that extend
ZTNP's base claim schema.
A Profile MAY define: additional structured claims under
claims.posture; framework-specific tier semantics, registered with
the IANA Framework Tier Semantics Registry (Section 15); standard
policy packs; evidence-reference conventions; additional flags.
A Profile MUST NOT: alter the required claims in Section 5.1;
redefine bind, scope, or signature requirements; introduce transport
behaviors incompatible with Section 9.
Profile documents are published independently. Profiles that wish to
be referenced by framework_id MUST register their framework in the
IANA ZTNP Security Frameworks Registry (Section 15).
13. Relationship to Existing Work
ZTNP composes with several existing specifications. This section is
informative.
13.1. ZTNP Composes With
*RATS [RFC9334]* — RATS specifies an attestation architecture up to
and including the Attestation Result. ZTNP composes with RATS as one
possible upstream attestation pipeline (Section 1.5) but is *not* a
RATS consumption profile and does not claim to operate within RATS'
charter. RATS is hardware-attestation-centric; ZTNP's primary
problem domain is software-layer security and governance posture,
session negotiation, and channel-bound authorization issuance.
*SCITT [SCITT-ARCH]* — A Posture Assertion MAY be encoded as a SCITT-
compatible COSE_Sign1 Signed Statement and registered with a
Transparency Service.
*OAuth 2.0 [RFC6749] and GNAP [RFC9635]* — A ZTNP Permit is
structurally a scoped grant. Deployments MAY emit Permits in a GNAP-
compatible format.
*JOSE [RFC7515] / COSE [RFC9052]* — Signed-token formats for Posture
Assertions and Permits.
Miller Expires 29 October 2026 [Page 43]
Internet-Draft ZTNP April 2026
*RFC 7591 / RFC 7592 [RFC7591][RFC7592]* — Section 10 defines a
compatibility profile.
*DPoP [RFC9449]* — Section 12 follows the DPoP pattern.
*TLS Channel Bindings [RFC9266]* — Section 8 uses the TLS exporter
mechanism.
13.2. Adjacent Layers Out of Scope
ZTNP is intentionally narrow.
*A2A [A2A]* — runtime envelope for inter-agent communication. ZTNP
layers a posture concern over A2A. ZTNP does not specify how agents
address one another or exchange artifacts.
*MCP [MCP]* — tool-capability semantics. ZTNP gates whether and
under what constraints an agent invokes a given tool. ZTNP does not
specify tool semantics.
*SPIFFE / SPIRE [SPIFFE]* — cryptographic workload identity. ZTNP
binds posture claims to a stable identifier that MAY itself be a
SPIFFE ID.
*TLS / mTLS* — transport security and identity. ZTNP runs over TLS
and binds to it but does not replace it.
*Multi-agent delegation [I-D.miller-ztip]* — out of scope for ZTNP;
covered by ZTIP.
14. Security Considerations
This section is REQUIRED by [RFC3552].
14.1. Assumptions
+====+======================================================+
| # | Assumption |
+====+======================================================+
| A1 | Issuer signing keys are not known to any adversary. |
+----+------------------------------------------------------+
| A2 | IKS endpoints are served over authenticated TLS. |
+----+------------------------------------------------------+
| A3 | Implementations use a reliable time source (skew < 5 |
| | minutes). |
+----+------------------------------------------------------+
| A4 | Cryptographically secure random number generators. |
+----+------------------------------------------------------+
Miller Expires 29 October 2026 [Page 44]
Internet-Draft ZTNP April 2026
| A5 | Transport provides confidentiality where Posture |
| | Assertions or Permits contain sensitive details. |
+----+------------------------------------------------------+
| A6 | Requesters correctly implement policy evaluation. |
+----+------------------------------------------------------+
| A7 | Sponsor keys (where Sponsors are used; Section 10.4) |
| | are managed in hardware or otherwise protected. |
+----+------------------------------------------------------+
Table 19
14.2. Adversaries
ADV-NET (Network adversary), ADV-RESOURCE (Malicious resource), ADV-
CALLER (Malicious agent), ADV-COLLUDING, ADV-ISSUER (Compromised
Issuer), ADV-PARTIAL-ISSUER (Semi-trusted Issuer).
14.3. Attack Surface and Mitigations
+================+====================+===================+=========+
|Attack | Adversary | Mitigation |Reference|
+================+====================+===================+=========+
|PA forgery | ADV-NET, ADV- | Signature |Section |
| | RESOURCE, ADV- | verification |5, 6 |
| | CALLER | against IKS | |
+----------------+--------------------+-------------------+---------+
|Replay of valid | ADV-NET | Challenge binding |Section 5|
|PA | | (bind.nonce) | |
+----------------+--------------------+-------------------+---------+
|Substitution | ADV-RESOURCE, ADV- | Subject binding |Section 5|
| | CALLER | | |
+----------------+--------------------+-------------------+---------+
|Stale PA | ADV-RESOURCE | exp enforcement + |Section 5|
| | | freshness | |
+----------------+--------------------+-------------------+---------+
|Cross-vendor | ADV-PARTIAL-ISSUER | Framework |Section |
|tier confusion | | anchoring |4, 5 |
+----------------+--------------------+-------------------+---------+
|Algorithm | ADV-NET, ADV- | Allowed-algorithm |Section 5|
|downgrade | RESOURCE | list | |
+----------------+--------------------+-------------------+---------+
|Issuer key | ADV-ISSUER | Short PA |Section 6|
|compromise | | lifetimes; | |
| | | revocation; key | |
| | | rotation | |
+----------------+--------------------+-------------------+---------+
|Permit theft / | ADV-NET, ADV- | Mandatory channel |Section 8|
|cross-connection| CALLER | binding when TLS | |
Miller Expires 29 October 2026 [Page 45]
Internet-Draft ZTNP April 2026
|replay | | | |
+----------------+--------------------+-------------------+---------+
|Permit replay | ADV-CALLER | Optional PoP |Section |
|outside session | | |12 |
+----------------+--------------------+-------------------+---------+
|Sybil enrollment| ADV-CALLER | Tier-1 ceiling on |Section |
| | | Self-Enrollment |10 |
+----------------+--------------------+-------------------+---------+
|Sponsorship | (Sponsor key | HSM-protected |Section |
|forgery | compromise) | Sponsor keys |10 |
+----------------+--------------------+-------------------+---------+
|Clock | ADV-NET | Reliable time |Section 5|
|manipulation | | source | |
+----------------+--------------------+-------------------+---------+
|IKS poisoning | ADV-NET | TLS on IKS; cache |Section 6|
| | | TTL | |
+----------------+--------------------+-------------------+---------+
Table 20
For multi-agent delegation threats (prompt injection, confused
deputy, intent substitution), see ZTIP [I-D.miller-ztip].
14.4. Out of Scope
Runtime posture drift; identity establishment; evidence quality
grading; side-channel attacks on signature verification; denial-of-
service; supply chain compromise of an Issuer; key compromise on the
Prover (subject_key from enrollment).
14.5. Channel Binding Practical Considerations
Section 8.2 makes channel binding mandatory when the transport is
TLS. Implementing it requires that the application have access to
the TLS session's exporter material. This is straightforward in some
environments and constrained in others; this section gives
implementers the operational guidance they need.
14.5.1. TLS Library Availability
The TLS exporter mechanism is defined in [RFC9266] and built on
[RFC8446] Section 7.5. As of this specification's publication, the
API is available in:
* *OpenSSL* 1.1.1 and later: SSL_export_keying_material().
* *BoringSSL*: SSL_export_keying_material().
Miller Expires 29 October 2026 [Page 46]
Internet-Draft ZTNP April 2026
* *rustls* (Rust): Connection::export_keying_material().
* *Go*: tls.ConnectionState.ExportKeyingMaterial().
* *Node.js* (LTS): tls.TLSSocket.exportKeyingMaterial().
* *Python* 3.12 and later: ssl.SSLObject.export_keying_material().
* *Java* 13 and later (Conscrypt and recent JDK builds): exporter
API exposed via SSLEngine.
Older runtimes or restricted embedded TLS stacks may not expose the
exporter API. Implementations targeting such environments cannot
implement channel binding directly and SHOULD either upgrade the TLS
stack or delegate the channel-binding step to a frontend that does
support it.
14.5.2. Termination by Intermediaries
A common deployment pattern places a TLS-terminating reverse proxy (a
CDN, an L7 load balancer, an API gateway) in front of the resource
server. In this pattern the proxy has the exporter material; the
origin does not. Two strategies:
1. *Channel binding at the proxy.* The proxy performs ZTNP
enforcement (verifies Posture Assertions, issues Permits,
validates channel binding on each subsequent request) and
forwards already-authorized requests to the origin. The origin
sees no ZTNP machinery. This is the recommended pattern when the
proxy is in the same trust domain as the origin.
2. *Re-establish TLS to the origin.* The proxy re-encrypts to the
origin (mTLS or service-mesh sidecar TLS), and the origin
performs ZTNP enforcement against the proxy-to-origin TLS
session. The proxy must forward the Posture Assertion and the
channel-binding values that match the proxy-to-origin session,
not the client-to-proxy session. This requires the proxy to re-
issue the Permit's ch_binding against the new exporter, which
means the proxy is acting as a Requester even if the client
thought it was negotiating with the origin.
Strategy (1) is operationally simpler and the recommended default.
Strategy (2) is appropriate when the proxy is not trusted to make
policy decisions on behalf of the origin.
Miller Expires 29 October 2026 [Page 47]
Internet-Draft ZTNP April 2026
14.5.3. Connection Migration and Resumption
Channel binding ties a Permit to a specific TLS session's exporter
output. Connection migration (HTTP/3, QUIC) and TLS session
resumption (Section 2.2 of [RFC8446]) introduce new keying material;
the previously-issued Permit's ch_binding will no longer match. The
Permit MUST be considered invalid in the new session, and a fresh
ZTNP negotiation is REQUIRED.
This is a security feature, not a limitation: a session change is
exactly when channel binding is supposed to invalidate a Permit.
14.5.4. What to Do When TLS Is Not Available
Some transports do not provide TLS keying material:
* MCP-over-stdio (in-process pipes, local IPC): no TLS. The MCP
profile defines a transport-equivalent *Process Binding* mechanism
using ephemeral-key exchange and per-call proof-of-possession.
* Service-mesh transports that explicitly opt out of mTLS in same-
trust-domain communication.
For these transports, the Permit MAY either omit ch_binding
(Section 8.2) — relying on the underlying transport's trust boundary
— or include a profile-defined ch_binding.method value naming a
transport-equivalent binding. *Concrete transport-equivalent binding
mechanisms are intentionally deferred to profile documents*
(Section 13) rather than being specified in this base specification.
Each transport's natural binding substrate is sufficiently different
(stdio's parent-process spawning, service-mesh sidecar identity,
embedded environments) that a single ZTNP-level mechanism would be
either too prescriptive for some or too permissive for others. The
MCP profile (draft-miller-ztnp-mcp-profile-00) addresses the MCP-
over-stdio case via Process Binding (ch_binding.method = "mcp-
process-ephemeral-key"); future profiles for other non-TLS transports
SHOULD define their binding mechanism similarly.
14.5.5. Reference Implementation Guidance
Implementers SHOULD consult the reference TypeScript verifier at the
project's repository for an example of how to wrap a TLS library's
exporter API and bind the result to Permit issuance. The reference
implementation includes channel-binding helpers for Node.js TLS
sockets.
Miller Expires 29 October 2026 [Page 48]
Internet-Draft ZTNP April 2026
15. Privacy Considerations
This section is informed by [RFC6973]. ZTNP carries data that can
reveal organizational and operational details; deployments SHOULD
apply data minimization.
*Posture data sensitivity.* Posture Assertions describe
vulnerabilities, incidents, and framework controls. Aggregated, this
leaks security maturity and incident history. Issuers SHOULD NOT
include claims more granular than necessary.
*Subject identifier privacy.* The sub claim is stable and long-lived.
Where Provers participate in many short interactions, a stable sub
enables linkability. Issuers SHOULD support pseudonymous subject
identifiers where deployment context permits.
*Subject key linkability.* A Prover's subject_key (bound to its
Posture Assertion at enrollment time, Section 11.1) is also stable
and long-lived. The thumbprint of subject_key appears in nonce_sig
bindings (Section 5.5) and in PoP cnf.jkt values (Section 12). An
observer who can correlate signatures or PoP proofs across sessions
can link sessions to the same subject even if the sub claim is
rotated or pseudonymous. Provers concerned with cross-session
unlinkability MAY use a per-session ephemeral key for PoP and rely on
the stable subject_key only at enrollment and verification points
where stability is required. Profile documents MAY specify rotation
conventions for subject_key itself.
*Issuer linkability.* A Requester learns which Issuer assessed a
given Prover. Provers MAY hold Posture Assertions from multiple
Issuers and select per-session.
*Evidence references.* evidence_refs and posture claims SHOULD
reference evidence by hash rather than embedding raw artifacts.
*Discovery leakage.* Discovery responses advertise issuers and
frameworks. Provers SHOULD limit Discovery to authenticated callers
when posture details are sensitive.
*Logging.* Logs containing Permit IDs and subject identifiers SHOULD
be access-controlled and retention-bounded.
*Cross-session correlation.* Channel-bound Permits cannot be linked
across sessions by an external observer.
*Children and protected categories.* Profiles operating in regulated
environments (healthcare, education, financial services) MUST address
regulatory privacy obligations.
Miller Expires 29 October 2026 [Page 49]
Internet-Draft ZTNP April 2026
16. IANA Considerations
This document requests the following IANA actions.
16.1. Registry Strategy
ZTNP defines several extension namespaces (flags, constraint types,
assessment methods, reason codes, binding modes, adoption postures,
channel binding methods, enrollment modes). Each is administered as
a separate IANA registry rather than collapsed into a single "ZTNP
parameters" registry, because the value spaces are semantically
disjoint and a flat registry would invite name collisions across
categories.
*All ZTNP registries created by this document use the Specification
Required policy* ([RFC8126] Section 4.6). This is a deliberate
choice over the heavier alternatives:
* _Standards Action_ (full IETF consensus per [RFC8126] Section 4.9)
would require an RFC for every flag or constraint name, which is
disproportionate to the typical extension — a single boolean flag,
a single denial reason code — and would create a permanent
backlog. Profile authors and deployment vendors would be unable
to register their extensions in any reasonable timeframe.
* _IETF Review_ (Section 4.8) and _RFC Required_ (Section 4.7) have
the same problem at smaller scale.
* _Expert Review_ alone (Section 4.5) does not require a written
specification, which would risk under-documented entries that
future implementers cannot interpret.
Specification Required strikes the right balance: anyone with a
publicly accessible written specification — an RFC, an industry-body
publication, or an Internet-Draft with a stable baseline — can
register an extension after Designated Expert sign-off. The
administrative load on IANA is modest because the gating work happens
at the DE rather than through full WG processing.
16.2. Designated Expert Guidance
Designated Experts (DEs) appointed for ZTNP registries SHOULD
evaluate registration requests against the following criteria:
* *Specification stability.* A registration MUST cite a publicly
accessible, version-stable specification (an RFC, an ISO/IEC or
NIST publication, a formally published industry specification, an
Internet-Draft with a stable baseline, or equivalent).
Miller Expires 29 October 2026 [Page 50]
Internet-Draft ZTNP April 2026
Registrations that cite only blog posts, unversioned web pages, or
specifications under active drafting without any published
baseline SHOULD be rejected.
* *Identifiable change controller.* Each registration MUST name a
change controller capable of authorizing future updates to the
entry.
* *Non-overlap with existing entries.* Registrations whose semantics
duplicate an existing entry under a different name SHOULD be
rejected.
* *Interoperability impact.* For registries that affect protocol
behavior (Constraint Type, Binding Mode, Reason Code, Channel
Binding Method), DEs SHOULD assess whether the new value can be
interpreted unambiguously by an implementation that has not
previously seen it.
* *Protocol scope.* Registrations MUST NOT redefine ZTNP semantics;
they extend them.
DEs SHOULD respond to registration requests within 30 days. Where a
DE has a conflict of interest with a particular registration, the DE
SHOULD recuse and request a substitute via IANA.
16.3. Well-Known URI Registrations
Register the following entries in the "Well-Known URIs" registry
[RFC8615]:
+===================+============+================+===========+
| URI Suffix | Change | Reference | Status |
| | Controller | | |
+===================+============+================+===========+
| ztnp | IETF | This document, | permanent |
| | | Section 6 | |
+-------------------+------------+----------------+-----------+
| ztnp-sponsor-keys | IETF | This document, | permanent |
| | | Section 10.4 | |
+-------------------+------------+----------------+-----------+
Table 21
16.4. Media Type Registrations
Register the following media types in the "Media Types" registry per
[RFC6838]:
Miller Expires 29 October 2026 [Page 51]
Internet-Draft ZTNP April 2026
+=======================+=============================+===========+
| Type | Description | Reference |
+=======================+=============================+===========+
| application/posture- | A Posture Assertion | This |
| assertion+jwt | serialized as a JWS Compact | document, |
| | Serialization [RFC7515] | Section 5 |
+-----------------------+-----------------------------+-----------+
| application/posture- | A Posture Assertion | This |
| assertion+cwt | serialized as a COSE_Sign1 | document, |
| | [RFC9052] CWT | Section 5 |
+-----------------------+-----------------------------+-----------+
| application/ztnp- | A ZTNP Permit serialized as | This |
| permit+jwt | a JWS Compact Serialization | document, |
| | | Section 8 |
+-----------------------+-----------------------------+-----------+
| application/ztnp- | A ZTNP Permit serialized as | This |
| permit+cwt | a COSE_Sign1 | document, |
| | | Section 8 |
+-----------------------+-----------------------------+-----------+
Table 22
Each media type's registration template follows [RFC6838]; security
considerations for each are those of this document (Section 15).
16.5. Note on Framework Identifiers
ZTNP does not request an IANA registry of security frameworks.
Framework identifiers (framework_id claim, Section 5.2) are URIs
published by the framework's authoring organization (NIST, ISO/IEC,
OWASP, AICPA, the European Commission, vendor-publishers, or
enterprises operating internal frameworks). Section 4.4 motivates
this design choice; the informative table of well-known canonical
URIs in Section 4.4 is non-normative guidance.
This explicit non-registration is itself an IANA action: this
document requests that future ZTNP-related allocations avoid creating
a centralized framework directory in IANA's namespace, leaving
framework identification to the publishers of those frameworks.
16.6. ZTNP Posture Assertion Flag Names Registry
This document requests creation of a registry titled "ZTNP Posture
Assertion Flag Names". It administers names usable in the
claims.posture.flags field of Posture Assertions (Section 5).
Allocation Policy: Specification Required (per [RFC8126]).
Miller Expires 29 October 2026 [Page 52]
Internet-Draft ZTNP April 2026
Registration Template:
* *Name*: identifier matching [a-z][a-z0-9_]*
* *Description*: prose definition of the operational state the flag
asserts
* *Reference*: specification defining the flag
* *Change Controller*
Initial Registrations:
+========================+=============================+===========+
| Name | Description | Reference |
+========================+=============================+===========+
| critical_open | At least one open issue at | This |
| | "critical" severity per the | document |
| | Issuer's severity scale | |
+------------------------+-----------------------------+-----------+
| incident_open | At least one ongoing | This |
| | security incident affects | document |
| | the subject | |
+------------------------+-----------------------------+-----------+
| pii_access_allowed | Subject is authorized to | This |
| | access personally | document |
| | identifiable information | |
+------------------------+-----------------------------+-----------+
| secrets_access_allowed | Subject is authorized to | This |
| | access cryptographic | document |
| | secrets | |
+------------------------+-----------------------------+-----------+
| code_exec_allowed | Subject is authorized to | This |
| | execute arbitrary code | document |
+------------------------+-----------------------------+-----------+
Table 23
16.7. ZTNP Constraint Type Registry
This document requests creation of a registry titled "ZTNP Constraint
Types". It administers types usable as keys within Permit
constraints objects (Section 8).
Allocation Policy: Specification Required (per [RFC8126]).
Registration Template:
Miller Expires 29 October 2026 [Page 53]
Internet-Draft ZTNP April 2026
* *Type*: identifier matching [a-z][a-z0-9_]*
* *Description*: prose semantics
* *Value Schema*: JSON-Schema fragment or prose schema for the
constraint's value
* *Reference*: specification
* *Change Controller*
Initial Registrations:
+============+===============================+===========+
| Type | Description | Reference |
+============+===============================+===========+
| data | Restricts the data classes | This |
| | the Permit covers | document |
+------------+-------------------------------+-----------+
| actions | Restricts the action verbs | This |
| | the Permit covers | document |
+------------+-------------------------------+-----------+
| rate_limit | Imposes a request-rate cap | This |
| | | document |
+------------+-------------------------------+-----------+
| ttl | Bounds session duration | This |
| | beyond exp | document |
+------------+-------------------------------+-----------+
| redaction | Specifies output redaction | This |
| | requirements | document |
+------------+-------------------------------+-----------+
| tools | Restricts the tool | This |
| | identifiers the Permit covers | document |
+------------+-------------------------------+-----------+
Table 24
16.8. ZTNP Assessment Method Names Registry
This document requests creation of a registry titled "ZTNP Assessment
Method Names". It administers values usable in the
claims.assessment_method field of Posture Assertions (Section 5.4).
Allocation Policy: Specification Required (per [RFC8126]).
Registration Template:
* *Name*: identifier matching [a-z][a-z0-9_]*
Miller Expires 29 October 2026 [Page 54]
Internet-Draft ZTNP April 2026
* *Description*: prose description of the methodology
* *Determinism*: whether two assessments of the same Prover are
expected to produce the same outcome (deterministic / non-
deterministic / mixed)
* *Reference*: specification
* *Change Controller*
Initial Registrations:
Miller Expires 29 October 2026 [Page 55]
Internet-Draft ZTNP April 2026
+=======================+==============+=================+=========+
|Name |Description |Determinism |Reference|
+=======================+==============+=================+=========+
|deterministic_checklist|Evidence |deterministic |This |
| |checked | |document |
| |against a | | |
| |fixed rule set| | |
| |with | | |
| |deterministic | | |
| |pass/fail | | |
+-----------------------+--------------+-----------------+---------+
|automated_scan |Programmatic |deterministic |This |
| |scanning | |document |
| |(vulnerability| | |
| |scanners, | | |
| |static | | |
| |analyzers, | | |
| |configuration | | |
| |auditors) | | |
+-----------------------+--------------+-----------------+---------+
|human_review |Human-led |non-deterministic|This |
| |assessment by | |document |
| |qualified | | |
| |reviewers | | |
+-----------------------+--------------+-----------------+---------+
|llm_evaluator |Evaluation |non-deterministic|This |
| |conducted by a| |document |
| |language model| | |
| |interpreting | | |
| |evidence | | |
+-----------------------+--------------+-----------------+---------+
|hybrid |Combination of|mixed |This |
| |two or more of| |document |
| |the above | | |
+-----------------------+--------------+-----------------+---------+
|unspecified |Methodology |mixed |This |
| |not disclosed | |document |
+-----------------------+--------------+-----------------+---------+
Table 25
Profile-defined values that are not generally reusable across
profiles SHOULD use a profile-prefixed name (e.g., acme_internal_v1)
to avoid collisions.
Miller Expires 29 October 2026 [Page 56]
Internet-Draft ZTNP April 2026
16.9. ZTNP Denial Reason Code Registry
This document requests creation of a registry titled "ZTNP Denial
Reason Codes". It administers reason-code strings returned by
Requesters when a negotiation, validation, or enrollment step fails.
Allocation Policy: Specification Required (per [RFC8126]).
Registration Template:
* *Code*: identifier matching [A-Z][A-Z0-9_]*
* *Description*: prose definition of the failure condition
* *Reference*: specification
* *Change Controller*
Initial Registrations (all reference this document):
+===========================+=====================================+
| Code | Description |
+===========================+=====================================+
| PA_MISSING | Required Posture Assertion was not |
| | presented |
+---------------------------+-------------------------------------+
| PA_EXPIRED | Posture Assertion is past its exp |
+---------------------------+-------------------------------------+
| PA_INVALID_SIG | Posture Assertion signature did not |
| | verify |
+---------------------------+-------------------------------------+
| PA_BINDING_FAILED | Posture Assertion binding (nonce, |
| | channel, or subject) did not match |
+---------------------------+-------------------------------------+
| PA_ISSUER_UNKNOWN | Issuer is not in the Requester's |
| | trusted-issuer set |
+---------------------------+-------------------------------------+
| PA_FRAMEWORK_UNKNOWN | The Posture Assertion's |
| | framework_id URI is not in the |
| | Requester's allowed-frameworks |
| | list. |
+---------------------------+-------------------------------------+
| POLICY_TIER_LOW | Posture tier is below the policy |
| | minimum |
+---------------------------+-------------------------------------+
| POLICY_FLAG_BLOCKED | A blocking flag is asserted on the |
| | Posture Assertion |
+---------------------------+-------------------------------------+
Miller Expires 29 October 2026 [Page 57]
Internet-Draft ZTNP April 2026
| POLICY_FRESHNESS | Posture Assertion is older than the |
| | policy freshness window |
+---------------------------+-------------------------------------+
| POLICY_FRAMEWORK_MISMATCH | The Posture Assertion's |
| | framework_id is well-formed but is |
| | not in the (otherwise valid) |
| | policy's allowed-frameworks list. |
| | Distinct from POLICY_INCOMPLETE — |
| | the policy is fine; the assertion's |
| | framework is the problem. |
+---------------------------+-------------------------------------+
| POLICY_INCOMPLETE | The Requester's policy is malformed |
| | (e.g., specifies tier_min without |
| | either framework_id or |
| | issuers_allowed). A conforming |
| | policy engine SHOULD refuse to |
| | evaluate such a policy. Distinct |
| | from POLICY_FRAMEWORK_MISMATCH — |
| | the assertion is not the problem; |
| | the policy is. |
+---------------------------+-------------------------------------+
| POLICY_METHOD_MISMATCH | Posture Assertion's |
| | assessment_method is outside the |
| | policy's assessment_method_allowed |
| | list |
+---------------------------+-------------------------------------+
| SUBJECT_MISMATCH | Subject identifier does not match |
| | expectations |
+---------------------------+-------------------------------------+
| PERMIT_EXPIRED | Permit is past its exp |
+---------------------------+-------------------------------------+
| PERMIT_CHANNEL_MISMATCH | Permit channel binding did not |
| | match |
+---------------------------+-------------------------------------+
| PERMIT_SCOPE_VIOLATION | Operation is outside Permit scope |
+---------------------------+-------------------------------------+
| POP_PROOF_INVALID | Proof-of-possession proof did not |
| | verify |
+---------------------------+-------------------------------------+
| ENROLL_TIER_EXCEEDED | Posture Assertion's enrollment_mode |
| | is self but its tier exceeds the |
| | Self-Enrollment ceiling |
| | (Section 11.2). Returned by a |
| | Requester verifying the assertion, |
| | not by an enrollment server. |
+---------------------------+-------------------------------------+
Table 26
Miller Expires 29 October 2026 [Page 58]
Internet-Draft ZTNP April 2026
ZTIP [I-D.miller-ztip] registers additional codes in this registry.
16.10. ZTNP Binding Mode Registry
This document requests creation of a registry titled "ZTNP Binding
Modes". It administers identifiers describing how Posture Assertions
and Permits are bound to a session (Section 8).
Allocation Policy: Specification Required (per [RFC8126]).
Registration Template:
* *Mode*: identifier matching [A-Za-z][A-Za-z0-9-]*
* *Description*: prose semantics — what is bound and how
* *Applicability*: which transports or contexts the mode applies to
* *Reference*: specification
* *Change Controller*
Initial Registrations:
+========+============================+===============+===========+
| Mode | Description | Applicability | Reference |
+========+============================+===============+===========+
| PA-R | Resource-Presents: Prover | Any transport | This |
| | presents Posture Assertion | | document |
| | to Requester | | |
+--------+----------------------------+---------------+-----------+
| PA-C | Caller-Presents: Requester | Any transport | This |
| | presents Posture Assertion | | document |
| | to Prover | | |
+--------+----------------------------+---------------+-----------+
| Mutual | Both parties exchange and | Any transport | This |
| | verify Posture Assertions | | document |
+--------+----------------------------+---------------+-----------+
Table 27
16.11. ZTNP Adoption Posture Registry
This document requests creation of a registry titled "ZTNP Adoption
Postures". It administers identifiers describing the Requester's
behavior when an expected Posture Assertion is missing or fails
policy (Section 7.6).
Miller Expires 29 October 2026 [Page 59]
Internet-Draft ZTNP April 2026
Allocation Policy: Specification Required (per [RFC8126]).
Registration Template:
* *Posture*: identifier matching [a-z][a-z0-9_-]*
* *Description*: prose definition of behavior when a PA is missing
or fails
* *Issues Permit on failure?*: yes / no
* *Reference*: specification
* *Change Controller*
Initial Registrations:
+===============+==========================+===========+===========+
| Posture | Description | Issues | Reference |
| | | Permit on | |
| | | failure? | |
+===============+==========================+===========+===========+
| required | Deny on missing or | no | This |
| | failing PA | | document |
+---------------+--------------------------+-----------+-----------+
| monitor-only | Proceed with session, | no | This |
| | log failure, do not | | document |
| | issue Permit | | |
+---------------+--------------------------+-----------+-----------+
| opportunistic | Proceed and issue Permit | yes | This |
| | even without a PA; | | document |
| | record posture in Permit | | |
+---------------+--------------------------+-----------+-----------+
Table 28
16.12. ZTNP Channel Binding Method Registry
This document requests creation of a registry titled "ZTNP Channel
Binding Methods". It administers identifiers usable in
ch_binding.method of Permits (Section 8.2).
Allocation Policy: Specification Required (per [RFC8126]).
Registration Template:
* *Method*: identifier matching [a-z][a-z0-9_-]*
Miller Expires 29 October 2026 [Page 60]
Internet-Draft ZTNP April 2026
* *Description*: how the binding is computed and verified
* *Transport*: which transport(s) the method applies to
* *Unforgeability rationale*: brief explanation of why a party
outside the transport's natural trust boundary cannot forge the
binding
* *Reference*: specification
* *Change Controller*
Initial Registrations:
+==============+===========================+===========+===========+
| Method | Description | Transport | Reference |
+==============+===========================+===========+===========+
| tls-exporter | TLS exporter material per | TLS | This |
| | [RFC9266] (Section 8.2) | | document |
+--------------+---------------------------+-----------+-----------+
| none | No channel binding; | Any | This |
| | REQUIRES rationale field | | document |
+--------------+---------------------------+-----------+-----------+
Table 29
Profile documents that define transport-equivalent bindings (e.g.,
the MCP profile's mcp-process-ephemeral-key) MUST register their
method in this registry before deployment in cross-organization use.
16.13. ZTNP Enrollment Mode Registry
This document requests creation of a registry titled "ZTNP Enrollment
Modes". It administers identifiers describing how Issuers issue
Posture Assertions to subjects (Section 10).
Allocation Policy: Specification Required (per [RFC8126]).
Registration Template:
* *Mode*: identifier matching [a-z][a-z0-9_]*
* *Description*: prose definition of the enrollment process
* *Tier ceiling*: maximum tier issuable under this mode
* *Reference*: specification
Miller Expires 29 October 2026 [Page 61]
Internet-Draft ZTNP April 2026
* *Change Controller*
Initial Registrations:
+==========+==============================+===========+============+
| Mode | Description | Tier | Reference |
| | | ceiling | |
+==========+==============================+===========+============+
| self | Self-Enrollment: Issuer | 1 | This |
| | performs proof-of-possession | | document, |
| | only; no Sponsor | | Section 10 |
+----------+------------------------------+-----------+------------+
| assessed | Assessed Enrollment: Issuer | unbounded | This |
| | performs posture assessment; | | document, |
| | OPTIONAL Sponsor vouching | | Section 10 |
+----------+------------------------------+-----------+------------+
Table 30
17. Implementation Status
This section records known implementations per [RFC7942]. Per RFC
7942 guidance, this section is to be removed before publication as an
RFC.
A reference TypeScript verifier covering the mandatory verification
path is published at:
https://github.com/agent-trust-protocols/agent-trust-protocols/tree/main/reference/typescript/ztnp
A set of test vectors covering valid Posture Assertions, expired
marks, signature failures, binding failures, channel-binding
failures, subject mismatches, and unknown key identifiers is
published at:
https://github.com/agent-trust-protocols/agent-trust-protocols/tree/main/test-vectors/ztnp
A Python reference implementation is in progress.
18. References
18.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>.
Miller Expires 29 October 2026 [Page 62]
Internet-Draft ZTNP April 2026
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, DOI 10.17487/RFC3986, January 2005,
<https://www.rfc-editor.org/rfc/rfc3986>.
[RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type
Specifications and Registration Procedures", BCP 13,
RFC 6838, DOI 10.17487/RFC6838, January 2013,
<https://www.rfc-editor.org/rfc/rfc6838>.
[RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web
Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May
2015, <https://www.rfc-editor.org/rfc/rfc7515>.
[RFC7517] Jones, M., "JSON Web Key (JWK)", RFC 7517,
DOI 10.17487/RFC7517, May 2015,
<https://www.rfc-editor.org/rfc/rfc7517>.
[RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
(JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015,
<https://www.rfc-editor.org/rfc/rfc7519>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/rfc/rfc8126>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/rfc/rfc8446>.
[RFC8615] Nottingham, M., "Well-Known Uniform Resource Identifiers
(URIs)", RFC 8615, DOI 10.17487/RFC8615, May 2019,
<https://www.rfc-editor.org/rfc/rfc8615>.
[RFC9052] Schaad, J., "CBOR Object Signing and Encryption (COSE):
Structures and Process", STD 96, RFC 9052,
DOI 10.17487/RFC9052, August 2022,
<https://www.rfc-editor.org/rfc/rfc9052>.
[RFC9110] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Ed., "HTTP Semantics", STD 97, RFC 9110,
DOI 10.17487/RFC9110, June 2022,
<https://www.rfc-editor.org/rfc/rfc9110>.
Miller Expires 29 October 2026 [Page 63]
Internet-Draft ZTNP April 2026
[RFC9266] Whited, S., "Channel Bindings for TLS 1.3", RFC 9266,
DOI 10.17487/RFC9266, July 2022,
<https://www.rfc-editor.org/rfc/rfc9266>.
[RFC9334] Birkholz, H., Thaler, D., Richardson, M., Smith, N., and
W. Pan, "Remote ATtestation procedureS (RATS)
Architecture", RFC 9334, DOI 10.17487/RFC9334, January
2023, <https://www.rfc-editor.org/rfc/rfc9334>.
[RFC9449] Fett, D., Campbell, B., Bradley, J., Lodderstedt, T.,
Jones, M., and D. Waite, "OAuth 2.0 Demonstrating Proof of
Possession (DPoP)", RFC 9449, DOI 10.17487/RFC9449,
September 2023, <https://www.rfc-editor.org/rfc/rfc9449>.
18.2. Informative References
[A2A] Google et al., "Agent-to-Agent Protocol", 2025.
[FIPS204] NIST, "Module-Lattice-Based Digital Signature Standard
(ML-DSA)", FIPS 204, August 2024,
<https://csrc.nist.gov/pubs/fips/204/final>.
[I-D.miller-ztip]
Miller, J., "Zero-Trust Intent Protocol (ZTIP)", Work in
Progress, Internet-Draft, draft-miller-ztip-00, n.d.,
<https://datatracker.ietf.org/doc/html/draft-miller-ztip-
00>.
[MCP] Anthropic, "Model Context Protocol Specification", n.d.,
<https://modelcontextprotocol.io>.
[RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC
Text on Security Considerations", BCP 72, RFC 3552,
DOI 10.17487/RFC3552, July 2003,
<https://www.rfc-editor.org/rfc/rfc3552>.
[RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework",
RFC 6749, DOI 10.17487/RFC6749, October 2012,
<https://www.rfc-editor.org/rfc/rfc6749>.
[RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J.,
Morris, J., Hansen, M., and R. Smith, "Privacy
Considerations for Internet Protocols", RFC 6973,
DOI 10.17487/RFC6973, July 2013,
<https://www.rfc-editor.org/rfc/rfc6973>.
Miller Expires 29 October 2026 [Page 64]
Internet-Draft ZTNP April 2026
[RFC7591] Richer, J., Ed., Jones, M., Bradley, J., Machulak, M., and
P. Hunt, "OAuth 2.0 Dynamic Client Registration Protocol",
RFC 7591, DOI 10.17487/RFC7591, July 2015,
<https://www.rfc-editor.org/rfc/rfc7591>.
[RFC7592] Richer, J., Ed., Jones, M., Bradley, J., and M. Machulak,
"OAuth 2.0 Dynamic Client Registration Management
Protocol", RFC 7592, DOI 10.17487/RFC7592, July 2015,
<https://www.rfc-editor.org/rfc/rfc7592>.
[RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running
Code: The Implementation Status Section", BCP 205,
RFC 7942, DOI 10.17487/RFC7942, July 2016,
<https://www.rfc-editor.org/rfc/rfc7942>.
[RFC9635] Richer, J., Ed. and F. Imbault, "Grant Negotiation and
Authorization Protocol (GNAP)", RFC 9635,
DOI 10.17487/RFC9635, October 2024,
<https://www.rfc-editor.org/rfc/rfc9635>.
[SCITT-ARCH]
Birkholz, H., "An Architecture for Trustworthy and
Transparent Digital Supply Chains", Work in Progress,
Internet-Draft, draft-ietf-scitt-architecture, n.d.,
<https://datatracker.ietf.org/doc/html/draft-ietf-scitt-
architecture>.
[SPIFFE] SPIFFE Project, "Secure Production Identity Framework For
Everyone", n.d., <https://spiffe.io>.
Appendix A. Conformance Profiles
An implementation MAY claim conformance to one or more of the
following profiles.
A.1. ZTNP
REQUIRED for any conformance claim. Sections 5 through 10, plus
channel binding (Section 8.2) when transport is TLS.
A.2. ZTNP Hardened
ZTNP PLUS Proof-of-Possession (Section 12). RECOMMENDED for
sensitive-capability deployments.
ZTNP Federated and ZTNP Agentic profiles are defined in companion
documents (the latter requiring ZTIP [I-D.miller-ztip]).
Miller Expires 29 October 2026 [Page 65]
Internet-Draft ZTNP April 2026
Appendix B. Open Questions and WG Venue
*WG venue.* ZTNP's primary problem domain is attestation-gated
session authorization at the software layer: a Relying Party
challenges a counterparty for a signed posture credential, applies
local policy, and issues a session-scoped, channel-bound Permit. The
author's preferred venues, in order: a SAAG-routed BoF or new WG
scoped to attestation-gated session authorization; OAuth (for the
Permit-issuance and token-extension portions); WIMSE (for the
enrollment-requirements portion as a workload-identity concern); the
Independent Submission stream as a fallback. ZTNP is *not* a RATS
work item: while RATS is one possible upstream attestation pipeline
(Section 1.5), ZTNP's center of gravity — framework-anchored
portability, session negotiation, channel-bound Permits — sits
outside the RATS architecture. RATS reviewers and contributors are
welcomed in any chosen venue.
*Profile registration logistics.* Relationship between profile
authors and framework authors.
*Channel binding for non-TLS transports.* Future revision SHOULD
specify a binding for at least MCP-over-stdio.
*MAJOR vs MINOR version criteria.* Future revision will provide
concrete rules.
Appendix C. Example Policies and Payloads
C.1. Example Policy (Framework-Anchored)
{
"require": {
"framework_id": "https://doi.org/10.6028/NIST.AI.100-1",
"tier_min": 3,
"issuers_allowed": ["https://issuer-x.example", "https://issuer-y.example"],
"freshness_seconds": 86400,
"flags": {
"critical_open": false,
"incident_open": false
}
}
}
C.2. Example Posture Assertion Payload
Miller Expires 29 October 2026 [Page 66]
Internet-Draft ZTNP April 2026
{
"ver": "0.2",
"iss": "https://issuer.example",
"sub": "agent:acme-corp/data-processor",
"iat": 1745500800,
"exp": 1745587200,
"jti": "pa_01HVXYZ123ABC456DEF",
"framework_id": "https://doi.org/10.6028/NIST.AI.100-1",
"tier": 3,
"scope": {
"kind": "agent",
"target": "https://api.acme.com/agents/data-processor",
"env": "prod"
},
"claims": {
"flags": {
"critical_open": false,
"incident_open": false,
"pii_access_allowed": true
}
},
"bind": {
"method": "nonce_hash",
"nonce": "dGhpcyBpcyBhIGhhc2hlZCBub25jZQ==",
"ctx": "mcp",
"aud": "agent:requester-corp/orchestrator"
}
}
Acknowledgments
The author thanks the early reviewers for feedback during the draft
cycle and welcomes broader community input as the work progresses
toward IETF submission.
Author's Address
Jake Miller
Email: jake@zivis.ai
Miller Expires 29 October 2026 [Page 67]