All JWS's passed between entities MUST contain the "kid" header parameter to allow explicitly signaling a key change to the recipient. Furthermore, all key id's used by an entity MUST be scoped (to avoid name conflicts) by a unique URI managed by the organization owning the entity. In the same way, all JWK's passed between entities must have a scoped key id.
JWS's in the model:
- Software statements issued by a federation.
- Public intermediate signing key published both by relying party and provider.
- JWKS published both by relying party and provider.
- Signed metadata published by the provider.
- Registration request signature value computed by the relying party.
JWK's in the model:
- The federations public key.
- The OP and RP's JWK's:
- root key
- intermediate signing key
- all its keys published in the JWKS.
Assume the Federation Operator (FO) has a public/private signing key pair,
call it F. The public part of this key, pub(F)
, must be given to all entities
that are part of the federation as a JWK.
- Relying Party Operator (RPO) creates a long-lived signing key pair; call it A.
- RPO submits registration data to Federation Operator (FO).
The registration data MUST include
redirect_uris
androot_key =
pub(A)
. - FO returns a signed (with key F) software statement containing the
submitted registration data, and any applied policy restrictions
(
response_types
, signing/encryption algorithms for ID Tokens and/or UserInfo Responses, similar to SAML entity categories in the form of e.g.claims_allowed
and/orscopes_allowed
).
- OpenID Connect Provider Operator (OPO), creates a long-lived signing key pair; call it B
- OPO submits registration data to Federation Operator (FO).
The registration data MUST include
issuer
androot_key =
pub(B)
. - FO returns a signed (with key F) software statement, SSOP,
containing the submitted registration data, and any applied policy
restrictions (
response_types
, signing/encryption algorithms for ID Tokens and/or UserInfo Responses, similar to SAML entity categories in the form of e.g.claims_supported
and/orscopes_supported
). - The OP MUST use the same
root_key =
pub(B)
for all software statements it intends to publish in the same discovery document.
To allow for key rotation in multiple steps, an intermediate key is used for signing. The keys in the JWKS could be rotated on a timescale of once every 24 hours, while the intermediate key could be rotated on timescale of once every month (the long-lived key can't be rotated at all).
- Create a JSON Web Key Set (JWKS) and publish it at a URL specified by
jwks_uri
in the client metadata sent in the Registration Request. - Create a new intermediate signing key pair, call it An and sign the JWK representation of pub(An) with A.
- Sign the JWKS with An.
A -- sign --> JWK(pub(An)) -- sign --> JWKS
- Create a JSON Web Key Set (JWKS) and publish it at a URL specified by
jwks_uri
in the provider metadata. - Create a new intermediate signing key pair, call it Bn and sign that key with B.
- Sign the JWKS with Bn.
- Include the software statement SSOP in the provider configuration and sign the provider configuration document using the key Bn.
B -- sign --> JWK(pub(Bn)) -- sign --> JWKS and provider metadata
There are three steps of communication between an RP and OP, see below figure.
------ ------
| | <--- 1) Discovery --------> | |
| RP | <--- 2) Registration -----> | OP |
| | <--- 3) Authentication ---> | |
------ ------
After the discovery and registration is completed a first time, they SHOULD only be repeated if any changes occur (see notes in respective sections below).
The OP MUST publish its provider metadata as specified by Obtaining OpenID Provider Configuration Information. The RP makes a standard OpenID Provider Configuration Request. The OP responds with its provider configuration and the following additional metadata parameters:
software_statements
: a list of software statements from all federations the OP is part of.signed_metadata
: a JWS containing all published metadata, exceptsigned_metadata
.signed_jwks_uri
: a URI to the location where the OP publishes the signed JWKS, SHOULD return the Content-Type 'application/jose' to indicate that the JWKS is in the form of a JWS using the JWS Compact Serialization.signing_key
: a JWK containing the OP's intermediate public key pub(Bn).
Upon receiving the response the RP MUST do the following steps:
- Find any software statement, SSOPH, in the
software_statements
signed by federation H which the RP is also part of and verify its signature with the federations public key, pub(FH). If the OP and RP both are part of more than one common federation the RP may decide, using any heuristic of its choice, which software statement to use. Since the OP MUST have the sameroot_key
in all its software statements, it does not matter from which software statementroot_key
is extracted. - Verify that
issuer
in the software statement matchesissuer
in the discovery response. - Verify the signature of
signing_key
with theroot_key
from SSOPH. - Verify the signature of
signed_metadata
withsigning_key
, and use this metadata instead of the clear-text values provided in the OpenID Provider Configuration Response.
Note: the OpenID Provider Configuration Request must be repeated when the OP rotates its intermediate signing key pair Bn -> Bn+1.
The OP MUST support dynamic client registration. The RP makes a signed standard Client Registration Request and includes the following additional metadata parameters:
software_statements
: a list of software statements from all federations the RP is part of.signing_key
: a JWK containing the RP's intermediate public key pub(An).signed_jwks_uri
: a URI to the location where the RP publishes the signed JWKS, SHOULD return the Content-Type 'application/jose' to indicate that the JWKS is in the form of a JWS using the JWS Compact Serialization.
The body of the request MUST be signed with key An, using A Method for Signing an HTTP Requests for OAuth. The signature value MUST be sent in the request header field "Authorization", using the authorization scheme "pop", i.e.:
Authorization: pop <signature value>"
Upon receiving the request the OP MUST do the following steps:
- Find any software statement, SSRPI, in the
software_statements
signed by federation I which the OP is also part of and verify its signature with the federations public key, pub(FI). If the OP and RP both are part of more than one common federation the RP may decide, using any heuristic of its choice, which software statement to use. - Verify the signature of
signing_key
with theroot_key
included in the software statement. - Verify the signature of the registration request with
signing_key
. - Use any client metadata parameters in SSRPI for the registration (they override any metadata paramters in the signed registration request).
- Fetch the RP's signed JWKS from
signed_jwks_uri
and verify its signature withsigning_key
. This step must be repeated every time the RP rotates the keys in the JWKS. - Include
provider_software_statement =
SS
OP
I
in the Registration Response, signaling the OP's choice to use the common federation I as grounds for trust/policy.
Upon receiving the response the RP MUST do the following steps:
- Verify the signature of
provider_software_statement
. - Verify that
issuer
in the software statement matchesissuer
known from the previous the discovery response. - Verify the providers signing key again with
root_key
fromprovider_software_statement
. - Fetch the OP's signed JWKS from
signed_jwks_uri
and verify its signature withsigning_key
. This step must be repeated every time the OP rotates the keys in the JWKS. - Use any provider metadata parameters in
provider_software_statement
, which override the signed metadata parameters specified in the earlier Discovery step.
Note: the Client Registration Request must be repeated when the RP rotates its intermediate signing key pair An -> An+1.
The authentication/request does not need to be extended in any way.
- Conflicting claims in software statements when RP and OP are part of multiple common federations?