Table of Contents
maxLevel 2

Summary of Planned and Enforced Sections

Section 2.1.1 - lang

Implemented: TBD

Description

This requirement ensures that human-readable elements in metadata include language information to improve usability and interoperability in multilingual environments.

Requirement

Requirement

All human-readable elements that support language tagging MUST include the xml:lang attribute.

The following rules apply:

• Language values MUST follow ISO 639-1 (e.g. sv, en)

• Both Swedish (sv) and English (en) MUST be present

• If a language is used in one metadata element, it MUST be used consistently across all metadata elements that support xml:lang

  • Exception: md:RegistrationPolicy

• The same language value MUST NOT appear more than once per element

  • Exception: mdui:Logo

This includes (but is not limited to):

• mdui:DisplayName

• mdui:Description

• md:ServiceName

• md:ServiceDescription

Examples

<mdui:DisplayName xml:lang="en">Example Organization</mdui:DisplayName>
<mdui:DisplayName xml:lang="sv">Exempelorganisation</mdui:DisplayName>
<mdui:Description xml:lang="en">Example Organization - more text...</mdui:Description>
<mdui:Description xml:lang="sv">Exempelorganisation - mer text...</mdui:Description>

Action

Ensure that:

• Both sv and en are always present

• Language usage is consistent across all relevant elements

• Only valid ISO 639-1 language codes are used

• No duplicate xml:lang values exist per element (except for Logo)

2.1.7 / 3.1.5 - SAML endpoints

Implemented: TBD

Description

This requirement enforces correctness and security of SAML endpoint definitions to ensure proper federation interoperability.

Requirement

All SAML endpoints MUST:

• use HTTPS (https://)

• be valid and well-formed URLs

• not contain localhost, IP addresses, or non-public domains

Applicable endpoints include, but are not limited to:

• SingleSignOnService

• SingleLogoutService

• AssertionConsumerService

For Service Providers, the following additional requirement applies:

• an AssertionConsumerService MUST NOT use the binding urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect

Examples

✅ Valid

<md:AssertionConsumerService
Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
Location="https://sp.example.se/acs"
index="0"/>

❌ Invalid – ACS with HTTP-Redirect

<md:AssertionConsumerService
Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect"
Location="https://sp.example.se/acs"
index="0"/>

✅ Valid

<md:SingleSignOnService
 Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect"
Location="https://idp.example.se/sso"/>

Action

Verify that all endpoint URLs:

• use HTTPS

• are publicly reachable

• follow correct URL syntax

For Service Providers, also verify that:

• no AssertionConsumerService uses the HTTP-Redirect binding

• AssertionConsumerService endpoints use an allowed binding, such as HTTP-POST

2.1.10 / 3.1.8 - ContactPerson

Implemented: TBD

Description

This requirement ensures that federation operators and participants can reliably contact responsible functions for operational, technical, and support-related matters, while complying with personal data protection legislation.

Requirement

Contact information MUST NOT refer to a natural person.

The following requirements apply for both Identity Providers and Relying Parties:

• An entity MUST include exactly one ContactPerson of each of the following types:

  • administrative

  • technical

  • support

• There MUST NOT be more than one ContactPerson per contact type

• Each ContactPerson MUST include:

  • EmailAddress

• The EmailAddress:

  • MUST start with mailto:

  • MUST refer to a functional mailbox (not a personal email)

Guidance

• The administrative contact is used for governance and federation-related matters

• The technical contact is used for technical issues and integration

• The support contact is used for end-user and non-technical support

Examples

✅ Valid

<md:ContactPerson contactType="administrative">
<md:EmailAddress>mailto:admin@example.se</md:EmailAddress>
</md:ContactPerson>

<md:ContactPerson contactType="technical">
<md:EmailAddress>mailto:tech@example.se</md:EmailAddress>
</md:ContactPerson>

<md:ContactPerson contactType="support">
<md:EmailAddress>mailto:support@example.se</md:EmailAddress>
</md:ContactPerson>

❌ Invalid – missing required contact types

<md:ContactPerson contactType="technical">
<md:EmailAddress>mailto:tech@example.se</md:EmailAddress>
</md:ContactPerson>

❌ Invalid – multiple contacts of same type

<md:ContactPerson contactType="technical">
<md:EmailAddress>mailto:tech1@example.se</md:EmailAddress>
</md:ContactPerson>

<md:ContactPerson contactType="technical">
<md:EmailAddress>mailto:tech2@example.se</md:EmailAddress>
</md:ContactPerson>

❌ Invalid – personal contact

<md:ContactPerson contactType="technical">
<md:EmailAddress>mailto:firstname.lastname@example.se</md:EmailAddress>
</md:ContactPerson>

Action

Ensure that:

• Exactly one ContactPerson exists for each required type (administrative, technical, support)

• No duplicate contact types exist

• All email addresses:

  • use the mailto: scheme

  • point to functional (role-based) mailboxes

• No personal data is used in contact information

Section 2.1.3 – errorURL

Implemented: 16 June 2025

...