InCommon Technical Discussions

[Mark Scheible <>]

But "Splitting InCommon" made for a great Subject, didn't it?!!!

I think the comments made in this thread have a lot of merit.  I also like Albert's suggestion we carry on the discussion at a "BoF" at Global Summit (possibly an impromptu BoF or Social Gathering).  We're also missing REFEDS input. Should we consider soliciting REFEDS members to join the technical-discuss list?

Certain suggestions in this thread could be part of the "Attribute Release 2.0" Working Group Charter.

Just some thoughts...

Mark

Mark A. Scheible

Sr. Lead IAM Solutions Architect

MCNC, Research Triangle Park, NC

Office: (919) 248-1997

Cell: (919) 609-8595

Fax: (919) 248-8419

On Thu, Mar 30, 2017 at 2:12 PM, Nick Roy <> wrote:

Splitting the federation would be a significant step in terms of policy, process, operations, resourcing, priorities, etc.  It is not something that either the TAC or InCommon Operations can make a determination on.  This would be squarely in the realm of Steering/T&I leadership decision making.

Best,

Nick

On 3/29/17 8:13 AM, Mark Scheible wrote:

Scott,

Thanks for your updates to the Work Plan.  They are inline with what our thoughts have been, but the perspective you provided helps clarify the issues that need to be addressed.  [I've decided to post this to the technical-discuss list to get some conversation flowing.]

In particular the following comment:

********************

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.

********************

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

Assuming InCommon Ops would agree to a separate aggregate or another solution, I wonder about the pros and cons of separating entities and the impact it might have on further adoption of R&S and attribute release.  It's certainly worth the discussion.

Mark

Mark A. Scheible

Sr. Lead IAM Solutions Architect

MCNC, Research Triangle Park, NC

Office: (919) 248-1997

Cell: (919) 609-8595

Fax: (919) 248-8419

To unsubscribe from this list, send email to with the subject: unsubscribe technical-discuss