Subject RE: VO challenges - article
From "Jones, Mark B" <Mark.B.Jones@xxxxxxxxxxx>
Date Tue, 27 Oct 2015 04:09:31 +0000

> >[Mark] Either I have missed the point or you have.
> >Sysadmins managing user their user's attributes for the purposes of their
> >institution is something that I would consider to be "their job", but 
> >managing
> >VO specific attributes for VO purposes is not only not "their job" but it 
> >is
> >unrealistic to expect ... which is what I thought was the point.
> That's an arbitrary distinction. VOs are nothing different than any other
> federated application on a campus, and most of those apps would be just as
> happy to be rid of central IT (and I can't really blame them seeing as I 
> work in
> that capacity, I know what we're like).
[Mark] What exactly is an arbitrary distinction?  My opinion is that VOs 
(external services) are, by definition, different than on campus (internal) 
applications.  There is no vested interest for an institution to maintain 
attributes in support of an external service.  If an institution has no 
internal reason to maintain an attribute then why would it bother?

> >[Mark] It may be useful to debate a very specific example.  What tools are 
> >you
> >envisioning that institutions should provide to external entities for 
> >managing
> >user attributes?
> The same tools I imagine they already use themselves because they're forced
> to run them to make up for the lack of support from the organizations for 
> which
> those users work.
> It doesn't really matter whether you agree with me or not on what is
> appropriate for the campuses to be doing. The point I was making is that the
> end result of that strategy is to bypass the campuses entirely, and I'm 
> simply
> observing that.
[Mark] I still have no idea what tools you are referring to.  It sounds like 
you are suggesting that institutions should allow external entities to make 
changes to their internal user's attributes by providing some sort of tools. 
And I don't see how this scales.  Is the VO supposed to manage their user's 
attributes using a suite of duplicated tools supplied by every IdP that any 
one of their users is associated with?

> >[Mark] The applications are better positioned to provide authorization, but
> >NOT to provide authentication.  I am a campus LMS operator.  We do
> leverage
> >LTIs.  But our LMS uses Shib instead of the LMS built in authentication.
> Same road. Eventually the IdP will be removed from that picture; the 
> important
> IdP in that exchange is the LMS.
[Mark] We must have an issue with vocabulary.  The only 'authentication 
provider' in the exchange is our local IdP.  And we would be changing LMS 
vendors if they stopped supporting using our IdP for authentication.

> The important function of an IdP is the attributes it provides, not the
> authentication. We have always differed on that, I think.
> -- Scott
[Mark] I'm not sure what you mean by "important".  I can agree that attributes 
are important, but are you really saying that authentication is not important? 
I'm not convinced that we differ.  I don't think we are particularly 
successful at communicating our positions to each other.

Attachment: smime.p7s
Description: S/MIME cryptographic signature