Summary of Enforced Sections (as of June 2025)

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