Re: [OAUTH-WG] OAuth 2.1 - require PKCE?

From working with a lot of developers on understanding OAuth 2.0 and OIDC, I definitely vote for simplicity. Understanding the subtle nuances of when a nonce is fine and when PKCE should be used is impossible without in-depth knowledge of the flows and their properties. Misunderstandings will

Re: [OAUTH-WG] [JWT Profile for OAuth 2.0 Access Tokens] Adding state into the JWT

Thanks Vittorio for your thoughts! On Thu, May 7, 2020 at 1:29 PM Vittorio Bertocci wrote: > Hi Prabath, > > Thanks for your comment! Here are my thoughts. > > I don’t believe embedding the state in the AT would help. The state is > generated (hence verified, if used for protection) by the

Re: [OAUTH-WG] OAuth 2.1 - require PKCE?

Aaron, I believe you’re trying to optimize the wrong thing. You’re concerned about “the amount of explanation this will take”. That’s optimizing for spec simplicity – a goal that I do understand. However, by writing these few sentences or paragraphs, we’ll make it clear to developers that

Re: [OAUTH-WG] OAuth 2.1 - require PKCE?

Backing up a step or two, there's another point here that I think has been missed in these discussions. PKCE solves two problems: stolen authorization codes for public clients, and authorization code injection for all clients. We've only been talking about authorization code injection on the list

Re: [OAUTH-WG] [JWT Profile for OAuth 2.0 Access Tokens] Adding state into the JWT

Hi Prabath, Thanks for your comment! Here are my thoughts. I don’t believe embedding the state in the AT would help. The state is generated (hence verified, if used for protection) by the client, but the content of the AT is really meant for the RS, which has no direct knowledge of what the

[OAUTH-WG] [JWT Profile for OAuth 2.0 Access Tokens] Adding state into the JWT

Hi all, Can we say in [1], that the AS should add the value of *state* parameter from the authorization request (if present), to the JWT access token it generates? This will help to address token injection issue [2], with respect to the implicit grant type. Appreciate your thoughts on this.

Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-security-topics-15.txt

Hi Denis, Am 07.05.20 um 14:46 schrieb Denis: > (...) > > A new definition for the term client should be adopted for this > document.  However, you are right, the two wordings shall remain. > I cannot follow any of this, sorry. >>> >>> 3) The "_Updated _OAuth 2.0 Attacker Model" is supposed to

[OAUTH-WG] draft-ietf-oauth-jwsreq-21

Perhaps quite late, but a few comments/questions related to this: 1) When decoded, all the JWT samples are missing the "typ" claim from the header, which I think should be "oauth.authz.req+jwt". 2) When validating the JAR if we are to validate the "typ" then this would be incompatible with

Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-security-topics-15.txt

Hi Daniel, Hi Denis, Am 05.05.20 um 17:19 schrieb Denis: 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

Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-security-topics-15.txt

Hi Denis, Am 05.05.20 um 17:19 schrieb Denis: > 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