Subject: Re: [public-agentprotocol] Layer 0 Trust & Verification

Hi Gaowei, Ren, all,

Gaowei, you have hit the exact architectural crux. You are absolutely
right: Layer 0 (the underlying transport and identity root) is a
prerequisite. If we cannot establish trusted domain names and DIDs, secure
communication collapses.

Building Layer 0 on top of HTTPS is the correct industry direction.
However, as you noted, establishing a DID only proves the identity of the
agent. It does not prove that the agent is authorized to perform a specific
action.

This is the gap that NTI (Neutral Trust Infrastructure) addresses. We do
not compete with Layer 0 or DIDs. We anchor to them.

Here is how NTI handles the second type of trust problem:

1. Principal-Bound Identity: Following Alan Karp's feedback, we bind the
DID of the agent to the responsible legal party (the human or enterprise).
2. Runtime Non-Repudiation: Even with a trusted DID, an agent can be
hijacked by prompt injection. NTI acts as a runtime sidecar. It verifies a
post-quantum (Dilithium5) signature on every tool call. If the signature is
missing or invalid, it fails closed.
3. The incomplete_check: If the revocation registry (where we check if a
DID has been compromised) is unreachable, we do not proceed. The agent
enters a PAUSE state.

In short: Layer 0 proves the agent exists. NTI proves the agent is allowed
to execute this exact action at this exact moment.

I would love to see how we can integrate the ANP identity layer with the
NTI enforcement layer. I am dropping the spec link here for your review
(and for anyone else asking the Layer 0 question):

👉 https://github.com/abisheakp197/nti-spec


Best,
Abisheak

On Sun, 1 Nov, 2026, 2:51 pm Gaowei Chang, <chgaowei@gmail.com> wrote:

> Let me briefly share my thoughts for discussion.我简要分享一下我的想法供大家讨论。
> First, on trust. What is encoded in protocols may not be the trust we
> speak of in everyday terms, but rather cryptographic security mechanisms.
> Take HTTPS as an example: if I know the counterparty’s domain name, a
> cryptographic mechanism can establish a secure, hard-to-compromise
> connection between us. This is the foundational network trust enabled by
> cryptography. It comes with a prerequisite, though: you need a trusted
> domain name.首先谈谈信任。协议中所编码的或许并非我们日常所说的信任，而是密码安全机制。以 HTTPS
> 为例：若我知晓对方的域名，一种密码安全机制便能在我们之间建立安全且难以被破解的连接。这是密码学所支撑的基础网络信任。不过，这有一个前提条件：你需要一个可信的域名。
> Another approach is something like Verifiable Credentials (W3C VCs): a
> trusted authority issues a credential for a DID. By verifying that
> credential, I know the DID has at least been attested by that trusted
> authority. The trust placed in the authority itself may, in turn, stem from
> offline arrangements or built-in machine trust roots.另一种方法类似于可验证凭证（W3C
> 可验证凭证）：受信任的机构为去中心化标识符（DID）签发一份凭证。通过验证该凭证，我就能知道该去中心化标识符（DID）至少已得到该受信任机构的认证。而对该机构本身的信任，又可能源自线下约定或内置的机器信任根。
> My point is that protocols may not fully solve this second type of trust
> problem. If anyone has a strong solution, I’d welcome you to share it.
> 我的观点是，协议或许无法完全解决第二类信任问题。如果有人有更好的解决方案，欢迎分享。
> As for whether trust can be established using text, I’m not yet clear on
> your exact line of thinking. Agents are indeed highly capable of processing
> text. That said, for two agents to communicate, there must be a Layer 0
> protocol beneath the application layer; otherwise, secure communication
> cannot be established at all.
> 至于能否通过文本建立信任，我目前还不清楚你具体的思路。智能体确实具备极强的文本处理能力。但即便如此，两个智能体要进行通信，应用层之下必须存在0层协议，否则根本无法建立安全通信。
> The only real question is where this Layer 0 should sit. The prevailing
> view across the industry today is to build the Layer 0 protocol on top of
> HTTPS, which is also the direction we are taking.
> 唯一真正的问题是这个第0层应该位于何处。目前整个行业的主流观点是在HTTPS之上构建第0层协议，这也是我们正在采取的方向。
>
> On Thu, Oct 22, 2026 at 7:03 AM 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
>>
>