3.2. <ins> This option, inspired by the OAuth DPoP specification RFC9449, uses a DPoP-like mechanism to authenticate the calling workload in the context of the request.  The WIMSE Identity Token to-wit is sent in the request as described in wit-http-header.  An additional JWT, the Workload Proof Token (WPT), is signed by the private key corresponding to the public key in the WIT.  The WPT is sent in the "Workload-Proof-Token" header field of the request.  A WPT contains the following: in the JOSE header: "alg": An identifier for an appropriate JWS asymmetric digital signature algorithm corresponding to the confirmation key in the associated WIT. "typ": the WPT is explicitly typed, as recommended in RFC8725, using the "application/wimse-proof+jwt" media type. in the JWT claims: "iss": The issuer of the token, which is the calling workload, represented by the same value as the "sub" claim of the associated WIT. "aud": The audience of the token contains the HTTP target URI (RFC9110) of the request to which the WPT is attached, without query or fragment parts. "exp": The expiration time of the WIT (as defined in RFC7519). WPT lifetimes MUST be short, e.g., on the order of minutes or seconds. "jti": A unique identifier for the token. "ath": Hash of the OAuth access token, if present in the request, which might convey end-user identity and authorization context of the request.  The value, as per RFC9449, is the base64url encoding of the SHA-256 hash of the ASCII encoding of the access token's value. "tth": Hash of the Txn-Token I-D.ietf-oauth-transaction-tokens, if present in the request, which might convey end-user identity and authorization context of the request.  The value MUST be the result of a base64url encoding (as defined in RFC7515) of the SHA-256 hash of the ASCII encoding of the associated token's value. "oth": Hash of any other token in the request that might convey end-user identity and authorization context of the request. The value MUST be the result of a base64url encoding (as defined in RFC7515) of the SHA-256 hash of the ASCII encoding of the associated token's value.  (note: this is less than ideal but seems we need something like this for extensibility) An example WPT might look like the following: The decoded JOSE header of the WPT from the example above is shown here: The decoded JWT claims of the WPT from the example above are shown here: An example of an HTTP request with both the WIT and WPT from prior examples is shown below: To validate the WPT in the request, the recipient MUST ensure the following: There is exactly one "Workload-Proof-Token" header field in the request. The "Workload-Proof-Token" header field value is a single and well-formed JWT. The WPT signature is valid using the public key from the confirmation claim of the WIT. The "typ" JOSE header parameter of the WPT conveys a media type of "wimse-proof+jwt". The "iss" claim of the WPT matches the "sub" claim of the WIT. (note: not sure "iss" in the WPT is useful or necessary) The "aud" claim of the WPT matches the target URI, or an acceptable alias or normalization thereof, of the HTTP request in which the WPT was received, ignoring any query and fragment parts. The "exp" claim is present and conveys a time that has not passed. WPTs with an expiration time unreasonably far in the future SHOULD be rejected. Optionally, check that the value of the "jti" claim has not been used before in the time window in which the respective WPT would be considered valid. If presented in conjunction with an OAauth access token, the value of the "ath" claim matches the hash of that token's value. If presented in conjunction with a Txn-Token, the value of the "tth" claim matches the hash of that token's value. If presented in conjunction with a token conveying end-user identity or authorization context, the value of the "oth" claim matches the hash of that token's value. </ins> 3.3. This option uses the WIMSE Identity Token (ref TBD) to sign the