This template document is licensed under Creative Commons CC BY 3.0. You are free to share, re-use and adapt this template as long as attribution is given. This document draws on work carried out by the UK Access Management Federation and the ACOnet Identity Federation with gratitude.
1. 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 [RFC2119].
The following definitions are used in this document:
- Federation: Identity Federation. An association of organizations that come together to securely exchange information as appropriate about their users and resources to enable collaborations and transactions.
- Federation Participant/Participant: An organization that has joined the Federation by agreeing to be bound by the Federation Policy in writing.
- Federation Operator: Organization providing the infrastructure for Authentication and Authorization to Federation Participants.
- Federation Policy: A document describing the obligations, rights and expectations of the Federation Participants and the Federation Operator.
- Entity: A discrete component that a Participant wishes to register and describe in metadata. This is typically an Identity Provider or Service Provider.
- Registry: System used by the Federation Operator to register Entity metadata. This may be via a self-service tool or via other manual processes.
- Registered Representatives: Individuals authorized to act on behalf of the Participant. These may take on different roles with different rights attached to them.
2. Introduction and Applicability
This document describes the metadata registration practices of the Federation Operator with effect from the publication date shown on the cover sheet. All new Entity registrations performed on or after that date SHALL be processed as described here until the document is superseded.
This document SHALL be published on the Federation Operator’s website here. Updates to the documentation 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 Metadata Registration Practice Statement (MRPS) MAY be made to the Federation Operator’s helpdesk.
3. Participant Eligibility and Ownership
Participants of the Federation are eligible to request changes to their Entity in the Federation Operator’s registry through their authorized contacts. Registration requests from other sources SHALL NOT be accepted.
The procedure for becoming a participant of the Federation is documented at: https://www.canarie.ca/identity/join
The application procedure verifies that the prospective Participant has legal capacity, and requires that each Participant enters into a contractual relationship with the Federation Operator by agreeing to the Federation Participation Agreement. The Operator makes checks based on the legal name provided.
The application process also identifies and verifies Registered Representatives, who are permitted to act on behalf of the organization in dealings with the Federation Operator. Verification is achieved by direct contact, prior relationship with CANARIE or by consulting the organization’s online staff directory.
The process also includes the identification of the legal name for the Federation Participant. The legal name of a Participant MAY change during the membership period, for example as a result of corporate name changes or mergers. The Participant’s legal name is disclosed in the Entity’s <md:OrganizationName> element [SAML-Metadata-OS].
4. Metadata Format
Metadata for all entities registered by the Federation Operator SHALL make use of the [SAML-Metadata-RPI-V1.0] metadata extension to indicate that the Federation Operator 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:
<mdrpi:RegistrationInfo
registrationAuthority="http://www.canarie.ca"
registrationInstant="2018-12-31T13:39:41Z">
<mdrpi:RegistrationPolicy xml_lang="en">
http://www.canarie.ca/doc/MRPS20181231</mdrpi:RegistrationPolicy>5. Entity Eligibility and Validation
Entity Registration
The process by which a Federation Participant can register an Entity is described at https://www.canarie.ca/identity/join
The Federation Operator SHALL verify the Participant’s right to use particular domain names in relation to entityID attributes.
The right to use a domain name SHALL be established in one of the following ways:
- A Participant’s legal name matches registrant information shown in
- A Participant MAY be granted the right to make use of a specific domain name through a permission letter from the domain owner on a per-Entity Permission SHALL NOT be regarded as including permission for the use of sub-domains.
EntityID Format
Values of the entityID attribute registered MUST be an absolute Uniform Resource Identifier (URI) using the http, https or urn 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.
Scope Format
For Identity Provider entities, scopes MUST be rooted in the DNS domain namespace, 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 Participant’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 public suffix – that is, a literal ‘.’, followed by at least two DNS labels separated by literal ‘.’ (representing a domain to be validated as “owned” by the Entity owner), and ending with a ‘$’ anchor (e.g. (foo | bar).example.com$).
Entity Validation
On Entity registration, the Federation Operator SHALL carry out Entity validation checks. These checks include:
- Ensuring all required information is present in the metadata;
- Ensuring metadata is correctly formatted; and
- Ensuring protocol endpoints are properly protected with TLS / SSL
Entity Management
Once a Participant has joined the Federation, any number of entities MAY be added, modified or removed by the organization.
Entity Change Requests
Any request for Entity addition, change or removal from Federation Participants needs to be communicated from or confirmed by their respective Registered Representatives.
Communication of change happens via e-mail communication to [email protected] by designated contacts.
Unsolicited Entity Changes
The Federation Operator may amend or modify the Federation metadata at any time in order to:
- Ensure the security and integrity of the metadata;
- Comply with interFederation agreements;
- Improve interoperability; or
- Add value to the metadata
Changes will be communicated to the appropriate Registered Representative(s) for the Entity.