Copyright © 2024-2026 World Wide Web Consortium. W3C® liability, trademark and permissive document license rules apply.
Linked Web Storage (LWS) 仕様のユーザーストーリーおよびユースケース。
この節では、この文書の公開時点における状態を説明する。現在の W3C 刊行物の一覧およびこの技術報告書の最新版は、 W3C 標準および草案 インデックスで確認できる。
この文書は、Linked Web Storage ワーキング グループによって、 ノートトラックを用いた グループノート草案として公開された。
グループノート草案は、 W3C またはそのメンバーによって承認されたものではない。
これは草案文書であり、いつでも他の文書によって更新、置換、または廃止される可能性がある。 この文書を作業中のもの以外として引用することは適切ではない。
W3C 特許 ポリシーは、 この文書に関するライセンス要件またはコミットメントを伴わない。
この文書は、 2025年8月18日 W3C プロセス文書に従う。
LWS 仕様は、現在の Web では通常、 データストレージ、エンティティ認証、アクセス制御、アプリケーションプロバイダーがすべて密結合であり、 そのうちの 1 つを変更するにはすべてを変更する必要があり、場合によっては過去のすべてのデータを犠牲にするのに対し、 それらすべてが疎結合である Web アプリケーションの開発を可能にすることを目指している。
この文書は、LWS 仕様のユーザーストーリーおよびユースケース、ならびにこれらのユースケースを満たすために必要であると特定された要件を列挙する。 この文書の一部のユースケースは、このワーキンググループにおいて優先度が下げられている、または明示的に範囲外である要件を導入する場合がある。 これらは、以下を行う取り組みを支援するため、この文書に保持されている。
用語集は、この仕様全体で使用される主要な用語および概念の定義を提供する。これは、読者と寄稿者の間で明確さと共通理解を確保するための クイックリファレンスとして機能する。用語を標準化することにより、用語集は、この仕様を解釈する際の一貫したコミュニケーションと整合を支援する。
LWS 仕様のユースケースを以下に記す。
汎用ストレージ
ユーザーとして、私はあらゆる種類のリソースをサポートする形式非依存のオンラインストレージシステムが欲しい。それにより、
メタデータおよびアクセス制御の変更、ならびに以前のバージョンの復旧を含む Create、Read、Update、Delete (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 Push
通知を受け取りたい。それにより、
重要なイベントを把握し続けられる。
コンテキスト: 通知は、ユーザーが自分のデータに関わり続けるのに役立つ。
課題: #100
ユニバーサルコミュニケーション
ユーザーとして、私は他のストレージ所有者との直接メッセージングチャネルが欲しい。それにより、
プラットフォーム内でシームレスに共同作業できる。
コンテキスト:
組み込みのコミュニケーションはユーザー同士のやり取りを強化する。
課題: #99,
#22
投票
ユーザーとして、私は自分のストレージ内で投票を作成および管理したい。それにより、
他者から意見やフィードバックを集められる。
コンテキスト: 投票は意思決定とコミュニティ参加を支援する。
課題: #144
セマンティック共同作業
ユーザーとして、私は永続的 URI
と柔軟な権限を用いて、構造化コンテンツを他者と共同執筆したい。それにより、
共同作業が効率的で追跡可能になる。
コンテキスト: これは共有ナレッジベースのような高度なユースケースを可能にする。
課題: #146, #98
個人情報管理
ユーザーとして、私は自分のストレージ内で個人データを管理し、何らかのデータ変換を通じて非 Solid
アプリと統合したい。それにより、
データサイロを作らずにさまざまなアプリを使用できる。
コンテキスト: これは相互運用性とユーザー制御を促進する。
課題: #2
「Bring Your Own Data」アプリ
アプリ開発者として、私は自分のアプリケーションがユーザーのストレージにデータを保存し、CRUD
操作とストア発見をサポートするようにしたい。それにより、
ユーザーが自分のデータの所有権と制御を保持できる。
コンテキスト:
これはデータ所有権をアプリからユーザーへ移す。
課題: #12, #120
デジタル商品の配送
ユーザーとして、私は確認受領書を伴うデジタル商品（例:
ソフトウェア、メディア）の安全な配送を望む。それにより、プロバイダーが最小限の介入でアセットを配送できる。
コンテキスト:
これは信頼できるデジタル製品配送を保証する。
課題: #14
データ 統合
アプリ開発者として、私は複数のソースからのデータを組み合わせる標準化された API
が欲しい。それにより、
多様なデータセットの統合が簡単かつ効率的になる。
コンテキスト: 簡素化された統合は開発の複雑さを軽減する。
課題: #26, #53, #88, #106
ビジネスデータアクセス
ビジネスユーザーとして、私はデータ共有に関する明確な強制ルールが欲しい。それにより、
企業統合が組織のポリシーに準拠する。
コンテキスト: これは安全な企業ユースケースを支援する。
課題: #27, #28
時系列ストレージ
ユーザーとして、私は解像度制限と多次元分析サポートを備えた時系列データを保存したい。それにより、
時間の経過に伴う傾向を効率的に分析できる。
コンテキスト: これは IoT や分析のようなアプリケーションにとって重要である。
課題:
#6
センサーデータ共有
ユーザーとして、私は重複なしに、さまざまな粒度でセンサーデータを共有したい。それにより、
利用者が必要な詳細だけを受け取れる。
コンテキスト: 効率的な共有はリソース使用量を削減する。
課題: #8
法的 報告
データ提供者として、私は監査コンプライアンスを支援するため、データ共有の検証可能な証明が欲しい。それにより、
アクセスが取り消された後でも法的義務を満たせる。
コンテキスト: これは透明性と説明責任を保証する。
課題: #9
検索機能
ユーザーとして、私はコンテキスト認識とセキュリティ強制を備えた強力な検索機能が欲しい。それにより、
関連するリソースをすばやく安全に見つけられる。
コンテキスト: 効果的な検索は大規模データセットに不可欠である。
課題: #152,
#87
ページネーションとフィルタリング
ユーザーとして、私は検索結果の効率的なページネーション、フィルタリング、並べ替えが欲しい。それにより、
大規模データセットを容易に移動できる。
コンテキスト: これらの機能はデータの使いやすさを高める。
課題: #103
SPARQL クエリ
パワーユーザーとして、私は複雑な検索とデータ分析を実行するために SPARQL
クエリのサポートが欲しい。それにより、
リンクトデータから洞察を抽出できる。
コンテキスト: SPARQL は高度なセマンティック Web
クエリを可能にする。
課題: #45
Web サイト作成
ユーザーとして、私は永続的 URI を備えた自己記述的な Web
サイトを公開したい。それにより、
自分のコンテンツが長期にわたってアクセス可能かつ相互運用可能な状態に保たれる。
コンテキスト: これは耐久性のある Web
公開を支援する。
課題: #31
家庭からの アクセス
ユーザーとして、私は動的 IP
を持つ家庭内デバイスから自分のストレージにアクセスしたい。それにより、
接続の問題によってデータの使用が妨げられない。
コンテキスト: これは家庭環境でのアクセス可能性を保証する。
課題: #105, #68
コンテキスト上の相互作用
ユーザーとして、私はコンテンツと並んで相互作用をコンテキストに応じて表示したい。それにより、
権限と履歴を直感的に理解できる。
コンテキスト: これはデータ相互作用に関するユーザーの理解を改善する。
課題: #55
WebID プロファイル相互作用
ユーザーとして、私はWebID
をクリックするとプロファイルと利用可能なアクションが表示されるようにしたい。それにより、
連絡先と容易に関われる。
コンテキスト: これは社会的および専門的なやり取りを強化する。
課題: #48, #47
ストレージ監視
アプリ開発者として、私はストレージ変更のオフライン監視が欲しい。それにより、
接続がない場合でもアプリケーションが同期された状態を維持できる。
コンテキスト: これは堅牢なオフラインアプリ機能を支援する。
課題:
#101
「End to End」暗号化
ユーザーとして、私はすべてのデータ保存と転送にエンドツーエンド暗号化が欲しい。それにより、
認可された当事者だけが私の情報を復号してアクセスできる。
コンテキスト: 暗号化はデータの機密性を保証する。
課題: #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
認証メカニズム
ユーザーとして、私はパスキー、サイレント認証、スクリプト向けオプションのような最新の認証方式のサポートが欲しい。それにより、
多様なシナリオで安全に認証できる。
コンテキスト: 柔軟な認証はさまざまなユーザーニーズを満たす。
課題: #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 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | |
|---|---|---|---|---|---|---|---|---|---|---|
| 汎用ストレージ | ✓ | ✓ | ✓ | |||||||
| ポータブルストレージ | ✓ | ✓ | ✓ | |||||||
| アクセス共有 | ✓ | ✓ | ✓ | ✓ | ||||||
| プロファイル共有 | ✓ | ✓ | ✓ | ✓ | ||||||
| グループ共有 | ✓ | ✓ | ✓ | ✓ | ||||||
| 管理アシスタント | ✓ | ✓ | ✓ | ✓ | ||||||
| オフラインデータアクセス | ✓ | ✓ | ✓ |
ストレージ内のリソースの追加、更新、削除 — このプロトコルは、認可されたエンティティが ストレージ内でリソースを追加、更新、および/または削除できるようにしなければならない。 一般に、このプロトコルは任意の種類のリソースをストレージに保存できるようにしなければならないが、 ストレージプロバイダーは種類やサイズなど、一定の制限を課してもよい。
データ共有 — このプロトコルは、エンティティが自身の制御するリソースへのアクセスを別のエンティティに付与できるようにしなければならない。 言い換えれば、最初のエンティティは、他方のエンティティに対して、そのリソースに対する何らかの操作 （読み取り、変更、削除など）を実行することを許可してもよい。アクセス付与は一時的、すなわち有効期限を持つものでも、 そうでなくてもよい。最初のエンティティは、後の時点で有効期限を変更したり、委任を完全に取り消したりすることにより、 そのような委任を変更できなければならない。
認証メカニズム — このプロトコルは、中央集権型、 フェデレーション型、および/または自己主権型の認証メカニズムをサポートしなければならない。
課題: #25, #90, #115, #128, #39, #49
ストーリー: アイデンティティ
と資格情報の管理、認証メカニズム
グローバルに一意な識別子 — エンティティおよびストレージを含むリソースは、 グローバルに一意に識別可能でなければならない。2 つの異なるリソースが同じ識別子を共有してはならない （ただし、1 つの識別子を持つ「集合」リソースが複数のリソースから構成され、それぞれが自身の識別子を持ち、 集合リソースに対して行われるアクションが、その集合リソースを構成するすべてのリソースに影響してもよい）。 さらに、1 つのリソースは複数の異なる識別子によって識別可能であってもよい。
グループベースのアクセス制御 — このプロトコルは、コントローラーが エンティティのグループを定義および管理し、グループレベルでアクセス制御ルールを適用し、 メンバーシップの変更を動的に伝播して、グループの変化に応じて権限が自動的に更新されるようにしなければならない。 このプロトコルは、グループ階層（入れ子グループと考えてもよい）も可能にすべきである。たとえば、 Solid-admin を Solid-contributors のサブセットとして定義でき、Solid-contributors に与えられたすべての権限が Solid-admin にも適用される。
制御の委任 — このシステムは、エンティティがストレージの制御を 別のエンティティに委任できるようにしなければならない。そのような委任は一時的、すなわち有効期限日時を持つものでも、 恒久的、すなわち有効期限が「なし」またはそれに類するものでもよい。エンティティは、後の時点で有効期限を変更したり、 委任を完全に取り消したりするなどして、自身の委任を変更できなければならない。
ストーリー: 制御の委任
リソース変更の購読（通知） — このプロトコルは、リソースの変更や アクセス権限の更新などの重要なイベントを、関連するエンティティに通知するメカニズムを提供しなければならない。 たとえば、リソースに対するアクセス権が変更された場合、または新しいデータが利用可能になった場合、影響を受ける当事者は 適時に警告を受けることができる。通知配信はリアルタイム（例: push/SSE）であっても、キュー化されたチャネル （例: メールまたは inbox）経由であってもよく、ユーザーの設定とプライバシーを尊重する。
サーバー間認証 — このプロトコルは、サーバー間およびバックエンドサービス統合に適した 安全な認証および認可フローをサポートし、信頼されたサービスが対話的ログインなしでユーザーのストレージにアクセスできるようにしなければならない。 可能性としては、相互 TLS、署名付き JWT ベースのサービス資格情報、スコープ付きの長期トークンなどが含まれる。
シリアル化形式 — このプロトコルは、ストレージ内のデータを 既知の形式でシリアル化できるようにしなければならない。
ストーリー: データ統合、個人情報管理
ストレージの 制御 — エンティティは、1 つまたは複数のストレージプロバイダーにまたがって 1 つ以上の ストレージを制御できなければならない。ストレージはちょうど 1 つのコントローラーを持たなければならない。 このコントローラーは、必ずしも個人またはエージェントである必要はなく、グループのような抽象エンティティであってもよい。
課題: #130
ストーリー: ストレージ
所有権
自己記述的で発見可能な API — このプロトコルは、 サービスがストレージで利用可能な機能を発見し、そのデータおよびアクセス制御インターフェイスを一貫して移動できる手段を含まなければならない。 これにより、サービスはユーザー管理のストレージ内でデータを保存、読み取り、更新、削除でき、ユーザーはデータの所有権と アプリ生成コンテンツに対する主権を保持できる。これは、応答内のハイパーメディア制御または標準記述子 （例: 利用可能なアクションまたはエンドポイントを示す JSON-LD リンク）によって実現される可能性がある。 サーバーは、サポートするプロトコルバージョン、拡張、および機能について、発見可能な記述を提供すべきである。
課題: #12, #21, #70, #120
ストーリー: ストレージ
の記述と発見、Bring-Your-Own-Data アプリ
サービス プロバイダーの使用 — このプロトコルは、エンティティが一部の機能を信頼されたサービスプロバイダーに 委任できるメカニズムを提供しなければならない。一部の相互作用では、サービスプロバイダーとエンティティの間の信頼関係が さらに必要になる場合がある。これは、エンティティがそのようなサービスを運用またはセルフホストする能力を妨げるべきではない。 また、信頼関係は推移的ではない。すなわち、エンティティがあるサービスプロバイダー、たとえばアイデンティティプロバイダーを 信頼している場合でも、そのエンティティがやり取りする他のサービスプロバイダー、たとえばストレージプロバイダーは、 そのアイデンティティプロバイダーを信頼する義務を負わない。
課題: #127
ストーリー: ストレージ
プロバイダーのための信頼メカニズム
ストレージ ポータビリティ — このプロトコルは、エンティティがストレージの内容全体をあるストレージプロバイダーから 別のストレージプロバイダーへ移植、すなわちコピー、移動、または転送できるようにしなければならない。 移動または転送が完了した後、エンティティの選択により、元のストレージプロバイダーはそのストレージに関する一切の責任から 解放されてもよい。
課題: #140
ストーリー: ポータブルストレージ
アクセス権の委任 — ストレージ全体の制御委任に加えて、 このプロトコルは、リソースに対して一定のアクセス権を持つエンティティが、元の所有者によって許可されている場合、 その権利のサブセットを別のエンティティに委任できるようにしなければならない。そのような再委任は一時的または別の形で スコープ付きであってもよく、元の付与者（またはリソース所有者）は、いつでも元の委任およびそれに付随する委任された権利を 取り消しまたは変更できなければならない。
課題: #10 [UC] 部門長のために働く
管理アシスタント, #104 [UC] 自律的な
グループ/組織によるアクセス委任
ストーリー: 管理アシスタント、健康記録へのアクセス
検索と クエリ — クエリ要件の集合:
ストーリー: 検索機能、ページネーションとフィルタリング、SPARQL クエリ
GET <my-pod-path>/__SPARQL?query=SELECT…
Host: <my-pod-server>
課題: #45 SPARQL クエリ,
#152 クエリ (/search)
ストーリー: 検索機能、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>
GET <my-pod-path>/<my-resource>?query=SELECT…
Host: <my-pod-server>
GET <other-pod-path>/__SPARQL?query=SELECT…
Host: <my-pod-server>
これは、たとえば LWP Container に対する GET など、プロトコルレベルのクエリにも同様に適用できる
課題: #103 ページネーション、 フィルタリング、並べ替え ストーリー: 検索機能、ページネーションとフィルタリング、SPARQL クエリ
フェデレーション型クエリ — ACL を尊重しながら、 外部データを結合し、潜在的に大規模な pod 内のものを容易に見つけるための SPARQL クエリ
GET <my-resource>?query=SELECT…FROM <other-pod-path>…
Host: <my-pod-server>
課題: #88 リソース
集約
ストーリー: データ統合、SPARQL クエリ
GET <my-resource>?query=SELECT…FROM <wikidata>…
Host: <my-pod-server>
GET <my-resource>?query=SELECT…SERVICE <wikidata>…
Host: <my-pod-server>
プロファイル 管理 — このプロトコルは、エンティティが複数の異なるプロファイル（例: 「仕事」と「私用」）を持つことをサポートしなければならない。それぞれは独自の識別子、メタデータ名前空間、 アクセス制御ルールを持ち、異なるペルソナのもとでデータを選択的に共有できるようにする。
ストーリー: プロファイル共有
アクセス 要求の処理 — このプロトコルは、エンティティが現在認可されていないリソースへのアクセスを容易に要求でき、 リソース所有者（またはコントローラー）がそのような要求を容易に確認し、許可または拒否できるようにしなければならない。 要求者がアクセス希望を示し、所有者が通知を受け取って応答するための標準的な方法がなければならない。 これにより、データ所有者は広範なアクセスを事前に付与することなく、要求に応じて特定のデータを容易に共有できるようになる。
同意に基づくデータ共有 —
データ完全性の検証 — このプロトコルは、保存データの完全性を保証し検証する メカニズムを組み込まなければならない。認可されたエンティティは、データが改ざんまたは破損しているかどうか （保存時または転送時のいずれであっても）を検出できるべきである。たとえば、このシステムは、クライアントがストレージから取得した リソースが所有者によって最初に保存されたものと正確に同じであることを確認できるよう、暗号ハッシュ、署名、 および/またはチェックサムを使用してもよい。
課題:
ストーリー: 法的報告
コンテキスト対応アクセス制御 — アクセス制御メカニズムは、コンテキスト対応ポリシーを サポートしなければならない。エンティティは、時間枠、位置、グループメンバーシップ状態などのコンテキストに基づき、 リソースアクセスに追加条件を課すことができるべきである。たとえば、ポリシーは特定の時間帯のみアクセスを許可したり、 要求当事者がその時点で特定のロールまたはグループ内にいる場合のみアクセスを許可したりできる。
信頼されたアイデンティティプロバイダー — このプロトコルは、ストレージプロバイダーが 任意のアイデンティティソースを盲目的に受け入れるのではなく、自ら選択したアイデンティティプロバイダーとの信頼関係を 確立できるようにしなければならない（ただし、そのような盲目的な受け入れも設定可能な選択肢であるべきである）。 信頼は推移的ではない。ストレージは信頼関係を継承せず、信頼するよう設定された IdP からの資格情報のみを受け入れる （これにはワイルドカードが含まれてもよい。たとえば、一般消費向けの Web サイトコンテンツの場合など）。
課題: #129
ストーリー: ストレージプロバイダーのための信頼メカニズム
制御の 移転 — このプロトコルは、エンティティがストレージの制御を別のエンティティに移転、 すなわち取り消し不能に再割り当てできるようにしなければならない。
ストーリー: 制御の委任
再開可能な大容量データ転送 — このプロトコルは、大容量ファイルおよびデータストリームの 効率的な処理をサポートしなければならない。これには、中断されたアップロード/ダウンロードを再開する能力が含まれる。 これにより、ネットワークまたはサーバーの中断によって転送全体を最初からやり直す必要がなくなり、大容量ファイル操作の信頼性が向上する。 クエリ生成データセットの再開をサポートするには大きなローカルストレージが必要となる可能性があり、そのためすべてのデプロイメントで 再開がサポートされるとは限らないことに注意。
課題: #18
ストーリー: 大容量ファイルのアップロード
スケーラブルなストレージ管理 — このプロトコルは、複数のストレージ単位または プロバイダーにまたがるエンティティのデータを柔軟に管理できるようにし、異種のバックエンドを論理的に統合できるようにしなければならない。 クライアントは、データがプロバイダー間で分割または移行されている場合でも、単一の一貫したストレージビューを体験できるべきであり、 管轄区域ごとの分割やプロバイダーフェイルオーバーのようなシナリオをサポートする。
ビューに基づくデータ共有 — このプロトコルは、コントローラーがリソースの派生「ビュー」 （例: フィルタ済み、集約済み、または編集済みのサブセット）を定義して公開できるようにし、 受信者が基礎となるデータを複製することなく、認可された部分だけを見られるようにしなければならない。
基盤プロトコルの疎結合 — 中核となるデータアクセスおよび アイデンティティ相互作用は、単一のトランスポートまたはエンコーディングから切り離され、抽象的に定義されなければならない。 HTTP(S) が想定されるが、このプロトコルのセマンティクスは、その基本モデルを変更することなく、代替または将来の トランスポート（例: gRPC、WebSocket 上の GraphQL、ローカル IPC）にマッピング可能でなければならない。
課題: #24
ストーリー: API プロトコルの分離
エンドツーエンド暗号化 — このプロトコルは、保存または転送されるデータが、 認可された当事者以外には読み取れないようにするエンドツーエンド暗号化を可能にしなければならない。 ストレージプロバイダーやネットワーク仲介者であっても、その内容を復号できない（データ所有者と意図された受信者のみが可能）。 エンドツーエンド暗号化は、標準アルゴリズムを用いて、保存時および転送時のデータに対して達成可能であるべきである。
性能とスケーラビリティ — このプロトコルおよびその実装は、 大規模環境で高い性能を発揮するよう設計されなければならない。アクセス制御チェックとデータ操作は最小限のオーバーヘッドで行われるべきであり、 設計は、典型的な Web 性能ニーズを満たすために、バッチ処理、キャッシュ、分散/クラスターデプロイメントを可能にすべきである。
課題: #72
ストーリー: 高性能なアクセス制御
フェデレーション型データクエリ — このプロトコルは、クライアントが 複数のストレージにまたがるクエリ（フェデレーション SPARQL を含む）を実行し、各ストレージのアクセス制御を維持しながら、 結果を透過的に集約して返すことをサポートしなければならない。
課題: #88
ストーリー: データ統合、SPARQL クエリ
リソース バージョニング — このプロトコルは、リソースの以前のバージョンを維持および取得することを サポートしなければならない。認可されたエンティティは、変更監査と変更の巻き戻しを可能にするため、 データ（メタデータおよびアクセス制御状態を含む）の以前のバージョンを復旧または検査できるべきであり、 これには誤削除からの復旧も含まれる。これは、長期にわたるデータの耐久性と追跡可能性を保証するのに役立つ。
ストーリー: 汎用ストレージ
Inbox （通知） — このプロトコルは、ユーザー（またはそのエージェント/アプリケーション）が自身のストレージを通じて 標準化された方法で直接メッセージまたはデータを交換するためのメカニズムを提供しなければならない。 これにより、外部メッセージングサービスに依存せずに組み込みの共同作業が可能になる。たとえば、ユーザーは別のユーザーの ストレージにメッセージ、通知、または招待を送信できるべきであり（適切な認可を伴う）、 受信側ユーザーのクライアントはこのメッセージを取得するか、または通知を受けることができる。
個人データ射影 — このプロトコルは、基礎となるリソースを複製することなく、 非 LWS アプリケーションが利用可能な形式（例: JSON、vCard）で 個人データの自動変換（射影）を支援するメカニズムを提供しなければならない。これはデータサイロを防ぎ、 既存の Web 標準との互換性および相互運用性を提供するためである。（これは、LWS アプリケーション間の相互運用性のために、ある LWS データスキーマまたは構造から別のものへ変換することにも適用される場合がある。）
課題: #2
ストーリー: 個人情報管理
監査可能な 証跡 — このプロトコルは、認可されたエンティティが、リソースへのすべてのアクセス要求と付与、 およびリソースのすべての読み取り/書き込み/削除に関する監査可能なログにアクセスできるようにしなければならない。 このログは、リソース（デジタル商品など）が作成、変更、配送、またはアクセスされた際の検証可能な受領書または確認応答を含み、 公開者が正常な配送または消費を確認できるようにしなければならない。
オフラインアクセスと同期 — このプロトコルは、ネットワークから切断されている場合でも エンティティがデータにアクセスして変更できるようにし、接続が回復したらローカル変更をオンラインストレージに同期できるようにしなければならない。 これには、データ破損に対する強い保証と、オフライン編集後のデータ一貫性を保証する堅牢な競合解決の提供が含まれる。
ストーリー: オフラインデータアクセス、ストレージ監視
自己記述的な Web サイト公開 — このプロトコルは、 ストレージから直接、永続的 URI を持つ自己記述的な Web サイトを公開することをサポートし、 耐久性があり相互運用可能なコンテンツホスティングを可能にしなければならない。
課題: #31
ストーリー: Web サイト作成
共同編集 — このプロトコルは、複数のエンティティが同じリソースを同時に 共同執筆または編集できるよう、組み込みの競合検出および解決を伴う任意のメカニズム （例: ロック、楽観的同時実行制御、CRDT ベースのマージ）を定義しなければならない。
課題: #146
ストーリー: セマンティック共同作業
時系列データサポート — このプロトコルは、時系列リソースの保存、クエリ、 集約のためのプリミティブを含まなければならず、IoT ストリームやメトリクスのようなデータについて、 設定可能な解像度制限と多次元分析をサポートする。
課題: #6
ストーリー: 時系列ストレージ
法的 根拠の強制 — このプロトコルは、アクセス制御の判断を法的根拠またはポリシーに関連付けることを サポートしなければならない。たとえば、実装者は、データアクセスルールに特定の法的根拠 （たとえば「同意 – GDPR 第 6 条 1 項 (a)」または「契約 – GDPR 第 6 条 1 項 (b)」）をタグ付けし、 監査証跡とともにメタデータとして記録できるべきである。
プロファイル 相互作用 UI — このプロトコルは、クライアントがエンティティのプロファイル（例: WebID）を取得して表示し、 サポートされるアクション（フォロー、メッセージ、共有）とともに提示するための標準的な方法を定義し、 ユーザーが連絡先とシームレスに関われるようにしなければならない。