Basic, Messages, Standard, Session - Review Check ID Endpoint text

[Michael Jones]

Look at Check ID Endpoint requests, verification text for Check ID Request/Response.

[Edmund Jay]

In Messages, section 2.3.1 Check ID Request, it mentions Bearer Tokens and the access token parameter. By default, Bearer Tokens has a HTTP binding, so should we be mentioning these in the Messages spec? It probably should belong in Standard since it's the HTTP binding spec. Also, the access_token parameter mentions HTTP authorization header, so maybe that should be moved to Standard as well. In section 2.3.2 Check ID Response, the section mentions setting content-type to application/json which is also HTTP related.

The same problem exists for the UserInfo sections. HTTP related text is included even though Messages is the abstract spec.

I think Section 5.2 can use a bit of clarification regarding the signing and decryption keys.

To verify the validity of ID Token in the Authorization //or Token Endpoint// Response, the Client MUST do the following:

    1. 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?)
      //1.1 The Client MUST then perform the following steps using the ID Token in the decrypted payload.//
    2. 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.
    3. 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
    4. 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.
    5. 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.
    6. 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.
    7. The current time MUST be less than the value of the exp Claim.
    8. 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.
    9. 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.
   10. 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.

Section 5.3 of Messages mentions POST body and HTTP header which should be moved to Standard.

Do we need to mention the public keys used for asymmetric signature validation?

Does the AS need to verify that the iss claim is itself and aud is one of its known clients?

Should AS check to make sure that the ID Token is not encrypted?

[Nat Sakimura]

Edmund, you are right.

Anything that is protocol binding related should be moved to Standard and removed from Messages. Searching for Bearer, HTTP etc. is a good check.

Re: Sec. 5.2. Good catch.

[Nat Sakimura]

In addition, 5.4 Referes to checking through TLS server certificate check. This also belongs to Standard. In Messages, it should just state that the identity of the OP MUST be verified.

[Michael Jones]

Nat will move the text from Messages to Standard that is about bindings. Edmund will file separate bugs for the other issues and assign them to John, other than those that pertain to moving text, which will be assigned to Nat.

[Nat Sakimura]

Check ID Verification Rules Re #408

→ 7b59cdbcc576

[Michael Jones]

Edmund may file new tickets based upon some of the comments contained, but the core issue in this ticket has been addressed.