ASILO：能力与作用点¶

ASILO 0.1 的说明性指南；能力的表示方式属于应用配置。

能力界定的是对某个资源的一项操作。其表示方式和机制属于应用配置；本指南不要求特定的签名、存储方式或语言。

契约声明被授权的身份或主体、资源、操作、上下文、有效期、撤销、允许的委派，以及相关的使用条件。如果某项操作必须是一次性的，应用配置要声明它如何判定并记录其消耗，即使在并发情况下也是如此。

从意图到结果¶

flowchart TD
  accTitle: ASILO：在作用点授权
  accDescr: 请求按顺序经过四项检查：按配置验证身份，输入符合契约，对资源、操作与上下文的授权，以及所要求的附加控制。任何否定回答都会拒绝请求且不产生效果；全部满足时在作用点执行。两种情况下都会记录结果与观察到的影响。
  P["请求"] --> I{"身份已按配置验证？"}
  I -->|"是"| V{"输入符合契约？"}
  I -->|"否"| R["拒绝，不产生所请求的效果"]
  V -->|"是"| A{"资源、操作与上下文已获授权？"}
  V -->|"否"| R
  A -->|"否"| R
  A -->|"是"| H{"所要求的附加控制已满足？"}
  H -->|"否"| R
  H -->|"是"| E["在作用点执行"]
  E --> L["记录结果与观察到的影响"]
  R --> L

SVG 图示：ASILO：在作用点的授权 · 可编辑的 Mermaid 源文件。箭头表示的是示意性的顺序，而不是一种实现。应用配置负责具体的检查、错误和记录。身份无效、输入不符合契约或未满足附加控制，同样会导致拒绝。

这个类比是：在想要打开的那扇门上出示钥匙。如果另有入口可以绕过，在前台所做的检查就不够。钥匙同样不能授权进入其他房间。在软件中，队列、重试和已缓存的响应都需要遵守相应的授权。

有效的权限并不能取代应用配置所要求的人工审查。当适用 ASILO-R-005 时，要保留其条件，以及针对关键影响的批准证据。只要缺少该条件，就不执行。

应用配置要解决的问题¶

谁来验证身份，并向作用点提供什么证据？
在返回已缓存的数据或执行排队的工作之前，是否检查了当前有效的权限？
如果权限在检查与操作之间过期或被撤销，会发生什么？
什么机制可以避免重复一项契约声明为唯一的影响？
如果操作已经发生而随后响应失败，应记录什么？

后续出现的错误并不能证明已经回退。撤销和并发操作需要明确的语义，并需要对真实机制进行测试；不能从接口推断得出。日志应避免复制密钥，并且只保留为其用途所必需的数据。

返回 ASILO · 边界测试。