OpenID NLGov 1.0.1

Web applications are applications that run on a web server and are consumed through the user-agent ("browser") by the End-User. Web applications are capable of securely authenticating themselves and of maintaining the confidentiality of secrets (e.g. Client credentials and tokens) and are therefore considered confidential Clients (OAuth 2.0 [RFC6749], Section 2.1).

Browser-based applications are applications that are dynamically downloaded and executed in a web browser that are also sometimes referred to as user-agent-based applications or single-page applications. Browser-based applications are considered to be not capable of maintaining the confidentiality of secrets, as they may be vulnerable to several types of attacks, including Cross-Site Scripting (XSS), Cross Site Request Forgery (CSRF) and OAuth token theft. Browser-based applications are considered public Clients (OAuth 2.0 [RFC6749], Section 2.1).

• Browser-based applications SHOULD follow the best practices specified in [OAuth2.Browser-Based-Apps].

Native applications are applications installed and executed on the device used by the End-User (i.e. desktop applications, native mobile applications). Native applications can sufficiently protect dynamically issued secrets, but are not capable of maintaining the confidentiality of secrets that are statically included as part of an app distribution. Therefore, Native applications are considered public Clients, except when they are provisioned per-instance secrets via mechanisms like Dynamic Client Registration (OAuth 2.0 [RFC6749], Section 2.1).

Hybrid applications are applications implemented using web-based technology but distributed as a native app; these are considered equivalent to native applications for the purpose of this profile.

• Native applications MUST follow the best practices as specified in OAuth 2.0 for Native Apps [RFC8252].
• The use of confidential Native applications (which are provisioned per-instance secrets) is RECOMMENDED over public Native applications, as confidential Clients provide better means to perform secure Client Authentication.
• Native applications MUST use an external user-agent or "in-app browser tab" to make authorization requests; an "embedded user-agent" or "web-view" components MUST NOT be used for this purpose. See 'OAuth 2.0 for Native apps' [RFC8252] for more information on the "in-app browser tab" feature and support on various platforms.

The following describes the supported OpenID Connect Authorization Code Flow parameters for use with a NL Gov compatible OpenID Provider. Some of these requirements are inherited as specified in Section 2.1.1 of [OAuth2.NLGov].

Request Parameters:

client_id

• REQUIRED. Valid OAuth 2.0 Client Identifier. MUST have the value as obtained during registration. Identical as in [OAuth2.NLGov].

response_type

• REQUIRED. MUST have value code for the Authorization Code Flow. Identical as in [OAuth2.NLGov].

scope

• REQUIRED. Indicates the access privileges being requested. MUST contain at least the value openid and SHOULD contain a specific scope for which access is requested.

redirect_uri

• REQUIRED. Indicates a valid endpoint where the Client will receive the authentication response. MUST be an absolute HTTPS URL unless the Client is a native application operating on a desktop device. In case of a native application on a desktop, this MAY be an absolute HTTP URL with the literal loopback IP address and port number the Client is listening on as hostname. MUST NOT use localhost for loopback addresses, see [RFC8252] Sections 7.3 and 8.3. MUST exactly match one of the Redirection URI values for the Client pre-registered at the OpenID Provider, except for the port URI component on loopback addresses for native applications on desktops. Inter-app redirect URIs for Native applications on mobile devices MUST use Claimed https Scheme URI Redirection, as specified in Section 7.2 of [RFC8252].

state

• REQUIRED. Unguessable random string generated by the Client, used to protect against Cross-Site Request Forgery (CSRF, XSRF) attacks. Must contain at least 128 bits of cryptographic random to avoid guessing. Returned to the Client in the Authentication Response. Identical as in [OAuth2.NLGov].

nonce

• REQUIRED. Unguessable random string generated by the Client, used to associate a Client session with an ID Token and to protect against replay attacks. Must contain at least 128 bits of cryptographic random to avoid guessing. Returned to the Client in the ID Token. See also [OpenID.Core], Section 15.5.2 for implementation notes.

acr_values

• OPTIONAL. Lists the acceptable LoAs for this authentication. Under this profile, acr_values takes precedence over vtr. See also Section 5.2.3. Identical as in [OpenID.Core].

vtr

• OPTIONAL. MUST be set to a value as described in Section 6.1 of Vectors of Trust [RFC8485]. MUST NOT be used when acr_values is set or when the acr Claim is requested via the claims parameter. See also Section 5.2.4.

claims

• OPTIONAL. This parameter is used to request specific Claims. The value is a JSON object listing the requested Claims, as specified in section 5.5 of [OpenID.Core].

code_challenge

• REQUIRED. Code challenge as in PKCE [RFC7636].

code_challenge_method

• REQUIRED. MUST use the value of S256.

Clients MAY optionally send requests to the Authorization Endpoint using the request or request_uri parameter as defined by OpenID Connect [OpenID.Core], section 6. Passing a Request Object by reference using the request_uri is preferred because of browser limits and network latency.

Request Objects MUST be signed by the Client's registered key. Request Objects MAY be encrypted to the OpenID Provider's public key. When sending Request Objects by reference, Clients MUST pre-register request_uri values with the OpenID Provider at registration and MUST only use pre-registered values for request_uri.

All Clients MUST validate the following in received Authentication Responses:

state

• The state response parameter MUST be present and MUST equal the state request parameter sent in the Authentication Request.

This in line with OpenID Connect Core ([OpenID.Core], Section 3.1.2.7), which equals to OAuth 2.0 ([RFC6749], Section 4.1.2 and 10.12). Verifying the state returned in the Authorization Response is part of CSRF mitigation measures and will help prevent attacks with late or stale responses, among others.

Confidential Clients, as defined in Section 4.1, MUST authenticate to the OpenID Provider using either:

• a JWT assertion as defined by the 'JWT Profile for OAuth 2.0 Client Authentication and Authorization Grants' [RFC7523] using only the private_key_jwt method defined in [OpenID.Core]; or
• mutually authenticated TLS, as specified in [RFC8705]. In case of a mutual TLS connection (mTLS) between the Client and the server, the JWT assertion SHOULD be omitted and the client_id parameter MUST be included.

Public Clients MAY authenticate to the OpenID Provider. However, the OpenID Provider MUST NOT rely on public Client Authentication for the purpose of identifying the Client.

Clients MUST NOT use more than one authentication method in each request.

The following describes the supported parameters for the Token Request. Some of these requirements are inherited as specified in Section 2.3.1 of [OAuth2.NLGov].

The following parameters are specified:

grant_type

• REQUIRED. MUST contain the value authorization_code. Identical as in [OAuth2.NLGov].

code

• REQUIRED. The value of the code parameter returned in the Authorization Response. Clients MUST NOT use the same authorization code more than once. Identical as in [OAuth2.NLGov].

client_assertion

• REQUIRED, in case private_key_jwt is used for Client Authentication. The value of the signed Client Authentication JWT generated as described in [OAuth2.NLGov]. The OpenID Client MUST generate a new assertion JWT for each call to the Token Endpoint.

client_assertion_type

• REQUIRED, in case client_assertion is present. MUST be set to urn:ietf:params:oauth:client-assertion-type:jwt-bearer.

client_id

• REQUIRED, in case mutually authenticated TLS is used for Client Authentication.

code_verifier

• REQUIRED. Code verifier as in PKCE [RFC7636].

All Clients MUST validate the following in received Token Responses:

• Follow the Token Response validation rules in [RFC6749], Sections 5.1 and 10.12.
• Validate the Access Token according to [OpenID.Core], Section 3.1.3.8.
• Validate the ID Token according to [OpenID.Core], Section 3.1.3.7, as well as the below mentioned requirements for validating the ID Token.

This in line with [OpenID.Core], Section 3.1.3.5.

All Clients MUST validate the signature of an ID Token before accepting it. Validation can be done using the public key of the issuing server, which is published in JSON Web Key (JWK) format. ID Tokens MAY be encrypted using the appropriate key of the requesting Client.

Clients MUST verify the following in received ID tokens:

iss

• The issuer Claim is the Uniform Resource Locater (URL) of the expected Issuer. Identical as in [OpenID.iGov].

aud

• The audience Claim contains the Client ID of the Client. Identical as in [OpenID.iGov].

nonce

• The nonce parameter in the ID Token MUST equal the nonce request parameter sent in the Authentication Request. This is in line with [OpenID.Core], Section 3.1.3.7.

exp, iat, nbf

• The expiration, issued at, and not before timestamps for the token are within acceptable ranges. These Claims are formatted as Unix Time Stamps (number of seconds since 1970-01-01T00:00:00Z UTC). Values for iat and nbf MUST lie in the past and exp MUST lie in the future; the acceptable range for how far away iat is in the past is specific to the Client. This is in line with [OpenID.iGov].

acr

• The Level of Assurance received in the acr Claim is at least the Level of Assurance requested. See also Section 5.2.3. This is in line with [OpenID.Core], Section 3.1.3.7.

represents

• The represents Claim, if applicable, identifies the represented service consumer on behalf of which the End-User intends to authenticate. Any Client MUST be able to process represents Claims. As an exception, represents Claims MAY be ignored by the Client if, and only if, it is explicitly agreed upon beforehand that no Representation will be provided.

OpenID Providers MUST accept requests containing a Request Object signed by the Client's private key. OpenID Providers MUST validate the signature on such requests against the Client's registered public key. OpenID Providers MUST accept Request Objects encrypted to the OpenID Provider's public key.

OpenID Providers SHOULD accept Request Objects by reference using the request_uri parameter. The Request Object can be either hosted by the Client or pushed to the OpenID Provider prior to the Authentication Request. OpenID Providers MUST verify that the request_uri parameter exactly matches one of the request_uri values for the Client pre-registered at the OpenID Provider, with the matching performed as described in Section 6.2.1 of [RFC3986] (Simple String Comparison).

Using Request Objects allows for Clients to create a request that is protected from tampering through the browser, allowing for a higher security and privacy mode of operation for Clients and applications that require it. Clients are not required to use Request Objects, but OpenID Providers are required to support requests using them.

Note that when a Request Object is used (either passed by value or by reference), the Client MAY send the parameters included in the Request Object duplicated in the query parameters as well for backwards compatibility (so that the request is a valid OAuth 2.0 Authorization Request). However, the OpenID Provider MUST only consider the parameters included in the Request Object and ignore the duplicated query parameters.

OpenID Providers MUST validate all incoming Token Requests according to [OpenID.Core], Section 3.1.3.2.

In addition, OpenID Providers MUST validate the code_verifier value against the code_challenge and code_challenge_method values specified by the Client in the Authorization Request according to [RFC7636], Section 4.6.

All ID Tokens MUST be signed by the OpenID Provider's private signature key. ID Tokens MAY be encrypted using the appropriate key of the requesting Client.

The ID Token MUST expire and SHOULD have an active lifetime no longer than five minutes. Since the ID Token is consumed by the Client and not presented to remote systems, it is RECOMMENDED that expiration times are kept as short as possible.

The Token Response includes an Access Token (which can be used to make a UserInfo request) and ID Token (a signed and optionally encrypted JSON Web Token). This profile imposes the following requirements on the Claims used in ID Tokens:

iss

• REQUIRED. The issuer field is the Uniform Resource Locator (URL) of the expected Issuer. Identical as in [OpenID.iGov].

aud

• REQUIRED. The audience field contains the Client ID of the Client. Identical as in [OpenID.iGov].

sub

• REQUIRED. The identifier of the authenticated End-User, also known as the subject. OpenID Providers MUST support a pairwise identifier in accordance with the OpenID Connect specification [OpenID.Core], section 8.1. See Pairwise Identifiers on when it may be useful to relax this requirement. Identical as in [OpenID.iGov].

sub_id_type

• OPTIONAL. The type of identifier passed in the sub Claim. In order to support multiple types of identifiers in an interoperable way, the type of identifier used for the identifier in the sub Claim SHOULD be explicitly included. The value of the sub_id_type MUST be a URI. Values supported by the OpenID Provider are provided via the Discovery endpoint.

acr

• OPTIONAL. The LoA the End-User was authenticated at. MUST be at least the requested Level of Assurance value requested by the Client (either via the acr_values or claims parameters) or - if none was requested - a Level of Assurance established through prior agreement. See also Section 5.2.3. As eIDAS is leading in most scenarios targeted by this profile, using the acr Claim to express the Level of Assurance is preferred over Vectors of Trust (vot).

nonce

• REQUIRED. MUST contain the nonce value that was provided in the Authentication Request. Identical as in [OpenID.iGov].

jti

• REQUIRED. A unique identifier for the token, which can be used to prevent reuse of the token. The value of jti MUST uniquely identify the ID Token between sender and receiver for at least 12 months.

auth_time

• REQUIRED if max_age was specified in the request or when auth_time was requested as an Essential Claim. Otherwise auth_time is OPTIONAL and SHOULD be included if the OpenID Provider can assert an End-User's authentication intent was demonstrated. For example, a login event where the End-User took some action to authenticate. See also Section 15.1 of [OpenID.Core].

exp, iat, nbf

• REQUIRED. The expiration, issued at, and not before timestamps indicate when the token expires, was issued and becomes valid, respectively. The expiration time for ID Tokens is specific to the OpenID Provider. In line with [OpenID.iGov].

represents

• REQUIRED in case Representation is applicable, the represents Claim provides information about the effective authorization due to a Representation Relationship for the End-User.

alt_sub

• OPTIONAL. Describes alternative Subject Identifiers for the authenticated End-User in the context of a specific audience. The value of alt_sub is an array of objects, each of which MUST contain sub and aud Claims to uniquely identify the authenticated End-User and the audience for the alternative Subject Identifier and SHOULD contain a sub_id_type Claim to explicitly indicate the type of identifier used in the sub claim if the OpenID Provider supports multiple types of subject identifiers.

vot

• OPTIONAL. The vector value as specified in Vectors of Trust. MUST NOT be included when acr is included. See also Section 5.2.4.

vtm

• REQUIRED if vot is provided. The trustmark URI as specified in Vectors of Trust. See also Section 5.2.4.

Other Claims MAY be included. See Claims Request below on how such Claims SHOULD be requested by the Client to be provided by the OpenID Provider.

Pairwise Subject Identifiers specified in OpenID Connect Core [OpenID.Core] Section 8 help protect an End-User's privacy by allowing an OpenID Provider to represent a single End-User with a different Subject Identifier (sub) for every Client the End-User connects to. This technique can help mitigate correlation of an End-User between multiple Clients and therewith tracking of End-Users between different sites and applications.

Use of pairwise identifiers does not prevent Clients from correlating data based on other identifying attributes such as names, phone numbers, email addresses, document numbers, or other attributes. However, since not all transactions require access to these attributes, but a Subject Identifier is always required, a pairwise identifier will aid in protecting the privacy of End-Users as they navigate the system.

OpenID Providers MUST support pairwise identifiers for cases where correlation of End-User's activities across Clients is not appropriate. OpenID Providers MAY support public identifiers for frameworks where public identifiers are required, or for cases where public identifiers are shared as attributes and the framework does not have a requirement for subject anonymity.

Burgerservicenummers (BSN), Rechtspersonen en Samenwerkingsverbanden Identificatienummers (RSIN) and Kamer van Koophandel (KvK) nummers are considered public sectoral identifiers and therefore MUST NOT be used as Subject Identifiers in case correlation of End-User's activities across Clients is not appropriate. In such cases, the use of Polymorphic Pseudonyms or Polymorphic Identities is preferred.

Note that BSNs MUST only be used by Relying Parties for Services eligible for using the BSN according to Dutch Law and that the BSN, or token containing it, SHOULD be encrypted.

In Use Cases that involve Representation Relationships, Representation Relationships are explicitly mentioned in the form of a represents Claim, analogous to the Delegation Semantics specified in [RFC8693].

Note: Whereas [RFC8693] lists the End-User in the act or may_act Claims and the represented service consumer in the sub Claim, this is reversed in this profile: the End-User is listed in the sub Claim and the represented service consumer is listed in the represents Claim. Reason for this is to mitigate the risk that a Client that does not explicitly supports the Representation Use Cases cannot recognize the difference between an End-User that authenticates on behalf of himself or on behalf of someone else via Representation.

As such, all Clients MUST process represents Claims used, in case Representation can be applicable in the context of the OpenID Client and OpenID Provider. As an exception, represents Claims MAY be ignored by the Client if, and only if, it is explicitly agreed upon beforehand that no Representation will be provided.

This profile specifies Representation Relations in ID Tokens as follows:

• The End-User is always identified by the sub Claim;
• The represented service consumer is mentioned in the represents Claim.
• In case a chain representation is applicable, the representation chain is represented as a series of nested represents Claims with the represented service consumer listed as the deepest nested represents Claim.
• Each represents Claim MUST contain sub and iss Claims to uniquely identify the represented party and SHOULD contain a sub_id_type Claim to explicitly indicate the type of identifier used in the sub claim if the OpenID Provider supports multiple types of subject identifiers.
• represents Claims MAY contain additional Claims (e.g. email) to provide additional useful information about the represented party.
• Claims within the represents Claim pertain only to the identity of that party and MUST NOT contain Claims that are not related to the represented party, such as top-level Claims exp, nbf, and aud.

Whereas the iGov Assurance Profile for OpenID Connect [OpenID.iGov] recommends the use of Vectors of Trust (vot) to determine the amount of trust to be placed in digital transactions, using Authentication Context Class References (acr) instead is RECOMMENDED by this profile, due to their better alignment to the Levels of Assurance (LoA) defined by the eIDAS standards that are used in the European Union.

OpenID Providers SHOULD use eIDAS Level of Assurance (LoA) values for the acr Claim, but MAY use different values if eIDAS is not applicable. The eIDAS Level of Assurance values are defined as URIs in [eIDAS.SAML], Section 3.2.

OpenID Providers MUST provide a Level of Assurance as acr value that is at least the requested Level of Assurance value requested by the Client (either via the acr_values or claims parameters) or - if none was requested - a Level of Assurance established through prior agreement.

OpenID Providers MUST NOT provide Authentication Methods References (amr), but MUST use Authentication Context Class References (acr) instead.

Clients MAY send an vtr (Vectors of Trust Request) parameter. If both the vtr and acr_values are in the request, the acr_values MUST take precedence and the vtr MUST be ignored.

Note: Risk Based Authentication (RBA) should be an integral part of the LoA framework that is used by an OpenID Provider (the Identity Provider), such that the risk criteria for the resulting authentication are at least sufficient to meet the applicable LoA. That is, an OpenID Provider MAY apply RBA to require authentication methods with enhanced security or ease towards more user friendly methods when allowed by evaluated risk for an authentication, as long as the trust framework requirements are met. Selection of and criteria for any LoA framework are, however, situation specific and beyond the scope of this profile.

OpenID Providers MAY provide vot (Vectors of Trust) and vtm (Vector Trust Mark) values in ID Tokens only if the acr Claim is not requested by the Client (either via the acr_values or claims parameters). More information on Vectors of Trust is provided in [RFC8485].

This profile requires an Access Token to be in JWT form. This is in line with the underlying NL GOV Assurance profile for OAuth 2.0 [OAuth2.NLGov].

Using a JWT formatted Access Token allows any OpenID Client to consume and verify a token without the need for introspection, thus reducing the dependency on an interaction with an external endpoint. As a result this may reduce load and availability requirements on the OpenID Provider. Furthermore, it provides a more uniform format over Access Token, ID Token, UserInfo response and Introspection response.

Note that ID Tokens and UserInfo responses are primarily intended for the Client. The Access Token is primarily intended for consumption by a Resource Server. The Introspection response is intended for the requestor of an Introspection, which can be either a Client or Resource Server. The Resource Server is typically not considered as an actor in OpenID Connect, but OpenID Providers will often act as Authorization Servers. In the case of Service Intermediation this is applicable by definition. This profile does not directly place any constraints on the placement of Claims in various tokens or response messages. Claims may be placed in any of the four tokens/response messages, unless explicitly specified otherwise. This allows for maximum flexibility and interoperability.

OpenID Providers MAY issue Refresh Tokens to Clients; when used, Refresh Tokens MUST be one-time-use or sender-constrained.

OpenID Providers MAY cryptographically bind Refresh Tokens to the specific Client instance (see also [OAuth2.1], Section 6.1); other methods to create sender-constrained Refresh Tokens MAY be applied as well.

For security reasons, Refresh Tokens that are not sender-constrained MUST be one-time-use, i.e. with every Access Token refresh response the OpenID Provider can issue a new Refresh Token and MUST invalidate the previous Refresh Token (see also [RFC6819], Section 5.2.2.3 and [OAuth2.1], Section 6.1).

Refresh Tokens MUST expire if the Client has been inactive for some time, i.e., the Refresh Token has not been used to obtain fresh Access Tokens for some time. The expiration time is at the discretion of the OpenID Provider, but MUST NOT exceed a maximum of 6 hours, preferably shorter.

For public Clients, no cryptographic key or Client Authentication method for binding Refresh Tokens to a specific Client is available. Public Clients therefore MUST use one-time-use Refresh Tokens with a limited validity, if applied.

All OpenID Providers are uniquely identified by a URL known as the issuer and MUST make a Discovery document in JSON format available at the path formed by concatenating /.well-known/openid-configuration to the issuer and SHOULD also make this Discovery document available at the path formed by concatenating /.well-known/oauth-authorization-server to the issuer. OpenID Providers MAY also publish their Discovery documents on other locations. All paths on which the Discovery document is published MUST use the https scheme.

Note that for privacy considerations, only direct requests to the server metadata document SHOULD be used. The WebFinger method to locate the relevant OpenID Provider and its metadata, as described in [OpenID.Discovery] section 2, MUST NOT be supported.

This profile imposes the following requirements upon the Discovery document:

issuer

• REQUIRED. The fully qualified Issuer URL of the OpenID Provider as defined by [RFC8414].

authorization_endpoint

• REQUIRED. The fully qualified URL of the OpenID Provider's Authorization Endpoint as defined by [RFC6749].

token_endpoint

• REQUIRED. The fully qualified URL of the OpenID Provider's Token Endpoint as defined by [RFC6749].

userinfo_endpoint

• RECOMMENDED. The fully qualified URL of the OpenID Provider's Userinfo Endpoint as defined by [OpenID.Core].

registration_endpoint

• RECOMMENDED. The fully qualified URL of the OpenID Provider's Dynamic Registration endpoint [RFC7591].

introspection_endpoint

• OPTIONAL. The fully qualified URL of the OpenID Provider's Introspection Endpoint as defined by 'OAuth 2.0 Token Introspection' [RFC7662].

revocation_endpoint

• OPTIONAL. The fully qualified URL of the OpenID Provider's Revocation Endpoint as defined by 'OAuth 2.0 Token Revocation' [RFC7009].

jwks_uri

• REQUIRED. The fully qualified URL of the OpenID Provider's public keys in JWK Set format. These keys can be used by Clients to verify signatures on tokens and responses from the OpenID Provider and for encrypting requests to the OpenID Provider.

scopes_supported

• REQUIRED. The list of scopes the OpenID Provider supports as defined by [RFC8414].

response_types_supported

• REQUIRED. JSON array containing the list of OAuth 2.0 response_type values that the OpenID Provider supports. In the context of this profile, the value MUST Be ['code'].

grant_types_supported

• REQUIRED. JSON array containing the list of OAuth 2.0 grant_type values that the OpenID Provider supports. In the context of this profile, the value MUST be ['authorization_code'].

claims_parameter_supported

• OPTIONAL. Boolean value specifying whether the OpenID Provider supports the use of the claims parameter, as defined by [OpenID.Discovery].

claims_supported

• REQUIRED. JSON array containing the list of Claims available in the supported scopes as defined by [OpenID.Discovery]. See Claims Supported.

claim_types_supported

• OPTIONAL. JSON array containing the list of Claim types that the OpenID Provider supports. REQUIRED when aggregated or distributed Claims are used. If omitted, the OpenID Provider only supports normal Claims. Identical to [OpenID.Discovery].

sub_id_types_supported

• OPTIONAL. JSON array containing the list of supported types of Subject Identifiers in the sub Claim of ID Tokens. The values MUST be URIs, the exact URIs to be used are situation specific; as an example encrypted BSNs and Pseudonyms could be specified with urn:nl-eid-gdi:1.0:id:BSN or urn:nl-eid-gdi:1.0:id:Pseudonym respectively.

acr_values_supported

• OPTIONAL. JSON array containing the list of supported Levels of Assurances, as defined by [OpenID.Discovery]. See Authentication Context.

subject_types_supported

• REQUIRED. JSON array containing the list of Subject Identifier types that this OpenID Provider supports. Valid types include pairwise and public.

token_endpoint_auth_methods_supported

• REQUIRED. JSON array containing the list of Client Authentication methods that this OpenID Provider supports. With respect to this profile, the allowed values are private_key_jwt, tls_client_auth, or both.

id_token_signing_alg_values_supported

• REQUIRED. JSON array containing the list of JWS signing algorithms (alg values) supported by the OpenID Provider for the ID Token to encode the Claims in a JWT. For more information, refer to Algorithms.

id_token_encryption_alg_values_supported

• OPTIONAL. JSON array containing the list of JWE encryption algorithms (alg values) supported by the OpenID Provider for the ID Token to encrypt the Content Encryption Key (CEK). REQUIRED when the OpenID Provider supports encryption of ID Tokens. For more information, refer to Algorithms.

id_token_encryption_enc_values_supported

• OPTIONAL. JSON array containing the list of JWE encryption algorithms (enc values) supported by the OpenID Provider for the ID Token to encrypt the Claims in a JWT using the CEK. REQUIRED when the OpenID Provider supports encryption of ID Tokens. For more information, refer to Algorithms.

userinfo_signing_alg_values_supported

• REQUIRED. JSON array containing the list of JWS signing algorithms (alg values) supported by the UserInfo Endpoint to encode the Claims in a JWT. For more information, refer to Algorithms.

userinfo_encryption_alg_values_supported

• OPTIONAL. JSON array containing the list of JWE encryption algorithms (alg values) supported by the OpenID Provider for the UserInfo Endpoint to encrypt the Content Encryption Key (CEK). REQUIRED when the OpenID Provider supports encryption of UserInfo responses. For more information, refer to Algorithms.

userinfo_encryption_enc_values_supported

• OPTIONAL. JSON array containing the list of JWE encryption algorithms (enc values) supported by the OpenID Provider for the UserInfo Endpoint to encrypt the Claims in a JWT using the CEK. REQUIRED when the OpenID Provider supports encryption of UserInfo responses. For more information, refer to Algorithms.

request_object_signing_alg_values_supported

• REQUIRED. JSON array containing the list of JWS signing algorithms (alg values) supported by the OpenID Provider for Request Objects. These algorithms are applicable for Request Objects passed by value and passed by reference. For more information, refer to Algorithms.

request_object_encryption_alg_values_supported

• OPTIONAL. JSON array containing the list of JWE encryption algorithms (alg values) supported by the OpenID Provider for Request Objects to encrypt the Content Encryption Key (CEK). REQUIRED when the OpenID Provider supports encryption of UserInfo responses. For more information, refer to Algorithms.

request_object_encryption_enc_values_supported

• OPTIONAL. JSON array containing the list of JWE encryption algorithms (enc values) supported by the OpenID Provider for Request Objects to encrypt the Claims in a JWT using the CEK. REQUIRED when the OpenID Provider supports encryption of UserInfo responses. For more information, refer to Algorithms.

request_uri_parameter_supported

• OPTIONAL. Boolean value which specifies whether the OpenID Provider accepts Request Objects passed by reference using the request_uri parameter. As per [OpenID.Core], the default value is true.

require_request_uri_registration

• REQUIRED and MUST have Boolean value true if the OpenID Provider accepts Request Objects passed by reference using the request_uri parameter. OPTIONAL otherwise. This parameter indicates that request_uri values used by the Client to send Request Objects by reference must always be pre-registered.

signed_metadata

• RECOMMENDED. A JWT, signed using JWS, containing metadata values about the OpenID Provider as claims, as specified in [RFC8414], Section 2.1.

It is RECOMMENDED that OpenID Providers provide caching directives through HTTP headers for the Discovery endpoint and the jwks_uri endpoint and make the cache valid for at least one week. OpenID Providers SHOULD document their change procedure. In order to support automated transitions to configuration updates, OpenID Providers SHOULD only make non-breaking changes and retain backward compatibility when possible. It is RECOMMENDED that OpenID Providers monitor usage of outdated configuration options used by any OpenID Client and actively work with their administrators to update configurations. The above on caching and changes MUST be applied to the jwks_uri containing the OpenID Provider's key set as well.

The OpenID Provider MUST provide its public keys in JWK Set format, such as the following example JWK Set containing a PKIoverheid certificate chain and its 2048-bit RSA key (example certificates abbreviated):

In case PKIoverheid certificates are used, the certificate and entire certificate chain up until the root certificate MUST be included as either an x5c or as x5u parameter, according to [RFC7517] Sections 4.6 and 4.7. Parties SHOULD support the inclusion of the certificate chain as x5c parameter, for maximum interoperability. Parties MAY agree to use x5u, for instance for communication within specific environments.

The OpenID Provider SHOULD utilize the approaches described in [OpenID.Core], Sections 10.1.1 (signing keys) and 10.2.1 (encryption keys), to facilitate rotation of public keys.

Please refer to Algorithms for more information on eligible cryptographic methods and keys that can be used by OpenID Providers.

Security of OpenID Connect and OAuth 2.0 is significantly based on the application of cryptography. Herein the choice of algorithms is important for both security as well as interoperability. This section lists relevant choices of algorithms for all messages and tokens.

For signing of messages and tokens, implementations:

• MUST support RS256.
• SHOULD support PS256; usage of PS256 is RECOMMENDED over RS256.
• MAY support other algorithms, provided they are at least equally secure as RS256.
• MUST NOT support algorithms that are less secure than RS256.

For asymmetric encryption, in particular encryption of content encryption keys, implementations:

• MUST support RSA-OAEP.
• SHOULD support RSA-OAEP-256.
• MAY support other algorithms, provided they are at least equally secure as RSA-OAEP.
• MUST NOT support algorithms that are less secure than RSA-OAEP.

For symmetric encryption, implementations:

• MUST support A256GCM.
• MAY support other algorithms, provided they are at least equally secure as A256GCM.
• MUST NOT support algorithms that are less secure than A256GCM.

In addition to proper selection and configuration of algorithms, implementations MUST ensure to use a cryptographically secure (pseudo)random generator. Administrators and implementations MUST apply industry best practices for key management of cryptographic keys. This includes best practices for selection of applicable key length as applicable for the relevant algorithm(s) selected.

One functionality that is widely used in the (semi-)governmental sector but is not included in the initial version of this profile specification is Service Intermediation. This scenario is sometimes also refered to as identity propagation. Examples of Service Intermediation scenario's include portals, API aggregators and Clients with enhanched or automated assistence for consuming services.

Service Intermediation is applicable when the Service Provider does not directly interact with the End-User, but delegates this responsibility to a Service Intermediary. The Service Intermediary therefore interacts with the OpenID Provider for End-User authentication, with the service offered by the Serivce Provider in scope of the Authentication Request. The Service Provider can now rely on a token from the OpenID Provider received via the Service Intermediary. Note that there is interaction with OAuth2, the Service Provider acts as Resource Server.

Such a Service Intermediary can intermediate a single service offered by a single Service Provider (e.g. an accounting app (service) that has an option to submit a tax declaration) or it can aggregate multiple Services offered by multiple Service Providers using intermediation (e.g. an app that aggregates your health information stored at several health organisations).

It is anticipated that support for Service Intermediation will be added in a later version of this profile; when it will, the following should be considered:

• Service Intermediaries should be able to obtain Claims and subject identifiers for different intermediated Services via different interactions with the OpenID Provider, with End-User consent but without the need of complete re-authentication.
• Service Intermediaries are generally not allowed to access Claims and subject identifiers. Hence, the use of pairwise and encrypted subject identifiers and Claims is usually required.
• Service Providers control which Service Intermediaries they support, specifically when confidential information is involved. Hence, Client Registration with the OpenID Provider must be established such that Service Intermediaries can only intermediate (and request Claims and subject identifiers for) Services that they are authorized for. A potential solution direction could be the use of Proof-of-Possession Key Semantics, as described in [RFC7800].

This profile acknowledges that federations are widely in use, in particular among (semi-)governmental and public domain orgranisations. However, no specific support or requirements for federations are included in this version of this profile. The OpenID Foundation is currently drafting a specification for explicit support of federations using OpenID Connect. Future updates to this profile may adopt such federation specificaitons once finalized. See Federation at the OpenID Foundation.

The following overview lists RFC and BCP documents being drafted by the OAuth 2.0 working group of the Internet Engineering Task Force (IETF) and work-in-progress by the OpenID Foundation. Future updates to this profile are likely to seek usage of and interoperability with these specifications once finalized.

[OAuth2.JWT]

• An RFC for Access Tokens in JWT format is being drafted in the OAuth 2.0 working group at IETF.

[OAuth2.JAR]

• An RFC for Secured (signed and/or encrypted) Authorization Requests is being drafted in the OAuth 2.0 working group at IETF. Most of the practices described in this RFC are already part of the OpenID Connect Core specification.

[OAuth2.RAR]

• An RFC that introduces a request parameter authorization_details, which allows for more expressive Authentication Requests than those possible with the scope parameter, is being drafted in the OAuth 2.0 working group at IETF.

[OAuth2.PAR]

• An RFC that introduces an endpoint to which Clients can push Authorization Requests via a direct POST request to an Authorizaton Server, prior to forwarding the End-User with a request_uri referencing the request to the Authorization Server, is being drafted in the OAuth 2.0 working group at IETF. The practices described in this RFC are already part of the OpenID Connect Core specification.

[OAuth2.Security]

• A Best Current Practice document that extends the OAuth 2.0 Security Threat Model and provides security recommendations to address security challenges in OAuth 2.0 is being drafted in the OAuth 2.0 working group at IETF.

[OAuth2.Browser-Based-Apps]

• A Best Current Practice document that details security considerations and best practices to be taken into account when implementing browser-based applications that use OAuth 2.0 is being drafted in the OAuth 2.0 working group at IETF.

[OAuth2.1]

• An effort to consolidate and simplify OAuth 2.0 by adding and removing functionality of the core OAuth 2.0 specification and by incorporating several RFCs and BCPs that were built upon OAuth 2.0.

[OpenID.Federation]

• Work by the OpenID Foundation to support federations of OpenID Providers and relying Service Providers, by publishing aggregated metadata in a specified format.