It’s not really an interop issue either, given that following or not following
this requirement doesn’t alter the shape of messages or tokens. It’s more of an
architectural requirement, which preserves the relationships between the OAuth2
roles involved and prevents the confusion that might
> In the password grant flow, the device holds the password and is not
involved in any interaction with the AS. This keeps the device use case
simple.
I'm not sure what you mean by this. If you're suggesting that the client
never interacts with the AS and sends the password directly to the
Hi Vittorio,
Yeah, this does make a bit of sense. So, the goal is to guide implementors from
making bad choices, not from a security perspective. Meaning, it's not a
security risk that a client does inspect or analyze the token. Instead, it's is
an interop issue and thus we are guiding
I am against OAuth 2.1 discarding the use of ROPC (Resource Owner Password
Credentials) with the following reasoning:
Auth Code Grant:
There are many use cases on the market where redirection based flows do
not work. As we see in the "OAuth 2.1 - require PKCE?" thread, the
complexity of user
Hi Aaron,
>
>
> Hi Beena,
>
> This sounds like a great use of the client credentials grant. The password
> grant is being removed from OAuth 2.0 by the Security Best Current
> Practice. Can you clarify what you've found useful about the password grant
> that the client credentials grant doesn't
Hi John,
I noticed this individual draft expired a little over a year ago. Do you
have any intention of picking up this work again?
https://tools.ietf.org/html/draft-bradley-oauth-jwt-encoded-state-09
Thanks!
Aaron Parecki
___
OAuth mailing list
Thank you Jared for your comment!
I have to admit I have been very tempted to go that route, mostly for moving
things forward, but I still think we’d do the reader a disservice by relaxing
the language there.
Real world scenarios are full of situations where additional assumptions can
lower
That works for me. Thanks all for the useful back-and-forth that got us to
this point of clarity. I suspect many of us learned things along the way; I
know that I did!
Cheers,
-- Mike
Thank you Neil.
To address Mike's concerns in the previous threads, I would like to also
update section 9.7 with the following text:
Clients MUST prevent injection (replay) of authorization codes into the
authorization response by attackers. The use of the `code_challenge`
parameter is
Torsten,
Thanks. I just updated the draft.
Best,
Nat Sakimura
On Sun, May 10, 2020 at 10:26 PM Torsten Lodderstedt wrote:
> I just read over the diff between -21 and -22 and realised the example in
> Section 5.2.2.
>
> https://server.example.com/authorize?
>
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Web Authorization Protocol WG of the IETF.
Title : The OAuth 2.0 Authorization Framework: JWT Secured
Authorization Request (JAR)
Authors : Nat
I am happy with this proposed wording. Thanks for updating it.
— Neil
> On 11 May 2020, at 19:52, Aaron Parecki wrote:
>
> Thanks for the lively discussion around PKCE in OAuth 2.1 everyone!
>
> We would like to propose the following text, which is a slight variation from
> the text Neil
Thanks for the lively discussion around PKCE in OAuth 2.1 everyone!
We would like to propose the following text, which is a slight variation
from the text Neil proposed. This would replace the paragraph in 4.1.2.1 (
https://tools.ietf.org/html/draft-parecki-oauth-v2-1-02#section-4.1.2.1)
that
I suspect it was an unintentional oversight in the Security BCP and that it
should be updated to allow for it.
On Mon, May 11, 2020 at 10:03 AM Aaron Parecki wrote:
> The Security BCP has pretty clear language around requiring exact matching
> of redirect URIs now.
>
>
>
The Security BCP has pretty clear language around requiring exact matching
of redirect URIs now.
https://tools.ietf.org/html/draft-ietf-oauth-security-topics-15#section-2.1
However the Native Apps BCP has an exception for localhost URIs to allow
variable ports.
If I may, step in and offer a suggestion.
What if instead of "MUST NOT" replace with "SHOULD NOT"?
To me, (and this might be me), but MUST NOT describes a violation. As in I
broke the law. Conversely, I interpret, "SHOULD NOT" as a recommendation, a
guideline, best practice, etc.
If then the
Hi Benjamin,
We are making progress since we now understand better each other. You
wrote several sentences on which I agree:
"I do in fact agree that token inspection by a client can be useful
in at least some situations".
"I fully support having privacy considerations sections that
All,
I have a new email address *rifaat.s.i...@gmail.com
* to replace the old address rifaat.i...@gmail.com.
I did that because some spammers have been sending spam email and
pretending that they are using my old email address as the sender, and as a
result I would get angry replies from the
> On 11. May 2020, at 10:59, Neil Madden wrote:
>
>
>
>> On 11 May 2020, at 08:53, Torsten Lodderstedt
>> wrote:
>>
>>
>>
>>> On 11. May 2020, at 09:34, Neil Madden wrote:
>>>
>>>
>>>
On 11 May 2020, at 08:05, Torsten Lodderstedt
wrote:
>> On 11.
> On 11 May 2020, at 08:53, Torsten Lodderstedt wrote:
>
>
>
>> On 11. May 2020, at 09:34, Neil Madden wrote:
>>
>>
>>
>>> On 11 May 2020, at 08:05, Torsten Lodderstedt
>>> wrote:
>>>
>>>
>>>
> On 11. May 2020, at 08:47, Neil Madden wrote:
>
>
>
>> On 11 May
Would be also interested in the official language here.
Would an implementation need to introduce an optional “strict JAR
validation mode” - which complies with JAR, but breaks OIDC compatibility?
———
Dominick Baier
On 7. May 2020 at 15:32:33, Brock Allen (brockal...@gmail.com) wrote:
> On 11. May 2020, at 09:34, Neil Madden wrote:
>
>
>
>> On 11 May 2020, at 08:05, Torsten Lodderstedt
>> wrote:
>>
>>
>>
On 11. May 2020, at 08:47, Neil Madden wrote:
> On 11 May 2020, at 07:41, Torsten Lodderstedt
> wrote:
> On 11. May
> On 11 May 2020, at 08:05, Torsten Lodderstedt wrote:
>
>
>
>>> On 11. May 2020, at 08:47, Neil Madden wrote:
>>>
>>>
>>>
On 11 May 2020, at 07:41, Torsten Lodderstedt
wrote:
>>>
On 11. May 2020, at 07:38, Neil Madden wrote:
There is no attack that this
In IdentityServer, the PKCE requirement is per client.
We started with a default of false - and now switched to true.
FWIW
———
Dominick Baier
On 10. May 2020 at 22:22:35, Mike Jones (
michael.jones=40microsoft@dmarc.ietf.org) wrote:
Exactly!
I believe that this also the same point that
> On 11. May 2020, at 08:47, Neil Madden wrote:
>
>
>
>> On 11 May 2020, at 07:41, Torsten Lodderstedt
>> wrote:
>>
>>> On 11. May 2020, at 07:38, Neil Madden wrote:
>>>
>>> There is no attack that this prevents so your claim of improving security
>>> is unsubstantiated. I can’t see
> On 11 May 2020, at 07:41, Torsten Lodderstedt wrote:
>
>> On 11. May 2020, at 07:38, Neil Madden wrote:
>>
>> There is no attack that this prevents so your claim of improving security is
>> unsubstantiated. I can’t see how we can ship a 2.1-compliant-by-default AS
>> while this
> On 10. May 2020, at 21:02, Mike Jones wrote:
>
> > Did I got it right that nonce does not protect public clients from code
> > theft/replay?
>
> I believe that the OpenID Connect Code Hash (“c_hash”) claim protects against
> this.
c_hash is designed to prevent injection at a legit
> On 11. May 2020, at 07:38, Neil Madden wrote:
>
> There is no attack that this prevents so your claim of improving security is
> unsubstantiated. I can’t see how we can ship a 2.1-compliant-by-default AS
> while this requirement remains so I don’t support it.
Are you saying PKCE does not
28 matches
Mail list logo
