BAS Metadata requirements

Abstract

This specification defines the metadata requirements for OAuth 2.0 Clients, Authorization Servers and Protected Resources participating in Federationskontext BAS, a federation context for machine-to-machine access within the Swedish public sector. The metadata is published in Entity Configurations according to OpenID Federation 1.1. 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. The primary purpose of the requirements is that a party can verify the system identity of an Entity and the organization it is registered for. The requirements also support interoperability according to the Ena OAuth 2.0 Interoperability Profile, and the registration of Clients at Authorization Servers, in that identifiers, keys, authentication methods, endpoints and algorithms are obtained from Resolved Metadata rather than agreed bilaterally. They do not regulate the information exchange that follows, including which scopes are defined or requested and what access a Client is granted.

1. Introduction

This document specifies the metadata that an OAuth 2.0 Client, Authorization Server or Protected Resource publishes when it joins Federationskontext BAS, hereafter BAS. It is written for the organizations that operate such Entities, and for the developers and operators who implement them. How BAS is structured, and which requirements apply when Federation Members are connected and their Entities registered, is described in [BAS.Rules].

BAS is a federation context for machine-to-machine access within, and towards, the Swedish public sector. It exists so that a party can verify the system identity of another party's Entity, and which organization that Entity is registered for, before any information is exchanged. This is the primary purpose of the requirements in this document. The same metadata also serves two further purposes. It supports interoperability according to the Ena OAuth 2.0 Interoperability Profile [Ena.OAuth2], in that the endpoints, keys, algorithms and authentication methods that parties need in order to interact are published in Resolved Metadata rather than agreed bilaterally. It also supports Client Registration, in that the Client's identifier, keys and authentication method can be taken from its Resolved Metadata. Meeting the requirements does not by itself ensure that two Entities can interoperate, nor does it result in Client Registration at every Authorization Server in BAS. [Ena.OAuth2] leaves some choices to the individual Entity, such as whether DPoP is supported, and the scopes, resources and access that an exchange depends on are agreed between the parties. Whether an Authorization Server accepts a Client, and what access it grants, remains the Authorization Server's decision. Every requirement in this document is derived from these purposes, and the document places no requirements beyond them. Section 1.3 states where the boundary lies.

BAS applies the requirements of the federation platform of Samordnad identitet och behörighet (SIB) for connection and registration. A Federation Member is connected under Requirements and Guidance for Connection (Swedish: Anslutning – Tillämpningskrav och vägledning) [SIB.Connection], which establishes the identity of the organization. Its Entities are then registered by a Federation Registration Operator under Requirements and Guidance for Registration (Swedish: Registrering – Tillämpningskrav och vägledning) [SIB.Registration], which establishes the identity of each Entity and its connection to the organization. Registration comprises three checks: verification of organisational affiliation, verification of registration submitter, and verification of display name (Swedish: verifiering av organisationskoppling, uppgiftslämnare och visningsnamn). Each check that has been performed is indicated by a registration policy URI in the Subordinate Statement for the Entity, see Section 7.2. What the checks mean and how they are performed is stated in [SIB.Registration]. This document states how their outcome is expressed in metadata, so that a peer can read it. The documents are meant to be read together. A metadata value assigned under this specification carries exactly the meaning given to it by the corresponding requirement, and no other.

The protocol requirements build on [Ena.OAuth2], which is the profile that BAS applies. Entities in BAS adhere to that profile. This document restates its metadata requirements and adds the constraints that follow from operating in a federation, where a Client joins the federation rather than registering separately with each Authorization Server it uses. Where the profile leaves a parameter optional but the purposes above require it to be present, this document raises the requirement level. The requirements on keys, signature algorithms and client authentication are stated in [BAS.Security]. This is the current scope rather than a permanent limitation. BAS may later admit other Entity Types, and Entities adhering to other profiles, and the requirements in this document would then not apply to them unaltered.

The requirements build on a number of further specifications. [OpenID.Federation] defines how metadata is published and resolved, and [OpenID.Federation.Connect] defines the Entity Types for OAuth 2.0. [OIDC.Sweden.Federation] profiles OpenID Federation for use in Swedish federations, a profile that BAS follows, and requires that an Authorization Server accepts and incorporates the metadata of a Client registered in the federation. [RFC7591], [RFC8414] and [RFC9728] define the metadata parameters for the three Entity Types. [OIDC.Sweden.OrgId] defines the parameter that identifies the organization behind an Entity, and [OpenID.Federation.RegPolicy] defines how the registration checks are expressed.

The requirement chapters state what has to appear in the Resolved Metadata of an Entity. Common Requirements covers the parameters that all three Entity Types share and that express identity and organizational connection. These requirements do not depend on the choices made for BAS, and are specified so that they can be applied unaltered in other federation contexts. The chapters on Clients, Authorization Servers and Protected Resources contain the requirements that are specific to BAS, including those that support interoperability and Client Registration. BAS Metadata Policies shows how the requirements are enforced, through the metadata policy that the BAS Trust Anchor applies to every Entity, and through the per-Entity values that a Federation Registration Entity sets when an Entity joins the federation. Within BAS these two roles are held by different organizations, the Federation Operator and a Federation Registration Operator, and the document states for every assigned or constrained value which of them controls it.

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.

1.2. Terminology

This specification uses the terms "Entity", "Entity Configuration", "Entity Identifier", "Entity Type Identifier", "Intermediate Entity", "Leaf Entity", "Subordinate Statement", "Trust Anchor", "Trust Chain" and "Resolved Metadata" as defined in [OpenID.Federation], and the terms "Federation Protocol Entity" and "Federation Registration Entity" as defined in [OIDC.Sweden.Federation]. It uses the terms "Client", "Authorization Server" and "Protected Resource" as defined in [Ena.OAuth2]. Within BAS, the Federation Registration Entity is the connection service (Swedish: anslutningstjänst) that a Federation Registration Operator provides.

This specification also defines the following terms:

• Client Registration: The incorporation of a Client into the service configuration of an Authorization Server, based on the Client's Resolved Metadata. Client Registration is distinct from the registration of an Entity in BAS, which a Federation Registration Entity performs by issuing a Subordinate Statement for the Entity.
• Federation Member (Swedish: Federationsmedlem): An organization that has been connected to BAS under [SIB.Connection], and on whose behalf Entities are registered in BAS.
• Federation Operator (Swedish: Federationsoperatör): The organization that operates the BAS Trust Anchor. For BAS, this is the Swedish Agency for Digital Government (Digg).
• Federation Registration Operator (Swedish: Anslutningsoperatör): An organization that has been connected to BAS as a Federation Registration Operator under [SIB.Connection], and that registers the Entities of Federation Members under [SIB.Registration].

1.3. Scope of the Requirements

The requirements in this document serve the purposes stated in Section 1. Primarily, a party can verify who it is about to exchange information with. In addition, Entities can interoperate according to [Ena.OAuth2], and Client Registration can be based on Resolved Metadata. To that end, this document regulates

• the parameters that identify the Entity and the organization it is registered for (Section 3), and the registration checks that have been performed (Section 7.2),
• where the keys by which the Entity's identity is verified are published (Sections 4, 5 and 6), while the requirements on the keys and algorithms themselves are stated in [BAS.Security],
• the way an Entity presents its identity to a peer, including its identifier and, for a Client, its authentication method (Sections 4.1, 4.2, 5 and 6.1),
• the protocol parameters that a peer needs in order to interact with the Entity, including those an Authorization Server needs for Client Registration (Sections 4, 5 and 6),
• the parameters that [Ena.OAuth2] requires an Entity to publish, at the requirement levels that profile states unless this document raises them, and
• which of the Federation Operator and the Federation Registration Operator controls each value that is assigned or constrained in the Trust Chain (Section 7).

Where [Ena.OAuth2] leaves a choice to the individual Entity, such as whether to support DPoP or access tokens bound to a TLS client certificate, this document may require the Entity to declare its choice in its metadata, but does not make the choice for it. A peer can therefore determine from Resolved Metadata whether an interaction is possible, but the requirements do not ensure that it is.

This document does not regulate the information exchange itself. It places no requirements on which scopes an Authorization Server defines or a Client requests, on the claims carried in access tokens, or on the interface of a Protected Resource. Where such parameters appear in the tables, they are included because the underlying specification defines them, and their values are left to the parties to an exchange.

Nor does this document regulate the decisions that the metadata informs. Whether an Authorization Server accepts a Client, which Clients may obtain access tokens for a Protected Resource, and what access is granted, are decided by the parties to an exchange and are outside the scope of this document.

2. General Requirements

This document specifies metadata requirements for OAuth 2.0 Clients, Authorization Servers and Protected Resources in BAS. The metadata is carried in the metadata Claim of each Entity's Entity Configuration, under the Entity Type Identifier oauth_client, oauth_authorization_server or oauth_resource, as specified in Sections 5.1.3 to 5.1.5 of [OpenID.Federation.Connect]. A Client or Protected Resource that cannot publish an Entity Configuration of its own may have it hosted by the Federation Registration Entity 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 Federation Registration Entity 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 BAS rather than to an individual Entity, and these are enforced through the metadata policy that the Trust Anchor applies. A parameter that is REQUIRED in the Resolved Metadata is therefore not always a parameter the Entity has to declare itself. Where a Federation Registration Entity supplies or modifies a value, or a metadata policy constrains it, the Description column says so.

Some metadata values are verified by the Federation Registration Operator when an Entity is registered, and are fixed by the Federation Registration Entity in the Subordinate Statement for the Entity. Which values are verified, and how, is stated in [SIB.Registration] and [BAS.Rules]. Section 7.2 states how the values are assigned.

Metadata values intended for human consumption are provided in both Swedish and English using language tags, as stated in [Ena.OAuth2]. Within BAS, Swedish is the default language. The Federation Registration Entity assigns a corresponding parameter without a language tag, holding the Swedish value, in the Subordinate Statement, so that the Resolved Metadata always contains it and implementations without support for language tags can use it. A value without a language tag that the Entity declares itself is replaced by the value assigned by the Federation Registration Entity.

"client_name#sv" : "Min tjänst",
"client_name#en" : "My service",
"client_name"    : "Min tjänst"   <- assigned by the Federation Registration Entity

Example: Multilingual parameter.

The keys that an Entity uses in the OAuth 2.0 protocol, as opposed to the Federation Entity Keys that sign its Entity Statements, are published in its oauth_client, oauth_authorization_server or oauth_resource metadata, as stated in Sections 4 to 6. The keys MUST meet the requirements of [BAS.Security].

This document does not specify the Entity Statement Claims themselves, such as iss, sub, iat, exp, jwks, authority_hints and trust_marks, with the exception of the registration_policy Claim, see Section 7.2. Those Claims are defined by Section 3.1 of [OpenID.Federation] and profiled by [OIDC.Sweden.Federation]. Clients, Authorization Servers and Protected Resources 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 BAS.

3. Common Requirements

The table below covers the metadata parameters that Clients, Authorization Servers and Protected Resources publish with the same meaning in their oauth_client, oauth_authorization_server and oauth_resource metadata, respectively. These parameters describe the Entity and the organization behind it, and are defined in Section 5.2.2 of [OpenID.Federation]. Some of these values are verified when an Entity is registered, see Section 2.

Table 1: Organization and informational metadata parameters.

3.1. The organization_identifier Format

A Swedish organization number is a ten-digit string, without a hyphen, according to [SKV709]. To allow BAS to interoperate with other federations, 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.

4. OAuth Client Requirements

The table below covers the metadata parameters that a Client publishes in its oauth_client metadata, in addition to those in Section 3. The parameters are defined in Section 2 of [RFC7591], and profiled by Section 2.2.2 of [Ena.OAuth2]. This version of the document covers Clients that use the client_credentials grant, which is the grant type that [BAS.Rules] permits. Parameters that apply only to other grant types, such as redirect_uris, require_signed_request_object and require_pushed_authorization_requests, are therefore not used. The token_endpoint_auth_signing_alg parameter defined by [OpenID.Registration] is not used either, since a Client in BAS does not declare the algorithm it signs with, see Section 4.2.

Table 2: Client metadata parameters.

4.1. Client Identifier

The client identifier of a Client in BAS is its Entity Identifier. A Client MUST use its Entity Identifier as client_id at every Authorization Server it interacts with. This fulfils the requirement of Section 2.2.1 of [Ena.OAuth2] that a Client in a federative context uses the same client identifier for all registrations, and allows every Authorization Server to verify the Client's identity and organizational connection through its Trust Chain.

4.2. Client Authentication

A Client in BAS authenticates at the token endpoint, and at any revocation or introspection endpoint, using the private_key_jwt method, as specified in Section 8.3.1 of [Ena.OAuth2]. This is the only client authentication method used within BAS, and every Authorization Server in BAS supports it, see Section 2 of [BAS.Security]. The keys used for signing are those published in jwks or jwks_uri. The Client signs with one of the algorithms that the Authorization Server declares in token_endpoint_auth_signing_alg_values_supported. Since every Authorization Server in BAS declares RS256 and ES256, see Section 3.1 of [BAS.Security], a Client that signs with one of them can authenticate at every Authorization Server in BAS.

5. Authorization Server Requirements

The table below covers the metadata parameters that an Authorization Server publishes in its oauth_authorization_server metadata, in addition to those in Section 3. The parameters are defined in Section 2 of [RFC8414], and profiled by Section 3.1.1 of [Ena.OAuth2]. Parameters that apply only to grant types other than client_credentials, such as authorization_endpoint, pushed_authorization_request_endpoint, code_challenge_methods_supported and require_signed_request_object, are not used.

An Authorization Server also publishes its metadata at the location stated in Section 3.1.2 of [Ena.OAuth2]. For every parameter that appears in both, the metadata published there MUST be consistent with the Authorization Server's Resolved Metadata. Where the Trust Anchor metadata policy removes values that the Authorization Server supports outside BAS, such as other grant types or client authentication methods, the value in the Resolved Metadata is a subset of the published value, and the two are consistent in this sense.

Table 3: Authorization Server metadata parameters.

6. Protected Resource Requirements

The table below covers the metadata parameters that a Protected Resource publishes in its oauth_resource metadata, in addition to those in Section 3. The parameters are defined in Section 2 of [RFC9728], which Section 5.1.5 of [OpenID.Federation.Connect] makes available to oauth_resource metadata, and profiled by Section 4.3 of [Ena.OAuth2].

Table 4: Protected Resource metadata parameters.

6.1. Resource Identifier

The resource identifier of a Protected Resource in BAS is its Entity Identifier. The resource parameter MUST be equal to the Entity Identifier, and MUST meet the requirements of Section 4.3 of [Ena.OAuth2]: it is a URL using the HTTPS scheme with a host component, it SHOULD NOT include a query component, and it MUST NOT include a fragment component. An Authorization Server uses the resource identifier as the audience of the access tokens it issues for the Protected Resource, see Section 6.1.1 of [Ena.OAuth2]. Resources that do not share the same access rules are registered as separate Entities, each with its own resource identifier, as recommended in Section 4.3 of [Ena.OAuth2].

7. BAS 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 BAS 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 and in who controls them. The metadata policy that the BAS Trust Anchor applies is federation-wide, identical for every Entity of a given Entity Type, and controlled by the Federation Operator. The values that a Federation Registration Entity sets when an Entity is registered differ from one Entity to the next, and are controlled by the Federation Registration Operator that registered the Entity.

A Trust Anchor issues Subordinate Statements only for its Immediate Subordinates, which within BAS are the Federation Registration Entities. A rule that is to reach every Leaf Entity in BAS therefore travels down the Trust Chain as a metadata policy. A value that differs per Entity is instead set by the Federation Registration Entity that registers the Entity, since that Entity is the Leaf Entity's Immediate Superior. When metadata is resolved, the metadata Claim of the Subordinate Statement about the Leaf Entity is applied first, and the resolved metadata policy after that, see Section 6.1.4.2 of [OpenID.Federation].

7.1. Trust Anchor Metadata Policy

The policy below is carried in the Subordinate Statements that the BAS Trust Anchor issues, and applies to every Entity resolved through a Trust Chain leading to that Trust Anchor. Only the Entity Types oauth_client, oauth_authorization_server and oauth_resource are shown, since those are the Entity Types this document covers. The policy uses the operators of Section 6.1.3.1 of [OpenID.Federation].

{
  "metadata_policy": {
    "oauth_client": {
      "organization_name": { "essential": true },
      "organization_identifier": { "essential": true },
      "contacts": { "essential": true },
      "token_endpoint_auth_method": {
        "essential": true,
        "one_of": ["private_key_jwt"]
      },
      "grant_types": {
        "essential": true,
        "subset_of": ["client_credentials"],
        "superset_of": ["client_credentials"]
      },
      "response_types": { "value": [] }
    },
    "oauth_authorization_server": {
      "organization_name": { "essential": true },
      "organization_identifier": { "essential": true },
      "contacts": { "essential": true },
      "issuer": { "essential": true },
      "token_endpoint": { "essential": true },
      "jwks_uri": { "essential": true },
      "response_types_supported": { "essential": true },
      "scopes_supported": { "essential": true },
      "grant_types_supported": {
        "essential": true,
        "subset_of": ["client_credentials"],
        "superset_of": ["client_credentials"]
      },
      "token_endpoint_auth_methods_supported": {
        "essential": true,
        "subset_of": ["private_key_jwt"],
        "superset_of": ["private_key_jwt"]
      },
      "revocation_endpoint_auth_methods_supported": {
        "subset_of": ["private_key_jwt"],
        "superset_of": ["private_key_jwt"]
      },
      "introspection_endpoint_auth_methods_supported": {
        "subset_of": ["private_key_jwt"],
        "superset_of": ["private_key_jwt"]
      },
      "token_endpoint_auth_signing_alg_values_supported": {
        "essential": true,
        "superset_of": ["RS256", "ES256"],
        "subset_of": ["RS256", "RS384", "RS512", "ES256", "ES384", "ES512",
                      "PS256", "PS384", "PS512"]
      }
    },
    "oauth_resource": {
      "organization_name": { "essential": true },
      "organization_identifier": { "essential": true },
      "contacts": { "essential": true },
      "resource": { "essential": true }
    }
  }
}

The operators act as follows:

• essential makes the parameter mandatory in the Resolved Metadata. An Entity whose Resolved Metadata lacks it fails policy resolution, and its Trust Chain is not valid.
• one_of checks that a Client's token_endpoint_auth_method is private_key_jwt.
• subset_of and superset_of with identical values require the value to be exactly that set, see Section 6.1.3.1.8 of [OpenID.Federation]. A grant type or client authentication method that an Authorization Server supports outside BAS is removed from its Resolved Metadata in BAS. An Entity that does not declare the required value fails policy resolution.
• For token_endpoint_auth_signing_alg_values_supported, superset_of is a check that RS256 and ES256 are declared, as Section 3.1 of [BAS.Security] requires, and subset_of is a filter that removes algorithms that [BAS.Security] does not permit.
• value assigns an empty response_types array to every Client, whatever the Client declares.

The values in the grant type entries follow the grant types that [BAS.Rules] permits, and are updated by the Federation Operator if [BAS.Rules] changes.

Some requirements cannot be expressed with the standard operators, such as that a Client publishes either jwks or jwks_uri but not both, that issuer and resource are equal to the Entity Identifier, and that URLs use the HTTPS scheme. A Federation Registration Entity SHOULD reject the registration of an Entity whose metadata does not meet them, and a peer that finds them unmet MUST NOT use the Resolved Metadata.

7.2. Federation Registration Entity Metadata Assignment

The parameters below hold values that differ from one Entity to the next. A Federation Registration Entity sets them in the Subordinate Statement it issues for the Entity, having performed the checks of [SIB.Registration]. The values are set in the metadata Claim of the Subordinate Statement, under the Entity Type of the Entity, and replace any value the Entity declares itself. A verified value is held fixed: the Entity cannot change it without a new verification under [SIB.Registration].

Table 5: Parameters set per Entity by a Federation Registration Entity.

The Federation Registration Entity also includes the registration_policy Claim defined in [OpenID.Federation.RegPolicy] in the Subordinate Statement. The Claim MUST list the registration policy URI of every check that has been performed for the Entity. The URIs are defined in [SIB.Registration]:

Table 6: Registration policy URIs.

The example below is non-normative. It shows the metadata and registration_policy Claims of a Subordinate Statement issued for a Client belonging to the Swedish Agency for Digital Government (Digg). The Client declared client_name in Swedish and English but not display_name, which is therefore taken from client_name. All three checks have been performed. The issuer and the two URIs not yet assigned are illustrative.

{
  "iss": "https://anslutning.example.se",
  "sub": "https://client.digg.se",
  "metadata": {
    "oauth_client": {
      "organization_name": "Myndigheten för digital förvaltning",
      "organization_name#sv": "Myndigheten för digital förvaltning",
      "organization_name#en": "The Swedish Agency for Digital Government",
      "organization_identifier": "urn:glue:iso6523:0007:2021006883",
      "client_name": "Ärendetjänst"
    }
  },
  "registration_policy": [
    "https://id.ena-infrastructure.se/regpolicy/v1/orgconnection",
    "https://id.ena-infrastructure.se/regpolicy/v1/submitter",
  ]
}

Example of the metadata and registration_policy Claims of a Subordinate Statement issued by a Federation Registration Entity for a Client.

8. Normative References

• [BAS.Rules] The Swedish Agency for Digital Government (Digg), federation rules for Federationskontext BAS, in preparation.
• [BAS.Security] The Swedish Agency for Digital Government (Digg), "Federationskontext BAS: Security Requirements 1.0, draft 01", October 2026.
• [Ena.OAuth2] "Ena OAuth 2.0 Interoperability Profile", Version 1.0, draft 01, 16 October 2025, https://ena-infrastructure.github.io/specifications/ena-oauth2-profile.html.
• [ISO.6523] "ISO/IEC 6523-1:2023. Part 1: Identification of organization identification schemes", 2023, https://www.iso.org/standard/82246.html.
• [OIDC.Sweden.Federation] Lindström, M. and S. Santesson, "Swedish OpenID Federation Deployment and Interoperability Profile 1.0, draft 03", 2 October 2026, 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", 9 January 2026, 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", 23 February 2026, https://www.oidc.se/specifications/openid-federation-organization-identifier-1_0.html.
• [OpenID.Federation] Hedberg, R., Jones, M. B., Ed., De Marco, G., Solberg, A. Å., Bradley, J., and V. Dzhuvinov, "OpenID Federation 1.1", 5 May 2026, https://openid.net/specs/openid-federation-1_1.html.
• [OpenID.Federation.Connect] Hedberg, R., Jones, M. B., Ed., De Marco, G., Solberg, A. Å., Bradley, J., and V. Dzhuvinov, "OpenID Federation for OpenID Connect 1.1", 5 May 2026, https://openid.net/specs/openid-federation-connect-1_1.html.
• [OpenID.Federation.RegPolicy] Lindström, M. and S. Santesson, "OpenID Federation Registration Policy 1.0, draft 01", 30 March 2026.
• [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
• [RFC7591] Richer, J., Ed., Jones, M., Bradley, J., Machulak, M., and P. Hunt, "OAuth 2.0 Dynamic Client Registration Protocol", RFC 7591, July 2015.
• [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, May 2017.
• [RFC8414] Jones, M., Sakimura, N., and J. Bradley, "OAuth 2.0 Authorization Server Metadata", RFC 8414, June 2018.
• [RFC8705] Campbell, B., Bradley, J., Sakimura, N., and T. Lodderstedt, "OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens", RFC 8705, February 2020.
• [RFC9449] Fett, D., Campbell, B., Bradley, J., Lodderstedt, T., Jones, M., and D. Waite, "OAuth 2.0 Demonstrating Proof of Possession (DPoP)", RFC 9449, September 2023.
• [RFC9728] Jones, M. B., Hunt, P., and A. Parecki, "OAuth 2.0 Protected Resource Metadata", RFC 9728, April 2025.
• [SIB.Connection] The Swedish Agency for Digital Government (Digg), "Anslutning – Tillämpningskrav och vägledning", version 12, 29 September 2026.
• [SIB.Registration] The Swedish Agency for Digital Government (Digg), "Registrering – Tillämpningskrav och vägledning", version 13, 29 September 2026.

9. 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, 23 July 2026, https://datatracker.ietf.org/doc/html/draft-ietf-spice-glue-id-10.
• [OpenID.Registration] Sakimura, N., Bradley, J., and M. Jones, "OpenID Connect Dynamic Client Registration 1.0 incorporating errata set 2", 15 December 2023, https://openid.net/specs/openid-connect-registration-1_0.html.
• [SKV709] Skatteverket, "SKV 709, Utgåva 8, Organisationsnummer", 2006, https://docs.swedenconnect.se/technical-framework/mirror/skv/skv709-8.pdf.