WD-P3P-syntax-19980702
このドキュメントは
Platform for Privacy Preferences (P3P) Syntax Specification
W3C Working Draft 2-July-1998
http://www.w3.org/TR/WD-P3P10-syntax/
の和訳です。
このドキュメントには和訳上の誤りがありえます。
内容の保証はいたしかねますので、必ずW3C Webサイトの正式版ドキュメントを参照して下さい。
また、著作権については本ドキュメントに含まれる記述に加え、こちらも必ず参照してください。
Copyright(C) 1995-1998
World Wide Web Consortium,
(Massachusetts Institute of
Technology, Institut National de Recherche
en Informatique et en Automatique, Keio
University). All Rights Reserved.
WD-P3P-syntax-19980702
本文書は、W3Cメンバー他によるW3Cワーキングドラフト公式第２版である。本文書は勧告案に昇格する前に（６週間以内に）もう１度アップデートされる予定である。この文書は、P3P活動の一部として作成されて来たものであり、最終的にはW3C勧告案に昇格する。W3Cのワーキングドラフトを参考資料として使ったり、"進行中の作業"としてではない引用を行うことは好ましくない。このドラフト基本コンセプトはかなりしっかりとしており、我々は仕様へのフィードバックのために実験的な実装やプロトタイプの開発を行うことを奨励する。しかしこのワーキンググループでは、今後のバージョンの文書を変更する可能性のある早期の実装は認めないであろう。
このドラフトはW3C processに従い、W3Cとそのメンバーにより考えられている。この文書はP3Pの実装、承認、採用に影響を与えそうな問題に関して、W3Cの会員およびスタッフに送られるコメントを受け取る目的で公開されている。
コメントがある方は以下にお願いしたい。
p3p-comments@w3.org
会員用のアーカイブは以下にまとめられている。
http://lists.w3.org/Archives/Member/p3p-comments/
___
Copyright (C) 1998 W3C (MIT, INRIA, Keio), All Rights Reserved. W3Cの 責任、 登録商標、, 文書の使用、そして ソフトウエアライセンスに関する規則が適用される。
Appendix 1: References （Normative:規範）
Appendix 2: Fingerprints and
Canonicalization (Normative:規範)
Appendix 3: P3P XML DTDs (Non-normative)
Appendix 3: Line-flow Scenario (Non-normative)
Appendix 4: ABNF Notation (Non-normative)
Appendix 5: Working Group Contributors
(Non-normative)
P3P(The Platform for Privacy Preferences)は、Webサイトが自分たちのプライバシープラクティスを表現し、 ユーザがそれらのプラクティスに対するプリファレンスを実行することを可能にする。 P3P準拠の製品は、ユーザが（マシンと人間の両方が解読できる書式で）サイトのプラクティスを知ること、 適切ならばコンピュータに決定を委ねること、そして特定サイトに結びつけることを許す。 ユーザのプリファレンスに適合したサイトのプラクティスは、ユーザの選択によりシームレスにアクセスすることができる。 そうでない場合は、ユーザはサイトのプラクティスを通知され、それらに同意する機会を与えられてブラウジングを続けることができる。
P3Pは、ユーザがWeb上で十分に説明された決定を行う能力と、彼らの情報の使用を制御する能力を与える。 サイトはP3Pを、サービス品質の向上・コンテンツのカスタマイズ・サイトアクセスの簡略化だけでなく、 サービス内での信頼ユーザの場所のレベルを上げるために使うことができる。
P3Pは、構造化データの交換と宣言のために [XML]（とりわけ[RDF]）を使う。 P3Pは将来のデジタル認証とデジタル署名の能力もサポートする予定。 P3Pはブラウザ、プラグイン、サーバ、もしくはクライアントとサーバ間のプロキシサーバに組み込むことができる。
P3P Specは、以下のメカニズムを与える。
このドキュメントは、統一されたP3Pアプリケーションのインプリメントに必要な全ての仕様を含む。 この仕様書は過去のワーキンググループの実績の上に築かれ、以下にあげるものを含んでいる。
文章のステータスを表現するために以下の規約を用いる。
| ABNF表記法の中のスキーマ定義 |
この仕様書で使われたABNF表記法は、RFC2234で規定され、要約が付録3にある。
P3Pプロポーザルは、１つまたはそれ以上のステートメントから成り立っている。
各々のステートメントは一連のデータエレメントに対するプライバシープラクティスを表現する。
P3Pプロポーザルはすべての関連したデータエレメントとプラクティスを含まなければならない。
もしサービスがデータエレメントを集めたければ、プロポーザルの中で述べなければならない。
P3Pのほとんどの宣言文は断定的で、やらないことよりもむしろやることを述べることに注意。
P3P Specの中心コンセプトは、P3P同意のそれである。P3P同意はサービスとユーザエージェントの双方に同意されたプロポーザルである。
ユーザエージェントはプロポーザルで規定されたプライバシープラクティスとユーザのプリファレンスを比較して、合意に入るかどうかを決定する。
1つの同意は特定のレルム内でユーザエージェントとサービス間で交換される全データに当てはまる。
レルムは1つのURIで参照されるWeb資源かもしくは複数のURIで参照されるWeb資源である。
いったん同意に達すると、同意したプロポーザルに含まれるデータエレメント群はサービスからのデータ要求ユーザエージェントに
解釈されるべきである。データエレメントを参照しない同意も可能である。そのような同意は"情報は集めない"と述べる。
プライバシープラクティスがユーザのプリファレンスと一致しない場合には、両サイドは代わりのプロポーザルを交換することで 同意に到達することができる。あらゆるプロポーザルはユーザが見ることができる一連の"結果"を持つことができる。 それは提案されたプラクティスが、たとえユーザが通常は同意しなくてもある特定の場合に大切であるかも知れないという理由を 説明するものである。我々はユーザエージェントが、合意に達した同意を同意IDという同意のフィンガープリントで表示された形で 記録することを期待する。
サイトは、接触のたびに新しいプロポーザルをユーザエージェントに送るのではなく、既存の同意IDを送っても良い。これは、 1)サービスとユーザエージェントが既に合意に達していることを示す、 2)どのプロポーザルとプライバシープラクティスがの下で動いているかを合図する、 3)同意で参照されているデータエレメントを要求する、という意味がある。 ユーザエージェントは断っても良いし、要求されたデータで応じても良いし、あるいは該当同意の記録がないか新しく欲しければ、 完全なプロポーザルを要求しても良い。
サイトはまた、プロポーザルの一部として、テンポラリIDあるいはペアワイズID（TUID／PUID）をユーザエージェントが戻った時に 自動的にサイトに送るよう要求する能力がある。PUIDはクッキーに似ているがP3P制御下にあり、数値に限られている。
我々の設計ではアプリケーションは、複数のやり取り、プロポーザルの保存能力、ユーザエージェントやサーバ側のデータレポジトリの使い方、 同意レポジトリのサイズに関する我々の仮定や期待とは独立したインプリメントが十分に可能である。
propURI：プロポーザルを発行するURI。
postURI：情報をどこに送るかを示すURI。
discURI：プロポーザルのプライバシーステートメントを自然言語で記述したURI。
P3Pは、動作する環境と解決すべき問題についていくつかの仮定を行っている。
以下のシナリオは、P3Pが使われる可能性のあるいくつかの場面を図解するために設計されている。 各シナリオは、それぞれ異なるP3Pの特徴を強調している。シナリオ１はどのようにして基本的なP3P同意が確立されるかを示す。 シナリオ２、３は既に同意に達しているサイトにユーザが戻った際に何が起きるかを示す。シナリオ４、 ５は同意を与えられたデータレポジトリの使用について強調している。
これらのシナリオは交渉が発生しない場合の相互作用を図解している。 しかしどのシナリオもサイトが初めから複数のプロポーザルを行うシナリオに拡張されたり、 サイトとユーザ間で一連のプロポーザルやカウンタープロポーザルが交わされるシナリオに拡張される可能性がある。 Appendix 1 のシナリオ拡張例は、交渉の一例を含んでいる。
以下の表は、各シナリオの特徴をまとめたもの。表中の"-"は、そのシナリオでは仮定されない(中立な)
という意味を表す。
| Scenario | Existing Agreement | New Proposal | PUID Requested | Data Requested | Data Written |
| 1 | No | Yes | Yes | - | - |
| 2 | Yes | No | No | - | - |
| 3 | Yes | Yes | Yes | - | - |
| 4 | - | - | - | Yes | No |
| 5 | - | - | - | Yes | Yes |
プロトコルシナリオ：クライアントはOPTヘッダー（[MANDA])参照）をサーバに送る。 サーバがP3Pをサポートしていない場合は、内容のみを送り返す。 （この内容とは、従来のCGIメソッドを使って情報をサーバに送るHTMLフォームになるだろう。） サーバがP3Pをサポートしていてかつ関連のプロポーザルを持っている場合は、 サーバは409コードとP3Pクライアントに対するプロポーザルをHTMLヘッダーもしくはURI参照の形で返す。
プロトコルシナリオ：クライアントはサーバにOPTヘッダとすべての関連したReturnIDを送る。 サーバは関連した内容を返し、それに続くP3Pデータ要求（同意ID付きTXD）を送ることができる。
プロトコルシナリオ：シナリオ5はシナリオ4の延長であり、 シナリオ4でユーザエージェントがサーバにOKと任意にTXD を送って終了したものと仮定している。今、サーバは自らのTXDと共に適切なデータエレメントをクライアントに送る。 もし成功すれば、ユーザエージェントはOK/200理由コードで応答する。失敗した場合にはクライアントはSRY/500理由コードで応答する。
以下のセクションは、同意を形成したりその後のデータを転送するのに必要な原型を規定している。
P3Pは、原型とP3P HTTP拡張のヘッダの内容を交換するように設計されている。しかし、何らかのHTTPインプリメント （例えば巨大なグラフィック画像）において、PROPやTXD の原型がヘッダの予定した長さを越えてしまう場合が考えられる。 よってRDF/XMLのアプリケーションとして、P3Pインプリメントは、 RDF/XML交換の方法が完全に規定されている時、その方法に従うことができなければならない。 それらの方法とは、以下のものが考えられる。
P3P 1.0インプリメントは、上記1-3のそれぞれをサポートしなければならない。シナリオを使ってそれらを解説する。 以下の表は各シナリオの特徴、propURI、postURIを使うかどうか、 プロポーザルが内容に組み込まれているかどうかをまとめたもの。
| Scenario | Proposal-URI | Post-URI | Proposal Embedded in Content |
| 6 | Yes | - | No |
| 7 | No | - | Yes |
| 8 | - | Yes | - |
サービスは、中継プロキシのキャッシュが長いHTTPヘッダを切り取るかあるいは、サービスのプロポーザ ルがプロキシに保存されることを願っている。
propURIはレルムの定義に関係ない。レルムに基づいて信用を決定する必要のあるインプリメントは、プロポーザルで定義されているレルム またはシナリオ1で取って来た本来のURIについて、決定しなければならない。
コンテンツプロバイダは、修正したHTTPヘッダなしで簡単なプライバシープラクティスを宣言したがるかも知れない。 そのような場合、サイトはHTML HEADタグ内に簡単なP3Pプロポーザルを埋め込んでも良い。 P3Pプロポーザルはタグ(< tag> content</tag>)内に内容を含まないので、古いバージョンのHTMLブラウザがそのようなデータを 与えてしまうことを心配する必要はない。しかしそのような提案には以下のような制約がある。
従って、
注意：内容の中でプロポーザルを探さなければならないというオーバーヘッドが潜在的にあり、 また埋め込まれたプロポーザルでサイトを管理することが複雑なためこの方式を積極的に推奨できない。従ってこの方式は、 1)P3Pデータを使わない2)少数でシンプルで重複しないプロポーザルを持つサイトのみで使用されるべきである。
サービスは大きなバイナリーファイルを要求するか、またはFORM/CGIのようにデータを処理することを好む。 そしてPOSTを使用して提供された情報を求める。
postURIはレルムの暗黙の部分である。従ってたとえURIがレルムURIの中にないとして も、情報は同意IDの下で提供されたpostURIに送られる。
ユーザエージェントは、"GET"、"POST"などの標準的なHTTP方式を使ったサーバと通信する。 P3Pはエージェントとサービス間でデータを転送するために命令拡張メカニズム[MANDA]を使う。 サーバに最初の要求を設定する際、ユーザエージェントは自身がP3P準拠であることを知らせるためにp3p-opt-headerを含んで良い。 もしユーザエージェントがOPTヘッダを送り、サーバがP3Pプロトコルをインプリメントする場合には、サーバは以下を必ず行わなければならない。
| [1] | p3p-request |
= |
start-line
*message-header "OPT" ":" p3p-opt-header CRLF [p3p-header-prefix "-P3P1.0: " 1*p3p-content CRLF] [message-body]
|
| [2] | p3p-opt-header |
= |
p3p-extension ";" "ns-" p3p-header-prefix |
| [3] | p3p-extension |
= |
`"` "http://www.w3.org/TR/1998/WD-P3P10-syntax-19980702/proposal.dtd" `"` |
| [4] | p3p-header-prefix |
= |
1*digit |
| [5] | digit |
= |
"0"|"1"|"2"|"3"|"4"|"5"|"6"|"7"|"8"|"9" |
| [6] | yesno |
= |
`"` ("0"|"1") `"` ;
0 = No, 1 = Yes |
以下の表は、P3Pプリミティブの意味とその関連と項、内容、HTTP理由コードをまとめたもの。 すべてのプリミティブはサービスまたはエージェントから送られるだろう。
| Message | Meaning | After Receiving | Expected Response | Data in Message | Optional in Message | HTTP Return Code |
| OK | Proposal acceptable or data transfer successful | PROP or TXD | none | MD5 hash of agreement or data transferred | 2xx | |
| PROP | Here's a Proposal | Any time | OK, SRY, or PROP | Text of a proposal | Signature of initiator, fingerprint of previous Proposal | 409 |
| SRY | Sorry - request not processed | PROP, TXD | PROP or none | Reason code and MD5 hash of proposal or data transferred | Which practices are unacceptable | 409 |
| TXD | Transfer Data | Any time | none, OK or SRY | Data element names and values to be written, as requested | Agreement | 2xx |
このセクションでは各動作を説明し、誰が(ユーザまたはサービス)どんな状況で動作を始めることが できるかを規定する。
このメッセージは参加者がプロポーザルに同意した時またはデータ転送が成功した時に送られる。 プロポーザルに対する返答がOKの場合、OKメッセージは 同意IDを含む。OKが TXDメッセージに答えて 送られる場合、OKメッセージはすでに転送されたデータの MD5ハッシュ値を含む。
どんな場合でも、いずれかの参加者は相手側に1つかそれ以上のプロポーザルを送ることができ、これらは、prop-msgの中で送られる。 プロポーザルの条件は、片方がそれらに合意するまで（OK またはTXD 原語を使って返答することによって）固まっていない。 プロポーザルはもしそう望めば、それを作成する者が署名して良い。さらにPROPは、 片方から受け取ったプロポーザルの同意IDを含まなければならない （これによって片方は交渉の記録をたどることができる）。サイトがデータエレメントが任意であることを表したい場合は、 プロポーザル内でそれを行っても良い。ユーザエージェントは、適切だと判断した時に任意のエレメントを返す。 任意の目的やクオリファイヤを持つプロポーザルに関する同意ははっきりしないが、ユーザエージェントが一方の目的が合意に達し、 一方は合意しなかったと表現するための明確な方法はない。従って、 任意の目的やクオリファイヤは複数のはっきりしたプロポーザルを通して表現されなければならない。
プロポーザルがユーザエージェントに自動的に受領されない場合、3つのオプションがある。 ユーザエージェントはどの返答が適切かどうかを決定するために、ユーザにガイダンスを指示することを含みながら何らかの方法で プログラムされていなければならない。
もしプロポーザルがユーザエージェントに承認されれば、ユーザエージェントはOKとともにデータをサービスに送らなければ ならない。 同意IDのもとでデータを送ることで、ユーザエージェントはプロポーザルを承認したことを示す。 TXDには承認されたプロポーザルの同意IDが含まれ、サービスは送られたデータを調べることで、 ユーザがどのデータエレメントを送ったのかを確定することができる。
このメッセージは、プロポーザル(PROP) またはデータ送信(TXD)に対し送られる。 これは、要求が処理されなかったことを示す。拒否には、 理由コードと同意IDの2つの情報が含まれている。理由コードは どのようなタイプの要求が拒否されたのか、なぜ拒否されたのかを示す。複数のプロポーザルが送られるため、同意IDはどの要求が 拒否されたのかを知る必要がある。プロポーザル拒否の特定の原因は理由コードにある。
最後に、SRYメッセージは、データ送信が失敗した時にデータ送信(TXD)メッセージに対して使うことができる。 送信者は、TXDメッセージを再試行すべきではない。
注意：P3P1.0は、プロポーザルが拒否された場合プロポーザルのどの部分が拒否されたのかをはっきりと指摘することはできない。 そのような機能はP3Pプロトコルの将来版に追加される予定である。P3P1.0では、詳細な交渉を要求するサービスやユーザエージェントのための可能な 予備システムは、カウンタープロポーザルを送り、受け入れられない元々のプロポーザルの部分を修正、除去することである。 インプリメントする人は、ユーザのプライバシープリファレンスを公開することに配慮が必要である。
プロポーザルを受け取った後、ユーザエージェントは要求されたデータを送る。ユーザエージェントは、 同意IDを含む必要がある。サービスは、同意がまだ有効であるならそれを与えなければならない。 同意IDが有効でないまたは存在しない同意の時は、 サービスはSRYメッセージと共に レスポンスコードを430(Unrecognized Agreement)に設定してTXDに返さなければならない。
プロポーザルが任意のエレメントを要求した場合、TXDは要求されたデータエレメントの全てを含まないかもしれない。これらのうちいくつを転送するかを決定するのはユーザエージェントによる。同意は、ユーザにオプション項目を送った結果（おそらく報酬）を知らせてもよい。
交渉を終わらせるための原語はない。代わりに、この機能は、P3Pメッセージのクオリファイヤを通して提供される。 どんなPROPやSRYメッセージも finalクオリファイヤに1を設定できる。サービスがfinal="1"クオリファイヤと共に PROPを受け取る時、それは、 OKまたはSRYで返答しなければならない。この返答は、 要求されたオブジェクトは同意なしでは返却されないと書かれているHTMLドキュメントと同じくらい簡単かも知れないが、 content本文を含んでいなければならない。ユーザエージェントがfinal="1"のクオリファイヤと共に PROPを受け取る時、ユーザエージェントは、 サービスがその"最終申し込み"を提示し、交渉を続けることは無意味であることを理解しなければならない。
| [7] | p3p-content |
= |
OK-msg | PROP-msg | SRY-msg | TXD-msg |
| [8] | OK-msg |
= |
"<OK" message-attribute "/>" |
| [9] | SRY-msg |
= |
"<SRY" [" final=" yesno] ; default is 0 (No) message-attribute "/>" |
| [10] | TXD-msg |
= |
"<TXD" message-attribute ">" data-xfer "</TXD>" |
| [11] | message-attribute |
= |
agreementid-attribute | reason-attribute | data-hash-attribute |
| [12] | agreementid-attribute |
= |
" agreeID=" `"` agreement-id `"` |
| [13] | reason-attribute |
= |
" r=" `"` reason-code `"` |
| [14] | data-xfer |
= |
<XML formatted data element name-value pairs> |
| [15] | agreement-id |
= |
<base64 of 128 bit MD5 digest of proposal as per RFC 1864> |
| [16] | data-hash-attribute |
= |
" dh=" `"` <base64 of MD5 digest of data-xfer> `"` ; used to acknowledge the receipt of data |
理由コードはP3Pヘッダの中でオプションとして送られる。全てのSRYメッセージは暗黙の400理由コードを持ち、 その他すべてのメッセージは、暗黙の200理由コードを持っている。これらのデフォルトを無効にする メッセージの中の理由コードも含まれる。 理由コードは大きく３つのクラスに分けられる。Successコード、rejectionコード、errorコードである。これらのクラスについての詳細を以下に示す。
理由コードのこのクラスは、要求が正しく受け取られ、理解され、了承されたことを示す。
理由コードのこのクラスは、要求が正しく受け取られ、理解されたが、了承されなかったことを示す。これらのコードは SRYメッセージでのみ送られなければならない。
理由コードのこのクラスは、要求が正しく受け取られなかったか、または受け入れられたが理解されなかったことを示す。 これらのコードはSRYメッセージでのみ送られなければならない。
| [17] | reason-code |
= |
200 | 400 | 430 | 431 | 432 | 433 | 434 | 500 | 530 | 531 |
このセクションでは、1) P3Pプロポーザル 2) データ転送のスキーマを説明する。プロポーザルで使用される英語の用語説明は、 [HARMV]に、より詳しく記載されている。
以下の文をコード化する。ここでプロポーザルは1つ、ステートメントは2つでそれぞれに論理ANDを含んでいる。 "Other disclosures"は自動的にプロポーザル全体に当てはまる。
PrivacyAssuredのメンバーであるCoolCatalogは、Webページhttp://www.CoolCatalog.com/catalogue/に 以下のstatementを載せている。私たちは、あなたの名前、年齢、性別を集める。それは、あなたが興味を持ちそうな衣服のタイプを見つけたり、または当方のリサーチ、 商品開発の目的でエントリーカタログページをカスタマイズするためである。この情報を身元が確認できるような方法では使用しない。また、 注文品を届けるためにあなたのお届け先情報を収集する。これは、当然であるが身元が判明する。この情報は社外に再び出ることはない。 あなたからの情報にアクセスできる可能性は提供しない。しかし、保持および脱退方針をもっている。詳しくは、 当方のプライバシーページ http://www.CoolCatalog.com/PrivacyPractice.htmlを参照のこと。
以下は良い形式的な記述である。コメントがセミコロンの後ろにある:
in proposal schema
CoolCatalog makes ; entity
this statement for http://www.CoolCatalog.com/catalogue/ ; realm
with assurance from PrivacyAssured
we read ; read is default
(User.Name.First) ; required is default
(User.Bdate.Year optional)
(User.Gender)
for the purpose of (2 3) ; Customization of the Site to Individuals, R&D
in (0) ; Non-Identifiable Form
and the recipients are (0) ; only ourselves and agents
with consequence of ("a site with clothes you'd
appreciate.") ; optional
we read&write
(User.Shipping.) ; this is a whole data set.
for the purpose of (0) ; Completing the Current Transaction
in (1) ; Identifiable Form
and the recipients are (0) ; only ourselves and agentsaccess disclosure (3) ; no access to identifiable data
other disclosures (0,1) ; we make disclosures
regarding changing agreement and retention
at http://www.CoolCatalog.com/PrivacyPractice.html
以下のRDFは、上記にあるような情報を捕捉する。P3Pプロポーザルとは、RDFおよび、 有効でよく形成されたXMLの構文モデルに基づいて 正しく表現された文章でなければならない。しかしプロポーザルを短くするために使われる、P3Pプロポーザルと標準RDFを わずかに区別する2つの仮定がある。
<?xml:namespace ns="http//www.w3.org/TR/1998/WD-P3P10-syntax#proposal.DTD" prefix="p3p"?> <?xml:namespace ns="http://www.w3.org/TR/WD-rdf-syntax#" prefix="RDF"?> <RDF:RDF><PROP realm="http://www.CoolCatalog.com/catalogue/" entity="CoolCatalog" agreeID="94df1293a3e519bb" assurance="http://www.TrustUs.org"> <USES> <STATEMENT purp="2,3" recpnt="0" id="0" consq="a site with clothes you'd appreciate."> <WITH><PREFIX name="User."> <REF name="Name.First"/> <REF name="Bdate.Year" optional="1"/> <REF name="Gender"/> </PREFIX></WITH> </STATEMENT> </USES> <USES> <STATEMENT action="read&write" purp="0" recpnt="0" id="1"> <REF name="User.Shipping."/> </STATEMENT> </USES> <DISCLOSURE discURI="http://www.CoolCatalog.com/PrivacyPractice.html" access="3" other="0,1"/> </PROP></RDF:RDF>
realm(レルム)属性は、同意の範囲を定義する。これは、ユーザエージェントにより使われるが、例えば、ReturnIDを 自動的に送るかや、データ転送要求に応じるかなどの決定を行う。プロポーザルがデジタル方式でサインされない場合は、 各レルムのURIは、サーバのドメインと、"domain-match"[Kristo参照] （ドメインが一致）しなければならない。 プロポーザルがデジタル署名される場合は、 元々のレルムの外のサーバが既存の同意に基づいてデジタル署名したプロポーザルを作成した時はいつでも、 レルムは拡大され現在の要求URIを含む。
注意点として、ユーザエージェントは現在の要求URIが既存の同意に影響されるのかどうかを決定するためにレルムを使う。 ユーザエージェントは、もし有効な同意がReturnIDを要求した場合、その要求とともに自動的にReturnIDを転送する。このことは、 サービスが状態を保持したり、客レベルの統計を保存したりする機能を与えている。
ショートプロポーザルは、サイトがエージェントが同意を知っていると仮定したいとき、 あるいはエージェントにpropURIで示される完全なプロポーザルを参照させたいときに送られる。
| [19] | short-proposal |
= |
( "<PROP agreeID=" `"` quoted-string `"` ">" | "<PROP propURI=" quoted-URI ">" ) "</PROP>" |
ロングプロポーザルは必要な属性のすべてを含んでいる。
| [20] | long-proposal |
= |
"<PROP"
[" final=" yesno] ; default is 0 (No)
[agreementid-attribute]
[" agrexp=" `"` datetime `"`] ;default is six months
" realm=" `"` URI *(" " URI) `"`
" entity=" quoted-string
[(" assurance=") quoted-URI]
[" postURI=" quoted-URI]
[" optional=" yesno] ;default is 0 (No)
">"
1*statement-block
disclosure
"</PROP>"
|
| [21] | schemaURI |
= |
`"` "http://www.w3.org/TR/1998/WD-P3P10-syntax-19980702/proposal.dtd " `"` |
| [22] | quoted-string |
= |
`"` string `"` |
| [23] | strin |
= |
<[UTF-8] string (with " and & escaped)> |
| [24] | quoted-URI |
= |
`"` URI `"';` |
| [25] | URI |
= |
<URI as per RFC 2068 [URI]> |
| [26] | datetime |
= |
<date/time as per section 3.3 of RFC 2068> |
Schemes（スキーマ）
P3Pは、HTTPと関連するschemes (HTTPSのような）用に設計されている。そのプロトコルは、将来拡大され、 FTPやNNTPなどのその他のスキーマを使ってデータ交換、交渉をサポートする可能性がある。特にHTTP、HTTPSの場合、 HTTPを使用して届いた同意は、HTTPS schemesを使用するURI要求をサポートする。例えば、 ユーザがrealm="http://www.romulus.com/"に同意した場合、 "https://www.romulus.com"は、レルムの一部と考えられる。しかし、 ユーザーがrealm="http://www.romulus.com/"に同意した場合、 "https://www.romulus.com"は、その同意の影響を受けない。
entity（実体）
entity属性は、legal entityと連携可能なドメイン名とパスを参照する。デジタル署名がない場合、 この機能はドメイン名登録から供給される権威のない確認メカニズムとドメイン名の責任機関を経由して legal entityの記録をたどる唯一の方法である。さらにentity属性は、証明がrealm属性として使用されていない時に、 realm内のURIがドメイン一致[KRISTOL]しなければならない"root" ドメインとして使用される。さらに、 客が要求したURIは、entity属性にドメイン一致しなければならない。
realm（レルム）
HTTP要求のための与えられたURIが特定の同意に従うかどうかを決定するために使用される URIを表すrealm属性。Realmは、entity属性にドメイン一致する1つまたは複数の URIであるか、あるいはURIのrealmのセットを表すデジタル認証を示す URI。以下のシナリオを考えてみてもらいたい。
- purp
- Webに関連したデータ処理の目的。
- recpnt
- データが分配されるサービスプロバイダやそのエージェント以外の組織の地域、領域。
- id
- 個人的な身元確認可能な方法で使用されるデータ。他のソースからのあなたに関する身元確認可能な 情報とのリンクを含む。
- action
- データを読む。または読み書き。
- source
- ネイティブなP3Pエージェントのインタフェース以外の方法（例：フォーム）で情報を求めることができる。
| [27] | statement-block |
= |
"<USES>"
"<STATEMENT"
[" action=" `"` action `"`]
[" purp=" `"` purpose *("," purpose) `"` ] ; default is 0 (No)
[" id=" yesno] ; default is 0 (No)
[" recpnt=" `"` recipients *("," recipients) `"` ] ; default is 0 (No)
[" consq=" quoted-string]
[" source=" `"` ("agent"|"form"|URI) `"`] ; default is agent
">"
*(datablock)
"</STATEMENT>"
"</USES>"
|
| [28] | purpose |
= |
"0" | ; Completion and Support of Current Activity
"1" | ; Web Site and System Administration
"2" | ; Customization of the Site to Individuals
"3" | ; Research and Development
"4" | ; Contacting Visitors for Marketing of Services or Products
"5" [" (" string ")"] ; Other Uses
|
| [29] | recipient |
= |
"0" | ; only ourselves and our agents "1" | ; organizations following our practices "2" | ; organizations following different practices "3" ; unrelated third parties or public forum |
| [30] | id |
= |
yesno ; default is 0 (No) |
| [31] | action |
= |
("r" | "rw") ; r=read, rw=read&write, default is read
|
この属性は、ネイティブなP3Pエージェントのインタフェースではなく、フォームを通して情報を求めることができる。これは、プロポーザルのエレメント名を連携したHTMLフォーム(HTTP content) のフォームのINPUT名と関連させることにより達成される。HTMLクライアント/P3Pエージェントは、適宜値を自動入力する可能性がある。
以下の場合にP3Pエレメントが要求される。
このフィールドの許容値は、以下の通りである。
agent.. デフォルト値。P3Pエージェントは、ユーザを要求しなければならない。
form.. 要求は、連携したHTML内容の暗黙のフォームを通して起こる。
URI.. 与えられた情報は、与えられたURIのresourceによって要求される。
例えば、サービスは自分の具象的な制御の下で要求を持ちたがる。また、サービスはデータをシナリオ8に書かれているpostメカニズムを通して受けたがっていると仮定する。
<?xml:namespace ns="http://www.w3.org/TR/1998/WD-P3P10-syntax-19980702/proposal.dtd" prefix="P3P"?> <?xml:namespace ns="http://www.w3.org/TR/WD-rdf-syntax#" prefix="RDF"?> <RDF:RDF><PROP realm="http://www.CoolCatalog.com/catalogue/" entity="CoolCatalog" agreeID="94df1293a3e519bb" assurance="http://www.TrustUs.org"postURI="http://www.CoolCatalog.com/cgi-bin"/><USES> <STATEMENTaction="rw"purp="2,3" recpnt="0" id="0" source="form" consq="a catalogue of shoes that fit you."><WITH><PREFIX name="Cool." dataschema="http://www.CoolCatalog.com/productschema.html"> <REF name="ShoeSize"/> </PREFIX></WITH> <REF name="Form.Data_"/> </STATEMENT> </USES></PROP></RDF:RDF>...Content-Type: text/htmlContent-Length: 110<html><body><h1>Welcome to Cool Catalogue</h1><p>We'd love to have the following information tocustomize our online catalogue to you.</p>
<form method="POST" action="http://www.CoolCatalog.com/cgi-bin">
<p><input type="submit" value="Submit" name="B1"><input
type="reset" value="Reset" name="B2">First Name<input type="text" name="P3P_User_First"
size="20" value="Your Name Here"> Shoesize <input type="text" name="Cool.ShoeSize"
size="20" value="9 1/2"></p>
</form>
</body></html>
- <DISCLOSURE>
- サービスのアクセス能力に関する簡単な情報開示能力で、entityがすでに集められたデータの同意の変更やデータの保持方法についての情報開示を行うかどうかに関するバイナリ値。
- discURI
- プロポーザルのわかりやすいURI。
- access
- 個人情報、住所に関する質問、サービスプロバイダーへの憂慮事項等を個人が参照できること。
- other
- サイトはそのdiscURIで知られる同意の変更や保持に関してそのポリシーを作るのか？
| [32] | disclosure |
= |
"<DISCLOSURE"
" discURI=" quoted-URI
" access=" `"` access-disclosure `"`
[" other=" `"`
other-disclosure *("," other-disclosure) `"`]
"/>"
|
| [33] | access-disclosure |
= |
"0" | ; Identifiable Data is Not Used "1" | ; Identifiable Contact Information "2" | ; Other Identifiable Information "3" ; None |
| [34] | other-disclosure |
= |
["0" | ; change agreement "1" ] ; retention |
より詳しい文法の説明は P3P Harmonized Vocabulary Specification を参照のこと。
data sets/elementsに対する参照は全て<REF>タグを使用したstatement内に囲まれている。 <REF>タグは、以下の属性を持っている。 name、dataschema、value、optional、type、 typeschema、short、long、category、size。
以下の6つの属性は新しい（P3P1.0ベースには定義されない）データエレメントやセットが参照された時のみに使用される。
| [35] | data-reference |
= |
"<REF" " name=" quoted-string [" dataschema=" quoted-URI] [" optional=" yesno] [" value=" quoted-string] [" type="quoted-string] [" typeschema=" quoted-URI] [" template=" yesno] [" category=" categories] [" short=" quoted-string] [" long=" quoted-string] [" size=" `"` 1*digit `"`] ; default is 0 (unlimited size) "/>" |
例として、ユーザのお届け先情報の都市名、User.Business.の全エレメント、そして（オプションとして）User.Home.Info.Phone. の全エレメントを要求するために、サービスはP3Pプロポーザルの中で以下のようなreferenceを送る。
<REF name="User.Shipping.Postal.City"/>
<REF name="User.Home.Telecom.Phone." optional="1"/>
<REF name="User.Business."/>
ユーザがcity, business情報,自宅の電話番号の国際コードのみを返すことに同意する場合、txdタグの中で以下のreferenceを送る。
<REF name="User.Shipping.Postal.City" value="Boston"/>
<REF name="User.Home.Telecom.Phone.IntCode" value="1"/>
<REF name="User.Business.Postal.Street" value="12 Main St."/>
<REF name="User.Business.Postal.City" value="Cambridge"/>
... (the other values of User.Business.) ...
データ参照の1セット中の多くのエレメント名は、１つのparentを共有する。例えば、上記にあるように"User"は、referenceのなかに共通して発生する。<WITH><PREFIX>タグは、文字列 prefixをref タグのすべての属性と連携させるのに使用することができる。従って、これは、名前の長さを短くしたり、新しいdata sets と elementsに参照文をつけるのに使うことができる。<REF>タグの一続きが&t;WITH><PREFIX> タグ内にある場合、そのブロックは入っている<WITH><PREFIX>タグが省略されたブロックと同等で、<REF>タグの各属性の値が<PREFIX>タグの属性の該当する値の前につけられる。例えば、上の例は以下のように書き換えることができる。
<WITH><PREFIX name="User.">
<REF name="Shipping.Postal.City" value="Boston"/>
<REF name="Home.Telecom.Phone.IntCode" value="1"/>
<REF name="Business.Postal.Street" value="12 Main
St."/>
<REF name="Business.Postal.City" value="Cambridge"/>
... (the other values of User.Business.)
...
</PREFIX></WITH>
<WITH><PREFIX> は、一揃いになることができる。Prefix は、最も奥の<WITH><PREFIX> ...</PREFIX></WITH> の組み合わせの前につけること（ここで"最も奥"は、タグの中には他の<WITH><PREFIX> が無いことを意味する）。そのため、上記の例は以下の方法でもっとコンパクトに書き換えることができる。
<WITH><PREFIX
name="User.">
<REF name="Shipping.Postal.City"
value="Boston"/>
<REF name="Home.Telecom.Phone.IntCode"
value="1"/>
<WITH><PREFIX
name="Business.Postal.">
<REF name="Street" value="12
Main St."/>
<REF name="City"
value="Cambridge"/>
... (the other
values of User.Business.Postal.) ...
</PREFIX></WITH>
... (the other values of
User.Business.) ...
</PREFIX></WITH>
注意：1つのタグ（<PREFIX>だけ）の代わりに2つのタグ（<WITH><PREFIX>）を使う理由は、技術的に RDFエンコードを用いているからである。
| [36] | datablock |
= |
*datareference | ( *datareference "<WITH><PREFIX" " name=" quoted-string [" dataschema=" quoted-string] [" optional=" quoted-string] [" value=" quoted-string] [" type=" quoted-string] [" typeschema=" quoted-string] [" template=" yesno] [" category=" quoted-string] [" short=" quoted-string] [" long=" quoted-string] ">" datablock "</PREFIX></WITH>" datablock ) |
Category は、データエレメントの属性であり、ユーザとユーザエージェントにデータの意図した使い方のヒントを与える。Categoryは、P3P ユーザエージェントの実施や使用を簡単にするために必要である。これにより、ユーザがデータの交換においてより一般的なプリファレンスやルールを表現することができる。Categoryは、新しいエレメントを定義したり、データを作るために参照したりする時にしばしば含まれる。
Categoryの中のデータエレメントのメンバーシップは、一般的にばらばら（disjoint）である。ほとんどのデータエレメントは、１つのcategoryに属さなければならないが、必要であればそれらは複数のcategoryに属する場合もある。さらに、データセットは、エレメントが属する全てのcategoryに属する。基本データエレメントは全てP3P仕様書のデフォルトcategoryに割り当てられている。サービスが新しいデータエレメントをproposeする時そのプロポーザルは、デフォルトcategoryかエレメント用の categoryを含んでいなければならないが、ユーザやユーザエージェントは、category割り当てに対する最終的な制御権を持っている。
| [37] | categories |
= |
`"` *(data-category ",") data-category `"` |
| [38] | data-category |
= |
"0" | ; Physical Contact Information "1" | ; Online Contact Information "2" | ; Unique Identifiers "3" | ; Financial Account Identifiers "4" | ; Computer Information "5" | ; Navigation and Click-stream Data "6" | ; Transaction Data "7" | ; Preference Data "8" | ; Demographic and SocioEconomic Data "9" ; Content |
categoryに関する詳しい説明は、P3P Harmonized Vocabulary Specificationを参照のこと。
サービスはユーザレポジトリに情報を書き込むように命令する能力を持っている。P3Pエージェントが以下のリクエストをプロポーザルの一部として受け取った場合を考えてみてもらいたい。
<STATEMENT action="r" purp="2" id="0"/>
<REF name="ID.PUID"/>
<REF name="User.Name.First"/>
</STATEMENT>
<STATEMENT action="rw" purp="2" id="0">
<REF name="FineShoes.shoesize"
dataschema="http://www.FineShoes.com/Schema1.0"
/>
</STATEMENT>
ユーザは、このプロポーザルに同意するかどうか聞かれたら、指示するかも知れない。 そして、User.PersonName.Firstを自動的に埋め込んだ(ユーザがそれを前に入力したと仮定して)インタフェースのフォーム とFineShoes.shoesize用の空のフィールドが表示される。ユーザは、この情報を入力し、TXDを送信する。
The user sends:
<TXD r="200" agreeID="94df1293a3e519bb">
<REF name="User.Name.First" value="Josephine"/>
<REF name="ID.PUID" value="1234567"/>
<REF name="FineShoes.Shoesize"
dataschema="http://www.FineShoes.com/Schema1.0"
value="7"/>
</TXD>
属性"rw"がデータエレメントに適用される場合や新しい値がユーザから提供される場合は必ずユーザエージェントはデータレポジトリへの書き込みをやってみなければならない。もし、これに失敗したらエージェントは、適切なレスポンスコードを戻さなければならない。この自動書き込みによってサービスがユーザエージェントに情報を戻す手間が省ける。しかし、サービスは、いつでも(TXD)を送るかも知れない。例えば、ーザが靴サイズ７という情報を提供しても、サービスは、ヨーロッパサイズに変換し、その値を代わりに書き込む。
P3Pに期待される特徴というのは、サービスが任意にエレメントに対し、行動（read & waite）を要求することができるということと、間接的にオプション的なクオリファイヤ(purposes, recipients, identifiable usage)をエレメントに適用することである。
エレメントに対する任意のaction(read or read & write) というのは記述しやすい。オプション的な要素は、<REF>タグのoptional属性によって表される。読み取りや書き込みのためにオプション的に要求されるが、クライアントは受け入れられないこれらのエレメントは、単に作用しない。データは戻されたり書き込まれたりしない。
オプションのクオリファイヤを表示するのは問題がある。 エレメントが処理を終了するのに必要とされるがオプションでダイレクトマーケティングのために要求される場合は、エレメントを単に返却することはユーザが何に同意したかのあいまいな表現になる。従って、あいまいさを避けるために以下のことが必要になる。
例えば、あるサービスが取引を成立させるためにお届け先情報を必要とし、またオプション的にこのデータの全てをマーケティング目的に使いたい場合、以下の２つのプロポーザルを送る必要がある。
<?xml:namespace
ns="http://www.w3.org/TR/1998/WD-P3P10-syntax-19980702/proposal.dtd"
prefix="P3P"?>
<?xml:namespace ns="http://www.w3.org/TR/WD-rdf-syntax#"
prefix="RDF"?>
<PROP agreeID="1e3a5d71297d104f>"
realm="http://www.CoolCatalog.com/catalogue/">
<USES>
<STATEMENT purp="2" id="1"
consq="We can ship your order to your door
step">
<REF name="User.ShipTo."/>
</STATEMENT> </USES>
<DISCLOSURE
text="http://www.CoolCatalog.com/PrivacyPractice.html"
access="3" other="0,1"/>
</PROP>
<PROP agreeID="2e3a5d71297d104f"
realm="http://www.CoolCatalog.com/catalogue/"
optional="1"> ; note optional is in
header.
<USES>
<STATEMENT purp="4" id="1"
consq="We will send you our world-renown
catalogue!">
<REF
name="User.ShipTo."/>
</STATEMENT> </USES>
<DISCLOSURE
text="http://www.CoolCatalog.com/PrivacyPractice.html"
access="3" other="0,1"/>
</PROP>
１つの複雑なプライバシーポリシーを表示するのに複数のプロポーザルを使用する場合は、以下のルールに従う必要がある。
我々の例では、ユーザが取引の完成のお届け先情報を使用するプロポーザルだけに同意する場合、その同意IDに基づいた情報を返す。
<TXD r="200" agreeID="1e3a5d71297d104f" />
<WITH><PREFIX name="User.ShipTo.">
<REF name="Postal.Name" value="Josephine
Hound"/>
...
<REF name="Telecom.Phone.Number"
value="2532442"/>
</PREFIX></WITH>
この解決策が、複数のプロポーザルとデータ転送において、冗長な情報の 転送を引き起こす可能性があることに注意。しかしこれは、彼らが同意した 曖昧なプロポーザルの一部を送り返すことよりも望ましい
プロポーザル の中で、新しいデータエレメントとデータセットを作成することができる。これは、未知のデータエレメント またはデータセットの参照がそのプロポーザルの中で 生じた時に起こる。そのような場合、ユーザーが同意すれば、新しいデータエレメントはユーザのレポジトリの中で作成される。新しいデータエレメントを作成するためには、エージェントは以下のことが必要になる：名前、付属するデータスキーマ,カテゴリ、データタイプ（タイプが定義されたデータスキーマ）、ショートディスプレイネーム（表示用の短縮名）。
また、サービスは特別なスキーマ定義の形でデータエレメントを詳細に説明する。この情報は、以下の２通りの方法で提供される。
情報が内部表示で元のサーバURIがデータスキーマURIと一致しない場合、メインデータスキーマ内の情報は、情報の一貫性を証明するためにチェックされなければならない。もしくは、メインデータスキーマ内の情報は、一貫性を証明するためにチェックされても良い。一致しない場合、530理由コード (Invalid Format)は返却されなければならない。ユーザーが必要な情報を再構築することができない理由が他にある場合、433理由コード (Data Unavailable)が返されなければならない。
新しいデータスキーマの書式は、特別なフォーム記述である。
<?xml:namespace ns="http://www.w3.org/TR/1998/WD-P3P10-syntax-19980702/proposal.dtd" prefix="P3P"?> <?xml:namespace ns="http://www.w3.org/TR/WD-rdf-syntax#" prefix="RDF"?> <PROP><USES><STATEMENT> .... </STATEMENT></USES></PROP>
データブロックは、<data>タグの中に入っており、データエレメントの参照を含んでいる。参照は、 <REF>タグとその属性を使用して作ることができる。
name (データエレメント の名前を定義する。)
category （categoryを定義する。）
type (type を定義する。)
typeschema (type が定義されているdata スキーマを定義する。)
short (short display nameを定義する。63字未満。)
long (データ項目のより長い表現を提供する。511字未満。)
sizelong (データのバイト形式で最大サイズを提供する。)
<PREFIX>タグは、データ転送のように共通のprefixと多くの<REF>属性を連携させることによって スキーマ定義を短くするために使うことができる。
各データ転送のために、long以外の情報は全て必要である。属性の１つが欠けていた場合、空の文字列と共に存在すると考えられる。typeschemaの場合は、空の文字列は特別な意味を持ち、typeschemaはdataschema属性の値と同じになる。
例えば、HyperSpeedという会社が以下のデータスキーマを構築したがっていると考えてみて欲しい。
car.model
car.color
car.built.year
car.built.where. (of basic type Postal.)
car.price
bike.model
bike.color
bike.built.year
bike.built.where. (of basic type Postal.)
bike.price
それから、この会社は、以下のコードをhttp://www.HyperSpeed.com./models-schemaに置くことができる。
<?xml:namespace ns="http://www.w3.org/TR/1998/WD-P3P10-syntax-19980702/proposal.dtd" prefix="P3P"?> <?xml:namespace ns="http://www.w3.org/TR/WD-rdf-syntax#" prefix="RDF"?> <PROP><USES><STATEMENT> <WITH><PREFIX name="car." short="Car" category="7" size="63"> <REF name="model" type="Text" short="Model"/> <REF name="color" type="Text" short="Color"/> <WITH><PREFIX name="built." short="Construction data"> <REF name="year" type="Number" short="Year"/> <REF name="where." type="Postal."/> </PREFIX></WITH> </PREFIX></WITH> <REF name="bike." type="car." typeschema="http://www.HyperSpeed.com/models-schema" short="Bike "/> </USES></STATEMENT></PROP>
データセットが作成されるたびにそれは上記のcar.の場合のように暗黙にtypeとして使用されることができる。しかし、いくつかの状況において、elementをユーザのレポジトリに作成せずにtypeを定義したい場合もある。このような時は、<REF>の中にtemplate属性を使うこと。値をyes, つまりtemplate="1"(defaultは"0"で意味は"no")に設定することは、対応するデータエレメントがtype定義の一部であることを意味し、実際に関連した値を持つデータエレメントを表現しているわけではない。例えば、HyperSpeedは汎用のGenericModel.タイプを定義したがっていて、それをcar.とbike.で例示したがっている。これは、以下のスキーマで表現することができる。
<?xml:namespace ns="http://www.w3.org/TR/1998/WD-P3P10-syntax-19980702/proposal.dtd" prefix="P3P"?> <?xml:namespace ns="http://www.w3.org/TR/WD-rdf-syntax#" prefix="RDF"?> <PROP><USES><STATEMENT> <WITH><PREFIX name="GenericModel." template="1" category="7" size="63"> <REF name="model" type="Text" short="model"/> <REF name="color" type="Text" short="color"/> <WITH><PREFIX name="built." short="Construction data"> <REF name="year" type="Number" short="Year"/> <REF name="where." type="Postal."/> </PREFIX></WITH> </PREFIX></WITH> <REF name="car." type="GenericModel." typeschema="http://www.HyperSpeed.com/models-schema" short="Car"/> <REF name="bike." type="GenericModel." typeschema="http://www.HyperSpeed.com/models-schema" short="Bike"/> </USES></STATEMENT></PROP>
以下は、基本データセットとエレメントである。これらのデータセットとエレメントは、サービスや
ユーザエージェントにる変更や削除ができない。しかし、ユーザは任意の値を提供することができる。例えば、ユーザエージェントは値を返さなかったり、ユーザによって異なる値を返したりする。将来、他のデータセットやエレメントに対する要求が増すであろうと予想する。
明らかに適用できるものは、カタログ、支払い、agent/system attribute schemaである。（システム
構成要素の幅広い組み合わせが、http://www.w3.org/TR/NOTE-agent-attributesに基づいて、white paper draftで適用されている。）
以下の各表は、データセット、データセット内のエレメント、エレメントに関連するカテゴリ、データセットやエレメントのタイプ、ユーザに見せる表示名を示している。１つのエレメントに１つ以上のカテゴリが関連付けられることもある。しかし、基本エレメントには、可能な限り１つ以上のカテゴリが関連付けられないように基本カテゴリを設計している。データスキーマを設計する場合は同様に設計することを推奨する。
ID.データセットは、１つのサービスでユーザを一意的に識別するために使われるエレメントを含む。
| ID. | Category | Type | Short display name |
| PUID | Unique Identifiers | Number | Pairwise or Site ID |
| TUID | Unique Identifiers | Number | Temporary or Session ID |
TUIDは、与えられたセッションの状態を保存するために使われる。PUIDは、複数のセッションにわたる状態を保存するために使われる。TUIDやPUIDは、ユーザ自信が自分を識別したり、複数のサイトで１つの一意的な識別子を共有するよう要求することを意味するものではない。どちらかというと、次のような意味でIDは一意であると言える。例えば、ある２つのユーザを管理するユーザエージェントがサイト＜Cool.Com＞との間でIDを生成した場合、それぞれのIDはサイト
User.データセットは、個人に関する一般的な情報を含む。
注意しなければならないのは、User.データセットは、それ自身がデータセットであるエレメントを含むということ。User.データセットに含まれるデータセットに関しては、「5.2 Data Types」で定義されている。データセットに含まれる各エレメントの表示名は、データセットとエレメントの表示名をコンマ','で区切って連結することで定義される。例えば、User.Home.Postal.PostCodeの表示名は、"User's Home Contact Information, Postal Address Information, Postal Code"となる。ユーザエージェントによっては、上記のように連結された表示名でなく、各エレメント用の表示名を生成するかも知れない。
Date.タイプは、日付を表す構造体。
PersonName.タイプは、個人の名前に関する情報を表す構造体。
PhoneNum.は電話番号を表す構造体。
Info.タイプは、構造化され、他のタイプに再度向けられるものである。たとえ要求の中で省略した表記を使うことを望んでいても、データ要求が必要のない情報を集める必要がないよう実行される。
Telecom.タイプは、個人の連絡先を表す構造体。
Online.タイプは、個人のオンラインアドレス情報を表す構造体。
例えば、P3P仕様で収集されないHTTPデータ収集活動を参照したい場合など、関連したデータの値を
持たないデータエレメントが必要になる場合がある。このような特別なエレメントはabstractと呼ばれる。abstractエレメントが他のエレメントと同じstatementに記述されている場合、以前データabstractな方法で収集されたことを意味し、おそらく、サービスがその情報をユーザの個人情報テーブル内の特殊なエレメントに対して読み書きを行う。abstractエレメントは、名前の最後に"_"が付いている。
上記abstractエレメントは、サービスがP3Pデータ転送要求以外の方法によるデータ収集を宣言することを可能とする。
abstractエレメントは、度々、ナビゲーションやWeb相互作用に潜在している。abstractエレメントは、abstractな方法で収集された情報のタイプを表すためにカテゴリとして使われるだろう。"Form.Data_"は、HTML形式やJava(スクリプト)インターフェースのような、サービスで制御される情報収集方法を含む。"Form.SearchText_"は、検索のサイトや索引のサイトで使われる形式で、特殊なタイプである。従って、検索エンジンページ上の唯一の形式フィールドが検索フィールドであるならば、データエレメントを開示することだけが必要である。
P3Pはプロポーザルやデータセットを確認する手段としてフィンガープリント（Message Digest,Hash）を用いる。これらのフィンガープリントはハッシュ関数を一連のデータに適用することで得られるある一定サイズの値を与える。フィンガープリントは容易に計算できるが、元の情報にほんの少しだけ修正を加えても、フィンガープリントは異なった値になる。従って、フィンガープリントはしばしば情報の完全性を保証する手段として用いられる。我々はP3Pのフィンガープリント用にMD5ダイジェストアルゴリズムを用いる。これはP3P通信の中で暗号化され交換される128ビットの値を与えるものである。エージェントとサービスの双方は、与えられたプロポーザルの参照と処理の完全性を保証するために（フィンガープリントに対するプロポーザルの正当性を確認しながら）これらのフィンガープリントを用いることができる。
フィンガープリントを生み出すプロセスは相当シンプルなものである。フィンガープリントが同一であるためには、送信者と受信者によってフィンガープリント化されるデータが同一でなければならない。我々の目的は、仲介者のあらゆる改ざん努力を無駄にさせるため、データが標準形式（正規化）にフィンガープリント化されるよう推し進めることである。そうなれば我々はフィンガープリントを生成するために、正規化されたバージョンのプロポーザルを使うことになる。同じプロポーザルが与えられれば、サービスとエージェントの双方は同じフィンガープリント値に到達できなければならない。
一例として、次のXMLを検討してもらいたい。
正規化の後、次のようになる。
いったんプロポーザルが正規化されると、P3Pフィンガープリントを生成するためにMD5アルゴリズムが使われる。このセクションではMD5の概略の提供と、いかにしてMD5ダイジェストが暗号化されるかの説明を行う。
MD5ハッシュアルゴリズムは以下で定義されている。
MD5（Message Digest 5）は、暗号化メッセージ要約アルゴリズムである。
MD5はRon Rivestにより設計された。彼は1991年のRSAの"R"でもある。MD5はRFC1321に記述されている。CのソースコードがRFCに含まれている。MD5は基本的には"安全ベルト"付きのMD4であり、MD4よりわずかに速度が遅いがセキュリティ度は高い。アルゴリズムは4つの異なるラウンドから成り、それらはMD4のものとはわずかに異なる設計になっている。メッセージ要約サイズは同じ。Den BoerとBosselaers(B.den BoerとA.BosselaersのMD5圧縮機能の不一致。Advances in Cryptology-Eurocrypt'93の293〜304ページ、Springer-Verlag、1994に書かれている。)はMD5の偽の不一致を見つけた(RSA FAQ Question 98を参照)が、他には暗号解読結果について何も知られていない。
MD5アルゴリズムは、入力として任意の長さのメッセージを受け取り、出力として128ビットの"フィンガープリント"または入力の"メッセージ要約"を生成する。同じメッセージ要約を持つ2つのメッセージを作ることや、前もって指定されたメッセージ要約を持つメッセージを作ることは、コンピュータでできないものと思われる。MD5アルゴリズムはデジタル署名アプリケーションを意図している。そこでは大きなファイルは、RSAやPGPのような公開鍵暗合方式の下で個人（秘密）鍵によって暗号化される前に、あるセキュアな方法で圧縮されなければならない。
MD5のさらに詳しい情報は、以下を参照のこと。
MD5要約で計算すると、4つの32ビット値が生じる。すべての値は、2の補数表現を含むバイト列を標準的なBase64の表現で暗号化される。このバイト列の最初のバイトはhigh-orderバイトである。最小限の数のバイトが値を表現するために使われているため、使われないバイトが含まれていてはいけない。
以下のBNFはどのようにしてMD5要約がP3P用に暗号化されるかを示している。
DTDのHypertextバージョンが以下にある。注意：URIのパスは指定URIを実際には指しておらず、HTMLバージョンを指している。しかし以下に指定されたURI中のパスはこの仕様書の例の中で使われているものである。
このシナリオは、シナリオ1,5および3に基づいており交渉を含んでいる。
ユーザはブラウザでCoolCatalogのホームページに行く。彼女は以前に一度もそこに行ったことがない。彼女は、自分のブラウザがP3Pを理解することを伝えることにより、要求の一部としてP3Pプロポーザルを要求する。
CoolCatalogはプロポーザルを送信する。それはプライバシープラクティス、情報開示、それらが当てはまるデータエレメントを含んでいる。この例では、サービスは将来自動的にReturnIDの一部としてPUIDが与えられることを要求し、ユーザレポジトリからユーザの性別を要求する。
[注意：プロポーザルは読みやすいように複数の行にまたがって分割されている。ネットワーク上で、一対のCRLFが</PROP>だけの後ろに追加される。以下の例でも同様。]
ユーザはこのプロポーザルを拒否する。上記のプロポーザルの同意ID(hash)が
"e3a5d71297d104f1"だと仮定する。ユーザの次のHTTP要求は次のようになるだろう。
サイトは新たなプロポーザルを提供し、今度は自動的なReturnIDを要求し、ユーザレポジトリからファーストネーム（名前）およびオプションで年齢を、共にサイトをカスタマイズする目的で要求する。
ユーザは自動的なReturnIDとカスタマイズだけのためにファーストネームを用意することに同意する。上記のプロポーザルの同意IDが"94df1293a3e519bb"だと仮定する。
この時点で、サービスはCoolCatalogのホームページを返す。
ユーザは1日後サイトに戻り、自動的にReturnIDを送る。
しかし、サーバは再びユーザのファーストネームを必要とし、以前の同意の下でそれを要求する。
ユーザは自分のファーストネームとPUIDを返す。
サービスはその後、以前のようにホームページで応答する。
P3Pの正式な文法は、http://info.internet.isi.edu/in-notes/rfc/files/rfc2234.txtで定義されたABNFを若干修正したものを使いながらこの仕様書の中に示されている。以下は、ABNFの簡単な表現である。
その他の表記として、
この作業は他のドキュメントに基づいた。特に、
同様に、
User.
Category
Type
Short display name
Name.
Physical Contact Information, Demographic and SocioEconomic Data
PersonName.
User's Name
Bdate.
Demographic and SocioEconomic Data
Date.
User's Birth Date
Cert
Unique Identifiers
Text
User's Identity Certificate
Gender
Demographic and SocioEconomic Data
Gender
User's Gender
Employer
Demographic and SocioEconomic Data
Text
Name of User's Employer
Department
Demographic and SocioEconomic Data
Text
Department or division of organization where user is employed
JobTitle
Demographic and SocioEconomic Data
Text
User's Job Title
Home.
Physical Contact Information,
Online Contact Information, Demographic and SocioEconomic DataInfo.
User's Home Contact Information
Business.
Physical Contact Information,
Online Contact Information, Demographic and SocioEconomic Data Info.
User's Business Contact Information
BillTo.
Physical Contact Information,
Online Contact Information, Demographic and SocioEconomic DataInfo.
User's Billing Address
ShipTo.
Physical Contact Information,
Online Contact Information, Demographic and SocioEconomic DataInfo.
User's Shipping Address
5.2 Data Types
Date.
Category
Type
Short display name
Year
Demographic and SocioEconomic Data
Number
Year
Month
Demographic and SocioEconomic Data
Number
Month
Day
Demographic and SocioEconomic Data
Number
Day
Hour
Demographic and SocioEconomic Data
Number
Hour
Minute
Demographic and SocioEconomic Data
Number
Minute
Second
Demographic and SocioEconomic Data
Number
Second
FractionSecond
Demographic and SocioEconomic Data
Number
Fraction of Second
TimeZone
Demographic and SocioEconomic Data
Text
Time Zone
PersonName.
Category
Type
Short display name
Prefix
Demographic and SocioEconomic Data
Text
Name Prefix
First
Physical Contact Information
Text
First Name
Last
Physical Contact Information
Text
Last Name
Middle
Physical Contact Information
Text
Middle Name
Suffix
Demographic and SocioEconomic Data
Text
Name Suffix
Nickname
Demographic and SocioEconomic Data
Text
Nickname
PhoneNum.
Category
Type
Short display name
IntCode
Physical Contact Information
Number
International Phone Code
LocCode
Physical Contact Information
Number
Local Phone Area Code
Number
Physical Contact Information
Number
Phone Number
Ext
Physical Contact Information
Number
Phone Extension
Comment
Physical Contact Information
Text
Phone Optional Comments
Info.
Category
Type
Short display name
Postal.
Physical Contact Information, Demographic and SocioEconomic
Data
Postal.
Postal Address Information
Telecom.
Physical Contact Information
Telecom.
Telecommunications Information
Online.
Online Contact Information
Online.
Online Address Information
Postal.タイプは、住所を表す構造体。
Postal.
Category
Type
Short display name
Name.
Physical Contact Information, Demographic and SocioEconomic
Data
PersonName.
Name
Street
Physical Contact Information
Text
Street Address
City
Physical Contact Information
Text
City
StateProv
Physical Contact Information
Text
State or Province
PostalCode
Demographic and SocioEconomic Data
Text
Postal Code
CountryCode
Demographic and SocioEconomic Data
Country
Country
Country
Demographic and SocioEconomic Data
Text
Country String
Telecom.
Category
Type
Short display name
Phone
Physical Contact Information
PhoneNum.
Phone Number
Fax
Physical Contact Information
PhoneNum.
Fax Number
Mobile
Physical Contact Information
PhoneNum.
Mobile Phone Number
Pager
Physical Contact Information
PhoneNum.
Pager Number
Online.
Category
Type
Short display name
Email
Online Contact Information
Text
Email Address
URI
Online Contact Information
URI
Home Page Address
この仕様書では、[XML1.0]、[HTTP1.1]、[XML-Data]をもとにした、以下の基本データエレメントで
示されるデータタイプを使用している。
Primitive DataType
Definition
Text
[UTF-8]
Gender
Text of character "M" or "F".
Boolean
Text of character "0" or "1".
Binary
Base64 per
RFC-1531.
[[MIME]]
Number
Text of characters composed with the digits "0", "1", "2",
"3", "4", "5", "6", "7", "8", "9".
UUID
[UUID]
Country
[ISO3166]
URI
[URI]
5.3 Abstract Elements
Category
Type
Short display name
ClickStream.Client_
Navigation and Click-stream Data, *
Boolean
Click-stream collected on the server
ClickStream.Server_
Boolean
Click-stream collected on the client
StoreNegotiation_
Transaction Data
Boolean
Server stores the negotiation history
Form.Data_
*
Boolean
Data entered through forms
Form.SearchText_
Transaction Data
Boolean
Search terms
6. Appendices（付録）
6.1 Appendix 1: References （Normative:規範）
Appendix 2: Fingerprints and
Canonicalization (Normative:規範)
プロポーザルの正規化ルール：
<rdf:rdf><PROP agreeID="94df1293a3e519bb"
realm="http://www.CoolCatalog.com/catalogue/" entity="CoolCatalog"
assurance="http://www.TrustUs.org">
<USES>
<STATEMENT consq="A site with clothes you'd appreciate."
purp="2,3" recpnt="0" id="0">
<WITH><PREFIX name="User.">
<REF name="Name.First"/>
<REF name="Bdate.YEAR" optional="1"/>
<REF name="Gender"/>
</PREFIX></WITH>
</STATEMENT>
</USES>
<USES>
<STATEMENT action="rw" purp="0" recpnt="0" id="1">
<REF name="User.shipping."/>
</STATEMENT>
</USES>
<DISCLOSURE discURI="http://www.CoolCatalog.com/PrivacyPractice.html"
access="3" other="0,1"/>
</PROP></rdf:rdf>
<PROP agreeID="94df1293a3e519bb" realm="http://www.CoolCatalog.com/catalogue/" entity="CoolCatalog" assurance="http://www.TrustUs.org">
<USES>
<STATEMENT consq="A site with clothes you'd appreciate." purp="2,3" recpnt="0" id="0">
<WITH>
<PREFIX name="user.">
<REF name="name.first"/>
<REF name="bdate.year" optional="1"/>
<REF name="gender"/>
</PREFIX>
</WITH>
</STATEMENT>
</USES>
<USES>
<STATEMENT action="rw" purp="0" recpnt="0" id="1">
<REF name="user.shipping."/>
</STATEMENT>
</USES>
<DISCLOSURE discuri="http://www.CoolCatalog.com/PrivacyPractice.html" access="3" other="0,1"/>
</PROP>
MD5フィンガープリントの生成
The MD5 Message Digest Algorithm, R.L. Rivest,
RFC 1321, April 1992
resource-hash = '"base64-string encoding of 128 bit MD5 message
digest of the information resource."'
base64-string = as defined in RFC-1521, section 5.2.
Appendix 3: XML DTDs (Non-normative)
Appendix 4: Line-flow Scenario (Non-normative)
GET / HTTP/1.1
Accept: */*
User-Agent: BugblatterBeast/3.02 (RT-11; English)
Host: www.CoolCatalog.com
OPT: "http://www.w3.org/TR/1998/WD-P3P10-syntax-19980702/proposal.dtd"; ns-42
HTTP/1.1 409 Agreement required
Server: Marvin/2.0.1
OPT: "http://www.w3.org/TR/1998/WD-P3P10-syntax-19980702/proposal.dtd"; ns-1944
1944-P3P1.0: <?xml:namespace ns="http://www.w3.org/TR/1998/WD-P3P10-syntax-19980702/proposal.dtd" prefix="P3P"?>
<?xml:namespace ns="http://www.w3.org/TR/WD-rdf-syntax#" prefix="RDF"?>
<PROP realm="http://www.CoolCatalog.com/" entity="CoolCatalog"
assurance="http://www.TrustUS.org" />
<USES>
<STATEMENT purp="2" id="0" recpnt="0" consq="a personalized site!"/>
<REF name="Web.PUID"/>
<REF name="User.Gender"/>
</STATEMENT>
</USES>
<DISCLOSURE text="http://www.CoolCatalog.com/PrivacyPractice.html"
access="3" other="0,1"/>
</PROP>
</P3P>
Content-Type: text/html
Content-Length: 110
<html><body>
<h1>HTTP/1.1 409 Agreement Required</h1>
<p>We need an agreement before we can continue.</p>
</body></html>
GET / HTTP/1.1
Accept: */*
User-Agent: BugblatterBeast/3.02 (RT-11; English)
Host: www.CoolCatalog.com
OPT: "http://www.w3.org/TR/1998/WD-P3P10-syntax-19980702/proposal.dtd "; ns-1776
1776-P3P: <SRY r="432" agreeID="e3a5d71297d104f1" />
HTTP/1.1 409 Agreement required
Server: Marvin/2.0.1
OPT: "http://www.w3.org/TR/1998/WD-P3P10-syntax-19980702/proposal.dtd"; ns-1492
1492-P3P1.0: <?xml:namespace ns="http://www.w3.org/TR/1998/WD-P3P10-syntax-19980702/proposal.dtd" prefix="P3P"?>
<?xml:namespace ns="http://www.w3.org/TR/WD-rdf-syntax#" prefix="RDF"?>
<PROP realm="http://www.CoolCatalog.com/" entity="CoolCatalog"
assurance="http://www.TrustUs.org"/>
<USES>
<STATEMENT purp="2" id="0" consq="a personalized site!">
<WITH><PREFIX name="User.">
<REF name="Name.First"/>
<REF name="Bdate.Year" optional="1"/>
</PREFIX></WITH>
<REF name="Web.PUID"/>
</STATEMENT>
</USES>
<DISCLOSURE text="http://www.CoolCatalog.com/PrivacyPractice.html"
access="3" other="0,1"/>
</PROP>
</P3P>
Content-Type: text/html
Content-Length: 110
<html><body>
<h1>HTTP/1.1 409 Agreement Required</h1>
<p>We need an agreement before we can continue.</p>
</body></html>
GET / HTTP/1.1
Accept: */*
User-Agent: BugblatterBeast/3.02 (RT-11; English)
Host: www.CoolCatalog.com
OPT: "http://www.w3.org/TR/1998/WD-P3P10-syntax-19980702/proposal.dtd"; ns-1861
1861-P3P1.0: <TXD r="200" agreeID="94df1293a3e519bb" >
<REF purp="2" name="User.Name.First" value="Josephine"/>
<REF purp="2" name="User.PUID" value="1234567"/>
</TXD>
HTTP/1.1 200 OK
Server: Marvin/2.0.1
OPT: "http://www.w3.org/TR/1998/WD-P3P10-syntax-19980702/proposal.dtd"; ns-1950
1950-P3P: <OK DH="s24fd20kuqexg5xk" />
Content-Type: text/html
Content-Length: xxx
[content of the CoolCatalog homepage]
GET / HTTP/1.1
Accept: */*
User-Agent: BugblatterBeast/3.02 (RT-11; English)
Host: www.CoolCatalog.com
OPT: "http://www.w3.org/TR/1998/WD-P3P10-syntax-19980702/proposal.dtd "; ns-2001
2001-P3P: <TXD agreeID="94df1293a3e519bb" >
<REF name="User.PUID" value="1234567"/>
</TXD>
HTTP/1.1 409 Agreement required
Server: Marvin/2.0.1
OPT: "http://www.w3.org/TR/1998/WD-P3P10-syntax-19980702/proposal.dtd"; ns-2010
2010-P3P: <PROP agreeID="94df1293a3e519bb"/>
</PROP>
</P3P>
Content-Type: text/html
Content-Length: 70
<html><body>
<h1>HTTP/1.1 400 Agreement Required</h1>
</body></html>
GET / HTTP/1.1
Accept: */*
User-Agent: BugblatterBeast/3.02 (RT-11; English)
Host: www.CoolCatalog.com
OPT: "http://www.w3.org/TR/1998/WD-P3P10-syntax-19980702/proposal.dtd"; ns-1968
1968-P3P1.0: <TXD agreeID="94df1293a3e519bb" >
<REF name="User.Name.First" value="Josephine"/>
<REF name="User.PUID" value="1234567"/>
</TXD>
HTTP/1.1 200 OK
Server: Marvin/2.0.1
OPT: "http://www.w3.org/TR/1998/WD-P3P10-syntax-19980702/proposal.dtd"; ns-1950
1950-P3P1.0: <OK DH="s24fd20kuqexg5xk" />
Content-Type: text/html
Content-Length: xxx
[content of the CoolCatalog homepage]
Appendix 5: ABNF Notation (Non-normative)
name = (element)
(element1 element2)
<a>*<b>element
<a>element
<a>*element
*<b>element
*element
[element]
"string" or 'string'
Appendix 6: Working Group Contributors
(Non-normative)
Lorrie Cranor
AT&T
Philip DesAutels
Matchlogic
Melissa Dunn
Microsoft
Daniel Jaye (Editor)
Engage Technologies
Kevin Jones
Intermind
Steve Lucas (Chair)
Matchlogic
Massimo Marchiori (Editor)
W3C
Maclen Marvit
Narrowline
Max Metral
Firefly Network Inc.
Paul Perry
Firefly Network Inc
Martin Presler-Marshall
IBM
Joseph Reagle (Project Manager)
W3C
Drummond Reed
Intermind