Differences

This shows you the differences between two versions of the page.

--- en:mrps [2017/02/10 07:02]
127.0.0.1 external edit
+++ en:mrps [2019/04/04 13:58] (current)
Jiří Bořík
@@ Line 1: / Line 1: @@
 ====== Metadata Registration Practice Statement ======
-  * Federation name: eduID.cz
+| Version           | 2.0                        |
-  * Federation operator: CESNET, z. s. p. o.
+| **Last Modified** | 2019-04-04                 |
-  * Federation web page: http://www.eduid.cz/
-Date of last change: 2012-01-30
+**Acknowledgements**
-===== Common Practices =====
+This document is based on the [[https://github.com/REFEDS/MRPS/|REFEDS Metadata Registration Practice Statement template]].
-An organisation becomes a member of the federation by registering an administrative contact - a person (one or more), which represents the organisation in its communication with the operator of the eduID.cz federation. The administrative contacts are responsible for metadata registration.
+===== 1. Definitions and Terminology =====
-To register an administrative contact it is necessary to fill in an appointment form, have it signed and stamped by the statutary body of the organisation and send the signed original by mail to the federation operator.
+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 administrative contact can appoint technical contacts within the organisation. The technical contacts are responsible for the technical implementation and are allowed to register metadata as well.
+The following definitions are used in this document:
-An organisation becomes a part of the federation, when the respective administrative contact publishes its metadata and the operator of the federation verifies it and includes it in the federation metadata.
+| Definition                 | Description |
+| 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 Member          | An organization that has joined the Federation by agreeing to be bound by the Federation Policy in writing.  |
+| Federation Operator        | Organisation providing the infrastructure for Authentication and Authorisation to Federation Members.|
+| Federation Policy          | A document describing the obligations, rights and expectations of the federation members and the Federation Operator. |
+| Entity                     | A discrete component that a member wishes to register and describe in the 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 member.  These may take on different roles with different rights attached to them. |
-The federation adopts the opt-in model for participating in eduGAIN. An entity must explicitly agree to be connected to eduGAIN before its metadata are included in the metadata exposed to the eduGAIN interfederation.
+===== 2. Introduction and Applicability =====
-===== Practices on Identity Provider Registration =====
+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.
-Only academic organisations within Czech Republic are allowed to operate identity providers in eduID.cz.
+This document SHALL be published on the Federation website at [[https://www.eduid.cz/en/mrps]]. Updates to the documentation SHALL be accurately reflected in entity metadata.
-Identity provider metadata are submitted by responsible contacts (administrative or technical) via email with a valid S/MIME signature. The certificate used for the S/MIME signature must be issued to the person appointed as a contact. It must be issued by a CA accepted by eduID.cz and must contain the registered email of the contact.
+An entity that does not include a reference to a registration policy MUST be assumed to have been registered under a historic, undocumented registration practice regime. Requests to re-evaluate a given entity against a current MRPS MAY be made to the Federation helpdesk.
-===== Practices on Service Provider Registration =====
+===== 3. Member Eligibility and Ownership =====
-Service provider metadata are submitted by responsible contacts (administrative or technical) via email with a valid S/MIME signature. The certificate used for the S/MIME signature must be issued to the person appointed as a contact. It must be issued by a CA accepted by eduID.cz and must contain the registered email of the contact.
+Members of the Federation are eligible to make use of the Federation Operator’s registry to register entities. Registration requests from other sources SHALL NOT be accepted.
-An alternative way of secure metadata registration exists, if it is not possible to use signed emails. Metadata are sent by email and at the same time a metadata waybill containing the contact's signature and the SHA1 hash of the metadata file need to be sent by fax or mail. Metadata are then verified against the SHA1 hash and the contact's signature is checked against the respective signature on the appointment form.
+The procedure for becoming a member of the Federation is documented at [[https://eduid.cz/en/join]].
+The membership procedure verifies that the prospective member has legal capacity, and requires that all members enter into a contractual relationship with the Federation Operator by agreeing to the [[https://www.eduid.cz/en/policy|Federation policy]] and [[https://www.cesnet.cz/conditions/?lang=en|Terms and conditions for the access to the CESNET e-infrastructure]]. The Operator makes checks based on the legal name provided. The checks are conducted with a number of official databases eg. Public registry ([[https://or.justice.cz/ias/ui/rejstrik|Veřejný rejstřík a sbírka listin]]), Registry of ecomomy subjects ([[https://wwwinfo.mfcr.cz/ares/ares_es.html.cz|ARES - ekonomické subjekty]]) etc.
+The membership process also identifies and verifies Registered Representatives (Administrative and technical contacts), who are permitted to act on behalf of the organization in dealings with the Federation Operator. Verification is achieved by appointment form signed by official representatives of member organization and provided by organization stamp.
+The process also establishes a canonical name for the Federation member.  The canonical name of a member MAY change during the membership period, for example as a result of corporate name changes or mergers. The member’s canonical name is disclosed in the entity’s SAML v2.0 ''<md:OrganizationName>'' element.
+===== 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:
+<code xml>
+  <mdrpi:RegistrationInfo
+    registrationAuthority="http://www.eduid.cz/"
+    registrationInstant="2016-11-29T13:39:41Z">
+    <mdrpi:RegistrationPolicy xml:lang="en">
+      http://www.eduid.cz/wiki/_media/en/eduid/policy/policy_eduid_en-1_1.pdf
+    </mdrpi:RegistrationPolicy>
+    <mdrpi:RegistrationPolicy xml:lang="cs">
+      http://www.eduid.cz/wiki/_media/eduid/policy/policy_eduid_cz-1_1-3.pdf
+    </mdrpi:RegistrationPolicy>
+  </mdrpi:RegistrationInfo>
+</code>
+===== 5. Entity Eligibility and Validation =====
+==== 5.1 Entity Registration ====
+The process by which a Federation member can register an entity is described at [[https://www.eduid.cz/en/join]].
+The Federation Operator SHALL verify the member’s right to use particular domain names in relation 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 WHOIS.
+  * A member 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 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-scheme or https-scheme.
+https-scheme only URIs are REQUIRED for new entities since 2013.
+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 MUST NOT be present in scopes.
+==== 5.4 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;
+  *	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 or removed by the organization.
+An organization MUST NOT have more than one Identity Provider entity.
+==== 6.1 Entity Change Requests ====
+Any request for entity addition, change or removal from Federation members needs to be communicated from or confirmed by their respective Registered Representatives. Communication of change happens via [[eduid-admin@eduid.cz]] email address using an electronically signed message.
+==== 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.
+===== References =====
+  * [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. https://tools.ietf.org/html/rfc2119
+  * [SAML-Metadata-RPI-V1.0]  SAML V2.0 Metadata Extensions for Registration and Publication Information Version 1.0. 03 April 2012. OASIS Committee Specification 01. http://docs.oasis-open.org/security/saml/Post2.0/saml-metadata-rpi/v1.0/cs01/saml-metadata-rpi-v1.0-cs01.html.
+  * [SAML-Metadata-OS] OASIS Metadata for the OASIS Security Assertion Markup Language (SAML) V2.0: http://docs.oasis-open.org/security/saml/v2.0/saml-metadata-2.0-os.pdf.

Differences

Links

Contact

Service desk