Re: [Ace] WGLC for draft-ietf-ace-aif
Olaf Bergmann <bergmann@tzi.org> Fri, 12 February 2021 09:05 UTC
Return-Path: <bergmann@tzi.org>
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 8A1A13A1462;
Fri, 12 Feb 2021 01:05:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.92
X-Spam-Level:
X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5
tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=-0.01,
RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, 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 Dv3scu44UZF7; Fri, 12 Feb 2021 01:05:07 -0800 (PST)
Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de
[134.102.50.17])
(using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))
(No client certificate requested)
by ietfa.amsl.com (Postfix) with ESMTPS id 18EC63A1461;
Fri, 12 Feb 2021 01:05:07 -0800 (PST)
Received: from wangari.tzi.org (p5b36f033.dip0.t-ipconnect.de [91.54.240.51])
(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256
bits)) (No client certificate requested)
by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4DcSJ15T5CzyQH;
Fri, 12 Feb 2021 10:05:05 +0100 (CET)
From: Olaf Bergmann <bergmann@tzi.org>
To: Ace Wg <ace@ietf.org>
Cc: draft-ietf-ace-aif@ietf.org
References: <CADZyTknQ97R+vR-tDcA6ZqCVA5qT-PMmPF44DzhLFzHhj8BU2w@mail.gmail.com>
Date: Fri, 12 Feb 2021 10:05:05 +0100
Message-ID: <87k0rdslku.fsf@wangari>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/Q3VqCFWl3bL3za7T-10nB8gnu90>
Subject: Re: [Ace] WGLC for draft-ietf-ace-aif
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: Fri, 12 Feb 2021 09:05:14 -0000
Hi all, hi Carsten, here is my review for draft-ietf-ace-aif-01. The document is well-written and straight forward. I have only a few minor comments (see below). Grüße Olaf # Abstract/1. Introduction "To transfer detailed authorization information from an authorization manager (such as an ACE-OAuth Authorization Server) to a device, a representation format is needed." Maybe add "compact" before "representation format is needed" to indicate that suitability for constrained devices is an important design goal here. ## 1.1. Terminology Mention that CDDL is used as a formal syntax? # 2. Information Model "For the purposes of this specification, the underlying access control model will be that of an access matrix, which gives a set of permissions for each possible combination of a subject and an object. We do not concern the AIF format with the subject for which the AIF object is issued, focusing the AIF object [...]" Here, the different use of "object" might be confusing (first as one dimension of the access matrix, then as "AIF object", i.e., the serialization of permission+object; in the next paragraph it is again the first meaning of object). Maybe this can be solved by unfolding the abbreviation: "[...] We do not concern the AIF format with the subject for which the Authorization Information is issued, focusing the Authorization Information [...]" Alternatively, these terms could be explained in the terminology section. Also, "AIF format" would double as "Authorization Information Format format". I would not bother, though. In the same sentence: "We do not concern the AIF format with the subject for which the AIF object is issued, focusing the AIF object on a single row [...]" I am not sure if "[...] focusing the AIF object [...]" is really meant here. Another, also valid statement would be "[...] focusing on the AIF object [...]"? ## 2.1 REST-specific model Heading: s/model/Model/ (also for 2.3 Extended REST-specific Model) The first paragraph refers to CoAP which has not been introduced (and motivated). It might be good to note that CoAP is used as an explanatory example here which is motivated by the target devices' constraints. Table 1: To readers who are not familiar with the notion of the "/s" and "/a" prefixes, it might be surprising that the light (sensor) should allow GET only. Maybe "/s/temp" would be more intuitive? (also in Figure 3 and Figure 5) ## 2.2. Limitations In the first sentence: s/e.g. URIs/e.g., URIs/ Second paragraph: s/doesn't/does not/ Last paragraph: s/specific to a subject, e.g. that/specific to a subject, e.g., that/ ## 2.3 Extended REST-specific model First paragraph: s/in a CoAP result/in a CoAP response/ s/rfc5661/RFC5661/ Table 2 is missing a reference in the text. The question that may arise here is how a receiver of an AIF object is supposed to react when it does not support the extended model? Is it safe to simply ignore the Dynamic-* part? (cf. Security Considerations below). # 3. Data Model OLD: "In CDDL [...] a specification of the data model [...] is:" NEW: "In CDDL [...] a specification of the data model [...] is shown in Figure 4." ## 5.2. Registries Table 4 names the reference to the AIF RFC "[RFCthis]" whereas it is "RFC XXXX" in the other subsections of Section 5 (including the note to the RFC Editor). # 6. Security Considerations I think that the question how to deal with AIF that is not understood warrants a short discussion here, e.g., motivating the usual "everything is denied until it is explicitly allowed" should hold here as well.
- [Ace] WGLC for draft-ietf-ace-aif Daniel Migault
- Re: [Ace] WGLC for draft-ietf-ace-aif Olaf Bergmann
- Re: [Ace] WGLC for draft-ietf-ace-aif Daniel Migault
- Re: [Ace] WGLC for draft-ietf-ace-aif Marco Tiloca
- Re: [Ace] WGLC for draft-ietf-ace-aif Carsten Bormann
- Re: [Ace] WGLC for draft-ietf-ace-aif Marco Tiloca