Subject Re: VO challenges - article
From "Cantor, Scott" <cantor.2@xxxxxxx>
Date Tue, 27 Oct 2015 14:04:39 +0000

On 10/27/15, 12:09 AM, "Jones, Mark B" <Mark.B.Jones@xxxxxxxxxxx> wrote:

>[Mark] What exactly is an arbitrary distinction?  My opinion is that VOs 
>(external services) are, by definition, different than on campus (internal) 

I don't share that opinion, or perhaps I should say that if I did, I would conclude that federation with campuses is fairly pointless. That's the different conclusion we're coming to. You want to preserve one minor use case (authentication) when I would dismiss that as relative easily fungible.

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

That's the same argument many campuses use to explain why they're not supporting R&S. Thus my conclusion that it's pretty much hand in hand.

>[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?

If it comes to it (again, I'm not speaking to what "works" but what the consequence of it "not working" really is). But I think there would be better models, such as data flows between the VOs and the campuses to effect the provisioning of attributes. Such tools may or may not exist at this point. As you note, it's moot, because so many campuses have washed their hands of the idea because it gets them out of doing anything at all.

>[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.

I said IdP, not authentication provider. IdP has a broader functional scope in SAML than just authentication. Once you have a proxy IdP that's doing all the real work of attributes and provisioning and so forth, the small bit left is easy to replace with a commodity.

>[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 saying it's easily fungible and not much of a reason for people to deal with campus IT.

-- Scott

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