Table of Contents

Summary of Enforced Sections (as of

...

June 2025)

Section 2.1.3 – errorURL

...

Implemented: X May 202516 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 Requirement:
An Identity Provider MUST include an errorURL element in its metadata.

...

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

Examples

Example :

xml <IDPSSODescriptor ...> <errorURL>https://idp.example.org/login-error</errorURL> </IDPSSODescriptor>

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

Action: Ensure your IdP metadata contains a reachable errorURL.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: X May 2025 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 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:xml <KeyDescriptor

<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

<KeyInfo> <X509Data> <X509Certificate>MIID...snip...</X509Certificate> </X509Data> </KeyInfo> </KeyDescriptor>Action: Verify that a valid signing certificate is present in your metadata.

Section 3.1.4 –

...

SAML certificates (

...

encryption)

Implemented: X May 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:xml <KeyDescriptor

<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

<KeyInfo> <X509Data> <X509Certificate>MIIF...snip...</X509Certificate> </X509Data> </KeyInfo> </KeyDescriptor>Action: Ensure your SP metadata includes a valid encryption certificate.

Section 3.1.6 – Requested Attributes (SP)

Implemented: X May 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 MUST include:

• A Name

  from the

  attribute

  profile

  .

• FriendlyName matching the same profile

• A FriendlyName attribute.

• NameFormat =

  A NameFormat attribute set to

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

Example:

...

• .

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 : 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:

...