oidc-metadata-requirements September 2026
Lindström Informational [Page]
Published:
Author:
M. Lindström
The Swedish Agency for Digital Government (Digg)

Sweden Connect – OpenID Connect Metadata Requirements 1.0 – draft 01

Abstract

This specification defines the metadata requirements for Relying Parties and OpenID Providers participating in the Sweden Connect OpenID Connect federation. The metadata is published in Entity Configurations according to OpenID Federation 1.0. The requirements apply to the resolved metadata, meaning the metadata that results once the Trust Chain of an Entity has been applied to the declarations the Entity makes about itself.

▲

Table of Contents

1. Introduction

This document specifies the metadata that a Relying Party or an OpenID Provider publishes when it joins the Sweden Connect OpenID Connect federation. It is written for the organizations that operate such Entities, and for the developers and operators who implement them. How the federation is structured, and how an Entity is registered in it, is described in [OIDC.SC.Structure].

The requirements stated here apply to Entities that adhere to [OIDC.SC.Profile], which is the profile in use within the federation at the time of writing. This is the current scope rather than a permanent limitation. The federation may later admit other Entity Types, and Relying Parties and OpenID Providers adhering to other profiles, and the requirements in this document would then not apply to them unaltered.

The requirements build on a number of specifications. [OpenID.Federation] defines how metadata is published and resolved, and [OIDC.Sweden.Federation] profiles OpenID Federation for use in Swedish federations, a profile that Sweden Connect follows. [OpenID.Discovery] and [OpenID.Registration] define the metadata parameters themselves, [OIDC.Sweden.Profile] and [OIDC.SC.Profile] set the requirement levels that apply in Sweden, and [SC.Security] states the algorithm and key requirements that apply within the federation.

The requirement chapters state what has to appear in the resolved metadata of an Entity. Sweden Connect Metadata Policies shows how those requirements are enforced, through the metadata policy that the Sweden Connect Trust Anchor applies to every Entity, and through the per-Entity values that a Sweden Connect Registration Intermediate sets when an Entity joins the federation.

1.1. Requirements Notation and Conventions

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

2. General Requirements

This document specifies metadata requirements for Relying Parties and OpenID Providers within the Sweden Connect federation. The metadata is carried in the metadata Claim of each Entity's Entity Configuration, under the Entity Type Identifier openid_relying_party or openid_provider, as specified in Section 5.1 of [OpenID.Federation]. A Relying Party that cannot publish an Entity Configuration of its own may have it hosted by the Sweden Connect RP Registration Intermediate according to [OIDC.Sweden.Hosting], in which case the requirements below apply to the hosted document.

The requirements apply to the resolved metadata, meaning the metadata that results from applying the Subordinate Statements of the Trust Chain to the Entity's own declarations, see Section 10 of [OpenID.Federation]. A Registration Intermediate may assign or refine values in the Subordinate Statement it issues, see Section 2.5 of [OIDC.Sweden.Federation]. Some requirements apply to every Entity in the federation rather than to an individual Entity, and these are enforced through the metadata policies the Trust Anchor applies. The algorithm requirements are of this kind. A parameter that is REQUIRED in the resolved metadata is therefore not always a parameter the Entity has to declare itself. Where a Registration Intermediate supplies or modifies a value, or a metadata policy constrains it, the Description column says so.

The tables also indicate whether the Federation Operator checks a particular parameter. Where it does, the checked value is normally fixed in a metadata policy, so that the resolved metadata always carries the value that was checked.

Some metadata parameters are multilingual, meaning that they should be provided for both Swedish and English. In such cases, the Federation Operator always includes a corresponding parameter without a language tag in the resolved metadata. The reason is to ensure that implementations without multi-language support can understand the resolved metadata. Within the Sweden Connect federation, Swedish is the default language. An Entity MAY itself provide the parameter with no language tag, to override the default.

"display_name#sv" : "Min tjänst",
"display_name#en" : "My service",
"display_name" : "Min tjänst"         <- REQUIRED in resolved metadata

Example: Multi-lingual parameter.

This document does not specify the Entity Statement Claims themselves, such as iss, sub, iat, exp, jwks, authority_hints, and trust_marks. Those are defined by Section 3.1 of [OpenID.Federation] and profiled by [OIDC.Sweden.Federation]. A Relying Party and an OpenID Provider are Federation Protocol Entities, and therefore always Leaf Entities, so their Entity Configurations MUST NOT contain metadata of the Entity Type federation_entity, see Section 2.2 of [OIDC.Sweden.Federation].

A parameter that is not listed in the tables below MAY be used at the requirement level given by the specification that defines it. Where a table states a requirement level that differs from the level given by the defining specification, the level stated in the table is the one that applies within Sweden Connect.

3. Common Requirements

The table below covers the metadata parameters that Relying Parties and OpenID Providers publish with the same meaning in their openid_relying_party and openid_provider metadata, respectively. These parameters describe the Entity and the organization behind it, and are defined in Section 5.2.2 of [OpenID.Federation]. The Sweden Connect Registration Intermediates check some of these values when an Entity joins the federation, see Section 3 of [OIDC.SC.Structure].

Table 1: Organization and informational metadata parameters.
Parameter Description Requirement Defined in
organization_name The name of the organization that owns the Entity. The value given without a language tag MUST be the legal name of the organization. Human-readable names for Swedish (#sv) and English (#en) MAY also be given. REQUIRED

Assigned by Federation Operator.

OPTIONAL for Entity to supply.		 Section 5.2.2 of [OpenID.Federation]
organization_identifier A unique identifier for the organization that owns the Entity. The value MUST contain the ten-digit Swedish organization number within an ISO/IEC 6523 [ISO.6523] GLUE-URI [I-D.ietf-spice-glue-id], see below. REQUIRED

Assigned by Federation Operator.

OPTIONAL for Entity to supply.		 Section 2 of [OIDC.Sweden.OrgId]
organization_uri A URL to a web page for the organization that owns the Entity. RECOMMENDED Section 5.2.2 of [OpenID.Federation]
display_name A human-readable name of the Entity itself, intended to be presented to the end-user.
The Federation Operator will check these values and pin them in a metadata policy.
If an RP does not supply this parameter, the Federation Operator will use the value given for client_name (see below).		 REQUIRED

Controlled by Federation Operaror.

OPTIONAL for RPs to supply.		 Section 5.2.2 of [OpenID.Federation]
logo_uri A URL referencing a logotype for the Entity, which a peer may display to the end-user. The URL MUST use the HTTPS scheme and point to a valid image file. SVG format is RECOMMENDED.
The Federation Operator will check this value and pin it a metadata policy.		 REQUIRED Section 5.2.2 of [OpenID.Federation] and Section 2 of [OpenID.Registration] (for RPs)
contacts Contact addresses for the people or groups responsible for operating the Entity. The value MUST hold at least one email address. REQUIRED Section 5.2.2 of [OpenID.Federation] and Section 2 of [OpenID.Registration] (for RPs)
description A brief human-readable description of the Entity. OPTIONAL Section 5.2.2 of [OpenID.Federation]
keywords Search keywords, tags, or categories that apply to the Entity. OPTIONAL Section 5.2.2 of [OpenID.Federation]
policy_uri A URL to the documentation of conditions and policies that are relevant to the Entity. OPTIONAL Section 5.2.2 of [OpenID.Federation] and Section 2 of [OpenID.Registration] (for RPs)
information_uri A URL to further documentation about the Entity, viewable by the end-user. OPTIONAL Section 5.2.2 of [OpenID.Federation]
The organization_identifier format

A Swedish organization number is a ten-digit string, without a hyphen, according to [SKV709]. To allow the Sweden Connect federation to interoperate with other federations in the future, the identifier MUST be expressed as a GLUE-URI [I-D.ietf-spice-glue-id] using ISO/IEC 6523 [ISO.6523] representation. The format for such identifiers is urn:glue:iso6523:<icd>:<organization-number>, where icd stands for International Code Designator, the ISO/IEC 6523 code identifying the scheme that issued the identifier. Swedish organization numbers are registered under ICD 0007, assigned to the Swedish Tax Agency (Skatteverket), so all Swedish organization numbers are prefixed with urn:glue:iso6523:0007:. 
"organization_identifier" : "urn:glue:iso6523:0007:2021006883"

Example of how the organization number for the Swedish Agency for Digital Government (Digg) is represented in an organization_identifier.

The keys an Entity uses in the OpenID Connect protocol, as opposed to the Federation Entity Keys that sign its Entity Statements, are published in its openid_relying_party or openid_provider metadata. Three representations are available, see Section 5.2.1 of [OpenID.Federation]. The requirement levels below follow [OIDC.Sweden.Profile], which states them separately for the two roles, in section 5.2 for OpenID Providers and in section 6 for Relying Parties, and they therefore differ between the roles.

Table 2: Parameters for publishing the Entity's OpenID Connect keys.
Parameter Description Requirement Defined in
jwks The Entity's JSON Web Key Set, included by value in the metadata. A Relying Party MUST publish its keys using either jwks or jwks_uri, see Section 6 of [OIDC.Sweden.Profile]. REQUIRED for a Relying Party, unless jwks_uri is used.
OPTIONAL for an OpenID Provider.		 Section 2 of [OpenID.Registration] and Section 5.2.1 of [OpenID.Federation]
jwks_uri A URL from which the Entity's JSON Web Key Set can be retrieved. The URL MUST use the HTTPS scheme. A Relying Party MUST publish its keys using either jwks or jwks_uri, see Section 6 of [OIDC.Sweden.Profile]. REQUIRED for an OpenID Provider, see Section 5.2 of [OIDC.Sweden.Profile].
REQUIRED for a Relying Party, unless jwks is used.		 Section 2 of [OpenID.Registration], Section 3 of [OpenID.Discovery] and Section 5.2.1 of [OpenID.Federation]
signed_jwks_uri A URL referencing a signed JWT that carries the Entity's JSON Web Key Set. The URL MUST use the HTTPS scheme, and the JWT MUST be signed with a Federation Entity Key. OPTIONAL Section 5.2.1 of [OpenID.Federation]

It is RECOMMENDED that an Entity uses only one of the three representations, see Section 5.2.1.1 of [OpenID.Federation].

The keys an Entity publishes MUST meet the cryptographic requirements of [SC.Security], which state the algorithms and minimum key lengths that apply within the Sweden Connect federation, see Section 3 of [SC.Security]. An Entity that replaces a key MUST follow the key rollover requirements of Section 4 of [SC.Security], so that other parties in the federation are not disrupted. To facilitate a smooth key rollover, each JWK MUST include a kid parameter, also in the cases where the JWK Set holds a single key, see Section 4 of [SC.Security].

4. Relying Party Requirements

This section covers the metadata of the Entity Type openid_relying_party, as defined in Section 5.1.2 of [OpenID.Federation]. A Relying Party publishes these parameters in the metadata Claim of its Entity Configuration, or has them published on its behalf according to [OIDC.Sweden.Hosting]. The parameters are those defined for Client Registration in Section 2 of [OpenID.Registration], with the requirement levels stated by Section 6 of [OIDC.Sweden.Profile] and Section 3.2 of [OIDC.SC.Profile]. The parameters of Common Requirements apply in addition to those listed here.

Table 3: Relying Party metadata parameters defined by the OpenID Connect specifications.
Parameter Description Requirement Defined in
redirect_uris The redirection URIs the Relying Party uses for receiving authorization responses. REQUIRED Section 2 of [OpenID.Registration]
response_types An array of the OAuth 2.0 response types the Relying Party uses. MUST contain the code response type. REQUIRED Section 2 of [OpenID.Registration]
grant_types An array of the OAuth 2.0 grant types the Relying Party uses. MUST contain the authorization_code grant type. REQUIRED Section 2 of [OpenID.Registration]
token_endpoint_auth_method The client authentication method the Relying Party uses at the Token endpoint. The value MUST be set to private_key_jwt. REQUIRED Section 2 of [OpenID.Registration]
client_name The presentation name of the Relying Party, which an OpenID Provider may display to the end-user during authentication. The name MUST be given in Swedish (#sv) and English (#en).
The Federation Operator will check these values and pin them in a metadata policy.

If no value is given for display_name (see Section 3), the Federation Operator will copy the values for client_name to corresponding values for display_name and pin them in a metadata policy.		 REQUIRED

Controlled by the Federation Operator.		 Section 2 of [OpenID.Registration]
client_uri A URL to the home page of the Relying Party, which an OpenID Provider may use when interacting with the end-user. The URL MUST use the HTTPS scheme and point to a valid web page. The parameter MAY be given for different languages. REQUIRED Section 2 of [OpenID.Registration]
subject_type The Subject Identifier type the Relying Party requests in tokens issued to it. Valid values are public and pairwise. The default is public, and is assigned by the Federation Operator if not supplied. REQUIRED

OPTIONAL to supply.		 Section 2 of [OpenID.Registration]
default_acr_values The Authentication Context Class Reference values the Relying Party requests by default. The values defined for use within Sweden Connect are given in Section 3.1.1 of [SC.Registry]. OPTIONAL Section 2 of [OpenID.Registration]
require_auth_time Whether the auth_time claim is required in ID Tokens issued to the Relying Party. An OpenID Provider within Sweden Connect always includes the auth_time claim, see Section 3.2.1 of [OIDC.Sweden.Profile], so the parameter is implicitly true. A Relying Party MUST NOT assign the value false. OPTIONAL Section 2 of [OpenID.Registration]

4.1. Relying Party Algorithm Parameters

The parameters below are the Relying Party's declarations of the signature and encryption algorithms to be used between it and the OpenID Providers of the federation. Each of them holds a single value, and that value is consumed by every OpenID Provider in the federation. Support for [OpenID.RP.Choices], which would let a Relying Party declare several values for a parameter, is only RECOMMENDED within Sweden Connect and cannot be relied upon, so these single-valued parameters have to carry the interoperability load. Sweden Connect therefore regulates their values, rather than leaving the choice to each Relying Party, so that any Relying Party and any OpenID Provider in the federation can work together. The permitted values follow from the algorithm requirements of Section 3 of [SC.Security] and Section 7.1 of [OIDC.Sweden.Profile].

Table 4: Relying Party metadata parameters selecting signature and encryption algorithms.
Parameter Description Requirement Defined in
id_token_signed
_response_alg 		The JWS algorithm the Relying Party requires OpenID Providers to use when signing ID Tokens issued to it. See "Signing of ID Tokens and UserInfo responses" below. Section 2 of [OpenID.Registration]
id_token_encrypted
_response_alg 		The JWE key management algorithm the Relying Party requires OpenID Providers to use when encrypting ID Tokens issued to it, which establishes the content encryption key. If given, the value MUST be one of the key management algorithms that Section 3 of [SC.Security] makes mandatory. The default, if the parameter is omitted, is that the ID Token is not encrypted. OPTIONAL Section 2 of [OpenID.Registration]
id_token_encrypted
_response_enc 		The JWE content encryption algorithm the Relying Party requires OpenID Providers to use when encrypting ID Tokens issued to it, which is applied to the token itself. If given, the value MUST be one of the content encryption algorithms that Section 3 of [SC.Security] makes mandatory. If id_token_encrypted_response_alg is given, the default for this parameter is according to Section 2 of [OpenID.Registration]. When this parameter is given, id_token_encrypted_response_alg MUST also be given. OPTIONAL Section 2 of [OpenID.Registration]
userinfo_signed
_response_alg 		The JWS algorithm the Relying Party requires OpenID Providers to use when signing UserInfo responses issued to it. See "Signing of ID Tokens and UserInfo responses" below. Section 2 of [OpenID.Registration]
userinfo_encrypted
_response_alg 		The JWE key management algorithm the Relying Party requires OpenID Providers to use when encrypting UserInfo responses issued to it, which establishes the content encryption key. If given, the value MUST be one of the key management algorithms that Section 3 of [SC.Security] makes mandatory. The default, if the parameter is omitted, is that the UserInfo response is not encrypted. OPTIONAL Section 2 of [OpenID.Registration]
userinfo_encrypted
_response_enc 		The JWE content encryption algorithm the Relying Party requires OpenID Providers to use when encrypting UserInfo responses issued to it, which is applied to the response itself. If given, the value MUST be one of the content encryption algorithms that Section 3 of [SC.Security] makes mandatory. If userinfo_encrypted_response_alg is given, the default for this parameter is according to Section 2 of [OpenID.Registration]. When this parameter is given, userinfo_encrypted_response_alg MUST also be given. OPTIONAL Section 2 of [OpenID.Registration]
request_object
_signing_alg 		The JWS algorithm the Relying Party declares that it uses when signing Request Objects sent to an OpenID Provider, and against which an OpenID Provider validates them. If given, the value MUST be one of the signature algorithms that Section 3 of [SC.Security] makes mandatory. OPTIONAL Section 2 of [OpenID.Registration]
request_object
_encryption_alg 		The JWE key management algorithm the Relying Party declares that it may use when encrypting Request Objects sent to an OpenID Provider, which establishes the content encryption key. If given, the value MUST be one of the key management algorithms that Section 3 of [SC.Security] makes mandatory. OPTIONAL Section 2 of [OpenID.Registration]
request_object
_encryption_enc 		The JWE content encryption algorithm the Relying Party declares that it may use when encrypting Request Objects sent to an OpenID Provider, which is applied to the Request Object itself. If given, the value MUST be one of the content encryption algorithms that Section 3 of [SC.Security] makes mandatory. If request_object_encryption_alg is given, the default for this parameter is according to Section 2 of [OpenID.Registration]. When this parameter is given, request_object_encryption_alg MUST also be given. OPTIONAL Section 2 of [OpenID.Registration]
token_endpoint_auth
_signing_alg 		The JWS algorithm the Relying Party declares that it uses when signing the JWT that authenticates it at the Token endpoint, and against which an OpenID Provider validates it. The parameter always applies within Sweden Connect, since token_endpoint_auth_method is private_key_jwt. If given, the value MUST be one of the signature algorithms that Section 3 of [SC.Security] makes mandatory, and none MUST NOT be used. OPTIONAL Section 2 of [OpenID.Registration]

Signing of ID Tokens and UserInfo responses

The parameters id_token_signed_response_alg and userinfo_signed_response_alg declare which algorithm the Relying Party wants an OpenID Provider to use when signing ID Tokens and UserInfo responses. The algorithm is applied with the OpenID Provider's key, not with the Relying Party's, and an OpenID Provider within Sweden Connect may hold a key of only one type. A Relying Party therefore cannot name a value that every OpenID Provider in the federation is able to use.

Omitting the parameters does not help, since both have defaults. Section 2 of [OpenID.Registration] gives id_token_signed_response_alg the default RS256, so an absent parameter selects RSA rather than leaving the choice open. An absent userinfo_signed_response_alg means that the response is not signed at all, which contradicts the requirement in Section 4.1 of [OIDC.Sweden.Profile] that UserInfo responses MUST be signed.

Within Sweden Connect the declaration is not needed. Section 3 of [SC.Security] requires every Entity to support signature validation with all the listed algorithms, so a Relying Party can validate whatever an OpenID Provider signs with. The following therefore applies:

  • Whatever value a Relying Party declares for id_token_signed_response_alg or userinfo_signed_response_alg is removed by the metadata policy that the Sweden Connect Trust Anchor applies, so neither parameter appears in the resolved metadata. A Relying Party that operates only within Sweden Connect has no reason to declare them.

  • An OpenID Provider MUST NOT apply the defaults given by Section 2 of [OpenID.Registration] when these parameters are absent. The algorithm is chosen by the OpenID Provider, from those required by Section 3 of [SC.Security], and matching the key it holds.

A Relying Party's metadata may also be resolved based on another Trust Anchor, that is, within another federation, where nothing is removed and these parameters take effect. There the base defaults apply if the parameters are absent, so a Relying Party that operates in more than one federation SHOULD declare them. Declaring them has no effect within Sweden Connect.

For the parameters below, the metadata policy that the Sweden Connect Trust Anchor applies adds the signature algorithms of Section 3 of [SC.Security] to the values a Relying Party declares. The resolved metadata therefore always states that the Relying Party accepts the algorithms every Entity in the federation supports, which keeps the choice of signing algorithm with the OpenID Provider, while a Relying Party that supports more than that keeps its own values.

Table 5: Choices parameters replacing the signing response algorithm parameters.
Parameter Description Requirement Defined in
id_token_signing_alg
_values_supported 		The JWS algorithms the Relying Party supports when validating the ID Token signature. REQUIRED

Assigned by Federation Operator.		 Section 2 of [OpenID.RP.Choices]
userinfo_signing_alg
_values_supported 		The JWS algorithms the Relying Party supports when validating the UserInfo response signature. REQUIRED

Assigned by Federation Operator.		 Section 2 of [OpenID.RP.Choices]

Outside Sweden Connect nothing is added to these parameters either, and the declared values are the ones that apply. It is therefore RECOMMENDED that a Relying Party declares values that reflect what it supports, even though the Sweden Connect Registration Intermediate does not check them.

Section 2 of [OpenID.RP.Choices] defines further client metadata parameters in which a Relying Party may declare several supported values instead of one. These MAY be used, and this specification does not regulate them beyond the two parameters described above.

5. OpenID Provider Requirements

This section covers the metadata of the Entity Type openid_provider, as defined in Section 5.1.3 of [OpenID.Federation]. An OpenID Provider publishes these parameters in the metadata Claim of its Entity Configuration. The parameters are those defined for OpenID Provider Discovery in Section 3 of [OpenID.Discovery], with the requirement levels stated by Section 5.2 of [OIDC.Sweden.Profile] and Section 2.1 of [OIDC.SC.Profile]. The parameters of Common Requirements apply in addition to those listed here.

Table 6: OpenID Provider metadata parameters defined by the OpenID Connect specifications.
Parameter Description Requirement Defined in
issuer The Issuer Identifier of the OpenID Provider. The value MUST match the Entity Identifier of the OpenID Provider, that is, the iss Claim of its Entity Configuration, see Section 5.1.3 of [OpenID.Federation]. REQUIRED Section 3 of [OpenID.Discovery]
authorization_endpoint The URL of the OpenID Provider's authorization endpoint. REQUIRED Section 3 of [OpenID.Discovery]
token_endpoint The URL of the OpenID Provider's Token endpoint. REQUIRED Section 3 of [OpenID.Discovery]
userinfo_endpoint The URL of the OpenID Provider's UserInfo endpoint. REQUIRED Section 3 of [OpenID.Discovery]
ui_locales_supported The languages the OpenID Provider supports in its user interface. The value MUST contain en and sv, and MAY contain other languages. REQUIRED Section 3 of [OpenID.Discovery]
service_documentation A URL to human-readable information about the OpenID Provider. RECOMMENDED Section 3 of [OpenID.Discovery]
scopes_supported The scope values the OpenID Provider supports. See Section 5.1, Supported Scopes and Claims. REQUIRED Section 3 of [OpenID.Discovery]
claims_supported The claim names the OpenID Provider may be able to supply values for. See Section 5.1, Supported Scopes and Claims. REQUIRED Section 3 of [OpenID.Discovery]
response_types_supported The OAuth 2.0 response types the OpenID Provider supports. The value MUST contain code, see Section 5.2 of [OIDC.Sweden.Profile]. REQUIRED Section 3 of [OpenID.Discovery]
acr_values_supported The Authentication Context Class Reference values the OpenID Provider supports. The values defined for use within Sweden Connect are given in Section 3.1.1 of [SC.Registry].

The Federation Operator checks that the OpenID Provider is authorized to issue the supplied acr values in ID Tokens, and pins these values in a metadata policy.		 REQUIRED

Controlled by Federation Operator.		 Section 3 of [OpenID.Discovery]
subject_types_supported The Subject Identifier types the OpenID Provider supports. The value MUST contain public and SHOULD contain pairwise, see sections 5.2 and 3.2.1.1 of [OIDC.Sweden.Profile]. REQUIRED Section 3 of [OpenID.Discovery]
token_endpoint_auth
_methods_supported 		The client authentication methods the OpenID Provider supports at the Token endpoint. The value MUST contain private_key_jwt. REQUIRED Section 3 of [OpenID.Discovery]
claims_parameter
_supported 		Whether the OpenID Provider supports the claims request parameter. The value MUST be true. REQUIRED Section 3 of [OpenID.Discovery]
request_parameter
_supported 		Whether the OpenID Provider supports the request parameter for Request Objects. The value MUST be true. REQUIRED Section 3 of [OpenID.Discovery]
request_uri_parameter
_supported 		Whether the OpenID Provider supports the request_uri parameter, that is, Request Objects passed by reference. The value true is RECOMMENDED, see Section 5.3 below. REQUIRED Section 3 of [OpenID.Discovery]
code_challenge_methods
_supported 		The PKCE code challenge methods the OpenID Provider supports. Required by Section 5.2 of [OIDC.Sweden.Profile]. The value MUST include S256 and MUST NOT include plain. REQUIRED Section 2 of [RFC8414]
client_registration
_types_supported 		The client registration types the OpenID Provider supports. If not supplied, the Federation Operator will pin the value automatic in a metadata policy. REQUIRED

Assigned by Federation Operator.

OPTIONAL to provide.		 Section 5.1.3 of [OpenID.Federation]
https://id.oidc.se/disco/
userMessageSupported 		Whether the OpenID Provider supports displaying a message supplied by the Relying Party. Section 2.2.2 of [OIDC.SC.Profile] recommends support for the https://id.oidc.se/param/userMessage request parameter. An OpenID Provider that supports it MUST include this parameter and set its value to true. RECOMMENDED Section 3.1.1 of [OIDC.Sweden.RPar]
https://id.oidc.se/disco/
userMessageSupported
MimeTypes 		The MIME types the OpenID Provider supports for a user message. REQUIRED if MIME types other than text/plain are supported, see Section 2.2.2 of [OIDC.SC.Profile]. If the parameter is absent, ["text/plain"] is assumed. The value is only relevant if userMessageSupported (above) is true. OPTIONAL Section 3.1.2 of [OIDC.Sweden.RPar]
https://id.oidc.se/disco/
authnProviderSupported 		Declares that the OpenID Provider accepts the https://id.oidc.se/param/authnProvider request parameter, by which a Relying Party asks for a specific underlying authentication service or mechanism. This applies to an OpenID Provider that acts as a proxy for underlying authentication mechanisms, or that offers more than one authentication mechanism. Section 2.2.3 of [OIDC.SC.Profile] states that such an OpenID Provider SHOULD support the request parameter, and an OpenID Provider that supports it MUST declare this parameter. OPTIONAL Section 3.2 of [OIDC.Sweden.RPar]

5.1. Supported Scopes and Claims

The scopes_supported parameter MUST contain the openid value. Furthermore, the following requirements apply:

The claims_supported parameter MUST contain all claims that are part of the scope definitions for each declared scope.

Note: Claims that a Relying Party cannot request, either indirectly using a scope, or directly using the claims request parameter, do not have to be listed in claims_supported.

5.2. OpenID Provider Algorithm Parameters

The parameters below declare the signature and encryption algorithms that an OpenID Provider supports. Within the Sweden Connect federation, the metadata policy that the Sweden Connect Trust Anchor applies adds the algorithms of Section 3 of [SC.Security] to the values an OpenID Provider declares. The resolved metadata therefore always contains the algorithms every Entity in the federation supports, while an OpenID Provider that supports more than that keeps its own values.

That holds only for a Trust Chain leading to the Sweden Connect Trust Anchor. An OpenID Provider's metadata may also be resolved based on another Trust Anchor, that is, within another federation, where nothing is added and the declared values are the ones that apply. It is therefore RECOMMENDED that an OpenID Provider declares values that reflect what it supports, even though the Sweden Connect Registration Intermediate does not check them.

  • id_token_signing_alg_values_supported, the algorithms the OpenID Provider signs ID Tokens with.
  • id_token_encryption_alg_values_supported, the key management algorithms it encrypts ID Tokens with.
  • id_token_encryption_enc_values_supported, the content encryption algorithms it encrypts ID Tokens with.
  • userinfo_signing_alg_values_supported, the algorithms it signs UserInfo responses with.
  • userinfo_encryption_alg_values_supported, the key management algorithms it encrypts UserInfo responses with.
  • userinfo_encryption_enc_values_supported, the content encryption algorithms it encrypts UserInfo responses with.
  • request_object_signing_alg_values_supported, the algorithms it accepts when validating a signed Request Object.
  • request_object_encryption_alg_values_supported, the key management algorithms it accepts when decrypting a Request Object.
  • request_object_encryption_enc_values_supported, the content encryption algorithms it accepts when decrypting a Request Object.
  • token_endpoint_auth_signing_alg_values_supported, the algorithms it accepts when validating the JWT that a Relying Party signs to authenticate at the Token endpoint.

The value none means that no signature is applied. It MUST NOT appear in id_token_signing_alg_values_supported, since Section 3.2.1 of [OIDC.Sweden.Profile] requires ID Tokens to be signed, nor in userinfo_signing_alg_values_supported, since Section 4.1 of [OIDC.Sweden.Profile] requires UserInfo responses to be signed. It MUST NOT appear in token_endpoint_auth_signing_alg_values_supported, see Section 5.2 of [OIDC.Sweden.Profile]. The value MAY appear in request_object_signing_alg_values_supported, since signing of Request Objects is recommended but not required. These requirements apply to the values an OpenID Provider declares, since the metadata policy adds values but does not remove any.

5.3. Signature Support

An OpenID Provider compliant with [OIDC.SC.Profile] MUST support "signature requests" as specified in [OIDC.Sweden.Sign]. The following metadata requirements apply:

  • The scopes_supported parameter (see Section 5.1 above) MUST contain https://id.oidc.se/scope/sign, https://id.oidc.se/scope/signApproval, or both, depending on the use cases the OpenID Provider supports, see Section 5.3 of [OIDC.Sweden.Sign]. An OpenID Provider that declares https://id.oidc.se/scope/sign SHOULD also declare https://id.oidc.se/scope/signApproval.
  • The claims_supported parameter (see Section 5.1 above) MUST include the claims given in the sign scope definitions in Section 3.2 of [OIDC.Sweden.Sign].
  • Section 5.3 of [OIDC.Sweden.Sign] requires that request_uri_parameter_supported is present. It is RECOMMENDED that the OpenID Provider supports signature requests sent by reference as Request Objects, that is, that the value is set to true.
  • Section 5.3 of [OIDC.Sweden.Sign] specifies that it is RECOMMENDED to include https://id.oidc.se/disco/userMessageSupportedMimeTypes, defined in Section 3.1.2 of [OIDC.Sweden.RPar], in the metadata. It states the MIME types the OpenID Provider supports for the sign_message field of a signature request. If the parameter is absent, ["text/plain"] is assumed.

6. Sweden Connect Metadata Policies

The requirements stated in the preceding chapters are enforced through the two mechanisms described in this chapter. A reader can use the chapter to see exactly what the federation applies to the metadata an Entity declares about itself. The resolved metadata is the result of applying these mechanisms to the Entity Configuration, see Section 10 of [OpenID.Federation].

The two mechanisms differ in scope. The metadata policy that the Sweden Connect Trust Anchor applies is federation-wide, and identical for every Entity of a given Entity Type. The values that a Sweden Connect Registration Intermediate sets when an Entity joins differ from one Entity to the next.

A Trust Anchor issues Subordinate Statements only for its Immediate Subordinates, which within Sweden Connect are the Registration Intermediates. A rule that is to reach every Leaf Entity of the federation therefore has to travel down the Trust Chain as a metadata policy. A value that differs per Entity is instead set by the Registration Intermediate that registers the Entity, since that Intermediate is the Entity's Immediate Superior.

6.1. Trust Anchor Metadata Policy

The policy below is carried in the Subordinate Statements that the Sweden Connect Trust Anchor issues, and applies to every Entity resolved through a Trust Chain leading to that Trust Anchor. Only the Entity Types openid_relying_party and openid_provider are shown, since those are the Entity Types this document covers. Any policy the Trust Anchor applies to other Entity Types is outside the scope of this document.

The algorithm parameters use the add operator, so the algorithms of Section 3 of [SC.Security] are added to whatever the Entity declares. An Entity that supports more than that keeps its own values, and an Entity that declares nothing ends up with the mandatory set.

The parameters id_token_signed_response_alg and userinfo_signed_response_alg are removed, using the value operator with a null value. The reason is given in Relying Party Algorithm Parameters.

The policy carries no per-Entity values. Those are set by the Registration Intermediate that registers the Entity, see Registration Intermediate Metadata Assignment.

{
  "metadata_policy": {
    "openid_relying_party": {
      "redirect_uris": { "essential": true },
      "response_types": { "essential": true, "superset_of": ["code"] },
      "grant_types": { "essential": true, "superset_of": ["authorization_code"] },
      "token_endpoint_auth_method": { "essential": true, "one_of": ["private_key_jwt"] },
      "client_uri": { "essential": true },
      "contacts": { "essential": true },
      "logo_uri": { "essential": true },
      "subject_type": { "default": "public", "one_of": ["public", "pairwise"] },
      "require_auth_time": { "one_of": [true] },

      "id_token_signed_response_alg": { "value": null },
      "userinfo_signed_response_alg": { "value": null },

      "id_token_signing_alg_values_supported": {
        "add": ["RS256", "RS384", "RS512", "ES256", "ES384", "ES512"]
      },
      "userinfo_signing_alg_values_supported": {
        "add": ["RS256", "RS384", "RS512", "ES256", "ES384", "ES512"]
      },

      "id_token_encrypted_response_alg": {
        "one_of": ["RSA-OAEP", "RSA-OAEP-256", "ECDH-ES"]
      },
      "id_token_encrypted_response_enc": {
        "one_of": ["A128CBC-HS256", "A256CBC-HS512", "A128GCM", "A256GCM"]
      },
      "userinfo_encrypted_response_alg": {
        "one_of": ["RSA-OAEP", "RSA-OAEP-256", "ECDH-ES"]
      },
      "userinfo_encrypted_response_enc": {
        "one_of": ["A128CBC-HS256", "A256CBC-HS512", "A128GCM", "A256GCM"]
      },
      "request_object_signing_alg": {
        "one_of": ["RS256", "RS384", "RS512", "ES256", "ES384", "ES512"]
      },
      "request_object_encryption_alg": {
        "one_of": ["RSA-OAEP", "RSA-OAEP-256", "ECDH-ES"]
      },
      "request_object_encryption_enc": {
        "one_of": ["A128CBC-HS256", "A256CBC-HS512", "A128GCM", "A256GCM"]
      },
      "token_endpoint_auth_signing_alg": {
        "one_of": ["RS256", "RS384", "RS512", "ES256", "ES384", "ES512"]
      }
    },

    "openid_provider": {
      "issuer": { "essential": true },
      "authorization_endpoint": { "essential": true },
      "token_endpoint": { "essential": true },
      "userinfo_endpoint": { "essential": true },
      "jwks_uri": { "essential": true },
      "contacts": { "essential": true },
      "logo_uri": { "essential": true },

      "scopes_supported": { "essential": true, "superset_of": ["openid"] },
      "response_types_supported": { "essential": true, "superset_of": ["code"] },
      "subject_types_supported": { "essential": true, "superset_of": ["public"] },
      "ui_locales_supported": { "essential": true, "superset_of": ["en", "sv"] },
      "acr_values_supported": { "essential": true },
      "claims_supported": { "essential": true },

      "token_endpoint_auth_methods_supported": {
        "essential": true,
        "superset_of": ["private_key_jwt"]
      },
      "code_challenge_methods_supported": {
        "essential": true,
        "subset_of": ["S256"],
        "superset_of": ["S256"]
      },
      "claims_parameter_supported": { "value": true },
      "request_parameter_supported": { "value": true },
      "request_uri_parameter_supported": { "essential": true },

      "client_registration_types_supported": { "default": ["automatic"] },

      "id_token_signing_alg_values_supported": {
        "essential": true,
        "add": ["RS256", "RS384", "RS512", "ES256", "ES384", "ES512"]
      },
      "userinfo_signing_alg_values_supported": {
        "add": ["RS256", "RS384", "RS512", "ES256", "ES384", "ES512"]
      },
      "request_object_signing_alg_values_supported": {
        "add": ["RS256", "RS384", "RS512", "ES256", "ES384", "ES512"]
      },
      "token_endpoint_auth_signing_alg_values_supported": {
        "essential": true,
        "add": ["RS256", "RS384", "RS512", "ES256", "ES384", "ES512"]
      },
      "id_token_encryption_alg_values_supported": {
        "add": ["RSA-OAEP", "RSA-OAEP-256", "ECDH-ES"]
      },
      "id_token_encryption_enc_values_supported": {
        "add": ["A128CBC-HS256", "A256CBC-HS512", "A128GCM", "A256GCM"]
      },
      "userinfo_encryption_alg_values_supported": {
        "add": ["RSA-OAEP", "RSA-OAEP-256", "ECDH-ES"]
      },
      "userinfo_encryption_enc_values_supported": {
        "add": ["A128CBC-HS256", "A256CBC-HS512", "A128GCM", "A256GCM"]
      },
      "request_object_encryption_alg_values_supported": {
        "add": ["RSA-OAEP", "RSA-OAEP-256", "ECDH-ES"]
      },
      "request_object_encryption_enc_values_supported": {
        "add": ["A128CBC-HS256", "A256CBC-HS512", "A128GCM", "A256GCM"]
      }
    }
  }
}

The code_challenge_methods_supported entry combines subset_of and superset_of. The intersection keeps plain out of the resolved metadata, and the superset check makes an OpenID Provider that declares only plain fail the policy.

Not every requirement in this document can be expressed as a metadata policy. The prohibition on none in id_token_signing_alg_values_supported, userinfo_signing_alg_values_supported, and token_endpoint_auth_signing_alg_values_supported cannot, since no operator removes a single value from an array. Nor can the rule that an _enc parameter requires its _alg partner, since no operator expresses a dependency between two parameters. Such requirements are checked by the Registration Intermediate when an Entity joins, or are not enforced by the federation at all.

6.2. Registration Intermediate Metadata Assignment

The parameters below hold values that differ from one Entity to the next. A Sweden Connect Registration Intermediate sets them in the Subordinate Statement it issues for the Entity, having checked the Entity as described in Section 3 of [OIDC.SC.Structure].

The Subordinate Statement carries both a metadata Claim and a metadata_policy Claim. The parameters organization_name and organization_identifier are set in the metadata Claim. The remaining parameters of the table below are pinned in the metadata_policy Claim, using the value operator.

Table 7: Parameters set per Entity by a Sweden Connect Registration Intermediate.
Parameter Checked before registration Mechanism
organization_name That the value given without a language tag is the legal name of the organization behind the Entity. Set in the metadata Claim. A value without a language tag is added, see General Requirements.
organization_identifier That the value holds the ten-digit Swedish organization number of that organization, in the form given in Common Requirements. Set in the metadata Claim.
display_name That the value is a correct presentation name for the Entity. Pinned in the metadata_policy Claim. Where a Relying Party has not declared display_name, the Registration Intermediate takes the value from client_name and pins that. A value without a language tag is added, see General Requirements.
logo_uri That the URL uses the HTTPS scheme and points to a valid image file. Pinned in the metadata_policy Claim.
client_name That the value is a correct presentation name for the Relying Party, and that it is given in Swedish and English. Pinned in the metadata_policy Claim. A value without a language tag is added, see General Requirements.
acr_values_supported That the OpenID Provider is authorized to issue the declared acr values in ID Tokens. Pinned in the metadata_policy Claim.

Note: Pinning a URL fixes the value that appears in the resolved metadata, so an Entity cannot point at a different resource after registration. It does not fix the resource itself. The Entity controls the server that hosts it and may replace what is served there at any time, so a check made at registration says nothing about what a peer will retrieve later. This applies to logo_uri, and equally to client_uri, organization_uri, policy_uri, and information_uri. It matters most for logo_uri, since that image may be displayed to the end-user during authentication.

The example below is non-normative. It shows the two Claims of a Subordinate Statement issued for a Relying Party belonging to the Swedish Agency for Digital Government (Digg). The Relying Party declared client_name and logo_uri, which are held fixed, and did not declare display_name, which is therefore derived from client_name. The values are illustrative.

{
  "iss": "https://fed.swedenconnect.se/im-reg-sc",
  "sub": "https://rp.example.se",
  ...
  "metadata": {
    "openid_relying_party": {
      "organization_name#sv": "Myndigheten för digital förvaltning",
      "organization_name#en": "The Swedish Agency for Digital Government",
      "organization_name": "Myndigheten för digital förvaltning",
      "organization_identifier": "urn:glue:iso6523:0007:2021006883"
    }
  },
  "metadata_policy": {
    "openid_relying_party": {
      "display_name#sv": { "value": "Min tjänst" },
      "display_name#en": { "value": "My service" },
      "display_name": { "value": "Min tjänst" },
      "client_name#sv": { "value": "Min tjänst" },
      "client_name#en": { "value": "My service" },
      "client_name": { "value": "Min tjänst" },
      "logo_uri": { "value": "https://www.example.se/logo.svg" }
    }
  }
}

Example of the metadata and metadata_policy Claims of a Subordinate Statement issued by a Sweden Connect Registration Intermediate for a Relying Party.

The example below is non-normative and shows a Subordinate Statement for an OpenID Provider. Unlike the Relying Party example, this OpenID Provider declared display_name itself, so the value is pinned rather than derived from another parameter, and the statement also pins the acr_values_supported that the Registration Intermediate has checked the OpenID Provider is authorized to issue.

{
  "iss": "https://fed.swedenconnect.se/im-reg-sc-op",
  "sub": "https://op.example.se",
  ...
  "metadata": {
    "openid_provider": {
      "organization_name#sv": "Acme AB",
      "organization_name#en": "Acme Inc.",
      "organization_name": "Acme AB",
      "organization_identifier": "urn:glue:iso6523:0007:2021006883"
    }
  },
  "metadata_policy": {
    "openid_provider": {
      "display_name#sv": { "value": "Exampel OP:n" },
      "display_name#en": { "value": "Example Authenticator" },
      "display_name": { "value": "Exampel OP:n" },
      "logo_uri": { "value": "https://www.acme.se/logo.svg" },
      "acr_values_supported": {
        "value": [
          "http://id.elegnamnden.se/loa/1.0/loa3",
          "http://id.elegnamnden.se/loa/1.0/loa2"
        ]
      }
    }
  }
}

Example of the metadata and metadata_policy Claims of a Subordinate Statement issued by a Sweden Connect Registration Intermediate for an OpenID Provider.

7. Normative References

[ISO.6523]
"ISO/IEC 6523-1:2023. Part 1: Identification of organization identification schemes", , <https://www.iso.org/standard/82246.html>.
[OIDC.SC.Claims]
Lindström, M., "OpenID Connect Claims and Scopes Specification for Sweden Connect", , <https://docs.swedenconnect.se/technical-framework/latest/OpenID_Connect_Claims_and_Scopes_Specification.html>.
[OIDC.SC.Profile]
Lindström, M. and S. Santesson, "OpenID Connect Profile for Sweden Connect", , <https://docs.swedenconnect.se/technical-framework/latest/OpenID_Connect_Profile_for_Sweden_Connect.html>.
[OIDC.SC.Structure]
Lindström, M., "Sweden Connect - OpenID Federation Structure", , <https://docs.swedenconnect.se/federation/oidf-structure.html>.
[OIDC.Sweden.Claims]
Lindström, M., "Claims and Scopes Specification for the Swedish OpenID Connect Profile", , <https://www.oidc.se/specifications/swedish-oidc-claims-specification-1_0.html>.
[OIDC.Sweden.Federation]
Lindström, M. and S. Santesson, "Swedish OpenID Federation Deployment and Interoperability Profile 1.0", , <https://www.oidc.se/specifications/swedish-openid-federation-profile.html>.
[OIDC.Sweden.Hosting]
Lindström, M. and S. Santesson, "OpenID Federation Entity Configuration Hosting 1.0", , <https://www.oidc.se/openid-federation-hosting/main.html>.
[OIDC.Sweden.OrgId]
Jones, M. B., Lindström, M., and S. Santesson, "OpenID Federation Organization Identifier Metadata Parameter 1.0", , <https://www.oidc.se/specifications/openid-federation-organization-identifier-1_0.html>.
[OIDC.Sweden.Profile]
Lindström, M., "The Swedish OpenID Connect Profile", , <https://www.oidc.se/specifications/swedish-oidc-profile-1_0.html>.
[OIDC.Sweden.RPar]
Lindström, M., "Authentication Request Parameter Extensions for the Swedish OpenID Connect Profile", , <https://www.oidc.se/specifications/request-parameter-extensions-1_1.html>.
[OIDC.Sweden.Sign]
Lindström, M., "Signature Extension for OpenID Connect", , <https://www.oidc.se/specifications/oidc-signature-extension-1_1.html>.
[OpenID.Discovery]
Sakimura, N., Bradley, J., Jones, M., and E. Jay, "OpenID Connect Discovery 1.0 incorporating errata set 2", , <https://openid.net/specs/openid-connect-discovery-1_0.html>.
[OpenID.Federation]
Hedberg, R., Jones, M. B., Solberg, A., Bradley, J., Marco, G. D., and V. Dzhuvinov, "OpenID Federation 1.0", , <https://openid.net/specs/openid-federation-1_0.html>.
[OpenID.RP.Choices]
Jones, M. B., Hedberg, R., Bradley, J., and F. Skokan, "OpenID Connect Relying Party Metadata Choices 1.0", , <https://openid.net/specs/openid-connect-rp-metadata-choices-1_0.html>.
[OpenID.Registration]
Sakimura, N., Bradley, J., and M. Jones, "OpenID Connect Dynamic Client Registration 1.0 incorporating errata set 2", , <https://openid.net/specs/openid-connect-registration-1_0.html>.
[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <https://www.rfc-editor.org/info/rfc2119>.
[RFC8174]
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <https://www.rfc-editor.org/info/rfc8174>.
[RFC8414]
Jones, M., Sakimura, N., and J. Bradley, "OAuth 2.0 Authorization Server Metadata", RFC 8414, DOI 10.17487/RFC8414, , <https://www.rfc-editor.org/info/rfc8414>.
[SC.Registry]
Lindström, M. and S. Santesson, "Sweden Connect - Registry for identifiers", , <https://docs.swedenconnect.se/technical-framework/latest/03_-_Registry_for_Identifiers.html>.
[SC.Security]
Lindström, M., "Sweden Connect - Security Requirements 1.0", , <https://docs.swedenconnect.se/federation/security-requirements.html>.

8. Informative References

[I-D.ietf-spice-glue-id]
Zundel, B., Dingle, P., and M. B. Jones, "GLobal Unique Enterprise (GLUE) Identifiers", Work in Progress, Internet-Draft, draft-ietf-spice-glue-id-10, , <https://datatracker.ietf.org/doc/html/draft-ietf-spice-glue-id-10>.
[SKV709]
Skatteverket, "Skatteverket, SKV 709, Utgåva 8, Organisationsnummer", , <https://docs.swedenconnect.se/technical-framework/mirror/skv/skv709-8.pdf>.

Appendix A. Notices

Copyright (c) The Swedish Agency for Digital Government (Digg), 2015-2026. All Rights Reserved.

Appendix B. Document History

Draft 0.1
Initial version

Author's Address

Martin Lindström
The Swedish Agency for Digital Government (Digg)