It's not a huge burden but does add some non-zero complexity to the
protocol as well as size to the proof. And in my mind anyway, doing so
would sort of beg the question as to having some similar treatment for
authz codes and refresh tokens. Which can, of course, also be done. But
adds more complex
The extent of the weirdness needed leads me to feel that it's not a threat
that's in scope. To copy the proof signature from a request with T1 onto a
new request using T2, Alice would need access to the first request, which
is made directly from client to RS. That's not possible for a web server
cl
BEGIN:VCALENDAR
PRODID:-//Microsoft Corporation//Outlook 10.0 MIMEDIR//EN
VERSION:2.0
METHOD:REQUEST
BEGIN:VTIMEZONE
TZID:America/New_York
TZURL:http://tzurl.org/zoneinfo-outlook/America/New_York
X-LIC-LOCATION:America/New_York
BEGIN:DAYLIGHT
TZOFFSETFROM:-0500
TZOFFSETTO:-0400
TZNAME:EDT
DTSTART:1
The Web Authorization Protocol (oauth) WG will hold
a virtual interim meeting on 2020-12-07 from 12:00 to 13:00 America/Toronto
(17:00 to 18:00 UTC).
Agenda:
This meeting is to discuss the OAuth 2.0 Authorization Server Issuer Identifier
in Authorization Response document:
https://tools.ietf.org
I agree with having the DPoP proof cover the access token (unless there's some
burden on the clients doing so that I'm unaware of).
That would also limit the ability to pre-compute DPoP proofs with future
timestamps (I sent an email to the list about this on 1 April) if an attacker
can perform
Correct, but the choice of using different keys is entirely in the hands of the
client, as the AS accepts whatever key the client presents in its initial DPoP
proof to bind to the token. If it’s on the client to prevent this kind of
thing, we should at least mention it in the security considerat
