Topics for conversation:
- What does it mean to have a federation policy in OIDFed? https://openid.net/specs/openid-federation-1_0.html#name-federation-policy
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 | |
| 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 goes to UK but .edu? Or a Norwegian school registered in Feide with a .ac.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 scpe 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.
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:
- OpenID Technical Profile Mapping
- Metadata Registration
- Metadata Production (entity not federation, everything is an entity). Is this simply statements around entity statement: https://openid.net/specs/openid-federation-1_0.html#name-entity-statement.
- Metadata Signing - are there any parameters we want to put on a sign JWT beyond algorithim?
- Participant requirements - out of scope, take up to metadata registration?
- Mandatory entity requirements (mandatory trust marks?). Is this just part of registration?