- From: Ruediger Grimm <grimm@darmstadt.gmd.de>
- Date: Mon, 21 Aug 2000 11:19:22 +0200
- To: "Joseph M. Reagle Jr." <reagle@mit.edu>
- CC: rosnagel@uni-kassel.de, www-p3p-public-comments@w3.org
Hi Joseph, thank you for going into this so deeply. We need this kind of discussion in order to open our minds outside of our German/European legal horizon. I will meet Lorry Cranor and Jazon Catlett in Kiel next week for the summer workshop at Marit Koehntopp's privacy protection offices (or how ever the official name is) of Schleswig-Holstein. "Joseph M. Reagle Jr." wrote: > Thank you for the explainations Rüdiger! > > At 18:41 8/8/2000 +0200, Ruediger Grimm wrote: > >... > >Our point is to associate a user CONSENT or a server POLICY > >with an electronic signature in order to make it authentic. If the consent > >is to be signed by a person who wants to remain unidentified, the > >person would use a persona signature (a "pseudonym" as the related > >acts on data protection and signature call it). > > So the text above, "the creator can be identified" refers to the service, > and not the user? Regardless, even a requirement for pseudonymous signatures > seems aggresive. P3P can certainly employ the functionality of XML Signature > [1], however the TDDSG then seems to presume a massively deployed and usable > signature and key infrastructure. I don't think this is likely any time > soon. (Even if I was peronally given the ability to use a key to sign > contracts or purchase orders on-line today, as a user, I would refuse it > because of other consumer protection concerns.) Regardless, P3P+XMLSignature > is technically capable of meeting this requirement. > > [1] http://www.w3.org/Signature/ You are absolutely right. The requirement is aggressive and technologically not yet feasible. The requirement is made by law-makers who know that other (German) law about digital signatures but who do not know the technical status of digital signatures. Of course, XML-DSig is the right technology to solve this problem one day. P3P is rising the authentication problem: P3P is right to shift this problem into the future. Anyway, we have to make this problem explicit in our articles on privacy technology. > >... > >If so: the German act does require this association because there should > >never be an indirection with the reason for data procession (or storage) > >of this type: > >"we have stored your personal data because our privacy statement is > >similar to the privacy statement of another organisation which has stored > >the data with your explicit consent": this would open an endless route of > >data transfer out of control of the user. > > I still don't follow. Is your bad case the following: if a site A says they > give the data to sites that have similar practices (such as those that don't > use it for marketing) including site B. Site B has similar practices (no > marketing, etc.) also gives it to site C? This could go on for a while. But > the goal is to provide the use with the assurance that if they don't want > marketing, they won't get marketing, and to give them a sense of the scope > of distribution, not a complete audit trail (which I think is infeasible). > What is the alternative and how does it prevent this scenario? The rules just prevent transitivity: a user would agree to transfer data to a service A. The user can also allow service A to transfer the date further to services B, C, D (but no others) for the puropse of (B: outsourced billing, C: market research, D: making sales offers to the user). Any other service who would like to get those user data from A would have to ask the user first. Of course, the user could also allow the service A to "transfer the user data to anyone A wants to, under the restriction that..." But this would be rather an exceptional case. Ths standard case is: explicit recipients for excplicit purposes. This is one of the strict rules of the German (and European) privacy protection laws. This rationale behind this is: the strong binding between data and the puropse of their use as a basic principle of privacy protection. Best greetings --- Ruediger
Received on Monday, 21 August 2000 05:20:12 UTC