Page tree
Skip to end of metadata
Go to start of metadata

Jump to: 

This document uses normative language (MUST, MAY, SHOULD, etc.) from RFC2119

About the Metadata Validation Procedure

This article describes the procedure InCommon performs to validate data elements submitted by Participants during the course of registering an organization and its entity metadata. 

Organization validation upon joining InCommon 

When an organization joins InCommon and signs the InCommon Participation Agreement, the InCommon Registration Authority (RA) performs validation on an organization's name and website. The same validation also occurs when an organization requests a name or website update.

Metadata Element

Requirement Level

Method

Assessor

OrganizationName

MUST

3rd Party verification (e.g., database such as accreditation listings)

InCommon Registration Authority (RA)

Organization
DisplayName

MUST

Same as OrganizationName or a reasonable variant if requested

InCommon RA

OrganizationURL

MUST

Demonstrable Control of domain.

InCommon RA

Entity validation performed by the Federation Manager

The following validations are run automatically in Federation Manager (FM) when a Site Administrator submits an entity to be published into the InCommon metadata. 

Metadata Element

Requirement LevelMethodAssessor
EntityID
MUSTFor new entity descriptors, must be a validly formatted URL.FM
EntityID
MUSTBe URLs only. Grandfathered URNs are supported.
FM
mdui:Logo
MUSTBe a resolvable URL, using the https:// scheme.FM
mdui:PrivacyStatementURL
MUSTBe a resolvable URLFM
Endpoints in IdPsMUSTContain a SAML V2.0 SingleSignOnService endpoint supporting the HTTP-redirect binding.FM
Endpoints in IdPsMUSTBe a validly formatted URL, using the https:// scheme.FM
Endpoints in SPsMUSTContain at least one AssertionConsumerService endpoint supporting the SAML V2.0 HTTP-POST binding.FM
Technical, Administrative, Support, Security contactsMUSTMetadata MUST contain at least one of each: Technical Contact, Administrative Contact, Security Contact.FM

Entity validation performed by Level 1 Registration Authority

The following validations are done by a Level 1 Registration Authority (RA L1) when a Site Administrator submits an entity to be published into the InCommon metadata. 

Metadata Element

Requirement Level

Method

Assessor

EntityID

MUST

Demonstrable Control of domain.

RA L1
mdui:DisplayName

MUST

Reasonableness Check

RA L1
mdui:Description

MUST

Reasonableness Check

RA L1

Entity validation performed by Level 2 Registration Authority

The following validations are done by a Level 2 Registration Authority (RA L2) when a Site Administrator submits an entity to be published into the InCommon metadata. 

Metadata Element

Requirement Level

Method

Assessor

shibmd:Scope in IdPs

MUST

Demonstrable Control of domain.

RA L2
shibmd:Scope in IdPs
SHOULDBe the root DNS zone for the organization (e.g., campus.edu, not library.campus.edu).RA L2

errorURL in IdPs

SHOULDBe a URL that resolves to a document describing how to contact IdP support personnel, or providing a form for contacting IdP support personnel (e.g., to request that attributes be released to an SP).RA L2
Endpoints in IdPsSHOULDContain a SAML V2.0 SingleSignOnService endpoint supporting the HTTP-POST binding.RA L2
Endpoints in IdPsSHOULD NOTContain one or more SAML V2.0 Attribute Authority endpoints, unless for a known use case articulated by the Site Administrator.RA L2
Certificate expirationsSHOULDThe certificate should be long lived (10 years). Not all places can do long lived certs so seek clarification if they want to switch to a long-lived cert before approving.RA L2

* This applies only to new entity submissions. Older entities may contain exceptions.

 Glossary

  1. MUST -  The Assessor must validate the metadata element. The entered value must meet validation rules before before the change is approved.

  2. SHOULD/SHOULD NOT - Submitters are warned or generally given guidance via email or phone notification.
  3. Demonstrable Control of domain - There are two methods for validating control of a domain:
    1. WHOIS: On a domain's WHOIS record, the Registrant Organization must be the Organization submitting the metadata. Results are archived in the Org's box folder.
    2. TXT Record: See the Domain Control Validation Procedure. Results are archived in the Org's box folder.
  4. Reasonableness Check for Names and Descriptions
    1. High-value names that obviously don't belong to the submitting organization are disallowed. For example, University-X cannot claim to be "Woolworth's" or "Pan Am" or "Compaq Computers."
    2. However, limited brand associations are allowed that constrain the relationship appropriately. For example Company-A should not assert "University-X's Job Board" but could assert "University-X's Job Board via Company-A."
    3. URLs are not allowed.
    4. Domain strings (e.g., campus.company.com) are allowed but discouraged (see SHOULD) where a name or brief description is more appropriate for human readable elements.
    5. Offensive language is discouraged (see SHOULD).
    6. It is ultimately up to the Org to ensure violations and infringements are not occurring.

Version:

Latest published version:https://spaces.at.internet2.edu/x/noY5CQ

This version:https://spaces.at.internet2.edu/x/noY5CQ

Change Management:

To modify this policy, send a request to: help@incommon.org

RACI Framework:

Responsible: InCommon Registration Authority

Approver:  InCommon Federation Service Manager

Consulted: For Material Changes that affect the Trust Model, InCommon Governance

Informed: For Material Changes that affect the Trust Model, InCommon Participants