要約

このノートは、リンクト・データ・プラットフォームWGのためのアクセス・コントロールのユースケースと要件について論じています。また、HTTPベースのアクセス・コントロールの標準の開発に関する憲章についても概説しています。憲章に記述されている取り組みは、リンクト・データ・プラットフォームWGや独立した関連WGで続行可能です。

このドキュメントのステータス

この項は、このドキュメントの公開時のステータスについて記述しています。他のドキュメントがこのドキュメントに取って代わることがありえます。現行のW3Cの刊行物およびこの技術報告の最新の改訂版のリストは、http://www.w3.org/TR/のW3C技術報告インデックスにあります。

リンクト・データ・プラットフォームWGは、アクセス・コントロールについて直接検討を行ってはいませんが、多くのユースケースと要件がその議論に含まれていることが確認されました。将来の作業のための基礎として役立つように、これらのユースケースと要件をこのドキュメントに記録しています。

このドキュメントは、リンクト・データ・プラットフォームWGがワーキンググループ・ノートとして発表しました。このドキュメントに関してコメントを行いたい場合には、public-ldp-comments@w3.org（購読、アーカイブ）にお送りください。どのようなコメントでも歓迎します。

ワーキンググループ・ノートとしての公開は、W3Cメンバーによる承認を意味するものではありません。これは草案ドキュメントであるため、他のドキュメントによって、随時更新されたり、置き換えられたり、廃止されることもありえます。このドキュメントを「作業中」以外のものとして引用することは適当ではありません。

このドキュメントは、2004年2月5日のW3C特許方針の下で活動しているグループによって作成されました。W3Cは、このグループの成果物に関連するあらゆる特許の開示の公開リストを維持し、このページには特許の開示に関する指示も含まれています。不可欠な請求権（Essential Claim(s)）を含んでいると思われる特許に関して実際に知っている人は、W3C特許方針の6項に従って情報を開示しなければなりません。

このドキュメントは、2014年8月1日のW3Cプロセス・ドキュメントによって管理されています。

目次

1. アクセス・コントロール

アクセス・コントロールは、資源とエージェントに対する方針に従って、あるエージェント（このケースでは、HTTPサーバー）が、他のエージェント -- それを構成する個人、組織および／またはグループ -- による資源への一定のオペレーションの実行を認めるメカニズムです。このドキュメントでは、資源はLDP資源ですが、アクセス・コントロールは、RDFやその他のドキュメント、名前付きグラフ、個々のトリプルといった様々な粒度で運用可能です。一般的に、オペレーションは、作成（create）、閲覧（read）、更新（update）、削除（delete）（CRUD）ですが、この型を用いて、その他のオペレーションを容易に適応させることができます。

エージェントが資源のコレクション（集合）に対してリクエストを行った場合には、承認された資源や資源の部分のみを閲覧できます。

アクセス・コントロールのメカニズムは、粒度によっては、パフォーマンスに影響を与えてもかまいませんが、セマンティクスには影響を与えるべきではありません。

アクセス・コントロールが機能するために、サーバーは、一部のオペレーションを一部の資源に制限しなければなりません。

2. 用語

3. ユースケース

3.1 HTTPによる資源の操作に対するアクセス・コントロール

アダム（Adsam）のユーザ・エージェントは次の試みを行います。
  1. URLで識別される資源を作成（CREATE）、閲覧（READ）、更新（UPDATEまたはPATCH）、削除（DELETE）しようとします。サーバーは、直ちにリクエストを認めるか拒否することができます。または、資源に対するACGの規定に従って、権限確認のために認証を行うように彼にリクエストでます。
  2. アクセスが拒否されたときには、エラーを検出してリクエストを修正できるように -- 潜在的には、そのような権限に対してリクエストを行えるように -- リクエストのすべてまたは一部が拒否された理由が説明されるべきです。
  3. 理想的には、アダムは、そのような試みを行う前に、資源にアクションを実行できるかどうか - つまり、資源の読み書きを行えるようになる前に、認証を行う必要があるか - を知りたいでしょう。

3.2 HTTPによるアクセス・コントロール規則の編集可能性

  1. バート（Bart）のユーザ・エージェントがサーバーにログオンし、会議で提示されるすべての資料などの関連する資源群を閲覧する権限をリクエストします。
  2. VPやSVPの肩書を持つ従業員は、供給契約に署名（更新）できます。
  3. ウェブマスターであるチャーリー（Charlie）は、理想的には、会議のすべての出席者に、会議で提示される資料への閲覧アクセス権を与えたいと考えます。

3.3 ユーザ・インターフェース・シナリオ

エディ（Eddie）のHTTPベースのユーザ・エージェントは、可能であれば、エディが次のことをできるようにするためのユーザ・インターフェースを提供したいでしょう。
  1. 彼が資源を編集または削除可能かを知る。
  2. 資源にアクセスできるようになるために彼が何をする（誰かの友人である、クラブの一員である、料金を支払う）必要があるかを知る。
  3. 次のような資源に対するアクセス・コントロール規則の編集をエディに認める。
    1. 彼の友人に、ドキュメントへのアクセスを認める。
    2. 彼の友人に、コンテナへのPOSTを認める（ただし、そのエージェントがポストしたものなど、コンテナのコンテンツのサブセットのみを閲覧可能）。
    3. LDP WGのすべてのメンバーが、特定のURLパターンを持つLDPコンテナなどの資源を作成、編集することを認める。
    4. foafプロフィールにおいてfoaf:knows関係で表されているすべての友人の友人が、あるコンテンツに関連付けられたコンテナにコメントをPOSTし、自身のコメントを編集することを認める。
    5. LDP WG、RWW CG、WebID CGのメンバー、ヨーロッパ・オントロジスト・ネットワークのメンバーが、オントロジーに対して共同作業を行うことを認める。グループのメンバーの和集合を作成する方法として、ウェブ上にあるこれらのグループのURLをユーザ・インターフェースにドラッグ＆ドロップできるべき。

3.4 要件

上記の要件には、承認されたエージェントによって、関連するACGを作成（CREATE）、編集（EDIT）、更新（UPDATE）する性能が必要です。

3.5 アクセス・コントロールWGの憲章の概要

アクセス・コントロール・グラフ（ACG）は、エージェントのコレクションと資源のコレクションの2種類のコレクションで構成されます。そして、エージェントが資源に対して有する権限（作成（CREATE）、閲覧（READ）、更新（UPDATE）、削除（DELETE））を識別する接続方法により、エージェントのコレクションを資源のコレクションに接続します。

ACGは、それ自体が資源であり、他の資源とまったく同じく、それらに対して定められているアクセス・コントロール権限を持つことができます。これにより、ACGの作成と修正を委任することができます。

エージェントのコレクションのメンバーには、エージェントが認証サービスから得たトークンが含まれます。資源のコレクションのメンバーは、URIまたはURIテンプレートです。

WGは、属性レベルのきめ細かいアクセス・コントロールを定義したいかどうかを決定する必要があります。

3.5.1 成果

  • ACGの一部であるコレクションを定義し、エージェントのコレクションを資源のコレクションに接続する方法を定義しました。
  • どのようにACGを作成、編集でき、どのようにその権限を委任できるかを定義しました。
  • エージェントによる資源へのアクセスのリクエストを、上記で定義しているACG構造でどのように効率的に処理できるかの概念実証の実装について説明しました。