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

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

Andy,

* Andy Bennett <andyjpb AT knodium.com> [2014-05-03 18:58]:
> I'd like to pitch in with our experience over the last few weeks
> which is mainly operational in nature. I've been encouraged to post
> here to open up a wider discussion. I've not been able to determine
> if what we are trying to do is pushing the envelope or whether there
> are others in eduGAIN trying to achieve a similar thing.

Thanks for bringing this up here. Also, please don't take the lack of
discussion so far as a lack of interest in this topic. Probably more
of a lack of good answers.

> The problem for us is that the two federations interpret the
> semantics of RequestedAttribute slightly differently and in mutually
> conflicting ways.
> 
> One federation's IDPs will only release an attribute if it is happy
> to do so *AND* it appears in our list of RequestedAttributes. If we
> ask for nothing then we get nothing.
> 
> The other federation's IDPs will always release everything we ask
> for but the federation will only "enable" us if our list of
> RequestedAttributes satisfies their policy.

Could you elaborate on how exactly those two requirements are mutually
exclusive?  Seems both will be happy if you included a set of
requested attributes?
(Also it seems to me a federation taking on part of home institutions'
liability by deciding what data should be released from institutions'
IDPs would be well-advised to police the data they want to take on
responsibility for.)

Due to institutional autonomy and legal liability you probably won't
ever get around the "institutions are releasing what they want" issue,
so that's not something you or anyone else can solve. We only need
ways to deal with it, e.g. by making it easy to offer only
likely-to-work IDPs in IDP discovery. That's what the IDP-support part
of the REFEDS R&S Entity Category is meant for, for example.

> Our service is able to use a wide range of attributes and so this is
> what we included in the metadata but we will still work if IDPs send us
> as little as EPTID (which we absolutely require). We would like to
> receive as much as we can mutually agree on in order to provide the
> friendliest experience to the end user.

Looking at your current entity descriptor in eduGAIN (what you call
the "much more minimal RequestedAttribute list", I wonder what it
looked like before) that's still a very extensive list of data, most
of which does /not/ have any clear definition and hence no consistent
use (if any) outside an individual institution (or even within).
  So I'm not sure what value you hope to derive from e.g. employeeType
(whatever that means, I haven't found a definition worth that term),
eduCourseMember, eduCourseOffering, organizationName or
schacHomeOrganizationType?
  Very well possible that having no agreed upon standards for many of
those attributes (or more often, their values) will not be an issue
for your intended use within your service (about which I know
nothing).

That points to another (?) problem of identity federations as we know
them today: We think we excel (i.e., offer something the market
doesn't or can't) in providing relevant/high-value attributes, when in
practice you can't really except anything other than the following
attributes to be available: ePPN, ePTId (or just one of those two),
ePSA, mail, some form of name (givenName/sn/displayName/cn), plus
regionally/nationally defined attributes maybe.  (For anything else
the service needs to be quite important to the institution, then you
get by with pretty much any request, no matter how unusual or outright
standards-violating.)

> I don't think it's particularly useful to have a debate about what
> the correct behaviour is as the operational reality is that there
> are differing implementations. I'm more interested in a discussion
> about how we should move forward in the medium term and how policy
> might be negotiated over a longer timescale.

The current thinking is that Entity Categories deal with a large part
of the problem space and work is underway (or should be, IMO) to get
SPs labelled with those categories and nudge home organisations to
support those categories.
OTOH if your service's requirements don't align with what (many) other
services in your space are doing (i.e., there's no concievable
category that would express that) then this is not something we have a
good answer to, today, I think.

Lacking any applicable abstractions that scale, the fallback would be
for each institution (or federation, where attribute release is
centrally controlled) to hand-carve release policies specifically for
your service.  How likely that is to happen is a function of how
popular your service is (and how well that popularity can be
translated and communicated to the people in a position to make the
integration happen.)

HTH or at least stimulates expression of objection from some.
-peter