Re: [Ace] Working Group Adoption Call for draft-bormann-core-ace-aif

Carsten Bormann <cabo@tzi.org> Fri, 17 July 2020 23:07 UTC

Return-Path: <cabo@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 DD1803A0AC8 for <ace@ietfa.amsl.com>; Fri, 17 Jul 2020 16:07:51 -0700 (PDT)
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 9iP48KiJVyyx for <ace@ietfa.amsl.com>; Fri, 17 Jul 2020 16:07:49 -0700 (PDT)
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 B81F83A0ACB for <ace@ietf.org>; Fri, 17 Jul 2020 16:07:48 -0700 (PDT)
Received: from [192.168.217.116] (p5089ae91.dip0.t-ipconnect.de [80.137.174.145]) (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 4B7mxD2cz1zyNv; Sat, 18 Jul 2020 01:07:44 +0200 (CEST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <20200717222130.GB41010@kduck.mit.edu>
Date: Sat, 18 Jul 2020 01:07:44 +0200
Cc: Jim Schaad <ietf@augustcellars.com>, ace@ietf.org
X-Mao-Original-Outgoing-Id: 616720064.227856-c1d633a13b345f628752f7750c63e063
Content-Transfer-Encoding: quoted-printable
Message-Id: <CD58739A-3D48-429B-B6DD-28FFE23B4E4D@tzi.org>
References: <010101d65ae9$bdffb520$39ff1f60$@augustcellars.com> <20200717222130.GB41010@kduck.mit.edu>
To: Benjamin Kaduk <kaduk@mit.edu>
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/HHvF3cP5vuhxN2QKNSwgc1rKKC0>
Subject: Re: [Ace] Working Group Adoption Call for draft-bormann-core-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, 17 Jul 2020 23:07:52 -0000

On 2020-07-18, at 00:21, Benjamin Kaduk <kaduk@mit.edu> wrote:
> 
> Refreshing my memory of the WG charter, it seems like this can be in scope,
> but we should be sure to consider what analogues already exist in
> non-constrained systems, and whether we are in fact creating something
> generally new and broadly useful.

Good point.

The simplistic model of AIF caters to servers where authorization can be described in terms of static resources (now also resources created from static resources) and CoAP methods that can be performed on them.

CoAP methods can be related to HTTP methods.

But I would expect most big-Web applications to have a more sophisticated authorization model, e.g., based on server-side information (user information in a database etc.).
E.g., an OAuth AS in the big Web wouldn’t say “give C access to these 10537 photos” and list them all, but “give C access to Peter’s photos”.

So I think the design of AIF is a bit specialized to devices where resources mostly correspond to physical traits of those devices that don’t go away or come anew, with action resources (which are now handled with dynamic permissions) maybe an exception.

Grüße, Carsten