at_hash required in messages, missing in basic profile

[Pamela Dingle]

In section 2.1.2.1 of draft 18 of the messages specification, the c_hash and at_hash claims are defined as OPTIONAL or REQUIRED (c_hash is REQUIRED when the idtoken is issued at the same time as an authorization code, at_hash is REQUIRED when the idtoken is issued at the same time as an access token).

I read the above as stating that one of the two claims is required in every idtoken that uses either the code or token flow.

In section 2.2 of draft 26 of the basic profile, however, the claims at_hash and c_hash are not even mentioned.

Either c_hash and at_hash claims need to be added to the basic profile, or the messages definitions for c_hash and at_hash need to be fixed.

[John Bradley]

The producer needs to include the hashes of the associated tokens when producing the id_token. Checking the hash by the client is not required with the response_type=code. This is because the id_token and token are bound by the TLS session directly between the client and token endpoint removing the opertunity for an attacker to swap the token. As the basic profile is only for the client the decision was to not confuse people creating simple clients by adding a explanation of a field that they don't need to validate.

We could say the field must be present in the received token but is not required to be validated in the flow used by Basic. I have a feeling that adding it will cause more problems than it will fix.

[Pamela Dingle]

I admit that your comment didn't clear anything up for me John. But Ryo Ito's email comment did. I only picked up on the difference between "idtoken sent with access token" vs "idtoken sent with code" but did not read between the lines to realize that since the idtoken is delivered by the Authorization endpoint this means that neither of these claims are applicable for the code flow in the first place.

[John Bradley]

We could probably remove c_hash as being optional when the token is issued from the token endpoint. The token endpoint, doesn't issue code, so that could be cleaned up in messages.

In messages it differentiates between id_tokens issued from the authorization endpoint vs those issued from the token_endpoint.

[John Bradley]

Say at hash may occur

[Michael Jones]

Fixed #833 - Stated that an "at_hash" Claim MAY be present in the ID Token.

→ <<cset 3bada6d59c94>>