Authors and *AD, [AD - please review and weigh in on Question 21.]
While reviewing this document during AUTH48, please resolve (as necessary) the following questions, which are also in the XML file. 1) <!-- [rfced] Please insert any keywords (beyond those that appear in the title) for use on https://www.rfc-editor.org/search. --> 2) <!--[rfced] Please review the use of "and" before list item 5: should this instead be "or"? Original: Even though access tokens have expiration times, there are circumstances by which an access token may need to be revoked before its expiration time, such as: (1) a registered device has been compromised, or is suspected of being compromised; (2) a registered device is decommissioned; (3) there has been a change in the ACE profile for a registered device; (4) there has been a change in access policies for a registered device; and (5) there has been a change in the outcome of policy evaluation for a registered device (e.g., if policy assessment depends on dynamic conditions in the execution environment, the user context, or the resource utilization). --> 3) <!--[rfced] Were we to expand this abbreviation, this text might be redundant. Please let us know if/how to update. Original: ...used in the ACE framework for Authentication and Authorization. As expanded, this reads as: ...used in the Authentication and Authorization for Constrained Environments framework for Authentication and Authorization. Original: ... described in the ACE framework for Authentication and Authorization [RFC9200 ]... --> 4) <!--[rfced] Please confirm that our suggested edit captures your intent. Original: It is also out of scope the method by which the AS determines or is notified of revoked access tokens, according to which the AS consequently updates the TRL as specified in this document. Perhaps: The method by which the AS determines or is notified of revoked access tokens, according to which the AS consequently updates the TRL as specified in this document, is also out of scope. --> 5) <!--[rfced] In the following, should a reference to RFC 7252 be added for the direct quote? This is the first occurrence of this text in an RFC. Original: This document does not use the CoAP definition of "endpoint", which is "An entity participating in the CoAP protocol." Perhaps: This document does not use the CoAP definition of "endpoint", which is defined in [RFC7252] as "An entity participating in the CoAP protocol." --> 6) <!--[rfced] Does the following rephrase capture your intended meaning? Original: By doing so, the registered device effectively subscribes to the TRL, as interested in receiving notifications about its update. Perhaps: By doing so, the registered device effectively subscribes to the TRL, as the device is interested in receiving notifications about the TRL's update. --> 7) <!--[rfced] We are unable to parse "and to which the access token pertains". Please rephrase. Original: That is, an Observe notification is sent to each registered device subscribed to the TRL and to which the access token pertains. --> 8) <!--[rfced] Please review the addition of "either" and let us know if this edit correctly captures your intent. Original: Depending on the specific subscription established through the Observation Request, the notification provides the current updated list of revoked access tokens in the subset of the TRL pertaining to that device (see Section 7), or the most recent TRL updates occurred over that list of pertaining revoked access tokens (see Section 8). Perhaps: Depending on the specific subscription established through the Observation Request, the notification provides either the current updated list of revoked access tokens in the subset of the TRL pertaining to that device (see Section 7) or the most recent TRL updates that occurred over that list of pertaining revoked access tokens (see Section 8). --> 9) <!--[rfced] We noticed repetition of the word "tag" in the following sentence. Does this rephrase correctly capture your intent? Original: In turn, the resulting tagged data item MUST be tagged by using the CWT CBOR tag with tag number 61 (see Section 6 of [RFC8392]). Perhaps: In turn, the resulting data item MUST be tagged using CWT CBOR tag number 61 (see Section 6 of [RFC8392]). --> 10) <!--[rfced] Much of Section 4 describes terminology. Should a pointer to this section be added to the Terminology section? Perhaps: See Section 4 for further terminology used throughout that section. --> 11) <!--[rfced] Does this rephrase capture your intended meaning? Original: An access token can have one among different formats. Perhaps: There are different formats an access token can have. --> 12) <!--[rfced] We note that the sub-bullets in Section 4.1.1 reverse order (i.e., the first bullet has CWT and then JWT mentioned in the sub-bullets and the second bullet lists JWT and then CWT in the sub-bullets). Please confirm that this is intentional or let us know if you'd like them to appear in the same order in both places.--> 13) <!--[rfced] When "tagged" appears in parentheses, should the reader assume this means "either tagged or not tagged"? For example: Original: That is, TOKEN_INFO is the binary representation of the (tagged) access token. Perhaps: That is, TOKEN_INFO is the binary representation of the tagged access token (whether or not it is tagged). --> 14) <!--[rfced] Please confirm that commas should not separate these values in curly brackets: Original: With reference to the example in Figure 3, BYTES is the bytes {0xd8 0x3d 0xd0 ... 0x64 0x3b}. --> 15) <!--[rfced] These sentences do not parse. Please review "with value the token hash" in particular. Original: Each element of the array is a CBOR byte string, with value the token hash of an access token. Original: Each element of the array is a CBOR byte string, with value the token hash of an access token such that: it pertained to the requester; and it was removed from the TRL during the update associated with the diff entry. --> 16) <!--[rfced] The double prepositions (between and towards) make this text hard to parse. How may we rephrase? Original: Consistent with Section 6.5 of [RFC9200], all communications between a requester towards the TRL endpoint and the AS MUST be encrypted, as well as integrity and replay protected. --> 17) <!--[rfced] Please review the following text and let us know what "trl_patch" names? Is this the name of the sets? The token hashes? Original: 2. The AS creates two sets "trl_patch" of token hashes, i.e., one "removed" set and one "added" set, as related to this TRL update. Perhaps: 2. The AS creates two sets of "trl_patch" token hashes, i.e., one "removed" set and one "added" set, as related to this TRL update. --> 18) <!--[rfced] Please clarify what "it" refers to in the following: Original: - All of the following hold: the update collection associated with the requester is not empty; no wrap-around of its 'index' value has occurred; and the 'cursor' query parameter has a value strictly greater than the current 'last_index' on the update collection (see Section 6.2.1). --> 19) <!--[rfced] This sentence doesn't parse. Please rephrase especially the part with "with value the token hash of an access token". Note similar text is in both bullets under number 3 in Section 8. Please let us know if the same fix may be applied in both places or if different changes are required. Original: Each element of the array is a CBOR byte string, with value the token hash of an access token such that: it pertained to the requester; and it was removed from the TRL during the update associated with the diff entry. --> 20) <!--[rfced] Please confirm our update to use the antecedent instead of "This" for clarity. Original: Otherwise, the 'cursor' parameter MUST specify a CBOR unsigned integer. This MUST take the 'index' value of the last series item in the update collection associated with the requester (see Section 6.2.1), as corresponding to the most recent TRL update pertaining to the requester. Perhaps: Otherwise, the 'cursor' parameter MUST specify a CBOR unsigned integer. This integer MUST take the 'index' value of the last series item in the update collection associated with the requester (see Section 6.2.1) as corresponding to the most recent TRL update pertaining to the requester. --> 21) <!--[rfced] *ADs - please review the following sentences that may lead to two interpretations of what the BCP 14 language applies to (due to the use of "and"). If the suggested text is not accurate, we suggest breaking up these sentences or rewording for clarity. Note that some of the following sentences appear in more than one location. Original: * The 'diff_set' parameter MUST be included and specifies the empty CBOR array. * The 'cursor' parameter MUST be included and specifies the CBOR simple value null (0xf6). * The 'more' parameter MUST be included and specifies the CBOR simple value false (0xf4). Perhaps: * The 'diff_set' parameter MUST be included and MUST specify the empty CBOR array. * The 'cursor' parameter MUST be included and MUST specify the CBOR simple value null (0xf6). * The 'more' parameter MUST be included and MUST specify the CBOR simple value false (0xf4). Original: * The 'full_set' parameter MUST be included and specifies a CBOR array 'full_set_value'. Perhaps: * The 'full_set' parameter MUST be included and MUST specify a CBOR array 'full_set_value'. Original: * The 'diff_set' parameter MUST be present and specifies a CBOR array 'diff_set_value' of U elements. Perhaps: * The 'diff_set' parameter MUST be present and MUST specify a CBOR array 'diff_set_value' of U elements. Original: * The 'diff_set' parameter MUST be present and specifies a CBOR array 'diff_set_value' of U elements. Perhaps: * The 'diff_set' parameter MUST be present and MUST specify a CBOR array 'diff_set_value' of U elements. Original: - The 'cursor' parameter MUST be present and specifies a CBOR unsigned integer. Perhaps: - The 'cursor' parameter MUST be present and MUST specify a CBOR unsigned integer. Original: - The 'more' parameter MUST be present and MUST specify the CBOR simple value false (0xf4) if U <= MAX_DIFF_BATCH, or the CBOR simple value true (0xf5) otherwise. Perhaps: - The 'more' parameter MUST be present and MUST specify the CBOR simple value false (0xf4) if U <= MAX_DIFF_BATCH; otherwise, it MUST specify the CBOR simple value true (0xf5). Original: o The 'more' parameter MUST be present and MUST specify the CBOR simple value false (0xf4) if SUB_U <= MAX_DIFF_BATCH, or the CBOR simple value true (0xf5) otherwise. Perhaps: o The 'more' parameter MUST be present and MUST specify the CBOR simple value false (0xf4) if SUB_U <= MAX_DIFF_BATCH; otherwise, it MUST specify the CBOR simple value true (0xf5). --> 22) <!--[rfced] We have attempted to break up and reorder this long sentence. Please review if the following suggested edit correctly captures your intent. Original: In order to further limit such a risk, when receiving an access token that specifies the 'exi' claim and for which a corresponding token hash is not stored, the RS can introspect the access token (see Section 5.9 of [RFC9200]), if token introspection is implemented by both the RS and the AS. Perhaps: This risk can be further limited. Specifically, if token introspection is implemented by both the RS and the AS, the RS can introspect the access token (see Section 5.9 of [RFC9200]) when receiving an access token that specifies the 'exi' claim and for which a corresponding token hash is not stored. --> 23) <!-- [rfced] [SHA-256] The reference to NIST FIPS 180-3 was very outdated. FIPS 180-3 was superseded by FIPS 180-4 in 2012. The latest version of this standard was released in August 2015. We have updated to the most recent version. Please let us know any objections--> 24) <!--[rfced] We noticed that Table 3 contains the only use of 'index' parameter. Please ensure parameter (and not value or unsigned integer) was intended. Original: Max value of each instance of the 'index' parameter --> 25) <!-- [rfced] We note that Appendices D and E were tagged "removeInRFC" in the XML. We have removed Appendix E (change log) but left Appendix D as it has citations to it in the text. Please review and let us know if any further updates are necessary. --> 26) <!--[rfced] We had the following questions/comments related to abbreviation use throughout the document. a) After first use with expansion, we will update the following to use only the abbreviation thereafter unless we hear objection: RS AS CWT b) We have expanded the following abbreviations on first use. Please review and let us know any objections. IoT CDDL CBOR JWE JWS OSCORE --> 27) <!--[rfced] We had the following questions regarding terminology used throughout the document: a) Please review the way parameter names are marked with regard to quotation, wo rd order, and the use of simply "parameter" or "query parameter". For example ( there may be more/others), we see: the 'access_token' parameter / the parameter 'access_token' the 'diff' query parameter / the query parameter 'diff' the 'cursor' query parameter / the query parameter 'cursor' / the 'cursor' parameter Please let us know if/how these may be made uniform throughout. b) We note that most field names were in single quotes. We have updated the wor d order in some places to appear as follows: 'name' field We also see a few uses of "unprotected" field. Is this a name? Or is this a different use of quotes? If a name, we suggest matching the pattern above. If a different concept, perhaps we can remove the quotes? c) We note that we normally see "a 2.05 (Content) response However, there is one use of "the CoAP response code 2.05 (Content). Please review and let us know if/how these should be made uniform. d) Please review uses of "Cursor". When double quoted, should it always be foll owed by the word extension? Note also that [I-D.bormann-t2trg-stp] uses 'cursor ' pattern (single quotes) instead. Examples below: Originals: ...as specified in Section 9 in fact relies on the "Cursor" pattern of the Series Transfer Pattern ... If supporting "Cursor", then UB = MAX_INDEX+1 ...in a diff query response when using "Cursor" C.4. Diff Query with Observe and "Cursor" Figure 13: Interaction for diff query with Observe and "Cursor" C.5. Full Query with Observe plus Plus Diff Query with "Cursor" etc. e) Will it be clear to the reader what the difference between "hashes" and "HASHES" is? Please review these uses and let us know if/how we may update (perhaps including a citation)? Should this actually be "a HASHES se t" or "a set of HASHES"? Uses of HASHES: 1. From the TRL, the AS builds a set HASHES such that: * If the requester is a registered device, HASHES specifies the token hashes currently in the TRL and associated with the access tokens pertaining to that registered device. f) Please note that we have made several updates related to the use of the word "occur" throughout the document. Please review these and let us know any objections. g) This document uses both GET request and GET (Observation) request. Please review and let us know if any updates for consistency are necessary. h) Please review the use of "Plus" in section and figure titles and let us know if "and" or something else is desirable. i) Please review the use of HASH_INPUT and Hash Input to ensure satisfaction with the variance. --> 28) <!--[rfced] Please consider if it would be helpful for the reader if mentions of "step #" were links to the steps in the html version. We believe the majority of the instances were pointing to steps directly above or below the text in which the pointer existed; thus, we have not made any such update (nor do we require it). An example of how to add this functionality if you so desire: <ol type="Step %d."> <li>... <li anchor="step2">... <li>... </ol> Following is a list of all such mentions in the current text for your convenienc e: discard the access token yet; instead, it moves to step 4. The RS skips step 3 only if it is certain that all its pertaining step 3. The RS skips step 4 only if it is certain that all its pertaining step 4. AS moves to step 2. considered at step 1. step 3. because SIZE is equal to 0 at step 2), then no diff entries are * At step 3, the AS considers the value MAX_DIFF_BATCH (see * At step 4, the CBOR map to carry in the payload of the 2.05 update collection for that requester (see step 5 at * At step 3, the AS considers the value MAX_DIFF_BATCH (see * At step 4, the CBOR map to carry in the payload of the --> 29) <!-- [rfced] We updated artwork tags to instead be sourcecode tags in the XML formatting of Sections 3, 4.2.1, 4.2.2, 6.1, 7, and 8. Please confirm that this is correct. In addition, please consider whether the "type" attribute of any sourcecode element should be set and/or has been set correctly. The current list of preferred values for "type" is available at <https://www.rfc-editor.org/rpc/wiki/doku.php?id=sourcecode-types>. If the current list does not contain an applicable type, feel free to suggest additions for consideration. Note that it is also acceptable to leave the "type" attribute not set. --> 30) <!--[rfced] Please review artwork to ensure that it fits within the 72-character line length limit. --> 31) <!-- [rfced] In the html and pdf outputs, the text enclosed in <tt> is output in fixed-width font. In the txt output, there are no changes to the font and the quotation marks have been removed. Please review carefully and let us know if the output is acceptable or if any updates are needed. --> 32) <!--[rfced] Please review cases such as the following knowing that we can us e <sub> or <sup> to express mathematical meaning (see https://authors.ietf.org/rfcxml-vocabulary#sup) and let us know if/how we should update: Original: The AS defines the single, constant unsigned integer MAX_INDEX <= ((2^64) - 1), where "^" is the exponentiation operator. --> 33) <!-- [rfced] Please review the "Inclusive Language" portion of the online Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language> and let us know if any changes are needed. Updates of this nature typically result in more precise language, which is helpful for readers. Note that our script did not flag any words in particular, but this should still be reviewed as a best practice. --> Thank you. RFC Editor/mf *****IMPORTANT***** Updated 2025/04/14 RFC Author(s): -------------- Instructions for Completing AUTH48 Your document has now entered AUTH48. Once it has been reviewed and approved by you and all coauthors, it will be published as an RFC. If an author is no longer available, there are several remedies available as listed in the FAQ (https://www.rfc-editor.org/faq/). You and you coauthors are responsible for engaging other parties (e.g., Contributors or Working Group) as necessary before providing your approval. Planning your review --------------------- Please review the following aspects of your document: * RFC Editor questions Please review and resolve any questions raised by the RFC Editor that have been included in the XML file as comments marked as follows: <!-- [rfced] ... --> These questions will also be sent in a subsequent email. * Changes submitted by coauthors Please ensure that you review any changes submitted by your coauthors. We assume that if you do not speak up that you agree to changes submitted by your coauthors. * Content Please review the full content of the document, as this cannot change once the RFC is published. Please pay particular attention to: - IANA considerations updates (if applicable) - contact information - references * Copyright notices and legends Please review the copyright notice and legends as defined in RFC 5378 and the Trust Legal Provisions (TLP – https://trustee.ietf.org/license-info). * Semantic markup Please review the markup in the XML file to ensure that elements of content are correctly tagged. For example, ensure that <sourcecode> and <artwork> are set correctly. See details at <https://authors.ietf.org/rfcxml-vocabulary>. * Formatted output Please review the PDF, HTML, and TXT files to ensure that the formatted output, as generated from the markup in the XML file, is reasonable. Please note that the TXT will have formatting limitations compared to the PDF and HTML. Submitting changes ------------------ To submit changes, please reply to this email using ‘REPLY ALL’ as all the parties CCed on this message need to see your changes. The parties include: * your coauthors * rfc-edi...@rfc-editor.org (the RPC team) * other document participants, depending on the stream (e.g., IETF Stream participants are your working group chairs, the responsible ADs, and the document shepherd). * auth48archive@rfc-editor.org, which is a new archival mailing list to preserve AUTH48 conversations; it is not an active discussion list: * More info: https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc * The archive itself: https://mailarchive.ietf.org/arch/browse/auth48archive/ * Note: If only absolutely necessary, you may temporarily opt out of the archiving of messages (e.g., to discuss a sensitive matter). If needed, please add a note at the top of the message that you have dropped the address. When the discussion is concluded, auth48archive@rfc-editor.org will be re-added to the CC list and its addition will be noted at the top of the message. You may submit your changes in one of two ways: An update to the provided XML file — OR — An explicit list of changes in this format Section # (or indicate Global) OLD: old text NEW: new text You do not need to reply with both an updated XML file and an explicit list of changes, as either form is sufficient. We will ask a stream manager to review and approve any changes that seem beyond editorial in nature, e.g., addition of new text, deletion of text, and technical changes. Information about stream managers can be found in the FAQ. Editorial changes do not require approval from a stream manager. Approving for publication -------------------------- To approve your RFC for publication, please reply to this email stating that you approve this RFC for publication. Please use ‘REPLY ALL’, as all the parties CCed on this message need to see your approval. Files ----- The files are available here: https://www.rfc-editor.org/authors/rfc9770.xml https://www.rfc-editor.org/authors/rfc9770.html https://www.rfc-editor.org/authors/rfc9770.pdf https://www.rfc-editor.org/authors/rfc9770.txt Diff file of the text: https://www.rfc-editor.org/authors/rfc9770-diff.html https://www.rfc-editor.org/authors/rfc9770-rfcdiff.html (side by side) Diff of the XML: https://www.rfc-editor.org/authors/rfc9770-xmldiff1.html Tracking progress ----------------- The details of the AUTH48 status of your document are here: https://www.rfc-editor.org/auth48/rfc9770 Please let us know if you have any questions. Thank you for your cooperation, RFC Editor -------------------------------------- RFC9770 (draft-ietf-ace-revoked-token-notification-09) Title : Notification of Revoked Access Tokens in the Authentication and Authorization for Constrained Environments (ACE) Framework Author(s) : M. Tiloca, F. Palombini, S. Echeverria, G. Lewis WG Chair(s) : Loganaden Velvindron, Tim Hollebeek Area Director(s) : Deb Cooley, Paul Wouters -- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
