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

From: "Stephen Farrell" <[email-masked]>
Date: Wed, 15 Feb 2017 16:20:40 -0800

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.)

---

From: Nat Sakimura <[email-masked]>
Date: Sat, 18 Feb 2017 20:23:18 +0000

Hi Stephen,

Thank you very much for your thoughtful comments.
My response (after discussing with John) inline:

> https://datatracker.ietf.org/doc/draft-ietf-oauth-jwsreq/

Will do.

> would still be in use, even on feature-phones. Do you really

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.

> Right.
The benefit of the flexibility is not big and may not warrant the cost
associated with it.

> attacks (to be assisted by an innocent browser) against some

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.

> 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-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>
-- 

Nat Sakimura

Chairman of the Board, OpenID Foundation