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

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

On 25 May 2018, at 14:22, Brook Schofield <Brook.Schofield AT geant.org> wrote:
> 
> All,
> 
> I present to you the application of: Malaysia / SIFULAN
> 
> their policy and MRPS is linked from their federation page 
> https://sifulan.my but for completeness you can find them here:
>  * Policy linked from https://sifulan.my/join.php (while titled DRAFT it 
> will be revised/approved as a result of this assessment).
>  * MRPS https://sifulan.my/download/SIFULAN-MRPS-v1.pdf 

Generally looks like it’s along the right lines, MDRPS only has some very 
minor issues, but I think the federation policy needs tweaking in several 
places:

-----
MDRPS:

Section 2 - "the Federation website at: https://SIFULAN© .my/metadata.php."

-> the URL for the federation has a copyright logo in it. I suspect that not 
to be correct…


Section 2: "An entity that does not include a reference to a registration 
policy MUST be assumed to have been registered under an historic, 
undocumented registration practice regime. Requests to re-evaluate a given 
entity against a current MRPS MAY be made to the Federation helpdesk.”

-> This is all fine for existing federations, and I have no issue with it 
being here (I assume it’s in the template, but too lazy to check) - but if 
this is a new federation, there should be no need for historically registered 
entities with no reg policy...



Section 3 - The MD non-normative example.

-> Not sure if it’s just on my mac, but it renders really weirdly… 
https://www.dropbox.com/s/3gdcc4hjjfnxeyh/Screenshot%202018-06-01%2010.04.20.png

-> Also, is it right that the registration policy name is 
"https://sifulan.my/join.php”? It seems to me that that won’t be very 
amenable to versioning should you wish to change the policy in the future and 
have a different name.



Section 5.1 - establishing the right to use a domain name via registration 
information in DNS.

-> This is not an issue with this specific edugain application, but one all 
of us are going to have to deal with - with GDPR coming into force, the 
information available to us through WHOIS is (can be) severely restricted, so 
we either have to insist that every potential member increases the visability 
of the details of their entries in WHOIS, or we’ll need to start doing more 
programmatic proof of control of a domain (e.g. add a TXT record for us, etc) 
alongside our traditional manual WHOIS checks.


-----
Federation Policy - on https://sifulan.my/join.php

-> One big one - end users do not join your federation, unless you want to 
have a direct contractual relationship and have them sign something 
individually. I don’t think you want to do that :-).


-----
Federation Policy - 
https://sifulan.my/download/SIFULAN-Federation-Policy-Draft-v1.pdf


Section 2, first paragraph:

-> you’ve capitalised "Federation Technologies” like it’s a term, but it 
doesn’t exist in the terminology section.


Section 2.2

-> In the terminology section, you describe a “federation member”, and then 
in 2.2 you introduce the term “subscriber” (which isn’t in the terminology 
section). What’s the relationship between the two, or are they the same 
thing? They seem to be used interchangeably throughout. If they’re the same, 
suggest you stick to just the one term. This is a problem throughout, so I 
won’t mention it again.

-> Subscribers are bound by the “Federation Constitution”. What’s that? It’s 
not defined anywhere, including in the terminology section. You have a 
Federation Policy though… 


Section 3.1 (and other mentions later)

-> You reserve the right to "Temporarily suspend individual Technology 
Profiles”, and in 3.2 members must comply with “the obligations of the 
technology profiles”. I can’t seem to find any technology profiles though… 
Have I just missed them, or do they not exist? If they don’t exist, it’s hard 
to comply with them.


Section 3.2 

-> Lots of “Shall” and “Must”s. Should these be “SHALL” and “MUST” or did you 
specifically decide that these aren’t RFC 2119?


Section 3.2 - “should report incidents within four (4) hours via email"

-> Federation members must report stuff within 4 hours, but no mention of 
when this applies - is this 4 hours within finding an issue 24/7/365?

-> On a related note: "Federation Operator will resolve appropriately within 
the next working day.” - you don’t define what a working day is anywhere.


Section 3.2 - “Prices and payment terms are specified in the appendix Fees.”

-> There is no appendix “Fees”


Section 3.2 - "Ensures an End User is committed to the Home Organization’s 
Acceptable Usage Policy.”

-> Seems a little unachievable to me. You can ensure they’ve signed up to the 
AUP, but to be “committed” to them seems rather strong and unmeasurable :-).


Section 3.2 - "If a Federation Member is acting as a:” (top of page 7)

-> …. as a what?


Section 5.1 - "pass technology implementation compliance test”

-> Is that test documented anywhere?


Section 5.2 - The Federation Operator may cancel its participation in the 
Federation by announcing the termination date to the Federation Members.”

-> Do you not want to give a minimum notice period, so that your members have 
some reassurance that you won’t decide to stop operating the federation as of 
the next day, or something?



Hope that helps!

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

Attachment: smime.p7s
Description: S/MIME cryptographic signature