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

"Stephen Farrell" <stephen.farrell@cs.tcd.ie> Fri, 24 April 2015 11:52 UTC

Return-Path: <stephen.farrell@cs.tcd.ie>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 218E41A900A; Fri, 24 Apr 2015 04:52:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sc7BL3e5-RS4; Fri, 24 Apr 2015 04:52:07 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B9FA1A902B; Fri, 24 Apr 2015 04:52:05 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: "Stephen Farrell" <stephen.farrell@cs.tcd.ie>
To: "The IESG" <iesg@ietf.org>
X-Test-IDTracker: no
X-IETF-IDTracker: 6.0.1.p1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20150424115205.3265.73381.idtracker@ietfa.amsl.com>
Date: Fri, 24 Apr 2015 04:52:05 -0700
Archived-At: <http://mailarchive.ietf.org/arch/msg/oauth/JxSA4oGEzFiOE-hEMdQH1XhGpJU>
Cc: draft-ietf-oauth-dyn-reg@ietf.org, oauth-chairs@ietf.org, oauth@ietf.org
Subject: [OAUTH-WG] Stephen Farrell's Discuss on draft-ietf-oauth-dyn-reg-28: (with DISCUSS and COMMENT)
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/oauth/>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 24 Apr 2015 11:52:09 -0000

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