Mesages - 5.2 ID Token Validation rule

Issue #456 invalid
Nat Sakimura created an issue

Currently, it is

If the Client has provided a id_token_encrypted_response_algs parameter during Registration, decrypt the id_token [JWE], using the key pair specified during Registration.

The Client MUST validate that the client_id in the aud (audience) Claim is one it has registered for the Issuer identified by the value in the iss (issuer) Claim. the ID Token MUST be rejected if the value of aud (audience) is not valid for the Issuer.

The Client MUST verify the ID Token signature according to Section 5 of JWS [JWS] using the algorithm specified in the alg parameter of the JWT header.

The value of alg SHOULD be the algorithm sent by the Client in the id_token_signed_response_algs parameter during Registration.

If the "alg" parameter of the JWT header is HS256 the client_secret for the client_id contained in the aud (audience) Claim is used to validate the signature.

For other Signing algorithms the Client must use the signing key provided in Discovery by the Issuer exactly matching the value of the iss (issuer) Claim.

The current time MUST be less than the value of the exp Claim.

The value of the nonce Claim MUST be checked to verify that it is the same value as the one that was sent in the Authorization Request. The Client SHOULD check the nonce value for replay attacks. The precise method for detecting replay attacks is client specific.

If the iso29115 Claim was requested, the Client SHOULD check that the asserted Claim Value is appropriate. The meaning and processing of "iso29115" Claim Values is out of scope for this specification.

If the auth_time Claim was requested, the Client SHOULD check the value and request re-authentication if it determines too much time has elapsed since the last user authentication.

Could be clarified as:

If the Client has provided a id_token_encrypted_response_algs parameter during Registration, decrypt the id_token [JWE], using the private key corresponding to the public encryption key (jwk_encryption_url or x509_encryption_url) specified during Registration. If a public encryption key has not been registered or configured, use the private key corresponding to the registered public keys (x509_url or jwk_encryption_url).(Can keys be preconfigured?). (Do we need to check encryption algorithms matches ones in Registration?)

The Client MUST then perform the following steps using the ID Token in the decrypted payload.

The Client MUST validate that the client_id in the aud (audience) Claim is one it has registered for the Issuer identified by the value in the iss (issuer) Claim. The ID Token MUST be rejected if the value of aud (audience) is not valid for the Issuer.

The Client MUST verify the ID Token signature according to Section 5 of JWS [JWS] using the algorithm specified in the alg parameter of the JWT header // and the public key

The value of alg SHOULD --> MUST (Registration states that id_token_signed_response_algs as REQURIED for signing) be the algorithm sent by the Client in the id_token_signed_response_algs parameter during Registration.

If the "alg" parameter of the JWT header is HS(256/384/512) the client_secret for the client_id contained in the aud (audience) Claim is used to validate the signature.

For other Signing algorithms the Client must use the signing key (x509_url or jwk_url) provided in Discovery by the Issuer exactly matching the value of the iss (issuer) Claim.

The current time MUST be less than the value of the exp Claim.

The value of the nonce Claim MUST be checked to verify that it is the same value as the one that was sent in the Authorization Request. The Client SHOULD check the nonce value for replay attacks. The precise method for detecting replay attacks is client specific.

If the iso29115 Claim was requested, the Client SHOULD check that the asserted Claim Value is appropriate. The meaning and processing of "iso29115" Claim Values is out of scope for this specification.

If the auth_time Claim was requested, the Client SHOULD check the value and request re-authentication if it determines too much time has elapsed since the last user authentication.

Comments (3)

  1. Nat Sakimura reporter

    It was Edmund's comment and I was trying to decipher it. Now Edmund is creating a ticket for it, so I have invalidated it.

  2. Log in to comment