[Ace] Review on draft-bormann-core-ace-aif-07

Jim Schaad <ietf@augustcellars.com> Mon, 25 May 2020 20:46 UTC

Return-Path: <ietf@augustcellars.com>
X-Original-To: ace@ietfa.amsl.com
Delivered-To: ace@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id B0B363A05A0; Mon, 25 May 2020 13:46:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id JjjBU4zIcT5M; Mon, 25 May 2020 13:46:53 -0700 (PDT)
Received: from mail2.augustcellars.com (augustcellars.com []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C30B43A0484; Mon, 25 May 2020 13:46:49 -0700 (PDT)
Received: from Jude ( by mail2.augustcellars.com ( with Microsoft SMTP Server (TLS) id 15.0.1395.4; Mon, 25 May 2020 13:46:40 -0700
From: Jim Schaad <ietf@augustcellars.com>
To: <draft-bormann-core-ace-aif@ietf.org>
CC: 'Ace Wg' <ace@ietf.org>
Date: Mon, 25 May 2020 13:46:38 -0700
Message-ID: <031c01d632d5$98158ba0$c840a2e0$@augustcellars.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 16.0
Content-Language: en-us
Thread-Index: AdYySg6qaQ1K2nGySeOKYIC/kF1pfw==
X-Originating-IP: []
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/2VX2gLdAzjPs9aSkZmP7ZBK3tsY>
Subject: [Ace] Review on draft-bormann-core-ace-aif-07
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: Mon, 25 May 2020 20:46:55 -0000

* Section 2 - I would like more clarification on the subject as being
derived implicitly from the armor and is a single entity rather than
multiple entities.   If we think that we want to do multiple subjects then
that needs to be discussed.

* Section 2.1 - The model does not current deal with the question of queries
and how they would be permitted for a non-query object.

*  How do we ant to look at doing the generalization for the structure
provided.  There are two things to look at:

1.  The object identifier:  It makes sense for a good many things for this
to be an absolute-path.  However for other things this would be some type of
identifier.  With both the GroupKDC and with MQTT this identifier is a
string.  In the MQTT case the string has defined wild card behavior.  Part
of the question is how much does the object naming scheme need to be
identified to the client, the AS and the RS.  

2.  The permissible actions:  For a coap addressed device, it makes sense
for this to be based on the set of coap verbs and the compressed bit string
makes a great deal of sense.  However for both GroupKDC and MQTT these verbs
are not the same and thus cannot be compressed in the same manner. 

What I would like to see is a structure defined that can be used in a number
of situations, but which the details are going to be very object dependent.

authorization-info = [ * authorization]

authorization = [
   object: object-identifier,
   permissions: [* permission-name] | uint .bits methods

permission-name = tstr

One option would be to allow the methods to be object dependent this means
that you could have  "methods = &( PUBLISH: 0, SUBSCRIBE: 1)" for the MQTT
case.  The advantage of this is that it provides better compressions, but it
also means that one needs to know what the enumeration is for each different
type of object.  I don't know if this means that one needs to start having a
registry to deal with people adding verbs to a particular interface.  I also
don't know what it would mean if they were interface specific and an object
supported two different interfaces.

Section 2 - para 2 s/on object/an object/