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

From: Daniel Migault <[email-masked]>
Date: Thu, 11 Feb 2021 11:18:08 -0500

Hi,

As discussed during the meeting, this email starts a WGLC for the document
draft-ietf-ace-aif. The WGLC ends on March 25, so please provide your feed
backs, comments reviews.

The document is available here:
https://datatracker.ietf.org/doc/draft-ietf-ace-aif/

Yours,
Daniel

-- 
Daniel Migault
Ericsson

---

From: Olaf Bergmann <[email-masked]>
Date: Fri, 12 Feb 2021 10:05:05 +0100

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.

---

From: Daniel Migault <[email-masked]>
Date: Fri, 12 Feb 2021 09:53:19 -0500

Thanks for the review Olaf.

Yours,
Daniel

On Fri, Feb 12, 2021 at 4:05 AM Olaf Bergmann <[email-masked]> wrote:

> _______________________________________________
> Ace mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ace
>

-- 
Daniel Migault
Ericsson

---

From: Marco Tiloca <[email-masked]>
Date: Wed, 17 Feb 2021 18:24:32 +0100

Hi all,

Please, find below my WGLC review for draft-ietf-ace-aif-01.

Thanks for this good and useful document!

Best,
/Marco

[General]

* The document header should mention the ACE Working Group

* s/Constrained Devices/Constrained devices

* 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.

[Abstract and Section 1]

* Just to cover also the extended REST-specific model, the last sentence
can be expanded as "... that describes REST (dynamically created)
resource and the permissions on them."

[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.

* s/of a such a/of such a

* s/doesn't/does not

* s/isn't locked/is not locked

* s/in a CoAP result/in a CoAP response

* "... created itself by previous operations (PUT, POST)" should also
include PATCH, which would possibly require an inline reference to RFC 8132.

* Is it correct to say that the extended REST-specific model inherits
the same limitations of the simple REST-specific model, except for the
last one? Are there more new limitations for the extended model, as
inherent to the targeted dynamic resources?

* If a request targets a dynamically created resource complying with the
Dynamic-X granted permissions, should the server return 4.01
(Unauthorized) in case it does not understand the extended REST-specific
model?

   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] https://tools.ietf.org/html/draft-ietf-ace-oauth-authz-37#appendix-D

[Section 3]

* I suggest that the first sentence on the "generic information model"
also refers to Section 2, while the following paragraph refers to
Sections 2.1 and 2.3.

   This would confirm that having Toid as a local URI is something done
for the REST and extended REST models, while other data models can use
the text string in other ways- For instance, they specify group names in
the ace-key-groupcomm-* documents [2][3].

[2] https://datatracker.ietf.org/doc/draft-ietf-ace-key-groupcomm/
[3] https://datatracker.ietf.org/doc/draft-ietf-ace-key-groupcomm-oscore/

[Section 5]

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

* In Section 5.2, just for consistency, s/[RFCthis]/RFC XXXX

[4] https://tools.ietf.org/html/rfc6838#section-5.6

On 2021-02-11 17:18, Daniel Migault wrote:
> Hi, 
>
> As discussed during the meeting, this email starts a WGLC for the
> document draft-ietf-ace-aif. The WGLC ends on March 25, so please
> provide your feed backs, comments reviews. 
>
> <https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-ace-aif%2F&data=04%7C01%7Cmarco.tiloca%40ri.se%7Cd0a9cc9cc3cd46f539da08d8cea8ae4e%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637486571578132165%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0&sdata=MiHnQPXV1WI0B1Jrk3ItSnjFd%2FMkIseYzoe85qoAoY8%3D&reserved=0>
>
> Yours, 
> Daniel
>
> -- 
> Daniel Migault
> Ericsson
>

-- 
Marco Tiloca
Ph.D., Senior Researcher

RISE Research Institutes of Sweden
Division ICT
Isafjordsgatan 22 / Kistagången 16
SE-164 40 Kista (Sweden)

Phone: +46 (0)70 60 46 501
https://www.ri.se

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 17 Feb 2021 20:56:08 +0100

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:

> * 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.

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.
> 

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 :-)

>  the Authorization Information is issued, focusing the Authorization

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

> 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

---

From: Marco Tiloca <[email-masked]>
Date: Wed, 17 Feb 2021 22:46:56 +0100

Hi Carsten,

Thanks for the swift revision, it looks good!

On the open point:

On 2021-02-17 20:56, Carsten Bormann wrote:

~snip~

> I couldn’t quite act on that.  Suggestions?

==>MT
It can be just fine to mention CWTs as "data structure" and default
choice for ACE, using COSE as "cryptographic armor".

Best,
/Marco
<==

>> [1] https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-ace-oauth-authz-37%23appendix-D&amp;data=04%7C01%7Cmarco.tiloca%40ri.se%7C38b1f9b1e3074a1bc65908d8d37e128f%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637491885720799437%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=amkcQPgZ7sNsoHoFBRbn%2FkJiDEEteRWq6kGWo%2Ba34nM%3D&amp;reserved=0

-- 
Marco Tiloca
Ph.D., Senior Researcher