Refeds


Subject RE: draft charge, refeds working group on attribute release
From Andrew Cormack <Andrew.Cormack@xxxxxx>
Date Thu, 7 Jul 2011 10:36:35 +0000

Been away working for the EC for a few days, so trying to catch up a number of points in one mail...

> -----Original Message-----
> From: Mikael Linden [mailto:Mikael.Linden@xxxxxx]
> Sent: 01 July 2011 15:29
> To: Tom Scavo
> Cc: REFEDS list
> Subject: RE: [refeds] draft charge, refeds working group on attribute
> release
> 
> me>> - the text in the button is either "I consent to attribute
> release" or
> me>> "I am informed on the attribute release"
> 
> Tom> We need to figure out how to implement and deploy these two
> Tom>notions independently since one may be easier than the other.
> 
> The problem we found is that who decides and how if attribute release
> to an SP is necessary or not.
> In the eduGAIN data protection good practice profile[1] we ended up to
> a solution that
> 1. The SP makes a proposal, by adding an element to its SAML metadata:
>    <md:Extensions>
>       <mddp:DataProtectionProperties>
>          <mddp:LegalGrounds>consent</mddp:LegalGrounds>
>       </mddp:DataProtectionProperties>
>    </md:Extensions>
> 2. Based on the element, the IdP decides if it's consent or necessity
> 3. When the attribute release is taking place, a consent module shows
> either of the two texts to the user

That's close, but whether the release of an attribute is based on consent or necessity may be different for different attributes to the same SP. For example if I'm trying to get authorised to a journal for which my organisation has a site licence then ePSA is necessary (that's what authorises me), but the release of an e-mail address to let me receive updates isn’t necessary so has to be based on consent. Conversely if I'm talking to a collaboration tool where I am authorised based on my real identity then an e-mail address strongly linked to me is necessary but there may be some other attributes that are consent-based. I have an interface in mind, but have never had time to do a mock-up to illustrate a write-up of how it might work. It's a list of attributes that the SP is able to use, very similar to the ones used by uApprove, etc. but with checkboxes next to the ones that are not necessary for the service to work (therefore can only be released based on consent). Incidentally if the attributes that may be released can be determined before login (see below) then logically I think this information can be presented on the same page as the login box, so it doesn't force the user into any extra interaction. No additional page, which seems to be the common complaint about the WAYF. If anyone would like to make me a picture then I'd be happy to provide a longer write-up on my blog where I can include references to the bits of law that make it work...

And on "necessary", in the eduGAIN discussions I was thinking of "necessary for the purpose of a contract", i.e. the education or employment one. That implied that the IdP had to ask two questions:
a) is this attribute necessary for the service to work? and
b) is access to the service necessary for the user's employment/education?
Clearly the answer to (b) could vary from one user to another.

However some lawyers Josh spoke to pointed out that we could also use "necessary for the legitimate interests of a third party" (i.e. the Service Provider). That has slightly more complex legal requirements, because it has the caveat "...and not overridden by the fundamental rights of the user". So this approach still has two questions:
a) is this attribute necessary for the service to work? and
b) does release of the attribute infringe the user's fundamental rights?
That has the benefit that for any given service and attribute the answers to (a) and (b) should be the same for all users. However it does require the IdP to consider whether attribute release infringes the user's rights, which probably means that it won't be possible to have a blanket rule of "directory information OK", because (as above) releasing my e-mail address to a research collaboration tool probably doesn't infringe my rights, whereas releasing my e-mail to a commercial site who will use it to spam me definitely does. So IdPs are still going to have to think per SP, or perhaps per group of similar SPs (e.g. academic journals are likely to look pretty similar).

And it is the IdP who has to make the decisions on (a) and (b). The "processing" that is being done based on necessity or consent is the act of releasing to the SP attributes that the IdP has previously obtained from the user. The SP can try to persuade the IdP which attributes are necessary - indeed I'd hope that that negotiation process itself might result in moving to less privacy-invasive attributes - but it's the IdP's decision to make. And yes, if that decision is ever challenged (most likely if harm resulted from it, e.g. because the SP misused or lost it) then legal people would probably review whether the IdP's decision to release was indeed reasonable, and include them in any liability claim if it wasn't. In UK law, at least, the question would be whether the decision was reasonable, not whether hindsight showed it was factually correct (itself a shifty concept). But an injured user could also make the same claim that they had been "forced" to consent to attribute release (there are UK cases where employers forced employees to consent to disclosure of criminal records checks, and the employer rarely wins). So you may bump into lawyers either way.

The fact that it's the IdP's responsibility delegating that task to someone who manages ARPs for them, effectively the service that WAYF.DK and (I think) FEIDE offer, or various companies operating outsourced IdPs in the UK. Or, as I've mentioned before, I could conceive of a service that just negotiated with SPs and provided appropriate ARPs to subscribing IdPs through some trusted technological channel. But that delegating does involve legal and operational risks for both parties (see the discussion on who decides whether it's necessary), so I'd expect them to want a formal contract covering it, and probably payment to the delegated operator too.

> [1] See my TNC2011 slides for details:
> https://tnc2011.terena.org/core/presentation/40
> 
> Peter>So, Mikael, are you in fact arguing that REFED[Ss] indeed
> Peter>needs to tackle the problem of consent overuse now -- and I
> Peter>thought the problem was that consent was not available widely
> Peter>enough even in those cases where it would be desirable and
> Peter>justified (and legally required)?
> 
> We probably often use the word "consent" to actually mean "consent or
> necessity". Technically, one implementation ("consent module") could
> cover them both.
> If the above solution gets support, the next step would be having it
> implemented in common SAML IdPs' "consent modules".

I'm sorry to keep banging on about not calling something consent when it isn't. But if you do that then you risk legislators and regulators believing you and regulating you for what you say rather than what you do. And in a world where they are saying things like "use consent as a last resort" (UK Information Commissioner) and "crack down on over-use of consent" (EC Commissioner), that could get very ugly. Whereas if you use the right terms for what you actually do then you could be recognised as leading good practice.

It's the same reason as I've kept telling people not to describe eduroam as an open network, BTW, which seems to have worked out very nicely for David ;)

Andrew

> Mikael



--
Andrew Cormack, Chief Regulatory Adviser, JANET(UK)
Lumen House, Library Avenue, Harwell, Didcot. OX11 0SG UK
Phone: +44 (0) 1235 822302
Blog: http://webmedia.company.ja.net/edlabblogs/regulatory-developments/

JANET, the UK's education and research network

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 Science and Innovation Campus, Didcot, Oxfordshire. OX11 0SG