Subject: [OAUTH-WG] PKCE & Hybrid Flow

From: Dominick Baier <[email-masked]>
Date: Tue, 26 Jan 2016 21:11:23 +0100

Hi, 

PKCE only mentions OAuth 2.0 code flow - but wouldn’t that also apply to OIDC hybrid flow e.g. code id_token?

— 
cheers
Dominick Baier

---

From: John Bradley <[email-masked]>
Date: Tue, 26 Jan 2016 17:19:46 -0300

Yes it also applies to the “code id_token” response_type.   It would also apply to “code token” , “code token id_token” response types as well though I can’t think of why a native app would use those.

We can look at a errata to clarify.  It is a artifact of resonse_type being treated as a single string as opposed to being space separated values as most people would expect.

John B.

> On Jan 26, 2016, at 5:11 PM, Dominick Baier <[email-masked]> wrote:
> 
> Hi, 
> 
> _______________________________________________
> OAuth mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>

---

From: Nat Sakimura <[email-masked]>
Date: Wed, 27 Jan 2016 02:11:19 +0000

To the end, perhaps amending RFC6749 so that the response type is treated
as a space separated value would be a better way to go?

2016年1月27日(水) 5:20 John Bradley <[email-masked]>:

> Yes it also applies to the “code id_token” response_type.   It would also
> apply to “code token” , “code token id_token” response types as well though
> I can’t think of why a native app would use those.
>
> We can look at a errata to clarify.  It is a artifact of resonse_type
> being treated as a single string as opposed to being space separated values
> as most people would expect.
>
> John B.
>
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>
>
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>

---

From: Dominick Baier <[email-masked]>
Date: Wed, 27 Jan 2016 08:10:28 +0100

Thanks!

we are almost done implementing PKCE in identity server.

And yea - a comment that PKCE applies to whenever a code is involved would be probably helpful for other implementers. Even if that makes total sense, it is not obvious.

— 
cheers
Dominick Baier

On 27 January 2016 at 03:11:28, Nat Sakimura ([email-masked]) wrote:

To the end, perhaps amending RFC6749 so that the response type is treated as a space separated value would be a better way to go? 

John B.

Hi, 

— 
cheers
Dominick Baier

---

From: John Bradley <[email-masked]>
Date: Wed, 27 Jan 2016 09:51:35 -0300

It is confusing that the value is a string that is order independent based on space breaks, rather than a space separated list of responses requested.

Changing it now may be more trouble than it is worth, if it may break deployments.   The editor at the time really didn’t want multiple response types, so that was a way to have them but not really.

John B.

> On Jan 26, 2016, at 11:11 PM, Nat Sakimura <[email-masked]> wrote:
> 
> 2016年1月27日(水) 5:20 John Bradley <[email-masked] <mailto:[email-masked]>>:
>> On Jan 26, 2016, at 5:11 PM, Dominick Baier <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> Hi, 
>>

---

From: Roland Hedberg <[email-masked]>
Date: Wed, 27 Jan 2016 13:58:23 +0100

> 27 jan. 2016 kl. 13:51 skrev John Bradley <[email-masked]>:
> 

Absolutely, I’ve always found that completely broken.

>> On Jan 26, 2016, at 11:11 PM, Nat Sakimura <[email-masked] <mailto:[email-masked]>> wrote:
>>