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

[Daniel Migault <[e-mail]>]

Hi All,

Anyone volunteering to do shepherd write up would be highly appreciated.
Marco and others folks already provided all the necessary information, so
that could be done very easily.

Yours,
Daniel

On Sat, Mar 25, 2023 at 12:46 AM Rikard Höglund <[e-mail]>
wrote:

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


-- 
Daniel Migault
Ericsson