- From: Schutzer, Daniel <schutzerd@citigroup.com>
- Date: Wed, 1 Jan 2003 07:26:41 -0500
- To: Giles Hogben <giles.hogben@jrc.it>, public-p3p-ws@w3.org, "'Durkee, Steve (CITIC)'" <steve.durkee@citicorp.com>
I agree with the problem defined in this work statement but am concerned that the recommended solution may be costly to implement and may impose performance issues. As there are other ways the same problem could be addressed; e.g. voluntary submittal of an organizations privacy policies, by the responsible organization to a publically maintained, or neutral third party, where an archive is maintained. Accordingly, I recommend that the solution allow for a variety of technical solutions, to be proposed and implemented that could address these problems, and time and implementation success could occur and determine which technical solutions prevail - we could address what aspects of the emerging dominant technical solutions need to be standardized upon in order to assure interoperability at that time. Dan Schutzer 212 559 1876 schutzerd@citigroup.com -----Original Message----- From: Giles Hogben [mailto:giles.hogben@jrc.it] Sent: Friday, December 13, 2002 8:34 AM To: public-p3p-ws@w3.org Subject: Future work proposal P3P - area 13 (XML Dig Sig) XML signed policy specification. (Item 13) ------------------------------------------ ------------------------------------------ Purpose: -------- A serious problem for P3P is that if a company's practices contravene its stated privacy policy, there is little technical or legal framework to prove that a company made the statements, which existed on its server at a given time. I.e. it is too easy for a company to repudiate its policy statements. While P3P does increase the level of trust felt by consumers by providing more transparent and unambiguous information, it does not however provide any assurance as to the authenticity and integrity of this information. The aim of this item is to provide a watertight route of legal recourse and thereby to increase trust in consumers. Probably the biggest obstacle in achieving these objectives is in driving the adoption of any measures taken. However, a prerequisite to this is to provide hooks within the P3P standard by which signed policies may be referenced, validated and later used as legal evidence. Scope: ------ Joseph Reagle of W3C has already gone some way towards outlining the detail of this solution and the solution would build on the document "A P3P Assurance Signature Profile". Building on this, the requirements for the P3P specification are as follows: 1. A mechanism for locating a signed version of a policy within a standard P3P policy. It has been suggested that the verification attribute should be used to identify the location of the signed policy. However it may be valuable to create another attribute so that user agents may easily identify the need to verify a signature. In any case, it needs to be clearly specified within the spec document where the signed version of a particular policy should be specified. 2. A similar element needs to be created within PRF files to verify the binding to the policy. This should be optional but recommended (a SHOULD) where a signed policy is referenced. 3. A full specification for the format of XML signed policies such as that specified within Reagle's P3P assurance profile document and Giles Hogben, Tom Jackson, Marc Wilikens (Joint Research Centre of the EC, I). A fully compliant research implementation of the P3P standard for privacy protection: experiences and recommendations There is little further work necessary. 4. If possible a sample tool for creating signed policies. 5. Description of verification process for user agents. The problem of how to automate this should be visited. For example if a certificate is provided for a domain, which does not match the domain of the signed policy, what should the agent do - should there be a checksum repository to help user agents verify certificates? 6. An addition to the APPEL specification so that signatures may be required under certain circumstances (e.g. "signaturerequired" attribute in a rule). Resources: ---------- The JRC has already developed a prototype specification for this functionality. This specification will be used to create a demonstrator module to be integrated within the JRC proxy architecture. Further resources for integrating this into the P3P specification can also be provided by the JRC. Time Frame: ----------- It is expected that the development of the architecture, specification and demonstrator will be finished by January 2004. _____________________________________________ Giles Hogben TP267 CyberSecurity Unit Institute for the Protection and Security of the Citizen (IPSC) European Commission - Euratom Centro Comune di Ricerca Via Enrico Fermi 1 21020 Ispra, Italy
Received on Wednesday, 1 January 2003 07:27:27 UTC