Subject Re: draft charge, refeds working group on attribute release
From David Simonsen <david@xxxxxxx>
Date Fri, 1 Jul 2011 16:05:10 +0200

On Jul 1, 2011, at 3:43 PM, Ingrid Melve wrote:
> On 01.07.2011 12:23, Leif Johansson wrote:
>> On 07/01/2011 12:19 PM, Mikael Linden wrote:
>>>> Not at all. Here is why: public entities that recieve the 
>>>> social security number as part of their duties/business 
>>>> may do so without the users consent. 
>>>> But they MUST tell the user about what information it 
>>>> recieved and for what purpose. This sounds pretty much 
>>>> like the requiments for user-consent, don't you think?
>>> David,
>>> You just described the difference between attribute release based on user consent and attribute release based on necessity. The issue Andrew has been explaining us several times.
>>> In both cases you must inform the end user on the attribute release.
>>> Consent!=Necessity. The difference between the two is technically small but legally significant:
>>> - the text in the button is either "I consent to attribute release" or "I am informed on the attribute release"
>>> - if attribute release is based on consent, the consent can be withdrawn any time.
>>> mikael
>> Exactly - and you know it has to be right when Michael, Andrew
>> *and* me agree on something. Take a picture folks - it probably
>> won't happen again in your lifetimes :-)
> Please get the picture done ;)
> Speaking for one of the federations where a info box is displayed with
> information about the attribute release the first time a user logs in, I
> tend to make the same mistake as David, speaking of this as consent,
> even if Andrew et al as made the point about this not really being
> consent in the legal sense (even with the option to abort a login before
> attributes are transferred)

Hmm, I seem to have missed a point about consent versus informing:  
Informing the user happens after the data release. Not before.
Therefore is a mistake is to say that is it not consent, when the user can actually opt out of the transaction.

> However, it turns out that both the end users and the Data Protection
> Agency like the fact that they are informed about where data flows. eGov
> services have been required to add the same information, and I wish
> their UI was as neat as ours. We have also had users who refuse to use
> Feide, since we expose the data flow that was already there and they
> were not aware of.

Those users will always exist. No news there.
Library loaners that refuse to be identified etc.

> It is not hard to inform the users.
> It works, whether or not is used to get a formal legal consent.
> As I get older, rudeness bothers me more, and not informing users about
> where their attributes are going, is just rude and inconsiderate.
> From where I stand, the technical mechanisms for informing and/or
> getting consent look the same, even if the requirements differ.

Se above.

> Has anyone looked closely enough at the UMA work over at Kantara too see
> where the overlap is with the current variations of federation policy?

Exellent idea.
BTW: we should all follow Kantara more closely in this space. Much happen over there - and I'm sure we can both contribute a lot and influence the out-come which I expect to draw up many of the play-fields that we will go to in the near future. Should liason with Kantara be a REFEDs work task?


> To get back to the proposed working group charter:
> - there is a definitive interest in the community to investigate the
> possible approaches to attribute sharing
> - the policies seem to be heavily influenced by the SP community (we
> serve many national administrative services, including digital exams,
> hence our willingness to handle NINs for relevant SPs)
> - we need transparency in the processes, while keeping uncluttered end
> user UIs and relevant information for the SPs (do not want to go the
> cloud route, where usage policies are either unacceptable or
> incomprehensible - or both)
> - cross-federation exposes the variations in trust fabric