Changes to the Metadata Registration Practice Statement that are purely technical in nature must reach rough consenus/no opposition at the SAFIRE Participants’ Forum. All other changes are approved by the SAFIRE Steering Committee. This version reached rough consensus on 16 September 2016 and was ratified by the Steering Committee on …. There has been a subsequent minor revision to add acknowledgements.

Definitions and terminology

The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC 2119¹.

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

• MUST¹ 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 <md:SingleSignOnService> or <md:SingleLogoutService>.
• MUST contain <shibmd:Scope> 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 <md:Organization> element, where:
  • <md:OrganizationName> MUST reflect the legal name of the juristic person.
  • <md:OrganizationDisplayName> MAY reflect a commonly known or shortened version of the organisation’s name.
  • <md:OrganizationURL> SHOULD contain the organisation’s web site address.
• MUST contain at least one <md:ContactPerson> of contactType="technical" and SHOULD contain one of contactType="support". Where <md:EmailAddress> is given this SHOULD be a role account rather than an individual.
• SHOULD contain an <mdui:UIInfo>, with at least the following elements set:
  • <mdui:DisplayName> — meaningful name for the identity provider.
  • <mdui:Description> — short (max 140 chars) description of the purpose.
• It is RECOMMENDED that <mdui:PrivacyStatementURL> be set and point at the organisation’s privacy policy. This MAY be required in future.
• It is RECOMMENDED that a <mdui:Logo> 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 <mdrpi:RegistrationInfo> 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 <md:OrganizationName> 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.

Changes to the Privacy Statement are approved by the SAFIRE Steering Committee. This version reached rough consensus on 21 December 2016 and still needs to be ratified. As a revision to version v20160622, it includes a new section about website analytics.

Introduction

This document explains what personal information is collected by the South African Identity Federation (SAFIRE) and how it is used.

Changes to the Key Management Practice Statement must reach rough consenus/no opposition at the SAFIRE Participants’ Forum. This version reached rough consensus on ….

Definitions and terminology

The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC 2119¹.

Changes to the Participation Agreement are approved by TENET’s Board of Directors. This version reached rough consensus within the community and was subsequently ratified on 26 October 2016. As a revision of v20160916, it contains minor typographical edits and the insertion of one new clause at 6.5.

There are some notes on interpretation available to help decision makers.

Please sign and scan (or electronically sign) a copy of the Participation Agreement and email it to us. TENET is happy to accept scanned documents and/or electronic signatures, and will normally return an electronically signed copy to you.

The following describes the technical and administrative checks that will be made before a service provider is admitted into the SAFIRE federation within the SAML2 Technology Profile. It also serves as a checklist for service provider operators for assessing their readiness to participate.

Metadata

• MUST¹ 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 <md:AssertionConsumerService> or <md:SingleLogoutService>.
• MUST contain an <md:Organization> element, where:
  • <md:OrganizationName> MUST reflect the legal name of the juristic person.
  • <md:OrganizationDisplayName> MAY reflect a commonly known or shortened version of the organisation’s name
  • <md:OrganizationURL> SHOULD contain the organisation’s web site address.
• MUST contain at least one <md:ContactPerson> of contactType="technical" and SHOULD contain one of contactType="support". Where <md:EmailAddress> is given this SHOULD be a role account rather than an individual.
• MUST contain an <mdui:UIInfo>, with at least the following elements set:
  • <mdui:DisplayName> — meaningful name for service.
  • <mdui:Description> — short (max 140 chars) explanation of the purpose of the service, such that it is reasonably obvious why the attributes requested are required.
  • <mdui:PrivacyStatementURL> — web site containing a copy of the service provider’s privacy policy.
• It is RECOMMENDED that a <mdui:Logo> 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 <mdrpi:RegistrationInfo> element (any existing one SHALL be removed by the federation agregator)
• MUST contain <md:RequestedAttribute> entries.
• 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 service. 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 <md:OrganizationName> 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.

The following PDF document contains a final draft of SAFIRE’s Participation Agreement. This agreement has achieved rough consensus within SAFIRE’s membership, and is currently awaiting legal review. There are not likely to be any substantive changes to this document, but the review process may result in a further revision.

This version of the document was submitted to eduGAIN on 18 September 2016.

Management of attribute release to Service Providers has been delegated to the Federation Operator in terms of the Participation Agreement. Through a community consensus process, the following attribute release profiles have been approved:

Default

The release profile used when no other attribute release policy is defined:

This version of the Metadata Registration Practice Statement reached rough consensus on 16 September 2016.

Definitions and terminology

The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in [RFC2119].