The Client Attestation PoP JWT should be able to support a data origin authentication service

[Denisthemalice]

Rather than relying on TLS to associate the authentication exchange with the request for a digital credential or for a security token,
security can be improved by solely relying on the private key which corresponds to the public key placed in the Client Attestation JWT.

The flow (5) is described as follows:

(5) The Client Instance generates a Proof of Possession (PoP) with
the Client Instance Key.

This flow only supports an authentication service while it can easily accommodate a data origin authentication service.

In the case of a data origin authentication service, a hash value of a former exchange with the Authorisation Server (i.e., the Issuer) can be included into the data that will be signed by the Client Instance Key.

That former exchange can be either a set of claims that the Client Instance requests to be included into a credential that will be issued or a token request.

It is proposed to allow Authorisation Servers to verify, using a single signed message, that the credentials request or the token request indeed originates from a Client instance that supports specific technical characteristics about the type of the device and the firmware/software on which the client instance is running.

In practice, it is proposed to optionally include a hash value of a former request with the Authorisation Server.

This should be added to the list of claims enumerated in section 5.1.

• req_hash: OPTIONAL. The req_hash (request hash value)
  claim. Its value is the base64url encoding of the left-most
  half of the hash of the octets of the ASCII representation of the
  request value, where the hash algorithm used is the hash algorithm
  used in the alg Header Parameter of the ID Token's JOSE Header.
  For instance, if the alg is RS256, hash the req_hash value with
  SHA-256, then take the left-most 128 bits and base64url-encode
  them. The at_hash value is a case-sensitive string.