A P3P Assurance Signature Profile

Draft 18-October-2000

This version:
Latest version:
Previous version:
Joseph Reagle <reagle@w3.org>
See Acknowledgements


This document specifies a P3P Assurance Signature Profile.

Status of this document

This document has no status what-so-ever. It is a very rough draft of the author that hasn't received any review. It is not intended to be a normative specification. Instead, it an captures the authors' thoughts on how applications might use the XML Signature specification to meet their requirements (defining signature semantics and algorithm profile) via the P3P application context.

Table of Contents

  1. Introduction
    1. Editorial Conventions
    2. Design Philosophy
    3. Versions, Namespaces and Identifiers
    4. Acknowledgements
  2. Overview and Examples
    1. Assurance Overview
    2. XML Signature Overview
    3. P3P-Policy Overview
  3. P3P Assurance
  4. XML Signature Profile
  5. P3P Policy
  6. Schema, Transforms, and Examples
  7. References
  8. Authors' Address

1.0 Introduction

This document specifies a P3P [P3P] Assurance Signature [XMLDSIG] Profile. Perhaps the best introduction to this specification is found within the introduction of its predecessors:

The Platform for Privacy Preferences Project (P3P) enables Web sites to express their privacy practices in a standard format that can be retrieved automatically and interpreted easily by user agents. P3P user agents will allow users to be informed of site practices (in both machine- and human-readable formats) and to automate decision-making based on these practices when appropriate. Thus users need not read the privacy policies at every site they visit.... It provides a way for a Web site to encode its data-collection and data-use practices in a machine-readable XML format known as a P3P policy.

(The excerpt from XML Signature also motivates why a XML Signature profile is necessary.)

XML Signature is a method of associating a key with referenced data (octets); it does not normatively specify how keys are associated with persons or institutions, nor the meaning of the data being referenced and signed. Consequently, while this specification is an important component of secure XML applications, it itself is not sufficient to address all application security/trust concerns, particularly with respect to using signed XML (or other data formats) as a basis of human-to-human communication and agreement. Such an application must specify additional key, algorithm, processing and rendering requirements.

The purpose of this specification if to specify the following:

[def:] P3P Assurance Signature Profile
(1) a definition of the assured semantic under its stated namespace and (2) a profile of XML Signature (constraints over algorithms, transforms, key types, etc.) in its application context.

An application's foresight with respect to permitting external signatures/semantics to be used in their application substantially affects the signatures' ease of use. This specification addresses a moderately difficult context in which a signature and its semantics must exist in a separate document.

1.1 Editorial and Conformance Conventions

For readability and brevity this document uses the term "signature(s)" to refer to XML Signatures and the application context is always presumed to be P3P. An understanding of [XMLDSIG] is necessary to understand this specification; understanding of [P3P] is optional though it contributes to this document's motivation.

This specification uses XML Schemas [XML-schema].

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this specification are to be interpreted as described in RFC2119 [KEYWORDS]:

"they MUST only be used where it is actually required for interoperation or to limit behavior which has potential for causing harm (e.g., limiting retransmissions)"

Consequently, capitalized keywords are used to unambiguously specify requirements over protocol and application features and behavior that affect the interoperability and security of implementations. These key words are not used (capitalized) to describe XML grammar; schema definitions unambiguously describe such requirements and we wish to reserve the prominence of these terms for the natural language descriptions of protocols and features.

1.2 Design Philosophy

The design philosophy and requirements of this specification are to:

  1. Define what it means for a P3P Policy to be assured via an XML Signature.
  2. Provide detached signatures for the P3P Policies and Assurances.
    1. Enveloping signatures MAY contain the P3P Policy Reference or Profile. This can be convenient in that all the files are included together, but this has the following two disadvantages: the Signature is the root element, and XPointer is required to select portions of the document.
    2. Enveloped signatures are prohibited by P3P's content model.
  3. Be concise and unambiguous.

The following issues still need to be addressed:

  1. It would be nice if the signature could be included within a P3P policy.
  2. Should this address the P3P Policy Reference File as well?
  3. Should I include the RDF tags as part of my schema definition?
  4. Calling these resulting signatures "P3P Assurance Signature Profile" is a mouthful!

1.3 Versions, Namespaces and Identifiers

The XML namespace [XML-ns] URI that MUST be used by implementations of this (dated) specification is:


1.4  Acknowledgements

The contributions of the following are gratefully acknowledged:

2.0 Overview and Examples

This section provides an overview of a P3P Assurance Signature Profile, an XML Signature, and a P3P-Policy.

2.1 Assurance Overview

The following is an XML instance of a P3P Assurance that describes a P3P-Policy as being assured via a detached signature. The assurances uses the RDF data-model and syntax to state that: A P3P Policy has the property of being assured.


<RDF xmlns="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
     <Description about="http://www.example.org/P3P-Policy.xml">
       <profile:Assured via="http://www.example.org/Signature.xml" />

2.2 XML Signature Overview

The following abbreviated Signature signs both the P3P-Policy, and the Assurance itself.


<Signature Id="P3Psig1" xmlns="http://www.w3.org/2000/09/xmldsig#">
    <Reference URI="http://www.example.org/P3P-Policy.xml">
        <Transform Algorithm="http://www.w3.org/TR/2000/WD-xml-c14n-20000907"/>
     <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
    <Reference URI="http://www.example.org/Assurance-Profile.xml">
        <Transform Algorithm="http://www.w3.org/TR/2000/WD-xml-c14n-20000907"/>
     <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
   <KeyInfo>KeyInfo of the Disputes Service</KeyInfo>

2.2 P3P-Policy Overview

The following abbreviated example describes the policy policies being assured, and uses the verification attribute to reference the profile.


<POLICY xmlns="http://www.w3.org/2000/09/15/P3Pv1"
  <DISPUTES resolution-type="independent"
   <IMG src="http://www.PrivacySeal.example.org/Logo.gif"
        alt="PrivacySeal's logo"/>
   <DATA ref="#dynamic.clickstream.clientip"/>
   <DATA ref="#dynamic.http.useragent"/>

3.0 P3P Assurance

The assurance semantic is:

[def:] Assured
the P3P DISPUTE service asserts that the P3P policy is accurate and that the P3P DISPUTE service commits to the enumerated REMEDIES.

The assurance content model permitts the P3P Policy and XML Signature to be referenced as external files, or as internal content.

Schema Definition:

<?xml version='1.0'?> 
<!DOCTYPE schema 
  SYSTEM 'http://www.w3.org/1999/XMLSchema.dtd' 

<schema targetNamespace='http://www.w3.org/2000/10/xmldsig-p3p-profile/' 

   <element name='Assured'> 
         <element ref='profile:P3P-Policy' minOccurs='0' />
         <element ref='profile:Signature' minOccurs='0' />
       <attribute name='via' type='URI'/> 
       <attribute name='Id' type='ID' use='optional'/> 

   <element name='P3P-Policy'> 
         <any namespace='http://www.w3.org/2000/10/18/P3Pv1'/>
       <attribute name='Id' type='ID' use='required'/> 

   <element name='Signature'> 
         <any namespace='http://www.w3.org/2000/09/xmldsig#'/>
       <attribute name='Id' type='ID' use='required'/> 


4.0 XML Signature Profile

A P3P Signature Profile signature is a valid signature [XMLDSIG] with the following REQUIRED constraints.

  1. The permissible CanonicalizationMethod is Canonical XML:
  2. The permissible SignatureMethods are DSA or RSA.
  3. The permissible DigestMethod   is SHA-1
  4. The permissible Transforms are:
    1. Canonical XML:
    2. P3P Statement to HTML/English XSLT: This specification provides a [XSLT] instance that transforms a P3P statement into an HTML page that uses English to describe that statement.
  5. The permissible KeyInfo
    1. DSAKeyValue or RSAKeyValue

Note: the authors welcome comments on how to make these constrains more realistic by offering a better defined application context and specific requirements/constraints. For instance, what would have to be done to make this a qualified electronic signature under the European Directive?

5.0 P3P Policy

The P3P Disputes verification attribute should be the URI of the assurance. No additional constraints or specification are made over [P3P], nor are any additional semantics introduced via this specification's namespace.

6.0 Schema, Transforms and Examples

XSLT P3P Statement to HTML Transform
This specification provides a [XSLT] instance that transforms a P3P statement into an HTML page that uses English to describe that statement.
P3P Assurance Signature Profile Schema

7.0 References

RFC2119 Key words for use in RFCs to Indicate Requirement Levels. S. Bradner. March 1997.
The Platform for Privacy Preferences 1.0 (P3P1.0) Specification. W3C Working Draft. Cranor, Langheinrich, Marchiori, Presler-Marshall, and Reagle, October 2000.
Resource Description Framework (RDF) Model and Syntax Specification. W3C Recommendation. Lassila and Swick. Febuary 1999.
XML-Signature Syntax and Processing. W3C Working Draft. Eastlake, Reagle, and Solo. September 2000.
Canonical XML. Working Draft. J. Boyer. September 2000.
Namespaces in XML Recommendation. T. Bray, D. Hollander, A. Layman. Janaury 1999.
XML Schema Part 1: Structures Working Draft. D. Beech, M. Maloney, N. Mendelshohn. September 2000.
XML Schema Part 2: Datatypes Working Draft. P. Biron, A. Malhotra. September 2000.
XSL Transforms (XSLT) Version 1.0. Recommendation. J. Clark. November 1999.

8. Authors' Address

Joseph M. Reagle Jr., W3C
Massachusetts Institute of Technology
Laboratory for Computer Science
NE43-350, 545 Technology Square
Cambridge, MA 02139
Phone: + 1.617.258.7621
Email: reagle@w3.org