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

[Niels van Dijk <niels.vandijk AT surfnet.nl>]

Hi all,

On 24-06-14 09:36, Peter Schober wrote:
> * 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.
> 

Sound like a very good additional usecase to me.

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

Well that was basically my point: The current way Mikeal described it,
the COC IdP is not requirering automatic attribute release, while I
would indeed argue that is the whole idea. I would think therefor that
the CoC on IdP site shoudl suggest automagical attribute release.


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

Sure

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

Well, it is just me wondering if we should  invest effort in the IdP CoC
or work on other stuff. As I said earlier, it may be low hanging fruit.
And in that case we should do it ofcause.

But I think we are by no means done with the CoC SP work. We now have
the means to actually do the CoC, which is a great achievement. Now we
(a.k. federations) need to educate IdPs and SPs. That is the really hard
part. Especially as for us (thinking about) interfederation may be a day
to day thing, but for our institutions it is a rather distant thing for
them. I notice that e.g. we are following up a lot of stuff rather
rapidly e.g. first CoC, then R&S and it takes time for SPs and IdPs to
grasp what it is and why it could be useful. Especially if you are a
newcomer to (inter)federation, ignorance is bliss. So all this extra
stuff may seem like overkill (to them, not to me!).

Cheers,
Niels