Re: [OAUTH-WG] Stephen Farrell's Discuss on draft-ietf-oauth-dyn-reg-28: (with DISCUSS and COMMENT)

[Justin Richer <[e-mail]>]

> I do wonder
> though if you ought also say a bit about, or point at a
> reference describing, the possible bad outcomes if
> one of these URLs  goes bad. The new text I think
> assumes that the developer will get how bad that can
> be, but I'm not sure if they would or not.

It can get as bad as the web, which is pretty bad, but I hope we don't 
have to point that out in great detail in every RFC that deals with the 
web. :) I think the drive-by-download malware example is a good one, and 
we could add another concrete one if you've got an idea, but I think the 
advice we have is sound and actionable and we should avoid having this 
spec be a catalogue of "bad things what can happen on the web". If there 
is such a reference, I'm happy to point to it!

  -- Justin

On 4/24/2015 7:52 AM, Stephen Farrell wrote:
> Stephen Farrell has entered the following ballot position for
> draft-ietf-oauth-dyn-reg-28: Discuss
>
> 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 http://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:
> http://datatracker.ietf.org/doc/draft-ietf-oauth-dyn-reg/
>
>
>
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
>
> (1) cleared
>
> (2) If the response (defined in 3.2.1) includes metadata that
> the server has altered, but that the client doesn't like, then
> what does the client do? (It may be that that's ok, but I'm
> not following why that is the case.) I'm also not sure the
> "https" requirement (1st bullet in section 5) is useful there.
>
> We had some mail discussion on this but I'd like to
> continue that a bit more to understand if the changes
> in -28 address the issue. I'll send mail.
>
> (3) cleared
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
>
> My previous DISCUSS point (1) is below. That has been
> handled via new text in section 5 (on p27). I do wonder
> though if you ought also say a bit about, or point at a
> reference describing, the possible bad outcomes if
> one of these URLs  goes bad. The new text I think
> assumes that the developer will get how bad that can
> be, but I'm not sure if they would or not.
>
> (1) General: there are many URIs sent to the AS from the
> client here. Nothing prevents the client messing about with
> the content served from those later, after registration. What
> mechanism holds clients accountable for such misbehaviours?
> (Examples, logo_uri, tos_uri, policy_uri, jwks_uri) Section 5
> does say that the AS "SHOULD check" but does not say what
> "checking" means, nor what to do if the check fails.  I think
> a bit more security considerations-like text here, reflecting
> what is (or ought;-) actually be done would be good. Do you
> agree?
>
>
> --- OLD COMMENTS, I didn't check if they'd been handled
>
> - s2, software_version: what is the impact if the s/w is
> updated twice a day, every day?
>
> - 3.2.1 - why is the response status 201? That may be correct,
> but seems to subtle if so to only state in an exmaple.
>
> - s5, last para - "be very particular" is not good spec
> language - what do you actually mean that can be implemented?
>
> - thanks for section 6 - it's great to see thought being
> devoted to these issues.
>
> - Did the secdir review [1] get a response? And I think I
> quite agree with Charlie's point#2 about versions.
>
>     [1] https://www.ietf.org/mail-archive/web/secdir/current/msg05519.html
>
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth