Veuillez consulter la liste des errata →vf de ce document, laquelle peut contenir des corrections normatives.
Voir aussi d'éventuelles traductions.
Copyright ©2002 W3C™ (MIT, INRIA, Keio), Tous droits réservés. Les règles de responsabilité, de nom de marque, d'utilisation du document et d'octroi de licence logicielle du W3C s'appliquent.
Ce document constitue la spécification de la plateforme pour les préférences de confidentialité (P3P). Avec ses références normatives, il contient toutes les indications nécessaires pour la mise en œuvre d'applications P3P interopérables.
Ce chapitre décrit le statut de ce document au moment de sa publication. D'autres documents peuvent venir le supplanter. La dernière version de cet ensemble de documents est conservée au W3C.
C'est la recommandation du W3C de la spécification de la plateforme pour les préférences de confidentialité 1.0 (P3P1.0).
Ce document, qui a été revu par les membres du W3C et les tiers concernés, a été approuvé par le Directeur comme recommandation du W3C. C'est un document stable qui peut être utilisé comme matériel de référence ou cité comme norme de référence par un autre document. Le rôle du W3C, en produisant cette recommandation, est de mettre en lumière la spécification et d'en promouvoir le plus large déploiement. Cela participe à améliorer la fonctionnalité et l'interopérabilité du Web.
Ce document a été produit par le Groupe de Travail sur la spécification P3P du W3C, partie de l'activité sur la vie privée du Domaine Technologie & Société du W3C.
On peut consulter les divulgations de brevets concernant cette spécification sur la page de divulgation de brevets →vf de P3P1.0, conformément à la politique de brevetabilité du W3C.
Veuillez signaler les erreurs dans ce documents sur www-p3p-public-comments@w3.org (archives publiques).
La liste des erreurs connues dans cette spécification est disponible à http://www.w3.org/2002/04/P3Pv1-errata.
Seule la version en anglais de cette spécification est normative. Les renseignements concernant les traductions (éventuelles) de ce document sont disponibles à http://www.w3.org/2002/04/P3Pv1-translations.
On peut trouver une liste des rapports techniques courants publics du W3C à http://www.w3.org/TR.
DATA-DEF
et DATA-STRUCT
Le projet de plateforme pour les préférences de confidentialité (P3P) permet aux sites Web d'exprimer leurs politiques de confidentialité dans un format normalisé que les agents utilisateurs peuvent obtenir automatiquement et interpréter aisément. Les agents utilisateurs P3P permettront d'informer les utilisateurs des pratiques des sites (dans des formats lisibles à la fois par une machine et par un humain) et d'automatiser au besoin les prises de décisions en fonction de ces pratiques. Les utilisateurs n'auront donc pas besoin de lire les politiques de confidentialité de chaque site visité.
Bien que le protocole P3P fournisse le moyen technique permettant aux utilisateurs d'être informés des politiques de confidentialité avant de confier des renseignements personnels, il n'offre aucun mécanisme technique qui garantisse le comportement des sites conformément à leurs politiques. Les produits qui mettent en œuvre cette spécification PEUVENT fournir une aide dans ce sens, selon les mises en œuvre en question, mais cela n'est pas traité par cette spécification. Toutefois, le protocole P3P complète les lois et les programmes auto-règlementés définissant des mécanismes d'application. En outre, le protocole P3P ne comprend aucun mécanisme de transport des données ou de sécurisation des données personnelles en transit ou stockées. On peut intégrer P3P à des outils conçus pour faciliter le transport des données. Ces outils devraient inclure les sécurités appropriées.
La spécification P3P1.0 définit la syntaxe et la sémantique des politiques de confidentialité P3P et les mécanismes permettant d'associer les politiques aux ressources Web. Les politiques P3P consistent en déclarations utilisant le vocabulaire P3P afin d'exprimer des pratiques touchant à la vie privée. Les politiques P3P appellent également des éléments du schéma de données de base de P3P, un jeu standard d'éléments de données que tout agent utilisateur P3P devrait reconnaître. La spécification P3P comprend un mécanisme permettant de définir de nouveaux éléments de données et ensembles de données et un mécanisme simple autorisant l'extension du vocabulaire de P3P.
Le protocole P3P version 1.0 est conçu pour informer les utilisateurs du Web des pratiques des sites Web concernant la collecte de données. Il permet à un site Web de transcrire ses pratiques de collecte et d'utilisation des données dans un format XML, lisible par une machine, que l'on appelle politique P3P. La spécification P3P définit :
schéma de données P3P de base;
Le but de P3P version 1.0 est double. Premièrement, permettre aux sites Web d'annoncer leurs pratiques de collecte
de données de manière normalisée, lisible par une machine et facilement disponible.
Deuxièmement, permettre aux utilisateurs du Web de savoir quelles données seront collectées par les sites visités,
comment ces données seront utilisées, et quels usages de ces données ces utilisateurs accepteront
(N.D.T. opt-in)
ou bien refuseront
(N.D.T. opt-out].
En introduction à P3P, prenons un scénario d'utilisation courant où intervient le protocole P3P. Claudia décide de visiter un magasin en ligne appelé CatalogueExemple et situé à http://www.catalog.example.com/. Supposons que la société CatalogueExemple ait placé des politiques P3P sur toutes ses pages et que Claudia utilise un navigateur avec P3P incorporé.
Claudia entre l'adresse de CatalogueExemple dans son navigateur. Celui-ci peut automatiquement récupérer la politique P3P pour la page en question. La politique annonce que les seules données collectées sur la page d'accueil seront celles contenues dans les journaux d'accès HTTP standards. Le navigateur compare maintenant cette politique aux préférences définies par Claudia. Cette politique est-elle acceptable ou bien faut-il la prévenir ? Supposons que Claudia ait défini le comportement comme étant acceptable. Auquel cas, la page d'accueil s'affiche normalement, sans irruption d'un message. Son navigateur peut très bien lui signaler, au moyen d'une petite icone quelque part le long d'un bord de la fenêtre, que le site a transmis une politique de confidentialité qui correspondait à ses préférences.
Claudia clique ensuite sur un lien menant au catalogue en ligne du site. La partie catalogue fait appel à un
programme plus complexe. Ce programme recourt à des cookies pour reproduire les fonctionnalités d'un panier d'achat
.
Comme d'autres renseignements sont collectés dans cette partie du site, le serveur Web fournit une politique P3P distincte
pour celle-ci. En supposant encore que cette politique corresponde aux préférences de Claudia, elle ne reçoit donc aucun message.
Claudia poursuit en sélectionnant les articles qu'elle souhaite acheter. Enfin, elle passe sur la page pour leur règlement.
La page de règlement de CatalogueExemple demande certains renseignements supplémentaires : le nom, l'adresse, le numéro de carte de crédit et le numéro de téléphone de Claudia. Il s'y trouve une autre politique P3P laquelle décrit les données qui seront collectées et déclare que ces données ne seront utilisées que pour la réalisation de la transaction courante, c'est-à-dire la commande.
Le navigateur de Claudia examine cette politique P3P. Imaginons que Claudia ait indiqué au navigateur qu'elle souhaite être avertie lorsqu'un site demande son numéro de téléphone. Auquel cas, le navigateur émettra un message disant que ce site Web demande son numéro de téléphone et en expliquant le contenu de la déclaration P3P. Claudia peut alors décider d'accepter ou non. Si c'est le cas, elle poursuit sa commande, sinon elle peut annuler la transaction.
Autrement, Claudia aurait pu indiquer qu'elle ne voulait être avertie que si un site demandait son numéro de téléphone pour le communiquer à un tiers et/ou l'utiliser pour autre chose que la réalisation de la transaction courante. Auquel cas, elle n'aurait pas du tout été interrogée par son navigateur et aurait poursuivi en concluant son achat.
Remarquer que ce scénario décrit une seule mise en œuvre possible de P3P. D'autres types d'interfaces utilisateurs sont également envisageables.
Les politiques P3P utilisent un codage XML avec des espaces de nommage (cf. [XML] et [XML-Name]) du vocabulaire P3P afin de fournir les coordonnées de l'entité légale responsable des pratiques de confidentialité d'une politique, d'énumérer les types de données ou les éléments de données collectés et d'expliquer la destination des données en question. En outre, les politiques identifient les destinataires des données et divulguent d'autres informations, dont les renseignements pour la résolution des litiges et l'adresse de la politique de confidentialité d'un site écrite pour un humain. Les politiques P3P doivent couvrir tous les éléments de données et pratiques mobilisés. Toutefois, les questions concernant le respect des demandes de renseignement légales ne sont pas traitées par cette spécification. Tout en respectant sa politique de non-redistribution des données à des tiers, un site peut être contraint de le faire par force de loi. Les déclarations P3P sont positives : les sites annoncent ce qu'ils font plutôt que ce qu'ils ne font pas. Le vocabulaire P3P est conçu pour décrire les pratiques d'un site plutôt que d'être juste un indicateur de la conformité à une loi particulière ou un code de conduite particulier. Par contre, on peut développer les agents utilisateurs de façon à tester si les pratiques d'un site sont conformes, ou non, à une loi ou un code.
Les politiques P3P représentent les pratiques du site. Les intermédiaires, tels que les opérateurs de télécommunications, les fournisseurs d'accès Internet, les serveurs mandataires et autres, peuvent avoir connaissance de l'échange des données entre un site et un utilisateur, sans que leurs pratiques ne soient régies par les politiques du site en question. En outre, il faut remarquer que chaque politique P3P s'applique aux ressources Web spécifiques (pages Web, images, cookies, etc.) listées dans un fichier d'appel de politique. Quand une entreprise ou une organisation placent une ou plusieurs politiques P3P sur un site Web, elles ne déclarent pas les pratiques de confidentialité associées aux autres ressources Web non mentionnées dans leurs fichiers d'appel de politique ou aux autres activités en ligne ou hors ligne ne se servant pas des données collectées sur les sites Web couverts par leurs politiques P3P.
Lorsque le vocabulaire P3P n'est pas suffisamment précis pour décrire les pratiques d'un site Web, les sites devraient utiliser les termes du vocabulaire qui correspondent au plus près à leurs pratiques et fournir des explications complémentaires (comme indiqué dans la section 3.2). Par contre, les politiques NE DOIVENT PAS faire de déclarations fausses ou trompeuses.
Les agents utilisateurs P3P1.0 peuvent être intégrés aux navigateurs Web, aux modules d'extension des navigateurs ou aux
serveurs mandataires. Ils peuvent aussi se présenter sous forme d'applets Java ou de
scripts JavaScript, ou être intégrés à des portefeuilles électroniques, des remplisseurs de formulaire automatiques
ou à d'autres outils de gestion des données de l'utilisateur. Les agents utilisateurs P3P recherchent les appels
de politiques P3P dans l'emplacement notoire,
dans les en-têtes P3P des réponses HTTP et dans les balises link
incorporées
à un contenu HTML. Ces appels indiquent l'emplacement des politiques P3P concernées.
Les agents utilisateurs peuvent récupérer la politique à l'endroit indiqué, l'analyser puis afficher des symboles,
émettre des sons ou générer des invites pour l'utilisateur afin de refléter les pratiques de confidentialité P3P d'un site.
Ils peuvent aussi comparer les politiques P3P aux préférences de confidentialité choisies par l'utilisateur
et prendre les mesures appropriées. Le protocole P3P peut faire office de portier
pour les mécanismes de
transfert de données, tels que les portefeuilles électroniques et les remplisseurs de formulaire automatiques.
Un agent utilisateur intégré à l'un de ces mécanismes récupérerait les politiques P3P, les comparerait aux préférences
de l'utilisateur et n'autoriserait la délivrance des données, premièrement, que si la politique est cohérente avec
les préférences de l'utilisateur et, deuxièmement, si le transfert de données requis est cohérent avec la politique en question.
Si l'une de ces conditions n'était pas remplie, l'utilisateur sera informé du désaccord et pourra accorder ou non
la délivrance des données en connaissance de cause.
La spécification P3P1.0 impose peu de contraintes sur l'interface utilisateur des agents utilisateurs. Les développeurs peuvent ainsi choisir les messages et symboles à présenter à l'utilisateur pour les informer de la politique de confidentialité d'un site Web. Les développeurs ne sont pas tenus d'utiliser textuellement les définitions qui se trouvent dans cette spécification pour leurs interfaces utilisateurs. Toutefois, ils devraient s'assurer que les informations présentées à l'utilisateur, quelles qu'elles soient, représentent fidèlement les politiques P3P décrites, comme dans l'Annexe 7 Les principes directeurs de P3P.
Les sites Web peuvent mettre en œuvre P3P1.0 sur leurs serveurs en transcrivant leurs politiques de confidentialité,
lisibles par un humain, vers une syntaxe P3P puis en publiant les fichiers résultants en même temps qu'un
fichier d'appel de politique qui désigne les parties du site concernées par la politique. Des outils automatisés
peuvent assister les opérateurs de site dans cette traduction. On peut mettre en œuvre P3P1.0
sur les serveurs Web existants, conformes à HTTP/1.1, sans autre programme ou mise à jour. Les serveurs peuvent
publier leurs fichiers d'appel de politique dans l'emplacement notoire
ou les appeler avec une balise link
dans un contenu HTML/XHTML. Autrement,
on peut configurer les serveurs compatibles pour qu'ils insèrent une en-tête d'extension P3P dans toutes leurs
réponses HTTP, celle-ci indiquant l'emplacement du fichier d'appel de politique du site.
Les sites Web ont toutes latitudes sur la manière d'utiliser P3P : ils peuvent opter pour une seule politique P3P pour le site en entier ou pour des politiques distinctes pour les différentes parties du site. Une politique P3P DOIT couvrir toutes les données générées ou échangées au cours des interactions HTTP du site avec les visiteurs. En outre, certains sites peuvent souhaiter écrire des politiques couvrant toutes les données collectées par une entité, sans se préoccuper de la manière dont elles l'ont été.
Des pans significatifs des premiers brouillons de la spécification P3P1.0 ont été supprimés pour faciliter la mise en œuvre et accélérer le déploiement d'une première étape P3P. Une future version de la spécification P3P pourra réintégrer ces fonctionnalités après le déploiement de P3P1.0. Cette spécification comportera vraisemblablement des améliorations en fonction des commentaires en retour d'expérience de mise en œuvre et de déploiement et aussi de quatre composants majeurs, appartenant à la vision P3P originale mais non compris dans P3P1.0 :
Ce document, ainsi que ses références normatives, comprend toutes les indications nécessaires pour la mise en œuvre d'applications P3P interopérables.
Les mots-clés suivants, employés tout au long du document, doivent se comprendre comme des conditions pour l'interopérabilité. Cette spécification emploient les termes définis dans RFC2119 [KEY] pour déterminer le caractère d'obligation de chaque condition particulière. Voici ces termes :
obligatoiredésignent une condition nécessaire à la spécification.
recommandésignifient qu'il peut exister, en certaines circonstances, des raisons valables pour ignorer la condition en question mais on devrait envisager toutes les conséquences et soupeser soigneusement le cas avant d'opter différemment.
optionnelindiquent une condition véritablement facultative. Un éditeur peut choisir d'en tenir compte parce qu'un marché particulier l'exige ou parce que celle-ci améliore le produit, par exemple, un concurrent ayant pu l'oublier.
La spécification P3P, sauf en ce qui concerne la section 2.2.2, la
section 2.2.3 et la section 4, définit une syntaxe
XML avec espaces de nommage (cf. [XML] et [XML-Name]).
Par souci de brièveté, on emploiera librement XML
par la suite, au lieu de l'expression plus exacte XML avec espaces de nommage
.
On utilise aussi une notation semblable à BNF pour toute la spécification :
la notation [ABNF] employée ici est spécifiée dans RFC2234
et résumée dans l'Annexe 6. Cependant, dans le cas d'une syntaxe XML, remarquez que
cette syntaxe ABNF n'est qu'une représentation grammaticale utilisée pour faciliter la lecture
(elle manque, par exemple, de toutes les souplesses syntaxiques qui sont implicites dans XML, c'est-à-dire,
les règles concernant les caractères blancs, la citation avec des guillemets simples '
ou des guillemets doubles "
,
le masquage des caractères →vf,
les commentaires, la sensibilité à la casse, l'ordre des attributs, la gestion des espaces de nommage) et, en tant que telle,
elle n'a pas de valeur normative. Toute la syntaxe XML définie dans cette spécification DOIT être conforme au
schéma XML de P3P (cf. l'Annexe 4) qui, avec les autres contraintes
exprimées en langage naturel dans la spécification, constitue la définition normative.
On PEUT utiliser la définition de type de document (DTD), non normative, fournie dans l'Annexe 5 pour vérifier la validité des fichiers P3P. Toutefois, il se peut que certains fichiers valides soient rejetés lors de l'évaluation contre le DTD parce que ceux-ci utilisent des espaces de nommage.
Donc, pour tout ce qui concerne la syntaxe non XML définie dans cette spécification (à savoir, la section 2.2.2 définissant l'en-tête HTTP de P3P, la section 2.2.3 définissant l'usage de P3P dans HTML et la section 4 définissant les politiques compactes), c'est la notation ABNF (avec les autres contraintes exprimées en langage naturel dans cette spécification) qui constitue la définition normative.
user.home-info.postal
". Le schéma de données de base de P3P1.0 définit
un certain nombre de jeux de données.<DATASCHEMA>
.
Le protocole P3P1.0 définit un schéma de données standard appelé
schéma de données P3P de base.serviceet
site Websont souvent interchangeables.
La localisation d'une politique P3P est l'une des premières étapes dans le déroulement du protocole P3P. Les services recourent à des appels de politique pour déclarer quelle politique s'applique à telle adresse URI ou tel jeu d'adresses URI. Les agents utilisateurs recourent à des appels de politique pour localiser la politique de confidentialité appliquée à une ressource Web afin de traiter cette politique pour le bénéfice de l'utilisateur.
Les appels de politique contribuent beaucoup à l'optimisation des performances. Les politiques P3P contiennent généralement plusieurs kilo octets de données, tandis qu'une adresse URI appelant une politique de confidentialité pèse en général moins de 100 octets. En plus des économies de bande passante, les appels de politiques réduisent également les besoins en calcul : les politiques sont en correspondance unique avec les adresses URI et les agents utilisateurs n'ont ainsi besoin d'analyser et de traiter une politique qu'une seule fois au lieu de la traiter avec chacun des documents auxquels elle s'applique. En outre, la centralisation des informations sur les politiques concernées simplifie l'administration du site Web.
On utilise un fichier d'appel de politique pour associer les politiques P3P à certaines régions de l'espace d'adresses URI. Le fichier d'appel de politique est un fichier XML avec espaces de nommage (cf. [XML] et [XML-Name]) qui peut définir la politique d'un seul document Web, ou de tout ou parties d'un site Web. Le fichier d'appel de politique peut désigner une ou plusieurs politiques P3P ; un seul fichier d'appel peut donc couvrir un site entier, même si différentes politiques P3P s'appliquent à différentes parties du site. On utilise le fichier d'appel de politique pour faire une ou toutes les déclarations suivantes :
Toutes ces déclarations sont contenues dans le corps du fichier d'appel de politique.
Cette section décrit le mécanisme servant à localiser un fichier d'appel de politique. On donne également la syntaxe détaillée des mécanismes mis en œuvre.
La localisation du fichier d'appel de politique peut être indiquée en recourant à l'un de quatre mécanismes. Le fichier d'appel de politique peut :
emplacement notoireprédéfini, ou
link
, oulink
, ouRemarquez que, si l'agent utilisateur peut récupérer un contenu HTML (ou respectivement XHTML) via HTTP, il DOIT gérer de façon interchangeable les mécanismes 1, 2 et 3 (et 4 pour XHTML) listés ci-dessus. Voir également les conditions de non-ambiguïté.
Les politiques s'appliquent au niveau des ressources. Une page
, du point de vue de l'utilisateur,
peut se composer de multiples ressources HTTP ; chacune peut se voir associer une politique P3P propre.
En pratique, cependant, le fait de placer beaucoup de politiques P3P différentes sur les diverses ressources
d'une seule page peut compliquer la tâche des agents utilisateurs qui est de restituer cette page et de signaler les politiques mises en jeu
à l'utilisateur. Par conséquent, on recommande aux services d'essayer de construire leurs fichiers d'appel de politique de telle
sorte qu'un seul fichier d'appel couvre la page
en question, afin d'accélérer la session de navigation de l'utilisateur.
Pour qu'un agent utilisateur puisse traiter la politique qui s'applique à une ressource donnée, il doit localiser le fichier d'appel de politique, l'analyser, récupérer toutes les politiques P3P requises puis analyser cette (ou ces) politique(s) P3P.
Ce document ne spécifie pas comment associer les politiques P3P aux ressources Web récupérées par un autre protocole que HTTP. Toutefois, il n'interdit pas le développement futur de mécanismes pour associer les politiques P3P aux ressources récupérées par d'autres protocoles. En outre, d'autres méthodes d'association des politiques P3P aux ressources HTTP sont susceptibles de développements ultérieurs.
Les sites Web utilisant P3P PEUVENT (et ils sont fortement encouragés à le faire) placer un
fichier d'appel de politique dans un emplacement notoire
. Pour cela, on devrait disposer sur le site un
fichier d'appel de politique ayant pour chemin d'accès /w3c/p3p.xml
.
Remarquez que les sites ne sont pas obligés de recourir à ce mécanisme ; toutefois, les sites qui le font sont assurés que leur politique P3P sera accessible aux agents utilisateurs avant toute autre ressource demandée au site. Les agents utilisateurs n'auront plus autant besoin d'accéder au site en recourant à des pratiques de zone sûre. En outre, si c'est la méthode choisie pour le site, le fichier d'appel de politique dans cet emplacement notoire n'est pas obligé de couvrir le site entier. Par exemple, les sites dont le contenu n'est pas tout entier contrôlé par une seule organisation PEUVENT ne pas opter pour ce mécanisme, ou PEUVENT opter pour placer un fichier d'appel de politique ne couvrant qu'une partie limitée du site.
Recourir à l'emplacement notoire pour le fichier d'appel de politique n'empêche pas de recourir à d'autres méthodes de spécification de ce fichier. Des parties du site PEUVENT employer n'importe lequel des autres mécanismes reconnus pour indiquer un fichier d'appel tant que les conditions de non-ambiguïté sont respectées.
Par exemple, imaginons un site de galerie marchande Web tenu par l'entreprise GalerieExemple. Sur leur site Web
(galerie.example.com
), les entreprises offrant des produits ou des services dans cette galerie
disposent d'un sous-arbre propre du site, avec un chemin d'accès comme /entreprises/nom-entreprise
.
L'entreprise GalerieExemple peut choisir de placer un fichier d'appel de politique dans l'emplacement notoire
couvrant le site en entier, sauf le sous-arbre /entreprises
. Ainsi, lorsque l'entreprise ChaussuresExemple place un contenu
à /entreprises/chaussuresexemple
, elle peut utiliser l'un des autres mécanismes pour indiquer la localisation
d'un fichier d'appel de politique couvrant sa partie du site galerie.example.com
.
L'utilisation de l'emplacement notoire pour le fichier d'appel de politique se révèle particulièrement utile
dans le cas d'un site dont le contenu est réparti sur plusieurs hôtes. Par exemple, supposons un site utilisant
pour toutes ses applications Web un hôte logique différent de celui hébergeant son contenu HTML statique.
Les autres mécanismes de localisation du fichier d'appel de politique obligent à récupérer une certaine
adresse URI sur l'hôte concerné pour localiser ce fichier d'appel de politique. Au contraire, ce n'est pas nécessaire
pour l'emplacement notoire. En supposant, par exemple, un formulaire HTML qui se trouve sur www.example.com
et
l'adresse URI de l'attribut "action" de ce formulaire qui conduit au serveur cgi.example.com
.
Le fichier d'appel de politique, qui couvre le formulaire, est incapable de produire une déclaration portant sur
l'adresse URI (de l'attribut "action") traitant le formulaire. L'administrateur du site publie néanmoins
un fichier d'appel de politique à http://cgi.example.com/w3c/p3p.xml
qui couvre l'adresse URI
(de l'attribut "action"), et permet ainsi à un agent utilisateur de localiser facilement la politique P3P qui s'y applique,
avant de soumettre le contenu du formulaire.
Tout document récupéré par HTTP PEUT pointer vers un fichier d'appel de politique au travers d'une nouvelle en-tête de réponse : l'en-tête P3P ([P3P-HEADER]). Si un site utilise des en-têtes P3P, il DEVRAIT les inclure dans toutes les réponses des méthodes de requête appropriées, y compris les requêtes HEAD et OPTIONS.
L'en-tête P3P colporte une ou plusieurs directives, séparées par des virgules. En voici la syntaxe :
[1] p3p-header = `P3P: ` p3p-header-field *(`,` p3p-header-field) [2] p3p-header-field = policy-ref-field | compact-policy-field | extension-field [3] policy-ref-field = `policyref="` URI-reference `"` [4] extension-field = token [`=` (token | quoted-string) ]
Ici, la valeur URI-reference
est définie selon RFC 2396
[URI] ; les valeurs token
et quoted-string
sont définies par [HTTP1.1].
Comme pour les autres en-têtes HTTP, la casse du nom de l'en-tête P3P est indifférente. Par contre, le contenu devrait s'écrire précisément avec la casse indiquée dans ce document.
La directive policyref
fournit une adresse URI qui indique la localisation d'un
fichier d'appel de politique, qui peut alors appeler la politique P3P couvrant le document pointant vers le
fichier d'appel et d'autres éventuellement. Quand l'attribut policyref
est une adresse URI relative,
celle-ci est relative à l'adresse URI de la requête. Remarquez que la récupération de l'adresse URI
fournie par la directive policyref
PEUT donner lieu à un code de réponse de la classe HTTP 300 (redirection) ;
les agents utilisateurs DOIVENT interpréter ces redirections selon la sémantique HTTP normale.
Les fournisseurs de services vont sans doute remarquer que les redirections accroissent le temps nécessaire pour que les
agents utilisateurs trouvent et interprètent leurs politiques. L'adresse URI de policyref
NE DOIT PAS servir pour un autre usage que la localisation et l'appel des politiques P3P.
La directive compact-policy-field
sert à indiquer des politiques compactes
. Cf. la
section 4.
Les agents utilisateurs rencontrant des directives non reconnues (dans les directives extension-field
) DOIVENT les
ignorer. Ceci afin de faciliter le déploiement des versions ultérieures de P3P.
1. Le client effectue une requête GET :
GET /index.html HTTP/1.1 Host: catalogue.example.com Accept: */* Accept-Language: de, en User-Agent: WonderBrowser/5.2 (RT-11)
2. Le serveur renvoie un contenu et l'en-tête P3P pointant vers la politique de la ressource :
HTTP/1.1 200 OK P3P: policyref="http://catalogue.example.com/P3P/ReferencesPolitiques.xml" Content-Type: text/html Content-Length: 7413 Server: CC-Galaxy/1.3.18
link
Les serveurs PEUVENT renvoyer un contenu HTML incorporant des balises link
(cf. [HTML]) qui indiquent la localisation du fichier d'appel de politique P3P concerné.
Cette utilisation de P3P n'induit aucun changement dans le comportement du serveur.
La balise link
code les informations d'appel de politique qui auraient pu être exprimées au moyen d'une en-tête P3P.
La balise link
prend la forme suivante (on a juste produit un format ABNF possible pour la
balise link
et supposé que les règles de syntaxe [HTML] pouvaient s'appliquer pour cette balise
dans un fichier HTML) :
[5] p3p-link-tag = `<link rel="P3Pv1" href="` URI `">`
Ici, la valeur URI
est définie selon RFC 2396 [URI].
Quand l'attribut href
est une adresse URI relative, celle-ci est relative à
l'adresse URI de la requête.
Pour illustrer l'emploi de la balise link
, on reprend l'appel de politique exprimée dans
l'Exemple 2.1 avec des en-têtes HTTP.
Cet exemple peut s'exprimer de manière équivalente en utilisant la balise link
dans le fragment HTML suivant :
<link rel="P3Pv1" href="http://catalogue.example.com/P3P/ReferencesPolitiques.xml">
Enfin, puisqu'on incorpore p3p-link-tag
à un document HTML, on remarquera que son codage de caractères sera
le même que celui du document HTML. À la différence des documents de politique P3P
et d'appel de politique (cf. la section 2.3 et la section 3 ci-dessous),
il n'est pas nécessaire de transcrire p3p-link-tag
dans le codage [UTF-8]. Remarquez également
que la balise link
n'est pas sensible à la casse.
link
En parallèlle de la balise HTML link
, le protocole P3P gère également XHTML
(cf. [XHTML-MOD]). Les serveurs PEUVENT, au moyen du module link XHTML
(cf. la section 5.19
de la spécification [XHTML-MOD]), renvoyer un contenu XHTML qui indique l'emplacement du
fichier d'appel de politique P3P concerné avec une balise XHTML link
incorporée.
Comme pour HTML, on peut utiliser une balise XHTML link
pour coder les informations
d'appel de politique (qui auraient pu être exprimées par une en-tête P3P) :
rel
la valeur "P3Pv1
" ;href
l'adresse URI du fichier d'appel de politique P3P concerné.Les mécanismes décrits ici PEUVENT servir pour des transactions HTTP sur n'importe quel protocole sous-jacent. À savoir le protocole HTTP en texte brut sur des connexions TCP/IP ou HTTP crypté sur des connexions SSL, ou bien HTTP sur tout autre protocole de communication dont les concepteurs souhaitent la mise en œuvre.
Les adresse URI PEUVENT contenir des numéros de port de réseau, comme défini dans
RFC 2396 [URI]. En ce qui concerne le protocole P3P,
les ports différents sur un seul hôte DOIVENT être considérés comme étant des sites
distincts. Ainsi, par exemple,
le fichier d'appel de politique à l'emplacement notoire pour www.example.com sur le port 80 (http://www.example.com/w3c/p3p.xml)
ne donnerait aucune information sur les politiques applicables à www.example.com lors d'un accès via SSL
(étant donné que la communication SSL interviendra sur un port différent, 443 par défaut).
Ce document ne définit pas comment associer les politiques P3P à des ressources récupérées par d'autres moyens que HTTP. Toutefois, cela n'exclut pas le développement futur de mécanismes d'association de politiques P3P à des ressources récupérées via d'autres protocoles. En outre, d'autres méthodes associant des politiques P3P à des ressources récupérées via HTTP sont susceptibles d'être développées ultérieurement.
Cette section détaille le contenu des fichiers d'appel de politique.
Considérons le cas d'un site Web souhaitant faire les déclarations suivantes :
/P3P/Politiques.xml#un
s'applique au site entier, sauf aux ressources dont les chemins d'accès
commence par /catalogue
, /cgi-bin
ou /servlet
;/P3P/Politiques.xml#deux
s'applique à toutes les ressources dont les chemins d'accès
commencent par /cgi-bin
ou /servlet
, sauf /servlet/inconnu
./servlet/inconnu
;On peut représenter ces déclarations dans le fragment XML suivant :
<META xmlns="http://www.w3.org/2002/01/P3Pv1"> <POLICY-REFERENCES> <EXPIRY max-age="172800"/> <POLICY-REF about="/P3P/Politiques.xml#un"> <INCLUDE>/*</INCLUDE> <EXCLUDE>/catalogue/*</EXCLUDE> <EXCLUDE>/cgi-bin/*</EXCLUDE> <EXCLUDE>/servlet/*</EXCLUDE> </POLICY-REF> <POLICY-REF about="/P3P/Politiques.xml#deux"> <INCLUDE>/catalogue/*</INCLUDE> </POLICY-REF> <POLICY-REF about="/P3P/Politiques.xml#trois"> <INCLUDE>/cgi-bin/*</INCLUDE> <INCLUDE>/servlet/*</INCLUDE> <EXCLUDE>/servlet/inconnu</EXCLUDE> </POLICY-REF> </POLICY-REFERENCES> </META>
Remarquez que cet exemple inclut également, via l'élément <EXPIRY>
, une date
d'échéance relative dans le document (cf. la section 2.3.2.3.2).
Cette section définit la syntaxe et la sémantique des fichiers d'appel de politique P3P. Tous les fichiers d'appel de politique DOIVENT être codés en [UTF-8]. Les serveurs P3P DOIVENT coder leurs fichiers d'appel de politique en utilisant cette syntaxe.
Un fichier d'appel de politique a pour racine l'élément <META>
. Il peut
contenir plusieurs éléments <POLICY-REF>
. S'il contient plus d'un élément, alors les
agents utilisateurs DOIVENT les traiter dans l'ordre d'apparition dans le fichier. Quand un agent utilisateur essaye de
déterminer quelle politique s'applique à une adresse URI donnée, il DOIT utiliser le premier élément
<POLICY-REF>
concernant cette adresse URI dans le fichier d'appel de politique.
Remarquez que chaque élément <POLICY-REF>
peut contenir plusieurs éléments <INCLUDE>
,
<EXCLUDE>
, <METHOD>
, <COOKIE-INCLUDE>
et <COOKIE-EXCLUDE >
et que tous ces sous-éléments d'un élément <POLICY-REF>
DOIVENT être évalués ensemble pour déterminer
si cet élément <POLICY-REF>
s'applique, ou non, à une adresse URI donnée.
Ainsi, il ne suffit pas de trouver un élément <INCLUDE>
qui corresponde à une adresse URI donnée,
car des éléments <EXCLUDE>
ou <METHOD>
peuvent intervenir comme modificateurs et
l'élément <POLICY-REF>
ne correspondra donc plus.
Les fichiers d'appel de politique déclarent quelle politique s'applique à une adresse URI donnée.
Ils reconnaissent un caractère joker simple qui permet des déclarations limitées
à certaines régions de l'espace d'adresses URI.
Le caractère astérisque
sert à représenter une séquence de zéro ou plus caractères arbitraires.
Aucun autre caractère spécial (comme ceux utilisés dans les expressions rationnelles) n'est reconnu.*
Comme l'astérisque est aussi un caractère légal pour les adresses URI ([URI]), on doit adopter
des conventions spéciales pour coder ces adresses URI étendues
dans un fichier d'appel de politique :
*
littéraux des adresses URI dans les fichiers d'appel DOIVENT être masqués
(c'est-à-dire qu'on doit les représenter par "%2A
"). Tout caractère *
présent dans une
adresse URI dans un fichier d'appel sera interprété comme un caractère joker astérisque ;*
littéral présent
aura été reconnu comme un caractère joker astérisque.Le masquage et le démasquage des adresses URI dépendent en grande partie de la combinaison réelle utilisée et peuvent même différer d'un composant individuel à l'autre dans une seule combinaison, on ne peut donc pas donner ici de règle simple permettant de déterminer quels caractères doivent être masqués. Reportez-vous directement à [URI] pour des précisions sur le processus de masquage standard. Remarquez que les agents utilisateurs P3P PEUVENT ignorer tout motif d'adresse URI non conforme à [URI].
On PEUT utiliser le caractère joker dans les éléments <INCLUDE>
et <EXCLUDE>
,
dans les éléments <COOKIE-INCLUDE>
et <COOKIE-EXCLUDE>
et dans l'élément
<HINT>
.
META
et POLICY-REFERENCES
<META>
<META>
contient un fichier d'appel de politique complet. Un
élément <POLICIES>
optionnel peut suivre. L'élément <META>
peut
également contenir un ou plusieurs éléments <EXTENSION>
(cf. la section 3.5), ainsi qu'un attribut xml:lang
(cf. la section 2.4.2)
pour indiquer la langue dans laquelle son contenu est exprimé.<POLICY-REFERENCES>
<POLICY-REF>
(appel de politique).
Il PEUT aussi contenir un élément <EXPIRY>
(qui donne la date d'expiration),
un ou plusieurs éléments <HINT>
et un ou plusieurs éléments <EXTENSION>
(cf. la section 3.5).[6] prf = `<META xmlns="http://www.w3.org/2002/01/P3Pv1"` [xml-lang] `>` *extension policyrefs [policies] *extension "</META>" [7] policyrefs = "<POLICY-REFERENCES>" [expiry] *policyref *hint *extension "</POLICY-REFERENCES>"
Ici la valeur PCDATA
est définie dans [XML].
<EXPIRY>
Il est souhaitable que les serveurs puissent informer les agents utilisateurs de la durée pendant laquelle ceux-ci peuvent
utiliser les affirmations faites dans un fichier d'appel de politique. Permettre aux clients de mettre en cache
le contenu d'un fichier d'appel réduit le temps requis pour traiter la politique de confidentialité associée à une ressource Web.
La charge exercée sur le réseau s'en trouve également atténuée. En outre, les clients ne disposant pas d'un fichier d'appel de politique
valide pour une adresse URI devront adopter des pratiques de zone sûre
pour leurs requêtes. Si les clients disposent de fichiers d'appel de politique dont la validité est avérée,
alors ils peuvent décider en connaissance de cause de la façon de procéder.
Pour en tirer des bénéfices, les fichiers d'appel de politique DEVRAIENT contenir un élément <EXPIRY>
,
qui indique la durée de vie de ces fichiers. Si le fichier d'appel ne contient pas d'élément <EXPIRY>
,
alors sa durée de vie implicite est de 24 heures.
La durée de vie d'un fichier d'appel de politique indique aux agents utilisateurs la période pendant laquelle ceux-ci peuvent compter sur les affirmations contenues dans le fichier d'appel. En donnant une durée de vie au fichier d'appel de politique, le site éditeur établit que les politiques mentionnées dans le fichier d'appel sont recevables pour la durée de vie de celui-ci. Par exemple, si un fichier d'appel a une durée de vie de trois jours, alors l'agent utilisateur n'aura pas besoin de recharger ce fichier au cours des trois jours suivants et pourra supposer que les références contenues dans ce fichier seront exactes dans cet intervalle. Tous les appels de politique contenus dans un seul fichier d'appel de politique auront la même durée de vie. La seule façon de définir d'autres durées de vie à des appels de politique différents sera de recourir à des fichiers d'appel de politique séparés.
Ce mécanisme pour indiquer la durée de vie d'un fichier d'appel de politique est le même qui sert à indiquer celle d'une
politique P3P. Ainsi, on DEVRAIT associer un élément <EXPIRY>
aux éléments <POLICIES>
.
Cette durée de vie s'applique à toutes les politiques P3P contenues dans l'élément <POLICIES>
. Si aucun
élément <EXPIRY>
n'est associé à une politique P3P, alors sa durée de vie implicite est de 24 heures.
Au moment de choisir les durées de vie des politiques et des fichiers d'appel de politique, les sites doivent retenir celle qui représente le meilleur compromis entre deux positions antagonistes. D'une part, que la durée de vie soit suffisante pour que les agents utilisateurs puissent retirer un avantage significatif de la mise en cache. D'autre part, que le site puisse changer de politique pour une nouvelle collecte de données sans devoir attendre une échéance trop lointaine. Une durée de vie comprise dans une fourchette d'un à sept jours apparaît comme un compromis raisonnable entre ces deux objectifs concurrents. Les sites doivent également revoir les conditions de mise à jour des politiques lorsque ces mises à jour ont lieu.
Lorsqu'un fichier d'appel de politique est expiré, l'agent utilisateur NE DOIT PAS utiliser les informations qui y sont contenues tant qu'il n'a pas revalidé avec succès le fichier d'appel ou récupéré une nouvelle version de celui-ci.
Bien que les agents utilisateurs ne soient pas obligés de revalider les fichiers d'appel de politique, ou ceux des politiques
non expirées, ils PEUVENT choisir de le faire avant leur expiration pour diminuer les probabilités de devoir recourir à des
pratiques de zone sûre
. Un agent utilisateur P3P valide n'est pas obligé de mettre en place
un cache pour les politiques et les fichiers d'appel de politique, quoique ses performances puissent être meilleures s'il en avait un.
<EXPIRY>
On peut utiliser l'élément <EXPIRY>
dans un fichier d'appel de politique et/ou
dans un élément <POLICIES>
pour indiquer combien de temps le fichier d'appel
(ou les politiques) restent valides. L'expiration est exprimée soit comme une échéance absolue,
soit comme une échéance relative. Une échéance absolue est une date, exprimée en temps GMT,
juqu'où le fichier d'appel de politique ou bien les politiques sont valides. Une échéance relative est le nombre
de secondes pendant lesquelles le fichier d'appel ou bien les politiques sont valides. Cette dernière est relative
au moment où le client a demandé le fichier d'appel ou bien les politiques. Le calcul DOIT tenir compte
de l'instant de la requête originale, ou de la revalidation, et de l'instant courant, les deux temps ayant été générés
par l'horloge du client. La revalidation est définie dans la section 13.3 de la spécification [HTTP1.1].
La quantité minimale de temps pour une échéance relative est de 24 heures, soit 86400 secondes. Toute échéance relative de moins de 86400 secondes DOIT être considérée comme valant 86400 secondes par la mise en œuvre du client. Si un client rencontre une échéance absolue dépassée, il DOIT agir comme si AUCUN fichier d'appel de politique (ou AUCUNE politique) n'était disponible. Cf. la section 2.4.7 L'absence d'un fichier d'appel de politique pour la procédure à suivre dans ces cas.
[8] expiry = "<EXPIRY" (absdate|reldate) "/>" [9] absdate = `date="` HTTP-date `"` [10] reldate = `max-age="` delta-seconds `"`
Ici, la valeur HTTP-date
est définie dans la section 3.3.1 et la valeur delta-seconds
dans la section 3.3.2 de la spécification [HTTP1.1].
Dans un réseau réel, il peut y avoir des caches stockant les contenus des politiques et des fichiers d'appel de politique. Cette mise en cache favorise les performances d'ensemble du réseau mais présente de sérieux inconvénients en ce qui concerne le fonctionnement de P3P quand elle est mal utilisée. Deux problèmes particuliers se posent :
Le protocole HTTP 1.1 [HTTP1.1] comporte des mécanismes puissants pour contrôler la mise en cache qui permettent aux clients de contraindre les caches d'un réseau ; ces mécanismes peuvent apporter des solutions aux problèmes mentionnés ci-dessus. On décrira une méthode particulière plus loin.
Par contre, le protocole HTTP 1.0 n'offre pas ces mécanismes de contrôle de cache sophistiqués. Un serveur mandataire
HTTP 1.0 calculera certainement la durée de vie de cache du fichier d'appel de politique (ou des politiques)
à partir de la dernière date de modification du fichier ; la durée de vie de cache pourra être beaucoup plus grande que celle indiquée
par l'élément <EXPIRY>
. Le serveur est donc susceptible de renvoyer aux clients un fichier d'appel de politique
(ou des politiques) bien après l'échéance indiquée par l'élément <EXPIRY>
et les agents utilisateurs recevront
par conséquent un fichier d'appel (ou des politiques) inutilisable.
Le second problème des serveurs mandataires HTTP 1.0 tient au fait que l'agent utilisateur n'a aucun moyen de savoir depuis combien de temps le fichier d'appel est stocké dans le serveur mandataire. Si le fichier d'appel de politique (ou les politiques) est régi par une échéance relative, il sera alors impossible pour l'agent utilisateur de déterminer si la durée de vie du fichier est épuisée ou si elle va l'être.
Donc, si un agent utilisateur demande un fichier d'appel de politique, ou une politique, et qu'il n'est pas sûr qu'aucun cache HTTP 1.0 ne se trouve sur le trajet vers le serveur d'origine, alors la requête DOIT forcer une revalidation de bout en bout. On peut obtenir ce comportement en utilisant l'en-tête de requête HTTP Pragma: no-cache. Remarquez que ni le protocole HTTP ni le protocole P3P ne définissent de moyen pour déterminer si un serveur mandataire HTTP 1.0 existe sur une route dans un réseau, et c'est la raison pour laquelle l'agent utilisateur, à moins d'être informé par une source extérieure, DOIT forcer une revalidation de bout en bout.
Si l'agent utilisateur sait, d'une manière ou d'une autre, que tous les caches sur la route vers le serveur d'origine sont compatibles HTTP 1.1 (ou qu'il n'y a aucun cache sur cette route), plutôt que de forcer une revalidation de bout en bout, il PEUT alors :
Remarquez que le client est incapable de déterminer avec précision l'importance de la latence susceptible d'affecter une requête HTTP. Donc, si la durée de vie du fichier d'appel de politique concerné par une requête est sur le point d'expirer, l'agent utilisateur PEUT envisager d'avertir l'utilisateur et/ou de revalider le fichier de référence avant de poursuivre la requête.
Les situations suivantes font l'objet d'une sémantique bien définie :
<EXPIRY>
, c'est le premier qui détermine
la durée de vie du fichier d'appel.POLICY-REF
Un fichier d'appel de politique peut appeler plusieurs politiques P3P, en fournissant des informations sur chacune d'elles.
L'élément <POLICY-REF>
décrit les attributs d'une seule politique P3P.
Les sous-éléments de l'élément <POLICY-REF>
indiquent l'emplacement de la politique et définissent les régions
de l'espace d'adresse URI (et les cookies) que chaque politique couvre.
<POLICY-REF>
about
(attribut obligatoire)name
) et dont la partie adresse URI indique
l'adresse URI où la politique réside, c'est-à-dire, un fichier de politique ou un fichier d'appel de politique
(cf. la section 3.2). S'il s'agit de l'appel d'une adresse URI relative, on l'interprète
par rapport à l'adresse URI du fichier d'appel de politique qui le contient.[11] policy-ref = `<POLICY-REF about="` URI-reference `">` *include *exclude *cookie-include *cookie-exclude *method-element *extension `</POLICY-REF>`
Ici, la valeur URI-reference
est définie selon RFC 2396
[URI].
INCLUDE
et EXCLUDE
Chaque élément <INCLUDE>
ou <EXCLUDE>
indique une adresse URI locale
ou un jeu d'adresses URI locales. Il s'agira d'un jeu d'adresses URI
si le caractère joker *
apparaît dans le motif d'adresse URI. Ces éléments
servent à désigner la partie du site Web couverte par la politique appelée par l'élément <POLICY-REF>
englobant.
Lorsque les éléments <INCLUDE>
et, en option, <EXCLUDE>
sont présents dans un
élément <POLICY-REF>
, alors la politique indiquée par l'attribut about
de
l'élément <POLICY-REF>
s'applique à toutes les adresses URI, sur l'hôte appelé, correspondant
à l'adresse URI locale (ou aux adresses URI locales) filtrée(s) par l'élément (ou les éléments) <INCLUDE>
,
sauf les adresses filtrées par des éléments <EXCLUDE>
.
Une politique référencée dans un fichier d'appel de politique ne peut s'appliquer qu'aux adresses URI sur l'hôte
DNS (Domain Name System) qui l'appelle. Donc, par exemple,
un fichier d'appel de politique trouvé à l'emplacement notoire de l'hôte www.example.com ne peut appliquer de politiques
qu'aux ressources hébergées sur www.example.com. Toutefois, si l'hôte foo.example.com insère dans ses réponses une
en-tête HTTP P3P qui appelle un fichier d'appel de politique sur bar.example.com, alors ce fichier s'appliquera
aux ressources de foo.example.com (et non à celles de bar.example.com ou de www.example.com). Le même fichier d'appel de politique
peut être appelé au travers des en-têtes HTTP P3P envoyées par plusieurs hôtes, auquel cas il pourra
s'appliquer à chacun des hôtes qui l'appellent. Les éléments <INCLUDE>
et <EXCLUDE>
DOIVENT
définir les motifs d'adresse URI relativement à la racine de l'hôte DNS auquel ils s'appliquent.
Cette condition ne s'applique PAS à l'emplacement du fichier de politique P3P (c'est-à-dire, l'attribut about
de l'élément <POLICY-REF>
).
Si un élément <METHOD>
(section 2.3.2.8) indique une ou plusieurs méthodes
pour appeler une politique englobante, il s'ensuit que toutes les méthodes non mentionnées ne seront donc pas couvertes
par cette politique. S'il s'agit du seul appel de politique pour un préfixe d'adresse URI donné, alors les
agents utilisateurs DOIVENT supposer qu'il n'y a PAS de politique en vigueur pour toutes les méthodes NON mentionnées
dans le fichier d'appel de politique. Quoique ça ne serve à rien, on peut légalement avoir un élément <METHOD>
sans élément <INCLUDE>
ni élément <COOKIE-INCLUDE>
.
Tout aussi légal mais inutile, il peut y avoir un élément <EXCLUDE>
sans élément <INCLUDE>
;
auquel cas, les agents utilisateurs DOIVENT ignorer cet élément <EXCLUDE>
.
Remarquez que le jeu d'adresse URI défini par les éléments <INCLUDE>
et <EXCLUDE>
n'inclut pas les cookies qui peuvent être installés ou lus au cours d'une requête vers l'une de ces adresses URI :
on devra recourir aux éléments <COOKIE-INCLUDE>
et
<COOKIE-EXCLUDE>
pour associer des politiques aux cookies.
[12] include = "<INCLUDE>" relativeURI "</INCLUDE>" [13] exclude = "<EXCLUDE>" relativeURI "</EXCLUDE>"
Ici, la valeur relativeURI
est définie selon RFC 2396
[URI], en ajoutant le caractère
qu'il faut traiter comme un caractère joker selon les définitions
de la section 2.3.2.1.2.*
HINT
Les conseils d'appel de politique permettent une optimisation des performances
et on peut y recourir dans certaines conditions. Un site peut déclarer un appel de politique vers lui-même en recourant à
l'emplacement notoire, à une en-tête de réponse P3P ou à une balise HTML/XHTML link
.
Le site PEUT en outre fournir des conseils pour d'autres appels de politique, comme ceux déclarés par d'autres sites.
Par exemple, une page HTML peut conseiller des appels de politique pour ses hyperliens, son contenu incorporé et ses adresses URI d'action. Les agents utilisateurs PEUVENT utiliser le mécanisme de conseil pour découvrir les fichiers d'appel de politique avant de demander les adresses URI affectées quand les appels de politique ne sont pas disponibles depuis l'emplacement notoire.
Les agents utilisateurs utilisant des conseils pour récupérer des politiques NE DOIVENT PAS appliquer ces politiques à un autre site que celui contenant le fichier d'appel de politique conseillé.
Tout fichier d'appel de politique PEUT contenir zéro ou plus conseils d'appel de politique. Chaque conseil est contenu
dans un élément <HINT>
avec deux attributs : scope
et path
.
L'attribut scope
sert à indiquer un système d'adresse URI et une autorité à laquelle
l'appel de politique peut s'appliquer. Si la composante autorité (cf. [URI]) est un composant de serveur
(par exemple, un nom d'hôte ou une adresse IP), la partie hôte de l'autorité
PEUT commencer par un caractère joker, comme défini dans la section 2.3.2.1.2.
L'attribut scope
NE DOIT PAS contenir de caractère joker à une autre position, il DOIT être codé en suivant les
conventions de la section 2.3.2.1.2 et il NE DOIT PAS contenir un chemin d'accès, une requête ou un fragment de composante
d'adresse URI. De surcroît, si l'autorité est un serveur, celle-ci ne DEVRAIT PAS contenir de partie userinfo.
Par exemple, les valeurs légales pour scope
comprennent :
http://www.example.com
http://www.example.com:81
http://*.example.com
ftp://ftp.example.org
Les valeurs suivantes sont illégales pour l'attribut scope
:
http://www.*.com
: le caractère joker se trouve uniquement en tête ;http://www.example.com/
: la barre oblique finale n'est pas admise ;www.example.com
; le système d'adresse URI doit être déclaré ;*://www.example.com
: le système d'adresse URI ne peut pas contenir de caractère joker ;http://www.example.com:*
: le port ne peut contenir de caractère joker.L'attribut path
sert à la localisation du fichier d'appel de politique sur le site conseillé. C'est une
adresse URI relative dont la base se compose du système d'adresse URI et de l'autorité filtrés dans
l'attribut scope
. L'attribut path
NE DOIT PAS être une adresse URI absolue, de sorte que le
fichier d'appel de politique soit toujours récupéré sur le site auquel il s'applique.
Exemple 2.3 :
<HINT scope="http://www.example.org" path="/mapolitique/p3.xml" /> <HINT scope="http://www.example.net:81" path="/w3c/prf.xml" /> <HINT scope="http://*.shop.example.com" path="/w3c/prf.xml" />
[14] hint = `<HINT scope="` scheme ( `://` | `:/` ) authority `" path="` relativeURI `/>`
Ici, les valeurs scheme
, authority
et relativeURI
sont définies dans
RFC 2965 [STATE].
COOKIE-INCLUDE
et COOKIE-EXCLUDE
Les éléments <COOKIE-INCLUDE>
et <COOKIE-EXCLUDE>
servent à associer
des politiques aux cookies (cf. [COOKIES] et [STATE]).
Une politique de cookie DOIT couvrir toutes les données (dans le champ de P3P) qui sont stockées dans ce cookie ou exploitées par celui-ci. En outre, toutes les données/intentions reliées par ce cookie DOIVENT être mentionnées dans la politique de cookie. Si ces données reliées sont collectées par HTTP, alors la politique, qui couvre cette requête GET/POST/quelle que soit la méthode, doit aussi couvrir cette collecte de données. Par exemple, quand l'entreprise CatalogueExemple demande à ses clients de remplir un formulaire, avec leur nom, leur adresse de facturation et de livraison, la politique P3P qui couvre la soumission du formulaire annoncera alors que CatalogueExemple collecte ces données et en expliquera la destination. Si l'entreprise CatalogueExemple place un cookie, dans le but de reconnaître ses clients et d'observer leurs comportements sur son site Web, elle aura une politique distincte pour ce cookie. Par contre, si ce cookie est aussi relié au nom, à l'adresse de facturation et de livraison de l'utilisateur, par exemple, parce que CatalogueExemple souhaite générer des pages de catalogue personnalisées en fonction de l'endroit où le client habite, alors cette utilisation des données doit également faire l'objet d'une divulgation dans la politique de cookie.
Pour les besoins de cette spécification, les mécanismes de gestion d'état utilisent soit l'en-tête
SET-COOKIE, soit l'en-tête SET-COOKIE2, et l'espace de nommage du cookie est défini selon
la valeur des attributs NAME
, VALUE
, Domain
et Path
,
définis dans [COOKIES] et [STATE].
Chacun élément <COOKIE-INCLUDE>
ou <COOKIE-EXCLUDE>
peut servir à filtrer
(d'une manière similaire aux éléments <INCLUDE>
et <EXCLUDE>
) les composants
NAME
, VALUE
, Domain
et Path
d'un cookie, en exprimant les cookies couverts
par la politique indiquée par l'attribut about
lorsque les cookies sont installés par des ressources du site Web
où le fichier de référence de politique réside :
<COOKIE-INCLUDE>
(resp. <COOKIE-EXCLUDE>
)name
, value
,
domain
et path
name
NAME
du cookievalue
VALUE
du cookiedomain
Domain
du cookiepath
Path
du cookieSi l'attribut domain
a pour valeur le caractère point
, le domaine ne correspondra
qu'aux cookies qui omettent l'attribut .
Domain
(et ont donc un domaine équivalant à l'hôte visé par la requête
selon RFC 2965 ([STATE])).
Les cookies qui omettent l'attribut Path
ont pour chemin d'accès implicite celui de l'adresse URI
de la requête qui a généré la réponse Set-Cookie, selon RFC 2965
[STATE]. L'attribut path
de l'élément <COOKIE-INCLUDE>
devrait être évalué
par rapport à cette valeur implicite lorsque le cookie omet l'attribut Path
.
Tous les quatre attributs sont optionnels. Si un attribut est absent, l'élément <COOKIE-INCLUDE>
(resp. <COOKIE-EXCLUDE>
) correspondra donc aux cookies qui auront cet attribut, quelle que soit sa valeur.
Quand les éléments <COOKIE-INCLUDE>
et, en option, <COOKIE-EXCLUDE>
sont présents
dans un élément <POLICY-REF>
, la politique indiquée par l'attribut about
de cet élément <POLICY-REF>
s'applique à tous les cookies filtrés par un élément <COOKIE-INCLUDE>
et ceux qui ne le sont pas par un élément <COOKIE-EXCLUDE>
.
Les agents utilisateurs DOIVENT interpréter les éléments <COOKIE-INCLUDE>
et <COOKIE-EXCLUDE>
d'un fichier d'appel de politique pour déterminer quelle politique s'applique aux cookies installés ou lus sur l'hôte
auquel le fichier d'appel s'applique. Bien que l'attribut domain
d'un élément <COOKIE-INCLUDE>
puisse représenter une correspondance plus large (par exemple, si l'attribut domain
est omis, il filtre implicitement
n'importe quelle valeur de domaine), les agents utilisateurs DOIVENT limiter leur application de la politique
aux domaines susceptibles d'être utilisés légalement dans un cookie installé sur l'hôte auquel le fichier d'appel de politique s'applique.
Par exemple, si abc.xyz.example.com déclare un appel de politique par <COOKIE-INCLUDE domain="*.xyz.*ple.com"/>
,
cette déclaration pourra correspondre aux domaines .abc.xyz.example.com et .xyz.example.com, mais pas à .example.com ou .xyz.sample.com.
Une politique P3P peut être associée à un cookie par l'hôte qui a installé le cookie, tout comme par
l'un ou tous les hôtes sur lesquels ce cookie peut être lu. Un agent utilisateur PEUT récupérer une politique de cookie au moment de
l'installation du cookie et l'appliquer plus tard lorsque le cookie en question est lu, par exemple, par les autres hôtes dans le domaine.
Un agent utilisateur PEUT demander un fichier d'appel de politique à un hôte avant de lire un cookie pour cet hôte et,
si le fichier d'appel contient un élément <COOKIE-INCLUDE>
adéquat, une politique s'appliquera à ce cookie,
même s'il n'a pas été installé par cet hôte. Tout hôte dont le cookie peut être lu DOIT être capable d'honorer
toutes les politiques associées au cookie, que cet hôte déclare une politique pour ce cookie ou non. Il est donc nécessaire de coordonner
les sites qui installent des cookies susceptibles d'être lus par les divers hôtes d'un domaine, afin de s'assurer que tous puissent
suivre la politique déclarée. En outre, les sites devraient se montrer prudents en utilisant les caractères jokers et s'assurer
qu'ils n'appliquent pas, par inadvertence, une politique à des cookies qui ne seraient pas concernés
(y compris les cookies toujours actifs installés précédemment et ceux installés par les autres hôtes du domaine).
La politique appliquée à un cookie s'exerce tant qu'elle n'a pas expiré, même si le fichier d'appel de politique associé expire avant la politique (mais après que le cookie a été installé). Si la politique associée à un cookie est expirée, alors l'agent utilisateur DEVRAIT révaluer la politique de cookie avant d'envoyer le cookie. En outre, les agents utilisateurs DOIVENT uniquement se servir de politiques et de fichiers d'appel de politique non expirés pour l'évaluation de nouveaux événements Set-Cookie.
L'exemple 2.4 déclare que la politique désignée par /P3P/Politiques.xml#un
s'applique à tous les cookies.
Exemple 2.4 :
<META xmlns="http://www.w3.org/2002/01/P3Pv1"> <POLICY-REFERENCES> <POLICY-REF about="/P3P/Politiques.xml#un"> <COOKIE-INCLUDE name="*" value="*" domain="*" path="*"/> </POLICY-REF> </POLICY-REFERENCES> </META>
L'exemple 2.5 déclare que la politique désignée par /P3P/Politiques.xml#un
s'applique à tous les cookies,
sauf ceux dont l'attribut name
a la valeur "cookie-repoussant
", l'attribut domain
a la valeur
".example.com
" et l'attribut path
la valeur "/
", et déclare, au contraire,
que la politique /P3P/Politiques.xml#deux
s'applique à tous les cookies dont les attributs name
,
domain
et path
ont justement ces dernières valeurs.
Exemple 2.5 :
<META xmlns="http://www.w3.org/2002/01/P3Pv1"> <POLICY-REFERENCES> <POLICY-REF about="/P3P/Politiques.xml#un"> <COOKIE-INCLUDE name="*" value="*" domain="*" path="*"/> <COOKIE-EXCLUDE name="cookie-repoussant" value="*" domain=".example.com" path="/"/> </POLICY-REF> <POLICY-REF about="/P3P/Politiques.xml#deux"> <COOKIE-INCLUDE name="cookie-repoussant" value="*" domain=".example.com" path="/"/> </POLICY-REF> </POLICY-REFERENCES> </META>
[15] cookie-include = "<COOKIE-INCLUDE" [` name="` token `"`] ; correspond à l'attribut NAME du cookie [` value="` token `"`] ; correspond à l'attribut VALUE du cookie [` domain="` token `"`] ; correspond à l'attribut Domain du cookie [` path="` token `"`] ; correspond à l'attribut Path du cookie "/>" [16] cookie-exclude = "<COOKIE-EXCLUDE" [` name="` token `"`] ; correspond à l'attribut NAME du cookie [` value="` token `"`] ; correspond à l'attribut VALUE du cookie [` domain="` token `"`] ; correspond à l'attribut Domain du cookie [` path="` token `"`] ; correspond à l'attribut Path du cookie "/>"
Ici, les valeurs token
, NAME
, VALUE
, Domain
et Path
sont
définies selon RFC 2965 [STATE], en ajoutant le
caractère
qu'il faut traiter comme un caractère joker, comme défini dans la
section 2.3.2.1.2.*
Remarquez que [STATE] définit des valeurs implicites pour les attributs
Domain
et Path
des cookies : on devrait utiliser ces valeurs de comparaison lorsque ces attributs
sont absents d'un cookie donné. Également, conformément à [STATE], si la valeur explicite
d'un attribut Domain
ne commence pas par un caractère point (
), alors l'agent utilisateur DOIT
le lui ajouter en préfixe ; remarquez que chaque valeur d'attribut .
Path
commence par le caractère
./
METHOD
Par défaut, un appel de politique s'applique aux adresses URI déclarées, quelle que soit la méthode employée pour accéder à la ressource. Toutefois, un site Web peut vouloir définir différentes politiques P3P en fonction de la méthode à appliquer à une ressource. Par exemple, un site peut vouloir collecter plus de données des utilisateurs si ceux-ci utilisent les méthodes PUT ou DELETE au lieu de la méthode GET.
L'élément <METHOD>
d'un fichier d'appel de politique sert à déclarer que l'appel de politique englobant
ne s'applique que si on utilise les méthodes indiquées pour accéder aux ressources demandées. On peut répéter
l'élément <METHOD>
pour indiquer plusieurs méthodes applicables. Si l'élément <METHOD>
est absent d'un élément <POLICY-REF>
, alors cet élément <POLICY-REF>
couvrira les
ressources indiquées quelles que soient les méthodes utilisées pour y accéder.
Ainsi, pour déclarer que la politique désignée par /P3P/Politiques.xml#un
s'appliquera à toutes les ressources dont le
chemin d'accès commence par /docs/
pour les méthodes GET et HEAD, tandis que la politique désignée
par /P3P/Politiques.xml#deux
s'appliquera aux méthodes PUT et DELETE, on écrirait l'appel de politique
de la manière suivante :
Exemple 2.6 :
<META xmlns="http://www.w3.org/2002/01/P3Pv1"> <POLICY-REFERENCES> <POLICY-REF about="/P3P/Politiques.xml#un"> <INCLUDE>/docs/*</INCLUDE> <METHOD>GET</METHOD> <METHOD>HEAD</METHOD> </POLICY-REF> <POLICY-REF about="/P3P/Politiques.xml#deux"> <INCLUDE>/docs/*</INCLUDE> <METHOD>PUT</METHOD> <METHOD>DELETE</METHOD> </POLICY-REF> </POLICY-REFERENCES> </META>
Remarquez que le protocole HTTP impose un même comportement pour les requêtes GET et HEAD et il est
donc inutile de définir des politiques P3P différentes pour ces méthodes. La syntaxe de l'élément <METHOD>
est la suivante :
[17] method-element = `<METHOD>` Method `</METHOD>`
Ici, la valeur Method
est définie dans la section 5.1.1 de [HTTP1.1].
Enfin, remarquez que l'élément <METHOD>
est conçu pour une utilisation conjointe avec les
éléments <INCLUDE>
ou <COOKIE-INCLUDE>
. Un élément <METHOD>
n'appliquera jamais
de lui-même un élément <POLICY-REF>
à une adresse URI.
Un fichier d'appel de politique indique la politique qui s'applique à une certaine adresse URI.
En d'autres termes, la politique indiquée décrit tous les effets issus de la résolution d'une adresse URI donnée
(et, dans certains cas, conformément aux spécifications de l'élément <METHOD>
).
La règle générale décrivant comment une politique P3P est supposée couvrir une adresse URI est la suivante : la politique appelée DOIT couvrir les actions que le logiciel client de l'utilisateur est censé entreprendre en réponse de la requête de cette adresse URI. Évidemment, la politique doit décrire toute la collecte des données effectuée par le site en conséquence du traitement de la requête de l'adresse URI. Si donc une adresse URI donnée est couverte pour des requêtes de type GET, alors la politique indiquée par le fichier d'appel de politique DOIT décrire entièrement la collecte des données effectuée par le site quand cette adresse URI est sollicitée. De même, si une adresse URI est couverte pour des requêtes de type POST, toute collecte de données survenant en résultat de la soumission d'un formulaire ou d'un autre contenu DOIT être décrite par la politique.
La notion d'actions que le logiciel client est censé entreprendre
comprend l'installation des cookies côté client
ou d'autres mécanismes de gestion d'état invoqués par la réponse. Si la requête d'une adresse URI renvoie un code exécutable,
alors la politique P3P qui couvre cette adresse URI DOIT aussi couvrir
les actions susceptibles de se produire à l'exécution de ce code. Ces actions couvertes sont toutes celles qui surviendraient
sans une invocation explicite par l'utilisateur. Si une action explicite de l'utilisateur provoque la collecte de données,
la politique P3P couvrant l'adresse URI de cette action révèlerait alors cette collecte.
Quelques exemples caractéristiques :
Envoyer. La politique P3P qui couvre la deuxième adresse URI DOIT divulguer toutes les données collectées par le formulaire. La politique P3P qui couvre la première adresse URI (celle par laquelle le formulaire a été chargé) PEUT divulguer, ou NON, les données qui seront collectées par le formulaire ;
submitou apparenté. Si le formulaire était posté automatiquement (par exemple, par un code JavaScript dans la page), on aurait alors un exemple identique à l'exemple n°2, c'est-à-dire que les données collectées par le formulaire DOIVENT alors être décrites par la politique P3P couvrant le formulaire HTML ;
Les formulaires méritent une attention particulière, dans la mesure où ils sont souvent reliés à des scripts CGI
ou à d'autres applications côté serveur par leur adresse URI d'action (l'action d'une adresse URI est
l'adresse URI indiquée par l'attribut action
de l'élément HTML FORM
,
comme défini dans la section 17.3 de [HTML]). Ces adresses URI d'action sont très souvent couvertes
par une politique différente de celle du formulaire lui-même.
Si un agent utilisateur ne trouve pas de règle <include>
correspondant à une adresse URI donnée
dans le fichier d'appel de politique, appelé depuis la page, il DEVRAIT en déduire qu'aucune politique n'est active.
Dans ce cas, les agents utilisateurs DEVRAIENT examiner l'emplacement notoire sur l'hôte de
l'adresse URI d'action pour essayer de trouver un fichier d'appel de politique couvrant cette adresse URI d'action.
Si cette démarche ne révèle aucune politique P3P couvrant l'adresse URI d'action, alors
l'agent utilisateur PEUT essayer de récupérer le fichier d'appel de politique en utilisant le
mécanisme des éléments <HINT>
sur l'adresse URI d'action et/ou en émettant
une requête HEAD vers l'adresse URI d'action, avant la soumission effective des données,
pour rechercher la politique active. Les services DEVRAIENT s'assurer que les applications côté serveur puissent répondre correctement
à ces requêtes HEAD et renvoyer le lien d'appel de politique correspondant dans les en-têtes. Au cas où l'application
sous-jacente ne reconnaîtrait pas la requête HEAD et qu'aucune politique ne serait prédéclarée pour
l'adresse URI d'action en question, l'agent utilisateur DOIT en déduire qu'aucune politique n'est active
et il DEVRAIT avertir l'utilisateur de la situation ou prendre les mesures appropriées conformément aux préférences de l'utilisateur.
Remarquez que les services peuvent utiliser l'élément <METHOD>
pour déclarer des politiques sur
les applications côté serveur qui ne couvrent qu'un sous-ensemble des méthodes reconnues, par exemple, POST ou GET.
Dans ce cas, on peut accepter de l'application en question qu'elle ne reconnaisse que les méthodes indiquées dans le
fichier d'appel de politique (par exemple, il n'est pas nécessaire de reconnaître les requêtes PUT).
Les agents utilisateurs NE DEVRAIENT PAS essayer de faire une requête HEAD vers une adresse URI d'action
si les méthodes concernées, indiquées par l'attribut method
du formulaire, ont été correctement prédéclarées
dans le fichier d'appel de politique de la page.
Dans certains cas, la même adresse URI d'action collectera des données différentes en fonction d'une
sélection effectuée dans le formulaire. Par exemple, un service peut proposer à la fois une recherche sur des personnes
(par leur nom et/ou leur adresse électronique) et sur des images (arbitraires). En jouant sur une combinaison de boutons radio sur le
formulaire, une seule application côté serveur située à une seule et même adresse URI d'action gèrera les deux cas et
collectera les renseignements nécessaires pour une recherche. Si un service souhaite prédéclarer les pratiques de collecte de données
de l'application côté serveur, il PEUT toutes les déclarer dans un seul fichier d'appel de politique (en utilisant
un élément <INCLUDE>
correspondant à l'adresse URI d'action). Auquel cas,
les agents utilisateurs DOIVENT en déduire que les éléments de données sont tous collectés à chaque fois. La commodité de cette solution
tient à l'utilisation d'une politique unique mais elle reflètera peut-être mal le fait que seule une partie des éléments de données
est collectée à un moment donné. Les services DEVRAIENT s'assurer par une requête HEAD simple vers
l'adresse URI d'action (c'est-à-dire, sans argument et notamment sans la valeur du bouton radio sélectionné)
qu'elle renverra une politique couvrant tous les cas.
Remarquez que si la gestion d'un formulaire a lieu au travers d'une utilisation de la méthode GET, alors l'adresse URI d'action
reflète le choix des éléments de formulaire sélectionnés par l'utilisateur. Dans certains cas, il sera possible d'utiliser la syntaxe
avec caractère joker, admise dans les fichiers d'appel de politique, pour indiquer différentes politiques pour des utilisations différentes
de la même adresse URI de gestionnaire d'action du formulaire. C'est pourquoi les agents utilisateurs DOIVENT inclure
la partie chaîne de requête des adresses URI lors des comparaisons avec les éléments <INCLUDE>
et <EXCLUDE>
des fichiers d'appel de politique.
Les agents utilisateurs doivent être capables de déterminer sans ambiguïté quelle politique s'applique à une adresse URI donnée. Les sites DEVRAIENT donc éviter de déclarer plus d'une politique non expirée par adresse URI donnée. Dans certains cas rares, les sites PEUVENT déclarer plusieurs politiques non expirées par adresse URI, par exemple, au cours d'une période de transition où le site change de politique. Dans ce cas, le site sera probablement incapable de déterminer avec certitude quelle politique un utilisateur donné aura vue, et il DOIT alors honorer toutes les politiques (il en est de même pour les politiques compactes, cf. la section 4.1 et la section 4.6). Les sites DOIVENT se montrer prudents dans leurs pratiques quand ils déclarent plusieurs politiques pour une adresse URI donnée et s'assurer de leur capacité effective à honorer simultanément toutes les politiques.
Si un fichier d'appel de politique à l'emplacement notoire
déclare une politique non expirée pour une adresse URI donnée, alors c'est elle qui s'appliquera indépendamment
d'éventuels fichiers d'appel contradictoires appelés au travers d'en-têtes HTTP ou de balises
HTML/XHTML link
.
Si une en-tête de réponse HTTP inclut des appels à plusieurs fichiers d'appel de politique, alors les agents utilisateurs P3P DOIVENT ignorer tous les appels suivant le premier.
Si un fichier HTML (ou XHTML) inclut des balises HTML (ou XHTML) link
appelant plusieurs fichiers d'appel de politique, alors les agents utilisateurs DOIVENT ignorer tous les appels suivant le premier.
Si un agent utilisateur découvre plusieurs politiques P3P non expirées pour une adresse URI donnée
(par exemple, parce qu'une page a en même temps une en-tête P3P et une balise link
appelant des
fichiers d'appel de politique différents, ou parce que les en-têtes P3P pour deux pages du site appellent des
fichiers d'appel différents qui déclarent des politiques différentes pour une même adresse URI), alors
l'agent utilisateur PEUT en déduire que n'importe quelle politique (ou toutes) s'applique car le site DOIT toutes les honorer.
Le serveur peut offrir des versions en plusieurs langues (traductions) de la même politique en recourant à l'en-tête HTTP Content-Language pour préciser la langue particulière utilisée par la politique. C'est une caractéristique utile qui permet de présenter les champs lisibles par un humain, tels que la personne et les implications, en différentes langues. Ce même mécanisme peut servir à fournir des versions en différentes langues des schémas de données. Les serveurs DEVRAIENT renvoyer une politique localisée en réponse à une requête HTTP ayant une en-tête Accept-Language lorsqu'une politique correspondant aux préférences de langue indiquées est disponible.
Dès lors qu'on utilise une en-tête Content-Language pour distinguer des politiques offertes en plusieurs langues à une même adresse URI, la teneur de ces politiques DOIT être la même dans chacune des langues. Deux politiques (ou deux schémas de données) sont considérées comme identiques si :
En raison de l'utilisation du mécanisme Accept-Language, les développeurs devraient noter que les agents utilisateurs sont susceptibles de voir des traductions différentes d'une politique ou d'un fichier d'appel de politique pour la même requête Accept-Language envoyée si une nouvelle traduction d'une politique ou d'un schéma de données est ajoutée.
Enfin, on peut aussi inclure directement les déclarations de langue dans les fichiers XML P3P : les
éléments <POLICY>
, <POLICIES>
, <META>
et <DATASCHEMA>
PEUVENT
avoir un attribut xml:lang
pour indiquer la langue de tous les champs lisibles par un humain qui y sont contenus
(la définition normative de xml:lang
se trouve dans la section 2.12 de [XML]).
[18] xml-lang = ` xml:lang="` language `"`
Ici, la valeur language
est un identificateur de langue, comme défini dans [LANG].
zone sûre
Le protocole P3P définit un ensemble particulier de pratiques de zone sûre
(N.D.T. safe zone)
que tous les agents utilisateurs et les services mettant en œuvre P3P DEVRAIENT observer pour les échanges
intervenant dans la récupération d'une politique ou d'un fichier d'appel de politique P3P. Ces pratiques de zone sûre
DEVRAIENT notamment couvrir les requêtes vers l'emplacement notoire pour les
fichiers d'appel de politique. Les échanges couverts par ces pratiques DEVRAIENT se résumer à une collecte minimale de données ;
aucune de ces données ne devrait être identifiable en cours d'utilisation.
Pour établir cette zone sûre, les agents utilisateurs P3P DEVRAIENT supprimer la transmission des données qui ne sont pas indispensables à la recherche de la politique d'un site tant que celle-ci n'aura pas été récupérée. Aussi les pratiques de zone sûre pour les agents utilisateurs comprennent les contraintes suivantes :
Les pratiques de zone sûre pour les serveurs comprennent les contraintes suivantes :
Remarquez que les contraintes de zone sûre n'interdisent pas aux sites de conserver les renseignements identifiables mais seulement qu'ils NE DEVRAIENT PAS utiliser de manière identifiable ces renseignements lors du service d'un fichier de politique ou d'appel de politique. Par exemple, la recherche de la source d'une attaque en déni de service peut être une raison légitime d'utiliser ces renseignements.
Les agents utilisateurs P3P DOIVENT interpréter (ou agir sur) les politiques P3P et les fichiers d'appel de politique seulement si ce sont des fichiers XML bien formés.
Les agents utilisateurs P3P DEVRAIENT interpréter (ou agir sur) les politiques P3P et les fichiers d'appel de politique seulement s'ils sont conformes au schéma XML fourni dans l'Annexe 4 et ils NE DEVRAIENT PAS tenir compte d'une partie de politique ou de fichier d'appel non conforme à ce schéma XML.
Les agents utilisateurs NE DOIVENT PAS modifier localement une politique P3P ou un fichier d'appel de politique pour les rendre conformes au schéma XML.
Les politiques P3P et les fichiers d'appel de politique NE DEVRAIENT PAS contenir de renseignements sensibles. Il n'existe aucune contrainte de sécurité supplémentaire, pour le transport d'un appel vers une politique P3P, hormi les contraintes du document auquel cet appel est associé ; donc, si un document HTML est servi normalement au cours d'une session non cryptée, le protocole P3P n'impose pas ni ne recommande qu'il le soit dans une session cryptée lorsqu'un appel de politique P3P se trouve dans le document.
Lorsqu'un site Web change de politique P3P, remarquez que la politique antérieure s'applique aux données collectées quand celle-ci était active. Le site a la responsabilité de conserver un historique des politiques P3P et des fichiers d'appel de politique, avec les dates où ils étaient en vigueur, et d'appliquer ces politiques de manière adéquate.
Si un site souhaite appliquer une nouvelle politique P3P sur des données collectées précédemment, il DOIT en faire part aux utilisateurs et leur laisser la possibilité d'accepter la nouvelle politique, conformément aux lois en vigueur, aux directives de l'industrie ou à d'autres accords concernant la vie privée passés par le site.
Si aucun fichier d'appel de politique n'est disponible pour un site donné, les agents utilisateurs DOIVENT supposer qu'il en existe un (vide) à l'emplacement notoire, ayant une durée de vie de 24 heures ; si l'utilisateur retourne sur le site après ce délai, l'agent utilisateur DOIT donc essayer de récupérer à nouveau un fichier d'appel à l'emplacement notoire. Les agents utilisateurs PEUVENT vérifier l'emplacement notoire plus souvent ou à l'occasion de certains événements, par exemple, quand l'utilisateur effectue un rafraîchissement du cache du navigateur. Les sites PEUVENT placer, à l'emplacement notoire, un fichier d'appel de politique faisant état d'aucune politique mais indiquant une date d'expiration, de sorte que les agents utilisateurs sachent qu'il n'est pas nécessaire de vérifier le site toutes les 24 heures.
Les agents utilisateurs PEUVENT récupérer et évaluer des politiques P3P de manière asynchrone. C'est-à-dire que les politiques P3P ne seront pas forcément récupérées et évaluées préalablement à d'autres transactions HTTP. Ce comportement peut dépendre des préférences de l'utilisateur et du type de la requête effectuée. Tant qu'une politique n'est pas évaluée, l'agent utilisateur DEVRAIT agir comme si le site n'avait pas de politique de confidentialité. Une fois celle-ci évaluée, l'agent utilisateur DEVRAIT appliquer les préférences de l'utilisateur. Pour favoriser un comportement déterministe, l'agent utilisateur DEVRAIT retarder l'application de la politique juqu'à un certain point. Par exemple, un navigateur Web peut appliquer les préférences de l'utilisateur juste après avoir terminé une navigation ou bien au moment de confirmer la soumission d'un formulaire.
Pour aider au déploiement du protocole P3P sur les sites, on décrit plusieurs scénarios d'utilisation de P3P sur des sites.
Scénario n°1 : Le site Web basique.example.com utilise diverses images, toutes hébergées sur le site. Il contient également quelques formulaires qui renvoient tous au site. Il peut déclarer une seule politique P3P pour le site entier (ou, si des politiques distinctes s'appliquent à des parties différentes du site, déclarer plusieurs politiques P3P). Puisque toutes les images et les adresses URI d'action des formulaires se trouvent dans des répertoires couverts par la politique P3P du site, les agents utilisateurs reconnaîtront automatiquement la couverture des images et des formulaires par la politique du site.
Scénario n°2 : Le site Web bourdonnant.example.com utilise, pour héberger ses images, un réseau de diffusion de contenu
appelé rdc.example.com afin de répartir la charge entre ses serveurs. Ainsi, toutes les images du site ont des adresse URI
dans rdc.example.com. Dans cette configuration, l'hôte Rdc qui se comporte comme un agent pour l'hôte Bourdonnant ne collecte pas
d'autres données que des données d'accès. Ces données d'accès ne sont utilisées que pour le site Web et l'administration du système
dans le cadre de la fourniture de services contractée par Bourdonnant. La politique de confidentialité de Bourdonnant s'applique
aux images hébergées par Rdc, c'est pourquoi Bourdonnant utilise un élément <HINT>
dans son fichier d'appel de politique
pour désigner un fichier d'appel de politique adéquat sur Rdc, indiquant que les images sont couvertes par une politique P3P
de example.com.
Scénario n°3 : Le site Web bourdonnant.example.com a également passé un contrat avec une entreprise de publicité,
nommée cliquepub.example.com, pour la fourniture de bandeaux de publicité sur son site. Le contrat autorise Cliquepub à placer
des cookies afin de contrôler la présentation, pas plus de trois fois, d'un bandeau de publicité au visiteur.
Cliquepub collecte des statistiques sur le nombre de visiteurs voyant chaque publicité et établit un rapport destiné
aux sociétés dont les produits font l'objet des publicités. Toutefois, ces rapports ne révèlent aucun renseignement personnel
sur le visiteur. Comme pour le scénario n°2, la politique de confidentialité de Bourdonnant s'applique à ces publicités hébergées
par Cliquepub, et Bourdonnant utilise ainsi un élément <HINT>
, dans son fichier d'appel de politique,
pour désigner un fichier d'appel de politique adéquat sur Cliquepub, indiqnant que la politique P3P de Bourdonnant
s'applique aux contenus servis par cliquepub.example.com. Les sociétés dont les produits font l'objet des publicités n'ont pas besoin
d'être mentionnées dans la politique de confidentialité de Bourdonnant parce qu'elles reçoivent seulement des données agrégées.
Scénario n°4 : En outre, le site Web bourdonnant.example.com a passé un contrat avec
discussion.example.com afin d'héberger un espace de discussion pour ses utilisateurs. Quand les utilisateurs entrent dans
l'espace de discussion, ils quittent en réalité le site Bourdonnant. Toutefois, l'espace de discussion affiche le logo de Bourdonnant
et l'espace est couvert par la politique de confidentialité de Bourdonnant. Dans ce cas, Discussion se comporte comme un agent
pour Bourdonnant mais, à la différence des exemples précédents, son contenu n'est pas incorporé dans le site de Bourdonnant.
Bourdonnant peut utiliser un élément <HINT>
, dans son fichier de référence de politique, pour désigner un
fichier d'appel de politique adéquat sur Discussion, lequel indique que l'espace de discussion de Discussion est couvert par la
politique de confidentialité de Bourdonnant, facilitant de ce fait une transition en douceur vers l'espace de discussion.
Scénario n°5 : Le site Web metarecherche.example.com contient un formulaire qui permet aux utilisateurs
de taper une requête de recherche, celle-ci ayant lieu sur le moteur de recherche de leur choix situé sur un autre site.
Quand un utilisateur clique le bouton d'envoi
, la requête de recherche est en réalité directement soumise à ces
moteurs de recherche, l'adresse URI d'action n'étant pas situé sur recherche.example.com mais plutôt sur le
moteur de recherche sélectionné par l'utilisateur. Metarecherche peut déclarer les politiques de confidentialité de ces
moteurs de recherche en utilisant un élément <HINT>
pour désigner le fichier d'appel de politique qui leur correspond.
Lorsque l'utilisateur clique sur le bouton d'envoi
, son agent utilisateur peut donc vérifier sa politique de confidentialité
avant de poster des données. Pour que ce mécanisme de choix fonctionne, Metarecherche peut en réalité offrir un formulaire dont
l'adresse URI d'action mène sur son propre site, en effectuant une redirection vers le moteur de recherche concerné.
Dans ce cas, l'agent utilisateur devrait vérifier la politique de confidentialité du moteur de recherche à la réception de la
réponse de redirection.
Scénario n°6 : Le site Web metarecherche.example.com contient aussi un formulaire qui permet aux utilisateurs de taper une requête de recherche qui sera soumise à dix moteurs de recherche en même temps. Metarecherche soumet les requêtes, reçoit en retour les résultats obtenus par chaque moteur de recherche, supprime les doublons et présente un résultat final à l'utilisateur. Dans ce cas, l'utilisateur n'interagit qu'avec Metarecherche. La seule politique P3P impliquée est donc celle qui couvre le site Web de Metarecherche. Toutefois, le site Metarecherche doit annoncer qu'il partage les requêtes de recherche de l'utilisateur avec des tiers (les sites des moteurs de recherche), à moins que Metarecherche ait contracté avec ces moteurs de recherche, auquel cas ils agissent comme des agents pour Metarecherche.
Scénario n°7 : Le site Web metarecherche.example.com comporte également des bandeaux de publicité
fournis par une société nommée reseaupub.example.com. Reseaupub utilise des cookies pour établir des profils d'utilisateur
partagés entre de nombreux sites différents, afin de leur proposer des bandeaux de publicité mieux adaptés à leurs centres d'intérêt.
Puisque les données concernant les sites visités par les utilisateurs ne se limitent pas seulement à servir des publicités
sur le site Web de Metarecherche, on ne peut pas considérer Reseaupub comme un agent dans ce contexte. Reseaupub doit créer
sa propre politique P3P et utiliser son propre fichier de référence de politique pour indiquer à quel contenu elle s'applique.
En outre, Metarecherche peut, en option, utiliser un élément <HINT>
, dans son fichier d'appel de politique,
pour indiquer que le fichier d'appel de politique P3P de Reseaupub s'applique aux publicités.
Metarecherche ne devrait le faire que si Reseaupub a indiqué quelle politique P3P s'applique aux publicités
et a accepté de notifier Metarecherche lorsque l'appel de politique nécessitera un changement.
Scénario n°8: Le site Web bourdonnant.example.com utilise des cookies partout dans le site. Il annonce une
politique de cookie, distincte de sa politique P3P générale, qui couvre ces cookies. Il utilise
un élément <COOKIE-INCLUDE>
, dans son fichier d'appel de politique, pour déclarer la politique appropriée à ceux-ci.
Afin d'optimiser les performances, il fournit également une politique compacte, au moyen d'une en-tête P3P qui inclut
celle-ci, à chaque fois où un cookie est installé.
Scénario n°9: Le site Web config.example.com propose des services d'optimisation pour tous types de contenu Web
en fonction du matériel et de la configuration Internet de chaque utilisateur. Les utilisateurs se rendent sur le site Web de Config
et répondent à diverses questions concernant leur système, leur écran et leur connexion Internet. Config code et range ces réponses
dans un cookie. Par la suite, lorsque l'utilisateur visite le site de Bourdonnant, qui a passé des accords avec Config, et dès lors que
son navigateur aura demandé un contenu optimisable (certaines images ou fichiers audio, etc.), Bourdonnant redirigera
l'utilisateur vers Config, qui lira le cookie de l'utilisateur et délivrera le contenu adéquat. Dans ce cas, le site Config
devrait déclarer une politique de confidentialité décrivant les types des données collectées et stockées dans ses cookies
et comment celles-ci sont exploitées. Il devrait utiliser un élément <COOKIE-INCLUDE>
,
dans son fichier d'appel de politique, pour déclarer la politique de cookies. Il appellera éventuellement la politique P3P
de Bourdonnant pour les fichiers d'images ou audio effectivement délivrés, en cours d'opération un peu comme Rdc le fait dans le scénario n°2.
Le site Bourdonnant utilisera aussi probablement des éléments <HINT>
, dans son fichier d'appel de politique,
pour appeler la politique pour le contenu délivré par Config.
Les politiques P3P sont codées en XML avec des espaces de nommage (cf. [XML] et [XML-Name]). Un codage possible utilisant le modèle de données RDF ([RDF]) est fourni dans [P3P-RDF].
La section 3.1 commence par un exemple de politique de confidentialité en langue naturelle et la politique P3P
correspondante. Les politiques P3P contiennent des assertions générales, qui s'appliquent à la politique entière,
ainsi que des assertions particulières, appelées déclarations, qui s'appliquent seulement à la manipulation
de types de données particuliers, appelées appels de données. La section 3.2 décrit l'élément <POLICY>
et les assertions au niveau de la politique. La section 3.3 décrit les déclarations et les appels de données.
Voici deux exemples de politique de confidentialité en langage naturel avant leur transcription dans une politique P3P. Les deux politiques concernent la société fictive CatalogueExemple qui a différentes politiques, selon que le visiteur navigue seulement dans le site ou que le visiteur achète effectivement des produits. L'exemple 3.1 se présente à la fois en français et dans une description plus formelle utilisant les noms d'éléments et d'attributs P3P.
CatalogueExemple
4000 Lincoln Ave.
Birmingham, MI 48009 USA
email : catalogue@example.com
Telephone 248-EXAMPLE (248-392-6753)
Rétention des données :
Les informations de navigation que nous collectons sont purgées toutes les deux semaines.
Voici maintenant l'exemple 3.1 dans une description plus formelle utilisant les noms d'éléments et d'attributs P3P [la section de la spécification utilisée est citée entre crochets pour en faciliter la référence] :
CatalogueExemple
4000 Lincoln Ave.
Birmingham, MI 48009 USA
email: catalogue@example.com
Telephone +1 248-EXAMPLE (+1 248-392-6753)
Si vous achetez un article, nous vous demanderons des renseignements supplémentaires dont :
Sur cette page, vous pourrez également opter pour recevoir des messages électroniques, des appels téléphoniques
ou des annonces commerciales de CatalogueExemple, ou bien de partenaires commerciaux soigneusement sélectionnés ayant des
pratiques de confidentialité similaires. Si vous optez pour recevoir ces offres, veuillez juste cocher la case appropriée.
Vous pouvez vous désinscrire à tout moment en modifiant simplement vos préférences.
Modification et mise à jour des informations personnelles
Les clients peuvent modifier toutes les informations sur leur compte personnel en se rendant dans la section
préférences de CatalogueExemple à http://catalogue.example.com/preferences.html. Vous pouvez modifier votre adresse,
votre numéro de téléphone, votre adresse électronique, votre mot de passe ainsi que vos préférences de confidentialité.
Cookies
CatalogueExemple emploie des cookies uniquement pour déterminer si vous êtes déjà client chez nous et, le cas échéant, pour
personnaliser nos services en fonction de vos habitudes de navigation et d'achat. Nous ne stockons aucun renseignement personnel
dans les cookies ni ne partageons ni vendons quelques informations que ce soient à des tiers ou affiliés.
Rétention des données
Nous conservons les renseignements vous concernant et ceux concernant vos achats aussi longtemps que vous restez notre client.
Si vous ne passez aucune commande dans une période d'un an, nous supprimerons ces informations de nos bases de données.
Les fragments [XML] suivants effectuent une capture des données exprimées dans les deux exemples ci-dessus. Les politiques P3P sont des déclarations exprimées correctement comme XML bien formé. La syntaxe des politiques sera abordée plus en détails dans la section qui suit.
Le codage XML de l'exemple 3.1 :
<POLICIES xmlns="http://www.w3.org/2002/01/P3Pv1"> <POLICY name="pourNavigateur" discuri="http://www.catalogue.example.com/confidentialite_navigation.html" xml:lang="en"> <ENTITY> <DATA-GROUP> <DATA ref="#business.name">CatalogueExemple</DATA> <DATA ref="#business.contact-info.postal.street">4000 Lincoln Ave.</DATA> <DATA ref="#business.contact-info.postal.city">Birmingham</DATA> <DATA ref="#business.contact-info.postal.stateprov">MI</DATA> <DATA ref="#business.contact-info.postal.postalcode">48009</DATA> <DATA ref="#business.contact-info.postal.country">USA</DATA> <DATA ref="#business.contact-info.online.email">catalogue@example.com</DATA> <DATA ref="#business.contact-info.telecom.telephone.intcode">1</DATA> <DATA ref="#business.contact-info.telecom.telephone.loccode">248</DATA> <DATA ref="#business.contact-info.telecom.telephone.number">3926753</DATA> </DATA-GROUP> </ENTITY> <ACCESS><nonident/></ACCESS> <DISPUTES-GROUP> <DISPUTES resolution-type="independent" service="http://www.sceauconfidentiel.example.org" short-description="sceauconfidentiel.example.org"> <IMG src="http://www.sceauconfidentiel.example.org/Logo.gif" alt="Le logo de SceauConfidentiel"/> <REMEDIES><correct/></REMEDIES> </DISPUTES> </DISPUTES-GROUP> <STATEMENT> <PURPOSE><admin/><develop/></PURPOSE> <RECIPIENT><ours/></RECIPIENT> <RETENTION><stated-purpose/></RETENTION> <!-- Remarquez également que la politique de confidentialité du site lisible par un humain DOIT mentionner la purge des données toutes les deux semaines, ou fournir un lien vers cette information. --> <DATA-GROUP> <DATA ref="#dynamic.clickstream"/> <DATA ref="#dynamic.http"/> </DATA-GROUP> </STATEMENT> </POLICY> </POLICIES>
Codage XML de l'exemple 3.2 :
<POLICIES xmlns="http://www.w3.org/2002/01/P3Pv1"> <POLICY name="pourAcheteurs" discuri="http://www.catalogue.example.com/Privacy/confidentialite_achat.html" opturi="http://catalogue.example.com/preferences.html" xml:lang="en"> <ENTITY> <DATA-GROUP> <DATA ref="#business.name">CatalogueExemple</DATA> <DATA ref="#business.contact-info.postal.street">4000 Lincoln Ave.</DATA> <DATA ref="#business.contact-info.postal.city">Birmingham</DATA> <DATA ref="#business.contact-info.postal.stateprov">MI</DATA> <DATA ref="#business.contact-info.postal.postalcode">48009</DATA> <DATA ref="#business.contact-info.postal.country">USA</DATA> <DATA ref="#business.contact-info.online.email">catalogue@example.com</DATA> <DATA ref="#business.contact-info.telecom.telephone.intcode">1</DATA> <DATA ref="#business.contact-info.telecom.telephone.loccode">248</DATA> <DATA ref="#business.contact-info.telecom.telephone.number">3926753</DATA> </DATA-GROUP> </ENTITY> <ACCESS><contact-and-other/></ACCESS> <DISPUTES-GROUP> <DISPUTES resolution-type="independent" service="http://www.sceauconfidentiel.example.org" short-description="sceauconfidentiel.example.org"> <IMG src="http://www.sceauconfidentiel.example.org/Logo.gif" alt="Logo de SceauConfidentiel"/> <REMEDIES><correct/></REMEDIES> </DISPUTES> </DISPUTES-GROUP> <STATEMENT> <CONSEQUENCE> Nous enregistrons certaines informations pour servir votre commande et pour la sécurité et l'amélioration de notre site Web. </CONSEQUENCE> <PURPOSE><admin/><develop/></PURPOSE> <RECIPIENT><ours/></RECIPIENT> <RETENTION><stated-purpose/></RETENTION> <DATA-GROUP> <DATA ref="#dynamic.clickstream"/> <DATA ref="#dynamic.http.useragent"/> </DATA-GROUP> </STATEMENT> <STATEMENT> <CONSEQUENCE> Nous utilisons ce renseignement quand vous effectuez un achat. </CONSEQUENCE> <PURPOSE><current/></PURPOSE> <RECIPIENT><ours/></RECIPIENT> <RETENTION><stated-purpose/></RETENTION> <DATA-GROUP> <DATA ref="#user.name"/> <DATA ref="#user.home-info.postal"/> <DATA ref="#user.home-info.telecom.telephone"/> <DATA ref="#user.business-info.postal"/> <DATA ref="#user.business-info.telecom.telephone"/> <DATA ref="#user.home-info.online.email"/> <DATA ref="#user.login.id"/> <DATA ref="#user.login.password"/> <DATA ref="#dynamic.miscdata"> <CATEGORIES><purchase/></CATEGORIES> </DATA> </DATA-GROUP> </STATEMENT> <STATEMENT> <CONSEQUENCE> À votre demande, nous vous enverrons des offres commerciales soigneusement sélectionnées qui sont susceptibles de vous intéresser. </CONSEQUENCE> <PURPOSE> <contact required="opt-in"/> <individual-decision required="opt-in"/> <tailoring required="opt-in"/> </PURPOSE> <RECIPIENT><ours/><same required="opt-in"/></RECIPIENT> <RETENTION><stated-purpose/></RETENTION> <DATA-GROUP> <DATA ref="#user.name" optional="yes"/> <DATA ref="#user.home-info.postal" optional="yes"/> <DATA ref="#user.home-info.telecom.telephone" optional="yes"/> <DATA ref="#user.business-info.postal" optional="yes"/> <DATA ref="#user.business-info.telecom.telephone" optional="yes"/> <DATA ref="#user.home-info.online.email" optional="yes"/> </DATA-GROUP> </STATEMENT> <STATEMENT> <CONSEQUENCE> Vous pouvez disposer d'un mot de passe permettant d'accéder à vos informations personnelles. </CONSEQUENCE> <PURPOSE><individual-decision required="opt-in"/></PURPOSE> <RECIPIENT><ours/></RECIPIENT> <RETENTION><stated-purpose/></RETENTION> <DATA-GROUP> <DATA ref="#user.login.id"/> <DATA ref="#user.login.password"/> <CATEGORIES><uniqueid/></CATEGORIES> </DATA> </DATA-GROUP> </STATEMENT> <STATEMENT> <CONSEQUENCE> À votre demande, nous pouvons personnaliser notre site et mettre en exergue les produits qui correspondent à vos intérêts. </CONSEQUENCE> <PURPOSE> <pseudo-decision required="opt-in"/> <tailoring required="opt-in"/> </PURPOSE> <RECIPIENT><ours/></RECIPIENT> <RETENTION><stated-purpose/></RETENTION> <DATA-GROUP> <DATA ref="#user.bdate.ymd.year" optional="yes"/> <DATA ref="#user.gender" optional="yes"/> </DATA-GROUP> </STATEMENT> <STATEMENT> <CONSEQUENCE> Nous personnalisons notre site en fonction de vos visites antérieures. </CONSEQUENCE> <PURPOSE><tailoring/><develop/></PURPOSE> <RECIPIENT><ours/></RECIPIENT> <RETENTION><stated-purpose/></RETENTION> <DATA-GROUP> <DATA ref="#dynamic.cookies"> <CATEGORIES><state/></CATEGORIES> </DATA> <DATA ref="#dynamic.miscdata"> <CATEGORIES><preference/></CATEGORIES> </DATA> </DATA-GROUP> </STATEMENT> </POLICY> </POLICIES>
Cette section définit la syntaxe et la sémantique des politiques P3P. Toutes les politique DOIVENT être codées en utilisant [UTF-8].
Au cas où le vocabulaire P3P n'est pas assez précis pour décrire les pratiques d'un site Web,
les sites devraient employer les termes de vocabulaire qui se rapprochent le plus de leurs pratiques et fournir des
explications plus complètes dans le champ <CONSEQUENCE>
et/ou leur politique lisible par un humain.
Néanmoins, les politiques NE DOIVENT PAS faire de déclarations fausses ou trompeuses.
Les politiques doivent être placées dans un élément <POLICIES>
.
POLICIES
L'élément <POLICIES>
rassemble une ou plusieurs politiques P3P dans un seul fichier.
Cette caractéristique permet d'optimiser les performances : plusieurs politiques sont réunies pour composer une seule requête,
ce qui améliore le trafic sur les réseaux et la mise en cache.
L'élément <POLICIES>
est l'élément racine des fichiers de politique. En outre, on peut placer
des éléments <POLICIES>
dans le fichier d'appel de politique, à l'intérieur d'un
élément <META>
; auquel cas, l'agent utilisateur n'a besoin de récupérer qu'un seul fichier contenant
à la fois le fichier d'appel de politique et les politiques.
L'élément <POLICIES>
peut contenir, en option, un attribut xml:lang
(cf. la
section 2.4.2), un élément <EXPIRY>
,
indiquant la date d'expiration des politiques incluses, et un schéma de données incorporé en utilisant
l'élément <DATASCHEMA>
(cf. la section 5).
Puisque les politiques sont incluses dans un élément <POLICIES>
, chacune DOIT avoir un attribut name
unique dans le fichier. C'est ce qui permet leur mobilisation par les appels de politique (dans les éléments <POLICY-REF>
).
Exemple 3.3 :
Le fichier situé à http://www.example.com/magasin/politiques.xml
pourrait avoir le contenu suivant :
<POLICIES xmlns="http://www.w3.org/2002/01/P3Pv1"> <POLICY name="politique1" discuri="http://www.example.com/disc1"> .... </POLICY> <POLICY name="politique2" discuri="http://www.example.com/disc2"> .... </POLICY> <POLICY name="politique3" discuri="http://www.example.com/disc3"> .... </POLICY> </POLICIES>
Les fichiers situés à http://www.example.com/magasin/CDs/*
pourraient alors être associés à la
deuxième politique ("politique2") en utilisant le fichier d'appel de politique suivant, à http://www.example.com/w3c/p3p.xml
:
<META xmlns="http://www.w3.org/2002/01/P3Pv1"> <POLICY-REFERENCES> <POLICY-REF about="/magasin/politiques#politique2"> <INCLUDE>/magasin/CDs/*</INCLUDE> </POLICY-REF> </POLICY-REFERENCES> </META>
[19] policies = `<POLICIES xmlns="http://www.w3.org/2002/01/P3Pv1"` [xml-lang] `>` [expiry] [dataschema] *policy "</POLICIES>"
POLICY
L'élément <POLICY>
contient une politique P3P complète. Chaque politique DOIT contenir
exactement un seul élément <POLICY>
. L'élément <POLICY>
DOIT contenir un
élément <ENTITY>
identifiant l'entité légale exposant les pratiques de confidentialité contenues dans la politique.
En outre, l'élément <POLICY>
DOIT contenir un élément <ACCESS>
, un ou plusieurs
éléments <STATEMENT>
, un élément <DISPUTES-GROUP>
,
un schéma de données P3P et une ou plusieurs extensions.
<POLICY>
name
(attribut obligatoire)discuri
(attribut obligatoire)opturi
<PURPOSE>
dont la valeur de l'attribut required
est "opt-in
" ou "opt-out
". Remarquez que les procédures d'inscription ou de désinscription sont déterminées
par chaque site et ne comprennent pas forcément un mécanisme centralisé pour le site entier ou un mécanisme automatisé en ligne.xml:lang
[20] policy = `<POLICY name=` quotedstring ` discuri=` quoted-URI [` opturi=` quoted-URI] [xml-lang] `>` *extension [test] entity access [disputes-group] 1*statement-block *extension `</POLICY>` [21] quoted-URI = `"` URI `"`
Ici, la valeur URI est définie selon RFC 2396 [URI].
TEST
L'élément <TEST>
sert à effectuer des simulations : la présence de cet élément dans une politique indique
que celle-ci est simplement un exemple et, de ce fait, elle DOIT être ignorée et considérée comme une politique P3P invalide.
[22] test = "<TEST/>"
ENTITY
L'élément <ENTITY>
donnent une description précise de l'entité légale qui
expose ses pratiques de confidentialité.
<ENTITY>
L'élément <ENTITY>
contient une description de l'entité légale qui consiste en
éléments <DATA> appelant tout ou partie des champs du jeu de données d'entreprise :
il DOIT contenir au moins le nom de l'entité légale et un (ou plusieurs) champ(s) de coordonnées choisi(s) parmi les
champs adresse postale, numéro de téléphone, adresse électronique, adresse URI. Remarquez que certains règlements légaux
et codes de conduite imposent aux entités d'inclure une adresse postale ou d'autres renseignements spécifiques comme coordonnées.
[23] entity = "<ENTITY>" *extension entitydescription *extension "</ENTITY>" [24] entitydescription = "<DATA-GROUP>" `<DATA ref="#business.name"/>` PCDATA "</DATA>" *(`<DATA ref="#business.` string `"/>` PCDATA "</DATA>") "</DATA-GROUP>"
Ici, la valeur string
est définie comme une séquence de caractères (les caractères "
et &
étant masqués)
composant une des valeurs admises du jeu de données d'entreprise. La valeur PCDATA
est définie
comme dans [XML].
ACCESS
L'élément <ACCESS>
indique si le site offre, ou non, un accès à divers types de renseignements.
<ACCESS>
access
.
La méthode d'accès n'est pas spécifiée. Une annonce (autre que <all/>
) n'implique pas qu'on puisse accéder
à toutes les données mais seulement à certaines, et les utilisateurs devraient entrer en relation avec le fournisseur de services
pour déterminer quelles sont les possibilités dont ils disposent.
Remarquez que les fournisseurs de services peuvent aussi autoriser un accès aux informations collectées via d'autres moyens que
par le Web à l'adresse URI indiquée par l'attribut discuri
. La portée des
déclarations P3P est limitée aux données collectées au travers du protocole HTTP ou d'autres protocoles
de transport Web. En outre, lorsque cet accès a lieu par le Web, on recommande l'utilisation de mécanismes d'authentification
et de sécurité forts pour ces échanges ; les questions de sécurité ne sont toutefois pas abordées par ce document.
L'élément <ACCESS>
doit contenir l'un des éléments suivants :
<nonident/>
<all/>
<contact-and-other/>
<ident-contact/>
<other-ident/>
<none/>
[25] access = "<ACCESS>" *extension access_disclosure *extension "</ACCESS>" [26] access_disclosure = "<nonident/>" | ; Les données identifiées ne sont pas utilisées "<all/>" | ; Toutes les informations identifiables "<contact-and-other/>" | ; Les coordonnées et autres données identifiées "<ident-contact/>" | ; Les coordonnées identifiables "<other-ident/>" | ; Autres données identifiées "<none/>" ; Aucun
DISPUTES
Une politique DEVRAIT contenir un élément <DISPUTES-GROUP>
contenant à son tour un ou plusieurs
éléments <DISPUTES>
. Ces éléments décrivent les procédures de résolution des litiges à observer
en cas de contestation des pratiques de confidentialité des services. Chaque élément <DISPUTES>
peut contenir, en option, un élément <LONG-DESCRIPTION>
, un élément <IMG>
et un
élément <REMEDIES>
. Les fournisseurs de services qui disposent de plusieurs procédures de résolution des litiges
devraient se servir d'un élément <DISPUTES>
différent pour chacune d'elles. Puisque les différentes procédures
de contentieux appellent des processus de réparation séparés, chacun des éléments <DISPUTES>
aura besoin
d'éléments <LONG-DESCRIPTION>
, <IMG>
et <REMEDIES>
distincts,
si on se sert de ces éléments.
<DISPUTES>
resolution-type
(attribut obligatoire)service
independent
court
law
service
(attribut obligatoire)verification
short-description
L'élément <DISPUTES>
peut contenir un élément <LONG-DESCRIPTION>
dans
lequel se trouve une description lisible par un humain : cette description devrait comprendre le nom de la juridiction concernée,
les règlements applicables ou une organisation tierce, ou bien les coordonnées du service clientèle si celles-ci ne sont pas
déjà mentionnées à l'adresse URI du service en question.
<LONG-DESCRIPTION>
<IMG>
src
(attribut obligatoire)width
height
alt
(attribut obligatoire)[27] disputes-group = "<DISPUTES-GROUP>" *extension 1*dispute *extension "</DISPUTES-GROUP>" [28] dispute = "<DISPUTES" " resolution-type=" '"'("service"|"independent"|"court"|"law")'"' " service=" quoted-URI [" verification=" quotedstring] [" short-description=" quotedstring] ">" *extension [longdescription] [image] [remedies] *extension "</DISPUTES>" [29] longdescription = <LONG-DESCRIPTION> PCDATA </LONG-DESCRIPTION> [30] image = "<IMG src=" quoted-URI [" width=" `"` number `"`] [" height=" `"` number `"`] " alt=" quotedstring "/>" [31] quotedstring = `"` string `"`
Ici, la valeur string
est définie comme une séquence de caractères (les caractères "
et &
doivent être masqués) et la valeur PCDATA
est définie comme dans [XML].
Remarquez qu'il peut y avoir plusieurs services de certification, indiqués par autant d'éléments <DISPUTES>
dans l'élément <DISPUTES-GROUP>
. Ces champs sont censés être utilisés de plusieurs façons, y compris l'indication
que les pratiques de confidentialité en question sont auto-certifiées, contrôlées par un tiers ou soumises à la juridiction
d'un organisme de régulation.
REMEDIES
Chaque élément <DISPUTES>
DEVRAIT contenir un élément <REMEDIES>
qui définit les
réparations possibles en cas de violation de la politique.
<REMEDIES>
L'élément <REMEDIES>
doit contenir l'un ou plusieurs des éléments suivants :
<correct/>
<money/>
<law/>
[32] remedies = "<REMEDIES>" *extension 1*remedy *extension "</REMEDIES>" [33] remedy = "<correct/>" | "<money/>" | "<law/>"
Les déclarations décrivent le traitement appliqué aux types de données spécifiques.
STATEMENT
L'élément <STATEMENT>
est un conteneur regroupant un élément <PURPOSE>
,
un élément <RECIPIENT>
, un élément <RETENTION>
, un élément <DATA-GROUP>
et,
en option, un élément <CONSEQUENCE>
ainsi qu'une ou plusieurs extensions.
Toutes les données référencées par l'élément <DATA-GROUP>
sont manipulées conformément aux divulgations
présentes dans les autres éléments contenus par la déclaration. Les sites peuvent ainsi regrouper les éléments qui se manipulent
de la même façon et créer une déclaration pour chaque regroupement. Les sites préférant divulguer séparément des intentions et
d'autres informations pour chaque type de données collectées peuvent le faire en créant une déclaration séparée par élément de données.
<STATEMENT>
[34] statement-block = "<STATEMENT>" *extension [consequence] ((purpose recipient retention 1*data-group) | (non-identifiable [purpose] [recipient] [retention] *data-group)) *extension "</STATEMENT>"
Pour simplifier la déclaration des pratiques, les fournisseurs de services peuvent assembler n'importe quelle divulgation
(c'est-à-dire, les intentions (<INTENTION>
), les destinataires (<RECIPIENT>
) et la rétention
(<RETENTION>
)) en une déclaration globale couvrant les éléments de données. Les fournisseurs de services DOIVENT réaliser
ces assemblages de manière additive. Par exemple, un site distribuant votre âge selon une destination <ours>
(nous-mêmes et nos agents) et, par contre, votre code postal selon une destination <unrelated>
(tiers non apparenté) PEUT annoncer qu'il distribue votre nom et votre code postal selon les destinations <ours>
et <unrelated>
. Une telle déclaration semblera distribuer plus de données qu'en réalité. Il est de la responsabilité
du fournisseur de services de déterminer la concision et la précision de ses divulgations. Remarquez que, dans un assemblage de
divulgations issues de déclarations parmi lesquelles apparaît un élément <NON-IDENTIFIABLE>
, cet élément
ne pourra être inclus dans la déclaration assemblée (globale) que s'il apparaît dans chacune des déclarations prises séparément.
De même, on doit toujours divulguer toutes les options qui s'appliquent. Supposons un site dont le seul but est de collecter
des informations avec une intention <contact/>
(Contact des visiteurs pour la commercialisation de services ou produits).
Bien que cette opération puisse avoir lieu dans le contexte d'une intention <current/>
(Achèvement et support d'un processus avec les données fournies), le site doit déclarer les deux intentions
<contact/>
et <current/>
. Supposons qu'un site distribue des informations à un
destinataire <ours>
pour leur redistribution à un destinataire <public>
:
le site doit alors déclarer les deux destinataires <ours>
et <public>
.
Les fournisseurs de services assemblent souvent les données qu'ils collectent. Parfois, ces données globales seront utilisées pour d'autres buts, partagées plus largement ou conservées plus longtemps que les données originales. Par exemple, beaucoup de sites publient ou divulguent des statistiques pour leurs annonceurs, tels que le nombre des visiteurs sur leur site Web, le pourcentage des visiteurs rangés par groupes démographiques, etc. Lorsqu'on utilise ou partage des statistiques globales à partir desquelles il est impossible de déduire des renseignements personnels concernant un individu ou un foyer, il n'est pas nécessaire de les divulguer dans une politique P3P. Par contre, les services DOIVENT divulguer la collecte des données originales et déclarer toute utilisation de celles-ci avant leur assemblage.
CONSEQUENCE
Les éléments <STATEMENT>
peuvent, en option, contenir un élément <CONSEQUENCE>
dont la présentation permettra à un utilisateur humain d'obtenir plus informations concernant les pratiques d'un site.
<CONSEQUENCE>
[35] consequence = "<CONSEQUENCE>" PCDATA "</CONSEQUENCE>"
NON-IDENTIFIABLE
Un élément <STATEMENT>
peut contenir, en option, un élément <NON-IDENTIFIABLE>
,
dont la présence signifie soit qu'aucune donnée n'est collectée dans le cadre de cet élément <STATEMENT>
,
soit que les données appelées par cet élément <STATEMENT>
seront rendues anonymes lors de leur collecte.
<NON-IDENTIFIABLE/>
<STATEMENT>
englobant.
Les données seront considérées anonymessi l'entité ou un tiers sont dans l'incapacité de les rattacher à l'identité d'une personne en utilisant des moyens raisonnables. Par essence, certains types de données sont anonymes comme c'est le cas, par exemple, pour les identifiants de session générés aléatoirement. Les données qui, dans certaines circonstances, sont susceptibles de permettre l'identification des personnes, tels que les adresses IP, les noms ou les adresses, doivent subir une transformation non réversible pour être considérées anonymes.
Si l'élément <NON-IDENTIFIABLE>
est présent dans un élément <STATEMENT>
de politique,
alors on DOIT inclure une explication, lisible par un humain, des moyens par lesquels les données ont été rendues anonymes
ou bien indiquer l'adresse de cette explication avec un attribut discuri
.
De même, si l'élément <NON-IDENTIFIABLE>
est présent dans un élément <STATEMENT>
, alors
les autres éléments contenus dans ce <STATEMENT>
deviennent optionnels.
[36] non-identifiable = "<NON-IDENTIFIABLE/>"
PURPOSE
Tout élément <STATEMENT>
sans sous-élément <NON-IDENTIFIABLE>
DOIT contenir
un élément <PURPOSE>
qui exprime une ou plusieurs intentions concernant la collecte ou l'utilisation des données.
Les sites DOIVENT classer leurs pratiques vis-à-vis des données dans l'une ou plusieurs des catégories d'intention énoncées ci-dessous.
<PURPOSE>
L'élément <PURPOSE>
DOIT contenir l'une ou plusieurs des intentions suivantes :
<current/>
<admin/>
<develop/>
<tailoring/>
<pseudo-analysis/>
<pseudo-decision/>
<individual-analysis/>
<individual-decision/>
<contact/>
<current/>
). En outre, n'est pas concernée la commercialisation, via un contenu Web
ou des bandeaux publicitaires personnalisés, incorporée aux sites visités par l'utilisateur (ces cas seraient couverts par les
valeurs d'intention <tailoring/>
, <pseudo-analysis/>
et <pseudo-decision/>
,
ou <individual-analysis/>
et <individual-decision/>
).<historical/>
<DISPUTES>
et DOIT inclure une définition précise du type de chercheur qualifié pouvant accéder à ces informations,
de l'endroit où ces informations seront stockées et, particulièrement, en quoi cette collecte participe à la conservation historique.<telemarketing/>
<current/>
).<other-purpose>
chaîne </other-purpose>
Chaque type d'intention (sauf <current/>
) admet les attributs optionnels suivants :
required
always
: L'intention est toujours obligatoire et les utilisateurs ne peuvent ni accepter
ni refuser cet usage de leurs données. C'est la valeur implicite en l'absence de l'attribut required
;opt-in
: Les données peuvent être utilisées dans l'intention en question
si l'utilisateur affirme cet usage, par exemple, à l'occasion d'une inscription sur une liste de diffusion.
Une requête affirmative oblige l'utilisateur à exercer une action spécifique pour manifester sa volonté. Par exemple,
lorsque l'utilisateur remplit un formulaire de sondage, le fait de cocher une case supplémentaire pour s'inscrire à une liste de diffusion
constitue une requête affirmative. Par contre, ce ne serait pas le cas si le formulaire de sondage était présenté avec
une demande d'inscription précochée. En outre, quelle que soit l'intention pour laquelle l'utilisateur se manifeste affirmativement,
il doit pouvoir se désengager s'il change d'avis (on DOIT le préciser à l'adresse URI indiquée par
l'attribut opturi
;opt-out
: Les données peuvent être utilisées dans l'intention en question,
à moins que l'utilisateur demande qu'on ne les utilise pas de cette manière. Pour cette valeur, le service DOIT fournir à l'utilisateur
des instructions claires, à l'adresse URI indiquée par l'attribut opturi
,
afin qu'il puisse se soustraire de cette intention. Les services DEVRAIENT également afficher ces instructions, ou un pointeur vers
celles-ci, au point de collecte des données.[37] purpose = "<PURPOSE>" *extension 1*purposevalue *extension "</PURPOSE>" [38] purposevalue = "<current/>" | ; Achèvement et support d'un processus ; avec les données fournies "<admin" [required] "/>" | ; Administration du site et du système "<develop" [required] "/>" | ; Recherche et développement "<tailoring" [required] "/>" | ; Ajustement ponctuel "<pseudo-analysis" [required] "/>" | ; Analyse pseudonyme "<pseudo-decision" [required] "/>" | ; Décision pseudonyme "<individual-analysis" [required] "/>" | ; Analyse individuelle "<individual-decision" [required] "/>" | ; Décision individuelle "<contact" [required] "/>" | ; Contact des visiteurs pour la ; commercialisation de services ou produits "<historical" [required] "/>" | ; Conservation historique "<telemarketing" [required] "/>" | ; Commercialisation par téléphone "<other-purpose" [required] ">" PCDATA "</other-purpose>" ; Autres usages [39] required = " required=" `"` ("always"|"opt-in"|"opt-out") `"`
Les fournisseurs de services DOIVENT utiliser les éléments ci-dessus pour expliquer l'intention motivant la collecte des données.
Ils DOIVENT divulguer toutes les intentions qui s'appliquent. Si un fournisseur de services n'annonce pas d'utilisation d'un
élément de données pour une intention donnée, cela implique que ces données ne seront pas utilisées dans l'intention en question.
Les fournisseurs de services qui annoncent l'utilisation de données pour une intention Autres usages
(<other-purpose>
) DOIVENT fournir des explications lisibles par un humain de cette intention.
RECIPIENT
Tout élément <STATEMENT>
sans sous-élément <NON-IDENTIFIABLE>
DOIT contenir un
élément <RECIPIENT>
lequel indique le (ou les) destinataire(s) des données collectées. Les sites DOIVENT doivent
classer les destinataires parmi l'un ou plusieurs des suivants :
<RECIPIENT>
L'élément <RECIPIENT>
DOIT contenir l'un ou plusieurs des destinataires suivants :
<ours>
<delivery>
<same>
<other-recipient>
<unrelated>
<public>
Chacune des balises précédentes peuvent inclure en option :
<recipient-description>
contenant une description du destinataire ;<ours>
, un attribut required
. Cet attribut, qui est
défini exactement comme l'attribut analogue de l'élément <PURPOSE>
, indique s'il est possible, ou non,
d'accepter N.D.T. opt-in ou de refuser (N.D.T. opt-out) le partage des données
(la valeur par défaut est always
).[40] recipient = "<RECIPIENT>" *extension 1*recipientvalue *extension "</RECIPIENT>" [41] recipientvalue = "<ours>" *recdescr "</ours> | ; Seulement nous-même et nos agents "<same" [required] ">" *recdescr "</same>" | ; Les personnes morales suivant ; nos pratiques "<other-recipient" [required] ">" *recdescr "</other-recipient>" | ; Les personnes morales suivant ; des pratiques différentes "<delivery" [required] ">" *recdescr "</delivery>" | ; Les services de livraison suivant ; des pratiques différentes "<public" [required] ">" *recdescr "</public>" | ; Les tribunes publiques "<unrelated" [required] ">" *recdescr "</unrelated>" ; Les tiers non apparentés [42] recdescr = "<recipient-description>" PCDATA ; Description du destinataire "</recipient-description>"
Les fournisseurs de services DOIVENT divulguer tous les destinataires qui s'appliquent. Le protocole P3P ne fait aucune distinction sur la manière dont les données sont délivrées au destinataire ; en cas de partage des données, il impose simplement la divulgation de ce partage dans la politique P3P. Comme exemples de divulgations de données qui DOIVENT être couvertes par une politique P3P :
Remarquez que le jeu de destinataires ci-dessus peut, dans certains cas, ne pas décrire entièrement tous les destinataires des données. Par exemple, la question des facilitateurs de transaction, tels que les services d'expédition ou de paiement, nécessaires pour l'achèvement et le support du processus mais susceptibles de suivre des pratiques différentes, posait problème. Pour l'instant, seuls les services de livraison peuvent être explicitement représentés dans une politique. Les autres facilitateurs de transaction devraient l'être dans les catégories qui réflètent le mieux leurs politiques par rapport au fournisseur de services original.
Un élément spécifique est prévu pour les services de livraison mais pas un seul pour les facilitateurs de paiement (tels que les banques ou les organismes de crédit), pour la raison suivante : les institutions financières auront généralement passé des accords séparés avec leurs clients, concernant leurs données bancaires, tandis que les destinataires d'une livraison n'auront pas eu l'opportunité d'examiner la politique de confidentialité du service de livraison en question.
Remarquez qu'on NE DEVRAIT PAS utiliser la balise <delivery>
pour les services de distribution
qui reconnaissent seulement utiliser les données au nom du fournisseur de services afin de terminer la livraison.
RETENTION
Tout élément <STATEMENT>
sans sous-élément <NON-IDENTIFIABLE>
DOIT contenir un
élément <RETENTION>
indiquant le type de politique de rétention appliqué aux données référencées dans la déclaration.
<RETENTION>
L'élément <RETENTION>
DOIT contenir l'une des éléments suivants :
<no-retention/>
<stated-purpose/>
<legal-requirement/>
<business-practices/>
<indefinitely/>
[43] retention = "<RETENTION>" *extension retentionvalue *extension "</RETENTION>" [44] retentionvalue = "<no-retention/>" | ; non conservé "<stated-purpose/>" | ; selon l'intention déclarée "<legal-requirement/>" | ; selon une intention déclarée et la loi "<business-practices/>" | ; selon des pratiques commerciales "<indefinitely/>" ; durée indéterminée
DATA-GROUP
et DATA
Tout élément <STATEMENT>
sans sous-élément <NON-IDENTIFIABLE>
DOIT contenir au moins
un élément <DATA-GROUP>
lequel contient à son tour un ou plusieurs éléments <DATA>
.
Les éléments <DATA>
servent à décrire les type de données collectés par un site.
<DATA-GROUP>
base
ref
. Quand cet attribut est omis, la valeur par défaut pour l'URI correspond à l'URI
du schéma de données P3P de base (http://www.w3.org/TR/P3P/base).
Quand l'attribut se présente sous la forme d'une chaîne vide (""), la base correspond au document local.<DATA>
ref
(attribut obligatoire)<DATA>
est contenu dans
un élément <DATA-GROUP>
, alors l'adresse URI de base par défaut est censée être celle indiquée
par l'attribut base
. Pour les autres cas, comme toujours, l'adresse URI de base par défaut se réfère
au même document ([URI]).user.gender
se distingue de USER.GENDER
ou User.Gender
).optional
no
" signifie que l'élément de données n'est pas optionnel (donc obligatoire) et
la valeur "yes
", au contraire, qu'il est optionnel. La valeur implicite est "no
".
L'attribut optional
n'apparaît que dans les politiques (pas dans les définitions des schémas de données).Remarquez que les agents utilisateurs devraient prendre des précautions lorsqu'ils utilisent l'attribut optional
dans
le contexte d'une prise de décision automatisée. Si l'attribut optional
est associé directement à un élément de données
contrôlé par l'agent utilisateur (tels qu'une en-tête HTTP Referer ou un cookie), alors l'agent utilisateur devrait
faire attention à ne pas transmettre ces données à des sites Web sur lesquels un élément de données est optionnel
et où la politique du site ne correspondrait pas aux préférences de l'utilisateur si l'élément de données était obligatoire.
De même, pour les éléments de données que les utilisateurs saisissent habituellement dans les formulaires, les agents utilisateurs
devraient avertir les utilisateurs lorsque les pratiques d'un site vis-à-vis de données optionnelles ne correspondent pas
à leurs préférences.
Les éléments <DATA>
peuvent contenir les données réelles (comme défini pour l'élément <ENTITY>
)
et des informations sur la catégorie apparentée.
[45] data-group = "<DATA-GROUP" [" base=" quoted-URI] ">" *extension 1*dataref *extension "</DATA-GROUP>" [46] dataref = `<DATA" ref="` URI-reference `"` [" optional=" `"` ("yes"|"no") `"`] ">" [categories] ; les catégories de l'élément de données. [PCDATA] ; la valeur éventuelle de l'élément de données "</DATA>"
Ici, la valeur URI-reference
est définie comme dans [URI].
Par exemple, le service qui voudrait référencer la ville de l'adresse du domicile de l'utilisateur, tous les éléments du
jeu de données user.business-info
et (en option) tous les éléments du jeu de données user.home-info.telecom
indiquera dans sa politique P3P les références suivantes :
<DATA-GROUP> <DATA ref="#user.home-info.city"/> <DATA ref="#user.home-info.telecom" optional="yes"/> <DATA ref="#user.business-info"/> </DATA-GROUP>
Lorsque la valeur réelle d'une donnée est connue, elle peut apparaître dans l'élément <DATA>
.
Par exemple, cf. les exemples de politiques :
<ENTITY> <DATA-GROUP> <DATA ref="#business.name">CatalogueExemple</DATA> <DATA ref="#business.contact-info.postal.street">4000 Lincoln Ave.</DATA> ...
CATEGORIES
Les catégories sont des éléments dans les éléments de données offrant aux utilisateurs et aux agents utilisateurs
des indications concernant les usage prévus des données. Les catégories sont essentielles et facilitent la mise en œuvre
et l'utilisation des agents utilisateurs P3P. Remarquez que les catégories ne sont pas des éléments de données :
elles permettent simplement aux utilisateurs d'exprimer des préférences et des règles plus générales pour échanger leurs données.
On NE DEVRAIENT PAS utiliser recourir aux catégories dans les sous-éléments <DATA>
des
éléments <ENTITY>
.
On utilise les éléments suivants pour indiquer les catégories des données :
[47] categories = "<CATEGORIES>" 1*category "</CATEGORIES>" [48] category = "<physical/>" | ; coordonnées physiques "<online/>" | ; coordonnées en ligne "<uniqueid/>" | ; identificateurs uniques "<purchase/>" | ; informations d'achat "<financial/>" | ; informations financières "<computer/>" | ; informations sur le système "<navigation/>" | ; données de navigation et de parcours "<interactive/>" | ; données interactives "<demographic/>" | ; données démographiques et socio-économiques "<content/>" | ; contenu "<state/>" | ; mécanismes de gestion d'état "<political/>" | ; informations politiques "<health/>" | ; informations de santé "<preference/>" | ; données préférentielles "<location/>" | ; données géographiques "<government/> | ; identificateurs d'origine gouvernementale "<other-category>" PCDATA "</other-category>" ; Autres
<physical/>
<online/>
Informations sur le système).
<uniqueid/>
<purchase/>
<financial/>
Informations d'achat, n'entrent pas seules dans le cadre de la catégorie
Informations financières.
<computer/>
<navigation/>
<interactive/>
<demographic/>
<content/>
<state/>
<political/>
<health/>
<preference/>
<location/>
<<government/>>
<other-category>
chaîne </other-category>
<other-category>
et </other-category>
).Les catégories computer
, navigation
, interactive
et
content
peuvent se distinguer comme suit. La catégorie computer
comprend les informations sur
l'ordinateur de l'utilisateur y compris l'adresse IP et la configuration logicielle. Les données de type navigation
décrivent le comportement effectif de l'utilisateur lors d'une navigation. Lorsqu'une adresse IP est stockée
dans un fichier journal avec des informations relatives à l'activité de navigation, on devrait utiliser les deux catégories
computer
et navigation
. La catégorie interactive
correspond aux données sollicitées activement,
hormi celles de navigation, afin d'obtenir un certain service utile d'un site. La catégorie content
correspond
aux informations échangées sur un site au motif de la communication.
On ne devrait se servir de la catégorie other
que si les données requises n'entrent dans aucune autre catégorie.
Le protocole P3P utilise des catégories pour fournir des indications supplémentaires aux utilisateurs et
aux agents utilisateurs sur le type d'information requis par un service. Bien que la plupart des données dans le schéma de données de base
se rangent dans des catégories connues (ou un jeu de catégories connu), certains éléments de données peuvent se trouver dans
plusieurs catégories, en fonction du contexte. Celles des catégories connues sont appellées éléments de données de catégorie fixe
(ou, en abrégé, éléments de données fixes
) et les autres éléments de données de catégorie variable
(ou éléments de données variables
). Les deux types d'élément sont décrits dans la section 5.7.
EXTENSION
Le protocole P3P offre un mécanisme souple et puissant permettant d'étendre sa syntaxe et sa sémantique grâce
à l'élément <EXTENSION>
. Cet élément sert à indiquer les parties de la politique, du fichier d'appel de politique
ou du schéma de données qui appartiennent à une extension. La signification des données dans l'élément <EXTENSION>
est définie par l'extension elle-même.
<EXTENSION>
optional
no
" à l'attribut optional
. Une extension obligatoire
de la syntaxe P3P signifie que les applications qui ne comprennent pas cette extension ne pourront pas non plus
comprendre la politique en entier (ou le fichier d'appel de politique, ou le schéma de données) qui la contient.
Une extension optionnelle, l'attribut optional
ayant la valeur "yes
", signifie que les applications
qui ne comprennent pas cette extension peuvent ignorer en toute sécurité le contenu de l'élément <EXTENSION>
et poursuivre le traitement de la politique entière (ou du fichier d'appel de politique, ou du schéma de données) comme si de rien n'était.
L'attribut optional
n'est pas obligatoire : sa valeur implicite est "yes
".[49] extension = "<EXTENSION" [" optional=" `"` ("yes"|"no") `"`] ">" PCDATA "</EXTENSION>"
Par exemple, si le site www.catalogue.example.com souhaite ajouter une fonctionnalité à P3P telle que seuls les utilisateurs vivant aux États-Unis, au Canada et au Mexique sont concernés par la collecte d'un certain jeu de données, il pourrait définir l'extension obligatoire suivante :
<DATA-GROUP> ... <EXTENSION optional="no"> <COLLECTION-GEOGRAPHY type="include" xmlns="http://www.catalogue.example.com/P3P/region"> <USA/><Canada/><Mexique/> </COLLECTION-GEOGRAPHY> </EXTENSION> </DATA-GROUP>
À l'inverse, si www.catalogue.example.com souhaite ajouter une extension qui annonce la localisation géographique du serveur, l'extension optionnelle suivante serait plus appropriée :
<POLICY> <EXTENSION optional="yes"> <ORIGIN xmlns="http://www.catalogue.example.com/P3P/origine" country="USA"/> </EXTENSION> ... </POLICY>
L'attribut xmlns
est significatif car il définit l'espace de nommage pour l'interprétation des noms des éléments et attributs
utilisés dans l'extension. Remarquez que, comme spécifié dans [XML-Name], l'adresse URI
de l'espace de nommage sert juste d'identificateur unique aux entités XML utilisées par l'extension. Toutefois,
les fournisseurs de services PEUVENT fournir une page décrivant l'extension à l'adresse URI correspondante.
L'élément <EXTENSION>
peut apparaître à diverses positions dans la syntaxe P3P :
le schéma XML présent dans l'annexe 4 spécifie ces positions de manière normative (elles sont
définies de manière informelle par la syntaxe ABNF et le DTD présent dans l'annexe 5).
Les agents utilisateurs DOIVENT documenter une méthode permettant d'importer et de traiter des préférences et DEVRAIENT en documenter une permettant de les exporter.
Les agents utilisateurs P3P DOIVENT agir en fonction des réglages de préférence sélectionnés par l'utilisateur. Pour cela, ils doivent être capables de traiter une politique, ou un fichier d'appel de politique, de manière à pouvoir évaluer chaque politique en fonction des préférences de l'utilisateur ou d'autres critères de réglage. Selon ces paramètres, l'agent utilisateur pourra, par exemple, vérifier la présence des parties obligatoires dans la politique P3P ou bien la validité de la syntaxe de la politique en entier.
Les politiques compactes sont des politiques P3P résumées fournissant aux agents utilisateurs des indications leur permettant de prendre des décisions rapides et synchrones pour l'application de la politique. Les politiques compactes représentent une optimisation des performances OPTIONNELLE pour les agents utilisateurs ainsi que pour les serveurs. Les agents utilisateurs qui n'obtiennent pas suffisamment d'informations dans une politique compacte pour prendre une décision en fonction des préférences de l'utilisateur DEVRAIENT récupérer la politique complète.
Dans P3P, les politiques compactes contiennent des informations de politique relatives à des cookies (cf. [COOKIES] et [STATE]). Le serveur Web est responsable de la construction d'une politique P3P compacte pour représenter les cookies référencés dans une politique complète. La politique spécifiée dans une politique P3P compacte s'applique aux données stockées dans tous les cookies placés au cours de la même réponse HTTP que la politique compacte, à tous les cookies placés par des scripts associés à cette réponse HTTP et aussi aux données reliées aux cookies.
Toute ressource HTTP PEUT inclure une politique P3P compacte au moyen de l'en-tête de réponse P3P (cf. section 2.2.2). Lorsqu'un site se sert d'en-têtes P3P, il DEVRAIT les inclure aux réponses de toutes les méthodes de requête appropriées, y compris les requêtes HEAD et OPTION.
L'en-tête de politique compacte P3P comporte une chaîne entre guillemets susceptible de contenir
un ou plusieurs atomes séparés (d'où politique compacte
). Les atomes peuvent apparaître
dans n'importe quel ordre et le caractère espace est le seul délimiteur valide. La syntaxe de cette en-tête est la suivante :
[50] compact-policy-field = `CP="` compact-policy `"` [51] compact-policy = compact-token *(" " compact-token) [52] compact-token = compact-access | compact-disputes | compact-remedies | compact-non-identifiable | compact-purpose | compact-recipient | compact-retention | compact-categories | compact-test
Comme pour toutes les en-têtes HTTP, le nom du champs d'en-tête P3P est insensible à la casse. Par contre, la valeur du champs (c'est-à-dire, le contenu de l'en-tête) est sensible à la casse.
Si une réponse HTTP inclut plusieurs politiques compacte, les agents utilisateurs DOIVENT ignorer toutes celles après la première.
Les politiques compactes P3P recourent à des atomes qui représentent les éléments suivants du vocabulaire P3P :
<ACCESS>
, <CATEGORIES>
, <DISPUTES>
, <NON-INDENTIFIABLE>
,
<PURPOSE>
, <RECIPIENT>
, <REMEDIES>
, <RETENTION>
et <TEST>
.
Si un atome apparaît plusieurs fois dans une seule politique compacte, sa sémantique est la même que si l'atome n'était apparu qu'une seule fois. Si un atome inconnu apparaîtt dans une politique compacte, sa sémantique est la même qui si cet atome était absent.
Le vocabulaire des politiques compactes P3P s'exprime à l'aide d'un code lisible par un développeur afin de réduire le nombre d'octets transférés via un réseau dans l'en-tête de réponse HTTP. La syntaxe des atomes est la suivante :
ACCESS
compactLes politiques compactes représentent les informations contenues dans l'élément <ACCESS>
par des atomes
formés d'un code en trois lettres :
[53] compact-access = "NOI" | ; pour <nonident/> "ALL" | ; pour <all/> "CAO" | ; pour <contact-and-other/> "IDC" | ; pour <ident-contact/> "OTI" | ; pour <other-ident/> "NON" ; pour <none/>
DISPUTES
compactSi une politique P3P complète a un sous-élément <DISPUTES-GROUP>
contenant un ou
plusieurs éléments <DISPUTES>
, alors le serveur devrait avertir l'agent utilisateur en lui
fournissant un seul atome "DSP
" dans le champ de politique compacte P3P :
[54] compact-disputes = "DSP" ; il y a un ou plusieurs éléments DISPUTES
REMEDIES
compactLes informations contenues dans l'élément <REMEDIES>
ont la représentation compacte suivante :
[55] compact-remedies = "COR" | ; pour <correct/> "MON" | ; pour <money/> "LAW" ; pour <law/>
NON-IDENTIFIABLE
compactLa présence de l'élément <NON-IDENTIFIABLE>
dans toutes les déclarations de la politique est signalée
par un atome "NID
" (remarquez qu'on NE DOIT PAS utiliser l'atome "NID
" tant que
l'élément <NON-IDENTIFIABLE>
n'est pas présent dans chaque déclaration dans la politique) :
[56] compact-non-identifiable = "NID" ; pour <NON-IDENTIFIABLE/>
PURPOSE
compactDans une politique P3P compacte, les intentions sont représentées par des atomes composés d'un code en trois lettres
plus un attribut optionnel représenté par une lettre. Ces attributs optionnels codent la valeur de l'attribut required
trouvé dans une politique P3P complète : sa valeur peut être "a
", "i
" ou "o
", ce qui
équivaut respectivement aux valeurs "always
", "opt-in
" ou "opt-out
" de l'attribut required
dans la politique P3P correspondante.
Si une politique P3P compacte doit représenter une ou plusieurs intentions <other-purpose>
de la politique P3P complète, on n'utilisera qu'un seul drapeau "OTP
" pour signaler à l'agent utilisateur
l'existence d'une ou de plusieurs intentions <other-purpose>
dans la politique P3P complète.
Les correspondances entre les intentions de la politiques P3P complète et les codes de la politique compacte sont les suivantes :
[57] compact-purpose = "CUR" | ; pour <current/> "ADM" [creq] | ; pour <admin/> "DEV" [creq] | ; pour <develop/> "TAI" [creq] | ; pour <tailoring/> "PSA" [creq] | ; pour <pseudo-analysis/> "PSD" [creq] | ; pour <pseudo-decision/> "IVA" [creq] | ; pour <individual-analysis/> "IVD" [creq] | ; pour <individual-decision/> "CON" [creq] | ; pour <contact/> "HIS" [creq] | ; pour <historical/> "TEL" [creq] | ; pour <telemarketing/> "OTP" [creq] ; pour <other-purpose/> [58] creq = "a" | ; pour "always" "i" | ; pour "opt-in" "o" ; pour "opt-out"
RECIPIENT
compactDans une politique P3P compacte, les destinataires sont représentés par des atomes composés d'un code en trois lettres
plus un attribut optionnel représenté par une lettre. Ces attributs optionnels codent la valeur de l'attribut required
trouvé
dans une politique P3P complète : sa valeur peut être "a
", "i
" ou "o
", ce qui
équivaut respectivement aux valeurs "always
", "opt-in
" ou "opt-out
" de l'attribut required
dans la politique P3P correspondante.
Les correspondances entre les destinataires de la politique P3P complète et les codes de la politique compacte sont les suivantes :
[59] compact-recipient = "OUR" | ; pour <ours/> "DEL" [creq] | ; pour <delivery/> "SAM" [creq] | ; pour <same/> "UNR" [creq] | ; pour <unrelated/> "PUB" [creq] | ; pour <public/> "OTR" [creq] ; pour <other-recipient/>
RETENTION
compactLes informations contenues dans un élément <RETENTION>
ont la représentation compacte suivante :
[60] compact-retention = "NOR" | ; pour <no-retention/> "STP" | ; pour <stated-purpose/> "LEG" | ; pour <legal-requirement/> "BUS" | ; pour <business-practices/> "IND" ; pour <indefinitely/>
CATEGORIES
compactLes catégories sont représentées dans les politiques compactes comme suit :
[61] compact-categories = "PHY" | ; pour <physical/> "ONL" | ; pour <online/> "UNI" | ; pour <uniqueid/> "PUR" | ; pour <purchase/> "FIN" | ; pour <financial/> "COM" | ; pour <computer/> "NAV" | ; pour <navigation/> "INT" | ; pour <interactive/> "DEM" | ; pour <demographic/> "CNT" | ; pour <content/> "STA" | ; pour <state/> "POL" | ; pour <political/> "HEA" | ; pour <health/> "PRE" | ; pour <preference/> "LOC" | ; pour <location/> "GOV" | ; pour <government/> "OTC" ; pour <other-category/>
Remarquez que, si une politique P3P complète indique une ou plusieurs catégories <other-category/>
,
on n'utilisera qu'un seul atome "OTC
" dans la politique compacte pour signaler à l'agent utilisateur
l'existence d'une ou de plusieurs catégories <other-category/>
dans la politique P3P complète.
TEST
compactLa présence de l'élément <TEST>
est signalée par l'atome "TST
" :
[62] compact-test = "TST" ; pour <TEST/>
Lorsqu'une politique P3P compacte est incluse dans une en-tête de réponse HTTP, elle s'applique aux cookies installés par la réponse courante. C'est-à-dire, les cookies placés au moyen d'une en-tête HTTP Set-Cookie ou ceux placés par un script.
Pour utiliser des politiques compactes, il faut que la validité de la politique P3P compacte couvre la durée de vie du cookie. Aucune méthode ne permet d'indiquer que la validité de la politique dépasse la durée de vie du cookie parce que les valeurs mises en cache par l'agent utilisateur sont marginales, dans la mesure où les sites ne sauraient pas s'ils doivent optimiser en n'envoyant pas de politique compacte. Lorsqu'un serveur envoie une politique compacte, il fait valoir que la politique compacte et la politique P3P complète correspondante seront en vigueur pour au moins la durée de vie du cookie sur lequel la politique compacte s'applique.
Lorsqu'un site Web utilise des politiques P3P compactes, il est tenu de construire une politique compacte en résumant
les politiques appelées par les éléments <COOKIE-INCLUDE>
d'un fichier d'appel de politique P3P.
Si le fichier d'appel de politique d'un site utilise des éléments <COOKIE-EXCLUDE>
, alors le site devra gérer
l'envoi des politiques P3P compactes à l'agent utilisateur, en fonction des cookies installés au cours d'une réponse
particulière.
La transformation d'une politique P3P en une politique P3P compacte peut se traduire par une
perte descriptive des informations de politique, la politique compacte risquant de ne pas contenir toutes les informations de politique
trouvées dans la politique P3P complète. Ces informations de la politique complète qui auront disparu pour la
construction de la politique compacte comprennent l'élément <EXPIRY>
, les
éléments <DATA-GROUP>
/<DATA>
, <ENTITY>
et <CONSEQUENCE>
, et
les éléments <DISPUTES>
seront réduits.
Les politiques complètes incluant des extensions obligatoires NE DOIVENT PAS être représentées par des politiques compactes.
On DOIT assembler toutes les intentions, tous les destinataires et toutes les catégories qui apparaissent dans les diverses déclarations d'une politique complète pour une politique compacte, comme décrit dans la section 3.3.1. Au cours de l'assemblage, le site Web DOIT divulguer tous les atomes concernés (cf. l'exemple 4.1 dans lequel plusieurs politiques de rétention sont spécifiées).
En outre, pour chaque élément de données de catégorie fixe apparaissant dans une déclaration, la catégorie associée telle que définie dans le schéma correspondant DOIT être incluse dans la politique compacte.
Exemple 4.1 :
Supposons la politique P3P suivante :
<POLICY name="echantillon" discuri="http://www.example.com/politique_cookie.html" opturi="http://www.example.com/opt.html"> <ENTITY> <DATA-GROUP> <DATA ref="#business.name">Exemple, Corp.</DATA> <DATA ref="#business.contact-info.online.email">vieprivee@example.com</DATA> </DATA-GROUP> </ENTITY> <ACCESS><none/></ACCESS> <DISPUTES-GROUP> <DISPUTES resolution-type="service" service="http://www.example.com/confidentialite.html" short-description="Pour les questions de confidentialité, merci de contacter notre service clientèle en envoyant un courrier électronique à vieprivee@example.com"/> </DISPUTES-GROUP> <STATEMENT> <PURPOSE><admin/><develop/><pseudo-decision/></PURPOSE> <RECIPIENT><ours/></RECIPIENT> <RETENTION><indefinitely/></RETENTION> <DATA-GROUP> <DATA ref="#dynamic.cookies"> <CATEGORIES><preference/><navigation/></CATEGORIES> </DATA> </DATA-GROUP> </STATEMENT> <STATEMENT> <PURPOSE><individual-decision required="opt-out"/></PURPOSE> <RECIPIENT><ours/></RECIPIENT> <RETENTION><stated-purpose/></RETENTION> <DATA-GROUP> <DATA ref="#user.name.given"/> <DATA ref="#dynamic.cookies"> <CATEGORIES><preference/><uniqueid/></CATEGORIES> </DATA> </DATA-GROUP> </STATEMENT> </POLICY>
La politique compacte correspondante sera la suivante :
"NON DSP ADM DEV PSD IVDo OUR IND STP PHY PRE NAV UNI"
Certains agents utilisateurs pourront essayer de générer une politique P3P complète à partir d'une politique compacte
dans le but d'évaluer les préférences de l'utilisateur. Ils ne pourront pas fournir de valeurs pour les
éléments <ENTITY>
et <DISPUTES>
tout comme pour un certain nombre d'attributs. Néanmoins :
<ACCESS>
adéquat
et un seul élément <STATEMENT>
contenant les éléments <RECIPIENT>
,
<RETENTION>
et <PURPOSE>
adéquats, ainsi qu'un élément
dynamic.miscdata
avec l'élément <CATEGORIES>
adéquat.<ACCESS>
adéquat et
plusieurs éléments <STATEMENT>
(autant qu'il y a de valeurs différentes de rétention
compactes) contenant une valeur correspondante différente pour l'élément <RETENTION>
,
l'élément <RECIPIENT>
adéquat et des éléments <PURPOSE>
, ainsi qu'un
élément dynamic.miscdata
avec l'élément
<CATEGORIES>
adéquat.Remarquez que, conformément aux conditions de non-ambiguïté déclarées dans la section 2.4.1, un site DOIT honorer, dans tous les cas, une politique compacte pour une adresse URI donnée (même si la politique complète référencée dans le fichier d'appel de politique pour cette adresse URI ne correspond pas, selon la section 4.5, à la politique compacte elle-même).
Un schéma de données représente une description d'un jeu de données. Le protocole P3P permet de décrire des schémas de données afin que les services puissent communiquer avec les agents utilisateurs au sujet des données qu'ils collectent. Un schéma de données se construit à partir d'un certain nombre d'éléments de données, qui sont des items de données spécifiques susceptibles d'être collectés par les services.
Les éléments de données d'un schéma de données peuvent avoir les propriétés suivantes :
<DATA>
. Il est obligatoire pour tous les éléments de données ;Les éléments de données sont organisés selon une hiérarchie. Un élément de données inclut automatiquement tous ceux situés plus bas
dans la hiérarchie. Par exemple, l'élément de données représentant le nom de l'utilisateur
inclut ceux représentant
le prénom de l'utilisateur
, le nom de famille de l'utilisateur
, et ainsi de suite. La hiérarchie est fondée sur le
nom de l'élément de données. Ainsi les éléments de données user.name.given
, user.name.family
et user.name.nickname
sont tous des sous-éléments de l'élément de données user.name
lequel est, à son tour,
un sous-élément de l'élément de données user
.
Le protocole P3P définit un schéma de données, appelé schéma de données P3P de base, qui comprend un grand nombre d'éléments de données d'utilisation courante pour les services.
Les services peuvent déclarer des nouveaux éléments de données en créant leurs propres schémas de données à l'aide d'un
élément <DATASCHEMA>
. Les schémas de données peuvent se présenter sous deux formes : publiés dans des
fichiers XML autonomes (dont l'élément racine est alors <DATASCHEMA>
) ou incorporés dans
un fichier de politique (le cas échéant, dans le même fichier dont les politiques appellent alors le schéma de données en question).
L'élément <DATASCHEMA>
est défini comme suit :
[63] dataschema = "<DATASCHEMA" [` xmlns="http://www.w3.org/2002/01/P3Pv1"`] [xml-lang] ">" *(datadef|datastruct|extension) "</DATASCHEMA>"
L'élément racine du fichier XML constituant un schéma de données autonome est élément <DATASCHEMA>
.
L'attribut xmlns
définit l'espace de nommage approprié qui permet de l'identifier comme schéma de données P3P :
<DATASCHEMA xmlns="http://www.w3.org/2002/01/P3Pv1"> <DATA-STRUCT ... /> ... <DATA-DEF ... /> </DATASCHEMA>
En option, l'élément <DATASCHEMA>
peut contenir un attribut xml:lang
(cf. la
section 2.4.2).
Lorsqu'on déclare un schéma de données dans un fichier de politique, alors l'élément <DATASCHEMA>
reste toujours
utilisé (comme décrit dans la section 3.2.1 L'élément <POLICIES>
).
Les schémas de données contiennent un certain nombre de champs en langage naturel. Le service qui publie un schéma de données PEUT vouloir traduire ces champs dans diverses langues. Les noms longs et abrégés des éléments de données PEUVENT être traduits mais on NE DOIT PAS traduire le nom de l'élément de données (ce champ doit rester constant d'une traduction du schéma de données à l'autre).
Si un service veut fournir un schéma de données en plusieurs langues, alors il DEVRAIT examiner l'en-tête de requête HTTP Accept-Language, lors des requêtes vers ce schéma de données, afin de retenir la meilleure option disponible.
Les schémas de données réutiliseront souvent un groupe d'éléments de données commun. Une structure de données est une définition abstraite nommée d'un groupe d'éléments de données. Lors de la définition d'un élément de données, on peut le définir comme étant d'un type non structuré, auquel cas il n'a aucun sous-élément. On peut aussi définir l'élément de données comme étant d'un type structuré spécifique, auquel cas il sera automatiquement développé pour inclure, comme sous-éléments, tous les éléments définis dans la structure de données. Par exemple, on utilise la structure suivante pour représenter une date et une heure :
<!-- Structure de données "date" --> <DATA-STRUCT name="date.ymd.year" short-description="Année"/> <DATA-STRUCT name="date.ymd.month" short-description="Mois"/> <DATA-STRUCT name="date.ymd.day" short-description="Jour"/> <DATA-STRUCT name="date.hms.hour" short-description="Heure"/> <DATA-STRUCT name="date.hms.minute" short-description="Minute"/> <DATA-STRUCT name="date.hms.second" short-description="Seconde"/>
Maintenant, nous allons définir un élément de données "rendezvous", avec une heure et un lieu de rendez-vous :
<DATA-DEF name="rendezvous.heure" short-description="Heure du rendez-vous" structref="#date"/> <DATA-DEF name="rendezvous.lieu" short-description="Lieu du rendez-vous"/>
Comme rendezvous.lieu
n'appelle aucune structure, il s'agit donc d'un type non structuré qui n'a aucun sous-élément.
L'élément rendezvous.heure
utilise la structure date
.
Par cette déclaration, on crée les sous-éléments suivants :
rendezvous.heure.ymd.year rendezvous.heure.ymd.month rendezvous.heure.ymd.day rendezvous.heure.hms.hour rendezvous.heure.hms.minute rendezvous.heure.hms.second
La politique P3P peut maintenant déclarer qu'elle collecte l'élément de données rendezvous
,
ce qui implique la collecte de tous les sous-éléments de rendezvous
, ou elle peut aussi utiliser les éléments de données situés
plus bas dans la hiérarchie (par exemple, rendezvous.heure
ou rendezvous.heure.ymd.day
).
DATA-DEF
et DATA-STRUCT
<DATA-DEF>
et <DATA-STRUCT>
<STATEMENT>
d'une politique P3P afin de décrire
les données couvertes par cette déclaration.Les attributs suivants sont communs aux deux éléments :
name
(attribut obligatoire)user.gender
diffère de
USER.GENDER
ou de User.Gender
. De plus, aucun caractère numérique ne peut apparaître immédiatement après un point
dans les noms des éléments et des structures de données.structref
structref
(et, de ce fait, sans structure associée), sont dits
non structurés.short-description
Les éléments <DATA-DEF>
et <DATA-STRUCT>
peuvent aussi contenir une description longue
de l'élément ou de la structure de données, en utilisant l'élément <LONG-DESCRIPTION>
.
[64] datadef = "<DATA-DEF name=" quotedstring [` structref="` URI-reference `"`] [" short-description=" quotedstring] ">" [categories] ; les catégories de l'élément de données. [longdescription] ; la description longue de l'élément de données. "</DATA-DEF>" [65] datastruct = "<DATA-STRUCT name=" quotedstring [` structref="` URI-reference `"`] [" short-description=" quotedstring] ">" [categories] ; les catégories de la strucutre de données. [longdescription] ; La description longue de la structure de données. "</DATA-STRUCT>"
Ici, la valeur URI-reference
est définie comme dans [URI].
Les éléments de données peuvent être structurés tout comme dans les langages de programmation courants.
Les structures sont des descriptions hiérarchiques (arborescentes) d'éléments de données ; cette description hiérarchique, reflétée
dans l'attribut name
, se sert du caractère point .
comme séparateur.
Le protocole P3P fournit un schéma de données P3P de base qui comporte les définitions d'un certain nombre de structures et d'éléments de données largement répandus. Toutes les mises en œuvre P3P sont tenues de reconnaître le schéma de données P3P de base, de sorte que les structures et les éléments qui y sont définis restent toujours disponibles pour les développeurs P3P.
Un schéma de données peut inclure plusieurs éléments <DATA-STRUCT>
décrivant ensemble une structure.
Par exemple, il n'y a pas d'élément <DATA-STRUCT>
tout seul pour la structure de données uri
(cf. section 5.5.7.1) dans le schéma de données P3P de base. Néanmoins, l'interprétation
simultanée des éléments uri.authority
, uri.stem
et uri.querystring
permet de définir cette structure.
On peut assigner des catégories aux structures de données et aux éléments de données. Les règles suivantes définissent comment ces définitions de catégorie doivent être utilisées :
<DATA-STRUCT>
PEUVENT inclure des définitions de catégorie. Si une définition de structure
comprend des catégories, alors toutes les utilisations de ces structures dans les définitions des données et des structures de données
reprennent ces catégories. Si une structure ne contient aucune catégorie, alors on PEUT définir des catégories pour cette structure
lorsque celle-ci est utilisées dans une autre structure ou un autre élément de données. Sinon, un élément de données utilisant
cette structure est un élément de catégorie variable. Toute utilisation d'un élément de données de catégorie variable dans
une politique exige que ses catégories soient listées dans cette politique ;<DATA-DEF>
de type non structuré est un élément de catégorie variable si aucune catégorie n'y est définie
ou, si des catégories y sont incluses, il liste alors exactement ces catégories ;<DATA-DEF>
(ou <DATA-STRUCT>
), de type structuré mais sans catégorie définie sur
cette structure, produit un élément de données (ou une structure de données) de catégorie variable si aucune catégorie n'est définie
dans l'élément <DATA-DEF>
(ou dans l'élément <DATA-STRUCT>
). Si
l'élément <DATA-DEF>
(ou <DATA-STRUCT>
) liste des catégories, alors celles-ci s'appliquent
à cet élément de données (ou à cette structure de données) et tous ses sous-éléments. En d'autres termes,
les catégories sont héritées par les sous-éléments lorsqu'on définit un élément de données comme étant d'un type structuré et que
ce type structuré ne définit aucune catégorie ;<DATA-DEF>
qui utilise un type structuré sur lequel des catégories sont définies reprend
toutes les catégories listées sur la structure. En outre, l'élément <DATA-DEF>
peut lister d'autres catégories
qui s'ajoutent alors à celles définies dans la structure. Ces catégories ne sont définies qu'au niveau de cet élément de données
et ne se répercutent pas aux sous-éléments ;<DATA-STRUCT>
sur lequel aucune catégorie n'est assignée, utilisant un sous-type structuré où
des catégories sont définies, retient toutes les catégories listées sur ce sous-type ;<DATA-STRUCT>
sur lequel des catégories sont assignées, utilisant un sous-type structuré,
remplace toutes les catégories qui y seraient listées ;remontéedes catégories lors de l'appel des éléments de données selon laquelle les éléments de données doivent au moins inclure toutes les catégories définies par leurs sous-éléments. Cette règle s'applique récursivement, de sorte que, par exemple, toutes les catégories définies par les éléments
foo.a.w
, foo.a.y
et foo.b.z
DEVRONT s'appliquer aux éléments de données foo
;<DATA-STRUCT>
avec certains sous-éléments étant de catégorie variable et
d'autres étant de catégorie fixe. Tous les sous-éléments d'une structure doivent soit être de catégorie variable, soit avoir
une ou plusieurs catégories assignées ;<DATA-DEF>
dont certains sous-éléments sont de catégorie variable et
d'autres sont de catégorie fixe. On ne peut donc pas appeler la structure dynamic
(cf. section 5.6.4 Les données dynamiques), appartenant au schéma de données de base,
dans une politique (par contre, chacun de ses sous-éléments dynamic.clickstream
, dynamic.http
, etc. pourra
l'être individuellement).Étudions le cas d'une société GrandeVitesseExemple qui souhaite décrire les caractéristiques d'un véhicule en se servant
d'une structure appelée vehicule
. Cette structure comprend :
vehicule.modele
),vehicule.couleur
),vehicule.construction.annee
) etvehicule.prix
).Si la société GrandeVitesseExemple veut aussi inclure le lieu de construction dans la définition d'un véhicule, elle pourra
ajouter d'autres champs à la structure avec toutes les données nécessaires comme le pays, l'adresse, le code postal, et ainsi de suite.
Mais chaque partie de structure peut aussi recourir à d'autres structures : on peut composer les structures. Dans le cas présent,
le schéma de données P3P de base fournit déjà la structure
postal
pour décrire toutes les informations postales concernant un lieu. La définition finale de la structure vehicule
est donc :
vehicule.modele
(non structuré)vehicule.couleur
(non structuré)vehicule.prix
(non structuré)vehicule.construction.annee
(non structuré)vehicule.construction.lieu
(avec la structure postal
du schéma de données de base).La structure postal
comprend les champs postal.street
, postal.city
, etc. Puisque nous avons
appliqué la structure postal
à l'élément de données vehicule.construction.lieu
, nous pouvons donc accéder
à la rue et à la ville de construction d'un véhicule en utilisant respectivement les descriptions
vehicule.construction.lieu.street
et vehicule.construction.lieu.city
. Par l'application d'une structure
(la structure postal
dans le cas présent), on peut ainsi construire des descriptions très complexes de façon modulaire.
La société GrandeVitesseExemple veut que toutes les informations concernant le véhicule soient de la catégorie <preference/>
.
Les champs vehicule.modele
, vehicule.couleur
, vehicule.prix
et
vehicule.construction.annee
étant tous de type non structuré, on peut donc le faire en assignant à chacun
la catégorie <preference/>
. Puisque vehicule
est une définition de structure, en assignant
la catégorie <preference/>
à vehicule.construction.lieu
, on va remplacer les catégories définies
sur les sous-éléments de vehicule.construction.lieu
par la catégorie <preference/>
, même si la
structure postal
était définie à l'origine comme étant dans d'autres catégories.
Comme dit précédemment, les structures ne contiennent pas d'élément de données : ce sont juste des types de données abstraits.
On peut les utiliser pour construire rapidement des collections d'éléments de données structurées. En poursuivant avec cet exemple,
la société GrandeVitesseExemple a besoin d'une description abstraite des caractéristiques d'un véhicule parce qu'elle veut en réalité
échanger des données pour des voitures et des motos. Elle pourra donc définir deux éléments de données, appelés auto
et moto
, les deux s'appuyant sur la structure vehicule
précédente.
Cette description des éléments de données et des structures de données se traduit en XML en recourant à un schéma de données. Dans le cas de la société GrandeVitesseExemple, ce schéma de données pourra avoir la forme suivante :
<DATASCHEMA xmlns="http://www.w3.org/2002/01/P3Pv1"> <DATA-STRUCT name="vehicule.modele" short-description="Modèle"> <CATEGORIES><preference/></CATEGORIES> </DATA-STRUCT> <DATA-STRUCT name="vehicule.couleur" short-description="Couleur"> <CATEGORIES><preference/></CATEGORIES> </DATA-STRUCT> <DATA-STRUCT name="vehicule.construction.annee" short-description="Année de construction"> <CATEGORIES><preference/></CATEGORIES> </DATA-STRUCT> <DATA-STRUCT name="vehicule.construction.lieu" structref="http://www.w3.org/TR/P3P/base#postal" short-description="Lieu de construction"> <CATEGORIES><preference/></CATEGORIES> </DATA-STRUCT> <DATA-DEF name="auto" structref="#vehicule"/> <DATA-DEF name="moto" structref="#vehicule"/> </DATASCHEMA>
En poursuivant avec l'exemple, la société GrandeVitesseExemple ou n'importe quel autre service pourra référencer un modèle d'auto et l'année de sa construction en envoyant dans une politique P3P les appels suivants :
<DATA-GROUP> <!-- Premièrement, l'élément de données "auto.modele", dont la définition se trouve dans le schéma de données à http://www.GrandeVitesse.example.com/modeles-schema --> <DATA ref="http://www.GrandeVitesse.example.com/modeles-schema#auto.modele"/> <!-- Deuxièmement, l'élément de données "auto.construction.annee", dont la définition se trouve dans le schéma de données à http://www.GrandeVitess.example.com/modeles-schema --> <DATA ref="http://www.GrandeVitesse.example.com/modeles-schema#auto.construction.annee"/> </DATA-GROUP>
En utilisant l'attribut base
, on peut
écrire les appels précédents d'une manière encore plus compacte :
<DATA-GROUP base="http://www.GrandeVitesse.example.com/modeles-schema"> <DATA ref="#auto.modele"/> <DATA ref="#auto.construction.annee"/> </DATA-GROUP>
Sinon on peut incorporer le schéma de données directement dans un fichier de politique, qui pourra être le suivant :
<POLICIES xmlns="http://www.w3.org/2002/01/P3Pv1"> <!-- Schéma de données incorporé --> <DATASCHEMA> <DATA-STRUCT name="vehicule.modele" short-description="Modèle"> <CATEGORIES><preference/></CATEGORIES> </DATA-STRUCT> <DATA-STRUCT name="vehicule.couleur" short-description="Couleur"> <CATEGORIES><preference/></CATEGORIES> </DATA-STRUCT> <DATA-STRUCT name="vehicule.construction.annee" short-description="Année de construction""> <CATEGORIES><preference/></CATEGORIES> </DATA-STRUCT> <DATA-STRUCT name="vehicule.construction.lieu" structref="http://www.w3.org/TR/P3P/base#postal" short-description="Lieu de construction"> <CATEGORIES><preference/></CATEGORIES> </DATA-STRUCT> <DATA-DEF name="auto" structref="#vehicule"/> <DATA-DEF name="moto" structref="#vehicule"/> </DATASCHEMA> <!-- Fin du schéma de données incorporé --> <POLICY name="politique1" discuri="http://www.example.com/disc1"> ... <DATA-GROUP base=""> <DATA ref="#auto.modele"/> <DATA ref="#auto.construction.annee"/> </DATA-GROUP> ... </POLICY> <POLICY name="politique2" discuri="http://www.example.com/disc2"> .... </POLICY> <POLICY name="politique3" discuri="http://www.example.com/disc3"> .... </POLICY> </POLICIES>
Dans tous les cas, il NE DOIT PAS y avoir plus d'un schéma de données par fichier.
Remarquez que les noms des éléments de données, indiqués dans le schéma de données de base ou dans les schémas de données des extensions, peuvent être utilisés ailleurs que dans les politiques P3P. Par exemple, les sites Web peuvent s'en servir pour nommer les champs des formulaires HTML. En référençant de la même façon les données des politiques P3P et des formulaires, on pourra intégrer plus facilement des routines pour remplir automatiquement les formulaires aux agents utilisateurs P3P.
Une condition essentielle pour les schémas de données est la persistance : les schémas de données récupérables à une certaine adresse URI ne peuvent être changés qu'en les étendant de manière rétrocompatible (c'est-à-dire que le changement du schéma de données ne modifie pas le sens d'une politique qui l'utilise). Ainsi, l'adresse URI d'une politique agit d'une certaine façon comme un identificateur unique pour les éléments de données et les structures de données qui y sont contenus : tout schéma de données non rétrocompatible doit donc utiliser une adresse URI différente.
Remarquez que de la persistance du schéma de données peut se révéler utile, par exemple, dans le cas d'un site multilingue : le serveur peut offrir plusieurs versions (traductions) du même schéma de données en se servant du champs d'en-tête HTTP Content-Language afin d'indiquer exactement la langue particulière utilisée pour le schéma de données.
Les structures de données de base sont celles utilisées par le schéma de données P3P de base (et, en raison de leur nature élémentaire, les autres schémas de données devraient autant que possible les réutiliser). Toutes les mises en œuvre d'agent utilisateur conformes à P3P DOIVENT reconnaître les structures de données de base. Chacun des tableaux suivants définit les éléments d'une structure de données de base, les catégories associées, leurs structures et les noms abrégés affichés aux utilisateurs. On peut associer plusieurs catégorie à un élément de données fixe. Toutefois, une catégorie seulement est associée à chaque élément de données de base tant que c'est possible. On recommande aux concepteurs de schémas de données de faire la même chose.
La structure date
définit une date. Dans la mesure où les informations de date peuvent s'employer de plusieurs façons,
en fonction du contexte, toutes les informations de type date
sont étiquetées comme étant de catégorie variable
(cf. la section 5.7.2). Les définitions de schéma peuvent fixer explicitement la catégorie correspondante
dans l'élément qui appelle cette structure, ainsi, par exemple, la demande de la date d'anniversaire d'un utilisateur pourra concerner
la catégorie Données démographiques et socio-économiques
tandis que la date d'expiration d'une carte de crédit relèvera
de la catégorie Informations d'achat
.
date |
Catégorie | Structure | Nom abrégé |
ymd.year | (catégorie variable) | non structuré | Année |
ymd.month | (catégorie variable) | non structuré | Mois |
ymd.day | (catégorie variable) | non structuré | Jour |
hms.hour | (catégorie variable) | non structuré | Heure |
hms.minute | (catégorie variable) | non structuré | Minute |
hms.second | (catégorie variable) | non structuré | Seconde |
fractionsecond | (catégorie variable) | non structuré | Fraction de seconde |
timezone | (catégorie variable) | non structuré | Fuseau horaire |
Par exemple, l'information du fuseau horaire
est décrite dans le temps normalisé [ISO8601].
Remarquez qu'on peut utiliser respectivement date.ymd
et date.hms
pour appeler rapidement
les blocs année/mois/jour et heure/minute/seconde.
La structure personname
définit les informations nominales d'une personne.
personname |
Catégorie | Structure | Nom abrégé |
prefix | Données démographiques et socio-économiques | non structuré | Titre |
given | Coordonnées physiques | non structuré | Prénom |
family | Coordonnées physiques | non structuré | Nom de famille |
middle | Coordonnées physiques | non structuré | Deuxième prénom |
suffix | Données démographiques et socio-économiques | non structuré | Suffixe de nom |
nickname | Données démographiques et socio-économiques | non structuré | Surnom |
La structure login
définit les informations (identificateur et mot de passe) nécessaires aux systèmes informatiques et
aux sites Web pour une authentification. Remarquez qu'on ne devrait pas se servir de cet élément de données pour les systèmes
ou les sites Web utilisant des certificats d'authentification numériques : pour ces cas, on se servira de la structure certificate
.
login |
Catégorie | Structure | Nom abrégé |
id | Identificateurs uniques | non structuré | Identifiant de connexion |
password | Identificateurs uniques | non structuré | Mot de passe de connexion |
Le champ id
représente la partie ID de l'information de connexion
pour un système informatique. Les ID des utilisateurs sont souvent rendus publics, tandis que les mots de passe
sont tenus secrets. Les ID n'incluent aucun type de mécanisme d'authentification biométrique.
Le champ password
représente la partie mot de passe de l'information de connexion pour un système informatique.
C'est une donnée secrète, généralement une chaîne de caractères, utilisée pour l'authentification d'un utilisateur.
Les mots de passe sont typiquement tenus secrets et constituent généralement une information sensible.
La structure certificate
sert à définir des certificats d'identité (par exemple, les certificats X.509).
certificate |
Catégorie | Structure | Nom abrégé |
key | Identificateurs uniques | non structuré | Clé de certificat |
format | Identificateurs uniques | non structuré | Format de certificat |
Le champ format
sert à représenter les informations de format d'une clé publique ou d'un certificat
d'authentification enregistrés auprès de l'IANA,
alors que le champ key
sert à représenter la clé de certificat correspondante.
La structure telephonenum
définit les caractéristiques d'un numéro de téléphone.
telephonenum |
Catégorie | Structure | Nom abrégé |
intcode | Coordonnées physiques | non structuré | Indicatif téléphonique international |
loccode | Coordonnées physiques | non structuré | Indicatif téléphonique régional |
number | Coordonnées physiques | non structuré | Numéro de téléphone |
ext | Coordonnées physiques | non structuré | Poste téléphonique supplémentaire |
comment | Coordonnées physiques | non structuré | Commentaires téléphoniques optionnels |
La structure contact
sert à définir des coordonnées. Les services peuvent définir précisément le jeu de données dont
ils ont besoin, à savoir les coordonnées postales, de télécommunication ou en ligne.
contact |
Catégorie | Structure | Nom abrégé |
postal | Coordonnées physiques, Données démographiques et socio-économiques | postal | Adresse postale |
telecom | Coordonnées physiques | telecom | Télécommunications |
online | Coordonnées en ligne | online | Adresse en ligne |
La structure postal
définit une adresse de courrier postal.
postal |
Catégorie | Structure | Nom abrégé |
name | Coordonnées physiques, Données démographiques et socio-économiques | personname | Nom |
street | Coordonnées physiques | non structuré | Rue |
city | Données démographiques et socio-économiques | non structuré | Ville |
stateprov | Données démographiques et socio-économiques | non structuré | État ou province |
postalcode | Données démographiques et socio-économiques | non structuré | Code postal |
country | Données démographiques et socio-économiques | non structuré | Pays |
organization | Données démographiques et socio-économiques | non structuré | Organisation |
Le champ country
représente le nom d'un pays (par exemple, un de ceux listés dans [ISO3166]).
La structure telecom
définit les coordonnées de télécommunication concernant une personne.
telecom |
Catégorie | Structure | Nom abrégé |
telephone | Coordonnées physiques | telephonenum | Numéro de téléphone |
fax | Coordonnées physiques | telephonenum | Numéro de télécopie |
mobile | Coordonnées physiques | telephonenum | Numéro de mobile |
pager | Coordonnées physiques | telephonenum | Numéro de téléavertisseur |
La structure online
définit les coordonnées en ligne concernant une personne physique ou morale.
online |
Catégorie | Structure | Nom abrégé |
Coordonnées en ligne | non structuré | Adresse électronique | |
uri | Coordonnées en ligne | non structuré | Adresse de page d'accueil |
Deux structures servant à représenter les formes d'adresses Internet sont fournies : la structure
uri
qui couvre les identificateurs de ressource universels (URI,
définis dans [URI] et la structure ipaddr
qui représente les adresses IP et les noms d'hôte
du système de nom de domaine (DNS).
uri |
Catégorie | Structure | Nom abrégé |
authority | (catégorie variable) | non structuré | Autorité de l'adresse URI |
stem | (catégorie variable) | non structuré | Radical de l'adresse URI |
querystring | (catégorie variable) | non structuré | Partie chaîne de requête de l'adresse URI |
L'autorité d'une adresse URI correspond à la définition du composant authority
dans [URI].
Le radical d'une adresse URI correspond aux informations contenues dans la partie de l'adresse URI située
après l'autorité et jusqu'au premier caractère point d'interrogation ?
compris, la chaîne de requête correspond aux informations
contenues dans la portion de l'adresse URI située après le premier caractère point d'interrogation ?
.
Pour les adresses URI sans caractère point d'interrogation ?
, le radical correspond à l'adresse URI
entière et la chaîne de requête correspond à l'élément vide.
Puisque les informations contenues dans l'adresse URI peuvent s'utiliser de différentes manières, en fonction du contexte,
tous les champs de la structure uri
sont étiquetés comme étant de catégorie variable
. Les
définitions de schéma DOIVENT explicitement assigner la catégorie correspondante dans l'élément appelant cette structure de données.
La structure ipaddr
représente le nom d'hôte et l'adresse IP d'un système.
ipaddr |
Catégorie | Structure | Nom abrégé |
hostname | Informations sur le système | non structuré | Nom d'hôte et de domaine complet |
partialhostname | Informations démographiques et socio-économiques | non structuré | Nom d'hôte partiel |
fullip | Informations sur le système | non structuré | Adresse IP complète |
partialip | Informations démographiques et socio-économiques | non structuré | Adresse IP partielle |
Le champ hostname
sert à représenter une collection composée soit du simple nom d'hôte d'un système,
soit du nom d'hôte complet, y compris le nom de domaine. Le champ partialhostname
se compose d'un nom d'hôte entièrement
qualifié, dont on a retiré au moins la partie hôte du nom d'hôte. En d'autres termes, on DOIT retirer tout ce qui va jusqu'au
premier caractère point .
, dans le nom d'hôte entièrement qualifié, pour qu'on puisse considérer l'adresse comme un
nom d'hôte partiel
.
Le champ fullip
correspond à une adresse IP version 4 (ou IP version 6) complète.
Le champ partialip
représente une adresse IP version 4 (uniquement, et pas une adresse de version 6),
dont au moins les sept derniers bits d'information ont été supprimés. On DOIT effectuer la suppression en remplaçant
ces bits par un motif fixe pour tous les visiteurs (par exemple, seulement des 0 ou seulement des 1).
Certains sites Web sont connus pour ne pas utiliser l'adresse IP ou le nom d'hôte complets du visiteur, mais seulement
une forme réduite. Par conséquent, la collecte d'un sous-ensemble des informations composant une adresse permet au visiteur du site
de bénéficier d'une certaine forme d'anonymat. Cette spécification ne prétend absolument pas qu'il soit impossible d'associer ces
adresses IP ou ces noms d'hôte tronqués
à un utilisateur individuel, mais plutôt que cette association est rendue
beaucoup plus difficile. Les sites qui opèrent cette réduction des données PEUVENT le déclarer afin de mieux refléter leurs pratiques.
La structure loginfo
sert à représenter les informations stockées habituellement dans le journal des accès du serveur Web.
loginfo |
Catégorie | Structure | Nom abrégé |
uri | Données de navigation et de parcours | uri | Adresse URI de la ressource demandée |
timestamp | Données de navigation et de parcours | date | Datation de la requête |
clientip | Informations du système, Données démographiques et socio-économiques | ipaddr | Adresse IP ou nom d'hôte du client |
other.httpmethod | Données de navigation et de parcours | non structuré | Méthode de requête HTTP |
other.bytes | Données de navigation et de parcours | non structuré | Nombre d'octets de données dans la réponse |
other.statuscode | Données de navigation et de parcours | non structuré | Code de statut de la réponse |
La ressource objet de la requête HTTP est capturée par le champ uri
. L'heure à laquelle le serveur
traite la requête est représentée par le champ timestamp
. Les mises en œuvre de serveur sont libres de définir
ce champs comme le moment de la réception de la requête, le moment où le serveur a lancé l'envoi de la réponse, le moment où l'envoi
de la réponse s'est terminé ou toute représentation commode du moment où la requête a été traitée. L'adresse IP
du système client à l'origine de la requête est donnée par le champ clientip
.
Les divers champs de données other
représentent les autres informations stockées habituellement dans les journaux d'accès
des serveurs Web. Le champ other.httpmethod
représente la méthode HTTP (telle que GET
, POST
, etc.)
utilisée dans la requête du client, le champ other.bytes
le nombre d'octets dans le corps de la réponse envoyée par le serveur,
le champ other.statuscode
le code de statut HTTP de la requête, tel que 200, 302 ou 404 (cf. la
section 6.1.1 de [HTTP1.1] pour des précisions).
La structure httpinfo
représente les informations véhiculées par le protocole HTTP non couvertes par la
structure loginfo
.
httpinfo |
Catégorie | Structure | Nom abrégé |
referer | Données de navigation et de parcours | uri | Dernière adresse URI demandée par l'utilisateur |
useragent | Informations de système | non structuré | Agent utilisateur |
Le champ useragent
représente les informations contenues dans l'en-tête HTTP User-Agent
qui renseigne sur les type et version du navigateur Web de l'utilisateur et/ou les en-têtes HTTP Accept*.
Le champ referer
représente les informations contenues dans l'en-tête HTTP Referer
qui renseigne sur la page précédente visitée par l'utilisateur. Remarquez que l'intitulé de ce champ contient une erreur orthographique
tout comme l'en-tête HTTP correspondante (NdT. l'orthographe anglaise correcte est referrer
).
Toutes les mises en œuvre d'agent utilisateur P3P conformes DOIVENT reconnaître les éléments de données
du schéma de données P3P de base. Le schéma de données P3P de base comprend les définitions des
structures de données de base et quatre jeux d'éléments de données : user
,
thirdparty
, business
et
dynamic
. Les jeux user
, thirdparty
et business
comprennent des éléments auxquels les utilisateurs et/ou les entreprises peuvent donner des valeurs, alors que le jeu dynamic
comprend des éléments automatiquement générés au cours de la session de navigation d'un utilisateur. Les agents utilisateurs peuvent
gérer des mécanismes divers, y compris des mécanismes multi-utilisateurs, permettant aux utilisateurs de fixer les valeurs des
éléments du jeu user
et de stocker ces valeurs dans un référentiel de données. Les utilisateurs peuvent aussi
ne pas fixer de valeur pour ces éléments de données.
La définition XML formelle du schéma de données P3P de base est fournie dans l'annexe 3. Dans les sections suivantes, les éléments de données et les jeux de données de base sont expliqués individuellement. Une demande pour la création d'autres jeux et éléments de données est très probable Les applications évidentes à prévoir comprennent les schémas de catalogue, de paiement et d'attributs d'agent/système (un jeu étendu d'éléments système est fourni en exemple dans http://www.w3.org/TR/NOTE-agent-attributes).
Chaque tableau suivant définit un jeu, les éléments de ce jeu, la catégorie associée à l'élément, la structure de l'élément et le nom abrégé affiché pour l'utilisateur. On peut associer plusieurs catégories à un élément de données fixe. Néanmoins, si c'est possible, chaque élément de données de base n'est associé qu'à une seule catégorie. On recommande aux concepteurs de schémas de données de faire de même.
Le jeu de données user
inclut des informations générales au sujet de l'utilisateur.
user |
Catégorie | Structure | Nom abrégé |
name | Coordonnées physiques, Données démographiques et socio-économiques | personname | Nom de l'utilisateur |
bdate | Données démographiques et socio-économiques | date | Date de naissance de l'utilisateur |
login | Identificateurs uniques | login | Identifiant de connexion de l'utilisateur |
cert | Identificateurs uniques | certificate | Certificat d'identité de l'utilisateur |
gender | Données démographiques et socio-économiques | non structuré | Genre (masculin ou féminin) |
employer | Données démographiques et socio-économiques | non structuré | Employeur de l'utilisateur |
department | Données démographiques et socio-économiques | non structuré | Service ou division de l'organisation employant l'utilisateur |
jobtitle | Données démographiques et socio-économiques | non structuré | Profession de l'utilisateur |
home-info | Coordonnées physiques, Coordonnées en ligne, Données démographiques et socio-économiques | contact | Coordonnées de l'utilisateur au domicile |
business-info | Coordonnées physique, Coordonnées en ligne, Données démographiques et socio-économiques | contact | Coordonnées de l'utilisateur au bureau |
Remarquer que ce jeu de données comprend des éléments qui sont en réalité eux-mêmes des jeux de données.
Ces jeux sont définis dans la sous-section Les structures de données de ce document.
On définit le nom abrégé d'un élément individuel contenu dans un jeu de données comme étant la concaténation des noms abrégés d'affichage
qui ont été définis pour le jeu et l'élément, délimités par des caractères appropriés selon la langue ou l'écriture en question,
c'est-à-dire, des caractères virgule en français. Par exemple, le nom abrégé pour user.home-info.postal.postalcode
pourrait être Coordonnées de l'utilisateur au domicile, Adresse postale, Code postal
. Les mises en œuvre d'agent utilisateur
peuvent choisir de développer leurs propres noms abrégés d'affichage au lieu d'utiliser des noms concaténés pour une présentation
d'informations à l'utilisateur.
Le jeu de données thirdparty
permet aux utilisateurs et aux entreprises de fournir des valeurs pour un tiers concerné.
Ceci peut se révéler utile à chaque fois qu'on aura besoin d'échanger les informations d'un tiers, par exemple, lorsqu'on commande un
cadeau en ligne devant être envoyé à une autre personne, ou lorsqu'on fournit des renseignements concernant un(e) époux(se)
ou un(e) associé(e). Ces renseignements pourraient être stockés dans un référentiel d'utilisateur en accompagnement du
jeu de données user
. Les agents utilisateurs peuvent proposer de stocker plusieurs jeux de données thirdparty
de ce type et permettre aux utilisateurs de sélectionner à la demande les valeurs appropriées dans une liste.
Le jeu de données thirdparty
est identique au jeu de données user
. Cf. la section
5.6.1 Les données de l'utilisateur pour des précisions.
Le jeu de données business
représente un sous-ensemble du jeu de données user
convenant à la description
des personnes morales. Dans le protocole P3P1.0, ce jeu de données sert principalement à déclarer l'entité responsable
de la politique, bien que le jeu puisse aussi s'appliquer aux échanges interentreprises.
business |
Catégorie | Structure | Nom abrégé |
name | Données démographiques et socio-économiques | non structuré | Nom de l'organisation |
department | Données démographiques et socio-économiques | non structuré | Service ou division de l'organisation |
cert | Identificateurs uniques | certificate | Certificat d'identité de l'organisation |
contact-info | Coordonnées physique, Coordonnées en ligne, Données démographiques et socio-économiques | contact | Coordonnées de l'organisation |
Dans certains cas, il est nécessaire de définir des éléments de données sans valeur fixe qu'un utilisateur peut saisir ou stocker
dans un référentiel. Dans le schéma de données P3P de base, tous les éléments de ce type sont regroupés dans le
jeu de données dynamic
. Les sites peuvent se référer aux types des données qu'ils collectent en utilisant seulement le
jeu de données dynamic
, au lieu d'énumérer tous les éléments de données spécifiques.
dynamic |
Catégorie | Structure | Nom abrégé |
clickstream | Données de navigation et de parcours, Informations de système | loginfo | Informations de parcours |
http | Données de navigation et de parcours, Informations de système | httpinfo | Informations de protocole HTTP |
clientevents | Données de navigation et de parcours | non structuré | Interaction de l'utilisateur avec une ressource |
cookies | (catégorie variable) | non structuré | Utilisation de cookies HTTP |
miscdata | (catégorie variable) | non structuré | Informations diverses hors du schéma de données de base |
searchtext | Données interactives | non structuré | Termes de recherche |
interactionrecord | Données interactives | non structuré | Historique de l'échange stocké par le serveur |
Ces éléments sont souvent implicites dans la navigation ou les interactions Web. On devrait les utiliser avec des catégories pour décrire le type d'information collecté par ces méthodes. Une brève description suit :
clickstream
clickstream
s'appliquera quasiment à tous les sites Web. Il représente une combinaison d'informations
trouvées typiquement dans les journaux d'accès des serveurs Web : l'adresse IP ou
le nom d'hôte du système de l'utilisateur, l'adresse URI de la ressource demandée, le moment où la requête a eu lieu,
la méthode HTTP employée pour la requête, la taille de la réponse et son code de statut. Les sites Web collectant
les journaux d'accès standards des serveurs, ainsi que ceux analysant les chemins d'accès des adresses URI,
peuvent recourir à cet élément de données afin de décrire comment sont utilisées les données. Les sites Web ne collectant qu'une partie
des éléments de données listés pour l'élément clickstream
PEUVENT opter pour lister ces éléments spécifiques au lieu de
l'élément dynamic.clickstream
en entier. Cela permet aux sites dont les pratiques de collecte des données sont
plus limitées de présenter exactement ces pratiques à leurs visiteurs.http
http
contient des informations supplémentaires issues du protocole HTTP. Cf. la définition de
la structure httpinfo
pour la description des éléments spécifiques. Les sites PEUVENT utiliser le
champ dynamic.http
comme raccourci pour couvrir tous les éléments de la structure httpinfo
,
ou bien ils PEUVENT appeler individuellement les éléments de la structure httpinfo
.clientevents
clientevents
représente des données liées au comportement de l'utilisateur vis-à-vis de son navigateur Web
au cours d'une interaction avec une ressource. Par exemple, une application souhaite collecter les informations répondant aux
questions suivantes : l'utilisateur a-t-il amené le pointeur sur telle image de telle page, ou a-t-il recouru à la fenêtre d'aide
d'un applet Java. Ce type d'information est représenté par l'élément de données dynamic.clientevents
.
La majeure partie de l'enregistrement de ces interactions est représentée par les événements et les données définis dans la spécification
du modèle objet de document (DOM) niveau 2 m‐ Événements
[DOM2-Events]. L'élément clientevents
couvre également toutes les autres données en rapport
avec les interactions de l'utilisateur avec son navigateur au cours de l'affichage d'une ressource, à l'exception des événements
couverts par d'autres éléments du schéma de données de base. Par exemple, le fait de requérir une page en cliquant sur un lien au cours
de la consultation d'une page constitue une interaction de l'utilisateur avec son navigateur, tandis que le simple fait de collecter
l'adresse URL correspondant au lien cliqué par l'utilisateur ne nécessite pas de déclarer cet élément de données :
cet événement est couvert par clickstream
. Par contre, l'événement DOM DOMFocusIn
(représentant le déplacement du pointeur sur un objet d'une page par l'utilisateur) n'est couvert par aucun élément existant, et
si un site enregistre l'occurrence de cet événement, il doit donc déclarer collecter l'élément dynamic.clientevents
.
Les items couverts par cet élément de données sont typiquement collectés côté client par des langages de script tel que JavaScript
ou par des applets tels que des applets ActiveX ou Java. Bien que la discussion précédente tienne du point de vue d'un utilisateur
voyant une ressource, remarquez que cet élément de données s'applique également aux applications Web non visuelles, par exemple, les
navigateurs Web sonores.cookies
cookies
à chaque fois que des cookies HTTP sont installés ou récupérés
par un site. Remarquez que cookies
est un élément de données variable qui nécessite une déclaration explicite
des catégories d'utilisation dans la politique.miscdata
miscdata
référence des informations collectées par un service ne recourant pas à un
élément de données spécifique. On doit se servir de catégories afin de décrire mieux ces données : les sites DOIVENT référencer
dans leurs politiques des éléments miscdata
séparés pour chaque catégorie de données diverses collectées.searchtext
searchtext
référence un type de sollicitation particulier utilisé pour une recherche dans les sites et pour
leur indexation. Par exemple, si les seuls champs de la page d'un moteur de recherche sont des champs de recherche,
alors le site aura seulement besoin de divulguer cet élément de données.interactionrecord
interactionrecord
si le serveur garde la trace des interactions avec un utilisateurs
(c'est-à-dire, d'autres informations que des données de parcours, par exemple, les transactions sur un compte, etc.).La plupart des éléments du schéma de données de base sont dits fixes
: ils appartiennent à une ou deux (au plus) classes
de catégorie. En assignant invariablement une catégorie aux éléments/structures du schéma de donnés de base, les services et
les utilisateurs peuvent se référer à des groupes d'éléments entiers en appelant simplement la catégorie correspondante. Par exemple,
en utilisant le langage d'échange de préférences de confidentialité [APPEL], les utilisateurs peuvent écrire
des règles afin d'être avertis lorsqu'ils visiteront un site collectant des éléments de données d'une certaine catégorie.
Lors de la création de schémas de données pour des éléments de données fixes, les concepteurs doivent explicitement énumérer les catégories auxquelles ces éléments appartiennent. Par exemple :
<DATA-STRUCT name="postal.street" structref="#text" short-description="Nom de la rue"> <CATEGORIES><physical/></CATEGORIES> </DATA-STRUCT>
Si un élément, ou une structure, appartient à plusieurs catégories, on peut utiliser plusieurs éléments référençant
les catégories appropriées. Par exemple, le fragment XML suivant peut servir à déclarer que les éléments de données dans
user.name
ont les deux catégories physical
et demographic
:
<DATA-STRUCT name="user.name" structref="#personname" short-description="Nom de l'utilisateur"> <CATEGORIES><physical/><demographic/></CATEGORIES> </DATA-STRUCT>
Remarquez qu'on ne peut pas supprimer les classes de catégorie des éléments/structures de données fixes, par exemple, en écrivant des règles ou des politiques assignant une catégorie différente à un élément de données de base fixe connu. Les agents utilisateurs DOIVENT ignorer ces catégories et continuer d'utiliser la catégorie d'origine (ou le jeu de catégories d'origine) listée dans la définition du schéma. Préférablement, les agents utilisateurs PEUVENT avertir l'utilisateur de l'emploi d'un élément de données fixe ayant une classe de catégorie non standard.
Les éléments/structures de données dans le schéma de données de base n'appartiennent pas tous à une classe de catégorie prédéfinie.
Parmi eux, il y en a qui contiendront des informations provenant de diverses catégories, en fonction d'une situation donnée.
Ces éléments ou structures de données sont appelés éléments/structures de données de catégorie variable (ou, en abrégé,
éléments/structures de données variables
. Bien que la plupart des éléments de données variables du
schéma de données P3P de base soit combinée dans le jeu d'éléments dynamic
, ils peuvent apparaître dans
n'importe quel jeu de données, et même mélangés avec des éléments de données de catégorie fixe.
Lors de la création d'une définition de schéma pour ces éléments et/ou structures, les auteurs NE DOIVENT PAS lister
d'attribut de catégorie explicite car autrement l'élément/structure devient fixe. Par exemple, lorsqu'on définit
la structure de données year
, qui est susceptible d'entrer dans plusieurs catégories selon le contexte (par exemple,
une date d'expiration de carte de crédit par opposition à une date d'anniversaire), on peut utiliser la définition de schéma suivante :
<DATA-STRUCT name="date.ymd.year" short-description="Année"/> <!-- Structure de données variable -->
Cela permet aux nouvelles extensions de schéma qui appellent ces structures de données de catégorie variable d'assigner une catégorie spécifique aux éléments dérivés, en fonction de leur emploi dans cette extension. Par exemple, une extension de schéma pour le commerce en ligne peut ainsi définir la date d'expiration d'une carte de crédit de la manière suivante :
<DATA-STRUCT name="Carte.DateExp" structref="#date.ymd" short-description="Date d'expiration de la carte"> <CATEGORIES><purchase/></CATEGORIES> </DATA-STRUCT>
Dans ces conditions, on assigne la catégorie fixe Informations d'achat
à la
structure de données variable date
lorsqu'elle sert à définir la date d'expiration d'une carte de crédit.
Bien que les préférences de l'utilisateur puissent lister ces éléments de données variables sans autre indication de catégorie
(en exprimant en fait des préférences pour n'importe quelle utilisation de cet élément), remarquez que les services DOIVENT
toujours définir explicitement les catégories qui s'appliquent à l'utilisation d'un élément de données variable
dans leur politique particulière. Cette information doit prendre la forme d'un élément <CATEGORIES>
dans l'élément <DATA>
listé dans la politique, par exemple, comme dans l'exemple suivant :
<POLICY ... > ... <DATA ref="#dynamic.cookies"><CATEGORIES><uniqueid/></CATEGORIES></DATA> ... </POLICY>
Dans cet exemple, un service déclare utiliser des cookies afin de reconnaître un utilisateur sur le site (c'est-à-dire, avec la catégorie Identificateurs uniques).
Si un service souhaite déclarer un élément de données qui apparaît dans plusieurs catégories, il déclare simplement les catégories correspondantes (comme illustré dans la section précédente) :
<POLICY ... > ... <DATA ref="#dynamic.cookies"><CATEGORIES><uniqueid/><preference/></CATEGORIES></DATA> ... </POLICY>
Selon la déclaration ci-dessus, un service annonce utiliser des cookies afin de reconnaître l'utilisateur sur le site et afin de stocker des données concernant les préférences de l'utilisateur. Remarquez que, pour le protocole P3P, un stockage de ces renseignements sur deux cookies distincts ou sur un seul cookie ne fait aucune différence.
Enfin, remarquez que les catégories peuvent aussi s'hériter : les catégories se répercutent sur les sous-éléments si les champs sont structurés mais uniquement quand ceux-ci n'ont aucune catégorie prédéfinie. On suggère donc aux auteurs de schémas de faire au mieux afin de s'assurer que toutes les catégories concernées puissent s'appliquer aux nouveaux éléments de données qu'ils auront créés.
Le protocole P3P offre aux sites Web une grande souplesse dans la manière de décrire les types de données qu'ils collectent :
dynamic.miscdata
et les catégories appropriées ;On peut combiner n'importe lesquelles de ces trois méthodes dans une seule politique.
En utilisant l'élément dynamic.miscdata
, les sites peuvent indiquer les types de données
qu'ils collectent, sans devoir énumérer individuellement chaque élément de données. Cela peut se révéler commode pour les sites
collectant beaucoup de données ou appartenant à de grandes organisations qui veulent offrir une seule politique P3P
couvrant l'organisation entière. Toutefois, cette approche présente l'inconvénient selon lequel les agents utilisateurs supposeront
que le site est susceptible de collecter n'importe quel élément de données appartenant aux catégories référencées par le site.
Ainsi, par exemple, si la politique d'un site déclare collecter les éléments de données dynamic.miscdata
de la catégorie Coordonnées physiques
, alors qu'il ne collecte en réalité comme seules coordonnées physiques que les
adresses au bureau, les agents utilisateurs supposeront néanmoins que le site peut aussi collecter les numéros de téléphone.
Si le site souhaite préciser ne pas collecter les numéros de téléphone ni aucune autre coordonnée physique hormi les adresses au bureau,
alors il devrait divulguer une collecte des éléments de données user.business-info.contact.postal
.
De plus, comme les agents utilisateurs tendent à offrir des fonctionnalités de remplissage automatique des formulaires,
les sites qui énumèrent les données collectées exploiteront vraisemblablement mieux ces outils.
En définissant de nouveaux schémas de données, les sites peuvent indiquer précisément quelles données sont collectées, au-delà du jeu de données de base. Toutefois, si les agents utilisateurs ne reconnaissent pas les éléments définis dans ces schémas, ils ne pourront offrir à l'utilisateur qu'un minimum d'information sur ces nouveaux éléments. Les informations fournies seront fondées sur la catégorie et sur les noms abrégés indiqués pour chaque élément.
Indépendamment du souhait de divulguer des données générales ou bien particulières, un site peut trouver d'autres avantages à
divulguer des éléments spécifiques en partant du jeu de données dynamic
. Par exemple, en divulguant
les éléments de données dynamic.cookies
, un site peut indiquer recourir à des cookies et
exposer les raisons de leur utilisation. On encourage les mises en œuvre d'agent utilisateur qui offrent des interfaces de contrôle
des cookies en fonction de ces informations. De la même façon, les agents utilisateurs qui n'envoient pas, par défaut,
d'en-tête HTTP Referer pourront rechercher l'élément de données dynamic.http.referer
dans les politiques P3P et envoyer alors cette en-tête, à condition que l'intention déclarée soit acceptable pour l'utilisateur.
On présente à la suite le schéma de données correspondant au schéma de données P3P de base pour en faciliter la consultation. Le schéma est également disponible dans un fichier séparé à l'adresse URI http://www.w3.org/TR/P3P/base.
<DATASCHEMA xmlns="http://www.w3.org/2002/01/P3Pv1"> <!-- ********** Structures de données de base ********** --> <!-- Structure de données "date" --> <DATA-STRUCT name="date.ymd.year" short-description="Année"/> <DATA-STRUCT name="date.ymd.month" short-description="Mois"/> <DATA-STRUCT name="date.ymd.day" short-description="Jour"/> <DATA-STRUCT name="date.hms.hour" short-description="Heure"/> <DATA-STRUCT name="date.hms.minute" short-description="Minute"/> <DATA-STRUCT name="date.hms.second" short-description="Seconde"/> <DATA-STRUCT name="date.fractionsecond" short-description="Fraction de seconde"/> <DATA-STRUCT name="date.timezone" short-description="Fuseau horaire"/> <!-- Structure de données "login" --> <DATA-STRUCT name="login.id" short-description="Identifiant de connexion"> <CATEGORIES><uniqueid/></CATEGORIES> </DATA-STRUCT> <DATA-STRUCT name="login.password" short-description="Mot de passe de connexion"> <CATEGORIES><uniqueid/></CATEGORIES> </DATA-STRUCT> <!-- Structure de données "personname" --> <DATA-STRUCT name="personname.prefix" short-description="Titre"> <CATEGORIES><demographic/></CATEGORIES> </DATA-STRUCT> <DATA-STRUCT name="personname.given" short-description="Prénom"> <CATEGORIES><physical/></CATEGORIES> </DATA-STRUCT> <DATA-STRUCT name="personname.middle" short-description="Deuxième prénom"> <CATEGORIES><physical/></CATEGORIES> </DATA-STRUCT> <DATA-STRUCT name="personname.family" short-description="Nom de famille"> <CATEGORIES><physical/></CATEGORIES> </DATA-STRUCT> <DATA-STRUCT name="personname.suffix" short-description="Suffixe de nom"> <CATEGORIES><demographic/></CATEGORIES> </DATA-STRUCT> <DATA-STRUCT name="personname.nickname" short-description="Surnom"> <CATEGORIES><demographic/></CATEGORIES> </DATA-STRUCT> <!-- Structure de données "certificate" --> <DATA-STRUCT name="certificate.key" short-description="Clé de certificat"> <CATEGORIES><uniqueid/></CATEGORIES> </DATA-STRUCT> <DATA-STRUCT name="certificate.format" short-description="Format de certificat"> <CATEGORIES><uniqueid/></CATEGORIES> </DATA-STRUCT> <!-- Structure de données "telephonenum" --> <DATA-STRUCT name="telephonenum.intcode" short-description="Indicatif téléphonique international"> <CATEGORIES><physical/></CATEGORIES> </DATA-STRUCT> <DATA-STRUCT name="telephonenum.loccode" short-description="Indicatif téléphonique régional"> <CATEGORIES><physical/></CATEGORIES> </DATA-STRUCT> <DATA-STRUCT name="telephonenum.number" short-description="Numéro de téléphone"> <CATEGORIES><physical/></CATEGORIES> </DATA-STRUCT> <DATA-STRUCT name="telephonenum.ext" short-description="Poste téléphonique supplémentaire"> <CATEGORIES><physical/></CATEGORIES> </DATA-STRUCT> <DATA-STRUCT name="telephonenum.comment" short-description="Commentaire téléphonique optionnel"> <CATEGORIES><physical/></CATEGORIES> </DATA-STRUCT> <!-- Structure de données "postal" --> <DATA-STRUCT name="postal.name" structref="#personname"> </DATA-STRUCT> <DATA-STRUCT name="postal.street" short-description="Rue"> <CATEGORIES><physical/></CATEGORIES> </DATA-STRUCT> <DATA-STRUCT name="postal.city" short-description="Ville"> <CATEGORIES><demographic/></CATEGORIES> </DATA-STRUCT> <DATA-STRUCT name="postal.stateprov" short-description="État ou province"> <CATEGORIES><demographic/></CATEGORIES> </DATA-STRUCT> <DATA-STRUCT name="postal.postalcode" short-description="Code postal"> <CATEGORIES><demographic/></CATEGORIES> </DATA-STRUCT> <DATA-STRUCT name="postal.organization" short-description="Nom de l'organisation"> <CATEGORIES><demographic/></CATEGORIES> </DATA-STRUCT> <DATA-STRUCT name="postal.country" short-description="Pays"> <CATEGORIES><demographic/></CATEGORIES> </DATA-STRUCT> <!-- Structure de données "telecom" --> <DATA-STRUCT name="telecom.telephone" short-description="Numéro de téléphone" structref="#telephonenum"> <CATEGORIES><physical/></CATEGORIES> </DATA-STRUCT> <DATA-STRUCT name="telecom.fax" short-description="Numéro de télécopie" structref="#telephonenum"> <CATEGORIES><physical/></CATEGORIES> </DATA-STRUCT> <DATA-STRUCT name="telecom.mobile" short-description="Numéro de mobile" structref="#telephonenum"> <CATEGORIES><physical/></CATEGORIES> </DATA-STRUCT> <DATA-STRUCT name="telecom.pager" short-description="Numéro de téléavertisseur" structref="#telephonenum"> <CATEGORIES><physical/></CATEGORIES> </DATA-STRUCT> <!-- Structure de données "online" --> <DATA-STRUCT name="online.email" short-description="Adresse électronique"> <CATEGORIES><online/></CATEGORIES> </DATA-STRUCT> <DATA-STRUCT name="online.uri" short-description="Adresse de page d'accueil"> <CATEGORIES><online/></CATEGORIES> </DATA-STRUCT> <!-- Structure de données "contact" --> <DATA-STRUCT name="contact.postal" short-description="Adresse postale" structref="#postal"> </DATA-STRUCT> <DATA-STRUCT name="contact.telecom" short-description="Coordonnées de télécommunication" structref="#telecom"> <CATEGORIES><physical/></CATEGORIES> </DATA-STRUCT> <DATA-STRUCT name="contact.online" short-description="Coordonnées en ligne" structref="#online"> <CATEGORIES><online/></CATEGORIES> </DATA-STRUCT> <!-- Structure de données "uri" --> <DATA-STRUCT name="uri.authority" short-description="Autorité d'adresse URI"/> <DATA-STRUCT name="uri.stem" short-description="Radical d'adresse URI"/> <DATA-STRUCT name="uri.querystring" short-description="Partie chaîne de requête d'adresse URI"/> <!-- Structure de données "ipaddr" --> <DATA-STRUCT name="ipaddr.hostname" short-description="Nom d'hôte et de domaine complet"> <CATEGORIES><computer/></CATEGORIES> </DATA-STRUCT> <DATA-STRUCT name="ipaddr.partialhostname" short-description="Nom d'hôte partiel"> <CATEGORIES><demographic/></CATEGORIES> </DATA-STRUCT> <DATA-STRUCT name="ipaddr.fullip" short-description="Adresse IP complète"> <CATEGORIES><computer/></CATEGORIES> </DATA-STRUCT> <DATA-STRUCT name="ipaddr.partialip" short-description="Adresse IP partielle"> <CATEGORIES><demographic/></CATEGORIES> </DATA-STRUCT> <!-- Structure de données "loginfo" --> <DATA-STRUCT name="loginfo.uri" short-description="Adresse URI de la ressource demandée" structref="#uri"> <CATEGORIES><navigation/></CATEGORIES> </DATA-STRUCT> <DATA-STRUCT name="loginfo.timestamp" short-description="Datation de la requête" structref="#date"> <CATEGORIES><navigation/></CATEGORIES> </DATA-STRUCT> <DATA-STRUCT name="loginfo.clientip" short-description="Adresse IP ou nom d'hôte du client" structref="#ipaddr"> </DATA-STRUCT> <DATA-STRUCT name="loginfo.other.httpmethod" short-description="Méthode de requête HTTP"> <CATEGORIES><navigation/></CATEGORIES> </DATA-STRUCT> <DATA-STRUCT name="loginfo.other.bytes" short-description="Nombre d'octets de données dans la réponse"> <CATEGORIES><navigation/></CATEGORIES> </DATA-STRUCT> <DATA-STRUCT name="loginfo.other.statuscode" short-description="Code de statut de la réponse"> <CATEGORIES><navigation/></CATEGORIES> </DATA-STRUCT> <!-- Structure de données "httpinfo" --> <DATA-STRUCT name="httpinfo.referer" short-description="Dernière adresse URI demandée par l'utilisateur" structref="#uri"> <CATEGORIES><navigation/></CATEGORIES> </DATA-STRUCT> <DATA-STRUCT name="httpinfo.useragent" short-description="Informations sur l'agent utilisateur"> <CATEGORIES><computer/></CATEGORIES> </DATA-STRUCT> <!-- ********** Schémas de données de base ********** --> <!-- Schéma de données "dynamic" --> <DATA-DEF name="dynamic.clickstream" short-description="Information de parcours" structref="#loginfo"> <CATEGORIES><navigation/><computer/><demographic/></CATEGORIES> </DATA-DEF> <DATA-DEF name="dynamic.http" short-description="Informations de protocole HTTP" structref="#httpinfo"> <CATEGORIES><navigation/><computer/></CATEGORIES> </DATA-DEF> <DATA-DEF name="dynamic.clientevents" short-description="Interaction de l'utilisateur avec une ressource"> <CATEGORIES><navigation/></CATEGORIES> </DATA-DEF> <DATA-DEF name="dynamic.cookies" short-description="Utilisation de cookies HTTP"/> <DATA-DEF name="dynamic.searchtext" short-description="Termes de recherche"> <CATEGORIES><interactive/></CATEGORIES> </DATA-DEF> <DATA-DEF name="dynamic.interactionrecord" short-description="Historique de l'échange stocké par le serveur"> <CATEGORIES><interactive/></CATEGORIES> </DATA-DEF> <DATA-DEF name="dynamic.miscdata" short-description="Informations diverses hors schéma de données de base"/> <!-- Schéma de données "user" --> <DATA-DEF name="user.name" short-description="Nom de l'utilisateur" structref="#personname"> <CATEGORIES><physical/><demographic/></CATEGORIES> </DATA-DEF> <DATA-DEF name="user.bdate" short-description="Date de naissance de l'utilisateur" structref="#date"> <CATEGORIES><demographic/></CATEGORIES> </DATA-DEF> <DATA-DEF name="user.login" short-description="Identifiant de connexion de l'utilisateur" structref="#login"> <CATEGORIES><uniqueid/></CATEGORIES> </DATA-DEF> <DATA-DEF name="user.cert" short-description="Certificat d'identité de l'utilisateur" structref="#certificate"> <CATEGORIES><uniqueid/></CATEGORIES> </DATA-DEF> <DATA-DEF name="user.gender" short-description="Genre de l'utilisateur"> <CATEGORIES><demographic/></CATEGORIES> </DATA-DEF> <DATA-DEF name="user.jobtitle" short-description="Profession de l'utilisateur"> <CATEGORIES><demographic/></CATEGORIES> </DATA-DEF> <DATA-DEF name="user.home-info" short-description="Coordonnées de l'utilisateur au domicile" structref="#contact"> <CATEGORIES><physical/><online/><demographic/></CATEGORIES> </DATA-DEF> <DATA-DEF name="user.business-info" short-description="Coordonnées de l'utilisateur au bureau" structref="#contact"> <CATEGORIES><physical/><online/><demographic/></CATEGORIES> </DATA-DEF> <DATA-DEF name="user.employer" short-description="Nom de l'employeur de l'utilisateur"> <CATEGORIES><demographic/></CATEGORIES> </DATA-DEF> <DATA-DEF name="user.department" short-description="Service ou division de l'organisation employant l'utilisateur"> <CATEGORIES><demographic/></CATEGORIES> </DATA-DEF> <!-- Schéma de données "thirdparty" --> <DATA-DEF name="thirdparty.name" short-description="Nom du tiers" structref="#personname"> <CATEGORIES><physical/><demographic/></CATEGORIES> </DATA-DEF> <DATA-DEF name="thirdparty.bdate" short-description="Date d'anniversaire du tiers" structref="#date"> <CATEGORIES><demographic/></CATEGORIES> </DATA-DEF> <DATA-DEF name="thirdparty.login" short-description="Identification de connexion du tiers" structref="#login"> <CATEGORIES><uniqueid/></CATEGORIES> </DATA-DEF> <DATA-DEF name="thirdparty.cert" short-description="Certificat d'identité du tiers" structref="#certificate"> <CATEGORIES><uniqueid/></CATEGORIES> </DATA-DEF> <DATA-DEF name="thirdparty.gender" short-description="Genre du tiers"> <CATEGORIES><demographic/></CATEGORIES> </DATA-DEF> <DATA-DEF name="thirdparty.jobtitle" short-description="Profession du tiers"> <CATEGORIES><demographic/></CATEGORIES> </DATA-DEF> <DATA-DEF name="thirdparty.home-info" short-description="Coordonnées du tiers au domicile" structref="#contact"> <CATEGORIES><physical/><online/><demographic/></CATEGORIES> </DATA-DEF> <DATA-DEF name="thirdparty.business-info" short-description="Coordonnées du tiers au bureau" structref="#contact"> <CATEGORIES><physical/><online/><demographic/></CATEGORIES> </DATA-DEF> <DATA-DEF name="thirdparty.employer" short-description="Nom de l'employeur du tiers"> <CATEGORIES><demographic/></CATEGORIES> </DATA-DEF> <DATA-DEF name="thirdparty.department" short-description="Service ou division de l'organisation employant le tiers"> <CATEGORIES><demographic/></CATEGORIES> </DATA-DEF> <!-- Schéma de données "business" --> <DATA-DEF name="business.name" short-description="Nom de l'organisation"> <CATEGORIES><demographic/></CATEGORIES> </DATA-DEF> <DATA-DEF name="business.department" short-description="Service ou division de l'organisation"> <CATEGORIES><demographic/></CATEGORIES> </DATA-DEF> <DATA-DEF name="business.cert" short-description="Certificat d'identité de l'organisation" structref="#certificate"> <CATEGORIES><uniqueid/></CATEGORIES> </DATA-DEF> <DATA-DEF name="business.contact-info" short-description="Coordonnées de l'organisation" structref="#contact"> <CATEGORIES><physical/><online/><demographic/></CATEGORIES> </DATA-DEF> </DATASCHEMA>
Cette annexe contient le schéma XML pour les fichiers d'appel de politique P3P, pour les documents de politique P3P et pour les documents de schéma de données P3P. Les fichiers d'appel de politique P3P, les documents de politique P3P et les documents de schéma de données P3P sont des documents XML qui DOIVENT se conformer à ce schéma. Remarquer que ce schéma se base sur la spécification XML Schéma [XML-Schema1][XML-Schema2]. Le schéma est également disponible en fichier séparé à l'URI http://www.w3.org/2002/01/P3Pv1.xsd.
<?xml version='1.0' encoding='UTF-8'?> <schema xmlns='http://www.w3.org/2001/XMLSchema' xmlns:p3p='http://www.w3.org/2002/01/P3Pv1' targetNamespace='http://www.w3.org/2002/01/P3Pv1' elementFormDefault='qualified'> <!-- activation de l'attribut xml:lang --> <import namespace='http://www.w3.org/XML/1998/namespace' schemaLocation='http://www.w3.org/2001/xml.xsd' /> <!-- Type de données P3P de base --> <simpleType name='yes_no'> <restriction base='string'> <enumeration value='yes'/> <enumeration value='no'/> </restriction> </simpleType> <!-- *********** Appel de politique *********** --> <!-- ************** META ************** --> <element name='META'> <complexType> <sequence> <element ref='p3p:EXTENSION' minOccurs='0' maxOccurs='unbounded'/> <element ref='p3p:POLICY-REFERENCES'/> <element ref='p3p:POLICIES' minOccurs='0'/> <element ref='p3p:EXTENSION' minOccurs='0' maxOccurs='unbounded'/> </sequence> <attribute ref='xml:lang' use='optional'/> </complexType> </element> <!-- ******* POLICY-REFERENCES ******** --> <element name='POLICY-REFERENCES'> <complexType> <sequence> <element ref='p3p:EXPIRY' minOccurs='0'/> <element ref='p3p:POLICY-REF' minOccurs='0' maxOccurs='unbounded'/> <element ref='p3p:HINT' minOccurs='0' maxOccurs='unbounded'/> <element ref='p3p:EXTENSION' minOccurs='0' maxOccurs='unbounded'/> </sequence> </complexType> </element> <element name='POLICY-REF'> <complexType> <sequence> <element name='INCLUDE' minOccurs='0' maxOccurs='unbounded' type='anyURI'/> <element name='EXCLUDE' minOccurs='0' maxOccurs='unbounded' type='anyURI'/> <element name='COOKIE-INCLUDE' minOccurs='0' maxOccurs='unbounded' type='p3p:cookie-element'/> <element name='COOKIE-EXCLUDE' minOccurs='0' maxOccurs='unbounded' type='p3p:cookie-element'/> <element name='METHOD' minOccurs='0' maxOccurs='unbounded' type='anyURI'/> <element ref='p3p:EXTENSION' minOccurs='0' maxOccurs='unbounded'/> </sequence> <attribute name='about' type='anyURI' use='required'/> </complexType> </element> <complexType name='cookie-element'> <attribute name='name' type='string' use='optional'/> <attribute name='value' type='string' use='optional'/> <attribute name='domain' type='string' use='optional'/> <attribute name='path' type='string' use='optional'/> </complexType> <!-- ************* HINT ************* --> <element name='HINT'> <complexType> <attribute name='scope' type='string' use='required'/> <attribute name='path' type='string' use='required'/> </complexType> </element> <!-- ************ POLICIES ************ --> <element name='POLICIES'> <complexType> <sequence> <element ref='p3p:EXPIRY' minOccurs='0'/> <element ref='p3p:DATASCHEMA' minOccurs='0'/> <element ref='p3p:POLICY' minOccurs='0' maxOccurs='unbounded'/> </sequence> <attribute ref='xml:lang' use='optional'/> </complexType> </element> <!-- ************* EXPIRY ************* --> <element name='EXPIRY'> <complexType> <attribute name='max-age' type='nonNegativeInteger' use='optional'/> <attribute name='date' type='string' use='optional'/> </complexType> </element> <!-- **************** Politique **************** --> <!-- ************* POLICY ************* --> <element name='POLICY'> <complexType> <sequence> <element ref='p3p:EXTENSION' minOccurs='0' maxOccurs='unbounded'/> <element ref='p3p:TEST' minOccurs='0'/> <element ref='p3p:ENTITY'/> <element ref='p3p:ACCESS'/> <element ref='p3p:DISPUTES-GROUP' minOccurs='0'/> <element ref='p3p:STATEMENT' maxOccurs='unbounded'/> <element ref='p3p:EXTENSION' minOccurs='0' maxOccurs='unbounded'/> </sequence> <attribute name='discuri' type='anyURI' use='required'/> <attribute name='opturi' type='anyURI' use='optional'/> <attribute name='name' type='ID' use='required'/> <attribute ref='xml:lang' use='optional'/> </complexType> </element> <!-- ************* TEST ************* --> <element name='TEST'> <complexType/> </element> <!-- ************* ENTITY ************* --> <element name='ENTITY'> <complexType> <sequence> <element ref='p3p:EXTENSION' minOccurs='0' maxOccurs='unbounded'/> <element name='DATA-GROUP'> <complexType> <sequence> <element name='DATA' type='p3p:data-in-entity' maxOccurs='unbounded'/> </sequence> </complexType> </element> <element ref='p3p:EXTENSION' minOccurs='0' maxOccurs='unbounded'/> </sequence> </complexType> </element> <complexType name='data-in-entity' mixed='true'> <attribute name='ref' type='anyURI' use='required'/> </complexType> <!-- ************* ACCESS ************* --> <element name='ACCESS'> <complexType> <sequence> <element ref='p3p:EXTENSION' minOccurs='0' maxOccurs='unbounded'/> <choice> <element name='nonident' type='p3p:access-value'/> <element name='ident-contact' type='p3p:access-value'/> <element name='other-ident' type='p3p:access-value'/> <element name='contact-and-other' type='p3p:access-value'/> <element name='all' type='p3p:access-value'/> <element name='none' type='p3p:access-value'/> </choice> <element ref='p3p:EXTENSION' minOccurs='0' maxOccurs='unbounded'/> </sequence> </complexType> </element> <complexType name='access-value'/> <!-- ************ DISPUTES ************ --> <element name='DISPUTES-GROUP'> <complexType> <sequence> <element ref='p3p:EXTENSION' minOccurs='0' maxOccurs='unbounded'/> <element ref='p3p:DISPUTES' maxOccurs='unbounded'/> <element ref='p3p:EXTENSION' minOccurs='0' maxOccurs='unbounded'/> </sequence> </complexType> </element> <element name='DISPUTES'> <complexType> <sequence> <element ref='p3p:EXTENSION' minOccurs='0' maxOccurs='unbounded'/> <choice minOccurs='0'> <sequence> <element ref='p3p:LONG-DESCRIPTION'/> <element ref='p3p:IMG' minOccurs='0'/> <element ref='p3p:REMEDIES' minOccurs='0'/> <element ref='p3p:EXTENSION' minOccurs='0' maxOccurs='unbounded'/> </sequence> <sequence> <element ref='p3p:IMG'/> <element ref='p3p:REMEDIES' minOccurs='0'/> <element ref='p3p:EXTENSION' minOccurs='0' maxOccurs='unbounded'/> </sequence> <sequence> <element ref='p3p:REMEDIES'/> <element ref='p3p:EXTENSION' minOccurs='0' maxOccurs='unbounded'/> </sequence> </choice> </sequence> <attribute name='resolution-type' use='required'> <simpleType> <restriction base='string'> <enumeration value='service'/> <enumeration value='independent'/> <enumeration value='court'/> <enumeration value='law'/> </restriction> </simpleType> </attribute> <attribute name='service' type='anyURI' use='required'/> <attribute name='verification' type='string' use='optional'/> <attribute name='short-description' type='string' use='optional'/> </complexType> </element> <!-- ******** LONG-DESCRIPTION ******** --> <element name='LONG-DESCRIPTION'> <simpleType> <restriction base='string'/> </simpleType> </element> <!-- ************** IMG *************** --> <element name='IMG'> <complexType> <attribute name='src' type='anyURI' use='required'/> <attribute name='width' type='nonNegativeInteger' use='optional'/> <attribute name='height' type='nonNegativeInteger' use='optional'/> <attribute name='alt' type='string' use='required'/> </complexType> </element> <!-- ************ REMEDIES ************ --> <element name='REMEDIES'> <complexType> <sequence> <element ref='p3p:EXTENSION' minOccurs='0' maxOccurs='unbounded'/> <choice maxOccurs='unbounded'> <element name='correct' type='p3p:remedies-value'/> <element name='money' type='p3p:remedies-value'/> <element name='law' type='p3p:remedies-value'/> </choice> <element ref='p3p:EXTENSION' minOccurs='0' maxOccurs='unbounded'/> </sequence> </complexType> </element> <complexType name='remedies-value'/> <!-- *********** STATEMENT ************ --> <element name='STATEMENT'> <complexType> <sequence> <element ref='p3p:EXTENSION' minOccurs='0' maxOccurs='unbounded'/> <element name='CONSEQUENCE' minOccurs='0' type='string'/> <choice> <sequence> <element ref='p3p:PURPOSE'/> <element ref='p3p:RECIPIENT'/> <element ref='p3p:RETENTION'/> <element name='DATA-GROUP' type='p3p:data-group-type' maxOccurs='unbounded'/> </sequence> <sequence> <element name='NON-IDENTIFIABLE'/> <element ref='p3p:PURPOSE' minOccurs='0'/> <element ref='p3p:RECIPIENT' minOccurs='0'/> <element ref='p3p:RETENTION' minOccurs='0'/> <element name='DATA-GROUP' type='p3p:data-group-type' minOccurs='0' maxOccurs='unbounded'/> </sequence> </choice> <element ref='p3p:EXTENSION' minOccurs='0' maxOccurs='unbounded'/> </sequence> </complexType> </element> <!-- ************ PURPOSE ************* --> <element name='PURPOSE'> <complexType> <sequence> <element ref='p3p:EXTENSION' minOccurs='0' maxOccurs='unbounded'/> <choice maxOccurs='unbounded'> <element name='current' type='p3p:purpose-value'/> <element name='admin' type='p3p:purpose-value'/> <element name='develop' type='p3p:purpose-value'/> <element name='tailoring' type='p3p:purpose-value'/> <element name='pseudo-analysis' type='p3p:purpose-value'/> <element name='pseudo-decision' type='p3p:purpose-value'/> <element name='individual-analysis' type='p3p:purpose-value'/> <element name='individual-decision' type='p3p:purpose-value'/> <element name='contact' type='p3p:purpose-value'/> <element name='historical' type='p3p:purpose-value'/> <element name='telemarketing' type='p3p:purpose-value'/> <element name='other-purpose'> <complexType mixed='true'> <attribute name='required' use='optional' type='p3p:required-value'/> </complexType> </element> </choice> <element ref='p3p:EXTENSION' minOccurs='0' maxOccurs='unbounded'/> </sequence> </complexType> </element> <simpleType name='required-value'> <restriction base='string'> <enumeration value='always'/> <enumeration value='opt-in'/> <enumeration value='opt-out'/> </restriction> </simpleType> <complexType name='purpose-value'> <attribute name='required' use='optional' type='p3p:required-value' default='always' /> </complexType> <!-- *********** RECIPIENT ************ --> <element name='RECIPIENT'> <complexType> <sequence> <element ref='p3p:EXTENSION' minOccurs='0' maxOccurs='unbounded'/> <choice maxOccurs='unbounded'> <element name='ours'> <complexType> <sequence> <element ref='p3p:recipient-description' minOccurs='0' maxOccurs='unbounded'/> </sequence> </complexType> </element> <element name='same' type='p3p:recipient-value'/> <element name='other-recipient' type='p3p:recipient-value'/> <element name='delivery' type='p3p:recipient-value'/> <element name='public' type='p3p:recipient-value'/> <element name='unrelated' type='p3p:recipient-value'/> </choice> <element ref='p3p:EXTENSION' minOccurs='0' maxOccurs='unbounded'/> </sequence> </complexType> </element> <complexType name='recipient-value'> <sequence> <element ref='p3p:recipient-description' minOccurs='0' maxOccurs='unbounded'/> </sequence> <attribute name='required' use='optional' type='p3p:required-value'/> </complexType> <element name='recipient-description'> <complexType mixed='true'/> </element> <!-- *********** RETENTION ************ --> <element name='RETENTION'> <complexType> <sequence> <element ref='p3p:EXTENSION' minOccurs='0' maxOccurs='unbounded'/> <choice> <element name='no-retention' type='p3p:retention-value'/> <element name='stated-purpose' type='p3p:retention-value'/> <element name='legal-requirement' type='p3p:retention-value'/> <element name='indefinitely' type='p3p:retention-value'/> <element name='business-practices' type='p3p:retention-value'/> </choice> <element ref='p3p:EXTENSION' minOccurs='0' maxOccurs='unbounded'/> </sequence> </complexType> </element> <complexType name='retention-value'/> <!-- ************** DATA ************** --> <complexType name='data-group-type'> <sequence> <element ref='p3p:EXTENSION' minOccurs='0' maxOccurs='unbounded'/> <element name='DATA' type='p3p:data-in-statement' maxOccurs='unbounded'/> <element ref='p3p:EXTENSION' minOccurs='0' maxOccurs='unbounded'/> </sequence> <attribute name='base' type='anyURI' use='optional' default='http://www.w3.org/TR/P3P/base'/> </complexType> <complexType name='data-in-statement' mixed='true'> <sequence minOccurs='0' maxOccurs='unbounded'> <element ref='p3p:CATEGORIES'/> </sequence> <attribute name='ref' type='anyURI' use='required'/> <attribute name='optional' use='optional' default='no' type='p3p:yes_no'/> </complexType> <!-- ************** Schéma de données ************* --> <!-- *********** DATASCHEMA *********** --> <element name='DATASCHEMA'> <complexType> <choice minOccurs='0' maxOccurs='unbounded'> <element ref='p3p:DATA-DEF'/> <element ref='p3p:DATA-STRUCT'/> <element ref='p3p:EXTENSION'/> </choice> <attribute ref='xml:lang' use='optional'/> </complexType> </element> <element name='DATA-DEF' type='p3p:data-def'/> <element name='DATA-STRUCT' type='p3p:data-def'/> <complexType name='data-def'> <sequence> <element ref='p3p:CATEGORIES' minOccurs='0'/> <element ref='p3p:LONG-DESCRIPTION' minOccurs='0'/> </sequence> <attribute name='name' type='ID' use='required'/> <attribute name='structref' type='anyURI' use='optional'/> <attribute name='short-description' type='string' use='optional'/> </complexType> <!-- *********** CATEGORIES *********** --> <element name='CATEGORIES'> <complexType> <choice maxOccurs='unbounded'> <element name='physical' type='p3p:categories-value'/> <element name='online' type='p3p:categories-value'/> <element name='uniqueid' type='p3p:categories-value'/> <element name='purchase' type='p3p:categories-value'/> <element name='financial' type='p3p:categories-value'/> <element name='computer' type='p3p:categories-value'/> <element name='navigation' type='p3p:categories-value'/> <element name='interactive' type='p3p:categories-value'/> <element name='demographic' type='p3p:categories-value'/> <element name='content' type='p3p:categories-value'/> <element name='state' type='p3p:categories-value'/> <element name='political' type='p3p:categories-value'/> <element name='health' type='p3p:categories-value'/> <element name='preference' type='p3p:categories-value'/> <element name='location' type='p3p:categories-value'/> <element name='government' type='p3p:categories-value'/> <element name='other-category' type='string'/> </choice> </complexType> </element> <complexType name='categories-value'/> <!-- *********** EXTENSION ************ --> <element name='EXTENSION'> <complexType mixed='true'> <choice minOccurs='0' maxOccurs='unbounded'> <any minOccurs='0' maxOccurs='unbounded' processContents='skip'/> </choice> <attribute name='optional' use='optional' default='yes' type='p3p:yes_no'/> </complexType> </element> </schema>
Cet annexe contient le DTD pour les fichiers d'appel de politique P3P, pour les documents de politiques P3P et pour les documents de schéma de données P3P. Ce DTD PEUT servir à vérifier la validité des fichiers P3P (bien que certains fichiers valides puissent être rejetés dans la vérification contre le DTD). Le DTD est également disponible dans un fichier séparé à l'adresse URI http://www.w3.org/2002/01/P3Pv1.dtd.
<!-- *************** Entités *************** -->
<!ENTITY % URI "CDATA">
<!ENTITY % NUMBER "CDATA">
<!-- *********** Référence de politique *********** -->
<!-- ************** META ************** -->
<!ELEMENT META (EXTENSION*, POLICY-REFERENCES, POLICIES?, EXTENSION*)>
<!ATTLIST META xml:lang NMTOKEN #IMPLIED>
<!ATTLIST META xmlns CDATA #FIXED "http://www.w3.org/2002/01/P3Pv1">
<!-- ******* POLICY-REFERENCES ******** -->
<!ELEMENT POLICY-REFERENCES (EXPIRY?, POLICY-REF*, HINT*, EXTENSION*)>
<!-- *********** POLICY-REF *********** -->
<!ELEMENT POLICY-REF (INCLUDE*,
EXCLUDE*,
COOKIE-INCLUDE*,
COOKIE-EXCLUDE*,
METHOD*,
EXTENSION*)>
<!ATTLIST POLICY-REF
about %URI; #REQUIRED >
<!-- ************** HINT ************** -->
<!ELEMENT HINT EMPTY>
<!ATTLIST HINT
scope CDATA #IMPLIED
path CDATA #IMPLIED >
<!-- ************* EXPIRY ************* -->
<!ELEMENT EXPIRY EMPTY>
<!ATTLIST EXPIRY
max-age %NUMBER; #IMPLIED
date CDATA #IMPLIED >
<!-- ************ POLICIES ************ -->
<!ELEMENT POLICIES (EXPIRY?, DATASCHEMA?,
POLICY*)>
<!ATTLIST POLICIES xml:lang NMTOKEN #IMPLIED>
<!ATTLIST POLICIES xmlns CDATA #FIXED "http://www.w3.org/2002/01/P3Pv1">
<!-- ***** INCLUDE/EXCLUDE/METHOD ***** -->
<!ELEMENT INCLUDE (#PCDATA)>
<!ELEMENT EXCLUDE (#PCDATA)>
<!ELEMENT COOKIE-INCLUDE EMPTY>
<!ATTLIST COOKIE-INCLUDE
name CDATA #IMPLIED
value CDATA #IMPLIED
domain CDATA #IMPLIED
path CDATA #IMPLIED>
<!ELEMENT COOKIE-EXCLUDE EMPTY>
<!ATTLIST COOKIE-EXCLUDE
name CDATA #IMPLIED
value CDATA #IMPLIED
domain CDATA #IMPLIED
path CDATA #IMPLIED>
<!ELEMENT METHOD (#PCDATA)>
<!-- **************** Politique **************** -->
<!-- ************* POLICY ************* -->
<!ELEMENT POLICY (EXTENSION*,
TEST?,
ENTITY,
ACCESS,
DISPUTES-GROUP?,
STATEMENT+,
EXTENSION*)>
<!ATTLIST POLICY
name ID #REQUIRED
discuri %URI; #REQUIRED
opturi %URI; #IMPLIED
xml:lang NMTOKEN #IMPLIED>
<!-- ******** TEST ******** -->
<!ELEMENT TEST EMPTY>
<!-- ************* ENTITY ************* -->
<!ELEMENT ENTITY (EXTENSION*, DATA-GROUP, EXTENSION*)>
<!-- ************* ACCESS ************* -->
<!ELEMENT ACCESS (EXTENSION*,
(nonident
| all
| contact-and-other
| ident-contact
| other-ident
| none),
EXTENSION*)>
<!ELEMENT nonident EMPTY>
<!ELEMENT all EMPTY>
<!ELEMENT contact-and-other EMPTY>
<!ELEMENT ident-contact EMPTY>
<!ELEMENT other-ident EMPTY>
<!ELEMENT none EMPTY>
<!-- ************ DISPUTES ************ -->
<!ELEMENT DISPUTES-GROUP (EXTENSION*, DISPUTES+, EXTENSION*)>
<!ELEMENT DISPUTES (EXTENSION*,
( (LONG-DESCRIPTION, IMG?, REMEDIES?, EXTENSION*)
| (IMG, REMEDIES?, EXTENSION*)
| (REMEDIES, EXTENSION*) )?)>
<!ATTLIST DISPUTES
resolution-type (service | independent | court | law) #REQUIRED
service %URI; #REQUIRED
verification CDATA #IMPLIED
short-description CDATA #IMPLIED >
<!-- ******** LONG-DESCRIPTION ******** -->
<!ELEMENT LONG-DESCRIPTION (#PCDATA)>
<!-- ************** IMG *************** -->
<!ELEMENT IMG EMPTY>
<!ATTLIST IMG
src %URI; #REQUIRED
width %NUMBER; #IMPLIED
height %NUMBER; #IMPLIED
alt CDATA #REQUIRED >
<!-- ************ REMEDIES ************ -->
<!ELEMENT REMEDIES (EXTENSION*, (correct | money | law)+, EXTENSION*)>
<!ELEMENT correct EMPTY>
<!ELEMENT money EMPTY>
<!ELEMENT law EMPTY>
<!-- *********** STATEMENT ************ -->
<!ELEMENT STATEMENT (EXTENSION*,
CONSEQUENCE?,
((PURPOSE,RECIPIENT,RETENTION,DATA-GROUP+)|
(NON-IDENTIFIABLE,PURPOSE?,RECIPIENT?,RETENTION?,DATA-GROUP*)),
EXTENSION*)>
<!-- ********** CONSEQUENCE *********** -->
<!ELEMENT CONSEQUENCE (#PCDATA)>
<!-- ******** NON-IDENTIFIABLE ******** -->
<!ELEMENT NON-IDENTIFIABLE EMPTY>
<!-- ************ PURPOSE ************* -->
<!ELEMENT PURPOSE (EXTENSION*,
(current
| admin
| develop
| customization errata E3
| tailoring
| pseudo-analysis
| pseudo-decision
| individual-analysis
| individual-decision
| contact
| historical
| telemarketing
| other-purpose)+,
EXTENSION*)>
<!ENTITY % pur_att
"required (always | opt-in | opt-out) #IMPLIED">
<!ELEMENT current EMPTY>
<!ATTLIST current %pur_att;>
<!ELEMENT admin EMPTY>
<!ATTLIST admin %pur_att;>
<!ELEMENT develop EMPTY>
<!ATTLIST develop %pur_att;>
<!ELEMENT customization EMPTY>
<!ATTLIST customization %pur_att;>
<!ELEMENT tailoring EMPTY>
<!ATTLIST tailoring %pur_att;>
<!ELEMENT pseudo-analysis EMPTY>
<!ATTLIST pseudo-analysis %pur_att;>
<!ELEMENT pseudo-decision EMPTY>
<!ATTLIST pseudo-decision %pur_att;>
<!ELEMENT individual-analysis EMPTY>
<!ATTLIST individual-analysis %pur_att;>
<!ELEMENT individual-decision EMPTY>
<!ATTLIST individual-decision %pur_att;>
<!ELEMENT contact EMPTY>
<!ATTLIST contact %pur_att;>
<!ELEMENT profiling EMPTY>
<!ATTLIST profiling %pur_att;>
<!ELEMENT historical EMPTY>
<!ATTLIST historical %pur_att;>
<!ELEMENT telemarketing EMPTY>
<!ATTLIST telemarketing %pur_att;>
<!ELEMENT other-purpose (#PCDATA)>
<!ATTLIST other-purpose %pur_att;>
<!-- *********** RECIPIENT ************ -->
<!ELEMENT RECIPIENT (EXTENSION*,
(ours
| same
| other-recipient
| delivery
| public
| unrelated)+,
EXTENSION*)>
<!ELEMENT ours (recipient-description*)>
<!ELEMENT same (recipient-description*)>
<!ATTLIST same %pur_att;>
<!ELEMENT other-recipient (recipient-description*)>
<!ATTLIST other-recipient %pur_att;>
<!ELEMENT delivery (recipient-description*)>
<!ATTLIST delivery %pur_att;>
<!ELEMENT public (recipient-description*)>
<!ATTLIST public %pur_att;>
<!ELEMENT unrelated (recipient-description*)>
<!ATTLIST unrelated %pur_att;>
<!ELEMENT recipient-description (#PCDATA)>
<!-- *********** RETENTION ************ -->
<!ELEMENT RETENTION (EXTENSION*,
(no-retention
| stated-purpose
| legal-requirement
| indefinitely
| business-practices),
EXTENSION*)>
<!ELEMENT no-retention EMPTY>
<!ELEMENT stated-purpose EMPTY>
<!ELEMENT legal-requirement EMPTY>
<!ELEMENT indefinitely EMPTY>
<!ELEMENT business-practices EMPTY>
<!-- ************** DATA ************** -->
<!ELEMENT DATA-GROUP (EXTENSION*, DATA+, EXTENSION*)>
<!ATTLIST DATA-GROUP
base %URI; "http://www.w3.org/TR/P3P/base" >
<!ELEMENT DATA (#PCDATA | CATEGORIES)*>
<!ATTLIST DATA
ref %URI; #REQUIRED
optional (yes | no) "no" >
<!-- *********** DATA SCHEMA *********** -->
<!ELEMENT DATASCHEMA (DATA-DEF | DATA-STRUCT | EXTENSION)*>
<!ATTLIST DATASCHEMA xml:lang NMTOKEN #IMPLIED>
<!ATTLIST DATASCHEMA xmlns CDATA #FIXED "http://www.w3.org/2002/01/P3Pv1">
<!ELEMENT DATA-DEF (CATEGORIES?, LONG-DESCRIPTION?)>
<!ATTLIST DATA-DEF
name ID #REQUIRED
structref %URI; #IMPLIED
short-description CDATA #IMPLIED >
<!ELEMENT DATA-STRUCT (CATEGORIES?, LONG-DESCRIPTION?)>
<!ATTLIST DATA-STRUCT
name ID #REQUIRED
structref %URI; #IMPLIED
short-description CDATA #IMPLIED >
<!-- *********** CATEGORIES *********** -->
<!ELEMENT CATEGORIES (physical
| online
| uniqueid
| purchase
| financial
| computer
| navigation
| interactive
| demographic
| content
| state
| political
| health
| preference
| location
| government
| other-category)+>
<!ELEMENT physical EMPTY>
<!ELEMENT online EMPTY>
<!ELEMENT uniqueid EMPTY>
<!ELEMENT purchase EMPTY>
<!ELEMENT financial EMPTY>
<!ELEMENT computer EMPTY>
<!ELEMENT navigation EMPTY>
<!ELEMENT interactive EMPTY>
<!ELEMENT demographic EMPTY>
<!ELEMENT content EMPTY>
<!ELEMENT state EMPTY>
<!ELEMENT political EMPTY>
<!ELEMENT health EMPTY>
<!ELEMENT preference EMPTY>
<!ELEMENT location EMPTY>
<!ELEMENT government EMPTY>
<!ELEMENT other-category EMPTY>
<!-- *********** EXTENSION ************ -->
<!ELEMENT EXTENSION ANY>
<!ATTLIST EXTENSION
optional (yes | no) "yes" >
La grammaire formelle de P3P est donnée dans cette spécification en recourant à une version légèrement modifiée de [ABNF]. Voici une description simplifiée de la notation ABNF :
Les autres notations utilisées dans les productions :
Cette annexe décrit les objectifs qui ont présidé au développement du protocole P3P et elle recommande des directives
pour une utilisation responsable de cette technologie. Une version précédente a été publiée dans la note du W3C
Les principes directeurs de P3P
(http://www.w3.org/TR/NOTE-P3P10-principles).
Le projet de plateforme pour les préférences de confidentialité (P3P) a été conçu pour être flexible et pour gérer un ensemble divers de préférences d'utilisateurs, de politiques publiques, de politiques de fournisseur de services et d'applications. Cette flexibilité permettra d'utiliser P3P dans beaucoup de situations inédites que même les concepteurs n'avaient pas entrevues. Les principes directeurs de P3P ont été créés pour exprimer les intentions des membres du groupe de travail P3P au moment de la conception de cette technologie et pour suggérer l'utilisation la plus efficace de P3P en protégeant la vie privée de l'utilisateur et en développant sa confiance dans le Web. Afin de maintenir cette flexibilité, ce document n'exerce aucune contrainte envers l'une ou l'autre partie. Il donne plutôt des conseils concernant, premièrement, ce qu'on devrait faire pour rester dans la logique des concepteurs du protocole P3P et, deuxièmement, la manière de renforcer la confiance de l'utilisateur vis-à-vis des mises en œuvre P3P et des services Web. Le protocole P3P a pour but de protéger la vie privée sur le Web. Nous invitons les organisations, les individus, les concepteurs de politique et les sociétés utilisant P3P à suivre ces principes directeurs afin de réaliser cet objectif.
Le protocole P3P a été conçu pour encourager la confidentialité et la confiance sur le Web en permettant aux fournisseurs de services de divulguer leurs pratiques en matière de données et en permettant aux individus de prendre des décisions raisonnées pour la collecte et l'utilisation des informations personnelles les concernant. Les agents utilisateurs P3P agissent pour le compte des individus en vue de trouver un accord avec les fournisseurs de services sur la collecte et l'utilisation de ces informations personnelles. La confiance se construit sur une compréhension mutuelle et sur le respect de l'accord établi par chaque partie.
Les fournisseurs de services devraient entretenir la confiance et protéger la vie privée en appliquant, à leurs pratiques, les lois correspondantes et les principes de protection et de confidentialité des données. Voici une liste des principes et des directives de confidentialité qui ont documenté le développement de P3P et qui peut être utile aux personnes utilisant P3P :
En outre, les fournisseurs de services et les développeurs P3P devraient repérer les problèmes particuliers touchant à la vie privée des enfants et y apporter des réponses.
Les fournisseurs de services devraient fournir des notifications efficaces, en temps et en heure, de leurs pratiques en matière de données et les agents utilisateurs devraient fournir des outils efficaces qui permettent aux utilisateurs d'accéder à ces notifications et de prendre des décisions en fonction de celles-ci.
Les fournisseurs de services devraient :
Les agents utilisateurs devraient :
Les utilisateurs devraient pouvoir faire des choix raisonnables pour la collecte, l'utilisation et la divulgation d'informations personnelles. Les utilisateurs devraient garder le contrôle de leurs informations personnelles et pouvoir décider des conditions de leur divulgation.
Les fournisseurs de services devraient :
Les agents utilisateurs devraient :
Les fournisseurs de services devraient traiter les utilisateurs et leurs informations personnelles avec loyauté et intégrité. Ce point est capital pour la protection de la vie privée et le renforcement de la confiance.
Les fournisseurs de services devraient :
Les agents utilisateurs devraient :
Bien que le protocole P3P ne comporte aucun mécanisme de sécurité, il est prévu pour être employé avec des outils de sécurité. Les informations personnelles de l'utilisateur devraient toujours être protégées par des barrières de sécurité raisonnables en fonction de la sensibilité des données.
Les fournisseurs de services devraient :
Les agents utilisateurs devraient :
Cette spécification a été produite par le Groupe de Travail pour la spécification P3P. Ont participé à ce groupe de travail, présidé par Lorrie Cranor (AT&T), les personnes suivantes : Mark Ackerman (University of California, Irvine), Margareta Björksten (Nokia), Eric Brunner (Engage), Joe Coco (Microsoft), Brooks Dobbs (DoubleClick), Rajeev Dujari (Microsoft), Matthias Enzmann (GMD), Patrick Feng (RPI), Aaron Goldfeder (Microsoft), Dan Jaye (Engage), Marit Koehntopp (Privacy Commission of Land Schleswig-Holstein, Germany), Yuichi Koike (NEC/W3C), Yusuke Koizumi (ENC), Daniel LaLiberte (Crystaliz), Marc Langheinrich (NEC/ETH Zurich), Daniel Lim (PrivacyBank), Ran Lotenberg (IDcide), Massimo Marchiori (W3C/MIT/UNIVE), Christine McKenna (Phone.com, Inc.), Mark Nottingham (Akamai), Paul Perry (Microsoft), Jules Polonetsky (DoubleClick), Martin Presler-Marshall (IBM), Joel Reidenberg (Fordham Law School), Dave Remy (Geotrust), Ari Schwartz (CDT), Noboru Shimizu (ENC), Rob Smibert (Jotter Technologies Inc.), Tri Tran (AvenueA), Mark Uhrmacher (DoubleClick), Danny Weitzner (W3C), Michael Wallent (Microsoft), Rigo Wenning (W3C), Betty Whitaker (NCR), Allen Wyke (Engage), Kevin Yen (Netscape), Sam Yen (Citigroup), Alan Zausner (American Express).
Le Groupe de Travail pour la spécification P3P a été le dépositaire des travaux précédents des différents groupes de travail pour la spécification P3P. Le groupe de travail voudrait remercier les membres de ces groupes précurseurs pour leurs contributions (les affiliations indiquées sont celles des membres au moment de leur participation à chaque groupe de travail).
Le Groupe de Travail pour la mise en œuvre et le déploiement de P3P, présidé par Rolf Nelson (W3C) et 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).
Le Groupe de Travail pour la syntaxe de P3P, présidé par 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).
Le Groupe de Travail pour l'harmonisation du vocabulaire de P3P, présidé par 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, anciennement chez DG XV, European Commission), Ari Schwartz (Center for Democracy and Technology), Jonathan Stark (TRUSTe).
Le Groupe de Travail pour les protocoles et le transport des données de P3P, présidé par 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).
Le Groupe de Travail pour le vocabulaire de P3P, présidé par Lorrie Cranor (AT&T) : Mark Ackerman (W3C), Philip DesAutels (W3C), Melissa Dunn (Microsoft), Joseph Reagle (W3C), Upendra Shardanand (Firefly).
Le Groupe de Travail pour l'architecture de P3P, présidé par Martin Presler-Marshall (IBM) : Mark Ackerman (W3C), Lorrie Cranor (AT&T), Philip DesAutels (W3C), Melissa Dunn (Microsoft), Joseph Reagle (W3C).
Enfin, l'annexe 7 s'inspire de la note du W3C Les principes directeurs de P3P, dont les signataires sont : 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.).