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
- [Ace] draft-ietf-ace-oauth-authz Jim Schaad
- Re: [Ace] draft-ietf-ace-oauth-authz Ludwig Seitz
- Re: [Ace] draft-ietf-ace-oauth-authz Jim Schaad
- Re: [Ace] draft-ietf-ace-oauth-authz Ludwig Seitz
- Re: [Ace] draft-ietf-ace-oauth-authz Jim Schaad
- Re: [Ace] draft-ietf-ace-oauth-authz Ludwig Seitz