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

Alan, agreeing on recourse, one addition from the EU side.

Recourse also depends on what can be shown afterwards. Under EU consumer
law, when a consumer places an order online, the merchant must make sure
the consumer explicitly acknowledges the obligation to pay. If it doesn't,
the consumer is not bound by the order (Directive 2011/83/EU, Art. 8(2)).

So when an agent places the order, the merchant will need to show who took
that step: the person, or an agent acting under a delegation. Trust
anchored in the operator tells you whom to hold responsible. A record of
who took the step, and under which delegation, is what lets you prove it.

On Tue, Oct 27, 2026 11:49 PM, Alan Karp <alanhkarp@gmail.com> wrote:

> I don't know that Agent<-Trust->Agent is the right approach.  Trust has to
> be associated with recourse if the trust is violated.  You're not going to
> drag an agent into court, so your trust is actually with the human (legal
> person) operator.  A nice side effect is that this approach deals with
> swarms of short-lived agents.
>
> --------------
> Alan Karp
>
>
> On Fri, Oct 23, 2026 at 5:55 PM Ren Yushan <keotheodangcha548@gmail.com>
> wrote:
>
>> I think we all have deep thoughts about the single word TRUST. And the
>> TRUST can mean a lot.
>>
>> However, what I want to ask is *what is the agent native way to Agent
>> TRUST when agents communicate*?
>>
>> Then we break up TRUST to several cases like:
>>
>> Agent <-TRUST-> Agent
>> Human <-TRUST-> Agent
>> Agent <-TRUST-> App Service(Access data or Agentic Payment)
>>
>> I think we can first fill in these blanks:
>>
>> What is Agent Identity? --- ANP DID
>> Who is behind the Agent? --- Authority granted human's agent DID
>> What can an Agent delegate access? --- App Service defines it.
>> Why can an Agent access? --- Human's intention.
>> Who can verify Human's intention? --- Trust Protocol
>> Can an Agent delegate to another Agent? --- Permission chain
>> How to trace the Permission chain? --- ???
>> *Can an Agent trust another Agent? --- ???*
>> *What resource should/should not an Agent send to another? --- ???*
>> ......
>>
>> Then fall back to the ANP protocol:
>>
>> What should belong to ANP?
>> What should other protocols fill? What are they?
>>
>> Best Regards,
>> Yushan Ren
>>
>>
>> On Fri, Oct 23, 2026 at 12: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
>>>>
>>>>
>>>>
>>>>