There is no specific mechanism right now.
But future developers won’t be able to read the reason why the extension point
is given only for confidential clients.
> On May 14, 2020, at 18:32, Torsten Lodderstedt <tors...@lodderstedt.net>
> wrote:
>
> Are you aware of any suitable mechanism? I’m asking since from my perspective
> this clause is mainly intended to allow existing OpenID Connect deployments
> to use nonce instead of PKCE in combination with OAuth 2.1. It’s a
> compromise. I think we should not encourage others to invent their own OAuth
> security mechanisms.
>
>> On 14. May 2020, at 09:37, Nov Matake <mat...@gmail.com> wrote:
>>
>> Hi,
>>
>> Why not allowing public clients use "other suitable mechanisms” then?
>> OAuth WG can allow both type of clients do so, then OIDF will define nonce
>> as the alternative only for confidential clients.
>>
>>> 2020/05/14 15:56、Torsten Lodderstedt
>>> <torsten=40lodderstedt....@dmarc.ietf.org>のメール:
>>>
>>> Hi all,
>>>
>>> I would also like to thank everybody for the substantial discussion.
>>>
>>> The proposed change for Section 4.1.2.1 works for me (as already stated).
>>> I’m not fully comfortable with the proposed change for Section 9.7 for the
>>> following reasons:
>>>
>>> - The text is weaker than Section 4.1.2.1 since it RECOMMENDS use of PKCE
>>> instead of requiring it (with a well-defined exception).
>>> - Given the latest findings re nonce I don’t feel comfortable with
>>> recommending any mechanism that this WG is not responsible for and thus did
>>> not conduct the security threat analysis for. I think the better way for us
>>> as WG is to define the extension point for other mechanisms. The OpenID
>>> Foundation (or any other body) can then fill in and issue a statement that
>>> nonce (or another suitable mechanism) fulfils the requirements of the
>>> extension point.
>>>
>>> Based on this considerations, I propose the following text for Section 9.7:
>>>
>>> Clients MUST prevent injection (replay) of authorization codes into
>>> the authorization response by attackers. Public clients MUST use the
>>> "code_challenge” with a transaction-specific value that is
>>> securely bound to the client and the user agent in which the
>>> transaction was started. Confidential clients MUST use
>>> the “code_challenge” in the same way or other suitable mechanisms to
>>> mitigate authorization code injection.
>>>
>>> This text follows the logic in Section 4.1.2.1 and allows use of the nonce
>>> for confidential clients.
>>>
>>> best regards,
>>> Torsten.
>>>
>>>> On 12. May 2020, at 02:21, Mike Jones
>>>> <Michael.Jones=40microsoft....@dmarc.ietf.org> wrote:
>>>>
>>>> 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
>>>>
>>>> From: Aaron Parecki <aa...@parecki.com>
>>>> Sent: Monday, May 11, 2020 4:55 PM
>>>> To: OAuth WG <oauth@ietf.org>
>>>> Cc: Neil Madden <neil.mad...@forgerock.com>; Mike Jones
>>>> <michael.jo...@microsoft.com>
>>>> Subject: Re: [OAUTH-WG] proposed resolution for PKCE in OAuth 2.1
>>>>
>>>> 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 RECOMMENDED to this end. For confidential clients, the
>>>> OpenID Connect `nonce` parameter and ID Token Claim {{OpenID}} MAY be used
>>>> instead of or in addition to the `code_challenge` parameter for this
>>>> purpose. The `code_challenge` or OpenID Connect `nonce` value MUST be
>>>> transaction-specific and securely bound to the client and the user agent
>>>> in which the transaction was started.
>>>>
>>>> This change better clarifies the specific circumstances under which the
>>>> "nonce" parameter is sufficient to protect against authorization code
>>>> injection.
>>>>
>>>> Aaron Parecki
>>>>
>>>> On Mon, May 11, 2020 at 11:55 AM Neil Madden <neil.mad...@forgerock.com>
>>>> wrote:
>>>> I am happy with this proposed wording. Thanks for updating it.
>>>>
>>>> — Neil
>>>>
>>>>
>>>> On 11 May 2020, at 19:52, Aaron Parecki <aa...@parecki.com> 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 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 begins with "If the client does not send the "code_challenge" in the
>>>> request..."
>>>>
>>>> "An AS MUST reject requests without a code_challenge from public clients,
>>>> and MUST reject such requests from other clients unless there is
>>>> reasonable assurance that the client mitigates authorization code
>>>> injection in other ways. See section 9.7 for details."
>>>>
>>>> Section 9.7 is where the nuances of PKCE vs nonce are described.
>>>>
>>>> As Neil described, we believe this will allow ASs to support both OAuth
>>>> 2.0 and 2.1 clients simultaneously. The change from Neil's text is the
>>>> clarification of which threats, and changing to MUST instead of SHOULD.
>>>> The "MUST...unless" is more specific than "SHOULD", and since we are
>>>> already describing the explicit exception to the rule, it's more clear as
>>>> a MUST here.
>>>>
>>>> Aaron Parecki
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> OAuth@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> OAuth@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>>
>
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
