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

[Rhys Smith <Rhys.Smith AT jisc.ac.uk>]

Hi all,

Apologies for lateness (been on paternity leave then catching up) - but just 
responding to points points below...

> Regarding the French/FÉR/Anass comments:
> #1 - the barrier is set at 1 member to ensure use of a service - it is 
> hoped that other members will take advantage of this service - but to wait 
> until 2 university (full) members are willing to subscribe or purchase a 
> service might delay the adoption of a federated service - so no change 
> needed.

I actually fundamentally disagree that if a service is only used by one IdP 
it shouldn’t be on the federation, and I’d push back quite heavily against 
that suggestion.

The UKf only requires a single sponsor for a service, and actively encourage 
registering services even if only one org cares about it.

What happens if you require multiple sponsors is that each entity now has to 
engage in bilateral MD exchange with services, and make sure it’s kept up to 
date. It also encourages services to think that bilateral MD exchange is ok, 
when it’s just a big pain in the behind for everyone involved and gets the 
administrators of those services into the wrong mindset from the very 
beginning.

> #4 - eduPersonTargetedID is realtime generated and doesn’t need to be 
> specified (unless you think you should add it to section 5.4.2 of your 
> Attribute Profile 
> https://www.hkaf.edu.hk/images/policies/hkaf-attribute-profile-v1.pdf 
> you’ve answered to the fact that you only have CORE and RECOMMENDED 
> attributes - and there is no difference between HKAF and interfederation 
> requirements. It is clear that attribute interoperability and release is a 
> future area of collaboration.

I would suggest that persistent identifiers and/or eduPersonTargetedID should 
be called out specifically in any attribute profile for a federation. Just 
because some instances of software do it “automatically” (though that’s also 
not quite true), doesn’t mean it shouldn’t be included in the list. If it 
isn’t included, any entity can not configure it, or unconfigure it, and still 
be meeting all policy requirements. But their end users will have a hard time 
interacting with many services.

Better to over-specify than under-specify.



Rhys.
--
Dr Rhys Smith
Chief Technical Architect, Trust & Identity
Jisc

T: +44 (0) 1235 822145
M: +44 (0) 7968 087821
Skype: rhys-smith
GPG: 0x4638C985
Lumen House, Library Avenue, Harwell Oxford, Didcot, OX11 0SG

jisc.ac.uk

Jisc is a registered charity (number 1149740) and a company limited by 
guarantee which is registered in England under Company No. 5747339, VAT No. 
GB 197 0632 86. Jisc’s registered office is: One Castlepark, Tower Hill, 
Bristol, BS2 0JA. T 0203 697 5800.