Hi Denis,
On Fri, May 01, 2020 at 10:47:18AM +0200, Denis wrote:
>Comments on draft-ietf-oauth-dpop-00.
>
>1) In section 9 (Security considerations), the text states:
>
>DPoP does not, however, achieve the
> same level of protection as TLS-based methods such as OAuth
On Fri, May 01, 2020 at 02:29:02AM +, Mike Jones wrote:
> * Is the DPoP signature really needed when requesting a bound token? It
> seems like the worst that could happen would be to create a token bound to a
> key you don't control, which you couldn't use. Daniel expressed concern
>
Yes, it potentially could. But I think we *really* want to avoid
adding a challenge/response
round trip to every call. So it wouldn't be a nonce exactly and there'd
need to some guidance or something on what it is and how long it could be
used. And that could introduce new server side state. Also
Thanks Neil. I do appreciate your review and feedback (even if it takes me
a nontrivial amount of time to reply). I've attempted to respond to things
inline below.
On Mon, May 4, 2020 at 5:51 AM Neil Madden
wrote:
> Some review comments:
>
> Section 1:
> I think terms like “relatively simple”
Hi all,
There was some discussion about adding “server contribution” in the DPoP proof.
I was wondering if the “challenge” server response described in section 6 can
include such a contribution (e.g., a server generated nonce).
Best,
Nikos
From: OAuth On Behalf Of Brian Campbell
Sent:
Hi all,
This is a 3rd working group last call for "JSON Web Token (JWT) Profile for
OAuth 2.0 Access Tokens".
Here is the document:
https://tools.ietf.org/html/draft-ietf-oauth-access-token-jwt-07
Please send your comments to the OAuth mailing list by May 12, 2020.
Regards,
Rifaat &
Comments on draft-ietf-oauth-security-topics-15
1) Historically, the acronym RO (Resource Owner) has been used but is
still used in this document.
Since a client is not necessarily any more a RO, it would be more
adequate to use the word "Client"
instead of "RO" in this document.
2)
Over in the ACE working group we are currently having a discussion about
refreshing tokens on an RS. I want to make sure that this is not something
that this working group has already solved. The basic scenario is:
1. Client gets token T1 and posts it to the RS
2. After some time the RS
Hi Daniel,
Rather than answering between the lines, I place a global answer in
front of your message.
Depending upon the content of the JWT, two different collaborative
attacks need to be considered,
one of them being an impersonation attack which can indeed be performed
using Teamviewer.
All,
Please take sometime to complete the survey below to help with the planning
for the coming, most likely virtual, IETF meetings.
Regards,
Rifaat
-- Forwarded message -
From: IETF Executive Director
Date: Mon, May 4, 2020 at 3:04 AM
Subject: Reminder: Survey on planning
10 matches
Mail list logo
