[Ztcpp] Re: 【ZTCPP Charter Discussions】RE: Re: [agent2agent] Re: 转发：FW: New Non-WG Mailing List: ztcpp (Zero Trust Control and Policy Protocol)

[Aijun Wang <[e-mail]>]

Hi, Philips:

Yes, you can refine the charter in the GitHub directly, describe concisely the problem existing, proposed standards approaches and the expected deliverables.

You can expand the current charter but should keep it confine within our initial aim, that is, “control and policy protocol for network and service security under zero trust principles”.

The Charter is mainly used to convince other experts, invite the possible interest experts and get the approval from our AD to support the forming of the formal WG.

Aijun

On Apr 23, 2026, at 16:37, Philip Griffiths <[e-mail]> wrote:



Morning Aijun,

Sure. Wrt the charter, I would say its a strong starting point and aligns well with the need for authenticated-before-connect (ABC) mechanisms and control-plane interoperability.

One area that may benefit from strengthening is ensuring that service-based, least-privilege policy can be both expressed and reliably bound to concrete sessions and flows (Seam 4.3). Interoperable policy distribution alone (Seam 4.2) is not sufficient unless identity- and service-based intent can be enforced with verifiable fidelity at runtime, rather than being diluted into coarse address-based enforcement.

Should I do a pull request on the GH repo??

Essentially, it would be to help to clarify that:

• eliminating ambient reachability (Seam 4.1),
• distributing and updating policy across enforcement points (Seam 4.2),
• and binding policy intent to runtime sessions and flows (Seam 4.3)

are distinct but interdependent concerns, all required to achieve consistent Zero Trust outcomes across implementations.

Additionally, the problem statement could more explicitly reflect the operational complexity of current approaches, where secure connectivity often requires coordination across infrastructure (e.g., routing, NAT, firewalls), governance processes, and distributed enforcement systems. This complexity largely arises from the absence of interoperable mechanisms to bind identity- and service-based policy directly to communication sessions, resulting in inconsistent enforcement and reduced agility.

It would also be useful to more explicitly position identity - particularly non-human identity (workloads, services, devices, and agents) - as foundational, while clarifying that the goal is interoperability and composition with existing identity systems (e.g., OIDC, PKI, workload identity), rather than defining new identity mechanisms.

Finally, clarifying that posture and context signals (e.g., device or workload state) are in scope at the protocol interaction level, even if endpoint technologies themselves are not, would help ensure that dynamic trust (primarily carried via Seam 4.2 and enforced via Seam 4.3) can be consistently applied across implementations.

Overall, the seam-based decomposition is a strong and practical foundation. Emphasising how these elements combine to enable service-level least privilege with verifiable runtime enforcement (Seam 4.3) would further strengthen alignment with Zero Trust principles such as those described in NIST SP 800-207.

Regards

Philip

On Thu, 23 Apr 2026 at 08:02, Aijun Wang <[e-mail]> wrote:

Hi, Philip and Chris:

 

Let’s confine our discussions within the [e-mail]

Currently, we would like to hear your opinions on the proposed charter: https://github.com/ietf-ztcpp/Charter/blob/main/Charter.md" target="_blank" rel="nofollow">https://github.com/ietf-ztcpp/Charter/blob/main/Charter.md

 

You can comments on the github directly for the detail description, or give the suggested text on the mail list.

 

Once we consensus on the Charter, we can discuss more on the specific proposals in detail.

 

The proposed charter should confine within our initial aim, and should also consider carefully the possible deliverables.

 

Aijun

 

From: [e-mail] [mailto:[e-mail]] On Behalf Of Philip Griffiths
Sent: Thursday, April 23, 2026 3:22 AM
To: Chris Hood <[e-mail]>
Cc: [e-mail]; [e-mail]; [e-mail]; [e-mail]
Subject: [Ztcpp] Re: [agent2agent] Re: 转发：FW: New Non-WG Mailing List: ztcpp (Zero Trust Control and Policy Protocol)

 

Hey Chris,

 

For sure, these are the slides we pull together in the CSA, which I presented, which Aijun and team used for protocol gap analysis of ZTCPP - https://github.com/ietf-ztcpp/125meeting/blob/main/0.4--IETF%20-%20ZTCPP%20presentation(Philips-Netfoundry).pdf" target="_blank" rel="nofollow">https://github.com/ietf-ztcpp/125meeting/blob/main/0.4--IETF%20-%20ZTCPP%20presentation(Philips-Netfoundry).pdf.

 

I have also attached the markdown I wrote before creating the slides.

 

Regards

Philip 

 

On Wed, 22 Apr 2026 at 20:00, Chris Hood <[e-mail]> wrote:

Philip,

 

Appreciate the thoughtful engagement. Your 4.2 and 4.3 refinements are genuinely clarifying.

 

One small reframe. AGTP is designed as a governance + transport layer rather than application-layer semantics. The intent is for agent-centric frameworks including MCP, A2A, ACP, and governance platforms such as Nomotic to function on top of AGTP rather than alongside it, each gaining protocol-level identity, authority, and attribution natively rather than retrofitting them. It seems that ZTCPP's coordination work sits naturally alongside those layers, ensuring coherent enforcement across heterogeneous deployments. The composition is cleaner than a head-to-head comparison might suggest.

 

On 4.1, your reframing is the accurate position. Both models will exist. AGTP's defaults target the open-agent-web deployment profile while providing the primitives that enterprise-oriented governance can build on.

 

I'll follow up separately with the crosswalk I mentioned, mapping AGTP's binding-layer constructs (Authority-Scope, Governance Tokens, Delegation-Chain, 451/551, Attribution-Record, NOTIFY revocation) against the Seam 4.2 and 4.3 definitions.

Please share with me the current ZTCPP seam documentation when you have a moment.

Regards,

Chris Hood

Nomotic, Inc.

[e-mail]

 

On Wed, Apr 22, 2026 at 8:09 AM Philip Griffiths <[e-mail]> wrote:

Hey Chris,

Thisis really helpful - appreciate you sharing the detail on AGTP. It was the first I heard about it so did some quick learning (thus please forgive if I make any misinterpretations). My hot take is there is alignment, but AGTP is not the same as what we are trying to achieve with ZTCPP, so there alignment and potential collaboration points. Much alignment comes around carrying identity, context, and scoped authority on every interaction.

wrt Seams 4.2 and 4.3, I agree there is strong overlap. AGTP’s use of Agent-ID, Principal-ID, delegation chains, and Authority-Scope is very much in line with what we’ve been describing as binding identity and policy intent to interactions. The Authority-Scope model in particular feels like a concrete example of binding-layer semantics. One nuance I’d highlight (and where I think ZTCPP can complement work like AGTP) is the distinction between:

• carrying semantics per request, and
• ensuring those semantics are interpreted, enforced, and verified consistently across different systems and enforcement points.

From the seam perspective:

• Seam 4.2 is less about in-band propagation of identity/context (which AGTP handles well), and more about policy lifecycle and coordination across enforcement points - e.g., update, revocation, reauth, convergence, and cross-domain consistency.
• Seam 4.3 is where we’ve been focusing on ensuring that whatever semantics are defined (e.g., Authority-Scope) can be reliably bound to runtime behaviour - not just per request, but across interactions - with consistent enforcement and auditable outcomes.

In other words, from my quick understanding, AGTP makes the binding layer explicit at the application level, whereas ZTCPP is trying to ensure that those semantics can be interoperably realised across implementations and trust domains, including how they map to enforcement in underlying systems.

On Seam 4.1, I think this is a really useful point of discussion. I completely agree that AGTP aligns with the open web model where reachability precedes authorisation, and governance controls what is exposed. From a Zero Trust perspective, the question we’ve been exploring is whether that model continues to hold in environments where:

• agents are highly dynamic
• interactions are machine-speed
• and exposure itself becomes a risk surface

So I’d frame this less as a disagreement and more as a design choice with different assumptions:

• AGTP preserves reachability-first interaction (web model)
• ZTCPP also considers architectures where reachability itself is mediated by identity and policy (which is a big request from large, enterprise organisations)

I suspect both models will exist, but being explicit about the trade-offs feels important. More broadly, I see a strong opportunity for collaboration here. AGTP can be seen as defining the application-layer semantics for agent interaction (identity, intent, authority), while ZTCPP is focused on how those semantics are:

• distributed and updated across systems (4.2)
• and enforced with consistent, verifiable outcomes (4.3)

Agentic systems feel like a natural driver for this work, but the same issues apply across users, services, and workloads more broadly.

Also completely agree on the vocabulary point - “Authority-Scope,” “binding layer,” “tool authorisation,” etc., are all converging on the same underlying need: consistent, enforceable semantics at the point of interaction

Happy to take this offline - comparing AGTP’s binding-layer semantics against the Seam 4.3 definition would be very useful, especially to understand where we can converge vs where differences are intentional.

Best,
Philip

 

On Wed, 22 Apr 2026 at 15:10, Chris Hood <[e-mail]> wrote:

Philip, Xuan, others -

 

Appreciate the framing for your charter. Much of this maps closely to Agent Transfer Protocol, AGTP (draft-hood-independent-agtp). I wanted to share some context for your consideration as it relates specifically to agents and zero-trust. A few points of alignment and one considered disagreement.

 

On Seams 4.2 and 4.3: AGTP carries identity, context, and authorization on every request through Agent-ID, Principal-ID, and Authority-Scope headers, with a three-level verification model (self-asserted, application-layer, transport-layer) covering different deployment profiles. The Authority-Scope vocabulary is AGTP's binding-layer common semantics, tokens like `documents:query`, `booking:*`, `payments:confirm` enforced on every request. The AGTP-CERT extension binds scope cryptographically for O(1) per-request enforcement at infrastructure layers. Delegation chains are strict-subset-constrained and recorded per hop. 451 Scope Violation and 551 Authority Chain Broken are first-class status codes.

 

On Seam 4.1: respectful disagreement. Agents should be reachable and discoverable prior to authorization, the same way websites are, with the governance platform controlling what's exposed and organizations able to hide agents when they choose to. AGTP's ANS gates discovery queries with Authority-Scope, but reachability itself is not the gatekeeper. Pre-authorization reachability is how the open web works and I think it's the right default for the open agent web too.

 

In the broader context, AGTP was designed as a governance + application layer, with the goal of moving agent traffic off HTTP so it's easier to observe, authenticate, and govern at the protocol level. One place AGTP differs from the autonomy-constraints framing is that AGTP doesn't define autonomy directly, because the systems aren't autonomous in the strong sense, they act on behalf of principals within scope grants. Authority-Scope and archetypes (assistant, analyst, executor, orchestrator, monitor) bound the action space.

 

Where I find a genuine opportunity is in the vocabulary. AGTP uses "Authority-Scope," "governance zone," "trust tier." CSA uses "seam," "binding layer," and "verifiable enforcement." ONUG uses "autonomy constraints," and "tool authorisation." Different traditions, largely overlapping concerns. Happy to take this offline to compare AGTP's binding-layer semantics against the Seam 4.3 definition if that's useful.

 

Chris Hood

Nomotic, Inc.

[e-mail]

 

 

On Wed, Apr 22, 2026 at 4:57 AM Philip Griffiths <[e-mail]> wrote:

Hey all,

 

Thanks Xuan. I have some feedback on the charter, should I just reply in this thread?? 

I also agree AI Agent communication should be done under the guise of zero trust principles. Mapping to the protocol gap work we created in the CSA, which I remotely presented, as well as the talk I gave earlier this month at the DoW Zero Trust Symposium on AI in collab with the CSA, wrt agentic systems, the traditional “never trust, always verify” model needs to extend beyond identity verification (particularly for non-human identities such as agents, services, and workloads) into how decisions are bound to runtime interactions.

In particular, agent-to-agent communication highlights three distinct but interdependent concerns:

• Eliminating ambient reachability (Seam 4.1) - agents should not be discoverable or reachable prior to authorisation
• Distributing and updating dynamic trust decisions (Seam 4.2) - including identity, context, and authorisation policies across systems
• Binding policy intent to concrete interactions (Seam 4.3) - ensuring that each agent-to-agent exchange is constrained to least-privilege semantics and can be verified at runtime

The last point becomes especially important in agentic environments. Agents are not just establishing connections - they are executing multi-step workflows, invoking tools, and passing context across domains. It is not sufficient to authenticate the agent; we must ensure that each interaction is explicitly authorised, scoped, and enforced at the session or operation level.

 

Without common semantics for this binding layer (Seam 4.3), we risk systems where identity is verified, and policy is distributed, but interactions remain over-broad or difficult to audit.

This maps very closely to some work thats taking place in ONUG on 'AOMC' (AI Agent Operations and Management Control framework), where Zero Trust begins to intersect with agent governance. Controls such as identity attestation, tool authorisation, and autonomy constraints require that policy is not only distributed (Seam 4.2), but consistently enforced at the point of action (Seam 4.3).

This suggests that agentic communication may be a strong driver for ZTCPP work around:

• standardising how identity (incl. non-human) and service intent are bound to interactions
• defining verifiable enforcement semantics for agent-to-agent exchanges
• ensuring interoperability across different agent frameworks and trust domains

Happy to share more detail or examples if useful - this feels like a natural extension of the current seam-based work.

 

Regards

Philip

 

On Wed, 22 Apr 2026 at 11:42, Xuan Si <[e-mail]> wrote:

Hi All,

 

I’m forwarding the announcement that the [e-mail] (Zero Trust Control and Policy Protocol) mailing list has been established:

https://mailman3.ietf.org/mailman3/lists/ztcpp.ietf.org/" target="_blank" rel="nofollow">https://mailman3.ietf.org/mailman3/lists/ztcpp.ietf.org/

This mail list will serve as a platform for us to exchange ideas, discuss technical issues and promote related research collaboration in the field of AI Agent and network security.

 

Our current Charter is available here:

https://github.com/ietf-ztcpp/Charter/blob/main/Charter.md" target="_blank" rel="nofollow">https://github.com/ietf-ztcpp/Charter/blob/main/Charter.md

 

One of our core research areas is reviewing AI Agent communication security under zero-trust principles. As agent-to-agent interaction grows, zero-trust models including “never trust, always verify” are critical to building secure and trusted communication environments.

 

We welcome everyone to submit proposals and share views on AI Agent security and zero-trust applications.

 

We also plan to hold a BoF or side meetings at IETF 126 for in-depth face-to-face discussions.

Please feel free to comment on the current Charter — your feedback will help us refine scope and direction.

 

Looking forward to your active participation.

 

Best regards,

Xuan Si

 

原始邮件

---

 

发件人：Aijun Wang <[e-mail]> 发件时间：2026年4月20日 18:31 收件人：saag <[e-mail]> 抄送：ztcpp <[e-mail]> 主题：[Ztcpp] FW: New Non-WG Mailing List: ztcpp (Zero Trust Control and Policy Protocol)

 

Hi, All SAAG experts:

 

If you are interested this direction, please subscribe the mail list(https://mailman3.ietf.org/mailman3/lists/ztcpp.ietf.org/" target="_blank" rel="nofollow">https://mailman3.ietf.org/mailman3/lists/ztcpp.ietf.org/) and propose your related drafts.

 

We also welcome you to review the ZTCPP charter (https://github.com/ietf-ztcpp/Charter/blob/main/Charter.md" target="_blank" rel="nofollow">https://github.com/ietf-ztcpp/Charter/blob/main/Charter.md) and give your suggestions within the [e-mail] mail list.

 

The materials for the past IETF 125 ZTCPP side meeting can be accessed at https://github.com/ietf-ztcpp/125meeting" target="_blank" rel="nofollow">https://github.com/ietf-ztcpp/125meeting (include problem statements, gap analysis, and brief of introduction of CSA alliance).

 

We are planning the IETF 126 BoF(or side meeting), welcome you all interested to join us together!

 

Aijun

 

 

 

-----Original Message-----

From: [e-mail] [mailto:[e-mail]] On Behalf Of IETF Secretariat

Sent: Saturday, April 18, 2026 1:13 AM

To: IETF Announcement List <[e-mail]>

Cc: [e-mail]; [e-mail]; [e-mail]; [e-mail]

Subject: New Non-WG Mailing List: ztcpp (Zero Trust Control and Policy Protocol)

 

A new IETF non-working group email list has been created.

 

List address: [e-mail]

Archive: https://mailarchive.ietf.org/arch/browse/ztcpp/" target="_blank" rel="nofollow">https://mailarchive.ietf.org/arch/browse/ztcpp/

To subscribe: https://mailman3.ietf.org/mailman3/lists/ztcpp.ietf.org/" target="_blank" rel="nofollow">https://mailman3.ietf.org/mailman3/lists/ztcpp.ietf.org/

 

Purpose: This email list focuses on exploring the practice and development of zero-trust strategies in modern multi-cloud and network environments, with a focus on zero trust's core principles, key elements, and specific application scenarios, control and policy protocol etc. 

 

The goal is to jointly advance understanding and practice of zero trust in cloud and networks, pool industry insights, explore better security strategies, and develop related communication standards.

 

This list belongs to IETF area: SEC

 

For additional information, please contact the list administrators.

 

_______________________________________________

IETF-Announce mailing list -- [e-mail] To unsubscribe send an email to [e-mail]

 

_______________________________________________

Ztcpp mailing list -- [e-mail]

To unsubscribe send an email to [e-mail]

 

_______________________________________________

Ztcpp mailing list -- [e-mail]

To unsubscribe send an email to [e-mail]

 

_______________________________________________
Ztcpp mailing list -- [e-mail]
To unsubscribe send an email to [e-mail]