このドキュメントは

The Platform for Privacy Preferences 1.0 (P3P1.0) Specification
W3C Working Draft 11 February 2000
http://www.w3.org/TR/2000/WD-P3P-20000211

の和訳です。

このドキュメントには和訳上の誤りがありえます。
内容の保証はいたしかねますので、必ずW3C Webサイトの正式版ドキュメントを参照して下さい。
また、著作権については本ドキュメントに含まれる記述に加え、こちらも必ず参照してください。

Copyright (C)  1999 W3C (MIT, INRIA, Keio), All Rights Reserved. W3C 責任、登録商標、, 文書の使用、 そして ソフトウエアライセンスに関する規則が適用される。




W3C

The Platform for Privacy Preferences 1.0 (P3P1.0) Specification

W3C Working Draft 11 February 2000

This Version:
http://www.w3.org/TR/2000/WD-P3P-20000211
Latest Version:
http://www.w3.org/TR/P3P
Previous Version:
http://www.w3.org/TR/1999/WD-P3P-19991102
Editor:
Massimo Marchiori, W3C/MIT, (massimo@w3.org)
Authors:
Lorrie Cranor, AT&T
Marc Langheinrich, ETH Zurich
Massimo Marchiori, W3C/MIT
Martin Presler-Marshall, IBM
Joseph Reagle, W3C/MIT


要旨

本仕様書は、「プライバシー情報取り扱いに対する個人の選好を支持する技術基盤(Platform for Privacy Preferences、P3P)」 の仕様書である。標準書作成手順に従い、本文書は、相互互換性のあるP3Pアプリケーションのインプリメントに必要な総ての仕様を規定している。

本文書の位置付け   

この節では、文書の発行時における当該文書の位置付けについて記述する。しかし、この記述内容は、他の文書で置き換えられる可能性がある。本文書シリーズの最新の位置付けは、W3Cが決めている。

本文書は、W3Cのメンバーやその他の関係者にレビューしてもらう為のW3Cワーキングドラフトである。本文書は、P3Pアクティビティの一つであるP3P仕様書ワーキンググループに依って作成されたものであり、また、 1999年11月2日に発行されたラストコール ドラフト(http://www.w3.org/TR/1999/ WD-P3P-19991102)を改定したものである。改定内容を分かりやすくする為、その 改定履歴 を本文書の最後に示す。本文書のラストコールの期限は、2000年4月30日である。本文書の改定版は、少なくとも2つの相互互換性のあるインプリメンテーションのデモンストレーションが実施されたならW3C勧告になる予定である。

本ワーキングドラフトは、P3Pボキャブラリを拡張するために必要な拡張メカニズムを有している。 P3P仕様書ワーキンググループは、このメカニズムを如何に改良できるか、また、このメカニズムを用いた拡張例等のフィードバックを得ることを特に期待している。これらの事例を知ることは、拡張メカニズムのデザインの改善に有益であり、更に、P3P仕様書ワーキンググループが、それに関する諸々のアイデアを標準として P3Pボキャブラリに取りこむことができれば、その後、利用者が、同じ拡張作業をする必要がなくなる。本文書の序論では、本ワーキングドラフトとP3Pの将来の文書との位置付けについて、更に記述する。

本文書は、ラストコール期間中においては、あくまでも、ドラフト文書である。従って、任意の時点で他の文書によって、改定されたり、置き換えられたり、もしくは、陳腐化したりする可能性がある。それゆえ、本文書のようなW3Cワーキングドラフトを標準として用いたり、不変のものとして引用することは、望ましいことではない。W3Cワーキングドラフトの一覧については、http://www.w3.org/TR/.を参照されたい。

もし、本文書の内容について、コメントがあるならば、www-p3p-public-comments@w3.orgにコメントを送付されたい。なお、これまでのコメントについては、次のページを参照されたい。http://lists.w3.org/Archives/Public/ www-p3p-public-comments/


目次

  1. 序論
    1. P3P1.0仕様書
      1. P3P1.0の最終目的と可能性
      2. P3P利用例
      3. P3Pポリシー
      4. P3Pユーザエージェント
      5. サーバ上でのP3Pの実装
      6. P3Pの将来バージョン
    2. 本仕様書について
    3. 用語
  2. ポリシー参照
    1. ポリシー参照の目的
    2. 参照シンタックス
      1. HTTP拡張フレームワークを用いたシンタックス
      2. METAタグを用いたシンタックス
    3. ポリシー参照の使用
      1. 一義性
      2. 多言語
      3. 直接参照と間接参照
      4. 間接参照の取り扱い
      5. ポリシーの不変性
    4. プライバシーポリシーと参照に関するキャッシュの可能性
      1. キャッシュされるオブジェクト
        1. プライバシーポリシー文書に関するキャッシュの可能性
        2. ポリシー参照に関するキャッシュの可能性
      2. キャッシュの有効期限の表記
        1. プライバシーポリシー文書の有効期限表記
        2. 直接ポリシー参照の有効期限表記
        3. 間接ポリシー参照のキャッシュ有効期限表記
      3. キャッシュ有効期限の規定値
    5. 追加要求事項
      1. セーフゾーン
      2. プライバシーポリシーの非差別化
      3. プライバシーポリシーの送信に関するセキュリティ
  3. プライバシーポリシーのシンタックスとセマンティクス
    1. プライバシーポリシー例
      1. 自然言語プライバシーポリシー
      2. プライバシーポリシーのXMLコード化
    2. P3Pポリシー
      1. POLICY要素
      2. DISCLOSURE要素
      3. DISPUTES要素
    3. ステートメント
      1. STATEMENT要素
      2. CONSEQUENCE要素
      3. PURPOSE要素
      4. RECIPIENT要素
      5. RETENTION要素
      6. DATA要素
    4. カテゴリ
      1. 固定カテゴリデータ要素
      2. 可変カテゴリデータ要素 
    5. 拡張メカニズム
  4. データスキーマ
    1. データスキーマの不変性
    2. プリミティブデータ型
    3. 基本データスキーマ
      1. 個人データ
      2. 動的データ
    4. 基本データ型
      1. 日付
      2. 名前
      3. 認証
      4. 電話
      5. 連絡先情報
        1. 郵便
        2. テレコミュニケーション
        3. オンライン
  5. 付録
    付録 1:参考文献(標準準拠)
    付録 2:P3P基本データスキーマ定義(標準準拠)
    付録 3:XMLスキーマ定義(標準準拠
    付録 4:RDFデータモデル(標準非準拠
    付録 5:ABNF表記法(標準非準拠)
    付録 6:P3Pガイドライン(標準非準拠)
    付録 7:ワーキンググループ貢献者(標準非準拠)

1. 序論

The Platform for Privacy Preferences Project (略称P3P)は、 Webサイトが標準形式でそのサイトのプライバシープラクティスを表現することを可能にし、その標準形式データをユーザエージェントが自動的に取りこんだり、簡単に処理したりすることを可能にする。P3Pユーザエージェントはサイトのプライバシープラクティスを利用者に(マシンリーダブルの形式、及び 人間が読むことのできる(ヒューマンリーダブルの)形式で) 通知することができ、プライバシープラクティスが適切ならば、自動意思決定を行うことも可能である。 P3Pユーザエージェントのこの自動意思決定機能を用いれば、利用者は、アクセスするサイトの総てのプライバシーポリシーを逐一読む必要が無くなる。

P3Pは、利用者が、個人情報を受け渡す前にサイトのプライバシーポリシーを知ることを可能にする メカニズムを提供するが、そのサイトがそのプライバシーポリシーに従った行動をすることを保証するメカニズムを提供するものではないことに注意されたい。本仕様書の内容を実装した幾つかのプロダクトは、そのような保証の支援メカニズムを有するかもしれないが、それは、個々の実装上の都合によるものであり、本仕様の範囲外である。しかしながら、P3Pは、プライバシーに関する法律や自主規制プログラムを補完するものであり、それらを強化するメカニズムを提供することができる。更に付け加えるならば、P3Pは、データ転送のメカニズムを提供するものではなく、また、データの保管を安全に行うためのメカニズムを提供するものでもない。P3Pは、データ転送を可能にするツールの中に組み込まれ、それらのツールは、適切な機密保護機構を有しているべきである。

1.1 P3P1.0仕様書

P3P1.0仕様書は、P3Pプライバシーポリシー (P3Pポリシー)のための シンタックスとセマンティクスとを定義しており、そして、Web リソースにプライバシーポリシーを付加するためのメカニズムを定義している。 P3Pポリシーは、プライバシーに関する処理を如何に行うかを表現する為に用いられるP3Pボキャブラリを使って組み立てられるステートメントから構成されている。 P3Pポリシーは、P3P基本データスキーマの要素を使用する。P3P基本データスキーマとは、データ要素の一つの標準集合のことを言い、総てのP3Pユーザエージェントは、これを処理できなければならない。P3P仕様書は、新たなデータ要素やデータ集合を定義可能とするメカニズムを規定しており、また,P3Pボキャブラリを増やすことを可能とする簡単なメカニズムも規定している。

1.1.1 P3P1.0の最終目的と可能性

P3Pバージョン1.0は、Webサイトがデータ収集を如何に行うかをWeb利用者に通知することを目的に設計されたプロトコルである。P3Pバージョン1.0は、Webサイトがデータ収集と収集したデータの処理とをどの様に行うかをマシンリーダブルのXML形式のP3Pポリシーにコード化する方式を提供する。P3P仕様書は、次の定義を行っている。

P3P1.0の最終目的は、次の二つである。最初の一つは、Webサイトがデータ収集を如何に行うかを標準化され、マシンリーダブルで、且つ、簡単な方法で、提示することを可能とすることである。二つ目は、Web利用者がアクセスするWebサイトが、どんなデータを収集し、どの様にデータが使われるかWeb利用者が知ることができ、どのデータやどんな利用をWeb利用者が "オプトイン"または"オプトアウト"することが可能か知ることができるようにすることである。

1.1.2 P3P利用例

P3Pを理解する為、P3Pを利用する一つの事例を考えてみよう。花子さんは、クールカタログ(そのURLが http://www.thecoolcatalog.com/)と呼ばれるあるサイトを見ようと思ったと仮定し、そのクールカタログは総てのページにプライバシーポリシーを附加しているものと仮定する、更に、花子さんは、 P3P対応のブラウザを利用しているものとする。

花子さんが、ブラウザ上でクールカタログのURLを指定したとすると、クールカタログは、ホームページ情報を返すとき、そのページに対応したP3Pポリシーも返す。そのポリシーには、当該ページでは標準のHTTPアクセスログに含まれるデータのみを収集すると記述しているものとする。花子さんのブラウザは、そのポリシーを予め花子さんがブラウザに与えておいたプリファレンスと照合し、そのポリシーが受け入れ可能か、又は、花子さんに通知すべきかチェックする。そのポリシーが受け入れ可能だったと仮定すると、この場合、ホームページは、如何なるポップアップメッセージも表示されること無しに表示される。多分、ウィンドウの片隅に小さなアイコンが表示され、サイトからプライバシーポリシーが提示され、そのポリシーは、彼女のプリファレンスに合致していることを示すであろう。

次に、花子さんが、当該サイトのオンラインカタログのリンクを選択したとすると、当該サイトのカタログ部分で少し複雑なソフトウェアが実行されるようになっていて、このソフトウェアがショツピングカート機能を実現する為に、クッキーを用いていたとすると、当該Webサイトのこの部分は、より多くの情報を収集するので、Webサーバは、花子さんのブラウザに新しいP3Pポリシーを送信する。この場合においても、当該ポリシーが花子さんのプリファレンスに合致したと仮定すると、何のポップアップメッセージが表示されることなく、花子さんは、操作を継続でき、何かを購入したりして、最後にチェックアウトページに進むことができる。

クールカタログのチェックアウトページは、何らかの追加情報を必要とする。例えば、花子さんの名前、住所、クレジットカード番号及び電話番号等である。この場合、当該Webサイトは、どんなデータをここで収集し、ここで収集した彼女のデータは、彼女の注文を処理する為にのみ使用すること等を記述した新しいP3Pポリシーを送信する。

花子さんのブラウザは、このP3Pポリシーを調べ、例えば、花子さんが、ブラウザにもしも、電話番号の要求があったならば、警告を通知するよう設定しているならば、ポップアップメッセージで、電話番号が要求されていることを通知し、且つ、P3Pステートメントの内容についても説明する。そこで、花子さんは、要求されたものが受け入れ可能か否か判断することができ、もし、受け入れ可能であるならば、彼女は、注文操作を継続することができ、受け入れることができないならば、トランザクションをキャンセルすることができる。

上記の場合と異なり、花子さんが、ブラウザに「サイトが電話番号を要求し、そして、その情報を第三者に渡し、そして/または、現在の注文処理以外に用いるならば、警告する」ように設定しているならば、花子さんは、如何なるポップアップメッセージが表示されることなく、注文操作を完了することができる。

(注)本シナリオは、あくまでも仮想のインプリメンテーションであり、ユーザインターフェースは、上記以外のものも可能である。

1.1.3 P3Pポリシー

P3Pポリシーは、ポリシーの中にプライバシー情報を如何に処理するか表記している組織を識別するためP3PボキャブラリのXMLエンコーディングを用い、収集されるデータ型とデータ要素を列挙し、そして、どの様にデータが使われるか説明する。更に、ポリシーは、データの受領者を明確にし、係争解決のための情報のような情報開示にまつわる諸々のものを作成可能にし、当該サイトの人間が読むことのできるプライバシーポリシーの場所(URL)の通知を行う。P3Pポリシーは、関係する総てのデータ要素とそれをどう使うかカバーしなければならない。(しかし、法の執行の際に必要とされる情報に関する法律的問題はこの仕様書では関知しない。:例えば、公権力によって要求された場合、第三者に提供しないはずのデータがポリシーの規定に反して、他の組織に提供されることがあるかもしれない。)P3Pの記述は、ポジティブな記述であるべきである。すなわち、或るサイトが何々をしないと記述するよりは、何々を行うと記述することが望ましい。P3Pボキャブラリは、或る特殊な法律や動規規範に準拠するためのインディケータと言うより、サイトがプライバシー情報を如何に取り扱うかを記述することを目的に設計されている。しかしながら、幾つかのユーザエージェントは、サイトのプライバシー情報の取り扱い方が法律や行動規範に合っているか否かテストするために、開発されるかもしれない。

P3Pポリシーは、サイトがプライバシー情報を如何に取り扱うかを表現する。しかし、電気通信プロバイダやISP、プロキシ業者、その他の中間業者が、サイトと利用者との間のプライバシーデータ交換に関与するが、それらの中間業者が何を行っているか、サイトのポリシーは、関与しない。

1.1.4 P3Pユーザエージェント

P3P1.0ユーザエージェントは、Webブラウザか、ブラウザプラグインか、プロキシサーバに組み込まれることができる。また、それらはJavaアプレットもしくは、JavaScriptで実装され、電子財布や自動フォーム入力やその他の利用者データ管理機能の中に組み込まれるかもしれない。 P3Pユーザエージェントは、HTTP応答の中にあるP3Pヘッダー及びHTMLコンテンツの中に埋め込まれているP3P METAタグを捜す。これらの特殊ヘッダーとタグとは、関係する P3Pポリシーの存在場所を示している。ユーザエージェントは、示された場所からポリシーを取り込み、それを解析し、シンボルを表示したり、音を鳴らしたり、サイトのP3Pプライバシープラクティスを示すプロンプトメッセージを生成したりする。更に、ユーザエージェントは P3Pポリシーを利用者が設定したプライバシープリファレンスの集合と比較し、適切な処理を行うことが可能である。P3Pは、電子財布や自動フォーム入力のようなデータ転送メカニズムにおけるある種の"ゲートキーパー"の機能を行うこともできる。或るP3Pユーザエージェントは、 P3Pポリシーを検索したり、利用者のプリファレンスと比較したり、次の二つの条件を満たしたときデータを送出するメカニズムの何れか中に統合されるかもしれない。a) ポリシーが、利用者のプリファレンスと一致している。そして、b) 要求されたデータ転送が、ポリシーと一致している。もしも、これらの条件の何れかに合致していないならば、利用者に、不一致の通知と、データを送出するか否か選択する機会が与えられるべきである。

1.1.5 サーバ上でのP3Pの実装

Webサイトは、利用者に文章で開示しているプライバシーポリシーをP3Pシンタックスに翻訳し、その P3Pポリシーの場所を通知するようサーバを再構成することにより、P3P 1.0を実装することができる。自動化ツールにより、この翻訳を支援することが可能である。多くのHTTP1.1サーバは新たなソフトウェアを導入しなくても、P3P 1.0サポートするよう構築できる。具体的には、HTTP拡張フレームワークを用いて、HTTP応答中に、サイトのP3Pポリシーの場所を示すP3P拡張ヘッダーを挿入するようサーバを構築できるであろうし、または、HTMLコンテンツ中にMETAタグを挿入するようにすることができる。Webサイトは、サイト全体に一つのP3P ポリシーを付与することもできるし、そのサイトの異なる部分に異なるポリシーを指定するといったこともできる。ある一つのP3Pポリシーは、そのサイトへの訪問者とHTTPでやりとりする際に生成されたり、交換されたりするすべてのデータをカバーするものでなければならない。更に言うと、幾つかのサイトは、データがどの様に収集されたかにかかわらず、総てのデータをカバーするポリシーを作ることを望むかもしれない。

1.1.6 P3Pの将来バージョン

P3P仕様書ワーキンググループは、当面の、P3Pの早期の実装と普及を促進するため、初期のP3P 1.0 仕様書に記述してあった重要な機能を削除している。当該グループは、P3P 1.0が普及した時点で、 P3Pの次期仕様書を公開することを予定している。次期仕様書には、実装経験や普及時の経験を反映させるとともに、P3P 1.0から落とされた、次の4つの重要な機能を盛り込む予定である。

1.2 本仕様書について

W3Cの正式仕様書作成手順に従い、本仕様書は、相互互換性のあるP3Pアプリケーションの作成に必要とされる総ての仕様を包含している。

本仕様書で用いられている[ABNF]記述は、RFC2234に従ったものであり、その概略を付録に示す。しかし、その構文は、XML構文で示される単なる一つの文法であることに注意されたい。そうであるけれども、XMLで表現できる構文の意味するところの総てを理解することができるであろう。例えば、空白規則、引用符(')や二重引用符(")を用いた引用、 エスケープ文字、コメント、各部分での記述方法などである。

更に、属性と要素は、任意の順序で使えることに注意されたい。本仕様書は、必要性の程度を表す為、 RFC2119 [KEY]に定義されている次の用語を用いる。次の重要な用語が、相互互換性を実現する為に、本文書全体を通して用いられている。

「しなければならない」 もしくは「してはならない」
この用語または形容詞"要求される"は、当該アイテムが本仕様書において絶対的に必要なものであることを意味する。
「するべきである」or「するべきでない」
この用語または形容詞"推奨される"は、当該アイテムが正当な理由のもとに、或る状況下において無視できることを意味する。しかし、完全実装の場合、実装すべきものであり、実装しない場合、注意深く検討すべきものである。
「してもよい」
この用語または形容詞"オプショナル"は、当該アイテムが有っても無くてもよいものであることを意味する。例えば、或るベンダーは、プロダクトを魅力あるものとする為、マーケット戦略的にこのアイテムを含めるかもしれないが、他のベンダーはこのアイテムを落とすかもしれない。

1.3 用語

データ要素
名字や電話番号と言った個々のデータの実体を意味する。相互互換性のため、P3P 1.0はデータ要素の基本集合を定めている。
データカテゴリ
「実社会における連絡先情報」などのような、データ要素 データ集合の或る重要な属性を指し、トラストエンジンにより、どのデータタイプが処理中なのか判断する為に用いられる。P3P 1.0は、基本データカテゴリを定めている。
データ集合
"user.home.postal."と言った、 データ要素の一般的なグループのことである。この集合は、最後にピリオドを付けて表される。 P3P 1.0は、幾つかのの基本データスキーマを定めている。
等価なプラクティス
オリジナルのプラクティスと比較して、目的、受領者、個人を識別可能な利用などが同じか、もしくは、より制約されているプラクティスであり、更に、その他の情報開示事項が本質的に異ならないものを言う。例えば、異なる業界ガイドラインに準拠しているが、似ているプラクティスを有する二つのサイトを言う。
個人を識別可能な利用
個人を識別可能な個人情報の利用を言う。これには、他のソースや連携情報からの、類推によって、個人を特定可能なリンク情報を含むことがある。
個人識別可能情報
個人に関するか、個人を識別可能な任意の情報
プライバシーポリシー
一つ、もしくは、複数のプライバシーステートメントの集まりであり、所有者、URI、保証や当該ポリシーによってカバーされるサービスの係争解決手続きなどと、一緒になっている。
プラクティス
データの利用の仕方、目的、受領者やその他の情報公開事項などを述べている情報公開の集合。
プリファレンス
ユーザエージェントが行うべきアクションを決める一つの規則、もしくは、規則の集合。或るプリファレンスは、形式定義の算定可能なステートメント(例;プリファレンス交換言語 [APPEL])により記述されるかもしれない。
目的
データ収集とデータ利用の理由
レポジトリ
ユーザエージェントの管理下で、利用者情報を格納しておくメカニズムを言う。
サービス
ポリシーを発行し、必要ならデータ要求を行うプログラムを言う。この定義に従えば、サービスは、サーバ(サイト)、ローカルアプリケーション、ローカルに動くアクティブコード(ActiveXコントロールや Javaアプレット等)や他のユーザエージェントであっても良い。
サービス提供者(データ管理者、組織)
Webサイトを使って情報やプロダクトを提供し、情報を収集し、プラクティスステートメントを作成し掲示する人、もしくは、組織を言う。
ステートメント
P3Pステートメントは、データ要素の収集を行うときに開示されるプライバシープラクティスの集合である。
URI
Webリソースを特定する為に用いられるUniform Resource Identifierを言う。 URIのシンタックス及びセマンティクスに関する詳細は付録の[URI]を参照されたい。
利用者
サービスを利用し、個人情報を有する個人(または、単体の様に行動する人々のグループ)を言う。
ユーザエージェント
利用者の代りに、ユーザプリファレンスに基づいて、サービスとのやりとりを仲介することを目的に作られたプログラムを言う。一人の利用者が複数のユーザエージェントを持つことができ、また、ユーザエージェントは、必ずしもデスクトップ上に存在しなければならないことはないが、総てのユーザエージェントは利用者だけの利益のために動作し、利用者の制御下になければならない。このような利用者とユーザエージェントの信頼関係は、P3P外部の制約によって左右されるかもしれない。例えば、或るユーザエージェントは、オペレーティングシステムやWebクライアントの一部として、また、ISPやプライバシー代行業者の契約条項の一部として、信頼されるかもしれない。

2. ポリシー参照

2.1 ポリシー参照の目的

プライバシーポリシーの参照(ポリシー参照)はP3Pプロトコルの手順における最初のステップの一つである。サービスは、特定のURIまたはURIの集合に対して適用するプライバシーポリシーを表明するためにポリシー参照を用いる。ユーザエージェントはあるページに適用されるプライバシーポリシーの場所を突きとめるために、ポリシー参照を使用するだろう。そのことによって、ユーザエージェントは利用者のためにプライバシーポリシーを処理することができる。

我々は広く、ポリシー参照をパフォーマンスの最適化のために使用する。プライバシーポリシーは典型的には数キロバイトのデータであるが、プライバシーポリシーを参照するURIは典型的には100バイト未満のデータである。こうした帯域幅の節約に加えて、ポリシー参照は必要な計算量を少なくする。すなわち、プライバシーポリシーは複数のURIと一意的に関連付けることができる。そのことによって、ユーザエージェントはプライバシーポリシーが適用される文書ごとにプライバシーポリシーを処理せずに、一度プライバシーポリシーを解析し処理すればよい。

2.2 参照シンタックス

以下の2つの方法のうち一つを用いることにより、P3PポリシーをHTTPによって取得された文書に関連付けることができる。第一に、P3PポリシーはPolicy 応答ヘッダを追加することによって文書に関連付けることができる 。第二に、P3PポリシーはMETA タグを通してHTML文書またはXML文書に関連 付けることができる。

本文書は、HTTP以外の方法で取得された文書にP3Pポリシーを関連付ける方法については規定しない。

2.2.1 HTTP拡張フレームワークを用いたシンタックス

P3PはHTTP拡張フレームワーク[HTTP-EXT]を使用する。HTTP拡張フレームワークにより、新たなHTTPヘッダを定義し、使用することができる。

ある拡張に関連したすべてのHTTPヘッダは、要求または応答において任意の2つの数字を前に置くこととなっている。実装者は、この数字をメッセージごとに選択してもよい。このことは、拡張に関連したヘッダのための一意的なネーム空間を保証する。さらに、拡張はネーム空間を宣言するときに、(URIにより)それ自身を識別しなければならない。

HTTP拡張フレームワークは、その拡張を識別する世界的に一意なURI(拡張宣言)を必要とする。 P3Pの拡張宣言は次のURIである。

http://www.w3.org/2000/P3Pv1

P3Pポリシーは、新たな応答ヘッダ(Policyヘッダ)を使用することにより、HTTPによって取得されるいかなる文書とも関連付けることができる。PolicyヘッダはP3Pポリシーが置かれているURIを含んでいる。このURIはP3Pポリシーの特定や参照以外のいかなる目的でも使用されてはならない(したがって、利用者の閲覧状態を維持するために使用されてはならない)。

P3P拡張宣言とPolicyヘッダは、P3Pが利用可能なサーバが関連する要求に対して応答する場合(HEAD要求やOPTIONS要求に応答する場合など)には、いつでも挿入するべきである

ヘッダのシンタックスは:
 
[2.1]
policy-header
=
prefix `-Policy: ` URI
ここでは、URIはRFC 2396 [URI]により定義される。prefix は、このメッセージ中のP3Pヘッダのために選択された2つの数字によるネーム空間の宣言であり、[HTTP-EXT].に従う。 このprefix は、応答における他のネーム空間の宣言と矛盾しない2つの数字であればいかなるものでもよい。

他のHTTPヘッダに対する規則に合致することであるが、このヘッダのPolicy部分はいかなる字体で書かれてもよい。

例2.1:

1. クライアントはGET要求を行う。

GET /index.html HTTP/1.1
Host: thecoolcatalog.com
Accept: */*
Accept-Language: de, en
User-Agent: WonderBrowser/5.2 (RT-11)

2. サーバはコンテンツと、そのページのプライバシーポリシーを示したPolicyヘッダを返信する。

HTTP/1.1 200 OK
Opt: "http://www.w3.org/2000/P3Pv1"; ns=11
11-Policy: http://thecoolcatalog.com/P3PPolicy1.xml
Content-Type: text/html
Content-Length: 7413
Server: CC-Galaxy/1.3.18

これ以外にも、PrefixExclude という2つのP3Pヘッダが存在する。これらによって、ある文書において、他の文書に対応するプライバシーポリシーを規定することができる。このことは、ユーザエージェントが他の文書の取得要求を個々に行うことなく、他の文書に関するプライバシーポリシーを知ることができるという点で有用である。 
[2.2]
prefix-header
=
prefix `-Prefix: ` local-URI *(`,` local-URI)
[2.3]
prefix-exclude
=
prefix `-Exclude: ` local-URI *(`,` local-URI)

Prefixヘッダ(また、オプショナルなものとしてExcludeヘッダ) が、Policyヘッダと一緒になって表示されたとき、Policy URIにおいて特定されたプライバシーポリシーがPrefixヘッダによって特定されたローカルなURIに対応するホストの URI全てに適用されること(また、Excludeヘッダによって特定されたローカルなURIに対応するホストのURI全てに適用されないこと)を意味する。

Prefixヘッダが宣言されない場合は、(例2.1のように)プライバシーポリシーが現在のリソースに適用されることが暗黙的な前提とされていなければならない

例2.2

クライアント要求:

GET /index.html HTTP/1.1
Host: thecoolcatalog.com
Accept: */*
Accept-Language: de, en
User-Agent: WonderBrowser/5.2 (RT-11)

サーバ応答:

HTTP/1.1 200 OK
Opt: "http://www.w3.org/2000/P3Pv1"; ns=11
Opt: "http://www.w3.org/2000/P3Pv1"; ns=12
11-Policy: http://thecoolcatalog.com/P3PPolicy1.xml
12-Policy: http://thecoolcatalog.com/P3PPolicy2.xml
12-Prefix: /images/,/styles/
12-Exclude: /images/banners/
Content-Type: text/html
Content-Length: 7413
Server: CC-Galaxy/1.3.18

例2.2のサーバ応答は(例2.1と同様に)、http://www.thecoolcatalog.com/index.htmlというページがhttp://thecoolcatalog.com/P3PPolicy1.xml というプライバシーポリシーに従うことを意味している。しかし、この例ではhttp://thecoolcatalog/images/* (http://thecoolcatalog/images/banners/*は除く)とhttp://thecoolcatalog/styles/*の形のURIも、このプライバシーポリシーに従うという追加的な情報が含まれている。

PrefixExclude のマッチングは単純な文字列 上のマッチングで行う。結果として、ディレクトリの末尾の“/”が欠けたりした場合、予期しない結果がもたらされるかもしれない。例えば、"12-Exclude: /images/logos"というヘッダは"/images/logos/"というサブディレクトリの中の全てのリソースを適用対象から除外するのみならず、"/images/logoschool.jpg"というURL上のファイルをも除外してしまうだろう。

2.2.2 METAタグを用いたシンタックス

サーバは、関連するP3Pポリシーの所在地を示すMETAタグが埋め込まれたHTMLコンテンツやXMLコンテンツを提供してもよい。P3Pのこの使用法では、P3P対応のサーバは必ずしも必要ではない(サーバの運用方法にいかなる変更も要求することなく、コンテンツに埋め込みリンクタグが含まれるように変更することができる)。

METAタグは、P3P PolicyPrefixおよびExcludeヘッダを用いても表現できる情報を直接、コード化するものである。拡張宣言"http://www.w3.org/2000/P3Pv1"によって規定された拡張ヘッダの各列は、直接、以下のような形式のMETAタグを埋め込んだHTMLにおいて表現することができる:
[2.4]
p3p-html-block
=
`<DIV>`
`<META name="P3Pv1-Policy" content="` 
   URI `">`
[`<META name="P3Pv1-Prefix" content="` 
   local-URI *(`,` local-URI) `">`]
[`<META name="P3Pv1-Exclude" content="` 
   local-URI *(`,` local-URI) `">`]
`</DIV>`

例えば、HTTPヘッダを用いた例2.2において表明されたプライバシーポリシーは、 http://thecoolcatalog.com/index.htmlというWebページの中に以下のHTMLの断片を含めることによって、同等に表明することができる。

<DIV>
<META name="P3Pv1-Policy" 
  content="http://thecoolcatalog.com/P3PPolicy1.xml">
</DIV>
<DIV>
<META name="P3Pv1-Policy"
  content="http://thecoolcatalog.com/P3PPolicy1.xml">
<META name="P3Pv1-Prefix" content="/images/,/styles/">
<META name="P3Pv1-Exclude" content="/images/banners">
</DIV>

METAタグで表現されるポリシー参照は、HTTPヘッダを用いて表現されるポリシー参照と全く等価であることに注意すること。ユーザエージェントは、両方のフォーマットに互換的に対処しなければならない。どちらの方法でなされた表明も、他のフォーマットにおいてなされた表明と矛盾するものではない。 一義性の要求事項も参照すること。

2.3 ポリシー参照の使用

2.3.1 一義性

ポリシー参照の第一の規則は、一義性である。Webサイト上の各リソースに対し、ある時点で有効なプライバシーポリシーはたかだか一つなければならない。このことはとりわけ、2.2.1節で説明した、 Prefixヘッダを用いて他のリソースのプライバシーポリシーの表明を行うこと(先取表明、forward declaration)にあてはまることである。この先取表明においては、同一のリソースに対して2つ以上の異なるポリシー URIが参照されてはならない。また、このことはHTTPヘッダによる表明とHTML文書中の METAタグによる表明を組み合わせた場合にも適用されることに注意すること(これら2つのフォーマットはユーザエージェントによって互換的に取り扱われなければならないため)。(しかし、HTTPヘッダによる表明とMETAタグによる表明の間で矛盾は、HTML/XMLコンテンツがすでにダウンロードされ、埋め込まれたMETAタグの表明が現れた後にのみ検出されるだろう。)

単一のリソースに対して上記のようなポリシー表明の多義性をチェックすることの必要性は明らかであるが、ユーザエージョントは、先取表明における多義性を検出するために、Webサイト全体にわたってポリシー表明を検索するべきである。あるリソースを要求した際のそのリソースのポリシー表明が、以前に与えられたそのリソースに関する先取表明とは異なってはならない

時間的な一義性(不変性)に関する議論として、ポリシーの不変性プライバシーポリシーと参照に関するキャッシュの可能性の節も参照すること。

2.3.2 多言語

同一のプライバシーポリシーの多言語版(翻訳版)は、そのプライバシーポリシーが特定の言語によってエンコーディングされていることを正確に示すために、HTTPの"Content-Language"タグを用いることによって、サーバによって提供することができる。このことは、「組織(entity)」や「結果(consequence)」のような人間が読むことのできる箇所を様々な言語で表現することができるので有用である。同一URI上で多言語で提供されている複数のプライバシーポリシーを区別するために Content-Languageタグが使用される場合は、常にそれらのプライバシーポリシーは各言語を通して同一の意味を持たなければならない

2.3.3 直接参照と間接参照

サービスは直接プライバシーポリシーを参照してもよいし、間接的に参照してもよい。プライバシーポリシーの 直接参照とは、取得されたポリシーURIがそのプライバシーポリシーの本体となるXML文書を返す場合の、ポリシーURIのことである。プライバシーポリシーの間接参照とは、取得されたポリシーURIが新たなポリシーURIを返す場合の、ポリシーURIのことである。間接参照によって返されるこの新たなポリシーURIは、それ自体が間接参照であってもよいが、このことはパフォーマンス上の理由から薦められない。

直接参照と間接参照は、それらが取得される際にサーバによって与えられるHTTPのリターンコードによって識別がされる。直接参照のポリシーURIが取得された場合、サーバは200番台のHTTPリターンコードか、301 (Moved Permanently)のリターンコードか、あるいは(適当であれば)エラーコードを返すべきである。サーバは302 (Found)や303 (See Other) 、 307 (Temporary Redirect)のリターンコードを返してはならない。間接参照のポリシーURIが取得された場合、エラーコード(400番台または500番台のコード)が適当な場合でないかぎり、サーバは302や303、307のリターンコードを返さなければならない。302や303、307のリターンコードが返される場合は、そのリターンコードは実際のポリシーURIを与えるLocation 応答ヘッダを含まなければならない

サービスは、適切な方法として、直接ポリシー参照と間接ポリシー参照のどちらを使用するか選択する ことができるポリシーの不変性の要求事項を尊重するかぎりにおいて)。直接参照は、これらのプライバシーポリシーを処理するユーザエージェントにとって最良のパフォーマンスをもたらす。ポリシーの不変性の規則により、ユーザエージェントがすでに取得済みのポリシーURIへの直接参照を受信した場合、それ以上の通信活動を行うことなく、プライバシーポリシーの処理を行うことができる。このことはユーザエージェントの応答時間を短縮する効果をもたらす。

間接参照は、実際のポリシーの所在を突きとめるために、さらに少なくとも一往復の通信活動を行うことが必要となる。このことはユーザエージェントのパフォーマンスを下げる結果となる。しかし、間接参照を用いることで、ある種の組織はより柔軟性のあるプライバシーポリシーの配置を行うことができる。以下にその一例を挙げる:

クールカタログという架空の企業は、世界的規模でWebサイトを開設している。この企業の大本のWebサイトwww. thecoolcatalog.comはいくつもの国別サイトへのリンクを提供している。ここでは、クールカタログが皮切りに、 usa.coolcatalog.com (米国)、www.thecoolcatalog.co.uk(英国)、www.thecoolcatalog.com.ru (ロシア)、 www.thecoolcatalog.com.jp(日本)という4つのローカルなサイトを立ち上げたと仮定する。また、これらのサイトは各々、サイトのコンテンツをローカルに開発していると仮定する。このことにより、各サイトはローカルな閲覧者により適合したサイトを構築することができる。

しかし、 クールカタログは、世界中の自社のサイト全てに適用する単一のプライバシーポリシーを所持することを決定した。クールカタログは大本のWebサイト(www.thecoolcatalog.com)にこのプライバシーポリシーを掲載し、ローカルなサーバ上の各ページにはこのプライバシーポリシーを参照させることで、この決定を実行することができるだろう。 ここで、クールカタログがプライバシーポリシーを更新しようとする場合、ポリシーの不変性の規則により、クールカタログは自社のプライバシーポリシーを新しいURIに掲載しなければならない。したがって、 クールカタログは自社の全てのWebサイト上のポリシー参照を変更しなければならない。このためには、世界各地の Web管理者の作業が必要となるだろう。この問題は、クールカタログがより事業を拡大し、20とか50とかのローカルな Webサイトを所持した時にはいっそう困った問題となる。

間接参照はこのような運用上の問題に対するソリューションとして意図されたものである。クールカタログの各ローカルサイトは大本のクールカタログのサーバを指し示したポリシーURIを表明することができる。このポリシーURIを取得すると、現在適用されているプライバシーポリシーへのポリシー参照が与えられる。例えばクールカタログが顧客にその週の特別供給品のリストを送付するために顧客の電子メールアドレスを収集しようとしていると仮定する。各ローカルサーバは間接的なポリシーURIであるhttp://www.thecoolcatalog.com/privacy/P3P/policy-weeklyspecialを使用することができる。このURIを取得すると、実際のプライバシーポリシー(それはhttp://www.thecoolcatalog.com/ privacy/P3P/policy-weeklyspecial-3.xmlであるかもしれない)へのリンクが与えられる。クールカタログがプライバシーポリシーを更新しようとする場合、そのプライバシーポリシーを参照しているローカルサーバの台数に関わりなく、大本のサーバ上でのみ更新を行えばよい。

一般に、サービスは直接ポリシー参照の使用が可能な場合には、そちらを使用するべきである。間接ポリシー参照については、沢山の多様なWebサイトを持つ組織のみが使用することが望ましい。

サービスは、プライバシーポリシーステートメントの正確性を保証するために、同一の組織運営下にあるURI間でのみ間接ポリシー参照を行うべきであることに注意すること。しかし、この要求事項を守らせるための技術的手段はない。間接ポリシー参照は、組織のWebサイトの構造によっては、他のホスト上のURIや他のドメイン内の URIに対してさえ参照を行うことができる

2.3.4 間接参照の取り扱い

ユーザエージェントがポリシー参照を受信したときに、それが直接参照なのか間接参照なのかを区別する方法はない。プライバシーポリシーを適切に処理するためには、ユーザエージェントはそのポリシー参照で規定されたURIを取得し なければならない。この参照が302(Found)、303 (See Other)、または 307 (Temporary Redirect)というリターンコードを返した場合は、ユーザエージェントはプライバシーポリシーを処理するために、実際のプライバシーポリシーの場所を指し示すLocation ヘッダにおいて与えられる URIを取得しなければならない。プライバシーポリシーが一たび直接参照により取得されると、(ユーザエージェントがこの 情報を記録しつづけるかぎり)2度目以降は取得される必要がなくなることに注意すること。しかし、間接参照では、(ExpiresまたはCache-ControlHTTP ヘッダによってプライバシーポリシーが変更されていないことが示されないかぎり)、プライバシーポリシーが変更されていないことを確認するために再チェックを行う必要がある。

2.3.5 ポリシーの不変性

プライバシーポリシーの重要な要求事項として、いわゆるポリシーの不変性がある。これは、一つの例外を除いて、あるURIで直接参照されるプライバシーポリシーは変更してはならないというものである。このようにして、プライバシーポリシーのURIはプライバシーポリシーの一意的な識別子のようにふるまうため、いかなる新たなプライバシーポリシーも新たな異なるURIを使用しなければならない。この一般原則に対する一つの例外とは、同一のポリシーの多言語版(翻訳版)が、HTTPの "Content-Language"タグを用いることにより、サーバによって提供される場合である。

P3Pクライアントは、キャッシュ上のプライバシーポリシー(および、Content-Language が表明されている場合にはそのContent-Language)と新たに取得したプライバシーポリシー(および、Content-Language が表明されている場合にはそのContent-Language)とを比較することにより、ポリシーの不変性をチェックしてもよい。ユーザエージェントが2つの異なるプライバシーポリシーが同一のURIを持つことを発見した場合、それらが2つの異なるContent-Language を持つのでないかぎり、ユーザエージェントはその変更されたプライバシーポリシーがカバーするページについてはP3Pポリシーを持たないものとして取り扱わなければならない

ポリシーの不変性は、直接参照されるプライバシーポリシーにのみ当てはまることに注意すること。間接参照に関しては、間接ポリシー参照が取得されたときに返される実際のポリシーURIは、時間の経過とともに変えることができる (これが間接ポリシー参照の背後にある目的である)。間接ポリシー参照は、直接ポリシー参照に変更され てはならない。このようなことを望む場合には、新たなポリシーURIが使用されなければならない

2.4 プライバシーポリシーと参照に関するキャッシュの可能性

ネットワークへのアクセス遅延や、決して十分とは言えない帯域幅をもったWorld Wide Webのような分散システムにおいて、キャッシュを行う事は、利用者に満足の行くパフォーマンスを提供するためにとても重要な事です。この事実に基づいて、我々がネットワーク上でのP3Pとキャッシュの相互作用に関して考慮することもまた重要なことです。

この章では、キャッシュ可能であるP3Pオブジェクトと、それらのオブジェクトの有効期限をどのようにして決定するかについて説明します。この説明の中で我々は、共有キャッシュとプライベートキャッシュを区別しません。この件に関しては、HTTP 1.1のCache-Control directivesで取り扱われています。HTTPにおけるキャッシュの一般的な説明は、[HTTP1.1]を参照してください。

2.4.1 キャッシュされるオブジェクト

HTTP自体は、文書、画像、音楽などのオブジェクトをキャッシュすることに関与しています。 P3Pでは、P3P自身をHTTPに関連した簡略化されたオブジェクトであるプライバシーポリシー文書をキャッシュする事に関与する必要があります。一方で、P3Pは「オブジェクトからプライバシーポリシーへの参照」についてもキャッシュする事を明確に論議する必要があります:

2.4.1.1 プライバシーポリシー文書に関するキャッシュの可能性

プライバシーポリシー文書はXML文書で、他のオブジェクトと同じ方法でHTTPを通して取得されます。結果として、HTTPによって提供されるメタデータは、プライバシーポリシー文書のキャッシュ有効期限を記述するのに適しています。我々は、プライバシーポリシーの不変性の規則により、プライバシーポリシー文書は大いにキャッシュされるべきという補足的な所見を述べます:それらの文書は決して変更されない。従って、サーバはプライバシーポリシー文書のための長期有効期限(例えば30日)を指定するためにCache-Control: max-age HTTPヘッダを使用しようとすることができます。

2.4.1.2 ポリシー参照に関するキャッシュの可能性

P3Pユーザエージェントは、第二の有効期限情報として、ポリシー参照の有効期限を使用することができます。従って新規の応答ヘッダによって指定されるこの有効期限は、ユーザエージェントに対して、指定された有効期限の間プライバシーポリシーが文書に適用されることを示します。ユーザエージェントは、指定された有効期限の間プライバシーポリシーの処理結果をキャッシュする事ができるので、このヘッダ情報を使用することで処理を簡略化することができます。

ポリシー参照に関するキャッシュの可能性が、どのようにユーザエージェントに対して有益であるかというと例として、大勢の利用者にサービスを提供する第三の信用機関があるとします。その信用機関が利用者の代わりにP3Pポリシーを取得すると仮定した場合、信用機関はそれらのプライバシーポリシーを利用者のプリファレンスと比較し、利用者に対して何らかの情報を提供します。もしポリシー参照が有効期限情報を持たない場合、信用機関はPolicyヘッダとMETAタグをチェックするために、利用者が要求した全ての文書を取得しなければなりません。最悪の場合、この事はサーバの負担を倍増し、利用者のブラウザを使用した閲覧に要する時間を大幅に増加させます。しかし、ポリシー参照がキャッシュの有効期限を含んでいる場合、信用機関はプロキシサーバがHTTP文書のキャッシュを保存するように、それらのポリシー参照をキャッシュする事ができます。我々はこのようなキャッシュ方法が、ネットワーク遅延や帯域幅の消費を劇的に低減できることを期待しています。

2.4.2 キャッシュ有効期限の表記

我々は、プライバシーポリシー文書とポリシー参照の望ましいキャッシュを制定するために、サービスに有効期限を示す手段を提供しなければなりません。

2.4.2.1 プライバシーポリシー文書の有効期限表記

上記で述べたように、HTTPではプライバシーポリシー文書の有効期限を指定するために十分適用できる幾つかのメカニズムを提供しています。特にCache-ControlExpiresHTTPヘッダは、この役割を果たすために使用できるでしょう。

2.4.2.2 直接ポリシー参照の有効期限表記

新規の応答ヘッダであるPolicy-CCは、直接ポリシー参照の有効期限を指定するために導入されています。このヘッダ名は"Policy Cache Control"を簡略化したもので、 Cache-ControlExipresHTTPヘッダからコンセプトを借用しています。 Policy-CCPolicyヘッダに含まれるであろう応答ヘッダで、Policyヘッダとして同一のネーム空間指定子によって前置されるべきです。

ヘッダシンタックス:
 
[2.5]
policy-cc-header
=
prefix `-Policy-CC: ` 1#directive
[2.6]
directive
=
expires-directive | 
max-age-directive | 
no-cache-directive | 
s-max-age-directive 
[2.7]
expires-directive
=
`expires="` HTTP-date `"`
[2.8]
max-age-directive
=
`max-age=` delta-seconds
[2.9]
no-cache-directive
=
`no-cache`
[2.10]
s-max-age-directive
=
`s-max-age=` delta-seconds
ここで、URIはRFC 2396 [URI]に準拠して定義されています。prefixは[HTTP-EXT]に一致する、メッセージ内のP3Pヘッダ用に選択された2桁のネーム空間宣言です。HTTP-dateと delta-secondsは[HTTP1.1]内に定義されています。

他のHTTPヘッダ規則に従って、このヘッダのPolicy-CC部分は大文字/小文字の区別なしに記述されるでしょう。

指定子の意味:

expires
与えられたHTTP-dateは、ポリシー参照のための絶対有効期限を指定します。もしこの日付が過去のものであったり、値が"0"であった場合、この応答の受領者は、キャッシュ指定子が指定されていないものとして取り扱わなければなりません。HTTP-date部分はスペースを含んでいる物として考えられなければなりません。
max-age
指定された時間(秒)の間プライバシーポリシーの参照が可能です。従って、ユーザエージェントは、応答ヘッダ内で参照されたプライバシーポリシーは、指定された期間有効であると仮定しなければなりません
no-cache
ポリシー参照は、単一利用者または複数の利用者によってキャッシュされてはなりません。
s-max-age
この指定子はmax-ageと同じ意味を持っていますが、共有キャッシュによってのみ使用されます。単一利用者はこの指定子を無視しなければなりません

max-ageとs-max-age指定子が指定されている場合、単一利用者のキャッシュはmax-age によって指定されている有効期限を使用し、s-max-age指定子を無視するべきです。共有キャッシュはmax-age指定子を無視しなければならず、s-max-age指定子で指定されている値を使用するべきです

max-age指定子のみが指定されている場合、共有または単一利用者のキャッシュは指定されている有効期限を使用するべきです。

s-max-age指定子のみが指定されている場合、共有キャッシュは指定されている有効期限を使用するべきです。単一利用者のキャッシュはこの指定子をno-cache 指定子が指定されているとして取り扱わなければなりません

expiresやno-cacheに加えてmax-ageやs-max-age指定子を指定する事は誤りで、ユーザエージェントはこれらをno-cache指定子のみが指定されているとして取り扱わなければなりません

2.4.2.3 間接ポリシー参照のキャッシュ有効期限表記

サービスは、間接ポリシー参照のキャッシュ有効期限を指定することによって、どれくらいの期間、間接参照がプライバシーポリシーを参照するかを指定してもよいでしょう。 この情報によってユーザエージェントは、キャッシュの有効期限の間、間接ポリシー参照を再び行う必要がありません。

サービスは[HTTP1.1]で指定されている様に、302応答に ExpiresまたはCache-Control HTTPヘッダを追加することによって、間接ポリシー参照の有効期限を指定してもよいでしょう。

サービスは間接ポリシー参照を行う場合にPolicy-CCヘッダを使用してはいけません。(このヘッダは直接参照を行う場合のみに使用されます)

2.4.3 キャッシュ有効期限の規定値

プライバシーポリシー文書のキャッシュ有効期限の規定値は、HTTP仕様書によって決定されています。

直接ポリシー参照の有効期限の規定値は24時間です。言い換えると、もしPolicy-CCヘッダがポリシーヘッダと共に指定されていない場合、ユーザエージェントは応答にxx-Policy-CC: max-age=86400ヘッダが含まれているとして振舞わなければなりません。(xxはネーム空間)

間接ポリシー参照の有効期限の規定値は0秒です。この規定値はP3Pの総体的見地から見て理想的ではありませんが、HTTP1.1の302応答の定義のために必要とされます。サーバは間接参照のキャッシュを許可するために、間接ポリシー参照の応答にExpires またはCache-Controlヘッダを指定しなければなりません。ユーザエージェントは適切なHTTPヘッダによってキャッシュを行う許可を得られない限り、間接ポリシー参照をキャッシュしてはいけません。

2.5 追加要求事項

2.5.1 セーフゾーン

P3Pを利用可能な全てのユーザエージェントとサービスは、P3Pプライバシーポリシーを取得する行為の一部として行われる全ての通信は、そこにおいては最小限のデータ収集のみ行い、収集したデータを個人識別不可能な方法でのみ使用することを意味する特別な“セーフゾーン”の一部であることを保証するべきです。

このセーフゾーンをサポートするために、P3Pユーザエージェントはサイトのプライバシーポリシーが取得されるまで、サイトのプライバシーポリシーを発見する目的に不必要なデータの送信を控えるべきです。従ってユーザエージェントはP3Pプライバシーポリシーを要求する間、 HTTPのRefererヘッダ、クッキー、またはユーザエージェント情報を送信するべきではありません。

加えてP3Pユーザエージェントは、他の要求を行う前に適切なプライバシーポリシーのある場所を知るために、サイトに対しHEAD要求を送信してもよいでしょう。この方法はデータの送信を必要とする要求を行う事なしに、サイトのプライバシーポリシーを取得するのに有効です。

サーバはプライバシーポリシーを提供するために、HTTP Refererヘッダや、クッキー、ユーザエージェント情報、要求に対する応答に不必要なその他の情報の受領を要求するべきではありません。 加えてサーバは、プライバシーポリシーを提供している間や、HEAD要求に応答している間に収集した全ての情報を、個人を認識可能な用途で使用するべきではありません。

サーバは、P3Pプライバシーポリシーが要求された時に、応答ヘッダ内にPolicy ヘッダを含んで応答してもよい。しかしPolicyヘッダは無視されなければならない事に注意することが重要で、上記で説明された“セーフゾーン”の要求事項が代わりに用いられます。この様な場合にPolicyヘッダを返すことは、管理者がサーバ上にある全ての文書に対して一つのP3Pプライバシーポリシーを簡単に適用させることができ、かつPolicyヘッダなしにプライバシーポリシーを要求することがサイトの管理者の負担を増加させるかもしれない事情に鑑みて許可されることである。

2.5.2 プライバシーポリシーの非差別化

サーバ側に対して3つの重要な追加要求があります:

全ての要求に対してプライバシーポリシーを参照すること:
P3Pに準拠したサーバは、適切なプライバシーポリシーが利用可能である場合に、Webリソースに対するプライバシーポリシーへの参照を含むべきです。
HTTP HEAD 要求のサポート
P3Pに準拠したサーバは、GET要求によって取得できる全ての文書のためにHEAD 要求をサポートするべきです。なお、技術的に実行可能な場合は、サーバは通常、他のHTTPメソッド(POSTなど)によってアクセス可能である文書のために、HEAD 要求に対しての有効な応答を提供しなければなりません。
ページへのアクセスに使用されたHTTPメソッドに関係なく同一のプライバシーポリシーを参照すること:
P3Pに準拠したサーバは、特定のページにアクセスするために、どのHTTPメソッドが使用されたかによって、プライバシーポリシーを区別するべきではありません。

2.5.3 プライバシーポリシーの送信に関するセキュリティ

P3PポリシーとP3Pポリシーへの参照内に、いかなる機密情報をも含むべきではありません。この事は、P3Pプライバシーポリシーが関連付けられた文書の要求事項の枠を超えて、 P3Pプライバシーポリシーへの参照を送信する事に関するセキュリティーの追加要求事項が無いことを意味します。従って、通常HTML文書が暗号化なしのセッシションを通して提供されている場合、P3Pプロトコルは、文書に含まれているP3Pプライバシーポリシーを参照する時に、暗号化されたセッションを通して文書が提供されることを要求しません

3. プライバシーポリシーのシンタックスとセマンティクス

3.1節では、自然言語で書かれたプライバシーポリシーとそれに対応するP3Pポリシーの実例を挙げる。P3Pポリシーの中には、プライバシーポリシー全体に適用される全般的な主張と、参照データにおいて言及された特定のデータ型の取扱いのみに適用される特定の主張(これをステートメントと呼ぶ)とがある。 3.2節では、policy要素とポリシーレベルの主張について説明する。3.3節ではステートメントと参照データについて説明する。

以下の節では、XML要素を紹介していく。各要素は <>ブランケット (例えば、<POLICY>)で表記され、その後に有効な属性がリストアップされる。「必須の属性」と付記された属性以外は、全てオプショナルな属性である。

3.1 プライバシーポリシー例

3.1.1 自然言語プライバシーポリシー

以下の文章は自然言語で書かれたプライバシーポリシーの一例である。後節で、このプライバシーポリシーをP3P ポリシーにコード化する。

クールカタログ(住所は123 Main Street, Bethesda, MD 20814, USA)のhttp://www.TheCoolCatalog.com/catalog/というWebページに対するステートメントは下記の通りです。当サイトはPrivacySeal.orgが発行するプライバシーシールを取得しています。当サイトのプライバシーポリシーはhttp://www.TheCoolCatalog.com/PrivacyPractice.htmlに掲示されています。当サイトは本人情報に対する開示要求に応じません。

当サイトは、カタログのトップページをカスタマイズする目的と調査と商品開発の目的で、クッキーを利用し、また、利用者の性別、衣服の嗜好、(オプショナルで)自宅の住所を収集しています。当サイトはこれらの情報を無期限に保有します。

当サイトはhttp://www.TheCoolCatalog.com/catalog/というWebページの訪問に関する情報および訪問者が利用したブラウザの種類を含むサーバログを保有します。当サイトはこれらの情報をWebサイトの管理と改善の目的で利用します。当サイトはこれらの情報を無期限に保有します。

P3P要素と属性名を用いた、より正式な記述は以下の通りである。

組織(Entity):クールカタログ(住所は123 Main Street, Bethesda, MD 20814, USA)

係争解決(Disputes):
 係争解決タイプ:独立機関(independent)
 サービス:http://www.privacyseal.org
 表記:PrivacySeal.org

情報公開(Disclosure):
 情報公開URI:http://www.TheCoolCatalog.com/PrivacyPractice.html
 個人特定情報へのアクセス:なし(none)

当組織が集めるかもしれない情報:
 dynamic.cookies (category = state)
 user.gender
 dynamic.miscdata (category = pref)
 user.home. (optional)
目的:Webサイトの利用者向けカスタマイズ、調査と開発
保有期間:無期限
受領者:当組織および当組織の業務委託先
情報を提供した場合の結果:利用者に適合した衣服を提供するサイト

当組織が集める情報:
    dynamic.clickstream.server
    dynamic.http.useragent
目的:Webサイトとシステムの管理、調査と開発
保有期間:無期限
受領者:当組織および当組織の業務委託先

3.1.2 プライバシーポリシーのXMLコード化

以下の[XML] 文書は上記の自然言語プライバシーポリシーをXMLで表現したものである。P3Pポリシーは、XML.によって正確に表現されたステートメントのことである。P3Pポリシーのシンタックスについては、後節でより詳細に説明する。

例3.1

<POLICY xmlns="http://www.w3.org/2000/P3Pv1"
   entity="TheCoolCatalog, 123 Main Street, Bethesda, MD 20814, USA">
  <DISPUTES-GROUP>
 	<DISPUTES resolution-type="independent" 
  	service="http://www.PrivacySeal.org" 
  	description="PrivacySeal.org"
	  image="http://www.PrivacySeal.org/Logo.gif"/>
  </DISPUTES-GROUP>
  <DISCLOSURE 
   discuri="http://www.TheCoolCatalog.com/PrivacyPractice.html" 
   access="none"/>
  <STATEMENT>
	 <CONSEQUENCE-GROUP>
	   <CONSEQUENCE>a site with clothes you would appreciate</CONSEQUENCE>
	 </CONSEQUENCE-GROUP>
	 <RECIPIENT><ours/>/RECIPIENT>
	 <PURPOSE><custom/><develop/></PURPOSE>
	 <RETENTION><indefinitely/></RETENTION>
     <DATA-GROUP>
       <DATA name="dynamic.cookies" category="state"/>
       <DATA name="dynamic.miscdata" category="preference"/>
       <DATA name="user.gender"/>
       <DATA name="user.home." optional="yes"/>
     </DATA-GROUP>
  </STATEMENT>
  <STATEMENT>
	<RECIPIENT><ours/></RECIPIENT>
	<PURPOSE><admin/><develop/></PURPOSE>
	<RETENTION><indefinitely/></RETENTION>
    <DATA-GROUP>
      <DATA name="dynamic.clickstream.server"/>
      <DATA name="dynamic.http.useragent"/>
    </DATA-GROUP>
  </STATEMENT>
</POLICY>

3.2 P3Pポリシー

本節では、P3Pポリシーのシンタックスとセマンティクスを定義する。全てのP3Pポリシーは[UTF-8]を用いて表現される。P3Pサーバはこのシンタックスを用いて自らの P3Pポリシーを表現しなければならない。 P3Pユーザエージェントはこのシンタックスを解析できなければならない

3.2.1 POLICY要素

POLICY要素(ポリシー要素)には、完全なP3Pポリシーが含まれる。各P3Pポリシーには、一つのPOLICY要素が正しく含まれなければならないPOLICY要素には、そのポリシーに含まれるプライバシープラクティスの代表者となる法人組織を識別するような組織属性が含まれなければならない。さらに、POLICY要素にはDISCLOSURE要素(情報公開要素)、少なくとも一つのSTATEMENT要素(ステートメント要素)が含まれなければならない。また、オプショナルなものとして DISPUTES-GROUP要素(係争解決グループ要素)、その他一つ以上のextension(拡張)が含まれてもよい。

<POLICY>
一つ以上のステートメントを含む。各ステートメントは一組のデータ要素に適用される一組のDISCLOSURE要素を含む。
 
entity必須の属性
P3Pポリシーに含まれるプライバシープラクティスの主体となる法人組織の名称と問い合わせ情報。組織要素には、法人組織の名称と、プライバシーポリシーに関して組織と連絡を取るために用いられる問い合わせ情報(住所、電話番号、電子メールアドレス、またはその他の情報)が含まれなければならない。法律や行動規範によっては、問い合わせ情報の中に組織の住所やその他の特定情報を含むように要求している場合があるので、注意すること。

[3.1]
policy
=
`<POLICY xmlns="http://www.w3.org/2000/P3Pv1"` 
" entity=" quoted-string 
">"
disclosure
[disputes-group]
1*statement-block 
*extension
`</POLICY>`
[3.2]
quoted-URI
=
`"` URI `"`
ここではURIはRFC 2396 [URI]によって定義される。

3.2.2 DISCLOSURE要素

DISCLOSURE要素(情報公開要素)には、いくつかの一般的なプライバシー情報公開が含まれる。情報公開要素には、人間が読むことのできるプライバシーポリシーの URIを表示するdiscuri属性と、様々な情報へのアクセスを提供しているか否かを表示するaccess属性とが含まれる。

<DISCLOSURE>
サービスのアクセス可能性、サービスが収集したデータについての同意変更(オプトアウト)に 関する情報公開を行うか否かのバイナリー値、およびデータの保有期間に関する簡潔な情報公開。
discuri 必須の属性
自然言語のプライバシーポリシーステートメントのURI。このプライバシーポリシーステート メントには、サービスに対して質問や苦情がある場合の連絡方法についての情報が含まれるべきである。
access 必須の属性
個人識別可能情報を本人が閲覧し、サービス提供者に対して質問や苦情を表明することができるか 否か。サービス提供者はaccess属性において一つの値を公開しなければならない。アクセス手段は 特定しない。利用者のアクセスが可能な値が公開されている場合、全てのデータへのアクセスが可能であることは意味せず、 アクセスが可能なデータがあること、また、どのようなデータにアクセスできるのか利用者はサービス提供者にさらに 確認するべきであることを意味している。
サービス提供者は、discuriで示されたWeb以外の手段で収集された情報にアクセス する許可を与えてもよい。しかし、P3Pステートメントが扱う範囲はHTTPまたは他のWeb転送プロトコルを通して収集される データに限られる。また、アクセスがWeb経由で提供される場合は、セキュリティの問題は本文書の 範囲外ではあるが、そのようなアクセスのために強固な認証とセキュリティメカニズムを使用することを推奨する。
 
access属性として以下の6つの有効な値がある:
個人識別可能データは利用していない [nonident]
個人識別可能な連絡先情報 [contact]
個人識別可能なオンライン連絡先情報と個人識別可能な実世界での連絡先情報へのアクセスが 提供されている(例えば、利用者は住所などの情報にアクセスすることができる) 。
その他の個人識別可能情報 [other_ident]
特定個人と結びついたその他の情報へのアクセスが提供されている(例えば、利用者は自分に課金された利用料などの情報にアクセスすることができる)。
個人識別可能な連絡先情報とその他の個人識別可能情報[contact_and_other]
個人識別可能なオンライン連絡先情報、個人識別可能な実世界における連絡先情報、および特定個人と結びついたその他の情報へのアクセスが提供されている。
全ての個人識別可能情報[all]
全ての個人識別可能情報へのアクセスが提供されている。
なし[none]
個人識別可能情報へのアクセスは提供していない。
[3.3]
disclosure
=
"<DISCLOSURE"
" discuri=" quoted-URI
" access=" `"` access-disclosure `"`
"/>"
[3.4]
access-disclosure
=
"nonident" | ; Identifiable Data is Not Used
"contact"  | ; Identifiable Contact Information
"other"	| ; Other Identifiable Information
"contact_and_other" | ; Identifiable and
			   Other Contact Information
"all"	  | ; All Identifiable Information
"none"	   ; None

3.2.3 DISPUTES要素

P3Pポリシーは、一つ以上の DISPUTES要素(係争解決要素)から成る、 DISPUTES-GROUP要素(係争解決グループ要素)を含むべきである。 DISPUTES 要素は、サービスのプライバシープラクティスに関して係争が生じた際に行われる係争解決手続きを記述している。

<DISPUTES>
サービスのプライバシープラクティスに関して係争が生じた際に 行われる係争解決手続きを記述している。
係争 解決タイプ
以下の4つの値から一つを選ぶ:
顧客窓口: [service]
利用者は、収集されたデータの利用に関する係争の解決のために、Webサイトの顧客窓口の 代表者に申し立てることができる。
独立機関:[independent]
利用者は、収集されたデータの利用に関する係争解決のために、ある独立機関に申し立てる ことができる。記述の中にはその第三者機関への連絡方法に関する情報が含まれなければならない
裁判所:[court]
利用者は、Webサイトを告訴することができる。
適用可能な法律: [law]
プライバシーステートメントに関連した係争については、 ステートメントにおいて参照された法律によって解決がなされる。
サービス
顧客窓口のWebページや独立機関のURI、または関連する裁判所や適用可能な法律に関する情報を載せている URI
表記
人間が読むことのできる表記;これには、適切な裁判所、適用可能な法律、または第三者機関の名称が 含まれるべきである;または(既に上記「サービス」で提供されていない場合には)顧客窓口の問い合わせ情報が含まれる べきである。
イメージ
イメージロゴ(例えば、独立機関または関連する裁判所のイメージロゴ)のURI
イメージロゴのピクセル幅
高さ
イメージロゴのピクセル高
代替テキスト
イメージロゴに代わる短いテキスト
[6]
assurance-group
=
"<DISPUTES-GROUP>"
*dispute
"</DISPUTES-GROUP>"
[7]
dispute
=
"<DISPUTES"
 " disputes-type=" '"'("serivice"|"independent"|"court"|"law")'"'
 " service=" quoted-URI
 [" description=" quoted-string]
 [" image=" quoted-URI
 [" width=" `"` number `"`]
 [" height=" `"` number `"`]
 [" alt=" quoted-string]
"/>"
[8]
quoted-string
=
`"` string `"`
ここでは、文字列は[UTF-8] 文字列(" と& escapedを含む)として定義される。

サービスは複数の保証サービスを持つことができ、それらはDISPUTES-GROUP要素に含まれる 複数のDISPUTES要素の記載を通して特定できることに注意すること。ある組織のプライバシープラクティスが自組織内で保証されたり、第三者機関によて監査されたり、または法的な監督機関の管轄下にあったりすることを説明することによって、このDISPUTES-GROUP要素のフィールドが様々な方法で使用されることを期待する。

3.3 ステートメント

ステートメントは、特定のデータの型に適用されるデータプラクティスを説明する。

3.3.1 STATEMENT要素

STATEMENT要素(ステートメント要素)は、PURPOSE要素(目的要素)、RECIPIENT 要素(受領者要素)、DATA-GROUP要素(データグループ要素)、オプショナルなものとしてCONSEQUENCE-GROUP 要素(結果グループ要素)と一つ以上の拡張を束ねたものである。DATA-GROUP要素で参照された全てのデータは、ステートメントに含まれたその他の要素から成る情報公開に従って取り扱われる。このように、サイトは同じ方法で取り扱われる要素をグループ化し、各グループに対してステートメントを作成することができる。サイトが収集するデータの種類に合わせて個々の目的とその他の情報を公開したい場合は、各データ要素に合わせて別々のステートメントを作成することによって、そのような公開を行うことができる。

<STATEMENT>
データ要素に適用されるデータプラクティス。
[9]
statement-block
"<STATEMENT>"
[consequence-group]
purpose
recipient
retention
data-group
*extension
"</STATEMENT>"

プラクティスの宣言を簡潔化するために、サービス提供者はデータ要素に関するステートメント内で情報公開(目的、受領者、個人識別可能な利用)を集合化することができる。サービス提供者は、このような集合化は付加的な作業として行わなければならない。例えば、利用者の年齢は「当組織および当組織の業務委託先」に提供するが、利用者の郵便番号は「当組織と無関係な第三者」に提供するようなサイトは、利用者の名前と郵便番号を「当組織および当組織の業務委託先」および「当組織と無関係な第三者」に提供すると表明してもよい。そのようなステートメントでは、実際に行っている以上に多くのデータを第三者に提供しているように見える。自サイトの情報公開を詳細なものとするか簡潔なものとするかどうかを決定するのは、サービス提供者次第である。

また、サービス提供者は常に、適用される全てのオプションを公開しなければならない。例えば、「サービスまたは製品のマーケティングのためにサイト訪問者と連絡をとる」という目的のみで情報を収集するサイトを考えてみる。サイトがこの「サービスまたは製品のマーケティングのためにサイト訪問者と連絡をとる」ことを「現在の活動の遂行とサポート」の目的によるものだとみなしている場合でも、サイトは両方の目的を表明しなければならない。情報を「サービスまたは製品のマーケティングのためにサイト訪問者と連絡をとる」目的で「当サイトおよび当サイトの業務委託先」に提供し、「現在の活動の遂行とサポート」の目的で「公のフォーラム」に提供するサイトは、「当サイトおよび当サイトの業務委託先」と「公のフォーラム」の両方の受領者を表明しなければならない。

3.3.2 CONSEQUENCE要素

STATEMENT要素(ステートメント要素)には、一つ以上のCONSEQUENCE要素(結果要素)が含まれるCONSEQUENCE-GROUP要素(結果グループ要素)をオプションとして含めてもよい。CONSEQUENCE 要素は、利用者に対し、サイトのプラクティスに関して追加的な説明を与えるために示されるものである。

<CONSEQUENCE>
結果(consequense)とは、サイトが提示するプラクティスが(利用者が通常はそのプラクティスを許可しない 場合であれ)、ある特別な場合になぜ価値があるのかを利用者に説明するために示されるものである。
xml:lang
結果の表記に用いる言語

複数の結果は、複数のCONSEQUENCE要素を用いて提示することができ、このCONSEQUENCE要素は各々それらの結果の一つを表すものである。また、xml:lang 属性を用いて、結果を多言語でコード化することができる。異なる言語の2つの結果が示されている場合、それらは同じ意味でなければならない
[10]
consequence-group
"<CONSEQUENCE-GROUP>" 
*consequence
"</CONSEQUENCE-GROUP>"
[11]
consequence
"<CONSEQUENCE" [" xml:lang=" LanguageID ] ">" 
PCDATA
"</CONSEQUENCE>"

xml:langとその価値の型であるLanguageIDは、PCDATAと同様に、 [XML]の仕様書で定義されている。

3.3.3 PURPOSE要素

STATEMENT要素(ステートメント要素)には、一つ以上のデータ収集目的またはデータ利用目的を含む PURPOSE要素(目的要素)が含まれなければならない。サイトは自らのデータプラクティスを、8つの特定化された目的のうちの一つ以上の目的に分類しなければならない

<PURPOSE>
Webサイトに関連したデータ処理の目的

PURPOSE要素には、以下の目的の中から一つ以上が含まれなければならない

<current/>
現在の活動の遂行とサポート:情報は、情報提供や通信、双方向サービスなど、利用者が そのために情報を与えたところの活動を遂行するために、サービス提供者によって利用されるかもしれない。 例えば、Web検索の結果の返信、電子メールの送信、商品の注文など。
<admin/>
Webサイトとシステムの管理:情報は、Webサイトとそのコンピュータシステムの技術サポートの ために利用されるかもしれない。この中には、コンピュータアカウント情報の処理や、サイトの保守管理の過程で 利用される情報の処理が含まれる。
<research/>
調査と開発:情報は、サイトやサービス、商品、マーケットを改善したり、評価したり、 検討したりするために利用されるかもしれない。この中には、特定個人に合わせてコンテンツを変更するために 個人情報を利用することや、特定個人を評価したり、ターゲットとしたり、プロファイルしたり、また特定個人と 連絡をとったりするために個人情報を利用することは含まれない。
<contact/>
サービスまたは商品のマーケティングのためにサイト訪問者と連絡をとる:情報は、商品や サービスの販売促進のために個人と連絡をとる目的で利用されるかもしれない。この中には、Webサイトの更新を 訪問者に通知することも含まれる。
<customization/>
肯定的なカスタマイズ:情報は、サイトへの1回または複数回の訪問を通じて、特定個人に よって肯定的に選択された仕様に合わせてサイトのコンテンツやデザインを変更するために利用されるかもしれない。 例えば、利用者にいくつかの株式銘柄を選択させ、利用者の訪問時にそれらの現在の株価を表示する金融サイトなど。
<targeting/>
その場限りのターゲット化:情報は、サイトへの1回の訪問のみで利用され、その後のいかなる カスタマイズにも利用されない情報として、特定個人によって肯定的に選択されていない形でサイトのコンテンツや デザインを変更するために利用されるかもしれない。例えば、訪問者が買い物かごに入れた商品にもとづいて、彼が その他に購入したいであろう商品を提案するオンラインショップなど。
<profiling/>
個人のプロファイリング:情報は、特定個人または特定コンピュータの習性や個人識別可能情報を 編集する目的で、その個人またはコンピュータに関する記録を作成するために利用されるかもしれない。例えば、 訪問者がこれまでにサイトで購入した商品にもとづいて、彼が購入したいであろう商品を提案するオンラインショップなど。
<other [xml:lang=language] > string </other>
その他の利用:情報は、上記の定義には当てはまらない方法で利用されるかもしれない。 (この場合、人間が読むことのできる説明を与えるべきである。)この説明においては、xml:lang タグによって、複数の言語を用いることができる。

各々の目的には、以下のオプショナルな属性を付加することができる:

change_preferences
サイトが個人に対して特定の目的に関する彼らのプリファレンスの変更を許可するか否か。規定値は「いいえ」である。「はい」の値が用いられた場合、サイトは個人に対して自分のデータをその目的では利用しないように要求するメカニズムを提供していることになる。このメカニズムの利用方法に関する情報はdiscuriの中に含まれなければならない。
[5]
yesno
=
"yes" | "no"
[12]
purpose
"<PURPOSE>" 
1*purposevalue "</PURPOSE>"
[13]
purposevalue
=
"<current" [change] "/>" | ; Completion and Support of Current Activity
"<admin" [change]   "/>" | ; Web Site and System Administration
"<develop" [change] "/>" | ; Research and Development
"<contact" [change] "/>" | ; Contacting Visitors for Marketing of Services or Products
"<customization" [change] "/>" | ; Affirmative Customization
"<targeting" [change] "/>"  | ; One-time Targeting
"<profiling" [change] "/>"  | ; Individual Profiling
"<other" [change] [" xml:lang=" LanguageID] >" PCDATA "</other>"; Other Uses
[14]
change
=
" change_preferences=" `"` yesno `"`

xml:langとその価値の型であるLanguageIDは、PCDATAと同様に、 [XML]の仕様書で定義されている。

サービス提供者は上記の要素をデータ収集の目的を説明するために用いなければならない。サービス提供者は適用される全ての目的を公開しなければならない。サービス提供者があるデータ要素をある目的で利用することを公開しなかった場合、そのことはデータをその目的では利用しないということを意味している。「その他の利用」の目的でデータを利用すると公開したサービス提供者は、の目的に関して人間が読むことのできる説明を与えなければならない

ワーキンググループは、サイトが実行するかもしれない目的と実行することになっている 目的との区別をサイトに許可することの可能性を、長時間議論してきた。ワーキンググループの総評は、そのような区別は必ずしも必要ないというものであった。しかし、この結論に同意しない何人かのメンバーは以下のように述べている:

ボキャブラリにおける応答の選択肢としては、「はい」、「いいえ」、および「かもしれない(may)」の 全てが必要である。もし選択肢が「いいえ」と「かもしれない」しかなかったならば、「かもしれない」の 意味は「はい」に等しいということになり、意味の乱れが生じてしまう。「かもしれない」はその真の意味 (「はい」または「いいえ」)を反映した一つの選択肢でなければならない。もし「かもしれない」が デフォルトとして「はい」を意味しているとしたら、「はい」は応答の選択肢に含まれていないため、消費者は 欺かれることになるだろう。「かもしれない」は、プライバシーポリシーを理解するために消費者が参照できるこの用語(「かもしれない」)の背後に一連の規則があることを含意するために使用されるべきである。もし「かもしれない」が「はい」を 意味するとしたら、消費者がクリックを通じてWebサイトのプライバシーポリシーを調査する可能性はもっと 低くなるだろう。この「いいえ」と「かもしれない」という一見簡素な解決策は、消費者が「いいえ」と 「かもしれない」だけに絞られた選択肢の意味において混乱をきたすので、電子商取引にとって重大な障壁と なる可能性がある。3つの選択肢全てを提供することはWebサイトの消費者を欺く企てにつながると主張する メンバーたちは、論点を外している。プライバシー保護の領域では、プライバシーポリシーを表明する際の 正確性こそが、情報の利用方法に関して消費者の信用と信頼を勝ち得るための決定的な要因なのだ。ソフトウェアの 簡潔性のために、消費者のプリファレンスの選択肢を「いいえ」と「かもしれない」に限定することは、消費者への 害悪となると同時に、プライバシーポリシーに関して消費者と正確な意思疎通を心がけているWebサイトへの害悪ともなるだろう。

3.3.4 RECIPIENT要素

STATEMENT要素(ステートメント要素)には、収集データの一つ以上の受領者を含むRECIPIENT要素(受領者要素)が含まれなければならない。サイトはデータの受領者を、6つの特定化された受領者のうちの一つ以上の受領者に分類しなければならない。

<RECIPIENT>
データを提供するかもしれないサービス提供者および当組織の業務委託先を超えた、法人組織または事業部門

RECIPIENT要素には、以下の受領者の中から一つ以上が含まれなければならない。

<ours/>
当組織および/または当組織の業務委託先:当組織およびその業務委託先。この場合、業務委託先(agent)とは、表明された目的の達成のためだけにサービス提供者に代わってデータを処理する第三者として定義される。(例えば、サービス提供者とその印刷事務所。ただし、印刷事務所は住所ラベルを印刷し、それ以上は情報に関わりを持たない。)
<same/>
当組織のプラクティスに従う法人組織:サービス提供者と等価なプラクティスの下で、自らのためにデータを利用する法人組織。(例えば、収集した個人情報へのアクセスを利用者に提供し、かつ、提供された個人情報を一度利用するが保有せずに破棄してまうパートナー企業に個人情報を提供するサービス提供者を考えてみる。サービス提供者と同様なプラクティスに従う受領者は、個人情報を破棄するため個人情報へのアクセスを利用者に提供できないので、受領者はサービス提供者と同等なプラクティスに従っているとみなされる。)
<other/>
当組織とは異なるプラクティスに従う法人組織:サービス提供者の制約を受け、サービス提供者に対して責任を負うが、サービス提供者のプラクティスにおいては特定されない方法でデータを利用するかもしれない法人組織。(例えば、サービス提供者が収集したデータを、その他の目的で利用するかもしれないパートナー企業に提供する場合。しかし、利用者の利益とサービス提供者の利益への侵害と考えられるような方法でデータが利用されないことを保証することが、サービス提供者の利益となるような場合。)
<delivery/>
当組織とは異なるプラクティスに従う可能性のある配送サービス:サービス提供者のプライバシーポリシーにおいて表明された目的の遂行以外の目的でデータを利用するかもしれない、配送サービスを行う法人組織。
<public/>
公のフォーラム:公のフォーラム。掲示版、公のディレクトリ、または商用CD-ROMのディレクトリなど。
<unrelated/>
当組織と無関係な第三者:サービス提供者がそのデータ利用プラクティスについて関知しないような法人組織。
[14]
recipient
"<RECIPIENT>" 1*recipientvalue "</RECIPIENT>"
[15]
recipientvalue
"<ours/>"	 |  ; only ourselves and our agents
"<same/>"	 |  ; legal entities following our practices
"<other/>"	|  ; legal entities following different practices
"<delivery/>" |  ; delivery services following different practices
"<public/>"   |  ; public fora
"<unrelated/>"   ; unrelated third parties

サービス提供者は適合する全ての受領者を公開しなければならない。ただし、上記の6つの受領者のセットでは、データの全ての受領者が完全には表示されない場合があることに注意すること。例えば、運送業者や決済業者は、取引活動を遂行し支援するために必要であるが、異なるプラクティスに従う場合もあり、このような業務処理促進業者に関する点が問題になっていた。現在のところ、明示的にポリシー内に示すことができるのは配送サービスだけである。その他の業務処理促進業者については、元のサービス提供者との関係において彼らのプラクティスを最も正確に反映しているカテゴリにおいて表明されなければならない。ワーキンググループは配送サービスに対して特別の区分を設けることにしたが、(銀行やクレジットカード会社のような)決済業者に対しては以下のような理由でそのような措置をとらなかった:金融機関は、典型的に、金融データの使用に関して顧客と個々に合意している一方で、配送サービスの受領者はたいてい、配送サービスのプライバシーポリシーを検討する機会をもたないためである。

<delivery/>要素は、配送を遂行するためにサービス提供者の代行としてのみデータを使用することに同意している配送サービスに対して使われるべきではないことに注意すること。

3.3.5 RETENTION要素

STATEMENT要素(ステートメント要素)には、そのステートメントで参照されたデータに当てはまる保有ポリシーを示すRETENTION要素(保有要素)が含まれなければならない

<RETENTION>
有効な保有ポリシーのタイプ

RETENTION要素には、以下のうちの1つが含まれなければならない:

<no-retention/>
情報は 、オンラインでの1回のインタラクションにおいてその情報を利用するのに必要な短い時間以上は保有されない。情報はこのインタラクションの後は消去されなければならず、ログとして記録されたり、履歴として残されたり、その他の方法で保存されたりしてはならない。このタイプの保有ポリシーは、例えば、Webサーバのログを取らないサービスや、1回のセッションで使用するためだけにクッキーを設定するサービス、Web検索を行うために情報を収集するが検索に関するログは取らないサービスなどに当てはまるだろう。
 
<stated-purpose/>
言明された目的のための保有:情報は言明された目的をかなえるために保有される。これは、情報ができるだけ早期に破棄されることを要求するものである。サイトは、データ消去のタイムテーブルを設定した保有ポリシーを持た なければならない。保有ポリシーは、サイトの人間が読むことのできるプライバシーポリシーに含まれるか、またはそこからリンクが張られてい なければならない
 
 
<legal-requirement/>
法律または適用可能な法律に基づく責務による要求:情報は、言明された目的をかなえるために保有されるが、その保有期間は、法律上の要求または責務によってそれよりも長い場合がある。例えば、消費者が一定期間の間、取引に対して異議申立てを行うことが法律によって認められているため、企業は責務上の理由によりその取引記録を保持しようとするかもしれない。また、企業が監査上の目的あるいは健全性の目的で記録を保持することが、法律によって肯定的に要求されているかもしれない。サイトはデータ消去のタイムテーブルを設定した保有ポリシーを持たなければならない。保有ポリシーは、サイトの人間が読むことのできるプライバシーポリシーに含まれるか、またはそこからリンクが張られていなければならない
 
    
<indefinitely/>
無期限:情報は、無期限に保有される。これは、保有ポリシーがない場合に起こるかもしれない。受領者が公のフォーラムである場合は、これが適切な保有ポリシーである。
 
    
<business-practices/>
サービス提供者の業務プラクティスによる決定:情報は、サービス提供者の言明した業務プラクティスに従って保有される。サイトはデータ消去のタイムテーブルを設定した保有ポリシーを持たなければならない。保有ポリシーは、サイトの人間が読むことのできるプライバシーポリシーに含まれるか、またはそこからリンクが張られていなければならない
 
[14]
retention
"<RETENTION>" retentionvalue "</RETENTION>"
[15]
retentionvalue
"<no-retention/>"	   | ; not retained
"<stated-purpose/>"	 | ; for the stated purpose
"<legal-requirement/>"  | ; stated purpose by law
"<indefinitely/>"	   | ; indeterminated period of time
"<business-practices/>"   ; by business practices

3.3.6 データ要素

STATEMENT要素(ステートメント要素)には、1つ以上のデータ要素を含むDATA-GROUP要素(データグループ要素)が含まれなければならない。データ要素は、サイトが収集するデータのタイプを説明するために使われる。

<DATA>
送信されるか、または推測されるデータを示す
    
名称(必須の属性
データ要素/集合の名称を示す文字列。集合と要素は、集合名称の後の接尾ドットの存在により、 シンタックス的に区別される。例えば、user.home.がデータ集合であることは、その接尾ドットによって 示されている。名称は活字ケース(大文字・小文字)の違いにより影響を受けることを記憶して おくこと。(例えば、user.home は USER. HOME. または User. Home.とは異なる)。 さらに、名称において、下線("_")が現れることはなく、またドットの直後に 数字が現れることはない
 
 
dataschema
データスキーマのURI;規定値はP3P基本データスキーマである。
optional
サイトがサイト訪問者に要求するデータ要素の提供が必須のものであるか否かを意味する;"no"は、そのデータ要素の提供が必須であることを意味し、"yes"はそのデータ要素の提供が必須ではないことを意味する。規定値は"no"である。このoptional属性は、プライバシーポリシーにおいてのみ使用される(データスキーマの定義においては使用されない)。P3Pは、あるデータプラクティスがオプショナルなものであることを規定するメカニズムを含んでいないことに注意すること。
 
category(カテゴリ)
データ要素のカテゴリを示す文字列。

以下の6つの属性は(P3P[Base Data Schema]では定義されていない)新たなデータ要素あるいは集合が参照された場合にのみ使用される。

type(型)
データ要素/集合のタイプを示す文字列。
 
 
typeschema(型スキーマ)
データスキーマを示すURI。このスキーマでは、属性において 規定されたタイプが定義されている。
 
template
対応するデータ要素が、ある型定義の部分にすぎないか、そうでないかを規定する。もし"yes"に 設定されれば、そのデータ要素は一つの型定義であり、関連した値をもつデータ要素を実際には表していない。 規定値は"no"である。
 
short
データ要素/集合の簡易表記名を示す文字列。[UTF-8] 文字の数は127以下。
 
long
データ要素/集合のより長い説明を示す文字列。[UTF-8] 文字の数は1023以下。
size
データ要素を保存するのに必要とされる[UTF-8]文字の最大数を示す。0の規定値は、データ要素が任意に大きくなってもよいことを意味している。
 
[16] 
data-group
=
"<DATA-GROUP>"
*data-reference
"</DATA-GROUP>"
[17] 
data-reference
=
"<DATA name=" quoted-string 
[" dataschema=" quoted-string] [" optional=" yesno]
[" type=" quoted-string] [" typeschema=" quoted-string] 
[" template=" yesno] [" category=" category] 
[" short=" quoted-string] [" long=" quoted-string]
[" size=" `"` number `"`] ; default is 0 (unlimited size)
"/>"

例えば、利用者の住所、データ集合user.businessの全ての要素、さらに(オプショナルなものとして)データ集合user.home.phoneの全ての要素を参照するために、サービスはP3Pポリシー内に以下の参照データを記載するだろう。

<DATA-GROUP>
<DATA name="user.home.city"/>
<DATA name="user.home.phone." optional="yes"/>
<DATA name="user.business."/>
</DATA-GROUP>

3.4 カテゴリ

カテゴリとは、利用者とユーザエージェントに、意図されたデータ利用に関してヒントを提供するデータ要素の属性である。カテゴリは、P3Pユーザエージェントの実装と使用をより容易にするために不可欠である;カテゴリによって、利用者はさらに一般化されたプリファレンスやデータ交換規則を表明することができる。また、カテゴリは、新しい要素を定義づけするときや、 (ユーザデータレポジトリに保存されているデータとは対照的に)利用者にタイプ入力を促すようなデータに言及するときに伴われることが多い。

P3Pの現バージョンにおいて、データカテゴリを示すために使われている記号は以下の通りである:
[18] 
category
=
"physical"	| ; Physical Contact Information
"online"	  | ; Online Contact Information
"uniqueid"	| ; Unique Identifiers
"financial"   | ; Financial Account Identifiers
"computer"	| ; Computer Information
"navigation"  | ; Navigation and Click-stream Data
"interactive" | ; Interactive Data
"preference"		| ; Preference Data
"demographic"   | ; Demographic and Socioeconomic Data
"content"	   ; Content

実社会における連絡先情報[physical]
実社会において個人に問い合わせを行ったり、所在を突き止めることを可能にするような情報。電話番号や住所など。
 
オンライン連絡先情報 [online]
インターネット上で個人に問い合せを行ったり、所在を突き止めることを可能にするような情報。電子メールアドレスなど。この情報は、ネットワークにアクセスするときに使用される特定のコンピュータには依存しないことが多い。("Computer Information"カテゴリを参照のこと。)
 
ユニークな識別子 [uniqueid]
個人を整合的に識別するために発行された識別子。金融機関のID番号を除く。 SSN(社会保障番号)やWebサイトIDなど。
 
金融機関のID番号 [financial]
個人と金融機関、金融口座、または支払いシステムと結びつけるような識別子。クレジットカード番号や預金口座番号など。
 
コンピュータ情報 [computer]
個人がネットワークにアクセスするときに使用しているコンピュータシステムに関する情報。IPアドレスや ドメインネーム、ブラウザの種類、オペレーティングシステムなど。
 
ナビゲーションとクリックストリームのデータ [navigation]
閲覧することによって受動的に生じるデータ。訪問したページや ページごとの滞在時間など。 
 
インタラクティブデータ [interactive]
Webサイトを通じた、サービス提供者との明示的なやりとりから積極的に生じるデータ。また、そのようなやりとりを反映したデータ。検索エンジンでの検索事項やアカウント活動のログ、Web上での購買品など。
 
人口統計学的・社会経済学的データ [demographic]
個人の特徴に関する情報。 性別や年齢、収入など。
 
嗜好データ [preference]
個人の好みや嫌いなものに関するデータ。好きな色や音楽の好みなど。 
 
文章の内容 [content]
通信活動に含まれる言葉や表現。電子メールの文章や掲示板への掲示内容、またチャットルームでの通信内容など。
状態管理メカニズム [state]
利用者とのセッションを維持したり、また以前に特定サイトを訪問したことや特定コンテンツにアクセスしたことがある利用者を 自動的に識別したりするメカニズム。HTTPクッキーなど。
 
その他 [other]
上記の定義にあてはまらない他のデータ型。(この場合、人間が読むことのできる説明が提示されなければならない。)

コンピュータ情報、ナビゲーションとクリックストリームのデータ、インタラクティブデータ、文章の内容のカテゴリは、以下のように区別することができる。コンピューター情報には、IPアドレスやソフトウェア構成を含む利用者のコンピューターに関する情報が含まれる。ナビゲーションとクリックストリームのデータには、閲覧に関係した利用者の実際の行動が記述されている。閲覧行動に関係した情報を含んだログファイルの中にIPアドレスが記録されている場合には、コンピュータ情報とナビゲーションとクリックストリームのデータの両者が使用されていることになる。インタラクティブデータは、閲覧にとどまらず、サイト上で何らかの有用なサービスを提供するために積極的にサイトが求めるデータである。文章の内容は、通信目的のためにサイト上で交換される情報のことである。

Otherカテゴリは、いずれのカテゴリにも当てはまらないデータが要求される場合にのみ使われるべきである。

P3Pは、利用者とユーザエージェントに、サービスから要求される情報型に関して付加的なヒントを提供するためにカテゴリを使用する。基本データスキーマ中の大部分のデータはいずれか1つのカテゴリ(またはいくつかのカテゴリの組み合わせ)に入るが、状況次第で異なる複数のカテゴリに入る可能性のあるデータ要素もある。前者は、固定カテゴリデータ要素(あるいは、短く「固定データ要素」)と呼ばれ、後者は可変カテゴリデータ要素(「可変データ要素」)と呼ばれている。以下の2つの節で、両タイプ要素を簡単に説明する。

3.4.1 固定カテゴリデータ要素

基本データスキーマのほとんどの要素は「固定」データ要素と呼ばれる:それらは、1つかせいぜい2つのカテゴリに属している。あるカテゴリを不変的に基本データスキーマの要素に割り当てることによって、サービスと利用者は、単に対応するカテゴリを参照するだけで要素の全グループに言及することができる。例えば、利用者はプライバシープリファレンス交換言語であるAPPELを使用して、ユーザエージェントがあるカテゴリ内のどのデータ要素も提供しないようにする規則を書くことができる。

固定データ要素に対するデータスキーマを考案する際、スキーマ考案者は、それらの要素が属するカテゴリを明確に列挙しなければならない。例えば:

<DATA name="postal.street.line1"     type="text"
          short="Street Address, Line 1" category="physical" template="yes"/>

1つの要素が複数のカテゴリに属する場合、同データについて言及している複数の要素を使用することができる。この時、それぞれの要素は異なるカテゴリに属する。例えば、user.nameのデータ要素が「実社会における連絡先情報」と「人口統計学的・社会経済学的データ」の両カテゴリを含んでいることを言明したい場合、以下の要素を使用できる:

<DATA name="user.name."     type="personname."
          short="User's Name" category="physical" template="yes"/>

<DATA name="user.name."     type="personname."
          short="User's Name" category="demographic" template="yes"/>

固定データ要素のカテゴリは、変更できないことに注意すること。例えば、既存の固定基本データ要素に別のカテゴリを当てはめる規則やポリシーを書くことはできない。ユーザエージェントは、そのようなカテゴリを無視して、代わりにスキーマ定義にリストされている元のカテゴリ(あるいはカテゴリの集合)を使用しなければならない。ユーザエージェントはむしろ利用者に、固定データ要素が非標準的なカテゴリにおいて使用されることを警告してもよい

3.4.2 可変カテゴリデータ要素

基本データスキーマにおける全てのデータ要素が、予め決まったカテゴリに属するわけではない。データ要素は個々の状況によって、カテゴリ領域からの情報を含むことができる。そのような要素は可変カテゴリデータ要素(あるいは短く「可変データ要素」)と呼ばれる。P3P基本データ・スキーマにおけるほとんどの可変データ要素は、dynamic.要素集合と結びついているにもかかわらず、可変データはどのデータ集合にも現れる可能性があり、固定カテゴリデータ要素と混合しさえするかもしれない。

そのような要素に対し、スキーマ定義を考案する際、スキーマ考案者は、明確なカテゴリ属性をリストしてはならない。さもなければ、その要素は固定データ要素になる。例えば、状況次第でさまざまなカテゴリをとり得る"Year" データ型(例として、クレジットカード期限や生年月日で使用される場合など)を規定するとき、以下のスキーマ定義を使用できる:

<DATA name=" date.ymd.year" type="number" size="6"
          short="Year"     template="yes"/>  <!-- Variable Data Element -->

これによって、そのような可変カテゴリデータ型を参照する新たなスキーマ拡張は、そのスキーマ拡張における使用に従って、引き出された要素に特定のカテゴリを割り当てる。例えば、こうしてE-commerceスキーマ拡張は、クレジットカード期限を以下のように定義できる:

<DATA name=" Card.ExpDate."         type=" date.ymd."
          short="Card Expiration Date" category="
financial" template="yes"/>

このような条件の下では、可変データ型date.は、クレジットカード期限を規定するために使用されている場合、 固定カテゴリ金融機関のID番号を割り当てられる。

利用者のプリファレンスは、(可変データ要素のあらゆる使用に関するプリファレンスを効果的に表現している)付加的なカテゴリ情報なしでも、そのような可変データ要素をリストすることができるが、サービスは、自らのプライバシーポリシーにおいて、可変データ要素の使用に適用するカテゴリを必ず明確に示さなければならない。この情報はプライバシーポリシーでリストアップされたデータ要素の一つの属性として現れなければならない。

<POLICY ... >
   ...
   <DATA name="dynamic.cookies" category="uniqueid">
   ...
</POLICY>

ここでサービスは、このサイトではクッキーを利用者の識別のために(すなわち、ユニークな識別子として)使用することを表明している。

3.5 拡張メカニズム

P3Pは、MAN-EXTENSIONOPT-EXTENSIONという2つの要素を使用して、シンタックスとセマンティクスを拡張するための柔軟かつ強力なメカニズムを提供する。MAN-EXTENSION内に含まれる記述は、シンタックスの必須の拡張であって、この拡張を理解しないアプリケーションは、プライバシーポリシー全体(あるいはデータスキーマ)の意味をも理解できないということになる。 OPT-EXTENSION内に含まれる記述は、シンタックスのオプショナルな拡張であり、この拡張を理解しないアプリケーションは、それを無視しても差し支えなく、それまでと同様にプライバシーポリシー全体(あるいはデータスキーマ)を処理し続けられることを意味する。
[19] 
extension
=
mandatoryext | optionalext
[20] 
mandatoryext
=
"<MAN-EXTENSION>" PCDATA "</MAN-EXTENSION>"
[21] 
optionalext
=
"<OPT-EXTENSION>" PCDATA "</OPT-EXTENSION>"

例えば、www.TheCoolCatalog.comが、プライバシーポリシーの期限といった特徴をP3Pに加えようとする場合、次のような必須の拡張を付加してもよい。

<MAN-EXTENSION>
   <EXPIRES xmlns="http://www.TheCoolCatalog.com/P3P-extensions" 
	 date="September 02, 2000"/>
 </MAN-EXTENSION>

一方、www.TheCoolCatalog.comが、サーバの所在国を示す拡張を加えようとする場合、以下のようにオプショナルな拡張の方が適切であろう:

<OPT-EXTENSION>
   <ORIGIN xmlns="http://www.TheCoolCatalog.com/P3P-extensions" 
	 country="USA">
</OPT-EXTENSION>

xmlns属性は重要な属性である。というのは、これは、拡張に使用される要素と属性の名称を解釈するためのネーム空間を規定するからである。[XML-Name]に具体的に示されるように、ネーム空間URIが単に拡張に対する唯一の識別子であることが意図されているにすぎないことに注意すること。しかしながら、サービス提供者は対応するURI上で、拡張の説明を載せたページを提供してもよい

4. データスキーマ

P3Pでは、サービスやユーザエージェントがデータ要素を参照するための共通の方法を提供するために、データスキーマを定義することができます。データスキーマは、階層的に分類されたデータ集合内にグループ化された特定のデータ要素の一群を表します。

サービスは、データスキーマを作成し、データスキーマ属性を使用したプライバシーポリシーにおいてデータスキーマを参照することによって、データ要素を宣言し使用することができます。P3Pは、P3P基本データスキーマと呼ばれる標準のデータスキーマからなっており、このP3P基本データスキーマは一般的に使用される多種多様なデータ要素を定義しています。P3P基本データスキーマはまた、他の新規のスキーマによって簡単に再使用されることが出来る基本データ型を提供しています。

データスキーマのフォーマット:

<DATASCHEMA xmlns="http://www.w3.org/2000/P3Pv1">
<DATA-GROUP>
<DATA ... />
...
<DATA ... />
</DATA-GROUP>
</DATASCHEMA>
[22]
dataschema
=
`<DATASCHEMA xmlns="http://www.w3.org/2000/P3Pv1">`
*(data-reference|extension)
"</DATASCHEMA>"

<DATASCHEMA>要素は、新規データ要素への参照を含んでおり、そのような参照は、<DATA>タグと属性(name, type, typeschema(DATA要素のネーム空間と同じ値の場合は省略される), template, category, short, long, size)を使用することによって可能となります。

データ要素がある属性を持たない場合、その属性には規定値として空の文字列が存在するとみなされます。型スキーマ (typeschema)の場合、空の文字列は、型スキーマは対応するデータ要素のネーム空間と一致しているという特別な意味を持っています。

例えば、HyperSpeed社が以下のようなデータスキーマを構築したいと考えた場合:

vehicle.model (of primitive type text)
vehicle.color (of primitive type text)
vehicle.built.year (of primitive type number)
vehicle.built.where. (of basic type postal.)
vehicle.price (of primitive type number)
car.model (of primitive type text)
car.color (of primitive type text)
car.built.year (of primitive type number)
car.built.where. (of basic type postal.)
car.price (of primitive type number)

以下のようなコードをhttp://www.HyperSpeed.com/models-schemaに置くことができます。

<DATASCHEMA xmlns="http://www.w3.org/2000/P3Pv1">
 <DATA name="vehicle.model" type="text" short="Model" 
   category="preference" size="63"/>
 <DATA name="vehicle.color" type="text" short="Color" 
   category="preference" size="63"/>
 <DATA name="vehicle.built.year" type="number" short="Construction Year" 
   category="preference" size="63"/>
 <DATA name="vehicle.built.where." type="postal."  short="Construction Place" 
   category="preference" size="63"/>
 <DATA name="car." type="vehicle." 
   typeschema="http://www.HyperSpeed.com/models-schema"/>
</DATASCHEMA>

データスキーマが作成される度に、データスキーマは上記のvehicle.のように暗黙のうちに型として使用されることができることに注意してください。

この例では、"car model"と"construction year"を参照するために、サービスはP3Pプライバシーポリシー内部に以下の参照場所を掲載することができるでしょう:

<DATA-GROUP>
<DATA name="car.model" dataschema="http://www.HyperSpeed.com/models-schema"/>
<DATA name="car.built.year" dataschema="http://www.HyperSpeed.com/models-schema"/>
</DATA-GROUP>

データスキーマファイルの多国語サポートを提供するために、サーバはHTTP Accept-Languageヘッダに基づいた適切な代替案を提供することができます。

データ要素は、固定カテゴリに属すか属さないかに従って分類することができます(カテゴリ属性を使用して)。スキーマの設計者は、個々のデータ要素の不変カテゴリを定義するために、スキーマ定義内にカテゴリ属性を使用することができます。一旦定義されると、ユーザプリファレンス内、P3Pプライバシーポリシー、又は他のスキーマ定義から値を参照する時に、この値を変更することはできません。しかし、属性が定義されていない場合、この属性はP3Pプライバシーポリシー内部に明白にリストされていなければなりません。利用者は、異なる属性値に基づいて、同じ要素に異なるプリファレンスをもつことができます。データ内に定義されていない属性がある場合、他のスキーマ定義は、継承された要素内にカテゴリを明白に設定することができます(もしそうでない場合は、オリジナルの定義は継承されたスキーマのいかなる値にも優先します)。

基本データスキーマや拡張データスキーマ内で指定されているデータ要素名は、P3Pプライバシーポリシーの目的以外に使用されるかもしれないことに注意してください。例えば、WebサイトがHTMLのフォームフィールドをラベル付けするためにそれらの名前を使用するかもしれません。P3Pプライバシーポリシーとフォームでのデータ参照方式を同じ方式で行うためには、フォームへの自動入力ツールは、P3Pユーザエージェントと統合された方が好ましいでしょう。P3Pデータ要素名が、HTMLフォームフィールド名として使用される場合は、"."の代わりに"_"が使用されなければなりません(例:user.name.firstは、user_name_firstとして参照されなければなりません)。このことは、フォームフィールド名と値にアクセスするために"."を使用するクライアント側のjavascriptとの相互運用を可能にします。

4.1 データスキーマの不変性

P3Pプライバシーポリシーと類似して、データスキーマにおける必須の要求条件は、データスキーマの不変性です。一つの例外を除いて、特定のURIから取得されるデータスキーマが変更されることはありません。このようにして、プライバシーポリシー上のURIは、データスキーマのためのユニークな識別子として振舞います。従って、通常新規のデータスキーマは、新規の異なるURIを使用しなければなりません。この一般的な基本方針での唯一の例外は、データスキーマのために特定の言語への記号化がなされていることを適切に示すためにHTTPの"Content-Language"タグを使用するサーバによって同一のデータスキーマの多国語(翻訳)版が提供される時のみです。P3Pクライアントは、キャッシュしてあったデータスキーマ(Content-Languageがある場合は、Content-Languageを含む)と、対応する新しく取得したデータスキーマ(Content-Languageがある場合は、Content-Languageを含む)を比較することによって、データスキーマの不変性をチェックしてもよい。もしユーザエージェントが、二つのデータスキーマは異なるが、同一のURIを所有していることを発見した場合、ユーザエージェントは、そのデータスキーマがContent-Languageに二つの異なる値を持っている場合以外は、そのリソースはP3Pプライバシーポリシーを持たないとして扱わなければなりません

4.2 プリミティブデータ型

P3Pスキーマは、以下のデータ要素型を引用することができます。
プリミティブデータ型 定義
text [UTF-8]
gender "M" または "F".
boolean "false" または "true".
binary RFC-2045に準拠したBase64 [MIME]
number "0", "1", "2", "3", "4", "5", "6", "7","8", "9"で構成されるテキスト
Country [ISO3166]に準拠した2桁の国コード
uri [URI

4.3 基本データスキーマ

P3Pに準拠して実装された全てのユーザエージェントは、P3P基本データスキーマのデータ要素を処理できなければなりませんP3P基本データスキーマには、user.dynamic.の2種類の要素の集合が含まれています。user.は、利用者が値を提供するであろう要素を含み、その一方でdynamic.は、利用者のブラウザによる閲覧を通して動的に生成される要素を含みます。ユーザエージェントは、複数の人物をサポートするメカニズムを含め、利用者がuser.集合の要素に値を提供し、データレポジトリにそれらを保存することを可能にする様々なメカニズムをサポートするかもしれない。また利用者はそれらのデータ要素に値を提供しない選択を行う事もできるでしょう。

P3P基本データスキーマの正式なXML定義は、Appendix 2で提供されています。以下のセクションでは、基本データ要素と集合を一つずつ説明していきます。このワーキンググループのメンバーは、将来、新規のデータ集合と要素の作成要求があることを期待しています。カタログ、支払い、そしてエージェント/システム 属性スキーマを含むアプリケーションに関してはすでに明白です。(拡張的なシステム要素の集合例はhttp://www.w3.org/TR/NOTE-agent-attributesで提供してあります)

以下のテーブルでは、集合、集合内の要素、要素に関連するカテゴリ、型、簡易表記名が指定してあります。我々は、可能である限り、一つの基本データ要素に対して一つのカテゴリを割り当てるように努力しましたが、一つ以上のカテゴリが固定データ要素と関連付けられているものもあります。我々は、スキーマの設計者にも同じ努力を行うことを推奨します。

4.3.1 個人データ

user.データ集合は、個人に関する一般的な情報を含みます。 
user. カテゴリ 簡易表記名
name. 実社会における連絡先情報、人口統計学的・社会経済学的データ personname. 利用者名
bdate. 人口統計学的・社会経済学的データ date. 利用者の誕生日
cert. ユニークな識別子 certificate 利用者の身元証明
gender  人口統計学的・社会経済学的データ gender 利用者の性別
employer 人口統計学的・社会経済学的データ text 利用者の雇主
department 人口統計学的・社会経済学的データ text 利用者が勤務している組織の部門または課
jobtitle 人口統計学的・社会経済学的データ text 利用者の勤務先での肩書き
home. 実社会における連絡先情報、
オンライン連絡先情報、人口統計学的・社会経済学的データ
contact. 利用者の自宅へのコンタクト情報
business. 実社会における連絡先情報、
オンライン連絡先情報、人口統計学的・社会経済学的データ
contact. 利用者の勤務先へのコンタクト情報

このデータ集合は、それ自体がデータの集合である要素を含んでいる事に注意してください。これらの集合は、4.4節の基本データ型で定義してあります。データ集合内部にある個々の要素のための簡易表記名は、カンマ区切りを用いて、集合と要素のために定義されている簡易表記名の連結として定義されています。例えば、user.home.postal.postalcodeの簡易表記名は、"利用者の自宅へのコンタクト情報, 郵便情報, 郵便番号"となります。ユーザエージェントの実装において、開発者は利用者に情報を提示する場合、連結された表記名を使用せずに、独自の簡易表記名を使用してもよいでしょう。

4.3.2 動的データ

利用者が入力したり、またはレポジトリに保存したりするような固定値を持たないデータ要素を指定する必要が出てくる場合があります。P3P基本データスキーマにおいてそれらの全ての要素はdynamic.データ集合下にグループ化されます。サイトは、特定の全てのデータ要素を列挙せずに、動的データ集合のみを利用して、収集するデータの型を参照してもよいでしょう。
dynamic. カテゴリ 簡易表記名
clickstream.client ナビゲーションとクリックストリームのデータ text クライアント側で収集されるクリックストリームのデータ
clickstream.server ナビゲーションとクリックストリームのデータ text サーバ側で収集されるクリックストリームのデータ
cookies (可変カテゴリ) text クッキーを使用します (read/write)
http.useragent コンピュータ情報 text ユーザエージェント情報
http.referrer ナビゲーションとクリックストリームのデータ uri 利用者によって要求された最後のURI
miscdata (可変カテゴリ) text 雑多な非基本データスキーマ情報
searchtext インタラクティブデータ text 検索文字列
interactionrecord インタラクティブデータ text サーバの処理履歴の保存

これらの要素は、しばしばナビゲーションやWebでのやり取りに事実上含まれています。また、それらの方法を通して収集される情報のタイプを表現するために、それらの要素はカテゴリと共に使用されるべきです。以下は、各々の要素についての簡単な説明です。

"clickstream.client" は、サーバが、利用者のクライアントによって収集されているオフラインでのブラウザによる閲覧情報にアクセスする場合に使用されるべきです。Microsoft社のInternet Explorerの幾つかのバージョン(5.0など)は、このような振るまいをサポートしていることで知られています。

"clickstream.server"は、今日のほとんどのWebサイトに適用されるでしょう。サーバ側で、ページへのアクセスデータが保存される場合には必ずclickstream.serverが使用されなければなりません。現在のほとんどのWebサーバの実装において、サーバはリクエストの発生場所(IPアドレスやDNS名)、時間、要求されたリソース、HTTPリターンコード、転送バイトなどを含むアクセスログを標準で作成します。リソース名とリクエストの発生したアドレスの組み合わせは、クリックストリームのデータ(すなわち、このデータはサイトを通した訪問者の動向を再現することを可能にします)とみなされ、宣言されるべきです。

参照(referer)ログやユーザエージェント情報(多くのブラウザによるHTTPリクエストのヘッダに含まれる)に関するログを採取する場合には、"http.useragent"と"http.referrer"データ要素を使用して、明白にその旨を宣言するべきです。

"cookies" は、後にその情報を要求する(すなわち、自動的に送信する)ために、HTTPのクッキーメカニズムを使用して、利用者のマシンに情報が置かれる場合に必ず使用しなければなりません。cookiesは、可変データ要素で、プライバシーポリシー内において使用カテゴリを明白に宣言する必要があることに注意してください。

"http.useragent" は、オペレーティングシステムやブラウザ(バージョン情報を含む)などのユーザエージェントに関する追加情報を、サーバがログに保存することを示します。

"http.referrer" は、"HTTP_REFERER"ヘッダによって示されているように、利用者が直前に閲覧したページに関する追加情報をサーバが保存することを示します。

"miscdata" 要素は、特定のデータ要素を使用しないで参照を行うサービスによって収集された情報を参照します。サイトは収集するmiscdataの各カテゴリに対し、プライバシーポリシーにおいて別々にmiscdata要素を参照しなければなりません。

"searchtext" は、サイトの検索と索引のために使用される特有の要求のことです。例えば、検索エンジンのページでの唯一のフィールドが検索フィールドである場合、サイトは、そのデータ要素のみを開示する必要があります。

"interactionrecord" 要素は、サーバが、利用者との間での交流履歴(クリックストリームのデータ以外の情報。例えば、口座取引など)を保存する場合にのみ使用されるべきです。この要素は、利用者との間での交流履歴情報が保持されることを利用者に知らせることのみを意味し、情報がどのくらいの期間保持されるということを知らせるものではありません。

上記の可変データ要素を一つでも含んでいるプライバシーポリシーは、要求する情報のカテゴリを明白に宣言します。例えば:

<POLICY ... >
   ...
   <DATA:REF name="dynamic.miscdata" category="online">
   ...
</POLICY>

これは、利用者のIRC名(この場合オンライン連絡先情報カテゴリに属す)を要求する場合である。

4.4 基本データ型

4.4.1 日付

date.型は、日付を特定するための構造化された型です。日付に関する情報は、周囲の状況によって使われ方が異なるので、全てのdate.情報は、“可変”カテゴリとして分類されます。スキーマ定義は、このデータ型を参照する要素内の対応するカテゴリを明白に設定しなければなりません。例えば、利用者の誕生日を要求する場合は、“人口統計学的・社会経済学的データ”になりますが、クレジットカードの有効期限は、”金融機関のID番号”カテゴリとなります。
date. カテゴリ 簡易表記名
ymd.year (可変カテゴリ) number
ymd.month (可変カテゴリ) number
ymd.day (可変カテゴリ) number
hms.hour (可変カテゴリ) number
hms.minute (可変カテゴリ) number
hms.second (可変カテゴリ) number
fractionsecond (可変カテゴリ) number 秒(小数点以下)
timezone (可変カテゴリ) text タイムゾーン

date. 型の全てのフィールドは、ISO8601の時間標準のものと同じフォーマットでなければなりません。"date.ymd."と"date.hms."は、年/月/日と時/分/秒、それぞれの組の参照時間を短縮するために使用されることに注意してください。

4.4.2 名前

personname.型は、個人の名前に関する情報を指定する構造化された型です。
personname. カテゴリ 簡易表記名
prefix 人口統計学的・社会経済学的データ text 敬称
first 実社会における連絡先情報 text 
last 実社会における連絡先情報 text 
middle 実社会における連絡先情報 text  ミドルネーム
suffix 人口統計学的・社会経済学的データ text Name Suffix
formatted 実社会における連絡先情報、人口統計学的・社会経済学的データ text formatted Name
nickname 人口統計学的・社会経済学的データ text 愛称

4.4.3 認証

certificate.型は、本人であることの証明(例:X.509)を指定する構造化された型です。
certificate. カテゴリ 簡易表記名
key ユニークな識別子 binary 認証鍵
format ユニークな識別子 text  認証フォーマット

"format"フィールドは、IANAに登録されている公開鍵、もしくは認証書のフォーマットのことです。"key"フィールドには、対応する認証鍵が含まれます。

4.4.4 電話

phonenum.型は、電話番号に関する特徴を指定する構造化された型です。
phonenum. カテゴリ 簡易表記名
intcode 実社会における連絡先情報 number 国番号
loccode 実社会における連絡先情報 number  局番
number 実社会における連絡先情報 number  電話番号
ext 実社会における連絡先情報 number 内線
comment 実社会における連絡先情報 text  注釈

4.4.5 連絡先情報

contact.型は、連絡先情報を指定するために使用される構造化された型です。サービスは、郵便、テレコミュニケーション、またはオンラインアドレス情報のどのデータの集合が必要であるか正確に指定することができます。
contact. カテゴリ 簡易表記名
postal. 実社会における連絡先情報、人口統計学的・社会経済学的データ postal. 郵便情報
telecom. 実社会における連絡先情報 telecom. テレコミュニケーション情報
online. オンライン連絡先情報 online. オンラインアドレス情報

4.4.5.1 郵便

postal.型は、郵便あて先を指定する構造化された型です。
postal. カテゴリ 簡易表記名
name. 実社会における連絡先情報、人口統計学的・社会経済学的データ personname. 氏名
street.line1 実社会における連絡先情報 text 町・番地1
street.line2 実社会における連絡先情報 text 町・番地2
street.line3 実社会における連絡先情報 text 町・番地3
city 実社会における連絡先情報 text 市・区
stateprov 実社会における連絡先情報 text 都道府県
postalcode 人口統計学的・社会経済学的データ text 郵便番号
countrycode 人口統計学的・社会経済学的データ Country 国コード
country 人口統計学的・社会経済学的データ text
organization 実社会における連絡先情報、人口統計学的・社会経済学的データ text 団体・組織名
formatted 人口統計学的・社会経済学的データ text 形式化された郵便あて先

町・番地に関する情報のために三つの異なるフィールドを使用することによって、サービス提供者とユーザエージェントは、要求中に長い住所を幾つかのラインに分割することができます。しかし、この三つのフィールドは共通のstreet.を共有しているため、このstreet.だけで三つのフィールドを一度に参照することができます。

"formatted" フィールドは、例えば、ラベル上に印刷されるあて先のように、配達先の住所に対応した形式化されたテキストを指定するために使用されます。

4.4.5.2 テレコミュニケーション 

telecom.型は、個人に関するテレコミュニケーション情報を指定する構造化された型です。
telecom. カテゴリ 簡易表記名
phone. 実社会における連絡先情報  phonenum. 電話番号
fax. 実社会における連絡先情報  phonenum. ファックス番号
mobile. 実社会における連絡先情報  phonenum. 携帯電話番号
pager. 実社会における連絡先情報  phonenum. ポケットベル番号

4.3.5.3 オンライン

online.型は、個人に関するオンライン情報を指定する構造化された型です。 
online. カテゴリ 簡易表記名
email オンライン連絡先情報 text 電子メールアドレス
uri オンライン連絡先情報 uri ホームページアドレス

4.5 データ要素の使用について

P3Pでは、Webサイトが収集するデータ型の表現方法に関して、様々な形に対応できるようにしています。

これらの三つの方法を、一つのプライバシーポリシー内部で組み合わせることができます。

dynamic.miscdata要素を使用することによって、サイトは各々のデータ要素を列挙することなしに、収集するデータを指定することができます。このことは、多くのデータを収集するサイトや、組織・団体の全体を一つのP3Pプライバシーポリシーでカバーしたい巨大な組織・団体のサイトにとって非常に便利です。しかし、このアプローチによる不利な点は、ユーザエージェントは、サイトが参照するカテゴリに属すすべてのデータ要素を収集するかもしれないと仮定しなければならないということです。従って、例えば、あるサイトのプライバシーポリシーに“実社会における連絡先情報”カテゴリのdynamic.miscdataを収集すると掲げてあり、実際に収集される情報は、勤務先の住所のみだとします、それでもやはりユーザエージェントは、サイトは電話番号も収集するかもしれないと仮定しなければなりません。もし、サイトが電話番号や勤務先の住所以外の“実社会における連絡先情報”情報を収集しないことを明白にしたい場合、サイトは、user.business.postal.要素を収集することを明らかにするべきです。なお、ユーザエージェントは、自動フォーム入力機能を伴って開発されているので、収集するデータを列挙するサイトは、自動フォーム入力機能をより良く統合することができると思われます。

新規スキーマを定義することによって、サイトは、基本データ集合の枠を超えて、収集するデータを正確に指定することができます。しかし、ユーザエージェントが新規スキーマ内に定義されている要素に精通していない場合、ユーザエージェントは、新規の要素に関しての最小限の情報だけを利用者に提供することができるでしょう。ユーザエージェントが提供する情報は個々の要素のために指定されたカテゴリと表記名に基づくでしょう

サイトが一般的なデータ開示、または特定のデータ開示のどちらかを望んでいるかにかかわらず、dynamic.データ集合に含まれる特定の要素を開示することには利点があります。例えば、dynamic.cookiesを開示することによって、サイトはクッキーの使用を示し、その使用目的を説明することができます。このワーキンググループでは、この情報に基づいて、利用者にクッキー制御のインターフェイスを提供するユーザエージェントの実装を奨励します。また、デフォルトではHTTP_REFERERヘッダを送信しないユーザエージェントは、P3Pプライバシーポリシー内でhttp.referrer要素を検索し、ヘッダが利用者の許容可能な目的で使用される場合には、ヘッダを送信するかもしれません。


5. 付録

付録1: 参考文献(標準準拠)

[ABNF]
D. Crocker, P. Overel. "RFC2234) -- Augmented BNF for Syntax Specifications: ABNF," Internet Mail Consortium, Demon Internet Ltd., November 1997.
[APPEL]
M. Langheinrich (Ed.). "A P3P Preference Exchange Language (APPEL)" World Wide Web Consortium.
[DSIG]
Y. Chu, P. DesAutels, B. LaMacchia, P. Lipp. "PICS Signed Labels (DSig) 1.0 Specification," World Wide Web Consortium Recommendation 27 May 1998.
[HTTP1.0]
T. Berners-Lee, R. Fielding, H. Frystyk Nielsen, "RFC1945 -- Hypertext Transfer Protocol -- HTTP/1.0," W3C/MIT, UC Irvine, W3C/MIT, May 1996.
[HTTP1.1]
R. Fielding, J. Gettys, J.C. Mogul, H. Frystyk, T. Berners-Lee, "RFC2068 -- Hypertext Transfer Protocol -- HTTP/1.1," UC Irvine, Digital Equipment Corporation, MIT.
[HTTP-EXT]
H. Frystyk, P. Leach, S. Lawrence. "IETF Internet Draft -- HTTP Extensions", W3C, Microsoft, Agranat Systems, March 1999.
[ISO3166]
"ISO3166: Codes for The Representation of Names of Countries." International Organization for Standardization.
[KEY]
S. Bradner. "RFC2119 -- Key words for use in RFCs to Indicate Requirement Levels." March 1997.
[MIME]
N. Freed, N. Borenstein. "MIME (Multipurpose Internet Mail Extensions) Part One: Mechanisms for Specifying and Describing the Format of Internet Message Bodies." November 1996.
[RDF]
O. Lassila and R. Swick (Ed.). "Resource Description Framework (RDF) Model and Syntax Specification." W3C Recommendation. 22 February 1999.
[SSL]
A. Freier, P. Karlton,  P. Kocher. "SSL 3.0 Specification."
[URI]
T. Berners-Lee, R. Fielding, and L. Masinter. "Uniform Resource Identifiers (URI): Generic Syntax and Semantics." August 1998. RFC 2396. [Updates RFC1738]
[UTF-8]
F. Yergeau. "RFC2279 -- UTF-8, a transformation format of ISO 10646." January 1998.
[VCARD]
F. Dawson, T. Howes. "RFC 2426 -- vCard MIME Directory Profile", Lotus Decelopment Corporation, Netscape Communications, September 1998.
[XML]
T. Bray, J. Paoli, C. M. Sperberg-McQueen. "Extensible Markup Language (XML) 1.0 Specification." World Wide Web Consortium, Recommendation. 10 February 1998.
[XML-Data]
A. Layman et al. "XML-Data." World Wide Web Consortium, Note.  5 January 1998.
[XML-Name]
T. Bray, D. Hollander, A. Layman. "Namespaces in XML." World Wide Web Consortium, Working Draft. 16 September 1998.
[XML-Schema1]
H. Thompson, D. Beech, M. Maloney, and N. Mendelsohn (Ed.). "XML Schema Part 1: Structures" World Wide Web Consortium Working Draft. 17 December 1999.
[XML-Schema2]
P. Biron, A. Malhotra (Ed.) "XML Schema Part 1: Datatypes" World Wide Web Consortium Working Draft. 17 December 1999.

付録2: P3P基本データスキーマ定義(標準準拠)

P3P基本データスキーマに相当するデータスキーマは以下のものです。我々はコードを読みやすくするために、属性名に伴ってコードを字下げし、整列させましたが、実際のスキーマ定義での空白は、文書の内容は変更されてはならないという観点(データスキーマの不変性)からみて、非常に重要な意味を持っています。

<DATASCHEMA xmlns="http://www.w3.org/2000/P3Pv1">
<!-- ********** Base Data Types ********** -->

<!-- "date." Data Type -->
<DATA:REF name="date.ymd.year"
          short="Year"
                          type="number" size="6"
                          template="yes"/>  <!-- Variable Data Element -->
<DATA:REF name="date.ymd.month"
          short="Month"
                          type="number" size="2"
                          template="yes"/>  <!-- Variable Data Element -->
<DATA:REF name="date.ymd.day"
          short="Day"
                          type="number" size="2"
                          template="yes"/>  <!-- Variable Data Element -->
<DATA:REF name="date.hms.hour"
          short="Hour"
                          type="number" size="2"
                          template="yes"/>  <!-- Variable Data Element -->
<DATA:REF name="date.hms.minute"
          short="Minutes"
                          type="number" size="2"
                          template="yes"/>  <!-- Variable Data Element -->
<DATA:REF name="date.hms.second"
          short="Second"
                          type="number" size="2"
                          template="yes"/>  <!-- Variable Data Element -->
<DATA:REF name="date.fractionsecond"
          short="Fraction of Second"
                          type="number" size="6"
                          template="yes"/>  <!-- Variable Data Element -->
<DATA:REF name="date.timezone"
          short="Time Zone"
                          type="text"   size="10"
                          template="yes"/>  <!-- Variable Data Element -->

<!-- "personname." Data Type -->
<DATA:REF name="personname.Prefix"
          short="Name Prefix"
                          type="text"
                          category="demographic" template="yes"/>
<DATA:REF name="personname.first"
          short="First Name"
                          type="text"
                          category="physical" template="yes"/>
<DATA:REF name="personname.last"
          short="Last Name"
                          type="text"
                          category="physical" template="yes"/>
<DATA:REF name="personname.middle"
          short="Middle Name"
                          type="text"
                          category="physical" template="yes"/>
<DATA:REF name="personname.suffix"
          short="Name Suffix"
                          type="text"
                          category="demographic" template="yes"/>
<DATA:REF name="personname.formatted"
          short="formatted Name"
                          type="text"
                          category="physical" template="yes"/>
<DATA:REF name="personname.formatted"
          short="formatted Name"
                          type="text"
                          category="demographic" template="yes"/>
<DATA:REF name="personname.nickname"
          short="Nickname"
                          type="text"
                          category="demographic" template="yes"/>

<!-- "certificate." Data Type -->
<DATA:REF name="certificate.key"
          short="Certificate Key"
                          type="binary" size="0"
                          category="uniqueid" template="yes"/>
<DATA:REF name="certificate.format"
          short="Certificate format"
                          type="number" size="128"
                          category="uniqueid" template="yes"/>

<!-- "phonenum." Data Type -->
<DATA:REF name="phonenum.intcode"
          short="International Phone Code"
                          type="number" size="11"
                          category="physical" template="yes"/>
<DATA:REF name="phonenum.loccode"
          short="Local Phone Area Code"
                          type="number" size="11"
                          category="physical" template="yes"/>
<DATA:REF name="phonenum.number"
          short="Phone Number"
                          type="number" size="30"
                          category="physical" template="yes"/>
<DATA:REF name="phonenum.ext"
          short="Phone Extension"
                          type="number" size="11"
                          category="physical" template="yes"/>
<DATA:REF name="phonenum.comment"
          short="Phone Optional Comments"
                          type="text"
                          category="physical" template="yes"/>

<!-- "contact." Data Type" -->
<DATA:REF name="contact.postal."
          short="Postal Address Information"
                          type="postal."
                          category="physical" template="yes"/>
<DATA:REF name="contact.postal."
          short="Postal Address Information"
                          type="postal."
                          category="demographic" template="yes"/>
<DATA:REF name="contact.telecom."
          short="Telecommunications Information"
                          type="telecom."
                          category="physical" template="yes"/>
<DATA:REF name="contact.online."
          short="Online Address Information"
                          type="online."
                          category="online" template="yes"/>

<!-- "postal." Data Type -->
<DATA:REF name="postal.name."
          short="Name"
                          type="personname."
                          category="physical" template="yes"/>
<DATA:REF name="postal.name."
          short="Name"
                          type="personname."
                          category="demographic" template="yes"/>
<DATA:REF name="postal.street.line1"
          short="Street Address, Line 1"
                          type="text"
                          category="physical" template="yes"/>
<DATA:REF name="postal.street.line2"
          short="Street Address, Line 2"
                          type="text"
                          category="physical" template="yes"/>
<DATA:REF name="postal.street.line3"
          short="Street Address, Line 3"
                          type="text"
                          category="physical" template="yes"/>
<DATA:REF name="postal.city"
          short="City"
                          type="text"
                          category="physical" template="yes"/>
<DATA:REF name="postal.stateprov"
          short="State or Province"
                          type="text"
                          category="physical" template="yes"/>
<DATA:REF name="postal.postalcode"
          short="Postal Code"
                          type="text"
                          category="demographic" template="yes"/>
<DATA:REF name="postal.organization"
          short="Organization Name"
                          type="text"
                          category="physical" template="yes"/>
<DATA:REF name="postal.organization"
          short="Organization Name"
                          type="text"
                          category="demographic" template="yes"/>
<DATA:REF name="postal.formatted"
          short="Formatted Postal Address"
                          type="text"
                          category="physical" template="yes"/>
<DATA:REF name="postal.formatted"
          short="Formatted Postal Address"
                          type="text"
                          category="demographic" template="yes"/>
<DATA:REF name="postal.country"
          short="Country Name"
                          type="text"
                          category="demographic" template="yes"/>
<DATA:REF name="postal.countrycode"
          short="Country Code"
                          type="Country" size="2"
                          category="demographic" template="yes"/>

<!-- "telecom." Data Type -->
<DATA:REF name="telecom.phone."
          short="Phone Number"
                          type="phonenum."
                          category="physical" template="yes"/>
<DATA:REF name="telecom.fax."
          short="Fax Number"
                          type="phonenum."
                          category="physical" template="yes"/>
<DATA:REF name="telecom.mobile."
          short="Mobile Phone Number"
                          type="phonenum."
                          category="physical" template="yes"/>
<DATA:REF name="telecom.pager."
          short="Pager Number"
                          type="phonenum."
                          category="physical" template="yes"/>

<!-- "online." Data Type -->
<DATA:REF name="online.email"
          short="Email Address"
                          type="text"
                          category="online" template="yes"/>
<DATA:REF name="online.uri"
          short="Home Page Address"
                          type="uri"
                          category="online" template="yes"/>

<!-- ********** Base Data Schemas ********** -->

<!-- "dynamic." Data Schema -->
<DATA:REF name="dynamic.clickstream.client"
          short="Click-stream collected on the client"
                          type="text" source="service"
                          category="navigation"/>
<DATA:REF name="dynamic.clickstream.server"
          short="Click-stream collected on the server"
                          type="text" source="service"
                          category="navigation"/>
<DATA:REF name="dynamic.cookies"
          short="cookies are processed (read/write)"
                          type="text" source="service"
                          template="yes"/>  <!-- Variable Data Element -->
<DATA:REF name="dynamic.http.useragent"
          short="User Agent information"
                          type="text" source="service"
                          category="navigation"/>
<DATA:REF name="dynamic.http.referrer"
          short="Last URI requested by the user"
                          type="uri" source="service"
                          category="navigation"/>
<DATA:REF name="dynamic.miscdata"
          short="Miscellaneous non base data schema information"
                          type="text" source="service"
                          template="yes"/>  <!-- Variable Data Element -->
<DATA:REF name="dynamic.searchtext"
          short="Search terms"
                          type="text" source="service"
                          category="interactive"/>
<DATA:REF name="dynamic.interactionrecord"
          short="server stores the transaction history"
                          type="text" source="service"
                          category="interactive"/>

<!-- "user." Data Schema -->
<DATA:REF name="user.name."
          short="User's Name"
                          type="personname."
                          category="physical"/>
<DATA:REF name="user.name."
          short="User's Name"
                          type="personname."
                          category="demographic"/>
<DATA:REF name="user.bdate."
          short="User's Birth Date"
                          type="date."
                          category="demographic"/>
<DATA:REF name="user.cert."
          short="User's Identity certificate"
                          type="certificate."
                          category="uniqueid"/>
<DATA:REF name="user.gender"
          short="User's gender"
                          type="gender"
                          category="demographic"/>
<DATA:REF name="user.jobtitle"
          short="User's Job Title"
                          type="text"
                          category="demographic"/>
<DATA:REF name="user.home."
          short="User's Home Contact Information"
                          type="contact."
                          category="physical"/>
<DATA:REF name="user.business."
          short="User's Business Contact Information"
                          type="contact."
                          category="physical"/>
<DATA:REF name="user.employer"
          short="Name of User's Employer"
                          type="text"
                          category="demographic"/>
<DATA:REF name="user.department"
          short="Department or division of organization where user is employed"
                          type="text"
                          category="demographic"/>
</DATASCHEMA>

付録3: XML スキーマ定義(標準準拠)

付録3には、P3Pポリシーの文書のためのXMLスキーマと、P3Pデータスキーマの文書のためのXMLスキーマが含まれています。XMLスキーマは、XML文書としてスキーマが作成された場合に使用される構造とデータ型の値を有効にするために使用されるでしょう。P3Pポリシーとデータスキーマの文書はXML文書であるため、XMLスキーマと一致しなければなりません。これらのXMLスキーマは12月17日版のXML Schema ワーキングドラフト[XML-Schema1][XML-Schema2]に基づいていますが、このワーキングドラフトは予告なしに変更される可能性があることに注意してください。

<?xml version='1.0'?>
<!-- XML Schema for P3P policies -->
<!DOCTYPE schema PUBLIC "-//W3C//DTD XMLSCHEMA 19991105//EN"
								"structures.dtd">

<schema  xmlns='http://www.w3.org/1999/XMLSchema/'
		 targetNamespace='http://www.w3.org/2000/P3Pv1/policyNS'
		 version='0.9'>

<!-- policy element ->
<element name='policy'>
 <type>
  <attribute name='entity'>
   <datatype basetype='STRING'
  </attribute>  

   <element ref='disclosure' minOccurs='1'/>
   <element ref='disputes-group' minOccurs='0'/>
   <element ref='statement' minOccurs='1' maxOccurs='*'/>
   <element ref='extension' minOccurs='0' maxOccurs='*'/>

 </type>
</element>

<!-- disclosure element -->
<element name='disclosure'>
 <type>
  <attribute name='discuri'>
   <datatype basetype='URI'/>
  </attribute>
 
  <attribute name='access-disclosure'>
   <datatype basetype='STRING'>
	<enumeration>
	 <literal>nonident</literal>
	 <literal>contact</literal>
	 <literal>other</literal>
	 <literal>contact_and_other</literal>
	 <literal>all</literal>
	 <literal>none</literal>
	</enumeration>
   </datatype>
  </attribute>
 
 </type>
</element>

<!-- disputes-group element -->
<element name='disputes-group'>
 <type>
  <element name='disputes' maxOccurs='*'>
   <type>
	<attribute name='resolution-type'>
	 <datatype basetype='STRING'>
	  <enumeration>
	   <literal>internal</literal>
	   <literal>third-party</literal>
	   <literal>law</literal>
	  </enumeration>
	 </datatype>
	</attribute>

	<attribute name='service' type='URI'/>
	<attribute name='description' type='string' minOccurs='0'/>
	<attribute name='verification' type='string' minOccurs='0'/>
	<attribute name='image' type='URI' minOccurs='0'/>
	<attribute name='width' type='non-negative-integer' minOccurs='0'/>
	<attribute name='height' type='non-negative-integer' minOccurs='0'/>
	<attribute name='alt' type='string' minOccurs='0'/>
   </type>
  </element>
 </type>
</element>
 

<!-- statement element ->
<element name='statement'>
 <type>
  <group>
   <element ref='consequence-group' minOccurs='0'/>
   <element ref='purpose' minOccurs='1'/>
   <element ref='recipient' minOccurs='1'/>
   <element ref='retention' minOccurs='1'/>
   <element ref='data-group' minOccurs='1'/>
   <element ref='extension' maxOccurs='*'/>
  </group>
 </type>
</element>

<!-- consequence-group element -->
<element name='consequence-group'>
 <type>
  <element name='consequence' maxOccurs='*' type='string'>
   <type>
	<attribute name='xml:lang' type='LanguageID'/>
   </type>
  </element>
 </type>
</element>
 

<!-- purpose element ->
<element name='purpose'>
 <type>
  <group minOccurs='1'>
   <element name='current'/>
	 <attribute name='change_preferences' type='yesorNo'/>
   <element name='admin'/>
	 <attribute name='change_preferences' type='yesorNo'/>
   <element name='develop'/>
	 <attribute name='change_preferences' type='yesorNo'/>
   <element name='contact'/>
	 <attribute name='change_preferences' type='yesorNo'/>
   <element name='customization'/>
	 <attribute name='change_preferences' type='yesorNo'/>
   <element name='targeting'/>
	 <attribute name='change_preferences' type='yesorNo'/>
   <element name='profiling'/>
	 <attribute name='change_preferences' type='yesorNo'/>
   <element name='other'>
	 <attribute name='change_preferences' type='yesorNo'/>
	<attribute name='xml:ang' type='LanguageID'/>
	<datatype basetype='string'/>
   </element>
  </group>
 </type>
</element>


<!-- recipient element ->
<element name='recipient'>
 <type>
  <group maxOccurs='1'>
   <element name='ours'/>
   <element name='same'/>
   <element name='other'/>
   <element name='public'/>
   <element name='unrelated'/>
   <element name='delivery'/>
  </group>
 </type>
</element>


<!-- retention element ->
<element name='retention'>
 <type>
   <element name='no-retention'/>
   <element name='stated-purpose'/>
   <element name='legal-requirement'/>
   <element name='indefinitely'/>
   <element name='business-practices'/>
 </type>
</element>


<!-- data-group element -->
<element name='data-group'>
 <type>
  <element ref='data' maxOccurs='*'/>
 </type>
</element>



<!-- data element -->

<element name='data'>
 <type>
  <attribute name='category'>
   <datatype basetype='STRING'>
	<enumeration>
	 <literal>physical</literal>
	 <literal>online</literal>
	 <literal>uniqueid</literal>
	 <literal>financial</literal>
	 <literal>computer</literal>
	 <literal>navigation</literal>
	 <literal>interactive</literal>
	 <literal>preference</literal>
	 <literal>demographic</literal>
	 <literal>content</literal>
	 <literal>state</literal>
	 <literal>other</literal>
	</enumeration>
   </datatype>
  </attribute>

  <attribute name='dataschema' type='string'/>
  <attribute name='optional' type='yesOrNo'/>
  <attribute name='type' type='string'/>
  <attribute name='typeschema' type='string'/>
  <attribute name='template' type='yesOrNo'/>
  <attribute name='short' type='string'/>
  <attribute name='long' type='string'/>
  <attribute name='size' type='non-negative-integer'/>
 </type>
</element>


<element name='man-extension'>
  <!-- any mixed content -->
</element>

<element name='opt-extension'>
  <!-- any mixed content -->
</element>

</schema>


<?xml version='1.0'?>
<!-- XML Schema for P3P dataschemas -->
<!DOCTYPE schema PUBLIC "-//W3C//DTD XMLSCHEMA 19991105//EN"
								"structures.dtd">

<schema  xmlns='http://www.w3.org/1999/XMLSchema'
		 targetNamespace='http://www.w3.org/2000/P3Pv1/dataschemaNS'
		 version='0.9'>

<!-- dataschema element -->
<element name='dataschema'>
 <type>
  <group maxOccurs='*'>
   <element ref='data-group'>
   <element ref='man-extension'>
   <element ref='opt-extension'>
  </group>
 </type>
</element>

</schema>

付録4: RDF データモデル(標準非準拠)

以下は、例 3.1で示されたプライバシーポリシーのためのRDF[RDF]データモデルを図にしたものです。

RDF Policy

付録5: ABNF 表記法(標準非準拠)

この仕様書での正式なP3P文法は、[ABNF]をわずかに修正したものを使用して作成されています。以下はABNFの簡単な説明です。

name = (elements) 
<name> は規則名で、 <elements> は複数の規則名または、以下の数式によって得られた結果です。規則名は大文字/小文字を区別しません。 
(element1 element2)
括弧によって囲まれた要素は一つの要素として扱われますが、括弧内の要素は厳密に順序付けられます。
<a>*<b>element
<a> 個から<b>個の要素。
(1*4<element> は1〜4要素を意味します)
<a>element
<a>個の要素。
(4<element> は4個の要素を意味します)
<a>*element
<a>個、またはそれ以上の要素。
(4*<element> は4個、またはそれ以上の要素を意味します)
*<b>element
0から<b>個の要素。
(*5<element> は0〜5個の要素を意味します)
*element
0個以上の要素。
(*<element> 0〜無限の要素を意味します)
[element]
オプション要素、*1(element)と同等。
([element] は 0 または 1 要素を意味します)
"string" or 'string'
””内に与えられた文字列を意味します。

使用されているその他の表記法は:

; or /* ... */
コメント

付録6:P3Pガイドライン (標準非準拠)

本付録はP3Pの開発の意図を説明し、P3P技術の責任ある使用に関するガイドラインを推奨するものである。前バージョンはW3Cノートの中でP3P Guiding Principles(P3Pガイドライン)として公表されている。

「プライバシー情報取り扱いに対する個人の選好を支持する技術基盤(P3P)」は柔軟性をもち、多様な利用者のプリファレンス、政策、サービス提供者のプライバシーポリシー、およびアプリケーションを支援するものとして設計された。P3Pのこの柔軟性は、設計者たちが想い描かなかったような様々な革新的方法においてP3Pを使用する機会を提供するものである。P3Pガイドラインは、巻末に記載したP3Pワーキンググループのメンバーが本技術を設計した際の意図を表明する目的で、また、Web上での利用者のプライバシーと信用・信頼を最大化するためにP3Pを最も効率的に用いる方法を提案する目的で作成された。我々の柔軟性の目標に適うように、本文書はいかなる組織に対しても要求を課すことはない。むしろ、本文書は1)P3P設計者の意図と整合性を保つために何をなすべきであるか、および2)P3P実装とWebサービスにおける利用者の信用を最大化するにはどうしたらよいかについての推奨を行う。我々は、P3Pを使用する組織や個人、政策決定者、企業が、我々と共にこのP3Pガイドラインを支持してくれることを期待する。

情報プライバシー

P3Pは、サービス提供者が自らの情報プラクティスを公開することと、個人が自分の個人情報の収集と使用に関して情報提供を受けた上での決定を行うことを可能にすることによって、Web上でのプライバシーと信用を向上させるために設計された。P3Pユーザエージェントは、個人情報の収集と使用に関してサービス提供者と合意に達するために、個人に代わって処理を行う。すべての組織がこのような合意を尊重するという相互理解の上に信用は得られる。

サービス提供者は、関連する法律やデータ保護・プライバシー原則を自らの情報プラクティスに適用することによって信用を維持し、プライバシーを保護するべきである。以下に、P3Pの開発にあたって参考にした、またP3Pを使用する組織にとって有用であろうプライバシー原則とガイドラインのリストを挙げる:

さらに、サービス提供者とP3P実装者は、子供のプライバシーをめぐる特別な懸念について理解し、それに対処するべきである

通知とコミュニケーション

サービス提供者は自らの情報プラクティスについて、適切なタイミングで実効のある通知を提供しなければならない。また、ユーザエージェントは利用者がそれらの通知にアクセスし、それらに基づいて意思決定を行うための効果的なツールを提供しなければならない。

サービス提供者は:

ユーザエージェントは:

選択とコントロール

利用者は個人情報の収集、使用および開示に関して意味ある選択を行う能力を与えられなければならない。利用者は自らの個人情報に対するコントロール権を保持し、個人情報を提供する際の条件について決定しなければならない。

サービス提供者は:

ユーザエージェントは:

公正さと完全性

サービス提供者は利用者と利用者の個人情報を公正さと完全性をもって取り扱わねばならない。これは、プライバシーを保護し、信頼を増すためには不可欠なことである。

サービス提供者は:

ユーザエージェントは:

セキュリティ

P3P自体はセキュリティメカニズムを含んでいないが、セキュリティツールと連携して使用されるように意図されている。利用者の個人情報は常に、その情報のセンシビティに合わせて適切なセキュリティ安全装置をもって保護されねばならない。

サービス提供者は:

ユーザエージェントは:

付録7:ワーキンググループ貢献者 (標準非準拠)

本仕様書はP3P仕様書ワーキンググループによって作成された。P3P仕様書ワーキンググループの参加メンバーは以下の通りである:Lorrie Cranor (AT&T、議長), Mark Ackerman (University of California, Irvine), Margareta Björksten (Nokia), Joe Coco (Microsoft), Patrick Feng (RPI), Daniel LaLiberte (Crystaliz), Marc Langheinrich (NEC/ETH Zurich), Daniel Lim (PrivacyBank), Massimo Marchiori (W3C/MIT), Christine McKenna (Phone.com, Inc.), Paul Perry (Microsoft), Martin Presler-Marshall (IBM), Joel Reidenberg (Fordham Law School), Dave Remy (Geotrust), Ari Schwartz (CDT), Rigo Wenning (W3C), Betty Whitaker (NCR), Sam Yen (Citigroup), Alan Zausner (American Express)

P3P仕様書ワーキンググループは、本仕様書の多くの部分を以前のP3Pワーキンググループから受け継いでいる。P3P仕様書ワーキンググループはこれらのグループのメンバーの貢献に対し謝意を表したい(付記した所属団体は、メンバーがワーキンググループに参加していた当時の所属団体である)。

P3Pインプリメンテーション・ディプロイメントワーキンググループの参加メンバーは以下の通りである:Rolf Nelson (W3C、議長), Marc Langheinrich (NEC/ETH Zurich、議長), Mark Ackerman (University of California, Irvine), Rob Barrett (IBM), Joe Coco (Microsoft), Lorrie Cranor (AT&T), Massimo Marchiori (W3C/MIT), Gabe Montero (IBM), Stephen Morse (Netscape), Paul Perry (Microsoft), Ari Schwartz (CDT), Gabriel Speyer (Citibank), Betty Whitaker (NCR)

P3Pシンタックスワーキンググループの参加メンバーは以下の通りである:Steve Lucas (Matchlogic、議長), Lorrie Cranor (AT&T), Melissa Dunn (Microsoft), Daniel Jaye (Engage Technologies), Massimo Marchiori (W3C/MIT), Maclen Marvit (Narrowline), Max Metral (Firefly), Paul Perry (Firefly), Martin Presler-Marshall (IBM), Drummond Reed (Intermind), Joseph Reagle (W3C)

P3Pボキャブラリハーモナイゼーションワーキンググループの参加メンバーは以下の通りである:Joseph Reagle (W3C、議長), Liz Blumenfeld (America Online), Ann Cavoukian (Information and Privacy Commission/Ontario), Scott Chalfant (Matchlogic), Lorrie Cranor (AT&T), Jim Crowe (Direct Marketing Association), Josef Dietl (W3C), David Duncan (Information and Privacy Commission/Ontario), Melissa Dunn (Microsoft), Patricica Faley (Direct Marketing Association), Marit Köhntopp (Privacy Commissioner of Schleswig-Holstein, Germany), Tony Lam (Hong Kong Privacy Commissioner's Office), Tara Lemmey (Narrowline), Jill Lesser (America Online), Steve Lucas (Matchlogic), Deirdre Mulligan (Center for Democracy and Technology), Nick Platten (Data Protection Consultant, formerly of DG XV, European Commission), Ari Schwartz (Center for Democracy and Technology), Jonathan Stark (TRUSTe)

P3Pプロトコル・データ送信ワーキンググループの参加メンバーは以下の通りである:Yves Leroux (Digital、議長), Lorrie Cranor (AT&T), Philip DesAutels (Matchlogic), Melissa Dunn (Microsoft), Peter Heymann (Intermind), Tatsuo Itabashi (Sony), Dan Jaye (Engage), Steve Lucas (Matchlogic), Jim Miller (W3C), Michael Myers (VeriSign), Paul Perry (FireFly), Martin Presler-Marshall (IBM), Joseph Reagle (W3C), Drummond Reed (Intermind), Craig Vodnik (Pencom Web Worlds)

P3Pボキャブラリワーキンググループの参加メンバーは以下の通りである:Lorrie Cranor (AT&T、議長), Mark Ackerman (W3C), Philip DesAutels (W3C), Melissa Dunn (Microsoft), Joseph Reagle (W3C), Upendra Shardanand (Firefly)

P3Pアーキテクチャワーキンググループの参加メンバーは以下の通りである:Martin Presler-Marshall (IBM、議長), Mark Ackerman (W3C), Lorrie Cranor (AT&T), Philip DesAutels (W3C), Melissa Dunn (Microsoft), Joseph Reagle (W3C)

最後に、付録6はW3Cノートの中のP3P Guiding Principlesを元に作成したものである。P3P Guiding Principlesの作成者は以下の通りである:Azer Bestavros (Bowne Internet Solutions), Ann Cavoukian (Information and Privacy Commission Ontario Canada), Lorrie Faith Cranor (AT&T Labs-Research), Josef Dietl (W3C), Daniel Jaye (Engage Technologies), Marit Köhntopp (Land Schleswig-Holstein), Tara Lemmey (Narrowline; TrustE), Steven Lucas (MatchLogic), Massimo Marchiori (W3C/MIT), Dave Marvit (Fujitsu Labs), Maclen Marvit (Narrowline Inc.), Yossi Matias (Tel Aviv University), James S. Miller (MIT), Deirdre Mulligan (Center for Democracy and Technology), Joseph Reagle (W3C), Drummond Reed (Intermind), Lawrence C. Stewart (Open Market, Inc.)


2 November 1999 Specification (last call)からの改定履歴