Skip to Content.
Sympa Menu

interfed - Re: [inc-interfed] comments re "New InCommon IdPs"

Subject: Interfederation

List archive

Re: [inc-interfed] comments re "New InCommon IdPs"

Chronological Thread 
  • From: Scott Koranda <>
  • To:
  • Subject: Re: [inc-interfed] comments re "New InCommon IdPs"
  • Date: Tue, 4 Mar 2014 08:06:15 -0600


On Tue, Mar 4, 2014 at 7:28 AM, Tom Scavo
> This message is a response to ScottK's comments added to the document
> "New InCommon IdPs":
> I wanted to address those here, on the mailing list, to avoid diving
> into the weeds on Wednesday's interfed call.
> In reverse order:
> 1) A security contact is not required in metadata and there are no
> plans to change that.

That should change. The TAC should begin to move towards requiring
a security contact as part of its new focused efforts in supporting
research organizations,
as discussed at last year's IdentityWeek.

Additionally, given the increased frequency at which campuses are targets
for major attacks that later receive significant publicity,
I would expect InCommon would move to help strengthen cybersecurity,
even in this minimal way.

> Honestly, I think Federated Security Incident
> Response needs its own working group.

Jim Basney and I had a call last week with the CIC IdM working group.
We are spinning up a new effort that will implement the federated identity
incident response policy developed by that same group in 2011 for
CIC schools.

The CIC will take the lead and then ask InCommon to review what it has done
and consider adopting it to some extent. It is my understanding this model
has been used before.

> 2) I know about the LIGO use case involving SAML artifact. It's a
> legitimate use case but AFAIK it's very much the exception rather than
> the rule, and so requiring artifact support of all IdPs in the
> Federation doesn't seem to be justified.

I am not asking that IdPs be required to support SAML artifact
and attribute query.

I am asking that InCommon continue to make possible and allow
IdPs that do support those profiles to continue to publish those
endpoints in the InCommon metadata feeds.

> If you really need artifact
> at your SP, put a simple IdP Proxy in front of your service that
> supports artifact.

That would reduce the usefulness of the InCommon federation
to supporting the LIGO research mission by requiring additional

If InCommon continues to allow (but not require) IdPs to publish artifact and
attribute query endpoints than this is not an issue.

> 3) I don't know about the LIGO use case involving attribute query. Can
> you explain that briefly?

Until international interfederation is well supported many researchers
across international boundaries will be "multi-homed" with identities
in multiple VOs in order to accomplish their research. The multiple
identities are serviced by multiple IdPs.

The LIGO IdP is the authoritative source for a number of LIGO
attributes that a research may need to take with him or her to other
VOs and their infrastructure even when they are forced to authenticate
using a non-LIGO IdP.

It can be easier to arrange for attribute query to the LIGO IdP than
it is to get all the IdPs and SPs to be internationally


Scott K for LIGO

Archive powered by MHonArc 2.6.16.

Top of Page