InCommon Technical Discussions

["Cantor, Scott" <>]

On 3/29/17, 10:13 AM, 
"
 on behalf of Mark Scheible" 
<
 on behalf of 
>
 wrote:

> I'm not sure exactly what it is that you're proposing here (I understand 
> the reasons, but didn't know whether you had a proposal),
> but perhaps creating a separate aggregate of R&S entities would accomplish 
> what you're suggesting. R&S SPs could then choose
> to only import the R&S aggregate. (Maybe a very poor suggestion, but I 
> thought I'd throw it out there to start the conversation.
> Feel free to poke holes in it, or offer other suggestions).

A Shibboleth SP can already do this filtering on the fly, so it wouldn't 
really accomplish much.

I don't know whether a separate federation provides a means of focus that 
some kind of trustmark or similar mechanism doesn't provide. I'm not sure 
that the bandwidth exists to split the federation in a way that wouldn't be 
just as easily achieved by figuring out who wants to focus on those problems 
and just letting them do so.

I think there's a sense though that there's a "subsidization" of things like 
Net+, which quite frankly I don't perceive as delivering value to InCommon, 
and that's the crux of the matter to me.

I'm deeply supportive of InCommon's focus being research support and away 
from the essentially solved (as much as it will ever be) problem of cloud 
integrations. The vendors are silos, they will not really federate, and they 
are pretty universally moving to self-service configuration models in which 
InCommon metadata will likely not be able to significantly add value, minus 
perhaps a few cases involving the move to per-entity metadata (but really, 
hosting one's own metadata is trivial anyway when we're talking about a 
single IdP).

I'm not sure how to accomplish the shift, but a separate aggregate isn't the 
way IMHO.

-- Scott (Cantor)