Hello
After reviewing the DPoP spec, and reflecting on implementations I have
worked with, I wanted to see if there was interest in a DPoP Binding JWT.
The use case is to enable existing deployments to add support for DPoP
without having to replace their existing refresh token and access tokens,
On Tue, May 5, 2020 at 2:52 PM Brian Campbell
wrote:
>
>
>> 9.1:
>> This would be a good place to mention BREACH as an example of how a DPoP
>> proof (and AT) might leak, despite only being sent over a direct HTTPS
>> channel. Note though that adding a random jti is an effective defence
>>
Hi Karsten,
I'm not sure why I'm on this email chain. Would you kindly remove my email?
Thanks,
Kristen
On Mon, Nov 2, 2020, 12:54 AM Karsten Meyer zu Selhausen <
karsten.meyerzuselhau...@hackmanit.de> wrote:
> Hi all,
>
> Daniel and I published a new version of the "iss" response parameter
I implemented the draft quickly and found no big hurdle for authorization
server implementations. The current snapshot of my implementation does not
add the `iss` parameter when JARM is used. However, for interoperability, I
feel that the spec should describe expected behaviors when a JWT is
I suspect those params are to signal the client if the user was
(re)authenticated, prompted for consent and the consented scope. But
being non-std and non-documented params it would be best to ignore them.
Vladimir
On 05/11/2020 15:47, Alex Kalp wrote:
> Hi Vladimir,
>
> Thanks for the reply.
