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

[Nat Sakimura <[e-mail]>]

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

Nat Sakimura

Chairman of the Board, OpenID Foundation