On Fri, Apr 24, 2020 at 5:48 PM Aaron Parecki <aa...@parecki.com> wrote:
> Thanks for the detailed review Brian! I've made many of these edits to the > draft, but there are still a few things that need some discussion on the > list. My notes are inline below. > Thanks Aaron. I realize there was a lot there. I've followed up on just a couple of the things below that seemed like they needed a response. > >> https://tools.ietf.org/html/draft-parecki-oauth-v2-1-01#section-6 >> " * _Sender-constrained refresh tokens:_ the authorization server >> cryptographically binds the refresh token to a certain client >> instance by utilizing [I-D.ietf-oauth-token-binding] or [RFC8705]." >> Given the relative immaturity of ways to do this, maybe something more >> open ended would be appropriate? This reads like token-binding or MTLS are >> the only ways allowed. I'd think wording that would allow for DPoP or some >> yet-to-be-defined method would be better here. Also maybe drop the >> token-binding reference all together (it's long expired and doesn't look >> like that's gonna change). >> > > I'm generally supportive of something more open ended here. Would that > also suggest that the corresponding text in the Security BCP be updated as > well? > For some reason, I'd been thinking that this stuff had been changed in the Security draft. But I was apparently mistaken. Anyway, yes, I think it should be updated there as well. > >> https://tools.ietf.org/html/draft-parecki-oauth-v2-1-01#section-9.7 >> <https://tools.ietf.org/html/draft-parecki-oauth-v2-1-01#section-9..7> >> "Attacker A4 in (#secmodel)" >> "The use of PKCE is RECOMMENDED to this end." >> PKCE is required elsewhere so this doesn't seem quite right. Similar >> comments about text ijn >> https://tools.ietf.org/html/draft-parecki-oauth-v2-1-01#section-9.14 >> that talks as though PKCE might not be there. >> > > I believe this text was included since an extension such as OpenID Connect > can define other methods of authorization code injection. Also note that > this same sentence is in the Security BCP so if we update anything here > they should probably match. > I guess my understanding of the intended scope of the two documents was that they were a little different. Like there's a security profile that describes a few different ways of achieving something with the tools of 2.0, OIDC and PKCE. While 2.1 is saying PKCE is always required and there are benefits to that. So the latter doesn't seem to need conditional language around PKCE or alternatives. Maybe my understanding is flawed though. Or maybe there's a larger question here about the value/need/cost of having a lot of duplicative or overlapping content across multiple documents. -- _CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited. If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you._
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
