链接式 Web 存储用例

LWS 规范的用例如下所述。

通用存储

作为用户，我希望拥有一个与格式无关的在线存储系统，支持任何类型的资源，以便我可以随时从任何设备执行创建、读取、更新和删除（CRUD）——包括元数据和访问控制修改，以及恢复以前的版本。 背景：这可确保跨设备的无缝数据管理，使用户能够完全控制其资源。
议题： #117, #97, #60, #63, #62, #69
可移植存储

作为用户，我希望能够自托管我的存储，或在提供者之间切换而不会丢失数据，以便我保留数据主权，并能够在提供者中断服务或迁移时承受影响而不丢失数据。 背景：可移植性可避免供应商锁定并增强数据主权。
议题： #30, #58, #140, #61
离线数据访问

作为用户，我希望能够离线访问和修改我的数据，并在重新连接后自动同步，以便我可以在没有网络的情况下工作，并避免数据损坏或冲突。
背景：离线支持对于网络连接不可靠地区的用户至关重要。
议题： #138, #64, #65, #67
大文件上传

作为用户，我希望能够通过可恢复上传来上传大文件，以便中断不会迫使我重新开始整个传输。
背景：这改善了管理大型媒体或数据文件时的可用性。
议题： #18

共享访问

作为数据所有者，我希望授予和撤销对我的资源的细粒度权限，以便协作者拥有适当的访问权限，并在其权限发生变化时收到通知。 背景：细粒度控制可确保安全且定制化的数据共享。
议题： #7, #27, #116, #148, #120, #98
权限变更通知

作为协作者，我希望在我对某项资源的权限被授予、撤销或修改时收到通知，以便我能及时了解访问权限的变化。背景：及时通知可帮助协作者了解其对共享资源的访问情况，从而增强协作和安全性。 议题： #116, #78
配置文件共享

作为用户，我希望维护多个具有不同访问控制的配置文件，以便我可以共享特定信息，同时保持其他数据私密。 背景：多个配置文件支持不同身份面向或上下文（例如工作与个人）。
议题： #29, #57
群组共享

作为用户，我希望与动态群组（例如活动参与者）共享数据，以便随着群组发展，成员资格和权限能够自动更新。
背景：这简化了临时或变化协作中的访问管理。
议题： #38, #102
行政助理

作为用户，我希望向助理委派特定权限，并通过审计日志跟踪其操作，以便他们可以代表我安全地管理我的数据。
背景：委派有助于需要协助的用户，同时保持监督。
议题： #10, #104, #118
上下文感知访问策略

作为管理员，我希望基于时间、地理位置或相对位置（靠近 Bob）等上下文因素强制执行访问策略，以便对数据的访问能够动态适应真实世界条件。
背景：上下文感知策略增强了安全性和灵活性。
议题： #17, #147, #94
健康记录访问

作为患者，我希望使用委派授权与 AI 助理共享特定健康记录，以便我可以获得第二意见，并通过审计日志确保问责。
背景：这支持安全、可审计的健康数据共享，以便作出知情决定。
议题： #11, #46, #54

会议安排

作为用户，我希望直接通过我的存储安排会议，并支持在线和离线场景的冲突检测，以便我避免重复预订。
背景：集成式日程安排可提升生产力和协调性。
议题： #3, #42
实时通知

作为协作者，我希望在我访问的资源被更新时收到实时通知，以便我无需手动检查即可保持知情。
背景：及时更新可提升协作效率。
议题： #32, #79
应用通知

作为用户，我希望收到有关存储活动的电子邮件或 Web 推送通知，以便我能够了解重要事件。
背景：通知让用户持续关注其数据。
议题： #100
通用通信

作为用户，我希望与其他存储所有者建立直接消息通道，以便我可以在平台内无缝协作。
背景：内置通信可增强用户互动。
议题： #99, #22
投票

作为用户，我希望在我的存储中创建和管理投票，以便我可以收集他人的意见和反馈。
背景：投票支持决策和社区参与。
议题： #144
语义协作

作为用户，我希望使用永久 URI 和灵活权限与他人共同创作结构化内容，以便协作高效且可追踪。
背景：这支持共享知识库等高级用例。
议题： #146, #98

个人信息管理

作为用户，我希望在我的存储中管理个人数据，并通过某种数据转换将其与非 Solid 应用集成，以便我可以使用各种应用而不产生数据孤岛。
背景：这促进了互操作性和用户控制。
议题： #2
“自带数据”应用

作为应用开发者，我希望我的应用将数据存储在用户的存储中，并支持 CRUD 操作和存储发现，以便用户保留其数据的所有权和控制权。
背景： 这将数据所有权从应用转移给用户。
议题： #12, #120
数字商品交付

作为用户，我希望安全交付数字商品（例如软件、媒体），并带有确认回执，以便提供者可以在最少干预下交付资产。
背景：这可确保可靠的数字产品交付。
议题： #14
数据集成

作为应用开发者，我希望有一个标准化 API 来组合来自多个来源的数据，以便集成多样化数据集变得直接而高效。
背景：简化的集成降低了开发复杂度。
议题： #26, #53, #88, #106
业务数据访问

作为业务用户，我希望有明确的数据共享执行规则，以便企业集成符合组织策略。
背景：这支持安全的企业用例。
议题： #27, #28

时间序列存储

作为用户，我希望存储具有分辨率限制和多维分析支持的时间序列数据，以便我能够高效地分析随时间变化的趋势。
背景：这对于 IoT 或分析等应用至关重要。
议题： #6
传感器数据共享

作为用户，我希望以不同粒度级别共享传感器数据而不发生重复，以便消费者只接收其所需的细节。
背景：高效共享可减少资源使用。
议题： #8
法律报告

作为数据提供者，我希望获得数据共享的可验证证明以支持审计合规，以便即使在访问被撤销后，我仍能履行法律义务。
背景：这可确保透明度和问责性。
议题： #9
搜索功能

作为用户，我希望拥有具备上下文感知和安全执行能力的强大搜索功能，以便我可以快速且安全地找到相关资源。
背景：有效搜索对于大型数据集至关重要。
议题： #152, #87
分页与过滤

作为用户，我希望能够对搜索结果进行高效分页、过滤和排序，以便我可以轻松浏览大型数据集。
背景：这些功能增强了数据可用性。
议题： #103
SPARQL 查询

作为高级用户，我希望支持 SPARQL 查询，以执行复杂搜索和数据分析，以便我能够从链接数据中提取洞见。
背景：SPARQL 支持高级语义 Web 查询。
议题： #45
网站创建

作为用户，我希望使用持久 URI 发布自描述网站，以便我的内容能够随着时间保持可访问和可互操作。
背景：这支持持久的 Web 发布。
议题： #31
家庭访问

作为用户，我希望从具有动态 IP 的家庭设备访问我的存储，以便连接问题不会阻止我使用我的数据。
背景：这可确保家庭环境中的可访问性。
议题： #105, #68
上下文交互

作为用户，我希望在内容旁边根据上下文显示交互，以便我可以直观理解权限和历史记录。
背景：这可提升用户对数据交互的理解。
议题： #55
WebID 配置文件交互

作为用户，我希望点击 WebID 时显示配置文件和可用操作，以便我能够轻松与联系人互动。
背景：这增强了社交和专业互动。
议题： #48, #47
存储监听

作为应用开发者，我希望离线监测存储变更，以便我的应用即使在无连接的情况下也能保持同步。
背景：这支持稳健的离线应用功能。
议题： #101

“端到端”加密

作为用户，我希望所有数据存储和传输都使用端到端加密，以便只有授权方能够解密并访问我的信息。
背景：加密可确保数据机密性。
议题： #4, #44, #73, #74, #75, #76
基于同意的共享

作为用户，我希望拥有带有审计轨迹的可验证同意机制用于数据共享，以便我能够确保符合隐私法规。
背景：同意管理支持合乎伦理的数据实践。
议题： #141, #80, #81, #82, #83, #84, #85, #86
法律依据支持

作为合规官，我希望基于法律依据（例如 GDPR）定义访问策略，以便数据共享符合监管要求。
背景：这可确保具备全球合规准备。
议题： #80, #141, #77

存储所有权

作为用户，我希望在创建存储时分配所有权，以便我从一开始就拥有完全控制权。
背景：即时所有权明确了用户权限。
议题： #43
高性能访问控制

作为用户，我希望访问控制机制响应迅速且可扩展，以便系统即使在高负载下也能表现良好。
背景： 性能对于大规模使用至关重要。
议题： #72, #153, #71
清晰的错误消息

作为用户，我希望错误消息清晰且可操作，以便我能够快速且不受挫地解决问题。
背景：良好的错误处理可增强用户体验。
议题： #34

身份与凭据管理

作为用户，我希望在本地管理我的身份和凭据，以便我能够直接从我的设备控制我的认证过程。
背景：本地管理可增强安全性和自主性。
议题： #25, #90, #115, #153, #128
认证机制

作为用户，我希望支持现代认证方法，例如 passkeys、静默认证以及脚本友好的选项，以便我能够在多样化场景中安全地进行认证。
背景：灵活的认证可满足多样的用户需求。
议题： #39, #41, #49, #50, #51, #114, #162, #129, #130, #136
存储提供者的信任机制

作为存储提供者，我希望拥有一种机制来信任身份提供者对实体进行认证，以便我能够确保只有已认证且已授权的实体访问存储。
背景：在一个可能涉及多个身份提供者的去中心化系统中，这种信任关系对于维护安全性至关重要。
议题： #129

API 协议解耦

作为开发者，我希望API 与 HTTP 解耦，以便我可以构建本地优先应用，或使用 gRPC、GraphQL 等替代协议。
背景：解耦增强了开发灵活性。
议题： #24
后端服务集成

作为服务提供者，我希望拥有 mTLS 等安全认证方法或更简单的替代方案用于后端服务，以便与 LWS 的集成无缝且安全。
背景：这可确保可靠的后端连接。
议题： #40, #56, #92
存储描述与发现

作为用户或应用，我希望检索关于可用存储和服务能力的元数据，以便我可以适当地配置交互并适应不同的存储行为。
背景： 以标准化方式描述服务器能力，使客户端能够动态调整其操作，改善互操作性，并促进工具或自动化。
议题： #21

存储灵活性

作为用户，我希望能够动态拆分或聚合存储单元，以便我可以随着需求变化调整容量和组织方式。
背景：灵活存储支持可扩展性和定制化。
议题： #110, #136, #127, #69, #70
超媒体创作

作为开发者，我希望拥有用于创作超媒体表示（例如 JSON-LD、Siren）的一致机制，以便客户端能够以统一方式导航和交互 API。
背景：标准化超媒体可改善 API 可用性。
议题： #33, #124

以下需求已被确定，并足以满足上述用例。这是一份非规范性文档，工作组可能会决定某些需求不在范围之内。

	1	2	3	6	7	8	9	10
通用存储		✓	✓		✓
可移植存储		✓	✓	✓
共享访问	✓		✓			✓	✓
配置文件共享	✓		✓			✓	✓
群组共享	✓		✓			✓	✓
行政助理	✓		✓			✓	✓
离线数据访问	✓	✓						✓

在存储中添加、更新、删除资源 — 协议应允许经授权的实体在存储中添加、更新和/或删除资源。一般而言，协议应允许任何类型的资源被存储在存储中，但存储提供者可能会施加某些限制，例如类型或大小方面的限制。

议题： #117, #124
故事：通用存储
数据共享 — 协议应允许实体向另一个实体授予其所控制资源的访问权。换言之，第一个实体可以允许另一个实体对该资源执行某些操作（读取、修改、删除……）。访问授予可以是临时的，即具有到期时间，也可以不是。第一个实体应能够在以后修改此类委派，例如更改到期时间或完全撤销委派。

议题： #27, #118
故事：共享访问、配置文件共享、群组共享、健康记录访问
认证机制 — 协议应支持集中式、联合式和/或自我主权类型的认证机制。

议题： #25, #90, #115, #128, #39, #49
故事：身份与凭据管理、认证机制
全局唯一标识符 — 资源，包括实体和存储，应当能够在全球范围内被唯一标识。任何两个不同资源都不应共享同一个标识符（不过，具有一个标识符的“集合型”资源可以由若干个资源组成，每个资源都有自己的标识符，并且对该集合型资源采取的操作可以影响构成该集合型资源的所有资源）。此外，一个资源可以通过多个不同的标识符来标识。

议题： #136, #108
故事：全局唯一标识符
基于群组的访问控制 — 协议应允许控制者定义和管理实体群组，在群组级别应用访问控制规则，并动态传播成员资格变化，以便随着群组发展自动更新权限。该协议还应允许群组层级结构（也可理解为嵌套群组），例如，可将 Solid-admin 定义为 Solid-contributors 的子集，因此授予 Solid-contributors 的所有权限也适用于 Solid-admin。

议题： #38, #102
故事：群组共享
控制权委派 — 系统应允许实体将存储的控制权委派给另一个实体。此类委派可以是临时的——即具有到期日期和时间——也可以是永久的——即到期日期为“永不”或类似值。实体应能够在以后修改其委派，例如更改到期时间或完全撤销委派。

故事：控制权委派
订阅资源变更（通知） — 协议应提供一种机制，用于通知相关实体重大事件，例如资源变化或访问权限更新。例如，如果资源上的访问权发生变化或有新数据可用，则受影响各方可被及时提醒。通知递送可以是实时的（例如 push/SSE），也可以通过排队通道（例如电子邮件或收件箱），并尊重用户偏好和隐私。

议题： #32, #100, #101
故事： 权限变更通知、实时通知、应用通知
服务器到服务器认证 — 协议应支持安全的认证和授权流程，适用于服务器到服务器和后端服务集成，使受信任服务无需交互式登录即可访问用户存储。可能方式包括双向 TLS、基于签名 JWT 的服务凭据，以及有范围限制的长生命周期令牌等。

议题： #40, #92
故事：后端服务集成
序列化格式 — 协议应使存储中的数据能够以已知格式序列化。

故事：数据集成、个人信息管理
存储的控制 — 实体应能够跨一个或多个存储提供者控制一个或多个存储。一个存储应当恰好具有一个控制者；该控制者可以是抽象实体，例如群组，而不一定是个人或代理。

议题： #130
故事：存储所有权
自描述且可发现的 API — 协议应包括一些手段，使服务可以发现存储的可用能力，并统一导航其数据和访问控制接口。这样，服务就可以在用户管理的存储中存储、读取、更新和删除其数据，从而使用户保留数据所有权以及对应用生成内容的数据主权。这可以通过响应中的超媒体控件或标准描述符实现（例如，指示可用操作或端点的 JSON-LD 链接）。服务器应提供其支持的协议版本、扩展和功能的可发现描述。

议题： #12, #21, #70, #120
故事：存储描述与发现、自带数据应用
服务提供者的使用 — 协议应提供一种机制，使实体可以将某些功能委派给受信任的服务提供者。某些交互可能还需要服务提供者与实体之间的信任关系。这不应妨碍实体运行或自托管此类服务的能力。另请注意，信任关系并不是传递性的，即如果实体信任某个服务提供者，例如身份提供者，则该实体交互的其他任何服务提供者，例如存储提供者，都没有义务信任所述身份提供者。

议题： #127
故事：存储提供者的信任机制
存储可移植性 — 协议应允许实体将一个存储的全部内容从一个存储提供者移植，即复制、移动或转移到另一个存储提供者。移动或转移完成后，根据实体的选择，初始存储提供者可以解除与该存储相关的任何责任。

议题： #140
故事：可移植存储
访问权委派 — 除整项存储的控制权委派外，协议还应允许对某个资源具有特定访问权的实体，在原始所有者允许的情况下，将这些权利的子集委派给另一个实体。此类再委派可以是临时的或以其他方式限定范围，并且原始授予者（或资源所有者）应能够随时撤销或修改原始权利以及由此产生的附属委派权利。

议题： #10 [UC] 行政助理为部门负责人工作, #104 [UC] 自治群组/组织的访问委派
故事：行政助理、健康记录访问
搜索与查询 — 查询需求集合：

故事：搜索功能、分页与过滤、SPARQL 查询
1. pod 级查询 — 遵守 ACL 的 SPARQL 查询，用于在可能很大的 pod 中轻松查找内容
```
GET <my-pod-path>/__SPARQL?query=SELECT…
Host: <my-pod-server>
```
议题： #45 SPARQL 查询, #152 查询（/search）
故事：搜索功能、SPARQL 查询
1. 元数据查询 — 遵守 ACL、针对服务器维护数据的 SPARQL 查询
例如，在根 Container 上：
```
GET <my-pod-path>?query=SELECT…
Host: <my-pod-server>
```
例如，在 Resource（或嵌套 Container）上：
```
GET <my-pod-path>/<my-resource>?query=SELECT…
Host: <my-pod-server>
```
1. 资源级查询 — 查询他人的 pod，并遵守 ACL
```
GET <my-pod-path>/<my-resource>?query=SELECT…
Host: <my-pod-server>
```
1. 查询其他 pod — 查询他人的 pod，并遵守 ACL
```
GET <other-pod-path>/__SPARQL?query=SELECT…
Host: <my-pod-server>
```
1. 分页、过滤、排序 — 为处理大型结果集，协议应提供查询结果的分页、过滤和排序等功能，并可支持标准查询语言（例如 SPARQL），用于对数据进行高级语义查询。
这同样可以适用于协议级查询，例如对 LWP Container 执行 GET

议题： #103 分页、过滤和排序 故事：搜索功能、分页与过滤、SPARQL 查询
1. 联合查询 — SPARQL 查询连接外部数据，并遵守 ACL，用于在可能很大的 pod 中轻松查找内容
  1. 跨多个 pod 的连接 — 连接 pod 的 SPARQL 查询，并遵守 ACL
```
GET <my-resource>?query=SELECT…FROM <other-pod-path>…
Host: <my-pod-server>
```
  议题： #88 资源聚合
  故事：数据集成、SPARQL 查询
  1. 跨多个资源的连接 — 连接外部数据的 SPARQL 查询，并遵守 ACL
```
GET <my-resource>?query=SELECT…FROM <wikidata>…
Host: <my-pod-server>
```
```
GET <my-resource>?query=SELECT…SERVICE <wikidata>…
Host: <my-pod-server>
```
配置文件管理 — 协议应支持实体拥有多个不同配置文件（例如 “工作”与“个人”），每个配置文件都有自己的标识符、元数据命名空间和访问控制规则，以便数据可以在不同身份面向下选择性共享。

故事：配置文件共享
访问请求处理 — 协议应使实体能够轻松请求访问其当前未获授权访问的资源，并允许资源所有者（或控制者）轻松审查并批准或拒绝此类请求。应有一种标准方式，使请求者能够表达访问意愿，并使所有者收到通知并作出回应。这将确保数据所有者可以根据请求轻松共享特定数据，而无需预先授予广泛访问权。

议题： #11, #28, #78, #79, #92
故事：健康记录访问
基于同意的数据共享 —
- 协议应提供一种方式来记录并遵守用户对数据共享的同意，包括共享对象、共享内容、共享目的以及共享期限等详细信息。
- 应存在可验证、可审计的用户同意记录（例如回执或令牌），该记录可撤销，以确保在撤回同意后移除访问权。
议题： #141, #81
故事： 基于同意的共享
数据完整性验证 — 协议应纳入机制，以确保并验证已存储数据的完整性。经授权的实体应该能够检测数据是否已被篡改或损坏（无论是在静态存储还是传输过程中）。例如，系统可以使用加密哈希、签名和/或校验和，使客户端能够确认从存储中检索到的资源与所有者最初存储时完全一致。

议题：
故事：法律报告
上下文访问控制 — 访问控制机制应支持上下文感知策略。实体应该能够基于时间窗口、位置和群组成员状态等上下文，对资源访问施加额外条件。例如，策略可以仅允许在特定时段访问，或仅当请求方在当时处于特定角色或群组中时允许访问。

议题： #17, #65, #179
故事： 上下文感知访问策略
受信任的身份提供者 — 协议应使存储提供者能够与其所选择的身份提供者建立信任关系，而不是盲目接受任何身份来源（不过，此类盲目接受应该也可作为可配置选项）。信任是非传递性的：存储不会继承信任关系；它只接受来自其被配置为信任的 IdP 的凭据（这可能是或包括通配符，例如用于面向一般访问的网站内容）。

议题： #129
故事：存储提供者的信任机制
控制权转移 — 协议应允许实体转移，即不可撤销地重新分配，某个存储的控制权给另一个实体。

故事：控制权委派
可恢复的大型数据传输 — 协议应支持高效处理大文件和数据流，包括恢复中断的上传/下载的能力。这可确保网络或服务器中断不会迫使重新开始整个传输，从而提升大文件操作的可靠性。请注意，为查询生成的数据集支持恢复可能需要大量本地存储，这可能意味着并非所有部署都支持恢复。

议题： #18
故事：大文件上传
可扩展存储管理 — 协议应允许对实体的数据进行灵活管理，使其能够跨多个存储单元或提供者管理数据，并允许对不同后端进行逻辑统一。即使数据被拆分或迁移到不同提供者，客户端也应能够体验到单一连贯的存储视图，从而支持司法辖区分区或提供者故障转移等场景。

议题： #110, #136
故事：存储灵活性
基于视图的数据共享 — 协议应使控制者能够定义并暴露资源的派生“视图”（例如过滤、聚合或经删减的子集），以便接收者只看到已授权的切片，而无需复制底层数据。

议题： #63, #106, #116
故事：传感器数据共享
底层协议的松耦合 — 核心数据访问和身份交互应以抽象方式定义，并与任何单一传输或编码解耦。虽然预期使用 HTTP(S)，但协议语义必须能够映射到替代或未来传输（例如 gRPC、基于 WebSocket 的 GraphQL、本地 IPC），而不改变其基本模型。

议题： #24
故事：API 协议解耦
端到端加密 — 协议应支持数据的端到端加密，使存储或传输的数据除授权方外对任何人都不可读。即使是存储提供者或网络中介也无法解密内容（只有数据所有者和预期接收者可以）。端到端加密应可用于静态数据和传输中的数据，并使用标准算法。

议题： #4, #44
故事：端到端加密
性能与可扩展性 — 协议及其实现应被设计为在规模化场景下保持高性能。访问控制检查和数据操作应产生最小开销，并且该设计应允许批处理、缓存和分布式/集群式部署，以满足典型 Web 性能需求。

议题： #72
故事：高性能访问控制
联合数据查询 — 协议应支持客户端跨多个存储执行查询（包括联合 SPARQL），透明地聚合并返回结果，同时维护每个存储的访问控制。

议题： #88
故事：数据集成、SPARQL 查询
资源版本控制 — 协议应支持维护和检索资源的先前版本。经授权的实体应能够恢复或检查数据的早期版本（包括元数据和访问控制状态），以支持修改审计和变更回退，包括从意外删除中恢复。这有助于确保数据随时间保持持久性和可追踪性。

故事：通用存储
收件箱（通知） — 协议应提供一种机制，使用户（或其代理/应用）能够以标准化方式通过其存储直接交换消息或数据，从而启用内置协作，而不依赖外部消息服务。例如，用户应能够向另一个用户的存储发送消息、通知或邀请（在具备适当授权的情况下），接收用户的客户端可以检索该消息，或被提醒该消息。

议题： #22, #99
故事：通用通信
个人数据投影 — 协议应提供一种机制，支持将个人数据自动转换（投影）为非 LWS 应用可使用的格式（例如 JSON、vCard），而不复制底层资源，以防止数据孤岛，并提供与现有 Web 标准的兼容性和互操作性。（这也可适用于从一种 LWS 数据架构或结构转换为另一种，以实现跨 LWS 应用的互操作。）

议题： #2
故事：个人信息管理
可审计轨迹 — 协议应使经授权实体能够访问有关所有访问请求和资源授权，以及所有资源读取/写入/删除的可审计日志。该日志应包括在资源（例如数字商品）被创建、修改、交付或访问时的可验证回执或确认，以确保发布者能够确认成功交付或消费。

议题： #84, #85 故事：行政助理、法律报告、健康记录访问、数字商品交付
离线访问与同步 — 协议应允许实体即使在与网络断开连接时也能访问和修改数据，并在连接恢复后将本地更改同步到在线存储。这包括提供强有力的保证防止数据损坏，以及稳健的冲突解决，以确保离线编辑后的数据一致性。

故事：离线数据访问、存储监听
自描述网站发布 — 协议应支持直接从存储发布具有持久 URI 的自描述网站，从而实现持久、可互操作的内容托管。

议题： #31
故事：网站创建
协同编辑 — 协议应定义可选机制（例如锁定、乐观并发、基于 CRDT 的合并），以允许多个实体同时共同创作或编辑同一资源，并内置冲突检测与解决。

议题： #146
故事：语义协作
时间序列数据支持 — 协议应包括用于存储、查询和聚合时间序列资源的原语，支持可配置的分辨率限制以及针对 IoT 流或指标等数据的多维分析。

议题： #6
故事：时间序列存储
法律依据执行 — 协议应支持将访问控制决策与法律依据或策略关联。例如，实现者应能够使用特定法律根据（例如“同意 – GDPR 第 6(1)(a) 条”或“合同 – GDPR 第 6(1)(b) 条”）标记数据访问规则，并将这些内容作为元数据与审计轨迹一起记录。

议题： #80, #77
故事：法律依据支持
配置文件交互 UI — 协议应定义一种标准方法，使客户端能够获取并显示实体的配置文件（例如 WebID），以及所支持的操作（关注、消息、共享），以便用户可以与联系人无缝互动。

议题： #47, #48
故事：WebID 配置文件交互

链接式 Web 存储用例

摘要

本文档状态

1. 引言

2. 术语表

3. 用例

3.1 功能性故事

3.1.1 数据管理

3.1.3 协作与通信

3.1.4 应用集成

3.1.5 高级功能

3.2 非功能性故事

3.2.1 安全与隐私

3.2.2 性能与可用性

3.3 技术故事

3.3.1 身份认证与信任

3.3.2 API 与协议灵活性

3.3.3 存储与资源管理

4. 需求

链接式 Web 存储用例

摘要

本文档状态

1. 引言

2. 术语表

3. 用例

3.1 功能性故事

3.1.1 数据管理

3.1.2 访问控制与共享

3.1.3 协作与 通信

3.1.4 应用集成

3.1.5 高级功能

3.2 非功能性故事

3.2.1 安全与隐私

3.2.2 性能与可用性

3.3 技术故事

3.3.1 身份 认证与信任

3.3.2 API 与协议 灵活性

3.3.3 存储与资源 管理

4. 需求

3.1.3 协作与通信

3.3.1 身份认证与信任

3.3.2 API 与协议灵活性

3.3.3 存储与资源管理