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 1 January 2019 and was ratified by the Steering Committee 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 BCP 14¹.

Federation, Identity Federation: An association of organisations that come together to securely exchange information as appropriate about their users and resources to enable collaborations and transactions.

South African Identity Federation, SAFIRE: A federation established to serve the South African research and education community, and operated by TENET NPC.

Federation Participant: An organisation that has joined the Federation by completing and signing a participation agreement in writing. Federation participants MAY also be members of the Federation governance structures.

Federation Operator: Organisation providing the infrastructure for Authentication and Authorisation to Federation Participants.

Entity: A discrete component that a participant wishes to register and describe in metadata. This is typically an Identity Provider or Service Provider.

Registered Representatives: Individuals authorised to act on behalf of the participant. These may take on different roles with different rights attached to them.

Introduction

This document describes the metadata registration practices of the South African Identity Federation (SAFIRE) with effect from the publication date.

All new entity registrations performed on or after that date SHALL be processed as described here until the document is superseded.

This most recent version of document SHALL be published on the Federation website at https://safire.ac.za/safire/policy/mrps/. Updates to the document SHALL be accurately reflected in entity metadata.

An entity that does not include a reference to a registration policy MUST be assumed to have been registered under an historic, undocumented registration practice regime. Requests to re-evaluate a given entity against a current MRPS MAY be made to the Federation Operator.

Participation eligibility

Participants in the South African Identity Federation are eligible to make use of SAFIRE’s registrar to register entities. Requests from other sources SHALL NOT be considered.

All participants MUST sign an appropriate participation agreement. Copies of the template agreement, and the process for becoming a participant are documented at https://safire.ac.za/safire/policy/participation/.

The Federation Operator will consider requests from service providers to become participants only after they’ve shown the support of at least one participating identity provider, which MAY be the same organisation. In general it is expected that service providers SHOULD be domiciled or have substantive representation in the Republic of South Africa. However requests from international parties MAY be considered if there is no viable alternative Federation or if technical considerations require it.

The registration process attempts to verify the legal status of prospective participants against public records such as the higher education management information system, the companies register, or tax registration. In cases where the participant is already a participant in the South African NREN, these processes MAY be short-circuited.

The process also establishes a canonical name for the Federation Participant. The canonical name of a participant MAY change during the participation period, for example as a result of corporate name changes or mergers. The participant’s most recent recorded canonical name is disclosed in the entity’s <md:OrganizationName> element.

Metadata format

Metadata for all entities registered by SAFIRE SHALL make use of the SAML-Metadata-RPI-V1.0² metadata extension to indicate that SAFIRE is the registrar for the entity and to detail the version of the MRPS statement that applies to the entity. The following is a non-normative example:

<md:Extensions
 xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata"
 xmlns:mdrpi="urn:oasis:names:tc:SAML:metadata:rpi">
  <mdrpi:RegistrationInfo
   registrationAuthority="https://safire.ac.za"/>
  <mdrpi:RegistrationPolicy>https://safire.ac.za/safire/policy/mrps-v20160901</mdrpi:RegistrationPolicy>
</md:Extensions>

Entity Eligibility and Validation

Entity Registration

The Federation Operator SHALL verify the participant’s right to use particular domain names in relation to entityID attributes and scoping elements.

The right to use a domain name SHALL be established in one of the following ways:

• A participant’s canonical name matches the registrant information shown in public whois records held by the DNS registrar.
• A DNS registrar confirms the participant’s eligibility from privately-held information.
• A participant MAY be authorised to make use of a specific domain name in writing from the domain owner on a per-entity basis. Such authorisation SHALL NOT be regarded as including authorisation for use of sub-domains.

EntityID Format

Values of the entityID attribute registered MUST be an absolute URI using the http or https schemes. https-scheme URIs are strongly RECOMMENDED to all participants.

http-scheme and https-scheme URIs used for entityID values MUST contain a host part whose value has corresponding resource records in the domain name system.

Scope Format

For Identity Provider entities, scopes MUST be rooted in the DNS domain name space, expressed in lowercase. Multiple scopes are allowed.

Regular expressions representing multiple scopes MAY be used, but all DNS domains covered by the expression SHALL be included in checks by the Federation Operator for the member’s right to use those domains. For these checks to be achievable by the Federation Operator, the set of DNS domains covered by the regular expression MUST end with a domain under a suffix listed in the Public-Suffix-List³ — that is, a literal ‘.’, followed by at least two DNS labels separated by literal ‘.’s (representing a domain to be validated as “owned” by the entity owner), and ending with a ‘$’ anchor (e.g. (foo|bar)\.example\.ac\.za$).

Entity Validation

On entity registration, the Federation Operator SHALL carry out entity validation checks. These checks MAY include:

• Ensuring all required information is present in the metadata;
• Ensuring metadata is correctly formatted;
• Ensuring URLs specified in the metadata are technically reachable;
• Ensuring protocol endpoints are properly protected with TLS / SSL certificates

Entity Categories

Entities that meet the registration criteria for the Research-and-Scholarship-v1.2⁴ entity category MAY request that their metadata reflect this.

Other entity categories MAY be introduced or supported on request, subject to participants demonstrating to the Federation Operator’s satisfaction that they meet the appropriate eligibility criteria.

Entity Management

Any request for entity addition, change or removal from Federation participants MUST be communicated from or confirmed by their respective Registered Representatives. Communication of change happens via email.

In addition, the Federation Operator MAY amend or modify the Federation metadata at any time in order to:

• Ensure compliance with this MRPS;
• Ensure the security and integrity of the metadata;
• Comply with inter-Federation agreements;
• Improve interoperability;
• Add value to the metadata.

Depending on the scope of such changes, they MAY be communicated to the Registered Representatives for the entity.

Inter-federation

The Federation Operator may make metadata from its registry available to other federations for the purposes of inter-federation. Service Provider entities MUST explicitly opt in before their metadata is re-published in this way. Identity Provider and Attribute Authority entities MAY opt out if they do not wish for their metadata to be published in this way. The Federation’s own metadata SHALL always be re-published.

Limitations

Most of the organisational and metadata checks are carried out manually. The Federation Operator will not knowingly introduce errors, but cannot be held responsible should any inadvertently be included in published metadata. Metadata is used at the consumer’s risk.

Acknowledgements & License

Parts of this work has been derived from works of others, including the REFEDS MRPS template⁵ document. This work is licensed under a Creative Commons Attribution 4.0 International License.

References