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 … 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, 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 process by which a Federation Participant can register an entity is described at: https://safire.ac.za/participants/

EntityID Format

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

http-scheme and https-scheme URIs used for entityID values MUST contain a host part whose value is a DNS domain.

The right to use a URI in an entityID SHOULD be established in one of the following ways:

• The Federation Participant demonstrates the right to use the host part of a URL by means of domain validation.
• In the case of software-as-a-service or cloud-hosted solutions that do not support adding entityIDs, all of the following apply:-
  1. The format of an entityID is well-known and contains a unique identifier for each specific instance. Such an identifier could be contained within the path or query subcomponents of a URL, or as a unique subdomain of the domain name identified in the host subcomponent;
  2. There is reasonable certainty that the unique identifier for an instant is both persistent and is not reassigned; and
  3. The instances’s unique identifier can be directly associated with the Participant in one of the following ways:
     • The solution provider has a lookup or API service that returns either the offical name of the Participant or a domain name the Participant has the right to use; or
     • A Registered Representative of the Participant attests to the Participant’s right to use the entityID; and can demonstrate operational control of the instance by means of login to a protected resource that displays both the instances’s unique identifier from the entityID, as well as the official name of the Participant or a domain name the Participant has the right to use.

Scope Format

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

The right to use a particular scope SHALL be established by means of domain validation.

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$).

Domain Validation

Where domain validation is required by this document, the Federation Operator will establish a Participant’s right to use a domain name in the following way(s):

• A Participant’s official name matches the registrant information shown in public WHOIS records held by the DNS registrar;
• A DNS registrar confirms the Federation Participant’s eligibility from privately-held information;
• A Registered Representative of the Participant attests to the Participant’s right to use the domain name; and can demonstrate operational control of the domain name by completing Domain Control Validation ⁴ using any of the mechanisms commonly accepted by public certification authorities.
• 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.

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 Federation Participants demonstrating to the Federation Operator’s satisfaction that they meet the appropriate eligibility criteria.

Entity Management

Once a Participant has joined the Federation any number of entities MAY be added, modified or removed by the organisation.

Entity Change Requests

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.

Unsolicited Entity Changes

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