Refeds


Subject Re: draft charge, refeds working group on attribute release
From David Chadwick <d.w.chadwick@xxxxxxxxxx>
Date Tue, 12 Jul 2011 17:53:10 +0100

Actually there is a way around this one. You gather information from the user on a publicly accessible page, before asking for confirmation from the IDP(s) as assertions.

Real life e.g. When buying tickets from theTrainLine.com you can say you have a discount card (student, OAP etc) and it will deduct the price from your ticket before asking for any assertions to prove it. Therefore the SP can tailor its attribute requirements to the user based on what the user self-asserts initially


regards

David


On 11/07/2011 16:40, Rhys Smith wrote:
There's also the case where attribute release requirements might change depending on the principal involved - e.g. you might have the case where if the principal is a certain type of member of the organisation (say staff vs student, or someone under 16 vs over 16) then certain attributes could change from a must to optional, or from must to absolutely must not...

In which case, you can only display a release page after you've first gathered the principal name - i.e. it couldn't be on the same page as the login page. On a subsequent page would be fine for this case. Except that the more steps we put in front of the user, the more likely they're going to get annoyed...

R.


On 11 Jul 2011, at 16:25, David Chadwick wrote:

Hi Andrew

this is fine as a first step of several. Its probably OK for 80% of current users.

Things you might like to consider next are:

i) increasing privileges, where a site has more secure resources that a user navigates to after the basic level of access has been granted

ii) user choice, where a user has several different ways of fulfilling a site's attribute requirements (e.g. several email addresses)

iii) attribute aggregation, where a site needs attributes from more than one IdP.

regards

David


On 11/07/2011 13:13, Andrew Cormack wrote:
Further to my last mail, I've now done a very crude mock-up of a possible attribute release notice. Visual appeal is minimal, but I hope it makes clearer what I'm trying to get at.
http://webmedia.company.ja.net/edlabblogs/regulatory-developments/2011/07/11/explaining-attribute-release/

Comments welcome, either on the blog or here

Andrew

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


-----Original Message-----
From: Andrew Cormack [mailto:Andrew.Cormack@xxxxxx]
Sent: 07 July 2011 11:37
To: Mikael Linden; Tom Scavo
Cc: REFEDS list
Subject: RE: [refeds] draft charge, refeds working group on attribute
release

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

--

*****************************************************************
David W. Chadwick, BSc PhD
Professor of Information Systems Security
School of Computing, University of Kent, Canterbury, CT2 7NF
Skype Name: davidwchadwick
Tel: +44 1227 82 3221
Fax +44 1227 762 811
Mobile: +44 77 96 44 7184
Email: D.W.Chadwick@xxxxxxxxxx
Home Page: http://www.cs.kent.ac.uk/people/staff/dwc8/index.html
Research Web site: http://www.cs.kent.ac.uk/research/groups/iss/index.html
Entrust key validation string: MLJ9-DU5T-HV8J
PGP Key ID is 0xBC238DE5

*****************************************************************

--
----------------------------------------------------------------------
Dr Rhys Smith                                   e: smith@xxxxxxxxxxxxx
Engineering Consultant: Identity&  Access Management  (GPG:0xDE2F024C)
Information Services,
Cardiff University,                            t: +44 (0) 29 2087 0126
39-41 Park Place, Cardiff,                     f: +44 (0) 29 2087 4285
CF10 3BB, United Kingdom.                      m: +44 (0) 7968 087 821
----------------------------------------------------------------------



--

*****************************************************************
David W. Chadwick, BSc PhD
Professor of Information Systems Security
School of Computing, University of Kent, Canterbury, CT2 7NF
Skype Name: davidwchadwick
Tel: +44 1227 82 3221
Fax +44 1227 762 811
Mobile: +44 77 96 44 7184
Email: D.W.Chadwick@xxxxxxxxxx
Home Page: http://www.cs.kent.ac.uk/people/staff/dwc8/index.html
Research Web site: http://www.cs.kent.ac.uk/research/groups/iss/index.html
Entrust key validation string: MLJ9-DU5T-HV8J
PGP Key ID is 0xBC238DE5

*****************************************************************