Do you know of anyone currently doing this today in an OAuth-only application?
If the group wanted to take some existing OIDC mechanisms and apply them to OAuth, I feel like that needs to happen in a separate RFC, and that's a much bigger discussion. This BCP shouldn't really be defining new behavior. It's similar to how "OAuth 2.0 for Mobile and Native Apps" is not where PKCE is defined, PKCE has its own RFC. - Aaron On Sat, Dec 8, 2018 at 10:33 AM Brock Allen <brockal...@gmail.com> wrote: > For the same reason the implicit flow uses it -- to reduce exposure of the > response params. I know the code is protected with the code_verifier, but > it wouldn't hurt to reduce its exposure, no? > > -Brock > > On 12/8/2018 1:23:41 PM, Aaron Parecki <aa...@parecki.com> wrote: > What would be the benefit of using this response type? Are you aware of > any OAuth (not OIDC) clients that do this today? > > - Aaron > > > On Sat, Dec 8, 2018 at 7:29 AM Brock Allen <brockal...@gmail.com> wrote: > >> Should the BCP suggest using OIDC's response_type=fragment as the >> mechanism for returning the code from the AS? Or simply suggest using the >> fragment component of the redirect_uri for the code, without a >> response_type parameter (IOW don't allow it to be dynamic)? >> >> -Brock >> >> _______________________________________________ >> 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
