Skip to Content.

edugain-discuss - Re: [eduGAIN-discuss] [refeds] mari plan & next steps

edugain-discuss AT lists.geant.org

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

List archive


Re: [eduGAIN-discuss] [refeds] mari plan & next steps


Chronological Thread 
  • From: Andy Bennett <andyjpb AT knodium.com>
  • To: Lukas Hämmerle <lukas.haemmerle AT switch.ch>, <edugain-discuss AT geant.net>, <refeds AT terena.org>
  • Subject: Re: [eduGAIN-discuss] [refeds] mari plan & next steps
  • Date: Wed, 29 Oct 2014 16:51:02 +0000
  • List-archive: <https://mail.geant.net/mailman/private/edugain-discuss/>
  • List-id: eduGAIN discussion list <edugain-discuss.geant.net>

Hi,

>> Others insist on you enumerating everything you can use and then only
>> sending you what they're happy to release.
>
> Isn't that the most reasonable approach, combined with some logic on the
> SP that throws an error message e.g. if neither displayName, commonName
> or givenName+sn is available even though the name is crucial for the
> operation of the service?

To my mind, yes. However, we've been lambasted in the for having an
overly broad set of RequestedAttributes. I don't mark any of them as
"required" but I will definitely try to do something sensible with
anything that anyone sends me.

...so there is a balance to be struck and the problems aren't just
technical. There seems to be a common point of view that holds that
you're not "supposed" to ask for things because they might be sensitive.
Even tho', SAML is a technical platform *for* releasing those things to
people who can handle them responsibly.

Entity Categories hopefully solve some of that stuff but I've heard the
same rhetoric about them. Apparently some of the wording in the GEANT
Code of Conduct just reinforces the position that they really shouldn't
release anything even if we're both signed up for it. The reasoning
always being due to "minimisation of release".

It seems that the "need" for an attribute is more intangible than just
whether you can be trusted to be responsible with the data and can do
something interesting with it.

All we strictly *need* in a technical sense for a user to log into our
service is EPTID but users who only send that will get a pretty
miserable experience and will probably not find it very useful and will
therefore leave.

As we're a collaboration platform, the more an IDP sends us, the more we
can do to make the platform useful to individual groups of people who
want to collaborate and discover each other.

If you send us affiliation we can put you with other staff or students
from your particular organisation, rather than just putting you in the
bucket of "users that we don't know where they're from". This is a good
baseline to have for IDPs even if we don't currently have a commercial
relationship with them.

If you send us display-name then we don't have to ask you for it when
you sign up. This starts to get useful when a lecturer wants to deploy
our product on a particular course.

If you send us course codes then we can automatically show you groups
related to your course. This gets useful when a whole department wants
to use our product.

If you send us EPPN then we can take a feed from your registry and
student information systems and provide "cohort management" services.

etc, etc.

The more you send, the more you we can do. So just send us as much as
you're happy with.


The trouble comes when people put the bar for "need" at "the bare
minimum which means your service doesn't reject the user at login time".





Regards,
@ndy

--
andyjpb AT knodium.com
http://www.knodium.com/






Archive powered by MHonArc 2.6.19.

Top of Page