Re: [Ace] WGLC for draft-ietf-ace-aif

Carsten Bormann <> Wed, 17 February 2021 19:56 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 802903A1CF0 for <>; Wed, 17 Feb 2021 11:56:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 5IoVB6cghG29 for <>; Wed, 17 Feb 2021 11:56:12 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C25183A1CEF for <>; Wed, 17 Feb 2021 11:56:11 -0800 (PST)
Received: from [] ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 4DgpVx2lB4zybx; Wed, 17 Feb 2021 20:56:09 +0100 (CET)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.\))
From: Carsten Bormann <>
In-Reply-To: <>
Date: Wed, 17 Feb 2021 20:56:08 +0100
Cc: Olaf Bergmann <>, Ace Wg <>
X-Mao-Original-Outgoing-Id: 635284568.878776-69f897f7dfd60fe2c47ae5bb48588176
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <>
To: Marco Tiloca <>
X-Mailer: Apple Mail (2.3608.
Archived-At: <>
Subject: Re: [Ace] WGLC for draft-ietf-ace-aif
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 17 Feb 2021 19:56:14 -0000

Olaf and Marco (and Alexey over on the media-types mailing list),
Thank you for your comments.

I have submitted an updated version that should address these comments.
Please do have a quick look.

A few comments on the comments:

Re Marco’s comments:

> * s/Constrained Devices/Constrained devices

I stuck with the capitalization as these are terms of art.
(I added a reference to RFC 7228 for the definitions of the terms.)

> * I wonder if the following section renumbering is good to do.
> - 2.1 --> 3
> - 2.2 --> 3.1
> - 2.3 --> 4
> - 3   --> 5
> - 4   --> 6
> - etc.

We did a big renumbering to arrive at the current structure (which I find quite logical); we used to have something that was closer to what you suggest.
I think it is important to separate information model and data model, hence the current structure.

> [Section 2]
> * I think it's worth mentioning examples of relevant "data structures" and "cryptographic armors". Especially thinking of the ACE framework, the capability list would be specified by the 'scope' of an protected Access Token.

I couldn’t quite act on that.  Suggestions?

>    Can this actually be the case? At least for ACE, the AS is assumed to know the scopes that the RS supports [1]. I read this as intended to cover also the scope formats and data models used to express them. So, the AS would not issue a Token with a scope that the RS does not understand in the first place.
> [1]

I didn’t discuss this, but added text to the security considerations — I believe implementations need to be able to cope with unexpected input, even if there is trust in an implementation that should not supply such.

> * In Section 5.1, some fields from [4] are missing in the registrations.

Yes, Alexey also pointed this out.
(My standard technique is to copy the template from somewhere else, and that failed here :-)

And re Olaf’s comments:

> # 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 [...]"

I found it simpler to just say “AIF data item”.

> Also, "AIF format" would double as "Authorization Information Format
> format". I would not bother, though.

Indeed, “a foolish consistency…”

> s/rfc5661/RFC5661/

Only once I fixed this, idnits warned me that this is obsolete :-)
Saying RFC8881 now.

Thank you!

I hope we can do another round before the I-D deadline.

Grüße, Carsten