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 think we need to change wording. Sender constraining for confidential client
and refresh tokens does not require any signature. It’s client authentication +
checking the client id matches. I don’t see an issue with this.
> Am 12.03.2020 um 19:36 schrieb Mike Jones
> :
>
>
> +1 on sender co
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
+1 on sender constraints being RECOMMENDED but not REQUIRED. Different
applications have different risk profiles. We should enable people to make
reasonable choices for their use cases.
Remember that OAuth 1.0 was rejected by the marketplace because implementing
the sender-constraint mechanis
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
Sorry for the delay here.
>From the formal perspective, Torsten's language works for me as well.
Thanks for taking the feedback into account.
I still worry that without an explicit reference to OIDC
implicit+form_post, I will have the conversation "but can we still do this
in OIDC now that implici
I'm a +1 for adding client_id back as well
On 3/12/20 11:31 AM, Brian Campbell wrote:
+1 (again) that `client_id` should be allowed/required as a query parameter
outside the request object JWT or URI and that its value has to be the same
as within the request object.
On Thu, Mar 12, 2020 at 8:2
So looks like a refresh token is allowed for this endpoint.
>> > > >>
>> > > >>
>> > > >> Bill Jung
>> > > >> Manager, Response Engineering
>> > > >> bj...@pingidentity.com
>> > > >> w: +1 60
gt; > On Mar 1, 2020, at 10:11 PM, Andrii Deinega
> > wrote:
> > >
> > > How would the authorization server know who actually uses the
> > > introspection endpoint assuming that a protected resource and a client
> > &g
+1 (again) that `client_id` should be allowed/required as a query parameter
outside the request object JWT or URI and that its value has to be the same
as within the request object.
On Thu, Mar 12, 2020 at 8:20 AM Joseph Heenan wrote:
> I agree with that too.
>
> Joseph
>
> On 12 Mar 2020, at 14
Yes, that sounds good to me.
Best,
Filip
On Tue, 25 Feb 2020 at 03:18, Nat Sakimura wrote:
> So, where should we take it to?
> Just add back client_id as it used to be?
>
> On Fri, Jan 24, 2020 at 6:55 AM John Bradley wrote:
>
>>
>> -- Forwarded message -
>> From: John Bradley
Please unsubscribe me from your mailing list
Isaac O.Ajonibode
C.Director CBMC Nigeria
cbmcnigeria2...@gmail.com
www.cbmcint.com/Nigeria
+2347087552127
FOUNDER/CEO
AJOFOLU VENTURES INT'L LTD
ajofoluventu...@gmail.com
+2348164286235
2 Corinthians 5:20
On Mon, 2 Mar 2020, 06:33 , wrote:
> Send
I agree with that too.
Joseph
> On 12 Mar 2020, at 14:18, Mike Jones
> wrote:
>
> I agree that we should restore the client_id functionality. Thanks for
> moving this forward!
>
>-- Mike
>
> From: OAuth mailto:oauth-boun...@ietf.org
I agree that we should restore the client_id functionality. Thanks for moving
this forward!
-- Mike
From: OAuth On Behalf Of Nat Sakimura
Sent: Monday, February 24, 2020 6:18 PM
To: John Bradley
Cc: oauth
Subject: Re: [OAUTH-WG] Fwd: [EX
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 Peter,
thanks, this is fixed in the (yet unpublished) version of the Security BCP.
-Daniel
Am 12.03.20 um 14:35 schrieb Pieter Philippaerts:
> Hi everyone,
>
> I hope this is the right mailing list to submit mistakes in the OAuth
> specifications...
>
> I was reading through the latest versio
Hi everyone,
I hope this is the right mailing list to submit mistakes in the OAuth
specifications...
I was reading through the latest version of the OAuth 2.0 Security Best Current
Practice (version 14) and noticed a very small error. Section 2.1.1 reads: "To
this end, they MUST either (a) pub
31 matches
Mail list logo
