Subject Re: VO challenges - article
From Niels van Dijk <niels.vandijk@xxxxxxxxxx>
Date Mon, 26 Oct 2015 10:33:24 +0100

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.


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