Topics for conversation:
HOMEWORK: read section 6 of the OIDFed spec above and bring your thoughts and ideas to the next meeting. You can also note these below:
| Questions | |
|---|---|
| 1 | There is a signed JWKS endpoint (signed_jwks_uri) we might want to require, rather than just TLS in the normal JWKS endpoint. Maybe we want to require that? |
| 2 | A policy operates by performing a check, a modification, or both on a given metadata parameter. We currently have limited abilities to perform some of the checks discussed. |
| 3 | Is the term member used consistently in the document? |
| 4 | NOTE: metadata_policy_crit OPTIONAL. Array of strings specifying critical metadata policy operators other than the standard ones defined in Section 6.1.3.1 that MUST be understood and processed. When included its value MUST NOT be the empty array []. If any of the listed policy operators are not understood and supported, then the Subordinate Statement and thus the Trust Chain that includes it MUST be considered invalid |
We've had several conversations about what we care about in terms of how we register organisations into federations and whether we actually check and police scopes.
Why do we register scopes?
Why do different scenarios allow for multiple scopes?
Regular Expressions don't work very well at the moment for various reasons.
How do we know how to police this? We can say that .ac.uk should probably go to UK but .edu? Or a Norwegian school registered in Feide with a .org.uk domain?
Should eduGAIN maintain an ALLOW list like we do with eduroam? This is challenging. We trust federation operators to do this, but this then changes when we have different entities published. We are purely reactive on scope checking.
How can we realistically change this and what checking can we request?
How do we put requirements on SPs? Can we enforce that they do scope checking?
Alex Stuart will share a word document on proposals for technical checks that could be made to support scope usage. See: 2026-03-16 Scope checking in eduGAIN.docx
What do we care about in terms of metadata registration:
This could form part of the Registration section in policy, and then a MRPS can be more focused on HOW each federation might implement those checks.
ACTION: consider adding statements around these elements to technical profiles (both SAML and OpenID).