You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 6 Current »

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
1There 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
3


  • Report on slack conversation regarding registration and scopes. 

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? 

  • Syntax of scopes. This is currently only described on the Shibboleth.  SAML Subject Identifiers defines syntax for scopes. This is currently only for SAML Subject identifiers that could be adapated for all scoped attributes. 
  • Issues with regex.

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:

  • We care that the entity has some sort of (legal?) claim over the domains / scope that they publish - own or delegated control.
  • We care that this information is changed in a managed way.
  • We care that the entity has some sort of formalised relationship with the federation ("member").
  • We care that the federation has taken some responsibility for the statements made. 

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

  • Elements of the policy:
  • No labels