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

I may well steal the way you describe things.

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


On Thu, Oct 22, 2026 at 9:22 AM Chris <chopmob@gmail.com> wrote:

> Dear Larry and colleagues,
>
> I agree that the distinction between communication trust, entity trust and
> behaviour or execution trust is a useful way to locate responsibility
> across the stack.
>
> I would add a separate distinction between a trust judgement and an
> authority grant.
>
> A trust judgement is an assessment made by a receiving agent. It may be
> based on identity evidence, credentials, previous interactions, runtime
> observations or other signals. It is local to the verifier, dependent on
> its policy and capable of changing as new evidence arrives.
>
> Delegated authority is different. It is an attributable grant from a
> principal or authorised delegator. It should have an identifiable issuer,
> subject, scope, validity period and revocation mechanism. It answers what
> the agent may do, not whether another agent currently appears trustworthy.
>
> The two can therefore produce different results:
>
> an agent may be considered trustworthy but lack authority for the
> requested action;
> an agent may hold a valid delegation but still fail the receiving party's
> trust or risk policy;
> a positive trust judgement must not widen a delegation, extend its
> validity, or override revocation;
> a valid delegation must not be treated as proof that every interaction
> with the agent is trustworthy.
> A third decision is then required: whether this particular action is
> permitted under the applicable policy. That decision combines the authority
> grant, current revocation state, action scope and the receiving party's
> trust or risk evidence. It should not be inferred from any one of those
> inputs alone.
>
> From an operator's perspective, this is also an accountability boundary.
> The operator defines the applicable policy, scope, thresholds and failure
> mode. An agent's trust judgement can be an input to that policy, but it
> cannot become self-authorising. The enforcement point must decide before
> the external side effect and should produce an explicit allow, refer or
> deny result with evidence of the inputs used. If revocation or trust
> evidence is unavailable, the operator should expose the selected fail-open
> or fail-closed behaviour rather than leaving it implicit.
>
> A practical payment example makes the boundary visible. An agent may
> assess a merchant or service as trustworthy based on identity and prior
> behaviour. Before the agent can spend, the receiving system must still
> verify the principal's delegation, the permitted scope and amount, the
> intended recipient, the validity period and the current revocation state.
> If the delegation has been revoked, a positive trust judgement cannot
> restore it. If the delegation is valid but the service fails the receiver's
> risk policy, the result may be refusal or referral according to that
> policy, but it should not be an automatic allow.
>
> This suggests an additional interoperability test family alongside the
> freshness and revocation cases:
>
> valid delegation and positive trust judgement;
> valid delegation and negative or insufficient trust evidence;
> positive trust judgement but no delegation for the requested action;
> positive trust judgement after the delegation has been revoked;
> valid delegation with an action outside its scope;
> unavailable or stale trust evidence and unavailable revocation information.
> The expected result should be reported separately for:
>
> trust assessment;
> authority validity;
> action scope and policy decision;
> execution outcome.
> The key invariant should be that trust evidence can inform an
> authorisation policy, but cannot silently become authority. Equally,
> authority can establish permission to act within a scope, but cannot by
> itself establish trustworthiness of the counterparty or the outcome.
>
> This separation would allow different protocols to contribute identity,
> evidence, delegation or execution records without requiring one protocol to
> own the entire trust decision. It also gives the test suite a way to show
> precisely where implementations agree and where their responsibilities stop.
>
> Best regards,
>
> AlgoVoi
>
> On Thu, 22 Oct 2026 at 17:10, 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
>>
>>
>>
>>