Thanks for the review, Mike. I've fixed the minor typos. Some other notes
below.
Section 3.1.2.1 currently retains this language from RFC 6749: “The
> redirection endpoint SHOULD require the use of TLS… This specification does
> not mandate the use of TLS because at the time of this writing, requi
We have had several customers express interest in sliding expiration (idle
timeouts) of refresh tokens and push back against rotation, particularly for
mobile apps where they worry that the false positive rate with rotation can be
too high to be practical due to flaky network connections.
Neil
> On 12. Mar 2020, at 23:14, Vittorio Bertocci wrote:
>
> Rotation can be used to detect leakage, right? Client credentials offer more
> guarantees, but unless you are using private JWTs with a non exportable
> certificate as client cred, a classic client secret _could_ technically leak.
> H
> On 12. Mar 2020, at 23:08, Pedro Igor Silva wrote:
>
> I don't but people using our AS. As I mentioned, rotation for such clients
> does not make sense but we had to deal with it.
>
> I just wanted to bring an example of how rotation can't be added without a
> significant impact on develop
Off the top of my head, rotation is useful for 2 things
* reducing the likelihood that an “old” refresh token is still valid (e.g.
“found” on some device, log file, source code etc...)
* being able to revoke all the active refresh tokens if a refresh token is
used twice
...and yes it introduces a
Rotation can be used to detect leakage, right? Client credentials offer
more guarantees, but unless you are using private JWTs with a non
exportable certificate as client cred, a classic client secret _could_
technically leak. Having rotation would alert you if someone got a hold on
those. Admitted
I don't but people using our AS. As I mentioned, rotation for such clients
does not make sense but we had to deal with it.
I just wanted to bring an example of how rotation can't be added without a
significant impact on development and runtime experiences (as mentioned by
Vittorio) if considered f
On Thu, Mar 12, 2020 at 3:03 PM Aaron Parecki wrote:
> > The Security BCP recommends S256.
>
> Is a recommendation enough to change the default?
No.
How would that work in practice anyway? If no code_challenge_method was
present, then you'd need to know which version of OAuth is being used
(ho
I agree that the language around sender constraining refresh tokens and
confidential client could/should be clearer.
I did try and discuss the idea that that such a refresh token is
constrained by virtue of being bound to the client and the client having to
authenticate to use it in
https://www.rfc
> The Security BCP recommends S256.
Is a recommendation enough to change the default? That's definitely
normative changes from PKCE. I could be convinced either way, but it
would be the first place that 2.1 deviates from the combination of the
RFCs and BCPs.
Aaron Parecki
aaronparecki.com
@a
> Am 12.03.2020 um 21:59 schrieb Aaron Parecki :
>
>
>>
>> In regards to `code_challenge_method` parameter in authorization requests..
>> Wouldn't make more sense to have the default value as `S256` based on the
>> statement in Section `4.1.1.2. Client Creates the PKCE Code Challenge` that
> In regards to `code_challenge_method` parameter in authorization requests.
> Wouldn't make more sense to have the default value as `S256` based on the
> statement in Section `4.1.1.2. Client Creates the PKCE Code Challenge` that
> says that `S256` is MTI on the server?
> So you have `plain` a
Then why are you rotating refresh tokens?
> Am 12.03.2020 um 20:48 schrieb Pedro Igor Silva :
>
>
> A confidential client, as per the `web application` definition in Section
> `2.1. Client Types`.
>
>> On Thu, Mar 12, 2020 at 4:39 PM Torsten Lodderstedt
>> wrote:
>> Is that a public clien
A confidential client, as per the `web application` definition in Section
`2.1. Client Types`.
On Thu, Mar 12, 2020 at 4:39 PM Torsten Lodderstedt
wrote:
> Is that a public client?
>
> Am 12.03.2020 um 20:32 schrieb Pedro Igor Silva :
>
>
> I agree with you and recently, we had to deal with a
Is that a public client?
> Am 12.03.2020 um 20:32 schrieb Pedro Igor Silva :
>
>
> I agree with you and recently, we had to deal with an issue where a `web
> application` using rotation (as defined by the draft) was having issues to
> refresh tokens due to multiple concurrent requests at the
I agree with you and recently, we had to deal with an issue where a `web
application` using rotation (as defined by the draft) was having issues to
refresh tokens due to multiple concurrent requests at the moment a token is
about to expire or already expired. We had to add some controls to deal
wit
Hi Aaron,
In regards to `code_challenge_method` parameter in authorization requests.
Wouldn't make more sense to have the default value as `S256` based on the
statement in Section `4.1.1.2. Client Creates the PKCE Code Challenge`
that says that `S256` is MTI on the server?
So you have `plain` as
Thanks for the clarification, Torsten.
I believe it's the first time I see use of client credentials positioned as
sender constraint; if the intent is saying that confidential clients should
use their credentials when redeeming refresh tokens, I am of course in
agreement but I think the language sh
I also am in favor of not requiring "sender constraint" as a MUST.
SHOULD or RECOMMENDED is fine. Many websites are NOT Single-Page-Apps
and as such DPOP doesn't work for those environments. Converting all web
based environments to SPAs so not viable.
Thanks,
George
On 3/12/20 2:28 PM, Vittor
Hi,
sender constraining refresh tokens for confidential client means client
authentication + check the binding of the refresh token with the respective
client id. I don’t think this is new as RFC6759 already required ASs to check
this binding. Assuming backends are generally confidential client
damnit, i hit enter too soon.
Hey guys,
thanks for putting this together.
I am concerned with the real world impact of imposing sender constraint |
rotation as a MUST on refresh tokens in every scenario.
Sender constraint isn't immediately actionable - we just had the discussion
for dPOP, hence I
Hey guys,
thanks for putting this together.
I am concerned with the real world impact of imposing sender constraint |
rotation as a MUST on refresh tokens in every scenario.
Sender constraint isn't immediately actionable - we just had the discussion
for dPOP, hence I won't go in the details here.
R
This looks like a great initial draft, and I hope to see it move forward.
Some comments so far:
Section 1.6:
“At the time of this writing” is duplicated.
Section 3.1.2.1 (and possibly other sections such as 1.6 / 2.3.1 / 3.1 / 3.2
that mandate TLS):
Section 3.1.2.1 currently retains this langu
Hi,
I just read the document and have minor feedback:
Under "2.3 Client Authentication" you mention mTLS (RFC8705) and reference
OpenID.
I am kind of missing RFC7523 here (JWT client authentication). Also, the OpenID
link is broken.
Best
Martin
> On 12. Mar 2020, at 01:28, Aaron Parecki wrot
I'm happy to share that Dick and Torsten and I have published a first
draft of OAuth 2.1. We've taken the feedback from the discussions on
the list and incorporated that into the draft.
https://tools.ietf.org/html/draft-parecki-oauth-v2-1-01
A summary of the differences between this draft and OAu
25 matches
Mail list logo
