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

[Andy Bennett <andyjpb AT knodium.com>]

Hi,

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

:-)
Thanks for the encouragement.


>> 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?

We only have one SP for our service so the set of attributes has to be
the lowest common denominator. i.e. the union of all the expectations.

This means that for the federations that only release if we ask, we
can't take advantage of anything we could use but can't ask for because
another federation won't allow us if we do.


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

Perhaps they do: in our case the Federation is a hub-and-spoke one where
all authentications to the SP come from their central IDP.


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

...and that's absolutely fine. We would like to have a basic level of
service for all IDPs but we work more closely with ones that we have
commercial relationships with. We'd like the federation to be
transparent at that commercial level so it makes sense for the IDP to
have the final say but be able to take the Requested Attributes as a
hint if they want to.

In this case, we are trying to work directly with one IDP in an edugain
federation so it doesn't seem to make sense for the release policy to be
one-size-fits-all at their federation level.


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

We had EPPN in there before which seems to tickle people in particularly
sensitive ways even if it doesn't initially *seem* to contain anything
more sensitive / identifiable than, say, an eMail address. I have a
little write-up somewhere about the psychology of EPPN somewhere. :-)

Our app is quite IDP-aware and when we see a new IDP I define how their
attributes map to our idea of user profile, etc. This means we're quite
flexible at the level of the meaning of an individual attribute and put
quite a bit of effort into making useful any information that we might
receive.


>   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?

Maybe it's not worth asking for them then. We don't use Requested
Attribute in the UKAMF so it was difficult to work out whether we should
be asking for absolutely everything we are able to do something with or
not. As we have found, other federations seem to take views at opposing
ends of the spectrum from each other.

We intend to use the eduCourseMember and eduCourseOffering attributes to
help with exploration of our site by showing users things that are
relevant to their peers (we're a course collaboration site).

employeeType we hope to use a little like affiliation.

I hoped organizationName would be interesting because a lot of
universities in the UK "trade" under a name different to their legal
one. For example, "Imperial College, London" is still known as "Imperial
College of Science Technology and Medicine" in all the formal data
sources and getting a mapping between these names (so that we can show
them "correctly" on our site) has been really rather tricky.
I also hoped it might help us in the case of the joint medical schools.
Joint medical school students are affiliated with more than one
university and sometimes have computer logins at one, both or neither.


Our Requested Attribute list is currently a list of "things that we will
do something sensible with if you send them" and we have the technology
in our app to make sure of that on an IDP-by-IDP basis. Most of the
things are about enriching the user experience. I find this whole
argument about "need" to be really tricky. We "need" those attributes to
make things the best they can be. You won't get an error message if you
only provide EPTID but the user experience will often be terrible to the
point of being useless. ...and that will mean that users don't like our
service as much as they could do.


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

Yes. They seem interesting but, unfortunately, more immature than RAs.
They definitely seem to fit into the "policy negotiated over a longer
timescale" bucket.

The reason I'm publishing RAs now is in an attempt to work with the
federations who are specifically asking for them.

Our problems are very much of a practical nature: different federations
have things set up in different ways and change involves time, effort
and development for them. If I was joining their federations directly
then I'd have to craft my metadata to their policies but as I'm being
imported via edugain there are restrictions on what I can do in order to
get the broadest possible support and therefore, (I'm trying to convince
them) that the development work falls to them to interpret the imported
data in the most flexible way.

We are happy to implement things in order to get more reach into
edugain. How much more reach would Entity Categories get us right now?


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

Yes. At the non-commerical level most federations have been incredibly
helpful. One in particular handcrafted a policy for us but found that it
got overwritten by their automated systems each night. The solution was
for us to start publishing RAs as that was less work for us than it
would be for them to do further development on their systems that might
affect many IDPs.

When we came to work with another federation we found that they also
wanted to see RAs but they want a minimal set rather than a maximum set
and now it's hard to change things without compromising the setup we
have with the first federation.


> HTH or at least stimulates expression of objection from some.

Yes, thanks. It's really good to hear from someone who has rather more
experience of these things than us.



Finally, I think RAs *could* work for us is there was a agreement about
what the "required" attribute does. That way we could have the best of
both worlds where we publish a maximum set but only mark EPTID as
required="true". That would at least get us a step closer.





Regards,
@ndy

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