Maeen Federation
Federation Operator Practice: Metadata Registration Practice StatementAuthors
Publication DateVersionMohamad M. Al-Ghamdi, Naser Almesad
2019-03-18
1.0LicenseThis template document is license under Creative Commons CC BY 3.0. You are free toshare, re-use and adapt this template as long as attribution is given. This document draws onwork carried out by the UK Access Management Federation and the ACOnet Identity
Federation with gratitude.

Table of Contents
1. Definitions and Terminology............................................................................................................. 3
2. Introduction and Applicability............................................................................................................4
3. Member Eligibility and Ownership................................................................................................... 5
4. Metadata Format................................................................................................................................ 6
5. Entity Eligibility and Validation..........................................................................................................7
6. Entity Management............................................................................................................................ 8
7. References.......................................................................................................................................... 9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 beinterpreted as described in RFC 2119 [RFC2119].
The following definitions are used in this document:
Federation

Federation Member
Federation Operator
Federation Policy
EntityRegistry
Registered Representatives

Identity Federation. An association of organisations that cometogether to securely exchange information as appropriate
about their users and resources to enable collaborations andtransactions.
An organisation that has joined the Federation by agreeing to
be bound by the Federation Policy in writing.
Organisation providing the infrastructure for
Authentication and Authorisation to Federation Members.
A document describing the obligations, rights andexpectations of the federation members and the federation
Operator.
A discrete component that a member wishes to register anddescribe in metadata. This is typically an Identity Provider orService Provider.
System used by the Federation Operator to register entity
metadata. This may be via a self-service tool or via othermanual processes.
Individuals authorised to act on behalf of the member. Thesemay take on different roles with different rights attached tothem.

2. Introduction and Applicability
This document describes the metadata registration practices of the Federation Operator witheffect 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 issuperseded.
This document SHALL be published on the Federation website at:https://www.maeen.sa/services/identity/. Updates to the documentation SHALL be accuratelyreflected in entity metadata.
An entity that does not include a reference to a registration policy MUST be assumed to havebeen registered under an historic, undocumented registration practice regime. Requests tore-evaluate a given entity against a current MRPS MAY be made to the Federation helpdesk.

3. Member Eligibility and Ownership
Members of the Federation are eligible to make use of the Federation Operator’s registry toregister entities. Registration requests from other sources SHALL NOT be accepted.
The procedure for becoming a member of the Federation is documented at:https://www.maeen.sa/services/identity/
The membership procedure verifies that the prospective member has legal capacity, andrequires that all members enter into a contractual relationship with the Federation Operator byagreeing to the Federation policy. The Operator makes checks based on the legal nameprovided. The checks are conducted with a number of official databases.
The membership process also identifies and verifies Registered Representatives, who arepermitted to act on behalf of the organisation in dealings with the Federation Operator.
Verification is achieved by complete Maeen Federation application form, and singed byorganisation manager.
The process also establishes a canonical name for the Federation member. The canonicalname of a member MAY change during the membership period, for example as a result ofcorporate name changes or mergers. The member’s canonical name is disclosed in theentity’s <md:OrganizationName>.

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 theentity. The following is a non-normative example:<mdrpi:RegistrationInfo registrationAuthority="https://www.maeen.sa"
registrationInstant="2018-12-12T13:39:41Z"><mdrpi:RegistrationPolicy xml:lang="en">https://www.maeen.sa/wp-content/uploads/2019/05/Maeen_Federation_MRPS_en-v1.0.pdf</mdrpi:RegistrationPolicy></mdrpi:RegistrationInfo>5. Entity Eligibility and Validation
5.1 Entity RegistrationThe process by which a Federation member can register an entity is described athttps://www.maeen.sa/services/identity/
The Federation Operator SHALL verify the member’s right to use particular domain names inrelation to entityID attributes and, for Identity Provider entities, any scope elements.
The right to use a domain name SHALL be established in one of the following ways:

A member’s canonical name matches registrant information shown in DNS.
A member MAY be granted the right to make use of a specific domain name througha permission letter from the domain owner on a per-entity basis. Permission SHALL
NOT be regarded as including permission for the use of sub-domains.

5.2 EntityID Format
Values of the entityID attribute registered MUST be an absolute URI using the http, https or
urn schemes.
https-scheme URIs are RECOMMENDED to all members.
http-scheme and https-scheme URIs used for entityID values MUST contain a host part
whose value is a DNS domain.
5.3 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 themember'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 adomain under a public suffix - 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 entityowner), and ending with a '$' anchor (e.g. (foo|bar)\.example\.com$).
5.4 Entity Validation
On entity registration, the Federation Operator SHALL carry out entity vaildations checks.
These checks include:

Ensuring all required information is present in the metadata;
Ensuring metadata is correctly formatted;
Ensuring protocol endpoints are properly protected with TLS / SSL certificates.

6. Entity Management
Once a member has joined the Federation any number of entities MAY be added, modified orremoved by the organisation.
6.1 Entity Change Requests
Any request for entity addition, change or removal from Federation members needs to becommunicated from or confirmed by their respective Registered Representatives.
Communication of change happens via e-mail.
6.2 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;
Add value to the metadata.

Changes will be communicated to Registered Representatives for the entity.

7. References
Remember to include references to documentation within your own Federation, such as yourIdentity Federation Policy.
[RFC2119]Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.

[SAML-Metadata-RPI-V1.0]

SAML V2.0 Metadata Extensions for Registration andPublication Information Version 1.0. 03 April 2012.
OASIS Committee Specification 01. http://docs.oasisopen.org/security/saml/Post2.0/saml-metadatarpi/v1.0/cs01/saml-metadata-rpi-v1.0-cs01.html.
OASIS Metadata for the OASIS Security Assertion
Markup Language (SAML) V2.0: http://docs.oasisopen.org/security/saml/v2.0/saml-metadata-2.0-os.pdf.

[SAML-Metadata-OS]