InCommon Technical Discussions

[David Langenberg <>]

What’s the underlying use-case driving this proposal?  Are you trying to 
lessen the experience for the 300 in hopes they join the 100?  Are you trying 
to show vendors / other VOs the value prop by saying, “Look at these 100 
places you can easily work with?” Is this really more about making your 
discovery interface automatically/easily include/exclude IdPs that meet “best 
practices”? Personally, I don’t think dividing InC into multiple 
federations/aggregates is the right answer, house divided and such, so I’m 
trying to understand what’s so impossibly horrible about the state of things 
today that the answer is to basically start over?

Dave

-- 
David Langenberg
Asst Director, Identity Management
The University of Chicago

On 3/30/17, 6:06 AM, 
"
 on behalf of Scott Koranda" 
<
 on behalf of 
>
 wrote:

    Hi,
    
    > ********************
    > Break InCommon into two effective federations:
    > 
    > One federation would be those campuses that want to support a national
    > infrastructure that facilitates collaboration in higher education and 
research.
    > It would require IdPs to support the R&S entity category. The other 
federation
    > would be for campuses that just want streamlined access to vendor SPs. 
Those
    > campuses that want to collaborate could then evolve faster.
    > ********************
    
    The context was making progress on the stalled issue of scaling
    attribute release.
    
    It is not a technical suggestion, though it would of course have
    technical ramifications.
    
    My observation is that there are roughly 100 InCommon Participant
    campuses that could and would, if mandated, implement changes
    to make the trust fabric more scalable and simply more trusted. Things
    like
    
    - attribute release to all R&S SPs in eduGAIN
    - populating MDUI elements
    - up to date and correct errorURL elements
    - security contacts in metadata
    - support for SIRTFI (security incident response)
    - consumption of per-entity metadata
    
    I expect those 100 or so organizations could make that happen in a year
    or less. They already "pay attention" and have most of it in place
    already.
    
    The other 300 or so organizations, more generally, are not interested in
    creating and sustaining a trusted fabric for facilitating
    collaboration and research. They have other concerns.
    
    Yet a lot of energy and resources are spent attempting to motivate those
    300 to operate like the 100, even though those 300 fundamentally do not
    have the drivers that might push them to operate at the higher level.
    
    So my proposal is to stop trying. 
    
    Instead let the 100 evolve quickly to a higher level and call that
    "InCommon".
    
    The other 300 could be called something like "InCommon light" or
    "InCommon basic". They would not have to meet the same level of
    performance and achieve the same level of interoperability, but they
    would also receive less services, and consume less resources.
    
    My proposal is to solve the attribute release problem by scoping it to
    the Participants that can actually solve it, and build a better
    federation on that foundation.
    
    Thanks,
    
    Scott K for LIGO

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