An open discussion list for topics related to the eduGAIN interfederation service.

[Peter Schober <peter.schober AT univie.ac.at>]

* Mikael Linden <mikael.linden AT csc.fi> [2014-06-24 07:51]:
> > Are there any additional usecases for this?
[...]
> Perhaps also monitoring the CoCo support in the IdPs (currently we have no
> idea how many IdPs are willing to release attributes to CoCo-committed
> SPs).

While that (monitoring) is not the primary reason to create semantics
for IDPs carrying the CoCo EC it's also not the worst reason for doing
that: The success of promoting the GEANT EU/EAA DP CoCo for SPs cannot
be measured by the number of SPs pledging to behave alone. All of this
means very little if IDPs don't comply. I.e. ultimately the CoCo is
/only/ about IDPs releasing attributes and currently we have no why of
knowing which IDPs do that.
So even if you think there's a need for dynamic IDP discovery (or SAML
metadata) filtering (maybe because those SPs had to learn to do that
via some other way) that alone might justify the introduction of
semantics for IDPs, IMO.

Niels wrote:
> >* The fact that the IdP claims support for CoC will still not
> > automagically warrant attribute release (I interpret "willing to
> > release attributes" not as "I am automatically releasing
> > attributes" as is the case for the R&S IdP statement, or do you
> > plan to make that part of the CoC of IdPs?).

The same argument could be made against the REFEDS R&S EC, which is
why that EC already includes language to that regard (which the CoCo
EC could copy):

  "An Identity Provider supports the R&S Category if, for some subset
  of the Identity Provider's user population, the Identity Provider
  releases a minimal subset of the R&S attribute bundle to R&S Service
  Providers without administrative involvement, either automatically
  or subject to user consent."

> The Home Organisations probably still want to leave the door open
> for blacklisting some individual CoCo-committed SPs (e.g. if the SP
> is known to have a problem).

Nothing we do (building federations, creating standards) will take
away institutional autonomy or preclude bilateral agreements.
So yes, that will always be possible and we can't and don't want to
take that (or other arrangements) away. But without EC support that's
/all/ we have, which (to use your words) is pretty thin too.

> However, if a Home Organisation blacklists all of them by default,
> then the benefits of the CoCo are lost.

Sure. The question then becomes whether we'd agree with such a HO then
claiming to support the GEANT EU/EAA DP CoCo for SPs (or REFEDS R&S,
for that matter).
I think you can't /sensibly/ claim to support an EC based on manual
configuration, even though theoretically it's certainly concievable
(with daily notifications of changes in eduGAIN, ad-hoc policy
decisions and manually making config changes to your IDP). Such an
approach pretty much rules out getting decisions about the release of
PII to third parties approved by management, so that's an approach we
shouldn't promote, IMHO.
So the defintion of what it means for an IDP to support an EC should
be worded as indicateds above, IMHO, to rule out such (corner) cases.

Niels:
> > So if the SP want to "protect" users against ending up at an IdP
> >that will not allow them to login, the SP still needs to configure
> >its IdP list manually.

I don't agree (even after substituting "allow them to login" with
"comsume interfederation-enabled metadata and release attributes"):
For one, the ECs we have are not strong guarantees, something you can
probably never have in Massive Multiparty (Inter-)Federation without
also investing Massive Amounts of Effort. Secondly if IDPs
systematically and in relevant numbers were signalling support for an
EC and not acting accordingly, we've either b0rked the EC definiion or
need to take action as Federation Operators to recify the situation
(incl potential removal of the EC from the entity).

To me ECs are a way to signal that an entity is likely non-broken,
with "broken" increasingly meaning "does not interfederate well", with
all that entails.
Not that I'm happy about the fact that we need this signalling.

> Yes! But CoCo and LoA are separate stories...

Very much so.  By defining what CoCo-support for IDPs means we're not
preventing you (Niels, or anyone else) from going forward with
"solving the LoA problem".
-peter