下面给你把第二部分（运行态零信任执行跨层级身份凭证与协同互认）里你提到的 (4)(5)(6) 补齐，并且把它们和第一部分产出的两类语义（“任务合法成员关系/绑定”、“多主体分权授权语义/能做什么”）贯通成一个完整体系。你可以直接把这段当作章节大纲+研究内容落地框架来用。

---

二、运行态零信任执行跨层级身份凭证与协同互认

在机动/协同/跨域三类运行态变化下，把第一部分定义并证明的两类语义持续“执行出来”：

• 绑定语义（是不是合法成员）：UE（人/机/站/软件代理）是否属于该任务的合法成员集合
• 授权语义（能做什么）：在多主体分权约束下，UE当前可执行的操作集合及其边界

（1）运行态“跨层级身份凭证链”建模：把语义落到可验证证据

1）凭证分层与对象关系（建议明确四层）

• 身份层：主体DID、可验证身份凭证（VC）
• 设备层：设备DID + 可信硬件/远程度量证明（attestation evidence）
• 任务层：任务成员绑定凭证（Membership VC / Task-bound VC）
• 权限层：最小权限能力凭证（Capability/Lease VC 或短时Token）

2）“绑定语义”的证据化表达

• 身份—设备—任务的绑定声明：<DID_subject, DID_device, TaskID, Role, Constraints, TTL>
• 绑定证明要包含：签发方、有效期、撤销指针、上下文约束（区域/时窗/频段/链路类型）

3）“授权语义”的证据化表达（多主体分权）

• 将“谁能干什么”表达为：
  • ABAC/策略型：属性+上下文满足才允许
  • 能力型：拿到“能力票据”才允许（可转授/不可转授、可拆分/不可拆分）
  • 阈值型：关键操作需多方联签/多数同意（M-of-N）

---

（2）零信任约束下的“轻量连续认证”与“受控协同”总框架

1）连续认证触发机制：从“周期”改为“事件驱动+风险驱动”

• 触发事件：位置/高度层变化、链路切换、编队关系变化、控制权转移、跨域接入、风险升高
• 风险信号：设备度量变化、行为/通信模式异常、策略冲突、证书接近过期、域信任分下降

2）跨层级执行面：PDP/PEP + 凭证编排

• PDP（策略决策点）做：验证凭证链 + 风险评估 + 策略求值
• PEP（策略执行点）做：会话门控、指令级授权、数据面加密访问控制
• 凭证编排：把“长凭证”（身份/设备）与“短凭证”（任务/能力租约）组合成可快速校验的“会话包”

3）安全目标（写进论文/方案很关键）

• 最小权限、持续验证、可撤销、可审计、抗重放/抗冒用、跨域可互认、资源可承受

---

✅ 你要补的（4）（5）（6）——三类运行态变化下的机制成体系展开

（4）机动资源受限下的轻量连续认证：算力/能量/带宽/链路波动约束

解决：飞行平台算力与电池敏感、链路间歇、认证频繁会“拖垮任务”。

1）约束建模（把问题写清楚）

• 计算约束：板载芯片算力有限，重签名/重验证成本高
• 通信约束：链路不稳定、带宽小、时延大、丢包
• 能量约束：认证与加密带来额外功耗
• 时钟/定位不稳：时间同步偏差导致会话票据失效风险

2）轻量化策略：把“持续认证”做成可降级、可自适应

• 分层验证：
  • 快路径：短时会话票据/缓存验证结果（毫秒级）
  • 慢路径：触发式远程度量/全链验证（秒级）
• 自适应频率：认证频率 = 风险函数（编队变化大就更频繁，巡航稳定就降低）
• 渐进披露/选择性披露：仅披露当前决策所需最小属性（减少通信+隐私泄露）
• 边缘协助/离线容忍：
  • 弱网时：允许“本地可验证的短租约”先行
  • 回联后：补齐审计与撤销检查（带“可追溯债务”机制）

3）连续认证证据来源：轻量但可信

• 设备侧：远程证明摘要（hash/度量链）、关键模块版本指纹
• 行为侧：通信节律、控制指令模式、航迹一致性（用于风险调权，不做唯一凭据）
• 环境侧：地理围栏/空域许可窗口/频段许可作为上下文约束

4）输出（写成明确产物）

• “轻量连续认证协议栈” + “风险自适应认证调度算法” + “弱网降级与追溯机制”
• 指标：认证时延、带宽开销、能耗、误拒/误受、弱网成功率、撤销生效率

---

（5）协同关系/控制权流转下的受控协同：动态组队、临时授权、可撤销接管

解决：协同过程中“谁在指挥谁”“控制权怎么转移”“临时协作怎么授权且不越权”。

1）协同语义分解：把“协同”拆成可控动作集合

• 关系变化：加入/退出编队、角色切换（侦察/中继/打击/诱饵等）
• 控制变化：操控权转移（A站→B站、地面→机载自治、域1→域2）
• 数据变化：共享传感数据、共享任务态势、共享资源（频谱/航线/算力）

2）受控协同核心机制：能力租约（Capability Lease）+ 分权审批

• 能力租约：
  • 明确操作集合（可发何指令/可读何数据/可调用何接口）
  • 明确边界（时窗、区域、高度层、速率、次数、链路类型）
  • 明确撤销（撤销指针 + 最短生效时间）
• 分权审批（多主体阈值授权）：
  • 高风险操作（接管、改航线、进入敏感空域）需要 M-of-N 联签
  • 低风险操作走单方授权，但受上下文约束与审计

3）控制权流转协议（建议你直接写成流程）

• 提议：发起方提交“接管/协作请求” + 当前绑定证明 + 风险上下文
• 审批：多主体签署租约（或策略引擎自动+人工兜底）
• 激活：生成短时“控制权票据”，PEP在指令级执行
• 监管：持续认证监测异常，触发冻结/降权
• 回收：租约到期/撤销触发，强制收回能力并记录审计链

4）关键安全性质（写清楚很加分）

• 最小权限、可追责不可抵赖、可撤销、抗越权扩散、抗冒用接管、抗“转授失控”

---

（6）跨域互认下的协同互信：不同域之间的身份/策略/撤销如何对齐

解决：多域协同最难的是“我信你的谁？你信我的哪些权限？策略不一致怎么办？撤销怎么同步？”

1）跨域互认的三层互认对象（体系化写法）

• 身份互认：承认对方域的身份签发与DID解析结果
• 绑定互认：承认对方域签发的“任务成员绑定”在本域可作为有效证据
• 授权互认：承认对方域的“能力语义/策略语义”在本域如何映射与限制

2）跨域互认技术路线（给你三个可选架构，按论文/项目偏好选）

• 信任注册表/信任目录：登记域的信任锚、VC schema、撤销入口
• 信任代理/网关（Trust Broker）：做策略翻译、属性映射、风险评估、隐私裁剪
• 去中心化互认：域间通过可验证的信任声明（Trust VC）互签，形成信任图谱

3）策略语义对齐：跨域“语义映射 + 最小披露”

• 属性映射：角色/等级/任务类型在不同域的等价关系与不等价约束
• 权限降维：跨域默认“降权互认”（只给对方域最低必需能力）
• 隐私最小化：只披露用于决策的最小属性集合（例如只证明“具备某资质/在某任务内”，不暴露真实身份细节）

4）跨域撤销与一致性：别让撤销变成短板

• 撤销检查弱网问题：本域可先基于短租约执行，回联后做撤销追验
• 关键能力票据必须短时有效 + 可快速失效（减少撤销传播压力）
• 审计对账：跨域操作生成可验证审计片段，支持争议裁决与追责

5）输出（明确交付物）

• “跨域互认协议（身份/绑定/授权三层）”
• “策略语义映射与降权互认规则”
• “跨域撤销与审计一致性机制”

---

二部分收束：建议你最后加一个“统一闭环”小节（让体系更完整）

（7）统一闭环：运行态零信任执行链路

• 输入：身份/设备/任务绑定凭证 + 多主体授权语义 + 运行态上下文
• 过程：验证→风险评估→策略求值→发放短租约→指令级执行→持续监测→撤销/降权→审计固化
• 输出：可证明的协同互认与控制权流转记录

---

如果你愿意，我也可以把这一整套进一步“写成论文体”的段落（每小节：问题—方法—协议/算法—安全分析—评测指标），并帮你把（4）（5）（6）各自补一张机制框图/流程图描述（文字版），方便你后续画图。

下面我按你问的两个点，把概念先“钉死”，再把（5）的“具体指啥、怎么做”给出一套可落地的机制（和你一/二部分的语义完全对齐）。

---

1）“全域 / 区域 / 节点”分别指什么？

这里建议你把它写成跨层级信任与控制的三层治理面（不是地理名词本身，而是治理与认证/授权的作用域层级）：

全域（Global / Federation Layer）

指整个多域联合体系的“最高层信任与互认平面”，作用是让不同域之间“能互信、能对齐、能追责”。

• 典型对象：全局信任锚（信任根/根CA或根DID）、互认目录/信任注册表、全局Schema（VC格式/语义）、跨域撤销与审计对账入口
• 典型能力：域间互认（谁是合法域、域的签发权是什么）、跨域策略基线（最低安全要求）、跨域追责证据格式

区域（Regional / Operational Area Layer）

指某个任务空域/作战区域/管制扇区/边缘云集群所覆盖的“区域域控层”，是运行态里最常见的“裁决/协调层”。

• 典型对象：区域域控/边缘控制器（区域PDP/协调者）、区域策略实例、区域风险评估与快速撤销广播、区域会话/租约签发
• 典型能力：对“本区域内”的 UE 做快速认证、连续认证调度、控制权流转仲裁、冲突消解（避免双控/分裂）

节点（Node / Endpoint Layer）

指具体执行与接入实体：无人机/地面站/中继/传感器/软件代理/载荷模块等（也包括它们上的 PEP）。

• 典型对象：UE、机载可信模块、节点PEP（指令门控/数据面门控）、本地缓存的短凭证/租约
• 典型能力：本地快速校验、指令级授权执行、弱网/断网下的“安全降级运行”、产生审计片段

一句话总结：

• 全域解决“域与域之间怎么互认”；
• 区域解决“运行态怎么协调/仲裁/撤销”；
• 节点解决“最后一公里怎么强制执行”。

---

2）“多主体动态协同与控制权流转下的身份—权限一致性与连续认证机制”具体指啥？

你这句话其实在说两个核心问题（都非常关键）：

A. 身份—权限一致性（Identity–Privilege Consistency）指什么？

在协同/控制权频繁变化时，要保证任意时刻：

1. 发指令的人/节点的身份是可验证的（你一(2)的“身份-设备-任务绑定”成立）
2. 它持有的权限与当前任务角色/上下文一致（你一(3)的“多主体分权授权语义”成立）
3. 权限不会因为流转而分裂/重复/漂移：不会出现“双控”“越权扩散”“撤销不生效”等

典型风险就是你描述的：

“一群人/一张控制权图在变，怎么保证权限不乱、执行不分裂”

B. 连续认证（Continuous Authentication）在这里指什么？

不是“固定周期再登录一次”，而是：控制关系/上下文一变，就触发轻量再证明，并且对高风险操作要求更强证明（甚至多方联签）。

---

3）那具体“怎么做”？——给你一套可写进（5）的机制框架

下面这套做法能把“控制权图在变”这件事管住：用“控制权图 + 短租约能力票据 + 原子化交接 + 风险驱动连续认证 + 区域仲裁/全域互认”。

3.1 把协同抽象成“控制权图”（Control-Right Graph）

• 节点：主体/控制节点/UE（人、地面站、无人机自治体、边缘控制器等）
• 边：对某UE的某类控制权/数据权的“能力租约”（Capability Lease）
• 边的约束：时窗、区域/高度层、指令集合、速率/次数、可否转授、是否需要多方联签

这样“多人协同”就不再是口头关系，而是可验证、可撤销、可审计的图结构。

3.2 权限载体用“短租约能力票据”（Lease/Capability Token），并绑定你的一(2)语义

每条“控制边”对应一个票据，票据里至少绑定：

• DID_subject + DID_device + TaskID + Role
• AllowedOps（可做什么） + Constraints（边界） + TTL（短时有效）
• Issuer（签发者：区域域控/多方联签） + RevocationPointer

节点PEP执行时只认两件事：
（i）你是不是合法成员（绑定证明） + （ii）你现在这张租约允许你做这个操作（授权语义）

3.3 控制权流转必须“原子化”（避免双控/分裂）

把“转交控制权”做成一个两阶段/三阶段的原子协议（写论文很好写）：

阶段1：Prepare（准备）
接管方提交：绑定证明 + 当前上下文 + 接管请求（包含目标UE、权限范围、时长）

阶段2：Commit（批准/签发）

• 低风险：区域域控单方签发租约
• 高风险：触发你的一(3)“多主体分权”——M-of-N 联签后签发
  同时生成一个**“控制纪元 epoch/序号”**（单调递增）

阶段3：Activate（激活/互斥生效）

• 新租约生效时，旧租约必须被同步撤销/冻结（至少在区域内广播）
• UE/节点只接受“epoch 最大且有效”的那张控制租约
  => 这样即使链路抖动，也能用“最大epoch规则”避免双控

关键点：互斥控制 = “同一UE同一控制域同一类控制权，在同一epoch只能有一个owner”
你要的“执行不分裂”，核心就靠这个。

3.4 连续认证用“事件/风险驱动”，并与租约联动

触发条件（举例就够写成体系）：

• 控制权边发生变化（加入协同、角色切换、接管/回收）
• 链路切换/跨域接入/区域变更
• 风险升高（设备度量变化、行为异常、策略冲突、撤销检查不可达）

触发后做的动作按成本分层：

• 快路径：校验租约签名 + TTL + epoch + 本地缓存撤销摘要
• 慢路径：远程度量证明/更强身份再证明/多方复核（仅对高风险场景触发）

3.5 断网/弱网怎么不乱？——“安全降级 + 追溯补账”

• 断网时允许执行短TTL、强约束的本地可验证租约（减少对撤销实时性的依赖）
• 回联后做“撤销追验 + 审计对账”
• 一旦发现冲突/撤销已发生：立刻降权或进入安全模式（悬停/返航/只读）

---

4）把（6）和上面机制的关系说清楚（你二(6)写起来就顺了）

• 全域层：定义互认基线（哪些域可信、VC/租约的语义schema、撤销/审计格式）
• 区域层：负责运行态的快速签发/撤销/仲裁（epoch、租约、冲突消解）
• 节点层：只做最小验证与强制执行（PEP按租约门控）

这样（5）的“控制权图/租约/epoch/连续认证”在域内能跑；（6）把“域与域之间”互认/传递/监管补齐，就形成你要的“可监管跨层级（全域/区域/节点）高效互认体系”。

---

如果你愿意我可以直接把（5）写成更“论文段落化”的版本：问题定义 → 威胁模型 → 机制设计（控制权图/租约/epoch/协议）→ 安全性质（互斥、最小权限、可撤销、可审计）→ 性能指标，你复制进正文几乎不用改。

区别不在于“谁来做认证”，而在于谁负责“裁决/一致性（coordination）”，谁负责**“本地强制执行（enforcement）”**——也就是 PDP vs PEP、全局视角 vs 本地视角。

---

1）区域层（Region）到底做什么？

区域层更像“运行态的域内控制平面/仲裁平面”，它解决的是：

• 一致性问题：同一时刻到底谁拥有某个UE的控制权？有没有“双控/分裂”？
  • 典型手段：控制权 epoch/序号、租约签发、冲突消解（谁的租约生效、谁必须失效）
• 撤销与传播问题：某个能力/租约被撤销，怎么在区域内快速同步，避免旧票据继续用？
  • 典型手段：区域撤销广播、区域会话目录/缓存、风险升级触发全链复核
• 策略裁决问题：多主体分权（M-of-N 联签）怎么落地、策略怎么求值、风险怎么评估？
  • 典型手段：区域PDP做策略求值+风险评估，决定“发不发租约、发多大、发多久”
• 跨节点协同的“规则”：不是把每个节点两两配对去谈规则，而是区域给出统一规则与状态，避免各干各的。

所以：区域层不等于“做节点间认证”；它更关键的是：** 让节点间的协同不会乱套**（一致性 + 撤销 + 仲裁 + 策略裁决）。

---

2）节点层（Node）到底做什么？

节点层是“最后一公里的执行平面/数据平面”，它解决的是：

• 本地快速校验：对方来了个指令/数据请求，我能不能立刻判断“你是谁、你能干啥”？
  • 典型手段：校验 DID/VC/短租约签名、TTL、epoch、上下文约束（区域/时窗/指令集）
• 强制门控：把裁决真正落实到“指令级/接口级/数据面”。
  • 典型手段：PEP拦截控制指令、API调用、数据访问；不满足就拒绝/降级
• 本地连续认证信号：节点产生最可信的运行态证据（设备度量、行为/链路状态、传感一致性），用于风险评估。
  • 典型手段：本地度量、轻量证明、异常检测触发再认证
• 弱网/断网下的安全运行：区域层可能暂时不可达，节点仍要靠短TTL租约 + 本地规则安全运行、避免失控。

所以：节点层不是“制定规则的人”，是执行规则的人，并且在断网时要能“安全自治”。

---

3）你说的“区域不就是解决节点与节点间的认证，那节点呢？”

更准确的分工是：

• 节点与节点之间的“身份校验/握手”：很多时候确实发生在节点侧（点对点）。
  但节点校验用的依据来自哪里？——来自区域/全域签发或认可的凭证与规则（VC/租约/撤销摘要/epoch）。
• 区域层解决的是节点点对点认证解决不了的事：
  1. 控制权互斥与一致性（防双控、防分裂）
  2. 撤销快速扩散（防旧票据继续用）
  3. 多主体分权裁决（高风险操作要联签/仲裁）
  4. 策略冲突消解（两个节点各说各话时，谁说了算？）

一句话例子：

• 两架无人机互相认证：节点能做（校验对方租约/身份）。
• 但“到底谁有权给第三架机改航线”+“旧控制者权限立刻失效”：必须要区域的仲裁/epoch/撤销，否则就可能双控或分裂。

---

如果你愿意，我可以把这段直接压成你正文可用的表述（更学术一点），并把“一个控制权转交场景”用区域 vs 节点分别写出消息流程（谁发什么、校验什么、什么时候撤销旧租约、epoch怎么比较），这样（5）那节会非常清晰。

这句话其实就是 （5）要解决的“核心矛盾” 的一个最典型例子。

（5）的标题里两件事：身份—权限一致性 + 连续认证。
而你这句——“谁有权改航线 + 旧控制者立刻失效”——对应的正是 身份—权限一致性 在“控制权流转”场景下的要求。

---

1）和（5）的关系：它就是（5）的问题定义（最关键那条）

在多主体协同里，控制权在变（控制权图在变），系统必须保证：

1. 唯一有效控制者（避免双控/分裂）
   同一时刻，对“第三架机的改航线权”只能有一个有效 owner。
2. 旧权利立即失效（可撤销、强一致）
   控制权转交后，旧控制者的“改航线权”必须立刻不能再被节点接受。
3. 新权利可证明、可执行（身份绑定+授权语义落地）
   新控制者不仅“说自己有权”，还要拿得出可验证的租约/能力票据，节点能本地强制执行。

你那句话把（5）的安全目标讲得非常精准：互斥 + 即时撤销 + 可证明执行。

---

2）为什么“必须要区域的仲裁/epoch/撤销”？——因为这是（5）的“手段”

（5）不是说“节点之间互相认证就行”，而是要在“控制权会变”的情况下，解决点对点认证解决不了的三件事：

A. 互斥一致性：靠 epoch（控制纪元）/仲裁

• 区域层负责签发“控制租约”并分配单调递增的 epoch
• 节点只接受 epoch 最大且有效 的控制租约
• 结果：即使网络抖动、消息乱序，也不会出现两个人都能控（双控）

B. 立即失效：靠撤销/冻结传播

• 区域层在签发新租约时，同时触发旧租约撤销/冻结（区域内快速扩散）
• 节点侧执行时检查撤销摘要/状态，旧票据马上用不了

C. 高风险转交：靠多主体分权（M-of-N）做“批准”

• “改航线/接管”这类高风险操作，区域层可以要求多方联签后才签发新租约
• 这就是你一(3)“多主体分权授权语义”在运行态的落地

所以你那句话里提到的 仲裁/epoch/撤销，就是（5）这一节的“关键机制组件”。

---

3）把（5）写清楚的一句话版本（你可直接放文稿）

（5）研究在多主体动态协同与控制权流转中，如何通过区域层仲裁签发的短时控制租约（带epoch）+ 快速撤销传播实现控制权互斥一致性，并由节点侧PEP指令级强制执行 + 事件/风险驱动连续认证保证身份—权限语义在运行态持续成立，从而避免双控、越权扩散与执行分裂。

---

4）给你一个“改航线权转交”的最小闭环（直观对应你那句话）

1. 新控制者请求接管（提交身份-设备-任务绑定证明）
2. 区域层仲裁：通过策略/分权审批 → 签发新租约（epoch=K+1）
3. 区域层同步撤销旧租约（epoch=K）
4. 第三架机节点PEP：只接受 epoch 最大且未撤销的租约
   → 旧控制者“立刻失效”，新控制者“可证明生效”，双控被消掉

---

如果你愿意，我可以把（5）进一步整理成**“三段式写法”**：

• 威胁/问题：双控、分裂、越权扩散、撤销不及时
• 机制：控制权图 + epoch租约 + 撤销 + 连续认证触发
• 性质与指标：互斥性、撤销时延、弱网一致性、认证开销、误接管率/误拒率

会的——但你这里把两件事混在一起了：连续认证（authn）和租约/epoch 的有效性检查（authz）。它们相关，但不是一回事；而且**（5）里 epoch 的价值不只是“过期”**，更关键是“没过期也要立刻失效”（控制权转交）。

下面把关系说清楚：

1）租约“过期”这件事，本质上不靠连续认证

epoch 租约是否有效通常由节点侧 PEP 做一个“硬检查”，几乎是每条指令/每次敏感调用都检查：

• 签名对不对
• TTL 是否过期
• epoch 是否是当前最新（或至少不小于本地已知最新）
• 是否在撤销列表/撤销摘要里

所以：即使你不做（4）那种连续认证，节点也应该能在执行时发现“租约过期了/不可用了”，直接拒绝。

2）（4）的连续认证能“发现过期”，但它解决的是另一类问题

（4）主要是在资源受限 + 匿名场景下，持续证明“你还是你、设备还是可信的、仍满足上下文约束”，它更多在做：

• 会话仍可信吗？（设备度量/环境/行为风险）
• 是否需要提升认证强度或重新发放/续租短票据
• 在弱网下如何降级、如何补账审计

它当然可以触发“你该续租了/票据快过期了”，但它并不负责“控制权互斥”。

3）（5）里 epoch 的关键：旧控制者没过期也必须立刻失效

你提的“会认证出来 epoch 租约过期”只覆盖了时间到期这一种失效方式。

但控制权流转最危险的是这类情况：

• 旧控制者的租约 TTL 还没到
• 但控制权已经转交给新控制者
• 如果没有 epoch/撤销/仲裁，旧控制者在 TTL 内仍可能继续发指令 ⇒ 双控/分裂

所以（5）用 epoch + 撤销实现的是：“替换式失效”

不是等你过期，而是我一转交，你立刻就该失效。

这件事不是（4）的连续认证能单独保证的。

4）两者怎么配合才“成体系”

最稳的组合是：

• 节点侧（PEP）每次执行都做硬校验：TTL + epoch + 撤销（这是授权强制执行）
• 连续认证负责“何时续租/何时降权/何时触发强认证”：风险驱动发新租约或收回租约（这是运行态持续可信）

一句话：

• （4）保证“你还是可信成员/设备仍可信”（偏认证）
• （5）保证“谁能控、控到什么程度、转交时不双控”（偏一致性授权）

如果你愿意，我可以把这段整理成（4）（5）衔接的小节写法（含一句定义 + 一句对比 + 一段“配合流程”），放进你正文里会非常顺。

对，（4）里确实既有认证也有授权。关键不在“有没有授权”，而在**（4）的授权解决的是“单主体/单权威下的授权新鲜度与轻量执行”，（5）的授权解决的是“多主体/多控制者下的授权一致性（互斥）与流转不分裂”**——这是两个层次的问题。

下面把差别讲清楚（你写正文也能直接用）。

---

（4）里的“认证+授权”在管什么？

（4）面向的是域内、单主体主导、资源受限/机动：典型是“某个UE在飞、链路抖、算力紧”，要持续证明：

• 认证（Authn）：你还是这次任务的合法成员（匿名/最小披露也行），设备仍可信、上下文仍满足。
• 授权（Authz）：你当前会话还能做哪些操作——通常体现为短时能力票据/租约（TTL短、范围小、可续租/可降级）。

所以（4）里的授权更像：

“在单一控制链条下，让权限持续新鲜、开销可控、弱网可运行”。

它默认**不存在或很少出现“多个控制者争同一控制权”**这种强冲突。

---

（5）为什么还要 epoch/仲裁/撤销？它解决的是（4）搞不定的“互斥一致性”

（5）讨论的是多主体动态协同 + 控制权流转，本质是“控制权图在变”。这里最致命的不是“过期没过期”，而是：

旧控制者的租约可能还没过期，但控制权已经转交了——必须立刻失效，否则双控/分裂。

这就是 epoch/仲裁/撤销存在的原因：

• epoch（控制纪元）：把“当前谁是合法控制者”做成一个可比较的全局/区域一致版本号
• 仲裁：当出现多个主体想要控制同一UE时，必须有一个“裁决点”决定谁拿到最新epoch的租约
• 撤销/冻结传播：让“没过期但已被替换”的旧租约立刻不可用

一句话：

• （4）保证“票据新鲜、轻量、不断线也能跑”；
• （5）保证“多人一起干时，权限不乱、控制不分裂、转交立即互斥生效”。

---

你提的“（4）连续认证会发现 epoch 租约过期”——是的，但只覆盖“时间失效”

连续认证当然能触发：

• 票据快到期 → 续租/再认证
• 风险升高 → 降权/收回票据

但它天然解决不了下面这个典型（5）问题：

• 旧租约 TTL 还在（没过期）
• 但控制权发生转交（应该立即失效）

这种“替换式失效”靠的是（5）的epoch + 撤销，不是靠“等到过期”或“周期再认证”。

---

最推荐你在正文里这样表述两者关系

（4）提供域内单主体场景下的轻量连续认证与会话级授权新鲜度维持（短租约续租/降级）；（5）在此基础上引入区域仲裁与epoch互斥机制，实现多主体协同与控制权流转中的身份—权限一致性（唯一有效控制者）与即时撤销，避免双控与执行分裂。

如果你愿意，我可以把（4）（5）各自补一句“研究目标/关键技术/输出指标”，并给你一个“控制权转交消息流程”图的文字版，方便你直接画图。

下面分别给你（4）（5）（6）各一个“会真的发生”的运行态例子，并标出为什么这是这一节在解决的问题。

---

（4）域内单主体资源受限/机动场景下轻量匿名连续认证：例子

场景：城市低空巡检任务（单域内），一架无人机在飞行中频繁切换链路与空域小区

• 无人机 UE 在同一个运营域内执行巡检：穿楼宇/桥梁导致 4G/5G ↔ 专网 ↔ 中继反复切换，链路抖动、带宽很小。
• 运营域只允许“任务合法成员”访问两类服务：
  1. 任务控制指令通道（起降、航点微调）
  2. 回传数据通道（视频/传感数据）
• 但 UE 算力/电量受限，不可能每隔几秒做一次重握手/全量证明；同时又希望“匿名/最小披露”（只证明“我属于该任务”，不暴露真实身份细节）。

会发生什么：

• UE 用“短时会话票据/租约”进入会话；飞到某个区域小区或链路切换时触发轻量连续认证（快路径），必要时才做强证明（慢路径）。
• 授权也在这里：票据里限定“只能上传视频、不能改航线；只能在该区域/该时窗有效”。

为什么属于（4）：

• 单主体/单域控：一个域内的控制平面给你发票据、续租、降权。
• 关键矛盾是：资源受限 + 机动导致上下文频繁变，要“持续可信”但又要“轻量 + 匿名”。

---

（5）多主体动态协同与控制权流转下身份—权限一致性与连续认证：例子

场景：同一任务编队协同，控制权在“地面A站 ↔ 地面B站 ↔ 区域边缘自治控制器”之间转交

• 一群 UE 在编队：侦察机、通信中继机、打击机。
• 起初由 A 地面站控制“打击机”的航线与载荷；后来 A 站链路质量下降，任务需要把控制权转交给 B 地面站，甚至短时间交给“区域边缘自治控制器”托管。
• 这时最危险的是：
  • A 站原来的控制租约 TTL 还没到期（“没过期”）
  • 但控制权已经转交给 B 站
  • 如果没有互斥机制，就会出现 双控/指令分裂（A、B都能改航线）

会发生什么：

• 区域层仲裁签发“控制租约（带 epoch）”：B 拿到 epoch=K+1 的新租约；同时 A 的 epoch=K 旧租约被撤销/冻结。
• UE 节点只接受“epoch 最新且未撤销”的控制租约，所以 A 会立刻失效，哪怕 TTL 还没到。
• 连续认证在这里也有，但它更多是对转交事件/风险升高触发再证明（比如接管属于高风险操作，需要更强证明/多方联签）。

为什么属于（5）：

• 关键矛盾是：控制权图在变（多个主体争夺/交接同一控制权），必须保证
  • 唯一有效控制者（互斥一致性）
  • 旧权利“替换式立即失效”（不是等过期）
  • 全程可审计、可撤销、不断裂
• 这是（4）的“续租/过期”解决不了的那类冲突问题。

---

（6）跨域认证与信任传递、可监管跨层级互认体系：例子

场景：跨运营域的应急协同——消防域无人机临时进入公安域/机场管制域的空域与网络

• 消防部门的无人机（域A）在灭火救援时，需要飞入靠近机场的敏感空域（域B：机场/空管域）并接入机场的监视/指挥网络。
• 域B不会“天然相信”域A签发的身份与权限：
  • A 说“它是救援任务成员”，B 要能验证
  • A 说“它可以进入某高度层、可以用某频段”，B 要能把这些语义映射到本域规则（通常还要降权）
  • 一旦 A 侧撤销（比如无人机丢失/被劫持），B 必须能快速生效

会发生什么：

• 全域层提供：域A/域B 的信任锚、VC schema、互认协议、撤销与审计格式。
• 区域层（域B 的区域控制/网关）做：策略翻译/降权互认（比如只允许“进入某扇区、只读态势、不得改航线”）。
• 节点层（机场网络入口/无人机本体）做：本地快速验证与强制执行。
• 产生可验证审计：跨域动作留痕，便于事后追责与争议裁决。

为什么属于（6）：

• 关键矛盾是：不同域之间身份、授权语义、撤销机制不一致，需要“互认 + 传递 + 监管”。
• 它要解决的不是“域内怎么轻量”，也不是“多人怎么交接”，而是“域与域怎么对齐并可监管”。

---

如果你愿意，我还能把每个例子再补一行“对应你章节里的关键词映射”（比如：绑定语义/授权语义/连续认证触发/epoch互斥/跨域降权互认/撤销传播），这样你直接放进（4）（5）（6）每节的开头当“动机场景”就很完整。

可以。（5）不一定要“编队/多机协同”，它本质是**“同一台（或同一任务对象）在多主体之间发生控制/授权关系变化”——哪怕只有一架无人机**，也完全成立。

下面给你一个不涉及编队、但会真实发生（而且特别典型）的（5）例子。

---

（5）不考虑编队的实际例子：单机任务的“多主体接管/托管/监管”链路

场景：一架物流无人机送货途中，控制权在多个主体之间流转

参与主体（多主体，但不是编队）：

• 运营控制中心（OC）：日常远程监控与指令下发
• 现场临时接管员（Field Operator）：在某个投递点附近，负责最后100米降落/避障确认
• 第三方空域/管制方（ATC/区域管制系统）：在临时空域管制时，对“航迹/高度/返航”有强制约束权（不是控制载荷，只约束飞行）
• （可选）机载自治模块：链路丢失时短时托管（failsafe）

为什么会发生（5）的问题？

送货过程中出现“关系变化/控制权变化”，例如：

1. 进入临时管制空域：管制方要求“你必须改走廊道/限高/返航”，这等于对飞行控制施加更高优先级的约束权
2. 到达投递点：现场临时接管员需要短时拿到“精确降落/微调航点”的权限
3. 运营中心链路抖动/策略升级：运营中心仍在线，但不再应当拥有“改航线”权（避免双控或违规）

（5）要解决的矛盾在这里具体长什么样？

• 运营中心手里原本就有“改航线/下发航点”的权限票据（TTL还没过期）
• 现在现场接管员/管制方也需要对同一架机下发某类指令
• 如果只是（4）那种“持续认证+票据续租”，会出现一个漏洞：
  旧票据没过期 ⇒ 旧控制者仍可能继续发指令 ⇒ 产生双控/冲突/执行分裂

（5）怎么做（对应你之前的“仲裁/epoch/撤销”）？

• 区域层仲裁：当“接管/管制介入”发生时，由区域控制面签发新的“控制租约/能力租约”，并赋予更高的 epoch（或更高优先级版本号）
• 旧权利替换式失效：同时撤销/冻结运营中心旧租约（即使TTL没到也立刻失效）
• 节点侧强制执行：无人机上的PEP对每条敏感指令检查：
  “租约签名 + TTL + 撤销状态 + epoch是否最新/优先级是否最高”
  ⇒ 最终只有一个来源的指令能被执行，避免分裂

---

一句话总结（不编队版）

（5）关注的是：同一任务对象（哪怕单机）在多主体之间发生控制权/权限流转时，如何保证“谁能干什么”在任何时刻都一致、互斥、可撤销，并且节点执行不分裂。

如果你愿意，我也可以按你“不编队”的设定，把（5）里的关键术语改得更贴合：把“协同”换成“多方监管/多角色接管”，把“控制权图”说成“单对象的多角色控制链”，更符合你这版叙事。

区别看**“是不是同一个信任/治理域”**（同一套信任根、同一套策略语义、同一套撤销与审计机制）——而不是看“有没有多主体”。

---

（5）= 域内多主体流转（一套规则里把控制权不搞乱）

前提：大家处在同一个域（或已经被当作同一个域来治理）

• 同一信任锚（同一套DID/VC体系或同一套域内CA/注册表）
• 权限语义一致（同一套“能做什么”的schema/策略语言）
• 撤销与审计在一个闭环里（撤销广播、epoch 规则、冲突仲裁都由域内控制平面管）

核心问题：控制权/权限在多个主体之间切换时

• 怎么保证互斥（同一类控制权同一时刻只有一个有效持有者）
• 怎么保证替换式立刻失效（旧票据TTL没到也必须马上失效）
• 怎么保证节点执行不分裂（只认最新epoch/最高优先级）

所以（5）是“在一套共同规则里，把动态流转管出一致性”。

---

（6）= 跨域互认与信任传递（两套规则之间先搞清“我凭什么信你”）

前提：主体/凭证/策略来自不同域（不同组织/不同治理边界）

• 不同信任锚（你域的签发者我不天然信）
• 权限语义不一致（你说“可改航线”，我域里可能要拆成多条细粒度能力，还要默认降权）
• 撤销不一致（你域撤销了，我域怎么及时知道并生效）
• 审计与监管要求不同（跨域要能对账、可追责、可仲裁）

核心问题：

1. 身份互认：我如何验证你域签发的身份/设备/任务绑定？
2. 授权语义映射/降权：你域的“能做什么”如何落到我域允许的最小能力集合？
3. 撤销与审计跨域传递：撤销如何传播、证据如何对账、监管如何落地（全域/区域/节点分层）

所以（6）是“两套规则之间先建立互信与语义对齐”，让后续控制/协作“能发生且可监管”。

---

一句话抓住边界

• （5）问的是：在同一个域里，多人/多角色切换控制权时，怎么保证唯一有效、立即失效、不分裂？
• （6）问的是：如果控制/接入牵涉到另一个域，怎么做到互认、语义对齐、撤销可达、审计可监管？

---

用你之前“单机送货”例子一刀切清楚

• 如果“现场接管员、运营中心、区域控制器”都属于同一运营公司的域控体系（同一信任根/策略/撤销闭环）
  → 这是 （5）域内控制权流转。
• 如果“临时管制方/空管系统”是另一个组织的域，它的凭证、策略、撤销都不归你管
  → 一旦它要对无人机下约束/发能力，你要先做互认与语义映射
  → 这是 （6）跨域互认（然后跨域内部再用（5）的epoch/撤销保证互斥执行）。

---

如果你希望我帮你把（5）（6）的边界写成论文里常用的“假设条件 + 问题定义 + 威胁模型”三段式，我也可以直接给一版可粘贴文本。

你这个疑问非常关键：（2）确实已经“把任务绑定发成了一个 VC”，那（3）还做什么？
答案是：（2）解决“你是谁/是不是任务成员”（成员资格关系）；（3）解决“你作为成员到底能干什么/谁来决定/怎么分权管控”（授权语义与治理）。两者可以都用 VC 表达，但语义层级不同、解决的问题不同。

---

（2）身份-设备-任务绑定：解决“合法成员关系（Membership）”

（2）的核心产物不是“权限”，而是一个可验证的成员关系：

• 谁是谁：主体 DID（人/组织/软件代理）与设备 DID（无人机/载荷/地面站）怎么绑定
• 是不是这次任务的合法成员：(主体/设备) ∈ TaskID 的成员集合
• 证明材料：DID/VC + 设备可信证明（远程度量/硬件证明）+ 可撤销机制

它回答的是零信任里最基础的一句：

“你先证明你是任务里的那个人/那台设备。”

类比：身份证/工牌（证明你属于这家公司/这个项目组）。

---

（3）多主体可信身份与授权：解决“能做什么 + 谁来给你这个权（Authorization & Governance）”

（3）不是重复发一个 VC，而是要把**“授权语义”和“多方分权治理”**补齐：

1）能做什么（权限语义要细到操作级）

同样是“任务成员”，权限可能完全不同：

• 只能上传遥测/视频 vs 可以改航线/改高度 vs 可以解锁载荷/进入敏感空域
• 还要带约束：时窗/区域/次数/速率/风险等级/是否可转授

成员 VC 只能说明“在任务里”，不能自动推出“可以改航线”。

2）谁来决定（多主体分权：不是一个人说了算）

低空运行里，授权往往要同时满足多方约束（这就是你写的“未来多方分权管控”）：

• 任务指挥方：决定任务操作权限
• 安全/空管/合规方：决定空域/高度/频段/安全动作权限
• 数据所有者：决定数据访问/共享权限
• 平台运维方：决定设备维护/升级/调参权限

因此（3）要定义并实现：

• 多方联签/阈值授权（M-of-N）：高风险操作必须多方同意
• 职责分离/最小权限：避免“一个成员拿到全权”
• 可委托/可回收/可审计：权力怎么转授、怎么立刻撤销、怎么追责

类比：（2）是你有工牌；（3）是你能进哪扇门、能操作哪台设备，而且某些门要两个人刷卡。

---

为什么“给无人机发一个任务 VC”不够？

因为会出现三类典型漏洞/缺口：

1. 成员不等于权限：任务成员里有观察员、操控员、维护员……不能默认全能
2. 权限需要多方约束：即使任务指挥想给你改航线权，空管/安全方可能不允许
3. 运行态权限是动态的：临时接管、风险升高降权、进入敏感区域触发额外审批——这些都需要（3）的“能力票据/租约/分权决策”体系来支撑

---

最清晰的分工一句话

• （2）定义并证明：UE 是不是任务合法成员（身份-设备-任务绑定关系成立）
• （3）定义并证明：作为成员，UE 在当前上下文下被允许执行哪些操作（多主体分权授权语义成立）

两者关系是：（2）是授权的前置条件，（3）是可执行操作的边界与治理。

如果你愿意，我可以把（2）的 VC（membership VC）和（3）的 VC/票据（capability lease VC / policy VC / threshold approval）各写一个“字段级模板”，让你章节里“语义怎么定义、怎么证明”更落地。

基本可以这么理解，但更准确一点是：

（2）是在证明“你是不是这次任务的合法成员”（身份/设备/任务绑定）

不是只证明“合法设备”，而是把 人/组织/软件代理（主体）+ 设备 + 任务 三者关系钉死：

• 这台无人机是谁名下/谁在负责（主体DID ↔ 设备DID）
• 这台无人机（连同操作者/控制端）是否被纳入 TaskID 的成员集合
• 证据形态：成员/绑定类 VC（可撤销、带时窗/区域等上下文约束）

一句话：（2）回答“你是谁 + 你是不是这次任务里的人/机”。

---

（3）是在证明“作为合法成员，你具有什么权限/能做什么”（多主体分权授权语义）

（3）关心的是“操作级能力”，并且强调多方共同决定（分权治理）：

• 你能发哪些指令/访问哪些数据/调用哪些接口
  例：只能上传遥测 vs 可以改航线 vs 可以接管控制 vs 可以解锁载荷
• 权限边界是什么
  例：仅在某区域/高度层/时窗有效，次数/速率限制，可否转授
• 谁批准的、是否需要多方联签
  例：改航线可能要“任务指挥+空管/安全”共同批准（M-of-N）

证据形态通常是：能力票据/短租约（Capability/Lease），或多方审批签署的授权 VC。

一句话：（3）回答“在当前上下文下，你能干什么 + 谁允许你干”。

---

两者关系

• （2）是前置门槛：不是任务成员，谈不上任何操作权限。
• （3）是操作边界：同是任务成员，也可能权限完全不同，而且权限会随运行态动态变化（续租/降权/撤销/接管）。

所以你那句可以改成更完整的版本：

• （2）= 合法成员（含合法设备/合法操作者/合法任务关系）
• （3）= 成员在特定上下文下的具体权限（多方分权决定）

在**（2）里说的“多主体”，主要不是“多方都给无人机发命令”，而是指： 任务成员关系（身份–设备–任务绑定）这件事，往往需要多方各自对不同部分负责背书/证明**。

你问的两个理解，分别对应两种完全不同的机制：

---

（2）里的“多主体”更接近：多方背书/联签“把它纳入任务成员”

发生在“发凭证/证明关系”的阶段，回答的是：

这台机 + 这个操作者/控制端，是不是这次任务的合法成员？

常见做法有两类：

A) 多方分别签不同的 VC（更常见）

• 运营方/组织：签“这是谁的设备/谁负责”
• 设备厂商/运维：签“设备可信/度量合格”（attestation 相关）
• 任务指挥/任务域控：签“此设备属于 TaskID 成员集合、角色是什么”

无人机/控制端在运行时携带一组 VC作为“成员证明包”。

B) 多方对同一份“成员VC”联签（也可做）

把“成员关系 VC”做成多签名：需要满足 M-of-N 才算“加入任务”。

注意：这仍然是“入组/成员资格”的多方背书，不是“发命令”。

---

“多方给无人机发命令/每一方都能发命令”属于（3）（甚至（5）），不是（2）

你提到的两种“多方发命令”模式，本质是授权与控制权设计：

1）多方联签批准“一条高风险命令”（推荐、常见）

• 实际执行上：无人机只接受一条命令
• 但这条命令要带上“多方批准的签名/授权票据”（如 M-of-N）
• 典型用于：改航线、进入敏感空域、接管控制等

➡️ 这是（3）“多主体分权授权语义（谁能干什么）”在命令级的落地；（5）再管“流转时不双控”。

2）每一方都可以发命令（通常要强约束，否则很危险）

如果多方都能直接发，会引入“双控/冲突”，所以一般只能在下面这种受限情形成立：

• 权限拆分：A 只能发载荷相关指令，B 只能发航迹约束，互不重叠
• 优先级/互斥机制：同一类控制权同一时刻只能有一个 owner（这就是（5）的 epoch/仲裁/撤销）

➡️ 这已经进入（5）的“控制权一致性与流转不分裂”。

---

一句话帮你定边界

• （2）多主体：多方对“成员资格/绑定关系”提供证明（签 VC/证明链）。
• （3）（5）多主体：多方对“能做什么/某条命令是否可执行/控制权如何互斥流转”进行分权管控。

如果你愿意，我可以按你论文写法，把（2）的“多方背书”明确成 2–3 个角色（任务方/运维方/监管方）各签什么 VC；再把（3）的“命令级多方联签”给一个字段模板（命令、约束、签名集合、有效期、撤销指针）。

你这个框架里，把零信任（持续验证/最小权限/显式策略）、多域（不同组织/不同治理边界）、**区块链（共享、可追溯、难篡改的信任账本）**结合起来，最稳的一句话是：

链上做“信任与治理的控制平面证据”（域信任、DID锚定、VC状态/撤销、审计、分权审批记录），链下做“实时执行平面”（PDP/PEP 快速决策与拦截）。
这样既符合零信任实时性，又用区块链解决多域互认与追责。

下面我给你：怎么结合的设计要点 + 4 张你能直接画/直接用的图（含 mermaid 代码）。

---

一句话落位：区块链放在哪些“关键点”

链上适合放（共识慢也能接受）：

• 多域信任锚/域证书/域DID与互认声明（哪个域可信、信任级别、有效期）
• DID 文档锚定/更新索引（或其哈希指针）
• VC 的撤销/冻结状态（revocation registry / status list 指针）
• 多主体分权的审批结果（M-of-N 联签、投票结果、谁批准了什么）
• 审计与追责证据的哈希锚定（谁在什么时间做了什么操作）

链下必须做（实时、低时延）：

• 节点侧 PEP 的指令级拦截（TTL/epoch/撤销摘要的快速校验）
• 区域侧 PDP 的策略求值/风险评估/短租约签发（可缓存链上状态）

---

对应你大纲：每节怎么“用上链”

• (1) 多域划分/边界：链上登记“域信任锚 + 域间互认声明 + 监管可见的最小基线”
• (2) 身份-设备-任务绑定：VC 本体链下携带；链上仅放“VC 状态/撤销指针 + Schema/发行者登记”
• (3) 多主体授权：高风险授权把“多方联签/投票结果”上链；最终执行用短租约（链下）
• (4) 轻量连续认证：连续认证主要链下跑；链上用于“撤销状态、审计锚定”
• (5) 控制权流转一致性：区域签发带 epoch 的控制租约（链下），同时把“epoch变更/撤销锚点/审计哈希”上链（可监管、可追责）
• (6) 跨域互认：链上做“互认目录 + 策略语义映射登记 + 撤销可达性”，链下做“翻译/降权/执行”

---

建议画的 4 张图（可直接用）

图1：总体架构（多域 + 零信任控制平面 + 区块链信任账本）

mermaid
flowchart TB
  subgraph L[联盟链 / 信任账本(链上)]
    T1[域信任锚/域DID登记]
    T2[互认声明(Trust VC)]
    T3[VC撤销/状态索引]
    T4[分权审批记录(M-of-N)]
    T5[审计哈希锚定]
  end

  subgraph A[域A]
    A_PDP[区域PDP/仲裁器]
    A_CA[发行者/任务域控(VC签发)]
    A_PEP[节点PEP(无人机/地面站)]
  end

  subgraph B[域B]
    B_PDP[区域PDP/信任代理]
    B_CA[发行者/监管方]
    B_PEP[节点PEP(空域入口/基站)]
  end

  A_CA -->|签发 Membership VC / Capability Lease| A_PEP
  A_PDP -->|短租约/epoch/撤销摘要| A_PEP

  A_CA <-->|登记发行者/Schema/状态指针| L
  A_PDP <-->|写入审批与审计锚点| L
  B_PDP <-->|读取互认/撤销/映射| L
  B_CA <-->|登记信任锚| L

---

图2：凭证体系（(2)绑定VC 与 (3)授权VC/租约 的关系；链上只管状态/治理）

mermaid
flowchart LR
  subgraph Off[链下：随会话携带/实时校验]
    M[Membership VC\n(身份-设备-任务绑定)\n回答:是不是任务成员]
    C[Capability Lease / AuthZ VC\n(能力/租约/约束+TTL+epoch)\n回答:能做什么]
    A[Attestation Evidence\n(设备可信证明)]
  end

  subgraph On[链上：共享状态与治理证据]
    R[Revocation/Status Registry\n(撤销/冻结/状态)]
    S[Schema & Issuer Registry\n(发行者/语义模板)]
    G[Governance Record\n(M-of-N审批/投票结果)]
    H[Audit Hash\n(操作留痕锚定)]
  end

  A --> M
  M --> C
  C -->|校验状态| R
  M -->|校验发行者/模板| S
  C -->|高风险需分权背书| G
  C -->|产生审计锚点| H

---

图3： (5) 单对象控制权流转（不编队）——epoch/撤销避免“双控与分裂”

mermaid
sequenceDiagram
  participant Old as 旧控制者(运营中心A)
  participant New as 新控制者(现场接管员B)
  participant Reg as 区域仲裁/PDP
  participant UE as 无人机节点PEP

  New->>Reg: 请求接管(提交Membership VC + 上下文)
  Reg->>Reg: 策略求值/风险评估\n高风险则触发M-of-N审批(链上可见)
  Reg-->>New: 签发新控制租约 Lease(epoch=K+1, TTL短, 约束)
  Reg-->>Old: 撤销/冻结旧租约 Lease(epoch=K)\n并广播撤销摘要
  New->>UE: 下发指令 + Lease(epoch=K+1)
  Old->>UE: 试图下发指令 + Lease(epoch=K)
  UE->>UE: 校验签名/TTL/撤销/epoch
  UE-->>New: 执行(接受epoch最大且未撤销)
  UE-->>Old: 拒绝(即使TTL未到也失效)

---

图4： (6) 跨域互认与权限传递（“先互认/映射/降权”，再执行）

mermaid
sequenceDiagram
  participant A as 域A(消防/运营方)
  participant L as 信任账本(链上)
  participant B as 域B(空管/机场域)
  participant GW as 域B信任代理/区域PDP
  participant UE as 无人机/入口PEP

  A->>L: 发布/更新 域A信任锚、发行者登记、撤销入口
  B->>L: 发布 域B信任锚、互认策略基线
  GW->>L: 查询 域A互认声明/VC状态/撤销
  A->>GW: 提交 Membership VC + 申请跨域能力
  GW->>GW: 语义映射&降权\n(将A的权限映射为B允许的最小能力)
  GW-->>A: 签发跨域短租约(可监管、TTL短)
  A->>UE: 带租约访问/进入空域/请求服务
  UE->>UE: 本地校验(签名+TTL+撤销摘要)
  UE-->>A: 放行/拒绝
  GW->>L: 锚定审计哈希(可追责)

---

你画图时的“标题建议”（直接贴论文/方案里）

• 图1：多域零信任 + 区块链信任账本的控制-执行分层架构
• 图2：绑定语义（Membership）与授权语义（Capability）及其链上状态治理
• 图3：控制权流转下的 epoch 互斥与撤销传播（避免双控/分裂）
• 图4：跨域互认：信任锚—语义映射—降权租约—可监管审计闭环

---

如果你希望我再给你两张更“论文味”的图：
1）威胁模型/攻击面覆盖图（冒用、重放、越权、双控、撤销延迟、跨域语义漂移）
2）状态机图（租约：Issued→Active→Replaced→Revoked→Expired；对应(4)(5)(6)触发条件）
我也可以继续补上同样可直接用的 mermaid。

mermaid
flowchart TB
  subgraph L[联盟链/信任账本（链上）]
    T1[域信任锚/域DID登记]
    T2[域间互认声明（Trust VC）]
    T3[VC状态/撤销索引（Status/Revocation）]
    T4[分权审批记录（M-of-N联签/投票）]
    T5[审计哈希锚定（可追责）]
  end

  subgraph A[域A（运营/任务域）]
    A_CA[发行者/任务域控（VC签发）]
    A_PDP[区域PDP/仲裁器（策略+风险）]
    A_PEP[节点PEP（无人机/地面站）]
  end

  subgraph B[域B（监管/空管域）]
    B_CA[发行者/监管方（域B信任锚）]
    B_PDP[区域PDP/信任代理（映射+降权）]
    B_PEP[节点PEP（入口/基站/网关）]
  end

  A_CA -->|Membership VC（成员绑定）| A_PEP
  A_PDP -->|短租约/epoch/撤销摘要| A_PEP

  A_CA <-->|发行者/Schema/状态指针登记| L
  A_PDP <-->|审批记录/审计锚点写链| L

  B_CA <-->|域B信任锚登记| L
  B_PDP <-->|查询互认/撤销/映射依据| L
  B_PDP -->|跨域短租约/降权能力| B_PEP

mermaid
flowchart LR
  subgraph Off[链下（实时携带/快速校验/执行）]
    A[Attestation Evidence\n设备可信证明/度量证据]
    M[Membership VC\n身份-设备-任务绑定\n回答：是不是任务成员]
    C[Capability Lease / AuthZ VC\n能力/租约（约束+TTL+epoch）\n回答：能做什么]
    PEP[节点PEP\n指令/接口/数据面门控]
  end

  subgraph On[链上（共享治理/状态/追责）]
    S[Issuer & Schema Registry\n发行者登记/语义模板]
    R[Status/Revocation Registry\n撤销/冻结/状态列表]
    G[Governance Record\nM-of-N审批/联签结果]
    H[Audit Hash Anchor\n审计哈希锚定]
  end

  A --> M
  M --> C
  C --> PEP

  M -->|校验发行者/模板| S
  C -->|校验状态/撤销| R
  C -->|高风险需分权背书| G
  PEP -->|操作留痕哈希锚定| H

mermaid
sequenceDiagram
  participant Old as 旧控制者（运营中心A）
  participant New as 新控制者（现场接管员B）
  participant Reg as 区域PDP/仲裁器
  participant UE as 无人机节点PEP

  New->>Reg: 请求接管（提交Membership VC + 上下文）
  Reg->>Reg: 策略求值/风险评估\n高风险→触发M-of-N审批（可写链）
  Reg-->>New: 签发新控制租约 Lease(epoch=K+1, TTL短, 约束)
  Reg-->>Old: 撤销/冻结旧租约 Lease(epoch=K)\n广播撤销摘要/更新状态
  New->>UE: 指令 + Lease(epoch=K+1)
  Old->>UE: 指令 + Lease(epoch=K)（TTL未到）
  UE->>UE: 校验：签名/TTL/撤销/epoch最大
  UE-->>New: 执行（接受epoch最新且未撤销）
  UE-->>Old: 拒绝（替换式立即失效）

mermaid
sequenceDiagram
  participant A as 域A（运营/消防）
  participant L as 信任账本（链上）
  participant B as 域B（空管/机场）
  participant GW as 域B信任代理/区域PDP
  participant PEP as 域B入口PEP/无人机PEP

  A->>L: 登记域A信任锚/发行者/Schema/撤销入口
  B->>L: 登记域B信任锚/互认基线/映射规则
  GW->>L: 查询域A互认声明/VC状态/撤销信息
  A->>GW: 提交Membership VC + 申请跨域能力（进入空域/接入网络）
  GW->>GW: 语义映射&降权\n（按域B策略生成最小权限）
  GW-->>A: 签发跨域短租约（TTL短/可监管/可撤销）
  A->>PEP: 携租约接入/进入空域/请求服务
  PEP->>PEP: 本地校验（签名+TTL+撤销摘要）
  PEP-->>A: 放行/拒绝
  GW->>L: 锚定审计哈希（跨域可追责）

给你生成了 4 张可直接用的架构图（PNG）：

• 图1：多域零信任 + 区块链（链上证据/治理，链下实时执行）
• 图2：（2）成员绑定 vs（3）能力授权（为什么两者都需要）
• 图3：（5）单机控制权流转：epoch + 撤销避免双控/分裂
• 图4：（6）跨域互认与权限传递：映射+降权+可监管审计