Subject: [abfab] A proposal for dealing with EU data protection & identifiers

From: Josh Howlett <[email-masked]>
Date: Mon, 7 Mar 2011 21:15:51 +0000

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

---

From: Sam Hartman <[email-masked]>
Date: Mon, 07 Mar 2011 16:46:31 -0500

So, Josh, I'd like to confirm that one consequence of what you're saying
is that it would be entirely fine for an implementation to use NAIs
including the actual username and for the IDP to only accept the NAI if
the email address was correct?

I.E. if we don't mind shooting privacy in the head, we have an easy
solution already supported by the protocols involved.

I'm not recommending that approach, just trying to understand it.

---

From: Josh Howlett <[email-masked]>
Date: Mon, 7 Mar 2011 22:03:21 +0000

> the email address was correct?

I believe that is correct.

When I was discussing this with our regulatory person, I framed the question using a pseudonymous identifier by way of example (because that's how we normally think about these problems) but he strongly implied that the principle is equivalently applicable to other less privacy-preserving identifiers. The key point is that the IdP isn't releasing information -- which is the legislation's basic test -- only an opinion. However, I'll ask him to explicitly ack your example tomorrow.

Josh.

---

From: Klaas Wierenga <[email-masked]>
Date: Mon, 7 Mar 2011 23:16:19 +0100

Hmm, interesting....

I am picturing flows like:

- I think this is Sam, can you confirm?
- ok, is it Josh then?
Etc. Etc. ad nauseam

Klaas

Sent from my iPad

On Mar 7, 2011, at 11:03 PM, "Josh Howlett" <[email-masked]> wrote:

> _______________________________________________
> abfab mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/abfab

---

From: Sam Hartman <[email-masked]>
Date: Mon, 07 Mar 2011 18:09:27 -0500

>>>>> "Josh" == Josh Howlett <[email-masked]> writes:

    >> So, Josh, I'd like to confirm that one consequence of what you're
    >> saying is that it would be entirely fine for an implementation to
    >> use NAIs including the actual username and for the IDP to only
    >> accept the NAI if the email address was correct?

    Josh> I believe that is correct.

    Josh> When I was discussing this with our regulatory person, I
    Josh> framed the question using a pseudonymous identifier by way of
    Josh> example (because that's how we normally think about these
    Josh> problems) but he strongly implied that the principle is
    Josh> equivalently applicable to other less privacy-preserving
    Josh> identifiers. The key point is that the IdP isn't releasing
    Josh> information -- which is the legislation's basic test -- only
    Josh> an opinion. However, I'll ask him to explicitly ack your
    Josh> example tomorrow.

Does it matter whether the user has control over their machine?
I.E. is it OK for an employer to force their employees to install
moonshot clients that break their privacy?

---

From: Eliot Lear <[email-masked]>
Date: Tue, 08 Mar 2011 11:09:43 +0100

Josh,

First, I would like to understand more about the situation where the IdP
has neither a contract with the service provider nor with the federation
to which they both belong.  That is- what are the ad hoc circumstances?

Thanks,

Eliot

> IdP: "Confirm", "Deny", "Neither Confirm Nor Deny".

I suspect you would prefer a slightly different question and answer:

Acceptor: "Do you authorize the current user (whose credentials you will
verify or have verified)  to use my local identifier FOO"?
Answer: "Yes" / "no"

A "yes" answer might be accompanied additional information, as allowed
by policy.

---

From: Josh Howlett <[email-masked]>
Date: Tue, 8 Mar 2011 12:16:29 +0000

> 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.

Following further discussion, it turns out that life isn't quite so simple, which largely breaks my proposal and so I retract it.

However there is definitely value in the acceptor constructing the initiator name from data provided by the initiator, rather than the AAA server.

Josh.

---

From: "Cantor, Scott E." <[email-masked]>
Date: Tue, 8 Mar 2011 15:03:14 +0000

>to which they both belong.  That is- what are the ad hoc circumstances?

The contract with the federation doesn't generally address release of data
to anybody, so it doesn't address liability of the IdP for doing so.

The canonical circumstance is any collaboration across a pair of
universities.

If we can't figure out how to address that problem with federation, it
will get addressed by Google and our users will just ignore all those
regulations.

-- Scott

---

From: "Henry B. Hotz" <[email-masked]>
Date: Tue, 8 Mar 2011 09:28:30 -0800

> 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.

To the contrary, I believe that solutions which satisfy not merely the legal requirements but also maximize the user's privacy are very broadly of interest.

------------------------------------------------------
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
[email-masked], or [email-masked]

---

From: Josh Howlett <[email-masked]>
Date: Wed, 9 Mar 2011 08:30:35 +0000

> To the contrary, I believe that solutions which satisfy not merely the
> legal requirements but also maximize the user's privacy are very
> broadly of interest.

I do hope so. Is there anyone who would be interested in working on defining privacy and data protection requirements for ABFAB?

Josh.

---

From: Eliot Lear <[email-masked]>
Date: Wed, 09 Mar 2011 10:05:14 +0100

Josh,
> I do hope so. Is there anyone who would be interested in working on defining privacy and data protection requirements for ABFAB?

Goodness I would hope that Hannes will have given us a head start on
that in the forthcoming Architecture doc.

Eliot

---

From: Josh Howlett <[email-masked]>
Date: Wed, 9 Mar 2011 10:02:48 +0000

> that in the forthcoming Architecture doc.

Definitely! What I'd like to do is define a set of requirements derived from the applicable legislation that we can compare against the privacy considerations that Hannes has already enumerated in architecture document. So this would be a complementary exercise intended to build confidence that the architecture will satisfy these data protection regimes.

Josh.