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

[Mikael Linden <mikael.linden AT csc.fi>]

Hi Niels,

> Are there any additional usecases for this?

Constructing the disco in the SP and deciding which IdPs' metadata the SP
consumes.

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

>* 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?).

It is a local policy decision, but I would assume Home organisations to
configure their IdPs to release attributes automatically to CoCo-committed
SPs (that is the scalability benefit of the CoCo, right?)

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). However, if a Home Organisation blacklists all of them
by default, then the benefits of the CoCo are lost.

> 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 think it is valuable to try to "protect" users against IdPs who are not
consuming the SP metadata and willing to release attributes, because
otherwise the end user will see a nasty error message and decide that
eduGAIN does not work.

Alternatively, the SP admin could deploy a robot which consumes eduGAIN
metadata and tries to log in using every IdP, one after another. Only
those IdPs who do not show an error message are shown in the disco. This
approach has been proposed e.g. by CLARIN [1].

>* In addition, I think very few services ever be interested in ALL CoC
IdPs,

Actually quite many, like the CLARIN services, Foodl, TERENA Proxy SP,
various wikis...

>but only a
>subset releant to the service (because of community, license etc). That
again requires
>manually creating a list of relevant IdPs

Sure, these are not mutually exclusive.

> I think the SPs would value much more for example a statement on how the
identity was
>vetted or other LOA related information.

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

Cheers,
mikael

[1] https://lindat.mff.cuni.cz/secure/aai-idps-weblicht
-----Original Message-----
From: Niels van Dijk [mailto:niels.vandijk AT surfnet.nl]
Sent: 23. kesäkuuta 2014 18:19
To: Mikael Linden; edugain-discuss AT geant.net
Subject: Re: [eduGAIN-discuss] Entity category support attribute for Data
Protection CoCo?

Hi Mikael, all,

Are there any additional usecases for this?

Although a see some value in the auto generation of discovery, I think it
is rather thin:
* 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?). 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.
* In addition, I think very few services ever be interested in ALL CoC
IdPs, but only a subset releant to the service (because of community,
license etc). That again requires manually creating a list of relevant
IdPs

I think there is much value in entity category statements in IdP metadata,
but I think the SPs would value much more for example a statement on how
the identity was vetted or other LOA related information. That said, I am
well aware that is not something achieved overnight, and maybe having this
IdP CoC attribute is low hanging fruit.

Cheers,
Niels

On 23-06-14 15:43, Mikael Linden wrote:
> Dear eduGAIN,
>
>
>
> Currently, the GÉANT Data protection Code of Conduct defines an entity
> category attribute just for SPs[1]. No entity category support
> attribute for IdPs is defined.
>
>
>
> I would like to ask the community’s opinion if there is a need to
> complement the CoCo specification by defining also the EC support
> attribute for IdPs. The semantics would be “As an IdP, I’m willing to
> release attributes to the SPs committed to the GÉANT Data protection
> Code of Conduct”. The use case would obviously be assembling a proper
> IdP Dicovery service in the SP side.
>
>
>
> The reason for the hesitation so far has been a possible interference
> of the multiple EC support attributes of an IdP, but that issue has
> been discussed in the REFEDS list [2]. The conclusion was that if an
> IdP asserts support to multiple ECs, they are interpreted separately
> and independently. For instance, if an IdP has both the CoCo and R&S
> support attributes, it means “this IdP releases attributes to an SP
> that asserts R&S and, independent of that, to an SP that asserts CoCo”.
>
>
>
> The CoCo support attribute would still leave an opportunity to the IdP
> to decide,
>
> - what is the maximum list of attributes to release (although the
> cookbook gives an idea[3])
>
> -  if the IdP wants to make an exception for some SPs (I think we
> can’t avoid this anyway).
>
>
>
> Looking forward to receiving your input!
>
>
>
> Cheers,
>
> Mikael (the CoCo flywheel)
>
>
>
> [1]
> http://www.geant.net/uri/dataprotection-code-of-conduct/V1/Documents/G
> EANT_DP_CoC_Entity_Category_ver1%200_0614.pdf
>
> [2] https://www.terena.org/mail-archives/refeds/msg03847.html
>
> [3] https://wiki.edugain.org/Recipe_for_a_Home_Organisation
>
> --
>
> Dr. Mikael Linden
> Senior application specialist, CISSP
> CSC - IT Center for Science Ltd.
> P.O. BOX 405, FI-02101 Espoo, Finland
> +358 40 507 4100, mikael.linden AT csc.fi <mailto:mikael.linden AT csc.fi>
>