OpenID Connect Profile for Sweden Connect

Version 1.0 - 2024-12-04

Registration number: 2024-7674

Introduction

1.1. Requirements Notation and Conventions

1.2. Conformance
OpenID Provider Requirements

2.1. OpenID Provider Discovery and Metadata Requirements

2.2. Authentication Request Requirements

2.2.1. Single Sign-on Processing

2.2.2. User Message Request Parameter

2.2.3. Requested Authentication Provider Parameter

2.3. Token Endpoint Requirements

2.3.1. Client Authentication Requirements

2.3.2. Token Response Requirements

2.4. eIDAS Requirements
Relying Party Requirements

3.1. Authentication Request Requirements

3.2. Client Registration and Metadata Requirements
References
Changes between versions

1. Introduction

This profile is an extension of The Swedish OpenID Connect Profile, [OIDC.Sweden.Profile], for the Sweden Connect identity federation.

The profile aims to get a baseline security and to facilitate interoperability between relying parties and OpenID providers within the Sweden Connect identity federation.

Note: This version of the profile does not address features concerning "Signature Services" and requirements for "authentication for Signature" that are specified in the corresponding Sweden Connect SAML deployment profile, [SC.SAML.Profile]. Nor does the profile specify how OpenID Provider metadata and Relying Party/Client metadata is distributed and made available to the members of the federation. This will be added in future versions of the profile.

1.1. Requirements Notation and Conventions

The keywords “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 behaviour 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), and the interaction between them.

Components compliant with this profile MUST adhere to the requirements of The Swedish OpenID Connect Profile, [OIDC.Sweden.Profile] along with the extensions and requirements stated in the rest of this profile.

2. OpenID Provider Requirements

An OpenID Provider compliant with this profile MUST adhere to the requirements stated in [OIDC.Sweden.Profile] along with the additions declared below.

2.1. OpenID Provider Discovery and Metadata Requirements

The following requirements concerning OpenID Provider Metadata documents apply in addition to section 5.2 of [OIDC.Sweden.Profile]:

The OP Metadata document SHOULD contain a service_documentation parameter having as its value a URL pointing to a resource containing human-readable information about the OP (for example, information about client registration). See section 3 of [OpenID.Discovery].
The OP Metadata document MUST contain the ui_locales_supported parameter, and its value MUST contain English (en) and Swedish (sv), and MAY contain support for other languages. See section 3 of [OpenID.Discovery].

Note: This version of the profile does not specify how OpenID Provider Metadata documents are made available to the Relying Parties/Clients of the federation. Future versions will include OpenID Federation and alternative mechanisms for distributing metadata.

2.2. Authentication Request Requirements

2.2.1. Single Sign-on Processing

Sweden Connect is a national identity federation and the Relying Parties of the federation generally have no organizational affinity, other than they use the same OpenID Providers for authentication of their users. Therefore, the feature of Single Sign-on by relying on a user's security context/session at an OpenID Provider that is used by several, non-connected, Relying Parties, should be used with great care.

This profile states the following requirements regarding the re-use of user sessions:

An OpenID Provider within the Sweden Connect federation MUST NOT allow user sessions to exceed 60 minutes.
If the prompt parameter is not present in an authentication request, the OpenID Provider MUST treat this request as if it would contain the prompt parameter with a value of login, meaning that a user (re-)authentication is required, no matter the state of the current user session at the provider.
If the prompt parameter is present and its value is set to none (meaning that the Relying Party wishes to make use of an existing user security context/session, i.e., SSO), the following requirements apply:
- If the security context/user session has expired, the OP MUST respond with an error holding the error code login_required.
- If the original authentication process, which led to the establishment of the security context, was created based on the request from another Relying Party than the sender of the current request, the OP MUST respond with an error holding the error code login_required.
  
  The exception to this requirement is that an OP is allowed to maintain a configuration of "groups of Relying Parties", where SSO is allowed. How this configuration is maintained is out of scope for this profile.
- If the original authentication process, which led to the establishment of the security context, was performed using another authentication method or acr (Authentication Context Class Reference) than what is requested in the current authentication request, the OP MUST respond with an error holding the error code login_required.
- If the original authentication process, which led to the establishment of the security context, involved user consent for a set of claims, and the current authentication request contains a request for a different set of identity claims, the OP MUST respond with an error holding the error code interaction_required.

See section 3.1.2.1 of [OpenID.Core] and section 2.1.4 of [OIDC.Sweden.Profile] regarding further requirements for the prompt request parameter.

2.2.2. User Message Request Parameter

It is RECOMMENDED that OpenID Providers compliant with this profile supports the https://id.oidc.se/param/userMessage request parameter according to section 2.1 of [OIDC.Sweden.RPar]. This parameter gives the Relying Party the possibility to request that a message (set by the RP) is displayed to the user during the authentication process.

OpenID Providers that support the https://id.oidc.se/param/userMessage request parameter MUST include the https://id.oidc.se/disco/userMessageSupported parameter in its Metadata document (see section 3.3.1 of [OIDC.Sweden.RPar]). If MIME types other than text/plain is supported, the OP MUST include the https://id.oidc.se/disco/userMessageSupportedMimeTypes parameter and as its value state all supported MIME types.

2.2.3. Requested Authentication Provider Parameter

An OpenID Provider that acts as a proxy for underlying authentication mechanisms SHOULD support the https://id.oidc.se/param/authnProvider request parameter extension (see section 2.2 of [OIDC.Sweden.RPar]).

OpenID Providers that support the https://id.oidc.se/param/authnProvider request parameter, MUST declare this support in its Metadata document using the https://id.oidc.se/disco/authnProviderSupported parameter, see section 3.2 of [OIDC.Sweden.RPar].

2.3. Token Endpoint Requirements

This section extends section 3 of [OIDC.Sweden.Profile] with additional requirements for Token endpoint requests and responses.

2.3.1. Client Authentication Requirements

The following requirements apply in addition to the requirements stated in section 3.1.1 of [OIDC.Sweden.Profile].

In the context of the Sweden Connect federation, the OpenID Provider MUST NOT accept any other client authentication methods than private_key_jwt, or, if a bilateral agreement exists with a Relying Party, mutual TLS authentication.

Mutual TLS authentication may be tls_client_auth or self_signed_tls_client_auth, and the requirements stated in section 2 of [RFC8705] MUST be followed.

2.3.2. Token Response Requirements

The contents of the Access Token issued in a Token response MUST NOT reveal any information about the user's identity or the authentication process.

Section 4.2 of [OIDC.Sweden.Profile] states:

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.

If the Access Token is a cleartext JWT holding user identity data, information that the Relying Party may not be authorized to access may be leaked. Therefore, it is RECOMMENDED that opaque strings are used as Access Tokens.

Note: An OpenID Provider that also acts as an OAuth2 Authorization Server may of course issue JWT Access Tokens. The above requirement only applies to the Access Tokens that are issued during authentication (i.e., for granting access to the UserInfo endpoint).

3. Relying Party Requirements

An OpenID Connect Relying Party (Client) compliant with this profile MUST adhere to the requirements stated in [OIDC.Sweden.Profile] along with the additions declared below.

3.1. Authentication Request Requirements

For all authentication requests where the Relying Party expects the user to authenticate itself, the RP SHOULD include the prompt request parameter and assign the login value. This is to prevent un-wanted SSO. See section 2.1.4 of [OIDC.Sweden.Profile].

It is RECOMMENDED that Relying Parties send authentication requests containing Request Objects, i.e., the request parameters are included in a JWT, and its encoding is assigned to the request parameter according to section 6.1 of [OpenID.Core]. It is also RECOMMENDED that the Request Object JWT is signed.

The above recommendation gives a higher level of security, and may be changed to an imperative requirement in future versions of this profile.

3.2. Client Registration and Metadata Requirements

Relying Parties compliant with this profile MUST follow the requirements stated in section 6 of [OIDC.Sweden.Profile] with the additions stated below.

The Relying Party/Client metadata MUST contain the following additional parameters:

The contacts parameter holding at least one email address of people/groups responsible for the Relying Party.
The client_name parameter holding the client presentation name. This name may be presented to the end-user by the OpenID Provider during authentication. The name MUST be given in Swedish (sv) and English (en).
The logo_uri parameter containing a URL referencing a logotype for the Relying Party. This logotype may be displayed by the OpenID Provider for the end-user during authentication. The URL MUST use the HTTPS-scheme and point to a valid image file. It is RECOMMENDED that the image file is in SVG-format. The parameter MAY be given for different languages.
The client_uri parameter containing a URL that is the home page for the Relying Party. This link may be used by the OpenID Provider when interacting with the user. The URL MUST use the HTTPS-scheme and point to a valid web page. The parameter MAY be given for different languages.

Also, it is RECOMMENDED, that a Relying Party includes the organization_name claim and provides its human-readable organization name in Swedish and English. See section 5.2.2 of [OpenID.Federation].

Example:

{
  ...
  "contacts": [
    "operations@example.com"
  ],
  "client_name#en": "The Example Service",
  "client_name#sv": "Exempeltjänsten",
  "logo_uri": "https://www.example.com/logo.svg",
  "client_uri#en": "https://www.example.com",
  "client_uri#sv": "https://www.example.com/sv",
  "organization_name#en" : "Example Organization",
  "organization_name#sv" : "Exempelorganisationen"
  ...
}

See further requirements concerning client metadata in section 2 of [OpenID.Registration].

Note: This version of the profile does not specify how client metadata is registered at/distributed to the OpenID Providers of the federation. Future versions will include OpenID Federation and alternative mechanisms for distributing client metadata.

4. References

[RFC2119]

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

[OpenID.Core]

[Sakimura, N., Bradley, J., Jones, M., de Medeiros, B. and C. Mortimore, "OpenID Connect Core 1.0", August 2015] (https://openid.net/specs/openid-connect-core-1_0.html).

[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.

[OpenID.Federation]

Hedberg, R., Jones, M.B., Solberg, A.Å., Bradley, J., De Marco, G. and V. Dzhuvinov, "OpenID Federation 1.0".

[RFC7515]

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.

[IANA-Reg]

IANA JSON Web Token Claims Registry.

[OIDC.Sweden.Profile]

The Swedish OpenID Connect Profile - version 1.0.

[OIDC.Sweden.Claims]

Claims and Scopes Specification for the Swedish OpenID Connect Profile - Version 1.0.

[OIDC.Sweden.RPar]

Authentication Request Parameter Extensions for the Swedish OpenID Connect Profile - Version 1.1.

[OIDC.Sweden.Sign]

Signature Extension for OpenID Connect - Version 1.1.

[SC.SAML.Profile]

Deployment Profile for the Swedish eID Framework.

5. Changes between versions

This is the first version of this specification.