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

["Cheng, Jonathan [ITS]" <jonathan.cheng AT polyu.edu.hk>]

Dear all

 

Thank you very much for the last comment from Anass, which is absolutely valid.  I would also like to thank Nick, Rhys and Pål for the follow-on comment and feedback. We have spent some time for internal discussion on this at HKAF and this is why we respond a little bit late.  I strongly agree with Rhys’ suggestion (shown below) that it is better to over-specify than under-specify the attribute requirements.  It is also true that our earlier saying that “Persistent NameID is automatically generated and released real-time by the Shibboleth IdP” is incorrect, which is dependent on the correct configuration.

 

<Suggestion of Rhys - Start>

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.

<Suggestion of Rhys – End>

 

We will review and amend our policy framework documents (including the Attribute Profile ) to address the eduPersonTargetedID /Persistent NameID related interoperability issue shortly. We welcome any suggestion on the best way to do this from other federations.

 

From the discussion on the application of HKAF to join eduGAIN in this mailing list, it seems that attribute interoperability issues need to be addressed both at intra-federation and inter-federation level during policy formulation for new federations.  It may also be worthwhile for the eduGAIN community to explore further how this can be handled more effectively.

 

Regards

Jonathan

 

 

 

From: Anass Chabli [mailto:anass.chabli AT renater.fr]
Sent: Wednesday, 11 October 2017 6:16 PM
To: Cheng, Jonathan [ITS] <jonathan.cheng AT polyu.edu.hk>
Cc: jiny92 <jiny92 AT kisti.re.kr>; edugain-discuss <edugain-discuss AT lists.geant.org>; Brook Schofield <Brook.Schofield AT geant.org>
Subject: Re: [eduGAIN-discuss] Assessment of Hong Kong/HKAF for eduGAIN membership

 

Hi Jonathan, 

 

Thank you for your detailed answers.

 

I have just a last comment bellow, regarding the last point (Attribute Profile).

 

Cheers, 

Anass

---

De: "Jonathan Cheng, ITS" <jonathan.cheng AT polyu.edu.hk>
À: "anass chabli" <anass.chabli AT renater.fr>
Cc: "jiny92" <jiny92 AT kisti.re.kr>, "edugain-discuss" <edugain-discuss AT lists.geant.org>, "Brook Schofield" <Brook.Schofield AT geant.org>
Envoyé: Mercredi 11 Octobre 2017 09:49:49
Objet: RE: [eduGAIN-discuss] Assessment of Hong Kong/HKAF for eduGAIN membership

 

Hi Anass

 

Thank you very much for your comments /questions /recommendations.  Our responses are provided below in bolded dark blue text in larger font.

 

Please feel free to let us know if you have further questions or comments.

 

Cheers

Jonathan

 

 

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.

 

#2 - This one is interesting:

 

https://www.hkaf.edu.hk/images/policies/hkaf-eligibility-policy-v1.pdf has a reference in 5.1 and talks about 3.3b above (but there isn’t a 3.3b above- I think you mean 4.3b).

Since you state “MUST itself qualify” - so it needs to qualify - and it doesn’t actually HAVE to join as an associate member. I don’t think this is in conflict. The “reputation” statement in 4.3b is something like - if a company that has a data breach is an outsourced provider - you’d want to have confidence in this organisation - even though your direct relationship is with the FULL member. I think it is a reasonable request. You’re not saying you want a relationship with the outsource providers - more that it is a reminder to FULL members that they have to keep their outsource partners in line.

 

#3 - Answered in your previous email (2nd response to Jinyong) - so it can be regarded as dealt with.

 

#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 think that you only need to correct the 3.3b —> 4.3b typo and nothing else - everything can be explained with words.

 

 

From: Anass Chabli [mailto:anass.chabli AT renater.fr]
Sent: Tuesday, 10 October 2017 4:43 PM
To: Cheng, Jonathan [ITS] <jonathan.cheng AT polyu.edu.hk>
Cc: jiny92 AT kisti.re.kr; edugain-discuss AT lists.geant.org; Brook Schofield <Brook.Schofield AT geant.org>
Subject: Re: [eduGAIN-discuss] Assessment of Hong Kong/HKAF for eduGAIN membership

 

Hi Jonathan,

 

I found that policies are well detailed and covers the key issues.

 

Here are some Comments/questions/recommendations:

 

    1-   5.1 Outsourcing the Operation of Identity Provider : The ASSOCIATE membership of an organization MUST be sponsored by a FULL Member.

                  - If we assume that an associate membership main purpose is to provide federated services, it would make more sens to require at least to be sponsored by more than 1 full Member, to ensure that the service is legitimate to be in the federation. 

                 If it’s intended to be used only by one member they don’t realy need to be in the federation.

 

This is for the scenario in which the service provider organization provides the service to a Federation Member in the form of federated service via HKAF, which is also open for adoption by other Members later.  The membership sponsorship quorum is set to 1 for the following reasons:

·      To ensure the Federation Member can adopt the service without the delay caused by having to wait for the sponsorship of additional Members, otherwise.

·      To open the opportunity for other Federation Members to take advantage of the service at a later stage easily.

 

     2-  5.1 Outsourcing the Operation of Identity Provider : While this outsourcing agreement is in operation, the third-party organization MUST itself qualify as an ASSOCIATE Member of the Federation

                - By definition ASSOCIATE Members MAY only deploy Service Providers. Why do you require a contract with an ASSOCIATE Member that operates an IdP ? If we assume that the IdP Operator refers to the legal Home Organization they are already reponsible for the overall processes supporting the IdP.

                 While Outsourcing an IdP, I don’t think It’s up to the federation to have contact or a contract with the third-party organization that provides services on behalf the Home Organization.

 

I would like to apologize that there is a typo error in section 5.1a of the HKAF Eligibility Policy (https://www.hkaf.edu.hk/eligibility-policy) as shown below:

5.1a   A FULL Member is permitted to outsource to a third-party organization the operation of its Identity Provider. While this outsourcing agreement is in operation, the third-party organization MUST itself qualify as an ASSOCIATE Member of the Federation, specifically by meeting the criteria set out in 3.3b above.

 

·      ‘3.3b’ should be ‘4.3b’ instead.

Section 4.3b states the following:

4.3b   The admission of an organization as an ASSOCIATE Member MUST not present any substantive risk to the Federation’s reputation (an example of a substantive risk to the Federation would be one organization’s membership causing another member organization to review its membership because of potential damage to its reputation).

 

·      Section 5.1a only states that the third-party organization MUST QUALIFY as an ASSOCIATE Member.  It DOES NOT MANDATE the REGISTRATION of the third-party organization as ASSOCIATE Member.

o   The objective is to provide HKAF the confidence in the third-party organization even though the direct relationship is with the FULL Member who owns the IDP. (It may be possible that the third-party organization had a data breach before.)

o   In effect, it serves as a reminder to FULL Members that they have to keep their outsource partners in line.

 

     3- 10.7 Data Privacy and Protection of Personal Rights :

              - Is there any obligation for IdP/SP operators to publish a privacy and data protection policy (for each service) and make it available for End User ?

 

The second and third rules in the HKAF Service Provider Management Standard at https://www.hkaf.edu.hk/sp-management-standard address the ‘Data Protection obligation’ (referencing the HKAF Data Protection Profile at https://www.hkaf.edu.hk/data-protection-profile) and ‘Information duty towards End User’ (covering a Privacy Policy) obligation for each Service Provider registered in HKAF.

 

 

     4-  Regarding the Attribute Profile :

               -I think one core attribute (for Hkaf and Interfederation) is missing :  the eduPersonTargetedID/persistentID , used to identify each user individually, in eduGAIN for example some services requires this attribute.

               -It would be good to distinguish more clearly between attributes for HKAF and Interfederation:

                   -HKAF Core attributes 

                   -HKAF Other attributes 

                   -Interfederation Core Attributes

                   -Interfederation Other Attributes

 

·      persistentID is automatically generated and released real-time by the Shibboleth IdP and is therefore not specified as a HKAF Core Attribute.

Yes, if we assume that all IdPs registered are Shibboleth IdPs, and are configured to store/release the persistentID properly. Otherwise if the Home Organization is using an other Identity Provider solution, they may need to deal with this attribute too.  

·      We only have CORE and RECOMMENDED attributes, and there is no difference in attribute requirements between HKAF and Interfederation.

 

Cheers, 

Anass

 

---

De: "Cheng, Jonathan [ITS]" <jonathan.cheng AT polyu.edu.hk>
À: jiny92 AT kisti.re.kr
Cc: edugain-discuss AT lists.geant.org, "Brook Schofield" <Brook.Schofield AT geant.org>
Envoyé: Mardi 10 Octobre 2017 06:40:36
Objet: RE: [eduGAIN-discuss] Assessment of Hong Kong/HKAF for eduGAIN membership

 

Hi Jinyong

Thank you very much for your feedback.

Our responses to your feedback are provided below in bolded purple texts in larger font.  Please feel free to let us know if you have further questions or comments.

Cheers

Jonathan

 

 

From: 振溶[Jinyong Jo] [mailto:jinyong.jo AT gmail.com]
Sent: Tuesday, 10 October 2017 11:49 AM
To: Cheng, Jonathan [ITS] <jonathan.cheng AT polyu.edu.hk>
Cc: edugain-discuss AT lists.geant.org; Brook Schofield <Brook.Schofield AT geant.org>
Subject: Re: [eduGAIN-discuss] Assessment of Hong Kong/HKAF for eduGAIN membership

 

Hello Jonathan,

 

My apologizes for late return. Korea's 10-day holidays just ended yesterday.

 

Comments/questions/recommendations:

 

1. 7-core attributes

Does a Korea institution (namely, a foreign full member) have to provide at least 7-core attributes if it wants to federate with a HKAF associate member via eduGAIN? 

 

No.  The HKAF Federation Policy only mandates the Home Organizations (i.e. the HKAF Full Members) to collect or generate the 7 Core Attributes for their End Users in their IdPs.  The policy does not mandate the HKAF Members to release all of the 7 Core Attributes in their IdPs.  Furthermore, the 2^nd rule in the HKAF Identity Provider Management Standard (https://www.hkaf.edu.hk/idp-management-standard) states that: “The Home Organization MAY ONLY release Attributes from its Identity Provider to a Service Provider, or another Identity Provider, with the permission of the End User.”

 

Furthermore, this policy only applies to the IdPs registered by HKAF Members, but not to the other IdPs connected via eduGAIN.

For the scenario that you mentioned, the Korea institution just has to release (provide) the attributes that the Service Provider of the HKAF Associate Member requests via eduGAIN (of course with User Consent).

 

2. eduPersonAssurance

Except for an example, it is hard to find any documents describing the format (a URN) of the attribute. Does HKAF use the same URN format as AAF has, and/or allow level 1 only? 

 

We will register the HKAF Level-1 Identity Assurance Profile in the IANA LoA profile shortly in Oct 2017.  It will be similar to the SWAMID Level-1 assurance profile.

 

 

It seems that HK has very similar data-protection/privacy-policy laws, including code of conducts, with Korea. For us, notifying items and getting user consent are essential before transmitting individual user information to domestic/foreign SPs. We leverage privacy policy statement to notify several items in [4.c.Information duty [1]] to end user. I hope HKAF encourages federation members to use the metadata element <mdui:PrivacyStatementURL>.

 

[1] HKAF Service Provider Management Standard, p. 5

 

We will definitely do so.

 

 

Cheers,

Jinyong Jo

KAFE/KISTI

 

 

2017-10-03 17:38 GMT+09:00 Cheng, Jonathan [ITS] <jonathan.cheng AT polyu.edu.hk>:

Hi Jinyong

 

Thank you very much for your questions and comments.

 

I am Jonathan Cheng from the Hong Kong Polytechnic University.  I am the Team Lead of the HKAF Operator Team, with members from the JUCC office and five JUCC Full Member Institutions.

 

Our responses to your questions and comments are provided below in bolded green texts in larger font.  Please feel free to let us know if you have further questions or comments.

 

Cheers

Jonathan

 

 

From: 振溶[Jinyong Jo] [mailto:jinyong.jo AT gmail.com]
Sent: Monday, 2 October 2017 10:07 AM
To: edugain-discuss AT lists.geant.org
Cc: Brook Schofield <Brook.Schofield AT geant.org>
Subject: Re: [eduGAIN-discuss] Assessment of Hong Kong/HKAF for eduGAIN membership

 

Hello HKAF,

 

I think, the overall documents are well organized and the policies are clearly described.

 

My questions/comments:

 

1.     It seems that SAML WebSSO Technology Profile is not posted on the web site.

 

The HKAF SAML WebSSO Technology Profile has been uploaded and is now available on the website. (Thank you for reminding us.)

 

2.     Compelling "Federation members MUST collect and generate HKAF Core Attributes [1]" would act as a barrier when eduGAIN-federated IdPs try to access any relying parties held by HKAF's Associate Members. It will be better if HKAF relaxes the compulsory clause to the level of Attribute Bundle in REFEDS R&S Category [2].  

 

The HKAF Federation Policy mandates the Home Organizations to collect or generate the 7 Core Attributes for their End Users in their IdPs, in order to make it sufficient for the deployment of the majority of SPs in most of the cases. In fact, the 4 yellow-shaded attributes are addressing the required and optional data elements specified in the REFEDS R&S attribute bundle.

·      eduPersonAffiliation

·      eduPersonScopedAffiliation

·      eduPersonAssurance

·      eduPersonPrincipalName

·      cn (commonName)

·      displayName

·      mail

 

Furthermore, the HKAF Data Protection Profile defines the attribute processing principles that the deployment of SP must follow.  The second principle states that:

‘The SP Organization agrees and warrants for all of its SPs to minimize the Attributes requested from a Home Organization to those that are adequate, relevant and not excessive for enabling access to the service and, where a number of Attributes could be used to provide access to the service, use the least intrusive Attributes possible. [Data minimization]’

HKAF encourages members (Associate or Full) to adopt the ‘data minimization’ principle in the deployment of their SPs, from the consideration of data protection as well as making it easier for target IdPs to support. Basically, the SP organizations would not request for all available attributes of the End User just because the IdPs will provide them on user consent.

 

3.     Especially for eduPersonAssurance [3], how about letting SPs determine required level of LoA and control access by themselves, instead of enforcing the mandatory use of the attribute? 

 

The HKAF Federation Policy only asks Home Organizations to generate the eduPersonAssurance attribute for their End Users in the IdPs in accordance with the HKAF Identity Assurance Profile.  It is totally up to the SPs to determine the required Identity Assurance Level for access authorization.

 

4.     I wonder what the exact meaning of the 'sponsored' in the sentence "The associated membership of an organization must be sponsored by a full member [4]" and how HKAF can verify the eligibility of the sponsored membership. It seems likely that foreign SPs will be federated very limitedly depending on the meaning.

 

It means that the application of HKAF Associate membership by the organization must be supported by a HKAF Full Member organization, but not in the sense of finance.  A typical scenario is that a HKAF Full Member institution sponsors the HKAF Associate membership application of another organization for registering and connecting SPs to HKAF for providing services to support R&E of the institution.  However, this does not affect the access to SPs already registered with other federations.

 

5.     I just want to know target applications/services HKAF pursues. The strict policy and profiles are fully understandable If the federated use of supercomputers or hpc resources is an ultimate goal. However, i would like HKAF to slightly mitigate the compelling stuff to accept wide variety of SPs.

 

The primary sector of applications /services which HKAF targets to pursue is Research and Education. The approach we have adopted in formulating our policy framework is to strike a balance between ‘making it very easy for organizations to register IdPs and SPs for connecting to the federation’ and ‘providing confidence and peace of mind to our potential members and our peer international federations on the level of security and data protection practices adopted by HKAF and its members’.  We would like End Users affiliated with HKAF members to be regarded by all federations as first-class trust-worthy netizens. Furthermore, SPs registered with HKAF can be trusted by Home Organizations all over the world.  We will continuously monitor the development of the global federation ecosystem and make necessary adjustment to our policy framework in the future.

 

[1] Hong Kong Access Federation (HKAF) Federation Policy, p. 15

[2] REFEDS, https://refeds.org/category/research-and-scholarship

[3] Hong Kong Access Federation (HKAF) Attribute Profile, p. 6

[4] Hong Kong Access Federation (HKAF) Eligibility Policy, p. 5

 

Cheers,

Jinyong JO,

KAFE/KISTI

 

2017-09-28 23:28 GMT+09:00 Brook Schofield <brook.schofield AT geant.org>:

All,

I present to you the application of:
 * Hong Kong/HKAF

 

who has Signed the eduGAIN Declaration, has a policy based on the federation policy template that covers all the prescribed areas with extensions into useful areas, is self declaring their federation as a production service and is wanting to join the global R&E federated environment. To provide guidance on your assessment I’ve performed a summary (attached) of their policy.

You can find more detailed information about the federation under "eduGAIN Candidates” at
    https://technical.edugain.org/status.php

which contains links to their policy and MRPS (which doesn’t follow the MRPS template but does address Home Organisation, IdP and SP registration and production of @scope).

This application is from an organisation that is closely aligned with the GÉANT community via their participation in the APAN and Asi@Connect/TEIN communities. The development of this federation has been supported by the Australian Access Federation (AAF). They are also the eduroam .hk roaming operator.

So I ask the following federations to specifically review the submission by HKAF:

 * France / FÉR

 * Japan/GakuNin

 * Korea/KAFE

 * Latvia / LAIFE

 * Lithuania / LITNET FEDI

 

All eduGAIN members can (and should) provide feedback on this.

If you have any questions please contact the HKAF team that are subscribed to this mailing list.

 

This announcement of the assessment of a federation is new to the eduGAIN-Discuss mailing list. It is hoped that this platform will allow the free flow of information between commenters and the HKAF team (which wasn’t possible when this discussion was only on the eduGAIN Steering Group (eSG) mailing list. Formal components of the membership process will continue on the eSG list. Hopefully this will be an improvement to the membership process. 

 

My intention is to call a vote to accept Hong Kong/HKAF as a member after I’ve received confirmation from at least 3 of the specific federations that this policy is inline with their expectations.

Thanks,

 

Brook Schofield
eduGAIN Steering Group Chair
GÉANT

M: +31651553991 
Skype: brookschofield

www.polyu.edu.hk/80anniversary

Disclaimer:

This message (including any attachments) contains confidential information intended for a specific individual and purpose. If you are not the intended recipient, you should delete this message and notify the sender and The Hong Kong Polytechnic University (the University) immediately. Any disclosure, copying, or distribution of this message, or the taking of any action based on it, is strictly prohibited and may be unlawful.

The University specifically denies any responsibility for the accuracy or quality of information obtained through University E-mail Facilities. Any views and opinions expressed are only those of the author(s) and do not necessarily represent those of the University and the University accepts no liability whatsoever for any losses or damages incurred or caused to any party as a result of the use of such information.

 

www.polyu.edu.hk/80anniversary

Disclaimer:

This message (including any attachments) contains confidential information intended for a specific individual and purpose. If you are not the intended recipient, you should delete this message and notify the sender and The Hong Kong Polytechnic University (the University) immediately. Any disclosure, copying, or distribution of this message, or the taking of any action based on it, is strictly prohibited and may be unlawful.

The University specifically denies any responsibility for the accuracy or quality of information obtained through University E-mail Facilities. Any views and opinions expressed are only those of the author(s) and do not necessarily represent those of the University and the University accepts no liability whatsoever for any losses or damages incurred or caused to any party as a result of the use of such information.

 

www.polyu.edu.hk/80anniversary

Disclaimer:

This message (including any attachments) contains confidential information intended for a specific individual and purpose. If you are not the intended recipient, you should delete this message and notify the sender and The Hong Kong Polytechnic University (the University) immediately. Any disclosure, copying, or distribution of this message, or the taking of any action based on it, is strictly prohibited and may be unlawful.

The University specifically denies any responsibility for the accuracy or quality of information obtained through University E-mail Facilities. Any views and opinions expressed are only those of the author(s) and do not necessarily represent those of the University and the University accepts no liability whatsoever for any losses or damages incurred or caused to any party as a result of the use of such information.

 

www.polyu.edu.hk/80anniversary

Disclaimer:

This message (including any attachments) contains confidential information intended for a specific individual and purpose. If you are not the intended recipient, you should delete this message and notify the sender and The Hong Kong Polytechnic University (the University) immediately. Any disclosure, copying, or distribution of this message, or the taking of any action based on it, is strictly prohibited and may be unlawful.

The University specifically denies any responsibility for the accuracy or quality of information obtained through University E-mail Facilities. Any views and opinions expressed are only those of the author(s) and do not necessarily represent those of the University and the University accepts no liability whatsoever for any losses or damages incurred or caused to any party as a result of the use of such information.