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 <sakim...@gmail.com> 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? > > 2016年1月27日(水) 5:20 John Bradley <ve7...@ve7jtb.com > <mailto:ve7...@ve7jtb.com>>: > 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 <dba...@leastprivilege.com >> <mailto:dba...@leastprivilege.com>> wrote: >> >> 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 >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org <mailto:OAuth@ietf.org> >> https://www.ietf.org/mailman/listinfo/oauth >> <https://www.ietf.org/mailman/listinfo/oauth> > _______________________________________________ > OAuth mailing list > OAuth@ietf.org <mailto:OAuth@ietf.org> > https://www.ietf.org/mailman/listinfo/oauth > <https://www.ietf.org/mailman/listinfo/oauth>
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
