Missing clear instructions of time constrains on statements and how to relate to OpenID Connect protocol

A single MS is a JWT and it has some time related claims exp, nbf and iat that are all OPTIONAL. An OpenID Connect trust chain (compound metadata) consists of a chain of metadata statements (JWTs).

The specification should say something about validating the trust chain as a whole when it comes to time constrains. This is important because it is tightly coupled with key rotation and revocation which is challenging topics of the trust fabric that is important to get clear and right, and without diverging understandings, implementations...

The spec should also give an example of how key rotation is performed for both a provider and a client.

Here is a few example of text that could be added.

Somewhere i section 3:

All statements MUST include the claims exp and iat.

Section 4.4:

The entity validating a chain of MS should first fetch all the relevant MS blocks. The entity will have a locally configured trust root, and a MS issued by this trusted entity should be the first MS to validate. Then each MS should be evaluated independently using the result of the previous.

For each MS, you will have a specific iss and a set of signing keys as input for the validation from the previous step. MS missing required claims should not be trusted. All signatures SHOULD include a key id both in the signature and in the signing keys jwks. An MS may contain multiple signing keys - used for key rollover. Although the MS signature needs to be valid now, the entity also need to keep track of the soonest expiration time (exp) of all the elements in the chain. The time window from now, until the soonest expiration time, is the time when the entity can trust the chain without the need to re-fetch and re-evaluate the chain.

For the trust chain to be complete the chain for a client needs to contain a redirect_uris claim. For a provider chain to be valid it needs to contain the issuer claim, and this claim has to match the outermost MS sub.

The OP should be able to fetch updated MS continuously in order to establish a durable trust relationship. This is possible either if all MS are independently available on HTTP endpoints, such as metadata_statement_uris - or even better WebFinger ;) or alternatively the RP regularly push updated MS through dynamic client registration updates.

The spec needs to state something about these two alternatives: * OP is allowed to fetch all needed MS and be able to extend the trust time window without interaction with the RP. The OP may then issue a long lived symmetric id/secret during client registration. The OP needs a way of signal (error code or similar) that the client is revoked or if update trust chain has otherwise failed. * In contract, if the OP is not able to fetch all the MS by itself, it need to issue short lived client id/secret, and the client will need to re-register for each time window pushing updated MS statements in the update request.

When this validation is well defined, key rotation becomes a piece of cake. According to the valid time window of a MS, the MS publish two signing keys, and start using the other, until the window is closed, and the first is dropped from the published MS.

Comments (3)