[privacydir] [abfab] A proposal for dealing with EU data protection & identifiers (fwd)
Lucy Lynch <llynch@civil-tongue.net> Mon, 07 March 2011 21:35 UTC
Return-Path: <llynch@civil-tongue.net>
X-Original-To: privacydir@core3.amsl.com
Delivered-To: privacydir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix)
with ESMTP id 3E92F3A682C for <privacydir@core3.amsl.com>;
Mon, 7 Mar 2011 13:35:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.026
X-Spam-Level:
X-Spam-Status: No, score=-102.026 tagged_above=-999 required=5 tests=[AWL=0.573,
BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com
[127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lJFemKll8aFg for
<privacydir@core3.amsl.com>; Mon, 7 Mar 2011 13:35:23 -0800 (PST)
Received: from hiroshima.bogus.com (hiroshima.bogus.com [IPv6:2001:418:1::80])
by core3.amsl.com (Postfix) with ESMTP id DC3103A6819 for
<privacydir@ietf.org>; Mon, 7 Mar 2011 13:35:22 -0800 (PST)
Received: from hiroshima.bogus.com (localhost [127.0.0.1]) by
hiroshima.bogus.com (8.14.3/8.14.3) with ESMTP id p27LaaMD049097
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for
<privacydir@ietf.org>;
Mon, 7 Mar 2011 13:36:36 -0800 (PST) (envelope-from llynch@civil-tongue.net)
Received: from localhost (llynch@localhost) by hiroshima.bogus.com
(8.14.3/8.14.3/Submit) with ESMTP id p27LaZvP049093 for <privacydir@ietf.org>;
Mon, 7 Mar 2011 13:36:35 -0800 (PST) (envelope-from llynch@civil-tongue.net)
Date: Mon, 7 Mar 2011 13:36:35 -0800 (PST)
From: Lucy Lynch <llynch@civil-tongue.net>
X-X-Sender: llynch@hiroshima.bogus.com
To: privacydir@ietf.org
Message-ID: <alpine.BSF.2.00.1103071336180.38126@hiroshima.bogus.com>
User-Agent: Alpine 2.00 (BSF 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Subject: [privacydir] [abfab] A proposal for dealing with EU data protection &
identifiers (fwd)
X-BeenThere: privacydir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "Privacy Directorate to develop the concept of privacy considerations
for IETF specifications and to review internet-drafts for privacy
considerations." <privacydir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/privacydir>,
<mailto:privacydir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/privacydir>
List-Post: <mailto:privacydir@ietf.org>
List-Help: <mailto:privacydir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/privacydir>,
<mailto:privacydir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 07 Mar 2011 21:35:25 -0000
forwarded for your information - Lucy ---------- Forwarded message ---------- Date: Mon, 7 Mar 2011 21:15:51 +0000 From: Josh Howlett <Josh.Howlett@ja.net> To: "abfab@ietf.org" <abfab@ietf.org> Cc: Josh Howlett <Josh.Howlett@ja.net> Subject: [abfab] A proposal for dealing with EU data protection & identifiers I admit that this is likely to be something of a minority interest. It's hard to get people excited about privacy and data protection law and identifiers. However, I claim that it this an important problem to solve. Unfortunately, understanding this requirement requires some knowledge of the implications of EU data protection law on federated identity before. I provide a brief summary below, before setting out my proposal. ** Problem description ** Very frequently, a relying party will want a unique identifier for a user. Such identifiers are very useful for recognition (knowing that a user is the same as one seen previously) and accountability (so that abuse, etc, can be tracked). Within federations today, it is common for identity providers to release these identifiers to relying parties. These identifiers may name a user explicitly (e.g. taking a value of an email address), but other identifiers can name a user pseudonymously (e.g. by taking an opaque value) to improve privacy. The release of these identifiers often have legal implications. The EU data protection regime treats all such identifiers as 'personally identifiable information', because it can be linked directly or indirectly to a person. One of the practical consequences of this (within the EU) is that it is highly desirable to have a legal contract between the issuer and consumer of an identifier. By default the IdP will be responsible for all misuse of the identifier by the RP, with civil and/or criminal implications depending on the EU member state in question. A contract is not an onerous requirement if -- for example -- the RP is formally providing some kind of service or content to the IdP organisation; there will generally be a contract to control that business relationship regardless. However, increasingly a user may want access to an RP that his IdP has no relationship with; and often that RP will want an identifier. Unfortunately, addressing the general case (pairwise contracts between all IdPs and all SPs in federation) creates a legal scalability problem that people involved in EU federation policy and governance get fairly exercised about. User consent is sometimes invoked as a mechanism for addressing identifier release to 'unknown' RPs, but in general it's not a useful strategy within the EU (though it might be fine in other jurisdictions). There are other approaches that use umbrella legal structures to control the risk, but EU member states take different views on the appropriateness of these structures, and so they are not generally universally applicable. In summary it would be ideal if the RP could be provisioned with an identifier without invoking the EU data protection regime, at all. ** Proposal ** It turns out that the EU data protection regime does not have any opinions about an IdP either confirming or denying if an identifier is associated with a user. Thus, it appears that it is possible to entirely sidestep the data protection regime by having the RP pose the question "please confirm that it is reasonable for this user to claim the identifier FOO", rather than the more conventional request "please provide an identifier for this user". I don't know if this is true for other jurisdictions other than the EU. If anyone else also has access to lawyers with DP knowledge of other jurisdictions, it would be wonderful if you could bounce this approach off them. I'm currently working on the assumption that, because the EU DP regime is one of the more difficult (or so I understand), it should work elsewhere, but that's purely an assumption. The more educated opinions, the better. Therefore, my proposal is that we should seek to model identifier assignment using a 'confirmation' model, rather than the conventional 'release' model. I believe the semantics of the identifier confirmation model should be: Acceptor: "Is the identifier FOO associated with a user that you know about?". IdP: "Confirm", "Deny", "Neither Confirm Nor Deny". The value of FOO would be asserted by the initiator to the acceptor. It would take an opaque value that the IdP can verify is only likely to have been generated by a user that it knows about. The value should generally be permanent, but it should also be possible to change it on a per-acceptor basis if necessary. We have some existing components in the ABFAB toolbox that I believe we can re-use to avoid creating significant work. Sam and I bounced around a few ideas earlier this morning, but as a first step we thought it would be useful to know what the WG thinks of this as a general strategy. Josh. JANET(UK) is a trading name of The JNT Association, a company limited by guarantee which is registered in England under No. 2881024 and whose Registered Office is at Lumen House, Library Avenue, Harwell Oxford, Didcot, Oxfordshire. OX11 0SG _______________________________________________ abfab mailing list abfab@ietf.org https://www.ietf.org/mailman/listinfo/abfab