Refeds


Subject RE: draft charge, refeds working group on attribute release
From Andrew Cormack <Andrew.Cormack@xxxxxx>
Date Mon, 11 Jul 2011 16:36:57 +0000

Agreed. It seems to me inevitable that if you have complicated (dynamic, even) authorisation rules, then you're going to have a complicated UI :(

On the question of one-of-many attributes, radiobuttons might help, but for anything more complex than that you're beyond my (1999-era) knowledge of HTML ;)

Andrew

> -----Original Message-----
> From: Robin Wilton [mailto:racingsnake@xxxxxxxxxxx]
> Sent: 11 July 2011 17:33
> To: Rhys Smith (Cardiff); David Chadwick
> Cc: Andrew Cormack; REFEDS list
> Subject: Re: [refeds] draft charge, refeds working group on attribute
> release
> 
> Well, not necessarily the principal's name... but the underlying point
> is that the release requirements are a function of the relationship
> between the data subject and the requester (and othe rcontextual
> variables) - so even if it isn't the name, you need to be able to base
> the release decision on enough data to establish what that relationship
> is.
> 
> R
> 
> On Mon, 11 Jul 2011 16:40 +0100, "Rhys Smith" <smith@xxxxxxxxxxxxx>
> 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
> > ---------------------------------------------------------------------
> -
> >
> Robin Wilton
> 
> +44 (0)705 005 2931