[OAUTH-WG] Stephen Farrell's No Objection on

Nat Sakimura

2017-02-18 20:23:18 UTC

Hi Stephen,

Thank you very much for your thoughtful comments.

Post by Stephen Farrell
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.
https://datatracker.ietf.org/doc/draft-ietf-oauth-jwsreq/
----------------------------------------------------------------------
----------------------------------------------------------------------
- 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.

Post by Stephen Farrell
- 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.

Post by Stephen Farrell
- 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.

Post by Stephen Farrell
- 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.

Post by Stephen Farrell
- 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

Post by Stephen Farrell
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth

--
Nat Sakimura

Chairman of the Board, OpenID Foundation