[OAUTH-WG] DPoP followup I: freshness and coverage of signature

[Brian Campbell <[e-mail]>]

There were a few items discussed somewhat during the recent interim
<https://datatracker.ietf.org/meeting/interim-2020-oauth-16/session/oauth>
that I committed to bringing back to the list. The slide below (also
available as slide #17 from the interim presentation
<https://datatracker.ietf.org/meeting/interim-2020-oauth-16/materials/slides-interim-2020-oauth-16-sessa-dpop-01.pdf>)
is the first one of them, which is difficult to summarize but kinda boils
down to how much assurance there is that the DPoP proof was 'freshly'
created and that can dovetail into the question of whether the token is
covered by the signature of the proof.
There are many directions a "resolution" here could go but my sense of the
room during the meeting was that the contending options were:

   1.  It's sufficiently okay as it is
   2.  Include a hash of the access token in the DPoP proof (when an access
   token is present)


Going with #2 would mean the draft would also have to define how the
hashing is done and deal with or at least speak to algorithm agility.
Options (that I can think of) include:

   - 2a) Use the at_hash claim defined in OIDC core
   https://openid.net/specs/openid-connect-core-1_0.html#CodeIDToken. Using
   something that already exists is appealing. But its hash alg selection
   routine can be a bit of a pain. And the algorithm agility based on the
   signature that it's supposed to provide hasn't worked out as well as hoped
   in practice for "new" JWS signatures
   https://bitbucket.org/openid/connect/issues/1125/_hash-algorithm-for-eddsa-id-tokens
   - 2b) Define a new claim ("ah", "ath", "atd", "ad" or something like
   that maybe) and just use SHA-256. Explain why it's good enough for now and
   the foreseeable future. Also include some text about introducing a new
   claim in the future if/when SHA-256 proves to be insufficient. Note that
   this is effectively the same as how the confirmation claim value is
   currently defined in this document and in RFC8705.
   - 2c) Define a new claim with its own hash algorithm agility scheme
   (likely similar to how the Digest header value or Subresource Integrity
   string is done).


I'm requesting that interested WG participants indicate their preference
for #1 or #2. And among a, b, and c, if the latter.

I also acknowledge that an ECDH approach could/would ameliorate the issues
in a fundamentally different way. But that would be a distinct protocol. If
there's interest in pursuing the ECDH idea, I'm certainly open to it and
even willing to work on it. But as a separate effort and not at the expense
of derailing DPoP in its general current form.
[image: Slide17.jpeg]

-- 
_CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
material for the sole use of the intended recipient(s). Any review, use, 
distribution or disclosure by others is strictly prohibited.  If you have 
received this communication in error, please notify the sender immediately 
by e-mail and delete the message and any file attachments from your 
computer. Thank you._