[OAUTH-WG] Stephen Farrell's No Objection on draft-ietf-oauth-jwsreq-12: (with COMMENT)

["Stephen Farrell" <[e-mail]>]

Stephen Farrell has entered the following ballot position for
draft-ietf-oauth-jwsreq-12: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-oauth-jwsreq/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------


- intro: "attacks... have been identified." yells out for a
reference - it'd be a good bit better if implementers could
easily find details of some such attacks, so I hope you add
some refs here.

- section 3; WAP? Really? I'm surprised any WAP technology
would still be in use, even on feature-phones. Do you really
need this?

- section 4: I think it will turn out to be an error to allow
for mixing query parameters and protected parameters (in a
Request Object) in a single request. Do you really need that
level of flexibility? It'd be simpler and less likely to be
attackable to insist that all parameters be in the Request
Object if one is used. (See also section 11.2.1 below.)

- section 10: Is there nothing to be said about the new
indirection caused by the request_uri? I'd have thought there
were some corner cases that'd warrant a mention, e.g. if some
kind of deadlock or looping could happen, or if one client (in
OAuth terms) could use a request_uri value as a way to attempt
attacks (to be assisted by an innocent browser) against some
resource owner.

- section 11: thanks for that, it's good.

- section 11: Saying that an ISO thing is "good to follow" is
quite weak IMO. (And is that ISO spec accessible? Hmm...  it
seems that one needs to accept cookies to get it which is
wonderfully ironic;-) If the authors have the energy, I'd
suggest trying to find better guidance that's more publically
available in a privacy-friendly manner. (Or just drop the ISO
reference if 6973 is good enough.)