Openid Connect Conformance Profiles V3.0

OpenID Connect Conformance Profiles v3.0

OpenID Connect Working Group, OpenID Foundation

June 28, 2018

1. Introduction This document defines the set of profiles of the OpenID Connect specifications used for certifying implementations conforming to those profiles. This document also lists the features that must be supported by implementations certified as conforming to each profile and lists the tests used to test those features.

Many but not all of the features are able to be tested using the self-certification test procedures established by the OpenID Connect working group and the OpenID Foundation. The testing procedures are described in the Conformance Testing Procedures.

2. Overview of Conformance Profiles This section briefly describes each of the defined conformance profiles. In the published summaries of conformance self-certification results, these are the columns in the certification results table and implementations are the rows.

This section describes the conformance profiles included in the phase 1 launch of the OpenID Certification program in April 2015. While future phases of the OpenID Certification program will include Relying Party profiles, all of the phase 1 profiles are OpenID Provider profiles.

2.1 OpenID Provider Conformance Profiles

2.1.1 Basic OpenID Provider Basic OpenID Providers implement the features needed by Basic Relying Parties – essentially, those that use the features described in the OpenID Connect Basic Client Implementer’s Guide 1.0 (although the actual profile is based on OpenID Connect Core 1.0). These include the Mandatory to Implement Features for All OpenID Providers described in Section 15.1 of OpenID Connect Core 1.0.

2.1.2 Implicit OpenID Provider Implicit OpenID Providers implement the features needed by Implicit Relying Parties – those that use the features described in the OpenID Connect Implicit Client Implementer’s Guide 1.0, excluding the Self-Issued OP features described in Section 4 (although the actual profile is based on OpenID Connect Core 1.0). These include the Mandatory to Implement Features for All OpenID Providers described in Section 15.1 of OpenID Connect Core 1.0.

2.1.3 Hybrid OpenID Provider Hybrid OpenID Providers implement the features needed by Hybrid Relying Parties – those that use the features described in Section 3.3 of OpenID Connect Core 1.0. These include the Mandatory to Implement Features for All OpenID Providers described in Section 15.1 of OpenID Connect Core 1.0.

2.1.4 OpenID Provider Publishing Configuration Information OpenID Providers Publishing Configuration Information publish their discovery information at provider configuration endpoints, as described in Sections 3 and 4 of OpenID Connect Discovery 1.0.

2.1.5 Dynamic OpenID Provider Dynamic OpenID Providers implement the Mandatory to Implement Features for Dynamic OpenID Providers described in Section 15.2 of OpenID Connect Core 1.0. Note that conforming to the Dynamic OpenID Provider profile also requires that the implementation conforms to the Basic OpenID Provider, Implicit OpenID Provider, and OpenID Provider Publishing Configuration Information profiles and implements the OP features of the OpenID Connect Discovery 1.0 and OpenID Connect Dynamic Client Registration 1.0 specifications.

2.1.6 Form Post OpenID Provider Form Post OpenID Providers support the Form Post Response Mode, as described in OAuth 2.0 Form Post Response Mode.

If the OP supports all of the Basic, Implicit, and Hybrid profiles, then the Form Post Response Mode must be supported for all six response_type values. However, if the OP does not support any of the Basic, Implicit, or Hybrid profiles, then Form Post Response Mode conformance is only measured over the response types for the supported profiles. For instance, if Implicit is not supported, then Form Post support is not expected for the “id_token” or “id_token token” response types.

2.2 Relying Party Conformance Profiles

2.2.1 Basic Relying Party Basic Relying Parties implement the features described in the OpenID Connect Basic Client Implementer’s Guide 1.0 (although the actual profile is based on OpenID Connect Core 1.0). These include the Mandatory to Implement Features for Relying Parties described in Section 15.4 of OpenID Connect Core 1.0.

2.2.2 Implicit Relying Party Implicit Relying Parties implement the features needed by Implicit Relying Parties – those that use the features described in the OpenID Connect Implicit Client Implementer’s Guide 1.0, excluding the Self-Issued RP features described in Section 4 (although the actual profile is based on OpenID Connect Core 1.0). These include the Mandatory to Implement Features for Relying Parties described in Section 15.4 of OpenID Connect Core 1.0.

2.2.3 Hybrid Relying Party Hybrid Relying Parties implement the features described in Section 3.3 of OpenID Connect Core 1.0. These include the Mandatory to Implement Features for Relying Parties described in Section 15.4 of OpenID Connect Core 1.0.

2.2.4 Relying Party Using Configuration Information Relying Parties Using Configuration Information consume discovery information from provider configuration endpoints, as described in Sections 3 and 4 of OpenID Connect Discovery 1.0.

2.2.5 Dynamic Relying Party Dynamic Relying Parties can perform Dynamic Client Registration at OpenID Providers implementing the Dynamic OpenID Provider profile. Note that conforming to the Dynamic Relying Party profile also requires that the implementation conforms to the Basic Relying Party, Implicit Relying Party, and Relying Party Using Configuration Information profiles and implements the RP features of the OpenID Connect Discovery 1.0 and OpenID Connect Dynamic Client Registration 1.0 specifications.

2.2.6 Form Post Relying Party Form Post Relying Parties support the Form Post Response Mode, as described in OAuth 2.0 Form Post Response Mode.

If the RP supports all of the Basic, Implicit, and Hybrid profiles, then the Form Post Response Mode must be supported for all six response_type values. However, if the RP does not support any of the Basic, Implicit, or Hybrid profiles, then Form Post Response Mode

3 conformance is only measured over the response types for the supported profiles. For instance, if Implicit is not supported, then Form Post support is not expected for the “id_token” or “id_token token” response types.

3. Conformance Profile Definitions

3.1 OpenID Provider Conformance Profile Definitions The following table specifies the protocol features included in the OpenID Provider conformance profiles defined above (excepting the Form Post profile, which is still in pilot mode). It also names the tests in the OpenID Provider test suite at http://op.certification.openid.net/ that are used to test those features.

Conformance Feature Information OP Conformance Profiles Feature Name Conformance Test Name Test ID Basic Implicit Hybrid Config Dynamic Response Type & Response Mode Support code response_type Request with OP-Response-code y response_type=code Support id_token response_type Request with OP-Response-id_token y response_type=id_token Support id_token token Request with OP-Response-id_token+token y response_type response_type=id_token

token Support code id_token Request with OP-Response-code+id_token y response_type response_type=code

id_token Support code token Request with OP-Response-code+token y response_type response_type=code

token Support code id_token token Request with OP-Response- y response_type response_type=code code+id_token+token id_token token Reject request without Authorization request OP-Response-Missing y y y response_type missing the response_type parameter

ID Token

ID Token has iss claim IdToken.verify() y y y

ID Token has sub claim IdToken.verify() y y y

ID Token has aud claim IdToken.verify() y y y

ID Token has iat claim IdToken.verify() y y y

Does the OP sign the ID Token and Does the OP sign the ID OP-IDToken-Signature y y y with what Token and with what Asymmetric ID Token signature Asymmetric ID Token OP-IDToken-RS256 y with RS256 signature with RS256 ID Token has kid claim IDToken has kid OP-IDToken-kid y y y

Unsecured ID Token signature Unsecured ID Token OP-IDToken-none y if uses y if uses y if uses with none signature with none none none none ID Token has at_hash when ID ID Token has at_hash OP-IDToken-at_hash y y Token and Access Token returned when ID Token and from Authorization Endpoint Access Token returned

from Authorization Endpoint ID Token has c_hash when ID ID Token has c_hash OP-IDToken-c_hash y Token and Authorization Code when ID Token and returned from Authorization Authorization Code

Endpoint returned from Authorization Endpoint UserInfo Endpoint

Has UserInfo Endpoint UserInfo Endpoint access OP-UserInfo-Endpoint y y y with GET and bearer header UserInfo Endpoint access with UserInfo Endpoint access OP-UserInfo-Header y y y header method with POST and bearer header UserInfo Endpoint access with UserInfo Endpoint access OP-UserInfo-Body Warning Warning Warning form-encoded body method with POST and bearer if broken if broken if broken body

UserInfo has sub claim OpenIDSchema.verify() y y y

Can provide signed UserInfo RP registers OP-UserInfo-RS256 y response with RS256 userinfo_signed_respons e_alg to signal that it wants signed UserInfo returned

nonce Request Parameter

Support requests without nonce Login no nonce, code OP-nonce-NoReq-code y when using the code flow flow Reject requests without nonce Reject requests without OP-nonce-NoReq-noncode y y unless using the code flow nonce unless using the code flow ID Token has nonce when ID Token has nonce when OP-nonce-code y requested for code flow requested for code flow ID Token has nonce when Request with nonce, OP-nonce-noncode y y requested for non-code flows verifies it was returned in ID Token scope Request Parameter

Support openid scope Does the OP sign the ID OP-IDToken-Signature no err no err no err Token and with what

Support profile scope Scope requesting profile OP-scope-profile no err no err no err claims Support email scope Scope requesting email OP-scope-email no err no err no err claims Support address scope Scope requesting address OP-scope-address no err no err no err claims Support phone scope Scope requesting phone OP-scope-phone no err no err no err claims Support scope value requesting all Scope requesting all OP-scope-All no err no err no err basic claims claims

display Request Parameter

Support display value page Request with OP-display-page no err no err no err display=page Support display value popup Request with OP-display-popup no err no err no err display=popup prompt Request Parameter

Support prompt value login Request with OP-prompt-login y y y prompt=login Support prompt value none Request with OP-prompt-none-NotLoggedIn y y y prompt=none when not logged in Support prompt value none Request with OP-prompt-none-LoggedIn y y y prompt=none when logged in Misc Request Parameters

Support max_age request Requesting ID Token with OP-Req-max_age=1 y y y parameter max_age=1 seconds

restriction ID Token has auth_time claim Requesting ID Token with OP-Req-max_age=1 y y y when max_age in request max_age=1 seconds

restriction Support max_age request Requesting ID Token with OP-Req-max_age=1 Warning Warning Warning parameter when max age reached max_age=1 seconds if no if no if no

restriction prompt prompt prompt Support max_age request Requesting ID Token with OP-Req-max_age=10000 y y y parameter when max age not max_age=10000 seconds reached restriction Ignores not understood query Request with extra query OP-Req-NotUnderstood y y y parameter in Authentication component Request Support id_token_hint request Using prompt=none with OP-Req-id_token_hint SHOULD SHOULD SHOULD parameter user hint through id_token_hint

Support login_hint request Providing login_hint OP-Req-login_hint no err no err no err parameter Support ui_locales request Providing ui_locales OP-Req-ui_locales no err no err no err parameter Support claims_locales request Providing claims_locales OP-Req-claims_locales no err no err no err parameter Support acr_values request Providing acr_values OP-Req-acr_values no err no err no err parameter OAuth Behaviors

OAuth state request value VerifyState() y y y returned in response Reject second use of Trying to use OP-OAuth-2nd Warning Warning Authorization Code authorization code twice if under if under should result in an error 30s 30s Reject second use of Trying to use OP-OAuth-2nd-30s OAuth OAuth Authorization Code after 30 authorization code twice MUST MUST seconds with 30 seconds in between must result in an error

Second use of Authorization Code Trying to use OP-OAuth-2nd-Revokes OAuth OAuth revokes previously issued Access authorization code twice SHOULD SHOULD Token should result in revoking previously issued access tokens

Reject second use of Trying to use OP-OAuth-2nd-30s OAuth OAuth Authorization Code authorization code twice MUST MUST with 30 seconds in between must result in an error

redirect_uri

Reject redirect_uri not matching a Sent redirect_uri does OP-redirect_uri-NotReg y y y registered redirect_uri not match a registered redirect_uri

Reject request without Reject request without OP-redirect_uri-Missing y redirect_uri when multiple redirect_uri when registered multiple registered Preserves query parameter in Request with a OP-redirect_uri-Query-OK y redirect_uri redirect_uri with a query component when a redirect_uri with the same query component is registered

Preserves query parameter in Request with a OP-redirect_uri-Query-OK y registered redirect_uris redirect_uri with a query component when a redirect_uri with the same query component is registered

Reject redirect_uri when query Rejects redirect_uri when OP-redirect_uri-Query-Mismatch y parameter does not match query parameter does not match what is registed Reject redirect_uri when query Request with redirect_uri OP-redirect_uri-Query-Added y parameter added with query component when registered redirect_uri has no query component

Reject registration of redirect_uris Registration where a OP-redirect_uri-RegFrag y with fragment redirect_uri has a fragment Client Authentication

Support client authentication to Access token request OP-ClientAuth-Basic-Dynamic y y Token Endpoint using HTTP Basic with client_secret_basic with POST authentication

(same as above) Access token request OP-ClientAuth-Basic-Static y y with client_secret_basic authentication Support client authentication to Access token request OP-ClientAuth-SecretPost- y y Token Endpoint using form- with client_secret_post Dynamic encoded client credentials in authentication POST body (same as above) Access token request OP-ClientAuth-SecretPost-Static y y with client_secret_post authentication Discovery

Publishes openid-configuration Publishes openid- OP-Discovery-Config y y discovery information configuration discovery

information Config has issuer ProviderConfigurationResponse.v y y erify() Discovered issuer matches ProviderConfigurationResponse.v y y openid-configuration path prefix erify() Discovered issuer matches ID IdToken.verify() y y Token iss value Config has CheckEndpoint() y y authorization_endpoint Config has token_endpoint CheckEndpoint() y unless y only Implicit Config has userinfo_endpoint CheckEndpoint() y unless y self-

issued Config has jwks_uri Verify that jwks_uri is OP-Discovery-jwks_uri y unless y published only

none Keys in OP JWKs well formed Keys in OP JWKs well OP-Discovery-JWKs y unless y formed only

none

Config has scopes_supported CheckScopeSupport() y y

Config has ProviderConfigurationResponse.v y y response_types_supported erify() Config has ProviderConfigurationResponse.v y y subject_types_supported erify() Config has ProviderConfigurationResponse.v y unless y id_token_signing_alg_values_sup erify() only ported none Config has claims_supported Verify that OP-Discovery-claims_supported y y claims_supported is published All OP endpoints use https VerifyOPEndpointsUseHTTPS() y y

Can Discover Identifiers using E- Can discover identifiers OP-Discovery-WebFinger-Email y Mail Syntax using e-mail syntax

Support WebFinger discovery Can discover identifiers OP-Discovery-WebFinger y using URL syntax

Dynamic Client Registration

Config has registration_endpoint Verify that OP-Registration-Endpoint y registration_endpoint is published Enables dynamic registration Client registration OP-Registration-Dynamic y request Support using Sector Identifier for no err pairwise sub values Displays logo_uri in login page Registration with logo_uri OP-Registration-logo_uri SHOULD

Displays policy_uri in login page Registration with OP-Registration-policy_uri SHOULD policy_uri

Displays tos_uri in login page Registration with tos_uri OP-Registration-tos_uri SHOULD

Uses keys registered with jwks Uses keys registered with OP-Registration-jwks y value jwks value Uses keys registered with jwks_uri Uses keys registered with OP-Registration-jwks_uri y value jwks_uri value Reject Sector Identifier not Incorrect registration of OP-Registration-Sector-Bad y containing registered redirect_uri sector_identifier_uri values Key Rotation

Can rotate OP signing key Can rotate OP signing OP-Rotation-OP-Sig y keys Support RP signing key rotation Request access token, OP-Rotation-RP-Sig y change RSA signing key and request another access token request_uri Request Parameter

Support request_uri request Support request_uri OP-request_uri-Support y parameter request parameter Support request_uri request Support request_uri OP-request_uri-Unsigned no err no err no err parameter with unsecured request parameter with request unsigned request Support request_uri request Support request_uri OP-request_uri-Unsigned- y parameter with unsecured request parameter with Dynamic request unsigned request

Support request_uri request Support request_uri OP-request_uri-Sig y parameter with signed request request parameter with signed request request Request Parameter

Support request request Support request request OP-request-Unsigned no err no err no err parameter with unsecured parameter with unsigned request request

claims Request Parameter

Support claims request parameter Claims request with OP-claims-essential no err no err no err essential name claim

3.2 Relying Party Conformance Profile Definitions The following table specifies the protocol features included in the Relying Party conformance profiles defined above above (excepting the Form Post profile, which is still in pilot mode). It also names the tests in the Relying Party test suite at http://rp.certification.openid.net/ that are used to test those features.

Conformance Feature Information RP Conformance Profiles Feature Name Conformance Test Name Test ID Basic Implicit Hybrid Config Dynamic Response Type & Response Mode Can make request with code Can make request using rp-response_type- y response_type response_type 'code' code Can make request with id_token Can make request using rp-response_type- y response_type response_type 'id_token' id_token Can make request with id_token Can make request using rp-response_type- y token response_type response_type 'id_token id_token+token token' Can make request with code Can make request using rp-response_type- y id_token response_type response_type 'code id_token' code+id_token Can make request with code token Can make request using rp-response_type- y response_type response_type 'code token' code+token Can make request with code Can make request using rp-response_type- y id_token token response_type response_type 'code id_token code+id_token+token token' ID Token Reject ID Token with invalid iss Rejects ID Token with incorrect rp-id_token-issuer- y y y claim 'iss' claim mismatch Reject ID Token without sub claim Rejects ID Token without 'sub' rp-id_token-sub y y y

claim Reject ID Token with invalid aud Rejects ID Token with invalid rp-id_token-aud y y y claim 'aud' claim Reject ID Token without iat claim Rejects ID Token without 'iat' rp-id_token-iat y y y claim Accept ID Token without kid claim if Accepts ID Token without 'kid' rp-id_token-kid- optional y y only one JWK supplied in jwks_uri claim in JOSE header if only absent-single-jwks one JWK supplied in 'jwks_uri' Reject ID Token without kid claim if Rejects ID Token without 'kid' rp-id_token-kid- optional rejection rejection multiple JWKs supplied in jwks_uri claim in JOSE header if absent-multiple-jwks allowed allowed multiple JWKs supplied in 'jwks_uri' Reject invalid at_hash when ID Rejects ID Token with incorrect rp-id_token-bad- y y Token and Access Token returned 'at_hash' claim when at_hash from Authorization Endpoint response_type='id_token token' Reject invalid c_hash when ID Rejects ID Token with incorrect rp-id_token-bad- y Token and Authorization Code 'c_hash' claim when hybrid c_hash returned from Authorization flow is used Endpoint Accepts ID Token with valid Accepts ID Token with valid rp-id_token-sig-rs256 y y y asymmetric 'RS256' signature asymmetric 'RS256' signature Can request and use unsecured ID Can request and use unsigned rp-id_token-sig-none optional use use Token signature ID Token optional optional Rejects invalid asymmetric ID Token Rejects ID Token with invalid rp-id_token-bad-sig- optional y y signature with rs256 asymmetric 'RS256' signature rs256 UserInfo Endpoint Accesses UserInfo Endpoint with Can send Access Token in the rp-userinfo-bearer- y y y header method HTTP Authorization request header header Accesses UserInfo Endpoint with Can send Access Token as rp-userinfo-bearer- alt to alt to alt to form-encoded body method form-encoded body parameter body hdr hdr hdr mthd mthd mthd

Does not access UserInfo Endpoint Does not send Access Token as (implicitly tested) y y y with query parameter method URI query parameter Reject UserInfo with invalid sub Rejects UserInfo Response rp-userinfo-bad-sub- y y y claim with invalid 'sub' claim claim Can request and use signed Can request and use signed rp-userinfo-sig use use UserInfo response UserInfo Response optional optional nonce Request Parameter Sends nonce request parameter Sends 'nonce' unless using rp-nonce-unless- y y unless using code flow code flow code-flow Reject ID Token with invalid nonce Rejects ID Token with invalid rp-nonce-invalid y y y when nonce valid sent 'nonce' when valid 'nonce' sent scope Request Parameter Scope openid present in all requests 'openid' scope value should be (implicitly tested) y y y present in the Authentication Request Can request UserInfo claims with Can request and use claims rp-scope-userinfo- use use use scope values using scope values claims optional optional optional Client Authentication Can make Access Token request Can make Access Token rp-token_endpoint- y y y using client_secret_basic client Request with client_secret_basic authentication 'client_secret_basic' authentication Discovery Can discover identifiers using e-mail Can discover OpenID providers rp-discovery- y syntax using acct URI syntax webfinger-acct Can discover identifiers using URL Can discover OpenID providers rp-discovery- y syntax using URL syntax webfinger-url Uses openid-configuration Uses Provider Configuration rp-discovery-openid- y y discovery information Information configuration

Reject discovered issuer not Rejects discovered issuer not rp-discovery-issuer- y y matching openid-configuration path matching provider not-matching-config prefix configuration issuer Reject ID Token with iss not Rejects discovered issuer not rp-discovery-issuer- y y matching discovered issuer matching provider not-matching-config configuration issuer Uses keys discovered with jwks_uri Uses keys discovered with rp-discovery- y y value jwks_uri value jwks_uri-keys Dynamic Client Registration Uses dynamic registration Uses dynamic registration rp-registration- y dynamic Registration has redirect_uris Registration request has (implicitly tested) y redirect_uris Keys in RP JWKs well formed Keys are published as a well- (implicitly tested) y formed JWK Set Uses https for all endpoints unless Uses HTTPS for all endpoints (implicitly tested) y y y only using code flow Key Rotation Support OP signing key rotation Supports rotation of provider's rp-key-rotation-op- y y asymmetric signing keys sign-key request_uri Request Parameter Can use request_uri request Can use request_uri request rp-request_uri- use parameter with unsecured request parameter with unsigned unsigned optional request Can use request_uri request Can use request_uri request rp-request_uri-sig use parameter with signed request parameter with signed request optional