Re: [Ace] draft-ietf-ace-oauth-authz

Jim Schaad <ietf@augustcellars.com> Tue, 26 February 2019 16:55 UTC

Return-Path: <ietf@augustcellars.com>
X-Original-To: ace@ietfa.amsl.com
Delivered-To: ace@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A2A4130F09; Tue, 26 Feb 2019 08:55:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 wYUOsbujRdEk; Tue, 26 Feb 2019 08:55:02 -0800 (PST)
Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C2350130EEE; Tue, 26 Feb 2019 08:55:01 -0800 (PST)
Received: from Jude (192.168.0.11) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Tue, 26 Feb 2019 08:54:31 -0800
From: Jim Schaad <ietf@augustcellars.com>
To: 'Ludwig Seitz' <ludwig.seitz@ri.se>, draft-ietf-ace-oauth-authz@ietf.org
CC: 'ace' <ace@ietf.org>
References: <000201d4cbd5$d6837900$838a6b00$@augustcellars.com> <a4e42204-df48-f550-7e98-095bdbdd9ff3@ri.se> <00b001d4cd2c$c361f920$4a25eb60$@augustcellars.com> <c0868edf-7914-fb86-6853-3615b608527f@ri.se>
In-Reply-To: <c0868edf-7914-fb86-6853-3615b608527f@ri.se>
Date: Tue, 26 Feb 2019 08:54:27 -0800
Message-ID: <019901d4cdf3$f11aa7f0$d34ff7d0$@augustcellars.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQHtvGpMaQ5ktN+nGoFqPem4h+hCsQLbA0epAa+49AACYB0DAKWJFaJQ
Content-Language: en-us
X-Originating-IP: [192.168.0.11]
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/zlRUQu6uUfE-Dm4J7ViiznCAOpQ>
Subject: Re: [Ace] draft-ietf-ace-oauth-authz
X-BeenThere: ace@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" <ace.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ace>, <mailto:ace-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ace/>
List-Post: <mailto:ace@ietf.org>
List-Help: <mailto:ace-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ace>, <mailto:ace-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 26 Feb 2019 16:55:12 -0000


> -----Original Message-----
> From: Ludwig Seitz <ludwig.seitz@ri.se>
> Sent: Tuesday, February 26, 2019 4:32 AM
> To: Jim Schaad <ietf@augustcellars.com>; draft-ietf-ace-oauth-
> authz@ietf.org
> Cc: 'ace' <ace@ietf.org>
> Subject: Re: draft-ietf-ace-oauth-authz
> 
> On 25/02/2019 18:08, Jim Schaad wrote:
> 
> >>> 3. In section 8.3 - Is/Should there be a requirement that the
> >>> error also be registered in an OAuth registry?  If so then this
> >>> needs to be part of the expert reviewer instructions on this
> >>> registry.
> >>
> >> The expert reviewer instructions already state this:
> >>
> >> "Since a high degree of overlap is expected between these
> >> registries and the contents of the OAuth parameters registries,
> >> experts should require new registrations to maintain a reasonable
> >> level of alignment with parameters from OAuth that have comparable
> >> functionality."
> >>
> >> This includes the error registry, do you think this is
> >> sufficiently clear or should I elaborate?
> >
> > The question I had was the difference between SHOULD and MUST be
> > registered.  The text there says - try and keep them in sync, but if
> > they are not it is not a problem.   If that is what you want then
> > this is not a problem, I was just validating this.
> 
> The intention of the "should require ... a reasonable level of
> alignment" was "try and keep them in sync, but if they are not you need
> a good reason for this".
> 
> Your alternate interpretation makes me think the text is not worded
> strongly enough.

I think that this is basically the same thing.   The only thing that you might want to add is some guidance on what constitutes a good reason.

> 
> >
> >>
> >>>
> >>> 4. In section 8.4 - Is there a reason to require a specification
> >>> for this registry?  Should it be sufficient to have somebody
> >>> request that a mapping be registered and the DE approves it?  The
> >>> previous comment would apply
> >> to
> >>> all of the mapping registries that are just mappings.
> >>>
> >> The idea is to prevent the squatting of low byte count
> >> abbreviations by parameters that are not frequently used, thus
> >> there is a range of different policies for different integer
> >> abbreviation number ranges. (note: I'm following the example of the
> >> CWT specification here)
> >
> > Not requiring a document to exists could still allow this.  IANA
> > would still have the DE approve the assignment.
> >
> 
> Ok so you mean not having "specification required" for -65536 to -257
> and 256 to 65535 and not having "standards action" for -256 to 255 would
> be ok?
> 
> Note that this would be different from the policy in RFC 8392 (CWT).

Yes I understand that this is different from CWT.  When looking at the registries you basically would write a specification which contains the following text:

If, for example , in section 8.4 it was already registered in the OAuth registry, then the document would boil down to:

Please assign a number in the "OAuth Grant Type CBOR Mappings" registry with the following properties:
Name:  grant_type_name
CBOR Value: TBD
Reference: [This document]
Original Specification: [The document for grant_type_name] in the "OAuth Grant Type" registry.

This seems like it is really overkill to have to produce a full specification with of one page when an email to IANA would seem to have the same info.   If you were defining a new grant type, then a full spec would be useful but it would also be expected to do the registration in the "OAuth Grant Type" registry as well as in this registry.

I am not overly worried about getting this resolved at this point as it can be changed later if that makes more sense.

Jim

> 
> /Ludwig
> 
> 
> --
> Ludwig Seitz, PhD
> Security Lab, RISE
> Phone +46(0)70-349 92 51