Thanks Justin for bringing this to our attention.
Right now, I don't think that this is a big problem and I wasn't able to
come up with a way to improve the attack. I hope that it doesn't come
back to haunt us when somebody does a more in-depth analysis...
That said, the lack of binding to the ac
I agree with Daniel that I’d be a bit wary of assuming that this could never be
exploited. For example, a server-side web app that signs DPoP proofs on behalf
of client-side Javascript (to keep the key safe on the server) and reuses the
key for different users could be a risk.
IMO this is anot
On Tue, Nov 24, 2020 at 2:39 AM Daniel Fett wrote:
>
> The recommendation could be to use a fresh key pair for each token request.
>
>
Public clients will have RTs bound so need to use the same key.
--
_CONFIDENTIALITY NOTICE: This email may contain confidential and privileged
material for th
It took me some time to warm to the ECDH based idea but I do think it has a
lot of merit. For whatever it's worth, I put the idea forth as one
potential path forward during the general PoP interim meeting back in March
(
https://datatracker.ietf.org/meeting/interim-2020-oauth-02/materials/slides-in
With the renewed work on HTTP Message Signatures[1] in the HTTP WG[2], I think
we might have a good avenue for this ECDH-with-KDF flavor of message signature
in that arena instead of trying to twist it into DPoP. I think that this
signing mechanism will be a better base for a general PoP effort
Hi Karsten,
I read draft-meyerzuselhausen-oauth-iss-auth-resp-02. I think it is good
enough for authorization server implementers to implement the specification.
Best Regards,
Taka
On Tue, Nov 17, 2020 at 8:48 PM Karsten Meyer zu Selhausen <
karsten.meyerzuselhau...@hackmanit.de> wrote:
> Hi al
