The Swedish OpenID Connect Profile

Version: 1.0 - 2023-12-11

Abstract

This specification defines a profile for OpenID Connect for use within the Swedish public and private sectors. It profiles the OpenID Connect protocol to get a baseline security and to facilitate interoperability between relying parties and OpenID providers.

Introduction

1.1. Requirements Notation and Conventions

1.2. Conformance
Authentication Requests and Responses

2.1. Authentication Request Parameters

2.1.1. The scope Parameter

2.1.2. The state Parameter

2.1.3. The redirect_uri Parameter

2.1.4. The prompt Parameter

2.1.5. The login_hint Parameter

2.1.6. The claims Parameter

2.1.7. Request Objects (request and request_uri parameters)

2.1.8. PKCE Parameters

2.2. Processing of Authentication Requests

2.3. Authentication Responses
Token Endpoint Requests and ID Token Issuance

3.1. Token Requests

3.1.1. Client Authentication

3.2. Token Responses and Validation

3.2.1. ID Token Contents

3.2.2. ID Token Validation
Claims and Scopes

4.1. UserInfo Endpoint

4.2. Claims Release Requirements
Discovery

5.1. Discovery Requirements for a Relying Party

5.2. Discovery Requirements for an OpenID Provider
Client Registration
Security Requirements

7.1. Cryptographic Algorithms

7.2. Signing Requirements
Normative References

1. Introduction

This specification defines a profile for OpenID Connect for use within the Swedish public and private sector. It profiles the OpenID Connect protocol to get a baseline security and to facilitate interoperability between relying parties and OpenID providers.

The profile is loosely based on the International Government Assurance Profile for OpenID Connect draft.

1.1. Requirements Notation and Conventions

The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” are to be interpreted as described in [RFC2119].

These keywords are capitalized when used to unambiguously specify requirements over protocol features and behavior that affect the interoperability and security of implementations. When these words are not capitalized, they are meant in their natural-language sense.

1.2. Conformance

This profile defines requirements for OpenID Connect Relying Parties (clients) and OpenID Providers (identity providers). Furthermore, it defines the interaction between a Relying Party and an OpenID Provider.

When a component compliant with this profile is interacting with other components compliant with this profile, all components MUST fully conform to the features and requirements of this specification. Any interaction with components that are not compliant with this profile is out of scope for this specification.

2. Authentication Requests and Responses

An OpenID Connect authentication request is a request sent to the Authorization endpoint of an OpenID Provider. These requests MUST be sent using the authorization code flow.

This chapter defines requirements for Relying Parties issuing requests and OpenID Providers processing requests that MUST be followed in order to be compliant with this profile.

2.1. Authentication Request Parameters

Section 3.1.2.1 of [OpenID.Core] defines a set of request parameters for OpenID Connect.

The table below lists request parameters that are mandatory according to this profile, along with selected optional parameters for which this profile extends the requirements or descriptions given in [OpenID.Core].

In the table below the "Support Requirement" column indicates whether a parameter is required or optional for a Relying Party to include in a request, and required or optional for an OP to support and process.

Parameter	Description	Support Requirement
`client_id`	The client identifier valid at the OpenID Provider/Authorization Server.	REQUIRED
`response_type`	The response type. MUST be set to `code`.	REQUIRED
`scope`	Indicates the scopes requested. See 2.1.1 below.	REQUIRED
`state`	Random string generated by the Relying Party. The state is used to protect against CSRF attacks. This value is returned to the Relying Party in the authentication response. See 2.1.2 below.	REQUIRED
`redirect_uri`	The endpoint where the Relying Party will receive the authentication response. See 2.1.3 below.	REQUIRED
`nonce`	String value used to associate a client session with an ID Token, and to mitigate replay attacks. The value is a (unguessable) random string generated by the Relying Party. The nonce value is returned to the Relying Party in the ID Token.	OPTIONAL for RP REQUIRED for OP
`prompt`	Space delimited, case sensitive list of string values that specifies whether the OpenID Provider prompts the end-user for re-authentication and consent. See 2.1.4 below.	OPTIONAL for RP REQUIRED for OP
`login_hint`	Hint to the OpenID Provider about an identifier of the end-user. See 2.1.5 below.	OPTIONAL
`claims`	Parameter for requesting individual claims and specifying parameters that apply to the requested claims. See 2.1.6 below.	OPTIONAL for RP REQUIRED for OP
`acr_values`	Requested Authentication Context Class Reference (`acr`) values. According to section 3.1.2.1 of [OpenID.Core] the `acr` claim is requested as a voluntary claim by this parameter. A Relying Party wishing to request the `acr` claim as an essential claim should request the `acr` claim using the `claims` parameter and set it as "essential". See section 2.1.6 below and section 5.5.1.1 of [OpenID.Core].	Optional for RP Mandatory for OP
`request`	Request Object JWT. See 2.1.7.	OPTIONAL for RP REQUIRED for OP
`request_uri`	Request Object JWT passed by reference. See 2.1.7.	OPTIONAL
`code_challenge`, `code_challenge_method`	Proof Key for Code Exchange (PKCE). See 2.1.8 below.	See 2.1.8 for RP REQUIRED for OP

2.1.1. The scope Parameter

The scope parameter value MUST contain openid and MAY contain additional scopes controlling required claims.

See section 4, Claims and Scopes, for further requirements concerning scope processing.

2.1.2. The state Parameter

Relying Parties MUST use an unguessable random value for the state parameter, where the value has at least 128 bits of entropy.

Relying Parties MUST validate the value of the state parameter upon return to the redirect URI and MUST ensure that the value is tied to the current session of the user.

An OpenID Provider MUST include the value of the state parameter in the authentication response.

2.1.3. The redirect_uri Parameter

An OpenID Relying Party MUST include the complete redirect URI as a redirect_uri parameter value.

In order to prevent open redirection and other injection attacks, the OpenID Provider MUST match the entire URI using a direct string comparison against registered values and MUST reject requests with an invalid or missing redirect URI.

2.1.4. The prompt Parameter

A Relying Party MAY use the prompt parameter to control, or prevent, Single Sign On.

By setting the prompt parameter to none the Relying Party instructs the OpenID Provider that no display of any authentication or consent views is allowed, and that an error should be returned if the user is not already authenticated at the OpenID Provider. This corresponds to the SAML authentication request attribute IsPassive=true.

By setting the prompt parameter to login the Relying Party instructs the OpenID Provider that the user MUST authenticate, and that it MUST NOT use a previous authentication session for the end-user. This corresponds to the SAML authentication request attribute ForceAuthn=true.

An OpenID Provider MUST support the prompt parameter according to the requirements in section 3.1.2.1 of [OpenID.Core], with the following extension: If the value of the prompt parameter contains the "login" string value the OpenID Provider MUST prompt the end-user for (re-)authentication.

2.1.5. The login_hint Parameter

Section 3.1.2.1 of [OpenID.Core] states that a Relying Party MAY include the login_hint parameter in an authentication request, and that its value is a string that can help the OpenID Provider to select the end-user to authenticate.

This profile does not define which type of string that is passed as a value to the login_hint parameter. It is context- and OpenID Provider specific.

However, a Relying Party MUST NOT use the login_hint to pass a claim value that it requests to be delivered in the resulting ID Token. In these cases the claims request parameter SHOULD be used, see 2.1.6 below.

2.1.6. The claims Parameter

Section 5.5 of [OpenID.Core] specifies how individual claims can be requested using the claims request parameter.

An OpenID Provider compliant with this profile MUST support the claims parameter, both when passed as an OAuth parameter and when included in a Request Object (see 2.1.7).

Section 2.1.5 states that the claims parameter is to be used in favour of the login_hint parameter when the Relying Party needs to pass a value that it wants to be delivered as a claim in the resulting ID Token.

The example below illustrates the contents of the claims parameter where the Relying Party specifies a value for a specific claim. By doing this instead of specifying the value as a login_hint, the RP gives the OpenID Provider a more exact view of the user being authenticated.

{
  "id_token" : {
    "email" : { 
      "essential" : true, 
      "value" : "user@example.com" 
    }
  }
}

A Relying Party that has a strict requirement for deliverance of the acr claim in the ID Token has the possibility to include the acr claim in the claims parameter and specify it as "essential". Furthermore, if the RP wants to specify which Authentication Context Class Reference values that are acceptable, the values parameter could be included and list these values. See section 5.5.1.1 of [OpenID.Core].

{
  "id_token" : {
    "acr": { "essential": true,
             "values": [ "https://acr.example.com/1", "https://acr.example.com/2" ] }
  }
  ...
}

A Relying Party specifying the acr claim in the claims parameter SHOULD NOT include the acr_values parameter in the request.

2.1.7. Request Objects (request and request_uri parameters)

An OpenID Provider compliant with this profile MUST support Request Object JWT:s sent by value (using the request parameter) and MAY support Request Object JWT:s sent by reference (using the request_uri parameter).

An OpenID Provider MUST be prepared to accept and process signed and/or encrypted Request Objects.

A Relying Party that signs a Request Object MUST do so using is registered key, and a Relying Party that encrypts a Request Object MUST do so using the OpenID Provider's public key.

If a Request Object is signed it MUST contain the iss (issuer) and aud (audience) claims.

The iss value MUST be the client ID of the Relying Party (unless it was signed by a different party than the RP).

The aud value SHOULD be set to the OpenID Provider's Issuer Identifier URL. [OpenID.Core] also allows for this value to be an URL including the OP Issuer Identifier URL. In practice this means that the OP Authorization Endpoint URL may be used. Therefore, an OpenID Provider compliant with this profile MUST accept aud values that are either the OP Issuer Identifier URL or the Authorization Endpoint on which an authentication request was received.

A Relying Party sending an authentication request containing a Request Object SHOULD use the POST method to do so. Since the contents of the request parameter is signed the payload may become too large for using GET.

See chapter 6 of [OpenID.Core] for further details.

2.1.8. PKCE Parameters

Regular Relying Parties (i.e., not Public Clients) SHOULD use the Proof Key for Code Exchange (PKCE) extension, [RFC7636] and include the code_challenge and code_challenge_method parameters.

A "Public Client", i.e., a browser-based web application or a native mobile app with no backend logic, MUST use PKCE and include the code_challenge and code_challenge_method parameters in the authentication request.

When PKCE is used, the code challenge method S256 SHOULD be used.

An OpenID Provider compliant with this profile MUST support the PKCE extension including support for the S256 code challenge method.

An OpenID Provider MUST NOT allow a Relying Party to use the plain code challenge method.

2.2. Processing of Authentication Requests

An OpenID Provider compliant with this profile MUST follow the requirements stated in section 3.1.2.2 of [OpenID.Core] and the requirements put in section 2.1 of this profile.

Furthermore, the OpenID Provider MUST NOT proceed with the authentication if the request contains a claims parameter including essential acr values and none of the specified Requested Authentication Context Class Reference values can be used to authenticate the end-user. In these cases the provider SHOULD respond with an unmet_authentication_requirements error as defined in [OpenID.Unmet-AuthnReq]. See section 5.5.1.1 of [OpenID.Core].

2.3. Authentication Responses

Entities compliant with this profile MUST follow the requirements regarding authentication error responses put in section 3.1.2.6 of [OpenID.Core].

OpenID Providers SHOULD limit the use of error codes to the sets defined in:

Section 4.1.2.1 of [OAuth2.RFC6749],
section 3.1.2.6 of [OpenID.Core], and,
[OpenID.Unmet-AuthnReq].

All error codes defined in the OpenID Connect and OAuth2 specifications except for access_denied represent error conditions that are caused by either an invalid request or conditions/requirements that can not be met, where access_denied represents that the authentication process was not completed.

A non-completed authentication process may be caused by:

the user denies, or cancels, the authentication process, or,
the user agrees to authenticate, but the authentication operation fails.

In the latter case the OpenID Provider MUST inform the user about the error that occurred before responding with an error response.

In both above scenarios the error_description-field of the error response SHOULD be set and contain a description suitable for the Relying Party application logs.

3. Token Endpoint Requests and ID Token Issuance

This chapter declares requirements that extend, or clarify, the requirements for ID Tokens in section 3.1.3 of [OpenID.Core].

3.1. Token Requests

A Token Request MUST be sent in accordance with section 3.1.3.1 of [OpenID.Core] meaning that the grant_type is set to authorization_code and code carries the value of the code parameter returned in the authentication (authorization) response.

If PKCE parameters were sent in the authentication request, see section 2.1.8 above, the Token Request MUST include the PKCE code_verifier parameter, and the OpenID Provider MUST process this parameter according to section 4.6 of [RFC7636].

For client authentication requirements, see 3.1.1 below.

3.1.1. Client Authentication

OpenID Providers compliant with this profile MUST support the private_key_jwt method for client authentication at the Token endpoint, and MAY support other methods if permitted by the context or policy under which the OP is functioning.

If Mutual TLS authentication is supported and used, the requirements stated in section 2 of [RFC8705] MUST be followed.

A Relying Party SHOULD default to use the private_key_jwt method, and in these cases the following claims MUST be included in the token request:

client_assertion_type - Set to urn:ietf:params:oauth:client-assertion-type:jwt-bearer
client_assertion - The value of the signed client authentication JWT generated. The Relying Party must generate a new assertion JWT for each call to the token endpoint.

Section 9 of [OpenID.Core] lists the required contents of the signed JWT. These requirements states that the aud claim value SHOULD be set to the URL of the OpenID Provider's Token endpoint. In order to facilitate interoperability it is RECOMMENDED that an OpenID Provider compliant with this profile also accepts its Issuer Identifier URL as a valid value for the aud claim.

3.2. Token Responses and Validation

The token response MUST include an access token (to be used to make UserInfo requests) and an ID Token as described below.

3.2.1. ID Token Contents

ID Tokens issued by OpenID Providers compliant with this profile MUST be signed and MAY be encrypted using the appropriate key of the requesting Relying Party.

Section 2 of [OpenID.Core] defines the contents of an ID Token. Below follows a listing of the token claims that are mandatory according to this profile along with selected optional claims for which this profile extends the requirements or descriptions given in [OpenID.Core].

Token Claim	Description	Requirement
`iss`	Issuer of the token.	REQUIRED
`sub`	Subject identifier. See 3.2.1.1 below.	REQUIRED
`aud`	Audience of the ID Token.	REQUIRED
`exp`	Expiration time. See 3.2.1.2 below.	REQUIRED
`iat`	Issuance time.	REQUIRED
`auth_time`	Time when the end-user authentication occurred. In the cases where an ID Token is issued based on a previous end-user authentication, this claim MUST hold the time from the original authentication.	REQUIRED
`nonce`	Nonce that must be matched against nonce provided in the authentication request.	OPTIONAL
`acr`	Authentication Context Class Reference. See 3.2.1.3 below.	REQUIRED if the `acr` claim was requested as an essential claim (see 2.1 above), otherwise OPTIONAL.

Except for the claims listed above the OpenID Provider also includes claims in the ID Token that depends on requested scopes and claims.

3.2.1.1. The sub Token Claim

Section 8 of [OpenID.Core] defines two Subject Identifier Types, public and pairwise. An OpenID Provider compliant with this profile MUST support the public type and SHOULD support the pairwise type.

In order to avoid privacy violations an OpenID Provider MUST NOT use an end-user attribute that reveals personal information about the end-user as the value for sub, for example a personal identity number. Even though this information may be available in other token claims, its release should be dependent on requested scopes (or claims) and not be revealed unless explicitly requested (and in some cases consented).

3.2.1.2. The exp Token Claim

The lifetime of an ID Token should be kept as short as possible, and MUST NOT exceed 5 minutes. Shorter times are RECOMMENDED when possible.

3.2.1.3. The acr Claim

An OpenID Provider compliant with this profile MUST adhere to section 5.5.1.1 of [OpenID.Core] regarding issuance of the acr claim.

3.2.2. ID Token Validation

Relying Parties MUST follow the requirements in section 3.1.3.7 of [OpenID.Core].

4. Claims and Scopes

4.1. UserInfo Endpoint

An OpenID Provider compliant with this profile MUST support releasing claims from the UserInfo endpoint and MUST follow the requirements from section 5.3 of [OpenID.Core].

Access to the UserInfo endpoint MUST be denied if a valid access token is not presented.

Responses from the UserInfo endpoint MUST be signed.

See section 4.2 below for claims release requirements via the UserInfo endpoint.

Relying Parties MUST follow section 5.3.4 of [OpenID.Core] when validating a UserInfo response message.

4.2. Claims Release Requirements

OpenID Providers MUST return claims on a best effort basis. However, an OpenID Provider asserting it can provide a user claim does not imply that this data is available for all its users. Relying Parties MUST be prepared to receive partial data.

An OpenID Provider MUST NOT release any claim to a Relying Party that it has not been authorized to receive. How this authorization is handled and managed is out of scope for this profile.

An OpenID Provider compliant with this profile MUST NOT release any identity claims in the ID Token, or via the UserInfo endpoint, if they have not been explicitly requested via scope and/or claims request parameters, or indirectly by a policy known, and accepted, by the involved parties.

The above requirement does not include the mandatory sub claim, and claims that do not reveal identity information about the user, for example, transaction identifiers or claims holding information about the authentication process.

An OpenID Provider compliant with this profile MUST adhere to the following rules for release of identity claims belonging to the subject:

If a claims request parameter is included in the authentication request, the claims contained in this parameter are delivered according to their indicated destination (id_token or userinfo).
If a scope request parameter value is included in the authentication request, and this scope definition has specific claims delivery requirements (i.e., whether the claims belonging to the scope should be delivered in ID Token or via the UserInfo endpoint), the claims are delivered according to these scope requirements.
If none of the above rules apply, claims are delivered via the UserInfo endpoint, as specified by [OpenID.Core].

In cases where a claim is delivered in the ID Token due to a specific claims parameter request, and this claim is part of a standard or custom scope that states delivery via the UserInfo endpoint (which is the default), the claim MUST also be delivered via the UserInfo endpoint (if the scope in question is requested).

5. Discovery

5.1. Discovery Requirements for a Relying Party

Relying Parties SHOULD cache OpenID Provider metadata after a provider has been discovered and used by the Relying Party.

5.2. Discovery Requirements for an OpenID Provider

OpenID Providers compliant with this profile MUST support the OpenID Connect Discovery standard, [OpenID.Discovery] and adhere to the requirements defined in this chapter.

Access to the Discovery document MAY be protected with existing web authentication methods if required by the OpenID Provider. Further requirements about access management of the Discovery document is outside of the scope for this specification.

The endpoints described in the Discovery document MUST be secured in accordance with this profile.

All OpenID Providers are uniquely identified by a URL known as the issuer. This URL serves as the prefix of a service discovery endpoint as specified in [OpenID.Discovery].

An OpenID Provider compliant with this profile MUST present a discovery document including the required fields specified in section 3 of [OpenID.Discovery] and meet the requirements in the table below:

Field	Description	Requirement
`token_endpoint`	Fully qualified URL of the OpenID Provider's OAuth 2.0 Token Endpoint.	REQUIRED
`userinfo_endpoint`	Fully qualified URL of the OpenID Provider's UserInfo Endpoint.	REQUIRED
`jwks_uri`	URL of the OP's JSON Web Key Set [JWK] document. To facilitate a smooth key rollover, each JWK of the referenced document SHOULD include a `kid` parameter. See section 4.5 of [RFC7517].	REQUIRED
`scopes_supported`	JSON array containing a list of the scope values that this provider supports. MUST contain the `openid` value.	REQUIRED
`response_types_supported`	JSON array containing a list of the OAuth 2.0 `response_type` values that the OpenID Provider supports. MUST contain the `code` type.	REQUIRED
`acr_values_supported`	JSON array containing a list of the Authentication Context Class References that the OpenID Provider supports.	REQUIRED
`subject_types_supported`	JSON array containing a list of the Subject Identifier types that the OpenID Provider supports. MUST contain `public` and SHOULD contain `pairwise`	REQUIRED
`token_endpoint_auth_` `methods_supported`	JSON array containing a list of client authentication methods supported by at the Token endpoint. MUST contain `private_key_jwt` and MAY contain other authentication methods as specified in section 9 of [OpenID.Core] or [RFC8705] for Mutual TLS.	REQUIRED
`token_endpoint_auth_` `signing_alg_values_supported`	JSON array containing a list of JWS signing algorithms supported by the Token Endpoint for the signature on the JWT used to authenticate the client at the Token Endpoint for the `private_key_jwt`. `RS256` and `ES256` MUST appear, and `none` MUST NOT appear. See section 7.1 below.	REQUIRED
`claims_supported`	JSON array containing a list of the claim names of the claims that the OpenID Provider MAY be able to supply values for.	REQUIRED
`claims_parameter_supported`	Boolean value specifying whether the OpenID Provider supports use of the `claims` request parameter. Since this profile requires support the value MUST be set to `true`.	REQUIRED
`request_parameter_supported`	Boolean value specifying whether the OpenID Provider supports use of the `request` parameter for Request Objects. Since this profile requires support the value MUST be set to `true`.	REQUIRED
`code_challenge_methods_supported`	JSON array containing a list of PKCE code challenge methods supported by this OP. The array MUST include the `S256` method and MUST NOT include the `plain` method. The `code_challenge_methods_supported` parameter is defined in section 2 of [RFC8414].	REQUIRED

Any other fields specified in [OpenID.Discovery] not appearing in the table above MAY also be used.

6. Client Registration

Section 2 of [OpenID.Registration] defines a listing of the client metadata used for Client Registration at the OpenID Provider. This chapter adds extra requirements and clarifications for use according to this profile.

The profile does not mandate OpenID Provider support for Dynamic registration of Relying Parties (clients). However, an OpenID Provider compliant with this profile MUST still be able to handle the client registration parameters specified in this section and in section 2 of [OpenID.Registration]. This means that if an OpenID Provider registers Relying Parties by other means, it MUST gather and maintain all required client information parameters in the following table.

Parameter	Description	Requirement
`redirect_uris`	Array of redirection URI values used by the Relying Party.	REQUIRED
`response_types`	The response types that the Relying Party uses. Must be set to `code`.	REQUIRED
`grant_types`	The OAuth2 grant types the Relying Party uses. Must be set to `authorization_code`.	REQUIRED
`jwks` `jwks_uri`	The Relying Party's JSON Web Key Set [JWK] document, passed by value or reference (URI). To facilitate a smooth key rollover, each JWK of the referenced document SHOULD include a `kid` parameter. See section 4.5 of [RFC7517].	At least one of `jwks` or `jwks_uri` is REQUIRED. Except for those clients that authenticate according to the exceptions described in section 3.1.1.
`subject_type`	Subject type requested for responses to this Client. The `subject_types_supported` discovery parameter contains a list of the supported `subject_type` values for this server. Valid types include `pairwise` and `public`. The default SHOULD be `public`. See section 3.2.1.1.	OPTIONAL
`token_endpoint_auth_method`	Authentication method for accessing the Token endpoint. See section 3.1.1.	REQUIRED
`default_acr_values`	Default requested Authentication Context Class Reference values.	OPTIONAL

7. Security Requirements

All transactions MUST be protected in transit by TLS as described in [NIST.800-52.Rev2].

All parties MUST conform to applicable recommendations in section 16, "Security Considerations" of [OAuth2.RFC6749] and those found in "OAuth 2.0 Threat Model and Security Considerations", [RFC6819].

7.1. Cryptographic Algorithms

This section lists the requirements for cryptographic algorithm support for being compliant with this profile.

All entities compliant with this profile MUST follow the guidelines in [NIST.800-131A.Rev2] regarding use of algorithms and key lengths¹. Specifically, for signature and encryption keys the following requirements apply:

RSA public keys MUST be at least 2048 bits in length.
EC public keys MUST be at least 256 bits in length (signature only). The curve NIST Curve P-256 MUST be supported ([RFC5480]), and NIST Curve P-384 and NIST Curve P-521 SHOULD be supported.

Entities conforming to this profile MUST support algorithms according to "JSON Web Algorithms (JWA)", [RFC7518], with the following additions:

RS256, RSASSA-PKCS1-v1_5 using SHA-256, is listed as recommended in [RFC7518], but is REQUIRED to support by this profile.
RS384, RSASSA-PKCS1-v1_5 using SHA-384, is listed as optional in [RFC7518], but is RECOMMENDED to support by this profile.
RS512, RSASSA-PKCS1-v1_5 using SHA-512, is listed as optional in [RFC7518], but is RECOMMENDED to support by this profile.
ES256, ECDSA using P-256 and SHA-256, is listed as recommended in [RFC7518], but is REQUIRED to support by this profile.
ES384, ECDSA using P-384 and SHA-384, is listed as optional in [RFC7518], but is RECOMMENDED to support by this profile.
ES512, ECDSA using P-521 and SHA-512, is listed as optional in [RFC7518], but is RECOMMENDED to support by this profile.
RSA-OAEP, RSAES OAEP using default parameters, is listed as recommended in [RFC7518], but is REQUIRED to support by this profile.
A128GCM and A256GCM, AES GCM using 128/256-bit key, are listed as recommended in [RFC7518], but are REQUIRED by this profile.

The sender of a secure message MUST NOT use an algorithm that is not set as REQUIRED in [RFC7518] or in the listing above, unless it is explicitly declared by the peer in its metadata (Discovery document or Client Registration metadata).

[1]: [NIST.800-131A.Rev2] contains a listing of algorithms that must not be used. However, there is a need to explicitly point out that the commonly used algorithm SHA-1 for digests is considered broken and MUST NOT be used or accepted.

7.2. Signing Requirements

Entities compliant with this profile MUST follow the requirements from section section 10.1 of [OpenID.Core]. This section states the following:

If there are multiple keys in the referenced JWK Set document, a kid value MUST be provided in the JOSE Header.

In order to facilitate for rotation/update of asymmetric keys and to enable for the receiving entity to dynamically update the sender's JWK Set document entities compliant with this profile SHOULD include the kid value also in the cases where its jwks only contains one (signing) key.

8. Normative References

[RFC2119]

Bradner, S., Key words for use in RFCs to Indicate Requirement Levels, March 1997.

[OAuth2.RFC6749]

Hardt, D., "The OAuth 2.0 Authorization Framework", RFC 6749, DOI 10.17487/RFC6749, October 2012.

[OpenID.Core]

Sakimura, N., Bradley, J., Jones, M., de Medeiros, B. and C. Mortimore, "OpenID Connect Core 1.0", August 2015.

[OpenID.Unmet-AuthnReq]

T. Lodderstedt, "OpenID Connect Core Error Code unmet_authentication_requirements".

[OpenID.Discovery]

Sakimura, N., Bradley, J., Jones, M. and E. Jay, "OpenID Connect Discovery 1.0", August 2015.

[OpenID.Registration]

Sakimura, N., Bradley, J., and M. Jones, “OpenID Connect Dynamic Client Registration 1.0,” November 2014.

[RFC7515]

Jones, M., Bradley, J., and N. Sakimura, “JSON Web Signature (JWS)”, May 2015.

[RFC7517]

Jones, M., "JSON Web Key (JWK)", May 2015.

[RFC7518]

Jones, M., "JSON Web Algorithms (JWA)", May 2015.

[RFC7519]

Jones, M., Bradley, J. and N. Sakimura, "JSON Web Token (JWT)", May 2015.

[RFC8705]

B. Campbell, J. Bradley, N. Sakimura, T. Lodderstedt, "OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens", February 2020.

[RFC8414]

Jones, M., Bradley, J., and N. Sakimura, "OAuth 2.0 Authorization Server Metadata", June 2018.

[RFC6819]

Lodderstedt, T., McGloin, M. and P. Hunt, "OAuth 2.0 Threat Model and Security Considerations", RFC 6819, January 2013.

[RFC7636]

Sakimura, N., Bradley, J. and N. Agarwal, "Proof Key for Code Exchange by OAuth Public Clients", RFC 7636, DOI 10.17487/RFC7636, September 2015.

[RFC5480]

IETF RFC 5480, Elliptic Curve Cryptography Subject Public Key Information, March 2009.

[NIST.800-52.Rev2]

NIST Special Publication 800-52, Revision 2, "Guidelines for the Selection, Configuration, and Use of Transport Layer Security (TLS) Implementations".