Hi Stephen, Thank you very much for your thoughtful comments. My response (after discussing with John) inline:
On Thu, Feb 16, 2017 at 9:20 AM Stephen Farrell <[email protected]> wrote: > 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. > Will do. > > - section 3; WAP? Really? I'm surprised any WAP technology > would still be in use, even on feature-phones. Do you really > need this? > WAP/cHTML and the variation there of. It may not be truly WAP but it would exemplify those. I could have said "limited capaibility browsers" but then that would sound like something akin of mobile browsers on smartphones. > > - 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.) > > Right. The benefit of the flexibility is not big and may not warrant the cost associated with it. > - 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. > Good point. I can think of several attack surfaces such as DoS attack to the authorization server. I could not come up with an attack against the resource owner for the time being though. > > - 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.) > > When I first put in the reference to 29100, I meant to write a fuller write up using it as it would be useful for the orgaanizations implementing ISMS. (Privacy extensions to ISMS are written based on 29100). But I did not. I may just drop the reference as well since collection minimization and disclosure minimization probably is self evident. Best, Nat > > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth > -- Nat Sakimura Chairman of the Board, OpenID Foundation
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
