Subject Re: VO challenges - article
From Heather Flanagan <hlflanagan@xxxxxxxxx>
Date Mon, 26 Oct 2015 11:23:33 -0700

(Sorry for the top posting)

I think the clarification about the limits of consent in this space is worth capturing in the doc. I will work on that later this week.

Sent from my iPad

> On Oct 26, 2015, at 02:33, Niels van Dijk <niels.vandijk@xxxxxxxxxx> wrote:
> Hash: SHA1
> Hello Jill
>> On 22-10-15 19:56, JILL GEMMILL wrote:
>> I am surprised that the topic of consent hasn't come up yet -- so
>> here it is.  One way to get release of attribute(s) needed for
>> collaboration is to have the user authorize this for themselves.
> If so, what makes an Authentication from a user at an institutional IdP
> 'better' then one from the same user using Google?
> Second, using consent in this way - to get the IdP of the hook legally -
> does not work for an EU IdP if the service the user is accessing is used
> in the primary process of the user. Under EU law consent is only usable
> if it is freely given. A very clear example of incorrect use would be
> asking consent from a student to access the Campus learning platform. If
> access to collaborative Research services is also the primary process of
> the user may be debated, but I guess it is true for many VO users that
> they would need that to do their day to day work.
>> Nick, you go ahead and put up your slide at the Global Summit --
>> it's CIOs that need to lobby with Registrar/Lawyers for R&S
>> support.  These CIOs also need to know of some campus research big
>> shots who need this stuff- it helps.
>> Scott's brings up an interesting question about the relevance of
>> IdPs if their role in federation is limited to authentication; it
>> is the snail pace that institutions have taken towards releasing
>> anything that is driving the research community to come up with its
>> own solutions, including VO management services, and even identity
>> mapping for users who move to another institution.  IT departments
>> will not put research support as a high priority unless the CIO
>> does so.
> Identity Federation works well for Campus IdPs where they are setting up
> to authenticate a large subset of there user, e.g. all their students to
> a small set of Services.
> Although the researchers are also a large group, they actually behave as
> many small groups, because they need access to many services in small
> groups. Institutions cannot deal with the many 100s SPs that would be
> needed on a per SP basis, and a solution, like R&S is needed to scale
> this process.
> VOs are ultimately about allowing groups of users to share resources.
> This often implies managing access to the resources. Only the VO knows
> who its members are and what role the user has in the VO. This is why
> many cross institutional and international VOs will/must maintain
> their own authorization management. Also campus IT will not manage
> individual attributes on a per user basis in their campus IDM. there
> are just to many users they would need to do this for.
> VOs would be happy to use federated authN as provided by federations
> and institutional IdPs, provided there is actually a positive business
> case. Read Heathers overview and see of yourself if you think that is
> currently the case. I for one are not so sure.
> Best,
> Niels
>> - Jill
>> -----Original Message----- From: Nick Roy
>> [mailto:nroy@xxxxxxxxxxxxx] Sent: Thursday, October 22, 2015 12:34
>> PM To: Keith Hazelton <keith.hazelton@xxxxxxxx>; refeds@xxxxxxxxxx 
>> Subject: Re: [refeds] VO challenges - article
>> Thanks!  I wold like to know if anyone is uncomfortable with me
>> sticking a slide up on a screen with that chunk of this
>> conversation on it, and doing my best Steve Jobs impression, say,
>> "read this - I'll give you 3 minutes" and then drop the R&S bomb on
>> them.
>> Nick
>> On 10/22/15, 10:22 AM, "Keith Hazelton" <keith.hazelton@xxxxxxxx>
>> wrote:
>>> Nick, I’m totally comfortable with YOU saying it  ;-)
>>> —Keith -- email & jabber: keith.hazelton@xxxxxxxx calendar:
>>> __________ On 2015-10-22, 10:54 , "Nick
>>> Roy" <nroy@xxxxxxxxxxxxx> wrote:
>>>> I would LOVE to put this snippet of email on a slide and show
>>>> it to CIOs at Global Summit in the spring.  It is the most
>>>> useful, concrete articulation I have yet seen of the dire
>>>> problem we have with attribute non-release.
>>>> The message I want to try to send is: Release at least R&S -
>>>> EVERYONE DO THIS NOW.  Go home, tell your IdPOs to do this.
>>>> Talk to your registrars.  Don't let them say no.  Don't even
>>>> open the door for that.  This is directory data.  Tell your
>>>> IdPOs to configure a persistent nameID and release that to
>>>> everyone.  Ask your IAM architect if you have something you can
>>>> easily configure as ePUID.  If you have that, release it too.
>>>> Are the folks in the conversation comfortable with me doing
>>>> that?
>>>> Thanks,
>>>> Nick
>>>> On 10/22/15, 8:36 AM, "David Chadwick"
>>>> <d.w.chadwick@xxxxxxxxxx> wrote:
>>>>>> On 22/10/2015 15:17, Cantor, Scott wrote:
>>>>>> On 10/22/15, 6:57 AM, "David Chadwick"
>>>>>> <d.w.chadwick@xxxxxxxxxx> wrote:
>>>>>>> But isn't this a protocol issue? The SP can demand this
>>>>>>> in the request cant it? (certainly in our Shib
>>>>>>> implementation we can ask for either persistent or
>>>>>>> transient and both work)
>>>>>> I can demand a pony, that doesn't mean I'll get one.
>>>>> But really we are not asking for a pony, only an ant (since
>>>>> PIDs are as common as them)
>>>>>> My own opinion is that once you give up on using federation
>>>>>> for authorization data, it's inevitable that authentication
>>>>>> will follow.
>>>>> With the evolution of FIDO this may well be the case. But the
>>>>> value of SSO with a PID is still worth a lot to end users and
>>>>> SPs, at the cost of next to nothing for IdPs.
>>>>>> If the IdPs don't want to be in the buisiness of helping
>>>>>> with access management for the applications using their
>>>>>> service, then they won't have a service to worry about
>>>>>> within a short span of time.
>>>>> Sadly most likely to be true
>>>>> David
>>>>>> -- Scott
> - -- 
> Please note:
> On January 1st, 2015 SURFnet moved to a new office.
> New Visiting address: Kantoren Hoog Overborch (Hoog Catharijne)
> Moreelsepark 48, 3511 EP Utrecht
> Postal address: PO Box 19035, 3501 DA Utrecht
> New Telephone: +31 88-7873000
> Version: GnuPG v2.0.22 (GNU/Linux)
> n/ZN3MUTafpCx4+GsmG5n6ifCBPJz85IbEudUMFObWwi2Z+3EzeI4tL5MxXcDEAw
> jm1yTv1uTmTdECrJ8ldBA2M3C+KFgwLxAOJlb5pfPuJ9Qll13kVoohhpgj/6j64Q
> vSy/RIRCtPkeWTWdsiXmxhhCAaanWN6V1r6BTrLE/2PH98hvnD9ZlHFRmLaKVt+7
> gslO1Cs9QlvkBq4QdowVb1D83uqOt/cihhzClMRtLKrMP71OZHepJTG4/YoXGocS
> puCfSALPJpJSTfGyTexNmczPxOEFxllT+X8HwoY+uwf51sieA72md519xi84dkf+
> Adb8bjcG5dz2MOZ+HPPMF4nbTlPYgXGEHhm8HAsZZU7GJDJCy3vfukZ1z4BkemOw
> XZvPmCwLn2joc+QMsAOK8ayYDDgYMgj7Ge7K6MLtoeluzbHdayex3IFVWsa8p/iS
> jMMyST1gbhOHlTI8bnf8aGx7YplBXvoZNTFbVsr2ZnxoPlV4zgNvz5nAaFJq1aj8
> HYcedcFkjfBv6jofKLqmfpmIji7iVvsHDuEEYvtbkzo4YKgNKDvfXfBeaV4+Gs+I
> hytx66uT6Yp91I1ymjx2CXoKM3C9bTfDwEAaEDEnc7r7mUNHaO/XlKS6laZSCj3D
> //D1O62P32HQ+hOL5a49
> =8Jew