信任注册表要解决的问题
当智能体跨组织边界运作时，接收方系统如何知道它们此时此刻是否获得授权？
传统方案：
- 目录联合 —— 合并 Active Directory（复杂，暴露内部结构）
- API 回调 ——“智能体 42 是否获得授权？“（存在延迟，依赖可用性）
- 静态凭据 —— 长期有效的令牌（无法即时吊销）
问题：
- 延迟 —— 每次鉴权检查都需要网络往返
- 隐私 —— 暴露了你在检查谁、何时检查
- 吊销滞后 —— 令牌吊销并非即时生效
- 紧耦合 —— 双方系统必须集成对接
信任注册表 + TRQP 解决了这个问题：一种标准化协议，用于查询”[这个智能体] 现在是否被授权[执行此操作]？“，且无需暴露内部策略。
什么是信任注册表？
信任注册表是一个授权权威机构，用于回答某个实体（智能体、个人、系统）当前是否被授权执行某项操作的查询。
不是数据库转储 —— 它不会暴露全部策略；它只回答具体的问题：
- ✅ “
did:webvh:bankA.com:agent-42是否被授权执行交易？” - ✅ “
agent-42是否依然有效，还是已被吊销？” - ❌ 不会回答：“把你所有智能体的列表给我”（保护隐私）
关键属性：
- 仅供查询 —— 验证者提出问题；注册表回答是/否
- 实时性 —— 授权状态反映当前状态（吊销即时生效）
- 隐私保护 —— 注册表不会得知智能体在做什么，只知道有人验证过它
- 解耦 —— 无需共享基础设施；基于 DID 身份的 HTTP API
什么是 TRQP？
TRQP（信任注册表查询协议） 是用于查询信任注册表的标准化 HTTP API。
类比： TRQP 之于信任，就像 DNS 之于域名——一种通用的查询协议。
TRQP 查询：
POST /trust-registry/query
Content-Type: application/json
{
"query": {
"agent": "did:webvh:bankA.com:agent-42",
"action": "execute-trades",
"resource": "AAPL"
}
}TRQP 响应：
{
"authorized": true,
"authorizedBy": "did:webvh:bankA.com:trader-alice",
"expiry": "2026-12-31T23:59:59Z",
"conditions": ["trades < $1M per transaction"]
}TRQP 具备以下特点：
- 标准化 —— 所有信任注册表使用相同的查询格式
- 可扩展 —— 可为特定领域需求添加自定义字段
- 无状态 —— 每次查询都是独立的
- 可缓存 —— 响应可被缓存（带 TTL）以提升性能
信任注册表的工作原理
1. 注册（初始设置）
签发者在其信任注册表中注册智能体：
// A 银行注册 Agent-42
await trustRegistry.register({
agent: 'did:webvh:bankA.com:agent-42',
authorizedBy: 'did:webvh:bankA.com:trader-alice',
permissions: ['execute-trades'],
expiry: '2026-12-31',
conditions: { maxTradeValue: 1_000_000 }
})2. 查询（运行时）
验证者查询注册表：
// B 银行检查 Agent-42 是否获得授权
const response = await trqpQuery({
registryUrl: 'https://bankA.com/trust-registry',
query: {
agent: 'did:webvh:bankA.com:agent-42',
action: 'execute-trades',
resource: 'AAPL',
timestamp: new Date().toISOString()
}
})
if (!response.authorized) {
throw new Error('智能体未获授权')
}
// 若已获授权则继续执行3. 吊销（动态调整）
签发者吊销授权：
// A 银行吊销 Agent-42 (即时生效)
await trustRegistry.revoke({
agent: 'did:webvh:bankA.com:agent-42',
reason: '交易员 Alice 已离职'
})
// 下一次 TRQP 查询将返回 authorized: falseTRQP 查询示例
示例 1：简单授权检查
查询：
{
"query": {
"agent": "did:webvh:bankA.com:agent-42",
"action": "execute-trades"
}
}响应：
{
"authorized": true,
"authorizedBy": "did:webvh:bankA.com:trader-alice",
"expiry": "2026-12-31T23:59:59Z"
}示例 2：特定资源的授权
查询：
{
"query": {
"agent": "did:webvh:hospital.com:agent-99",
"action": "access-PHI",
"resource": "patient-12345"
}
}响应：
{
"authorized": true,
"authorizedBy": "did:webvh:hospital.com:caseworker-bob",
"expiry": "2026-07-22T00:00:00Z",
"conditions": ["purpose: treatment-review"]
}示例 3：已被吊销的智能体
查询：
{
"query": {
"agent": "did:webvh:bankA.com:agent-99"
}
}响应：
{
"authorized": false,
"reason": "智能体已被签发者吊销",
"revokedAt": "2026-07-20T14:30:00Z"
}信任注册表与其他方案的对比
| 维度 | 目录联合 | API 回调 | 信任注册表 + TRQP |
|---|---|---|---|
| 搭建复杂度 | 高（需合并目录） | 中（需定制集成） | 低（标准协议） |
| 隐私性 | 暴露内部结构 | 签发者能看到每一次查询 | 仅查询，不暴露内部信息 |
| 延迟 | 不稳定（LDAP 查询） | 需网络往返 | 快（HTTP + 缓存） |
| 吊销速度 | 数分钟至数小时 | 实时（但紧耦合） | 实时（且解耦） |
| 跨组织支持 | 需要联合协议 | 每个合作伙伴需定制 | 标准协议 |
真实应用场景
1. 跨组织智能体信任
场景： A 银行的智能体与 B 银行的系统进行交易。
流程：
1. A 银行为 Agent-42 签发 DID + Mandate (VC)
2. A 银行在其信任注册表中注册 Agent-42
3. Agent-42 向 B 银行发送交易请求
4. B 银行通过 TRQP 查询 A 银行的信任注册表:
"Agent-42 是否被授权执行交易？"
5. 信任注册表回应: "是，已获交易员 alice 的授权，2026-12-31 到期"
6. B 银行放行该交易核心优势： B 银行永远不会看到 A 银行的内部授权策略——只能得到是/否的答案。
2. 运行时治理
场景： 智能体请求修改生产环境配置。
流程：
1. Agent Gateway 收到来自 Agent-42 的请求
2. Gateway 查询信任注册表:
"Agent-42 是否被授权在生产环境中修改配置？"
3. 信任注册表检查:
- Agent-42 是否仍然有效？
- 授权人 (工程师 bob) 是否仍在职？
- 是否存在任何时间/资源限制？
4. 响应: authorized=true, conditions: ["需要审批"]
5. Gateway 在允许操作前强制执行多重审批核心优势： 运行时策略执行，而不仅仅是事后取证式的日志。
3. PHI 访问授权 (HIPAA)
场景： AI 智能体需要访问患者健康记录。
流程：
1. 个案管理员 Alice 授权 Agent-99 访问患者 patient-12345
2. 信任注册表记录: Agent-99 → 由 Alice 授权 → 24 小时后过期
3. Agent-99 请求访问 PHI
4. 系统查询信任注册表: "Agent-99 是否被授权访问 patient-12345？"
5. 响应: "是，已获个案管理员 alice 的授权，2026-07-22 到期"
6. 授予访问权限，审计日志记录该授权 VC核心优势： 符合 HIPAA 要求的授权证明——不只是一条日志记录，而是可通过密码学验证的凭证。
Affinidi 技术栈中的信任注册表
信任注册表产品 提供 TRQP 端点：
// 设置: 注册一个智能体
await affinidi.trustRegistry.register({
agent: 'did:webvh:yourcompany.com:agent-42',
authorizedBy: 'did:webvh:yourcompany.com:manager',
permissions: ['execute-trades'],
expiry: '2026-12-31'
})
// 运行时: 查询授权状态
const result = await affinidi.trustRegistry.query({
agent: 'did:webvh:yourcompany.com:agent-42',
action: 'execute-trades',
resource: 'AAPL'
})
console.log(result.authorized) // true/falseAgent Gateway 通过 TRQP 强制执行策略：
// 智能体携带 DID 发送请求
const request = {
agent: 'did:webvh:yourcompany.com:agent-42',
action: 'execute-trade',
payload: { symbol: 'AAPL', quantity: 100 }
}
// Gateway 在放行前查询信任注册表
const authorized = await agentGateway.checkAuthorization(request)
if (!authorized) throw new Error('未获授权')
// 若已获授权则继续执行性能优化：缓存 TRQP 响应
TRQP 响应可以被缓存以降低延迟：
// 带缓存提示的查询
const response = await trqpQuery({
registryUrl: 'https://bankA.com/trust-registry',
query: { agent: 'did:webvh:bankA.com:agent-42' },
cacheControl: 'max-age=300' // 缓存 5 分钟
})
// 缓存响应
cache.set(agent, response, { ttl: 300 })
// 后续查询命中缓存 (亚毫秒级)权衡： 如果吊销发生在缓存 TTL 期间，缓存的响应可能已过时。需要根据你的风险承受能力，在延迟与实时性之间做出权衡。
快速上手
面向开发者
查询信任注册表：
npm install @affinidi/affinidi-tdkimport { TrustRegistry } from '@affinidi/affinidi-tdk'
const registry = new TrustRegistry('https://yourcompany.com/trust-registry')
const result = await registry.query({
agent: 'did:webvh:yourcompany.com:agent-42',
action: 'execute-trades'
})
console.log(result.authorized) // true/false面向架构师
何时应使用信任注册表：
- ✅ 跨组织智能体授权
- ✅ 需要实时吊销
- ✅ 隐私保护型授权（不暴露内部策略）
- ✅ 解耦系统（无需共享基础设施）
何时不应使用：
- ❌ 紧耦合的内部系统 (使用传统的授权方案)
- ❌ 对亚毫秒级超低延迟有要求，连 HTTP 都太慢的场景
- ❌ 永远不会变化的静态授权
延伸阅读
规范：
- 信任注册表查询协议 (TRQP) 规范
- MAS SAFR 白皮书 —— TRQP 背后真实的监管驱动因素
Affinidi 文档：
相关深度解析：
相关解决方案：
Related resources