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

[Marco Tiloca <[e-mail]>]

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. 
>
> The document is available here:
> https://datatracker.ietf.org/doc/draft-ietf-ace-aif/
> <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
>
> _______________________________________________
> Ace mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ace

-- 
Marco Tiloca
Ph.D., Senior Researcher

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

Phone: [phone]
https://www.ri.se