UPDATE ......Confluence has now been updated to version 9.2.6. Please see following page for details and feedback about changes:
Updates
This is the start of a breakdown to look at what policy changes will be needed for eduGAIN in order to introduce OpenID Federation into the eduGAIN framework.
Current Section of SAML Technical Profile (https://technical.edugain.org/doc/eduGAIN-saml-profile.pdf) | Purpose | References | OpenID Interpretation (looking at: https://openid.net/specs/openid-federation-1_0.html and | Notes |
|---|---|---|---|---|
Overview | General overview of the document but framed in SAML language | Operational Practice Statement for SAML: Operational Practice Statement - SAML profile Metadata Aggregation Practice Statement for SAML: Metadata Aggregation Practice Statement eduGAIN Best Current Practice as a SHOULD (CoCo, Sirtfi, R&S). | ||
Metadata Registration Practice Statement | Information on expectations on how an entity can be registered into a federation metadata stream | Metadata Registration Practice Statement ShibMD for scope information | Current reliance on a non-machine readable document and we do not have any strong requirements over what is included, this is left to federations to describe local practice. Does this still meet objectives or is another approach required? Note it is only a template, not a set of standards / requirements. Current MRPS only speaks to SAML requirements. | |
SAML Metadata Production | Basic requirements on how federation metadata is formed and minimum standards for the metadata published by the federation The SAML Metadata root element MUST contain: A validUntil attribute with a value not earlier then 120 hours (5 days) and not later than 2304 hours (28 days) after the creationInstant. <mdrpi:PublicationInfo> with publisher and creationInstant. Each <md:EntityDescriptor> element MUST contain: <mdrpi:RegistrationInfo> . mdrpi:registrationAuthority with a value that has been registered with the eduGAIN Operational Team. <md:Organization> with values in English other values in the service's native languages for the elements where appropriate. <md:OrganizationName> . <md:OrganizationDisplayName> . <md:OrganizationURL> . <md:ContactPerson> with contactType="technical" and/or contactType="support" . entityID prefixes that start with either urn: , https:// , or http:// only. The <md:EntityDescriptor> SHOULD contain: <mdrpi:RegistrationPolicy> . If the <md:EntityDescriptor> contains <md:IDPSSODescriptor> it SHOULD contain an <mdui:DisplayName> element and <mdui:Logo> element. If the <md:EntityDescriptor> contains <md:SPSSODescriptor> it SHOULD contain an <mdui:DisplayName> element, <mdui:Logo> element and an <mdui:Description> element with a value in English. Where the service supports other languages, these values SHOULD be supported for those languages. If an <mdui:Logo> element is present, the logo MUST be expressed as a Data URI (embedded logo) or an https URL. URLs used for this element MUST be publicly accessible. | eduGAIN Metadata Aggregation Practice Statement md / mdui / mdrpi | Has some requirements for the overall federation metadata and also places some requirements on information about individual entities although the current focus is on information about the organisation and its identity. Would additional items (e.g. privacy notice, security contact) sit here? | |
SAML Metadata Signing | Requirements for metadata signing Public keys used for signing are at least 2048 bits in length. At least 3072 bits is RECOMMENDED for new deployments. EC public keys are at least 256 bits in length. The signature is made using an explicit ID reference, not an empty reference. The signature reference refers to the document element. The signature's digest algorithm is at least as strong as SHA-256, and does not use MD5 or SHA-1. The signature's signature method is RSA with an associated digest at least as strong as SHA-256 and does not use MD5 or SHA-1. The signature's transforms contain only these permissible values: Enveloped signature. Exclusive canonicalisation with or without comments. | SAML V2.0 Metadata Interoperability Profile Version 1.0 Metadata for the OASIS Security Assertion Markup Language (SAML) V2.0 eduGAIN Metadata Aggregation Practice Statement | signed JWTs SHOULD support signature verification with the RSA SHA-256 algorithm | |
SAML Metadata Publication | Information on how metadata should be published back to entities by federations and how it should be consumed | |||
Participant Federation Requirements | Basic how of registering the metadata set | mdrpi for registrationauthority | ||
Adherence | Process for monitoring and addressing non-compliance with the requirements set out Series of BCP are mentioned here - this is probably not the best approach and has little in terms of incentives to enforce | eduGAIN Metadata Validator | What would this look like for OIDC? | |
Mandatory Entity Requirements | This does not currently exist but the suggestion of introducing a privacy statement and Sirtfi as mandatory requirements would require this to be added. Should this be part of the metadata production requirements or separate? Proposed new requirements for SAML Profile: https://refeds.org/metadata/contactType/security mdui:PrivacyStatementURL https://refeds.org/assurance (e.g. core conformance criteria for baseline only) | n/a | Trust Marks? |