Re: [Ace] WGLC draft-ietf-ace-revoked-token-notification-04.txt

[Rikard Höglund <[e-mail]>]

Hello.

Please find my review of draft-ietf-ace-revoked-token-notification-04 below.

Best
Rikard Höglund


[Abstract]

*"with the possible additional use of resource observation for the Constrained Application Protocol (CoAP)"

Seems to me that CoAP is mentioned quite late here. Not only the observations, but the whole functionality of this draft is based on CoAP messages. Same comment is applicable to the introduction.


[Section 1.1]

*What is the difference between "TRL resource" and "TRL endpoint"? Earlier in the terminology it says that "endpoint" is used for denoting resources.


*"A registered device acts as a caller of the TRL endpoint."

Perhaps it can be rephrased or another word than "caller" used? I don't see caller used in RFC9200, RFC7252, or RFC6749. Practically the registered device will perform a request to the TRL endpoint right?


[Section 2]

*Regarding the following 3 sentences:
"the registered device can send an Observation Request to the TRL resource"
"the registered device can send a GET request to the TRL endpoint"
"An administrator can access and subscribe to the TRL like"

First "resource" is used, then "endpoint" is used, and in the last instance neither is used. Best to stick to one choice. This is a comment applicable to the document overall.


*"provides the current updated list of revoked Access Tokens in the portion of the TRL pertaining to that device"

Why not instead?
"provides the current updated list of revoked Access Tokens from the TRL pertaining to that device"
"Pertaining Access Token" was already defined in the terminology. I'm not sure also the concept of "portions" of the TRL are needed.

The concept of "portion of the TRL" comes back multiple times in the document, but is it really needed?


[Section 3]

*Is it neccessary to have both parameters ENCODED_TOKEN and HASH_INPUT. Can't the value of HASH_INPUT be defined directly?


[Section 4]

*"The order of the token hashes in the CBOR array is irrelevant, and the CBOR array MUST be treated as a set in which the order of elements has no significant meaning."

It seems this sentence is saying the same thing twice. This kind of construction occurs multiple times in the document.


[Section 5]

s/two types of query of the TRL/two types of queries of the TRL


[Section 5.1.1]

*"where "**" is the exponentiation operator"

Any reason not to use the ^ notation instead?


[Section 6]

*"does not support the "Cursor" extension (if it supports diff queries at all)"

Suggested rephrasing:
"does not support the "Cursor" extension nor diff queries"


[Section 7]

*In this section I miss a mention of "trl_patch". Should it not be used here, as it is defined in CDDL in Figure 6 and described in Section 5.1? Alternatively remove the mention of "trl_patch", and just describe it as a CBOR array of token_hash values.


*Section 5.1 says the following:
"The series items in the update collection MUST be strictly ordered in a chronological fashion."

Then in Section 7 it says:
"Within 'diff_set_value', the CBOR arrays 'diff_entry' MUST be sorted to reflect the corresponding updates to the TRL in reverse chronological order."

Why mandate to store in one order, and send in another?


[Section 8.2.1]

s/regardless whether/regardless of whether


[Section 8.2.2]

If the request does not include the 'cursor' query parameter, why does the AS still use it in the response? What if the requester doesn't support and/or doesn't want to use it at all? Cannot the decision to use the 'cursor' be an explicit indication by the requester, like having to include 'cursor' with value 0 in the request, or similar?

The requester may know MAX_N and expect behaviour according to that. Even if it got MAX_DIFF_BATCH during the registration procedure, it may not understand that parameter if it doesn't support the 'cursor' extension.


[Section 10.1]

*"A response from the TRL endpoint indicating that t1 has expired."

Could be good to clarify this sentence to say that this indication is about th1 having been removed from the TRL.


*"If expunging or not accepting t2 yields the deletion of th2 as per the two conditions specified above"

Suggested rephrasing:
"If receiving t2 yields the deletion of th2 as per the two conditions specified above"
It is the "receiving and seeing" that is criteria 1. "Expunging" or "not accepting" is not part of critera 1 or 2.


*"iii) has the sequence number encoded in the 'cti' claim not greater than the highest sequence number among the expired Access Tokens specifying the 'exi' claim"

Should this say "is greater" rather than "not greater"? If for instance the sequence number is lower, then should not the procedure in 5.10.3 of RFC9200 make such an Access Token be rejected in the first place?


[Section 13.4]

s/Client migth/Client might

s/the Autherization Server/the Authorization Server


[Appendix B]

The table states that MAX_DIFF_BATCH is not a single instance parameter, and in Section 9 it states that a registered device may receive MAX_DIFF_BATCH from the AS during registration. Why is MAX_DIFF_BATCH not a single instance parameter, but MAX_N is? Or rather, why are they not both single instance, or not single instance?

________________________________
From: Ace <[e-mail]> on behalf of Daniel Migault <[e-mail]>
Sent: Monday, March 13, 2023 18:36
To: Ace Wg <[e-mail]>
Subject: [Ace] WGLC draft-ietf-ace-revoked-token-notification-04.txt

Hi everyone,

This email starts a WGLC for draft-ietf-ace-revoked-token-notification which ends on March 27. Please provide your support and feed backs by that time. We will take advantage of the IETF116 session to solve any remaining discussions on that draft.

I am also looking for someone interested in being the document shepherd: Please volunteer!

To the co-authors I am looking at:
- 1) a heads-up regarding the implementations.
- 2) a confirmation that they are or not aware of any IPR
- 3)  a confirmation that they are willing to co-author the document.

Yours,
Logan and Daniel


On Mon, Mar 13, 2023 at 11:36 AM <[e-mail]<mailto:[e-mail]>> wrote:

A New Internet-Draft is available from the on-line Internet-Drafts
directories. This Internet-Draft is a work item of the Authentication and
Authorization for Constrained Environments (ACE) WG of the IETF.

   Title           : Notification of Revoked Access Tokens in the Authentication and Authorization for Constrained Environments (ACE) Framework
   Authors         : Marco Tiloca
                     Ludwig Seitz
                     Francesca Palombini
                     Sebastian Echeverria
                     Grace Lewis
   Filename        : draft-ietf-ace-revoked-token-notification-04.txt
   Pages           : 59
   Date            : 2023-03-13

Abstract:
   This document specifies a method of the Authentication and
   Authorization for Constrained Environments (ACE) framework, which
   allows an Authorization Server to notify Clients and Resource Servers
   (i.e., registered devices) about revoked Access Tokens.  The method
   allows Clients and Resource Servers to access a Token Revocation List
   on the Authorization Server, with the possible additional use of
   resource observation for the Constrained Application Protocol (CoAP).
   Resulting (unsolicited) notifications of revoked Access Tokens
   complement alternative approaches such as token introspection, while
   not requiring additional endpoints on Clients and Resource Servers.

The IETF datatracker status page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-ace-revoked-token-notification/<https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-ace-revoked-token-notification%2F&data=05%7C01%7Crikard.hoglund%40ri.se%7C6e109d1b535245f2de8c08db23e98fd8%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C638143258281785774%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=ScSk98oxn17GGIh5VtkZxePUAxKw43vsnf57Ga7PT1M%3D&reserved=0>

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-ace-revoked-token-notification-04.html<https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-ietf-ace-revoked-token-notification-04.html&data=05%7C01%7Crikard.hoglund%40ri.se%7C6e109d1b535245f2de8c08db23e98fd8%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C638143258281785774%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=%2BjUghcelCIHrkNs7q7DgglS%2Fc4BbBfT6fA5VZlYmx0g%3D&reserved=0>

A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-ace-revoked-token-notification-04<https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fauthor-tools.ietf.org%2Fiddiff%3Furl2%3Ddraft-ietf-ace-revoked-token-notification-04&data=05%7C01%7Crikard.hoglund%40ri.se%7C6e109d1b535245f2de8c08db23e98fd8%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C638143258281785774%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=BkteXqyWwVs6fz%2BD1Iw5DjSKESHp8fU2wpkuO1i4Lx0%3D&reserved=0>

Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts


_______________________________________________
Ace mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/ace<https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Face&data=05%7C01%7Crikard.hoglund%40ri.se%7C6e109d1b535245f2de8c08db23e98fd8%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C638143258281785774%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=dazAHDncPrlikYhksl6%2FCHL%2FyaY94XbIwf4ZReYoTus%3D&reserved=0>


--
Daniel Migault
Ericsson