In order to prevent user agents from modifying Authorization responses we need to bind the response to the session with a more secure method than exists in OAuth 2.0 itself. OAuth 2.0 provides the client no protection from the user or user-agent modifying responses in the implicit flow.
Proposal: Modify multi-token response:
'id_token code' The response is fragment encoded code is passed as a claim in the id_token, and not as a separate parameter.
'id_token code token' The response is fragment encoded code is passed as a claim in the id_token, and not as a separate parameter, token is passed as a separate parameter.
In Messages add a new claim to id_token.
aft (Access Token Fingerprint) OPTIONAL This paramater is required for id_tokens issued by the Authorization endpoint when issued in conjunction with a access_token.
The value is the calculated by using the SHA hash of the equivalent bit length to the one used in the signing algorithm. If "lag":="HS256" then a SHA256 hash is calculated over the access_token. The hash output is then truncated in half by discarding the rightmost bits (in accordance with http://csrc.nist.gov/publications/nistpubs/800-107/NIST-SP-800-107.pdf,
The hash output is base64url encoded and used as the fingerprint value in the "aft" claim.
The check_id endpoint needs to take access_token as a paramater (I am thinking making this endpoint POST only). It would return an error if the access token failed to validate.
There may be a simplicity argument for not truncating the hash.