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

[Philip Griffiths <[e-mail]>]

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
>
>
>
> 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
> .
>
>
>
> 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 *A*gent* O*perations and* M*anagement* 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/
>
> 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
>
>
>
> 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/
> ) and propose your related drafts.
>
>
>
> We also welcome you to review the ZTCPP charter (
> 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
>  (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/
>
> To subscribe: 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]
>