1. Status of policy testing in OIDF pilot: https://raw.githubusercontent.com/GEANT/edugain-oidf-pilot/refs/heads/main/resources/metadata_policies/edugain-metadata-policy-v01.json
  2. Suggestions for federation policy areas from pilot so far:
    1. Usage of client secrets
    2. Algorithms 
    3. Client Registration methods
    4. Authorization flows (ban Hybrid and Implicit Flows)
  3. Policy to only include testable parameters?
  4. SAML Changes
    1. Increase length of public keys - see Alex's presentation from Townhall
    2. Require security contact, privacy notice and https://refeds.org/assurance. 
    3. More on registration? Is this possible?

Policy Testing

How do we want to extend the test? Solved some tests in lighthouse as to how the policy flows and is validated. Now moving out to look at testing some more technical parameters such as algorithms. In OIDF cannot require a specific RSA key size. Test will be limited to ECC - this is currently a technical limitation. 

Client authentication methods: can we prohibit client secrets? This is coupled with client registration methods - don't currently have a clear proposal for client registration methods. Issues around whether implicit registration methods can be used. 

There's a nice testing tool so you can see how these policies are being resolved. 

Key Size in SAML

About a third of entities currently would be deprecated in 2030 according to NIST.  Current SAML policy sets some requirements for SAML Metadata Producers - we are all in agreement that these will need to be increased and proposals should be made to change this section of the policy document (section 4). 

We need to make a decision as to whether we set a requirement for all entities at the eduGAIN level. 

Have an SSL Labs score above X? This is how InCommon have defined this in their baseline requirements.  Can something be actively checked against SSL labs? There are also issues with some of the requirements established for SSL Labs. 

How do we test for assurance? Spot checking entities could be an approach. 

Actions

Nicole / Davide to make proposed changes to SAML profile to cover 4b above.

Alex to make proposed changes to SAML profile to cover 4a above.

Nicole / Davide to work on proposed 2-pager with dates showing implementation requirements for the new items in the profile. 



  • No labels