Re: Remaining questions for Zoom meeting 2026-10-21

I think trust and authorization are orthogonal.  An operator starts an
agent with a set of permissions.  That agent interacts with another agent
started by a different operator.  The agent delegates some of its
permissions based on a trust decision.  If something goes wrong, the
operator of the delegating agent will hold the operator of the other agent
responsible.

--------------
Alan Karp


On Thu, Oct 22, 2026 at 9:08 AM Larry Lewis <llewis@sovrlabs.com> wrote:

> Dear Sean, Ren, Alan, and Community Group,
>
> I am loving these discussions and insights. Like to just add that I
> believe the distinction Sean has drawn between communication trust, entity
> trust, and behavior/execution trust provides a useful foundation for
> identifying the responsibilities of each layer.
>
> I also think Ren and Alan raise an important additional question: who
> ultimately has the authority to act on a trust decision?
>
> An autonomous agent may evaluate another agent using credentials, prior
> interactions, runtime evidence, or other mechanisms. Those assessments can
> help the agent determine whether an interaction is trustworthy.
>
> However, I believe we should distinguish an agent's trust assessment from
> its authority to perform an action.
>
> A verified identity does not automatically establish trustworthiness.
> Likewise, evidence of trustworthiness does not automatically establish
> delegated authority.
>
> From the Agent Trust Protocol (ATP) perspective, we have been exploring
> this separation through identity verification, trust evidence, bounded
> mandates, revocation, and runtime policy enforcement.
>
> I see an opportunity for complementary layers rather than requiring ANP
> itself to solve every aspect of trust.
>
> ANP can provide interoperable communication and identity mechanisms. Other
> systems can contribute credentials, attestations, delegated authority, and
> behavioral evidence. The receiving system can then evaluate that evidence
> under its own applicable authorization policy.
>
> This also allows flexibility in how agents establish confidence without
> making security-critical authorization constraints optional.
>
> One question I would add to the discussion is:
>
> *How should we distinguish the trust judgment made by an autonomous agent
> from the authority delegated to that agent by its operator or principal?*
>
> I believe this could be evaluated through practical interoperability tests.
>
> We have already proposed a collaborative experiment involving ATP, Agent
> Passport System, and RTTP/IQA to examine evidence freshness, revocation,
> and action-time authorization. Alan's question suggests an additional test:
> whether a positive agent-to-agent trust judgment can ever substitute for
> authorization from the appropriate principal.
>
> My view is that it should not.
>
> I would welcome further thoughts on how we might define these boundaries
> in a protocol-neutral way while leaving room for different implementations
> and trust mechanisms.
>
> Keep Innovating,
>
> Larry Lewis
> Chair, Agent Trust Protocol Community Group
> llewis@sovrlabs.com
>
>
> From: Sean Zhang <seanzhang9999@gmail.com>
> To: "Ren Yushan"<keotheodangcha548@gmail.com>
> Cc: "Alan Karp"<alanhkarp@gmail.com>, <public-agentprotocol@w3.org>
> Date: Thu, 22 Oct 2026 07:47:27 -0500
> Subject: Re: Remaining questions for Zoom meeting 2026-10-21
>
> Hi Ren,
>
> I think we may be discussing several different kinds of trust at the same
> time, which makes it difficult to evaluate the role of DID or ANP itself.
>
> My current understanding is as follows.
>
> ANP is primarily an agent networking protocol for identity discovery,
> addressing, communication, and invocation. In that sense, its role is
> closer to HTTP in the Internet stack. Its primary responsibility is
> enabling interoperable communication between agents rather than solving
> every trust problem at the application layer.
>
> Similar to how HTTP relies on HTTPS and PKI-based certificate systems to
> establish server trust, ANP adopts DID as its identity anchor. This allows
> ANP to leverage the broader DID/VC ecosystem for identity verification,
> credentials, and trust enhancement.
>
> From my perspective, at least three different layers of trust should be
> distinguished:
> 1. Communication Trust
>
> At the communication level, a DID associated with a cryptographic key can
> prove message origin, authenticity, and integrity.
>
> This answers the question:
>
> "Who am I communicating with?"
>
> The trust here is fundamentally cryptographic.
> 2. Entity Trust
>
> A cryptographically verified identity does not automatically imply that
> the underlying entity is trustworthy.
>
> The trustworthiness of an organization, individual, service provider, or
> agent operator typically requires additional evidence such as credentials,
> verifiable claims, certifications, organizational endorsements, regulatory
> qualifications, or reputation systems.
>
> This answers the question:
>
> "Is this entity trustworthy?"
>
> 3. Behavior / Execution Trust
>
> Even if an entity is trustworthy, that does not automatically prove it is
> currently behaving as claimed.
>
> Behavior trust may be established through multiple forms of evidence,
> including:
>
>    - Runtime attestation
>    - TEE-based proofs
>    - Verifiable computation
>    - Audit logs
>    - Challenge-response interactions
>    - Historical performance records
>    - Reputation accumulated through repeated interactions
>
> This answers the question:
>
> "Is this agent actually operating according to its claimed behavior right
> now?"
>
> In this sense, the interaction patterns you described between agents can
> also be viewed as mechanisms for establishing behavioral trust. They help
> participants gain confidence through observation, verification, and
> accumulated evidence.
>
> However, those interactions are different from communication trust itself.
> They are built on top of an already established cryptographic identity
> layer.
>
> Therefore, my view is that communication trust, entity trust, and
> behavior/execution trust are related but distinct problems. DID primarily
> provides an identity anchor for communication trust. VC and similar
> mechanisms help establish entity trust. Runtime proofs and
> interaction-based verification contribute to behavior trust.
>
> ANP can provide the foundation and extensibility points for these trust
> layers, but I do not think all of them need to be solved directly by the
> base protocol itself.
>
> In one sentence:
>
> Identity proves who you are, credentials prove what you are allowed or
> qualified to do, and behavioral evidence proves that you are actually
> acting as claimed.
>
> Best, Sean
>
> Ren Yushan <keotheodangcha548@gmail.com> 于2026年10月22日周四 13:40写道：
>
> Thanks Alan, your questions are right to the point. Here are what I meant.
> Just some brainstorming ideas.
>
> On Thu, Oct 22, 2026 at 7:26 AM Alan Karp <alanhkarp@gmail.com> wrote:
>
> A great point, but I think we need to answer some questions first.
>
> Does the agent make the trust decision or does the agent's operator, the
> legal person who gave it its prompt?
>
>
>  The agent chooses what means a trust. We can give the agent some advice,
> some choices, and the agent chooses what to use or whether to use it or
> not. But keep these choices as advices, not protocol. We'd better think
> carefully about what to do, or what not to do.
>
>
> Does one agent trust another, or does it trust the other agent's operator?
>
>
> Still the agent, agent to agent trust.
>
>
> Trust is based on the question, "Are you the guy I interacted with last
> time?"  As you note, the answer depends on a credential.  Do we know that
> agents won't share credentials, and does that affect trust decisions?
>
>
> Trust is from many sources. If we force the agent to use which
> cryptographic way, the trust is limited to getting the right signature. It
> is becoming easier. What I brainstormed was to leave it an OPTION not a
> MUST. The agent to agent chat channel is already well established by the
> E2E communication. We need them to trust each other in the agent native way.
>
>
> --------------
> Alan Karp
>
>
> On Wed, Oct 21, 2026 at 4:03 PM Ren Yushan <keotheodangcha548@gmail.com>
> wrote:
>
> Hi all,
>
> I'd like to raise a point about one interaction in the ANP protocol —
> specifically, how trust between agents is handled once they are talking to
> each other.
>
> If two agents want to communicate, they first have to discover each other
> and establish a connection. A separate concern is that, while they are
> chatting, they need to trust each other.
>
> The difficulty arises when that trust is written into the protocol. It has
> to become a normative statement — a formulation you use to verify that the
> other party is a safe object. But in reality, when we chat, there is no
> security-verification step. We do not run some protocol while talking in
> order to guarantee that the information is safe. Safety is something we
> discover during the conversation: whether this person is reliable or not.
>
> So I would argue that the protocol should not try to define what is safe,
> what is unsafe, and what is trustworthy. Instead, it could offer reference
> suggestions about what means agents might use to communicate — for example,
> a password, or a standardised JSON format. But if that format is hard-coded
> into the protocol, it cannot be switched; and if it later turns out to be
> insecure, the protocol itself acquires a hole.
>
> So could we take a step back: not define the protocol, only give reference
> definitions? Since agents can communicate in text, why not let them use
> text to establish trust? Give them a verification method they can choose —
> they decide whether to use it, and which one. That is my view of trust.
> Happy to hear counterarguments, especially from anyone who thinks trust can
> be made normative without the protocol becoming brittle.
>
> Best regards,
> Yushan Ren
>
>
>
>