Summary of Planned and Enforced Sections

Metadata example

A metadata example that conforms to the technical profile is found here.

Section 2.1.2 / 3.1.2 – entityID

Implemented: June 15, 2026

Description

The entityID is the globally unique identifier of an Identity Provider or Service Provider in the federation. It is used by federation participants to identify the entity in metadata and during SAML message processing.

This requirement ensures that all registered entities use a valid and interoperable identifier format.

Requirement

The entityID MUST be globally unique.

The entityID MUST be a URI and MUST start with one of the following:

• https://
• http://
• urn:

The urn: form is a legacy format and SHOULD NOT be used when registering a new entity.

The https:// format is preferred.

The entityID MUST NOT exceed 256 characters.

Examples

✅ Valid

https://idp.example.se/idp
https://sp.example.se/saml

✅ Not recommended for new entities

urn:mace:example.se:sp

❌ Invalid – not a URI

example-sp
example-idp
skolfederation-prod-sp

❌ Invalid – missing URI scheme

www.example.se
idp.example.se/saml

Action

Ensure that your metadata uses an entityID that:

• is globally unique
• starts with https://, http:// or urn:
• preferably uses https://
• does not exceed 256 characters
• does not use local, informal or product-specific identifiers

Section 2.1.5 / 3.1.3 – Metadata Extensions for Login and Discovery User Interface (MDUI)

Implemented: June 15, 2026

Description

MDUI provides human-readable information about an Identity Provider or Service Provider. This information is used in discovery services, login services and other user-facing interfaces to help users identify the correct organization or service.

This requirement improves usability and interoperability by ensuring that all entities provide consistent presentation information in metadata.

Requirement

Identity Providers and Service Providers MUST include MDUI information.

The following MDUI elements are required:

• DisplayName
• Description
• Logo

These elements MUST include language attributes according to the language requirements in the technical profile.

The DisplayName MUST be unique within the federation. The English DisplayName MUST be unique within the federation and all interacting interfederations.

The Logo value MUST:

• be a URL that starts with https://
• not be embedded in the metadata
• be publicly accessible
• use a domain owned by the organization or delegated to the organization

The Logo SHOULD:

• be in PNG format
• be transparent and work on a white or light grey background
• be square, or use landscape orientation if a square logo is not appropriate
• have a width between 64 and 350 pixels
• have a height between 64 and 146 pixels

For Identity Providers, the following MDUI element MAY be included:

• Keywords

Identity Providers MAY also include the following DiscoHints elements:

• IPHint
• DomainHint
• GeolocationHint

Examples

✅ Valid

<md:Extensions>
  <mdui:UIInfo>
    <mdui:DisplayName xml:lang="en">Example School</mdui:DisplayName>
    <mdui:DisplayName xml:lang="sv">Exempelskolan</mdui:DisplayName>
    <mdui:Description xml:lang="en">Login for Example School</mdui:Description>
    <mdui:Description xml:lang="sv">Inloggning för Exempelskolan</mdui:Description>
    <mdui:Logo xml:lang="en" height="128" width="128">https://example.se/logo.png</mdui:Logo>
    <mdui:Logo xml:lang="sv" height="128" width="128">https://example.se/logo.png</mdui:Logo>
  </mdui:UIInfo>
</md:Extensions>

❌ Invalid – missing Description

<mdui:UIInfo>
  <mdui:DisplayName xml:lang="en">Example School</mdui:DisplayName>
  <mdui:Logo xml:lang="en" height="128" width="128">https://example.se/logo.png</mdui:Logo>
</mdui:UIInfo>

❌ Invalid – embedded or non-HTTPS logo

<mdui:Logo xml:lang="en" height="128" width="128">data:image/png;base64,...</mdui:Logo>
<mdui:Logo xml:lang="en" height="128" width="128">http://example.se/logo.png</mdui:Logo>

Action

Ensure that your metadata contains MDUI information with:

• DisplayName
• Description
• Logo
• xml:lang attributes for language-tagged elements
• both Swedish (sv) and English (en) language values where required
• a federation unique DisplayName
• a publicly reachable HTTPS logo URL

Section 2.1.8 – Supported attributes

Implemented: June 15, 2026

Description

Supported attributes in Identity Provider metadata describe which attributes an Identity Provider can release. This helps Service Providers understand which attributes may be available and improves interoperability in the federation.

Requirement

An Identity Provider MUST define supported attributes in metadata.

An Identity Provider MUST have at least one Attribute element.

Each Attribute element MUST include:

• Name
• FriendlyName
• NameFormat

If the Name value is represented by an attribute in the federation Attribute Profile, the attribute definition in the Attribute Profile MUST be used. If the attribute value or purpose is not covered by the Attribute Profile, other attribute definitions MAY be used.

If the attribute is from the federation Attribute Profile, the FriendlyName value MUST match the FriendlyName defined for the corresponding Name in the federation Attribute Profile.

The NameFormat value MUST be:

urn:oasis:names:tc:SAML:2.0:attrname-format:uri

An Attribute element MAY include one or more AttributeValue elements.

Examples

✅ Valid

<saml:Attribute
  FriendlyName="givenName"
  Name="urn:oid:2.5.4.42"
  NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"/>

❌ Invalid – missing FriendlyName

<saml:Attribute
  Name="urn:oid:1.2.752.29.4.13"
  NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri" />

❌ Invalid – wrong NameFormat

<saml:Attribute
  Name="urn:oid:1.2.752.29.4.13"
  FriendlyName="norEduPersonNIN"
  NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic" />

Action

Ensure that your IdP metadata:

• contains at least one supported Attribute
• includes correct Name, FriendlyName and NameFormat
• uses the required URI-based NameFormat

Section 2.5.1 / 3.5.1 – Subject identifiers

Implemented: June 15, 2026

Description

This requirement ensures that Identity Providers support a baseline identifier format needed for interoperability, including use cases such as session handling and single logout.

Requirement

An Identity Provider MUST declare support of a transient NameID in metadata

urn:oasis:names:tc:SAML:2.0:nameid-format:transient

Attributes used to identify a subject are defined in the federation Attribute Profile. The SAML Subject NameID SHOULD NOT be used for user identification purposes.

Examples

✅ Valid

<md:NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:transient</md:NameIDFormat>

❌ Invalid – unsupported or missing transient NameID support

<md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress</md:NameIDFormat>

Action

Ensure that your instance:

• If IdP: supports release of transient NameID
• can use the transient NameID format when required
• follows the federation Attribute Profile for subject-identifying attributes
• If SP: does not require identification of subject using NameID

Section 2.1.11 / 3.1.9 – Non-secure cryptographic algorithms

Implemented: June 15, 2026

Description

SAML metadata may include algorithm declarations such as digest, signing and encryption methods. This requirement ensures that metadata does not advertise obsolete or insecure cryptographic algorithms.

Requirement

Metadata MUST only include the following elements when they contain algorithms defined in the latest published W3C Recommendations for XML Signature and XML Encryption:

• DigestMethod
• SigningMethod
• EncryptionMethod

Algorithms discouraged in the latest published versions of those recommendations SHOULD NOT be included.

MD5 is obsolete and RSA v1.5 is not recommended.

Examples

✅ Valid

<alg:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
<alg:SigningMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/>

❌ Invalid – obsolete digest algorithm

<alg:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#md5"/>

❌ Invalid – discouraged encryption algorithm

<md:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-1_5"/>

Action

Review your metadata and remove obsolete or discouraged cryptographic algorithms.

Ensure that:

• DigestMethod uses an algorithm defined in the latest XML Signature recommendations
• SigningMethod uses an algorithm defined in the latest XML Signature recommendations
• EncryptionMethod uses an algorithm defined in the latest XML Encryption recommendations
• MD5 is not used
• RSA v1.5 is not used

Section 2.1.12 / 3.1.10 – Unnecessary, large metadata

Implemented: June 15, 2026

Description

Some metadata elements are unnecessarily large and are not needed in the federation. Including them increases metadata size and may affect metadata processing for federation participants.

Requirement

Identity Provider and Service Provider metadata MUST NOT include RoleDescriptor elements.

Examples

✅ Valid

<md:IDPSSODescriptor
  protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">
  ...
</md:IDPSSODescriptor>

<md:SPSSODescriptor
  protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">
  ...
</md:SPSSODescriptor>

❌ Invalid

<md:RoleDescriptor
  protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">
  ...
</md:RoleDescriptor>

Action

Remove RoleDescriptor elements from your metadata.

Use the specific role descriptor required for the entity instead, such as:

• IDPSSODescriptor for Identity Providers
• SPSSODescriptor for Service Providers

Section 2.1.1 - lang

Implemented: June 15, 2026

Description

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

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

Description

The errorURL is a metadata element in an Identity Provider (IdP) configuration that points to a web page intended to help users troubleshoot login problems. When a user encounters an issue during authentication, a Relying Party (e.g. a Service Provider) may redirect the user to this URL for guidance or support. Including a valid and accessible errorURL enhances the user experience and aligns with SAML best practices.

Requirement

An Identity Provider MUST include an errorURL element in its metadata.

“A Relying Party may use the errorURL of an Identity Provider to assist users in resolving login issues.”

IdPs SHOULD follow the SAML V2.0 Metadata Deployment Profile for errorURL.

Examples

Example not supporting Metadata Deployment Profile for errorURL

<md:IDPSSODescriptor errorURL="https://example.com/error.html">

Example supporting Metadata Deployment Profile for errorURL, with the required and optional placeholders

<md:IDPSSODescriptor errorURL="https://example.com/ERRORURL_CODE?ts=ERRORURL_TS&rp=ERRORURL_RP&tid=ERRORURL_TID&ctx=ERRORURL_CTX">

Action

Ensure your IdP metadata contains a reachable errorURL.

Generic errorURL

A generic errorURL is provided by Skolfederation as an example and fallback. More info here.

Section 2.1.6 – SAML certificates (signing)

Implemented: 16 June 2025

Description

A signing certificate is a critical part of an Identity Provider’s SAML metadata. It ensures that SAML assertions and metadata can be cryptographically validated by relying parties. The certificate is included via a <KeyDescriptor> element, either explicitly marked with use="signing" or with no use attribute at all.

Requirement

An Identity Provider MUST include at least one signing certificate.

“A KeyDescriptor element with no use attribute or one set to signing.”

Examples

Example with use attribute set to signing:

<md:KeyDescriptor use="signing">
 	<ds:KeyInfo>
		<ds:X509Data>
			<ds:X509Certificate>
				<example-certificate-contents>
			</ds:X509Certificate>
		</ds:X509Data>
	</ds:KeyInfo>
</md:KeyDescriptor>

Example with no use attribute set:

<md:KeyDescriptor>
	<ds:KeyInfo>
		<ds:X509Data>
			<ds:X509Certificate>
				<example-certificate-contents>
			</ds:X509Certificate>
		</ds:X509Data>
	</ds:KeyInfo>
</md:KeyDescriptor>

Action

Verify that a valid signing certificate is present in your metadata.

Section 3.1.4 – SAML certificates (encryption)

Implemented: 16 June 2025

Description

An encryption certificate is required in a Service Provider’s SAML metadata to allow Identity Providers to encrypt assertions. This certificate must be included using a <KeyDescriptor> element, either explicitly marked with use="encryption" or with no use attribute (which implies general-purpose use, including encryption).

Requirement

A Service Provider MUST include at least one encryption certificate.

“A KeyDescriptor element with no use attribute or one set to encryption.”

Examples

Example with use attribute set to encryption:

<md:KeyDescriptor use="encryption">
 	<ds:KeyInfo>
		<ds:X509Data>
			<ds:X509Certificate>
				<example-certificate-contents>
			</ds:X509Certificate>
		</ds:X509Data>
	</ds:KeyInfo>
</md:KeyDescriptor>

Example with no use attribute set:

<md:KeyDescriptor>
	<ds:KeyInfo>
		<ds:X509Data>
			<ds:X509Certificate>
				<example-certificate-contents>
			</ds:X509Certificate>
		</ds:X509Data>
	</ds:KeyInfo>
</md:KeyDescriptor>

Action

Ensure your SP metadata includes a valid encryption certificate.

Section 3.1.6 – Requested Attributes (SP)

Implemented: 16 June 2025

Requirement

A Service Provider MUST include at least one AttributeConsumingService element.

Each AttributeConsumingService MUST contain:

• A ServiceName element with an xml:lang attribute.

• A ServiceDescription element with an xml:lang attribute.

• At least one RequestedAttribute.

Each RequestedAttribute MUST include:

• A Name attribute.

• A FriendlyName attribute.

• A NameFormat attribute set to urn:oasis:names:tc:SAML:2.0:attrname-format:uri.

It is strongly recommended to use attribute from the federation’s attribute profile for interoperability purposes.

If an attribute from the attribute profile is used, the FriendlyName MUST exactly match the name defined in the profile.

Examples

<AttributeConsumingService index="1"> 
	<ServiceName xml:lang="en">Demo Service</ServiceName> 
	<ServiceDescription xml:lang="en">Used for testing login functionality</ServiceDescription>
	<RequestedAttribute Name="urn:oid:1.2.752.29.4.13" FriendlyName="norEduPersonNIN" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri" />
</AttributeConsumingService>

Action

Add RequestedAttribute definitions that match the federation profile. Remember to use xml:lang for language tagging.

Enforcement Notes

The validator enforces these rules only when metadata is uploaded or updated. Existing metadata is unaffected unless resubmitted.

Need Help?

For validation help, you can:

• Use the external metadata validator,
• Review the technical profile,
• Contact your technical expertise for information how these rules affect your implementation,
• Contact us for any clarification: info@skolfederation.se