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

[Pål Axelsson <pax AT sunet.se>]

> -----Ursprungligt meddelande-----
> Från: Rhys Smith [mailto:Rhys.Smith AT jisc.ac.uk]
> Skickat: den 13 oktober 2017 01:25
> Till: Cheng, Jonathan [ITS] <jonathan.cheng AT polyu.edu.hk>
> Kopia: Anass Chabli <anass.chabli AT renater.fr>; jiny92 AT kisti.re.kr;
> edugain-
> discuss AT lists.geant.org; Brook Schofield <Brook.Schofield AT geant.org>
> Ämne: Re: [eduGAIN-discuss] Assessment of Hong Kong/HKAF for eduGAIN
> membership
>
> 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.

+1 on this. We see a lot of cases where IdP administrators can't handle
metadata administration on their own and heavily rely on the federation to
handle the metadata.

Pål

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