Changes to the Requirements for SAML2 Identity Providers that are purely technical in nature must reach rough consenus/no opposition at the SAFIRE Participants’ Forum. Changes to the administrative requirements are synchronised with the Metadata Registration Practice Statement. This version reached rough consensus on ….
The following describes the technical and administrative checks that will be made before an identity provider is admitted into the SAFIRE federation within the SAML2 Technology Profile. It also serves as a checklist for identity provider operators for assessing their readiness to participate.
…
The eduPersonEntitlement attribute is used to indicate a user’s entitlement to access a specific service or resource. For example, its most widely used value, urn:mace:dir:entitlement:common-lib-terms, is used to indicate eligibility to access licensed content from information publishers.
Relationship to eduPersonScopedAffiliation Library information providers often support both eduPersonEntitlement and eduPersonScopedAffiliation as a means of limiting access to licensed resources.
…
The following describes the technical and administrative checks that will be made before an identity provider is admitted into the SAFIRE federation within the SAML2 Technology Profile. It also serves as a checklist for identity provider operators for assessing their readiness to participate.
Metadata MUST1 have an entityID that is a URL (well-known location). The URL SHOULD use the https scheme and it is RECOMMENDED that valid metadata be available at this URL. MUST use secure (https) end-points for any or . MUST contain elements detailing every possible scoping value (domain) for eduPersonPrincipalName and mail. These MUST NOT be regular expressions. All scopes MUST be valid DNS domain names and those domains MUST be owned by the organisation (or have written confirmation from the domain owner). MUST contain an element, where: MUST reflect the legal name of the juristic person. MAY reflect a commonly known or shortened version of the organisation’s name. SHOULD contain the organisation’s web site address. MUST contain at least one of contactType="technical" and SHOULD contain one of contactType="support". Where is given this SHOULD be a role account rather than an individual. SHOULD contain an , with at least the following elements set: — meaningful name for the identity provider. — short (max 140 chars) description of the purpose. It is RECOMMENDED that be set and point at the organisation’s privacy policy. This MAY be required in future. It is RECOMMENDED that a be provided. Any logo MUST be served from a secure (https) server. Logos SHOULD have an aspect ratio as close to 1:1 as possible and SHOULD be at least 100x100 pixels (although 300x300 is RECOMMENDED). SHOULD NOT contain a element (any existing one SHALL be removed by the federation aggregator). SAML certificates included in metadata SHOULD be self-signed. Web server certificates used for end-points MUST use PKI that is reasonably likely to be embedded in the browser of all users of the identity provider. Unless an explanation is provided, these SHALL be tested against the root CA lists of common browsers. Language and Localisation The SAML metadata specification allows display elements such as to be localised by using the xml:lang attribute to specify a BCP 47 language code. In common with other federations worldwide, English (xml:lang="en") MUST always be included and will be used as the default when no localised version is available.
…
The following describes the technical and administrative checks that will be made before an identity provider is admitted into the SAFIRE federation within the SAML2 Technology Profile. It also serves as a checklist for identity provider operators for assessing their readiness to participate.
Metadata MUST1 have an entityID that is a URL (well-known location). The URL SHOULD use the https scheme and it is RECOMMENDED that valid metadata be available at this URL.
…
This page documents the history of SAFIRE’s Requirements for SAML2 Identity Providers and will display the most recent version. You should always reference this page when linking to the Requirements for SAML2 Identity Providers, unless you intend to link to a specific, versioned document.
Changes to the Requirements for SAML2 Identity Providers that are purely technical must reach rough consensus/no opposition among SAFIRE’s service advisory group. Changes to the administrative requirements are synchronised with the Metadata Registration Practice Statement.
…