[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