Skip to Content.
Sympa Menu

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

Subject: InCommon Technical Discussions

List archive

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


Chronological Thread 
  • From: David Langenberg <>
  • To: Scott Koranda <>
  • Cc: Mark Scheible <>, "" <>
  • Subject: Re: [InC-Technical] Re: Split InCommon into R&S and non-R&S federations?
  • Date: Thu, 30 Mar 2017 13:01:16 +0000
  • Accept-language: en-US
  • Authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=uchicago.edu;
  • Ironport-phdr: 9a23:E+46iBbA7fABXxCKhmtr8fj/LSx+4OfEezUN459isYplN5qZr8WybnLW6fgltlLVR4KTs6sC0LuL9fCxEjFdqb+681k6OKRWUBEEjchE1ycBO+WiTXPBEfjxciYhF95DXlI2t1uyMExSBdqsLwaK+i764jEdAAjwOhRoLerpBIHSk9631+ev8JHPfglEnjSwbLdyIRmsrgjcssYajItiJ60s1hbHv3xEdvhMy2h1P1yThRH85smx/J5n7Stdvu8q+tBDX6vnYak2VKRUAzs6PW874s3rrgTDQhCU5nQASGUWkwFHDBbD4RrnQ5r+qCr6tu562CmHIc37SK0/VDq+46t3ThLjlTwKPCAl/m7JlsNwjbpboBO/qBx5347Ue5yeOP5ncq/AYd8WWW9NU8BMXCJDH4y8dZMCAeofM+hFs4nzqVgArRW8CgaiBePg1jBHi2T53aEm1uQsCx3K0RYiEt8IrX/arM/1NKAXUe2twqfH1yvDb/JL1jzg7obHaBYhof6SUrJ2asXe11MvFwzYhViXtIPqJS2V2foJs2WA8upvSeKvi287pA5rrTivwd0ghZfUiYII013J8zhyzoUtJdCgVUJ3fdGpHIFfuiyYLYd7TM0vT3t1tCs0yrAKoYO3cDYJxZg92hLSZfyKf5KM7x/nTuqdPCl0iX1jdbminRi961Kgxff5VsSs0FZFsC5Fkt7Uu34VyxHd7dSLRuZk8kq8wTiC2Rnf6uZfLk8qj6bbLIMhwqIrmZoUrETDGDL5lF/ujK+McUUk5van5Pj7YrXnoZ+cMZV4igbjMqQynsy/BuM4MgsUU2eH/uS80aXv/Uz/QLpUkv07irTVvIzVKMgBqaO0ARVZ34gt5hqlEjur3tQVkWECLF1feRKHi4bpO0vJIPD9Ffqwnk6jkCl1yPDCJbDhH4nCLnjCkLj9Z7l95ElcxBAtwt9C+pJYEqsBL+7rWk/tqNzYCQc0Mw2yw+n7D9V904YeWWWJAqODN6PSq1CI6vszI+aSeIAVuDD9K/k56PH0iX81gEISfaiy3ZQLdXC4Be9mLl6dYXrtmdcBDXwKshQkQOzrjl2CTSBcZ2y0X60i+jE3FpiqApneSYCw0/S923KAFZpKeihlDUqFF3vhP9GfWPAWYSSeK+dulzUFUf6qTIp3hj+0swqv57N5L+ac3iQeup/l3tVv6KWHmRgs+DhcEs+d0mqEQGYyk28VEWxllJtjqFBwnw/QmZNzhOZVQJkKv6tE
  • Spamdiagnosticmetadata: NSPM
  • Spamdiagnosticoutput: 1:99

Perhaps this is better solved then by standing up a 2nd hub and spoke style
service? The VOs would use that one. The 100 or so who “get it” would see
no difference. The 300 ‘others’ would also be able to interop just fine, but
their users would be stopped at the federation IdP to self-assert missing
attributes?

Dave

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

On 3/30/17, 7:44 AM, "Scott Koranda"
<>
wrote:

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

Hi,

Leveraging InCommon to support large research projects that scale across
many institutions, such as LIGO, is difficult and takes a large
investment that many projects cannot or will not make. Few do so today.

The evidence for that is well known and accepted. I will not repeat it
here.

I think that InCommon has the potential to be the de-facto substrate for
identity management for research projects in the US, but it is unable to
realize that potential so far. Attribute release has long been the
primary concern. Despite more than 5 years of effort (yes, it really has
been that long since the R&S entity category was proposed) only 140 or
so campuses participate, and many of those (82) will not release
attributes
to SPs not published by InCommon.

I am attempting to provide "food for thought". Take it as you will.

Scott K for LIGO

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




Archive powered by MHonArc 2.6.19.

Top of Page