Skip to Content.
Sympa Menu

technical-discuss - RE: [InC-Technical] Split InCommon into R&S and non-R&S federations?

Subject: InCommon Technical Discussions

List archive

RE: [InC-Technical] Split InCommon into R&S and non-R&S federations?


Chronological Thread 
  • From: "Farmer, Jacob" <>
  • To: Nick Roy <>, Mark Scheible <>
  • Cc: "" <>
  • Subject: RE: [InC-Technical] Split InCommon into R&S and non-R&S federations?
  • Date: Fri, 31 Mar 2017 16:44:07 +0000
  • Accept-language: en-US
  • Ironport-phdr: 9a23:TNv+VxbcrW0/DhhL8RiWLeb/LSx+4OfEezUN459isYplN5qZrsm+bnLW6fgltlLVR4KTs6sC0LuL9fG5EjVYuN6oizMrSNR0TRgLiMEbzUQLIfWuLgnFFsPsdDEwB89YVVVorDmROElRH9viNRWJ+iXhpTEdFQ/iOgVrO+/7BpDdj9it1+C15pbffxhEiCCzbL52LBi6twHcutQZjYd/Nqo91wbCr2dVdehR2W5mP0+YkQzm5se38p5j8iBQtOwk+sVdT6j0fLk2QKJBAjg+PG87+MPktR/YTQuS/XQcSXkZkgBJAwfe8h73WIr6vzbguep83CmaOtD2TawxVD+/4apnVAPkhSEaPDMi7mrZltJ/g75aoBK5phxw3YjUYJ2ONPFjeq/RZM4WSXZdUspUUSFKH4GyYJYVD+cZPehWsZTzp0cAoxW9CwmjBuLvxSNHiXLt0q02z/gtHBna0AA8Hd8DtmnfotXvNKcVVOC41KfEwzXZYPNM3Dfy9pLIfgg8qv+IR71/bc3RxlIhGwjYiViQq5TlPz2P2eQXtmiU8fBgWPmui246sQ1+vCWgxto1h4TPm4kbyUjE+D1kzIorIdC0Ukx2bNq+HJdNrS2WKoh7T8A6T211tys21qcKtYO4cSQU0pgqxB3SZ+aHfoSU+h7jWvieLDRkiH9gfb+zmQq9/la6xeD5SMW50UtGriRAn9TCqnwA1QHc582IR/Rh4kus3yuE2RrJ5eFeO080kLLWK54/zb40kZoeqUTDETXsmEXqia+ZbEMk9vK16+TmfrXmvYWQN45yig7jM6QhgMq/Dv4iPgcQQmeb5Pyw1Lzl/ULnXLVHluA6nrfdvZzAJ8kWorS1DxJP3oo+6BuyDC+q0NECknkGKFJFdgiHj4/sO1zWIvD4Ffm/jE62kDdu2f/GJKbsApTQLnTZjrjuYKt951ZGyAUv1dBf+45UCrYZLfLyXE/+qNvYDho8MwyzxebrEtJ91pkRWW6WHq+WLr/dsV+O5uIuP+aDfosVtC/gJPgk/P7hkWI5mUQGfaSy2ZsXaWu4Huh9I0mHe3bsg9EBEXsUsQokSuzllkGCXSBJa3msQq08+2JzNYS9EI2WQ4mshKCGjjyqG4VfTmFAAVeJFHDuMYKeVKQwb3e0I8Ri2gYDRPD1TZUmxDmvshP30bxqMrCS9yEF49ar8dFv5KXonhE/9DZwAozJ1nqGT2x1lGcFbzo/3aR1plw7z1yF2u5/mfMORvJJ4PYcGCkzL5vR1agyKdn5XQiLNoOLUFivWNCrGxkwU5Q8z8JYMBU1IMmrkh2Wh3niOLQSjbHeQcVsqq8=

I think the framing of the discussion is really important. Are we really talking about two discrete cohorts? Or a base cohort + a ‘beta’ cohort that is willing to bear extra risk/burden/etc. in order to be able to evolve more quickly?

 

In the priorities, one group is characterized as a collection of institutions that “…just want streamlined access to vendor SPs.” I would argue that is the most critical use case for federated authentication, because it is what justifies the investment in IAM infrastructure. Our institutions desire identity integration Canvas, Google Apps, Box, etc. and are willing to commit resources to that end. It’s from that baseline that we’re able to carve out x% of someone’s time to focus on these other things.

 

Now, that doesn’t mean it’s the only use case – I agree that growing support of R&S is critical and it is a key place to focus energy moving forward. But if we want to grow the IAM resource pool – both human and fiscal – campus IAM is probably where there is the most room for growth.

 

Jacob

 

From: [mailto:] On Behalf Of Nick Roy
Sent: Thursday, March 30, 2017 3:00 PM
To: Mark Scheible <>
Cc:
Subject: Re: [InC-Technical] Split InCommon into R&S and non-R&S federations?

 

+1 to a BoF, but we should frame it as something like,

"Federation of the Willing" or "Solving the Federation Value Proposition Problem for Large Scale Research"

Nick

On 3/30/17 12:35 PM, Mark Scheible wrote:

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

 

 

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




Archive powered by MHonArc 2.6.19.

Top of Page