This document specifies a P3P Assurance Signature Profile.
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.
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:
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.
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.
The design philosophy and requirements of this specification are to:
Signatureis the root element, and XPointer is required to select portions of the document.
The following issues still need to be addressed:
The XML namespace [XML-ns] URI that MUST be used by implementations of this (dated) specification is:
The contributions of the following are gratefully acknowledged:
This section provides an overview of a P3P Assurance Signature Profile, an XML Signature, and a P3P-Policy.
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.
<profile:Assured via="http://www.example.org/Signature.xml" />
The following abbreviated Signature signs both the P3P-Policy, and the Assurance itself.
<KeyInfo>KeyInfo of the Disputes Service</KeyInfo>
The following abbreviated example describes the policy policies
being assured, and uses the
verification attribute to
reference the profile.
The assurance semantic is:
DISPUTE serviceasserts that the P3P policy is accurate and that the P3P
DISPUTE servicecommits to the enumerated
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/' version='0.1' xmlns='http://www.w3.org/2000/10/XMLSchema' xmlns:profile='http://www.w3.org/2000/10/xmldsig-p3p-profile/' elementFormDefault='qualified'> <element name='Assured'> <complexType> <all> <element ref='profile:P3P-Policy' minOccurs='0' /> <element ref='profile:Signature' minOccurs='0' /> </all> <attribute name='via' type='URI'/> <attribute name='Id' type='ID' use='optional'/> </complexType> </element> <element name='P3P-Policy'> <complexType> <sequence> <any namespace='http://www.w3.org/2000/10/18/P3Pv1'/> </sequence> <attribute name='Id' type='ID' use='required'/> </complexType> </element> <element name='Signature'> <complexType> <sequence> <any namespace='http://www.w3.org/2000/09/xmldsig#'/> </sequence> <attribute name='Id' type='ID' use='required'/> </complexType> </element> </schema>
A P3P Signature Profile signature is a valid signature [XMLDSIG] with the following REQUIRED constraints.
CanonicalizationMethodis Canonical XML:
SignatureMethods are DSA or RSA.
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?
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
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