rfc9770v1.txt | rfc9770.txt | |||
---|---|---|---|---|
Internet Engineering Task Force (IETF) M. Tiloca | Internet Engineering Task Force (IETF) M. Tiloca | |||
Request for Comments: 9770 RISE AB | Request for Comments: 9770 RISE AB | |||
Category: Standards Track F. Palombini | Category: Standards Track F. Palombini | |||
ISSN: 2070-1721 Ericsson AB | ISSN: 2070-1721 Ericsson AB | |||
S. Echeverria | S. Echeverria | |||
G. Lewis | G. Lewis | |||
CMU SEI | CMU SEI | |||
April 2025 | May 2025 | |||
Notification of Revoked Access Tokens in the Authentication and | Notification of Revoked Access Tokens in the Authentication and | |||
Authorization for Constrained Environments (ACE) Framework | Authorization for Constrained Environments (ACE) Framework | |||
Abstract | Abstract | |||
This document specifies a method of the Authentication and | This document specifies a method of the Authentication and | |||
Authorization for Constrained Environments (ACE) framework, which | Authorization for Constrained Environments (ACE) framework, which | |||
allows an authorization server to notify clients and resource servers | allows an authorization server to notify clients and resource servers | |||
(i.e., registered devices) about revoked access tokens. As specified | (i.e., registered devices) about revoked access tokens. As specified | |||
in this document, the method allows clients and resource servers to | in this document, the method allows clients and resource servers | |||
access a Token Revocation List (TRL) on the authorization server by | (RSs) to access a Token Revocation List (TRL) on the authorization | |||
using the Constrained Application Protocol (CoAP), with the possible | server by using the Constrained Application Protocol (CoAP), with the | |||
additional use of resource observation. Resulting (unsolicited) | possible additional use of resource observation. Resulting | |||
notifications of revoked access tokens complement alternative | (unsolicited) notifications of revoked access tokens complement | |||
approaches such as token introspection, while not requiring | alternative approaches such as token introspection, while not | |||
additional endpoints on clients and resource servers. | requiring additional endpoints on clients and RSs. | |||
Status of This Memo | Status of This Memo | |||
This is an Internet Standards Track document. | This is an Internet Standards Track document. | |||
This document is a product of the Internet Engineering Task Force | This document is a product of the Internet Engineering Task Force | |||
(IETF). It represents the consensus of the IETF community. It has | (IETF). It represents the consensus of the IETF community. It has | |||
received public review and has been approved for publication by the | received public review and has been approved for publication by the | |||
Internet Engineering Steering Group (IESG). Further information on | Internet Engineering Steering Group (IESG). Further information on | |||
Internet Standards is available in Section 2 of RFC 7841. | Internet Standards is available in Section 2 of RFC 7841. | |||
skipping to change at line 119 ¶ | skipping to change at line 119 ¶ | |||
15.5. ACE Token Revocation List Errors | 15.5. ACE Token Revocation List Errors | |||
15.6. Expert Review Instructions | 15.6. Expert Review Instructions | |||
16. References | 16. References | |||
16.1. Normative References | 16.1. Normative References | |||
16.2. Informative References | 16.2. Informative References | |||
Appendix A. On Using the Series Transfer Pattern | Appendix A. On Using the Series Transfer Pattern | |||
Appendix B. Local Supportive Parameters of the TRL Endpoint | Appendix B. Local Supportive Parameters of the TRL Endpoint | |||
Appendix C. Interaction Examples | Appendix C. Interaction Examples | |||
C.1. Full Query with Observe | C.1. Full Query with Observe | |||
C.2. Diff Query with Observe | C.2. Diff Query with Observe | |||
C.3. Full Query with Observe Plus Diff Query | C.3. Full Query with Observe and Diff Query | |||
C.4. Diff Query with Observe and "Cursor" | C.4. Diff Query with Observe and "Cursor" Extension | |||
C.5. Full Query with Observe Plus Diff Query with "Cursor" | C.5. Full Query with Observe and Diff Query with "Cursor" | |||
Extension | ||||
Appendix D. CDDL Model | Appendix D. CDDL Model | |||
Acknowledgments | Acknowledgments | |||
Authors' Addresses | Authors' Addresses | |||
1. Introduction | 1. Introduction | |||
Authentication and Authorization for Constrained Environments (ACE) | Authentication and Authorization for Constrained Environments (ACE) | |||
[RFC9200] is a framework that enforces access control on Internet of | [RFC9200] is a framework that enforces access control on Internet of | |||
Things (IoT) devices acting as Resource Servers (RSs). In order to | Things (IoT) devices acting as Resource Servers (RSs). In order to | |||
use ACE, both clients and RSs have to register with an Authorization | use ACE, both clients and RSs have to register with an Authorization | |||
skipping to change at line 151 ¶ | skipping to change at line 152 ¶ | |||
1. a registered device has been compromised or is suspected of being | 1. a registered device has been compromised or is suspected of being | |||
compromised; | compromised; | |||
2. a registered device is decommissioned; | 2. a registered device is decommissioned; | |||
3. there has been a change in the ACE profile for a registered | 3. there has been a change in the ACE profile for a registered | |||
device; | device; | |||
4. there has been a change in access policies for a registered | 4. there has been a change in access policies for a registered | |||
device; and | device; or | |||
5. there has been a change in the outcome of policy evaluation for a | 5. there has been a change in the outcome of policy evaluation for a | |||
registered device (e.g., if policy assessment depends on dynamic | registered device (e.g., if policy assessment depends on dynamic | |||
conditions in the execution environment, the user context, or the | conditions in the execution environment, the user context, or the | |||
resource utilization). | resource utilization). | |||
As discussed in Section 6.1 of [RFC9200], only client-initiated | As discussed in Section 6.1 of [RFC9200], only client-initiated | |||
revocation is currently specified [RFC7009] for OAuth 2.0 [RFC6749], | revocation is currently specified [RFC7009] for OAuth 2.0 [RFC6749], | |||
based on the assumption that access tokens in OAuth are issued with a | based on the assumption that access tokens in OAuth are issued with a | |||
relatively short lifetime. However, this is not expected to be the | relatively short lifetime. However, this is not expected to be the | |||
skipping to change at line 174 ¶ | skipping to change at line 175 ¶ | |||
This document specifies a method for allowing registered devices to | This document specifies a method for allowing registered devices to | |||
access and possibly subscribe to a Token Revocation List (TRL) on the | access and possibly subscribe to a Token Revocation List (TRL) on the | |||
AS in order to obtain updated information about pertaining access | AS in order to obtain updated information about pertaining access | |||
tokens that were revoked prior to their expiration. As specified in | tokens that were revoked prior to their expiration. As specified in | |||
this document, the registered devices use the Constrained Application | this document, the registered devices use the Constrained Application | |||
Protocol (CoAP) [RFC7252] to communicate with the AS and with one | Protocol (CoAP) [RFC7252] to communicate with the AS and with one | |||
another and can subscribe to the TRL on the AS by using resource | another and can subscribe to the TRL on the AS by using resource | |||
observation for CoAP [RFC7641]. Underlying protocols other than CoAP | observation for CoAP [RFC7641]. Underlying protocols other than CoAP | |||
are not prohibited from being supported in the future, if they are | are not prohibited from being supported in the future, if they are | |||
defined to be used in the ACE framework for Authentication and | defined to be used in the ACE framework. | |||
Authorization. | ||||
Unlike in the case of token introspection (see Section 5.9 of | Unlike in the case of token introspection (see Section 5.9 of | |||
[RFC9200]), a registered device does not provide an owned access | [RFC9200]), a registered device does not provide an owned access | |||
token to the AS for inquiring about its current state. Instead, | token to the AS for inquiring about its current state. Instead, | |||
registered devices simply obtain updated information about pertaining | registered devices simply obtain updated information about pertaining | |||
access tokens that were revoked prior to their expiration as | access tokens that were revoked prior to their expiration as | |||
efficiently identified by corresponding hash values. | efficiently identified by corresponding hash values. | |||
The benefits of this method are that it complements token | The benefits of this method are that it complements token | |||
introspection and does not require the registered devices to support | introspection and does not require the registered devices to support | |||
any additional endpoints (see Section 1.1). The only additional | any additional endpoints (see Section 1.1). The only additional | |||
requirements for registered devices are a request/response | requirements for registered devices are a request/response | |||
interaction with the AS to access and possibly subscribe to the TRL | interaction with the AS to access and possibly subscribe to the TRL | |||
(see Section 2) and the lightweight computation of hash values to use | (see Section 2) and the lightweight computation of hash values to use | |||
as access token identifiers (see Section 4). | as access token identifiers (see Section 4). | |||
The process by which access tokens are declared revoked is out of the | The process by which access tokens are declared revoked is out of the | |||
scope of this document. It is also out of scope the method by which | scope of this document. The method by which the AS determines or is | |||
the AS determines or is notified of revoked access tokens, according | notified of revoked access tokens, according to which the AS | |||
to which the AS consequently updates the TRL as specified in this | consequently updates the TRL as specified in this document, is also | |||
document. | out of scope. | |||
1.1. Terminology | 1.1. Terminology | |||
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | |||
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and | "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and | |||
"OPTIONAL" in this document are to be interpreted as described in BCP | "OPTIONAL" in this document are to be interpreted as described in BCP | |||
14 [RFC2119] [RFC8174] when, and only when, they appear in all | 14 [RFC2119] [RFC8174] when, and only when, they appear in all | |||
capitals, as shown here. | capitals, as shown here. | |||
Readers are expected to be familiar with the terms and concepts | Readers are expected to be familiar with the terms and concepts | |||
described in the ACE framework for Authentication and Authorization | described in the ACE framework [RFC9200], as well as with terms and | |||
[RFC9200], as well as with terms and concepts related to CBOR Web | concepts related to CBOR Web Tokens (CWTs) [RFC8392] and JSON Web | |||
Tokens (CWTs) [RFC8392] and JSON Web Tokens (JWTs) [RFC7519]. | Tokens (JWTs) [RFC7519]. | |||
The terminology for entities in the considered architecture is | The terminology for entities in the considered architecture is | |||
defined in OAuth 2.0 [RFC6749]. In particular, this includes client, | defined in OAuth 2.0 [RFC6749]. In particular, this includes client, | |||
resource server (RS), and authorization server (AS). | RS, and authorization server (AS). | |||
Readers are also expected to be familiar with the terms and concepts | Readers are also expected to be familiar with the terms and concepts | |||
related to the Concise Data Definition Language (CDDL) [RFC8610], | related to the Concise Data Definition Language (CDDL) [RFC8610], | |||
Concise Binary Object Representation (CBOR) [RFC8949], JSON | Concise Binary Object Representation (CBOR) [RFC8949], JSON | |||
[RFC8259], CBOR Object Signing and Encryption (COSE) [RFC9052], CoAP | [RFC8259], CBOR Object Signing and Encryption (COSE) [RFC9052], CoAP | |||
[RFC7252], CoAP Observe [RFC7641], and the use of hash functions to | [RFC7252], CoAP Observe [RFC7641], and the use of hash functions to | |||
name objects as defined in [RFC6920]. | name objects as defined in [RFC6920]. | |||
Note that the term "endpoint" is used here following its OAuth | Note that the term "endpoint" is used here following its OAuth | |||
definition [RFC6749], aimed at denoting resources such as /token and | definition [RFC6749], aimed at denoting resources such as /token and | |||
/introspect at the AS, and /authz-info at the RS. This document does | /introspect at the AS, and /authz-info at the RS. The CoAP | |||
not use the CoAP definition of "endpoint", which is "An entity | definition, which is "[a]n entity participating in the CoAP protocol" | |||
participating in the CoAP protocol." | [RFC7252], is not used in this document. | |||
This specification also uses the following terminology: | This specification also uses the following terminology: | |||
Token hash: identifier of an access token, in binary format | Token hash: identifier of an access token, in binary format | |||
encoding. The token hash has no relation to other access token | encoding. The token hash has no relation to other access token | |||
identifiers possibly used, such as the 'cti' (CWT ID) claim of | identifiers possibly used, such as the 'cti' (CWT ID) claim of | |||
CBOR Web Tokens (CWTs) [RFC8392]. | CBOR Web Tokens (CWTs) [RFC8392]. | |||
Token Revocation List (TRL): a collection of token hashes such that | Token Revocation List (TRL): a collection of token hashes such that | |||
the corresponding access tokens have been revoked but are not | the corresponding access tokens have been revoked but are not | |||
skipping to change at line 286 ¶ | skipping to change at line 286 ¶ | |||
TRL update pertaining to a requester: an update to the TRL through | TRL update pertaining to a requester: an update to the TRL through | |||
which token hashes pertaining to that requester have been added to | which token hashes pertaining to that requester have been added to | |||
or removed from the TRL. | or removed from the TRL. | |||
Full query: a type of query to the TRL where the AS returns the | Full query: a type of query to the TRL where the AS returns the | |||
token hashes of the revoked access tokens currently in the TRL and | token hashes of the revoked access tokens currently in the TRL and | |||
pertaining to the requester. Further details are specified in | pertaining to the requester. Further details are specified in | |||
Sections 6 and 7. | Sections 6 and 7. | |||
Diff query: a type of query to the TRL where the AS returns a list | Diff query: a type of query to the TRL where the AS returns a list | |||
of diff entries, each related to one update to the TRL and | of diff entries, each related to one update that occurred to the | |||
containing a set of token hashes pertaining to the requester. | TRL and containing a set of token hashes pertaining to the | |||
Further details are specified in Sections 6 and 8. | requester. Further details are specified in Sections 6 and 8. | |||
See Section 4 for further terminology used throughout that section. | ||||
Examples throughout this document are expressed in CBOR diagnostic | Examples throughout this document are expressed in CBOR diagnostic | |||
notation as defined in Section 8 of [RFC8949] and Appendix G of | notation as defined in Section 8 of [RFC8949] and Appendix G of | |||
[RFC8610]. Diagnostic notation comments are often used to provide a | [RFC8610]. Diagnostic notation comments are often used to provide a | |||
textual representation of the numeric parameter names and values. | textual representation of the numeric parameter names and values. | |||
In the CBOR diagnostic notation used in this document, constructs of | In the CBOR diagnostic notation used in this document, constructs of | |||
the form e'SOME_NAME' are replaced by the value assigned to SOME_NAME | the form e'SOME_NAME' are replaced by the value assigned to SOME_NAME | |||
in the CDDL model shown in Figure 15 of Appendix D. For example, | in the CDDL model shown in Figure 15 of Appendix D. For example, | |||
{e'full_set': [], e'cursor': 3} stands for {0: [], 2: 3}. | {e'full_set': [], e'cursor': 3} stands for {0: [], 2: 3}. | |||
Note to RFC Editor: Please delete the paragraph immediately preceding | Note to RFC Editor: Please delete the paragraph immediately preceding | |||
this note. Also, in the CBOR diagnostic notation used in this | this note. Also, in the CBOR diagnostic notation used in this | |||
document, please replace the constructs of the form e'SOME_NAME' with | document, please replace the constructs of the form e'SOME_NAME' with | |||
the value assigned to SOME_NAME in the CDDL model shown in Figure 15 | the value assigned to SOME_NAME in the CDDL model shown in Figure 15 | |||
of Appendix D. Finally, please delete this note. | of Appendix D. Finally, please delete this note. | |||
2. Protocol Overview | 2. Protocol Overview | |||
This protocol defines how a CoAP-based authorization server informs | This protocol defines how a CoAP-based AS informs clients and RSs, | |||
clients and resource servers, i.e., registered devices, about | i.e., registered devices, about pertaining revoked access tokens. | |||
pertaining revoked access tokens. How the relationship between a | How the relationship between a registered device and the AS is | |||
registered device and the AS is established is out of the scope of | established is out of the scope of this specification. | |||
this specification. | ||||
At a high level, the steps of this protocol are as follows: | At a high level, the steps of this protocol are as follows: | |||
1. Upon startup, the AS creates a single TRL accessible through the | 1. Upon startup, the AS creates a single TRL accessible through the | |||
TRL endpoint. At any point in time, the TRL represents the list | TRL endpoint. At any point in time, the TRL represents the list | |||
of all revoked access tokens issued by the AS that are not | of all revoked access tokens issued by the AS that are not | |||
expired yet. | expired yet. | |||
2. When a device registers at the AS, it also receives the url-path | 2. When a device registers at the AS, it also receives the url-path | |||
to the TRL endpoint. | to the TRL endpoint. | |||
skipping to change at line 335 ¶ | skipping to change at line 336 ¶ | |||
registered device can send a GET request to the TRL endpoint at | registered device can send a GET request to the TRL endpoint at | |||
the AS. When doing so, it can request the following: the current | the AS. When doing so, it can request the following: the current | |||
list of pertaining revoked access tokens (see Section 7) or the | list of pertaining revoked access tokens (see Section 7) or the | |||
most recent updates that occurred over the list of pertaining | most recent updates that occurred over the list of pertaining | |||
revoked access tokens (see Section 8). | revoked access tokens (see Section 8). | |||
In particular, the registered device can rely on Observation for | In particular, the registered device can rely on Observation for | |||
CoAP [RFC7641]. In such a case, the GET request sent to the TRL | CoAP [RFC7641]. In such a case, the GET request sent to the TRL | |||
endpoint includes the CoAP Observe Option set to 0 (register), | endpoint includes the CoAP Observe Option set to 0 (register), | |||
i.e., it is an Observation Request. By doing so, the registered | i.e., it is an Observation Request. By doing so, the registered | |||
device effectively subscribes to the TRL, as interested in | device effectively subscribes to the TRL, as the device is | |||
receiving notifications about its update. Upon receiving the | interested in receiving notifications about the TRL's update. | |||
Observation Request, the AS adds the registered device to the | Upon receiving the Observation Request, the AS adds the | |||
list of observers of the TRL endpoint. | registered device to the list of observers of the TRL endpoint. | |||
3. When an access token is revoked, the AS adds the corresponding | 3. When an access token is revoked, the AS adds the corresponding | |||
token hash to the TRL. Also, when a revoked access token | token hash to the TRL. Also, when a revoked access token | |||
eventually expires, the AS removes the corresponding token hash | eventually expires, the AS removes the corresponding token hash | |||
from the TRL. | from the TRL. | |||
In either case, after updating the TRL, the AS sends Observe | In either case, after updating the TRL, the AS sends Observe | |||
notifications as per [RFC7641]. That is, an Observe notification | notifications as per [RFC7641]. That is, an Observe notification | |||
is sent to each registered device subscribed to the TRL and to | is sent to each registered device that is subscribed to the TRL | |||
which the access token pertains. | and to which the access token pertains. | |||
Depending on the specific subscription established through the | Depending on the specific subscription established through the | |||
Observation Request, the notification provides the current | Observation Request, the notification provides either the current | |||
updated list of revoked access tokens in the subset of the TRL | updated list of revoked access tokens in the subset of the TRL | |||
pertaining to that device (see Section 7), or the most recent TRL | pertaining to that device (see Section 7) or the most recent TRL | |||
updates that occurred over that list of pertaining revoked access | updates that occurred over that list of pertaining revoked access | |||
tokens (see Section 8). | tokens (see Section 8). | |||
Further Observe notifications may be sent, consistent with | Further Observe notifications may be sent, consistent with | |||
ongoing additional observations of the TRL endpoint. | ongoing additional observations of the TRL endpoint. | |||
4. An administrator can access and subscribe to the TRL like a | 4. An administrator can access and subscribe to the TRL like a | |||
registered device while getting the content of the whole TRL (see | registered device while getting the content of the whole TRL (see | |||
Section 7) or the most recent updates to the whole TRL (see | Section 7) or the most recent updates that occurred to the whole | |||
Section 8). | TRL (see Section 8). | |||
Figure 1 shows a high-level overview of the service provided by this | Figure 1 shows a high-level overview of the service provided by this | |||
protocol. For the sake of simplicity, the example shown in the | protocol. For the sake of simplicity, the example shown in the | |||
figure considers the simultaneous revocation of the three access | figure considers the simultaneous revocation of the three access | |||
tokens t1, t2, and t3 whose corresponding token hashes are th1, th2, | tokens t1, t2, and t3 whose corresponding token hashes are th1, th2, | |||
and th3, respectively. Consequently, the AS adds the three token | and th3, respectively. Consequently, the AS adds the three token | |||
hashes to the TRL at once and sends Observe notifications to one | hashes to the TRL at once and sends Observe notifications to one | |||
administrator and four registered devices. Each dotted line | administrator and four registered devices. Each dotted line | |||
associated with a pair of registered devices indicates the access | associated with a pair of registered devices indicates the access | |||
token that they both own. | token that they both own. | |||
skipping to change at line 440 ¶ | skipping to change at line 441 ¶ | |||
lengths, and the length of the encoded tag numbers MUST be the | lengths, and the length of the encoded tag numbers MUST be the | |||
minimum possible length. This means that tag number 16 is | minimum possible length. This means that tag number 16 is | |||
encoded as 0xd0 and not as 0xd810. | encoded as 0xd0 and not as 0xd810. | |||
The example in Figure 2 shows a CWT that uses the COSE object | The example in Figure 2 shows a CWT that uses the COSE object | |||
COSE_Encrypt0 (see Section 5.2 of [RFC9052]). | COSE_Encrypt0 (see Section 5.2 of [RFC9052]). | |||
* If, like for JWTs [RFC7519], the access token relies on a JSON | * If, like for JWTs [RFC7519], the access token relies on a JSON | |||
object for encoding its claims, the following applies: | object for encoding its claims, the following applies: | |||
Consistent with the ACE framework for Authentication and | Consistent with the ACE framework [RFC9200], this document | |||
Authorization [RFC9200], this document specifically considers | specifically considers JWTs, which are always represented using | |||
JWTs, which are always represented using the JSON Web Signature | the JSON Web Signature (JWS) Compact Serialization from [RFC7515] | |||
(JWS) Compact Serialization from [RFC7515] or the JSON Web | or the JSON Web Encryption (JWE) Compact Serialization from | |||
Encryption (JWE) Compact Serialization from [RFC7516]. | [RFC7516]. Consequently, all the header parameters are specified | |||
Consequently, all the header parameters are specified within | within integrity-protected fields. | |||
integrity-protected fields. | ||||
In case alternative access tokens were used, the following | In case alternative access tokens were used, the following | |||
applies: | applies: | |||
- If the access token uses the JWS Compact Serialization from | - If the access token uses the JWS Compact Serialization from | |||
[RFC7515], it MUST NOT include the JWS Unprotected Header. | [RFC7515], it MUST NOT include the JWS Unprotected Header. | |||
- If the access token uses the JWE Compact Serialization from | - If the access token uses the JWE Compact Serialization from | |||
[RFC7516], it MUST NOT include the JWE Shared Unprotected | [RFC7516], it MUST NOT include the JWE Shared Unprotected | |||
Header and it MUST NOT include the "header" member in any of | Header and it MUST NOT include the "header" member in any of | |||
skipping to change at line 509 ¶ | skipping to change at line 509 ¶ | |||
the entire CBOR data item consisting of both a tag number and the tag | the entire CBOR data item consisting of both a tag number and the tag | |||
content: the tag content is the CBOR data item that is being tagged. | content: the tag content is the CBOR data item that is being tagged. | |||
Also, "tagged access token" is used to denote nested CBOR tags | Also, "tagged access token" is used to denote nested CBOR tags | |||
(possibly a single one), with the innermost tag content being a CWT. | (possibly a single one), with the innermost tag content being a CWT. | |||
4.1. Motivation for the Used Construction | 4.1. Motivation for the Used Construction | |||
An access token can have one among different formats. The most | An access token can have one among different formats. The most | |||
expected formats are CWT [RFC8392] and JWT [RFC7519], with the former | expected formats are CWT [RFC8392] and JWT [RFC7519], with the former | |||
being the default format to use in the ACE framework for | being the default format to use in the ACE framework (see Section 3 | |||
Authentication and Authorization (see Section 3 of [RFC9200]). While | of [RFC9200]). While access tokens are opaque to clients, an RS is | |||
access tokens are opaque to clients, an RS is aware of whether access | aware of whether access tokens that are issued for it to consume are | |||
tokens that are issued for it to consume are either CWTs or JWTs. | either CWTs or JWTs. | |||
4.1.1. Issuing of the Access Token to the Client | 4.1.1. Issuing of the Access Token to the Client | |||
There are two possible encodings that the AS can use for the AS-to- | There are two possible encodings that the AS can use for the AS-to- | |||
Client response (see Section 5.8.2 of [RFC9200]) where the issued | Client response (see Section 5.8.2 of [RFC9200]) where the issued | |||
access token is included and provided to the requester client. The | access token is included and provided to the requester client. The | |||
RS may not be aware of which encoding is used for that response to | RS may not be aware of which encoding is used for that response to | |||
that particular requester client. | that particular requester client. | |||
* One method of encoding relies on CBOR, which is required if CoAP | * One method of encoding relies on CBOR, which is required if CoAP | |||
is used (see Section 5 of [RFC9200]) and is recommended otherwise | is used (see Section 5 of [RFC9200]) and is recommended otherwise | |||
(see Section 3 of [RFC9200]). That is, the AS-to-Client response | (see Section 3 of [RFC9200]). That is, the AS-to-Client response | |||
has media-type "application/ace+cbor". | has media-type "application/ace+cbor". | |||
This implies that, within the CBOR map specified as message | This implies that, within the CBOR map specified as message | |||
payload, the parameter 'access_token' is a CBOR data item of type | payload, the 'access_token' parameter is a CBOR data item of type | |||
CBOR byte string and with a value of BYTES. In particular: | CBOR byte string and with a value of BYTES. In particular: | |||
- If the access token is a CWT, then BYTES is the binary | - If the access token is a CWT, then BYTES is the binary | |||
representation of the CWT (i.e., of the CBOR array that encodes | representation of the CWT (i.e., of the CBOR array that encodes | |||
the untagged CWT) or of a tagged access token with the CWT as | the untagged CWT) or of a tagged access token with the CWT as | |||
the innermost tag content. | the innermost tag content. | |||
- If the access token is a JWT, then BYTES is the binary | - If the access token is a JWT, then BYTES is the binary | |||
representation of the JWT (i.e., of the text string that | representation of the JWT (i.e., of the text string that | |||
encodes the JWT). | encodes the JWT). | |||
* An alternative method of encoding relies on JSON. That is, the | * An alternative method of encoding relies on JSON. That is, the | |||
AS-to-Client response has media-type "application/ace+json". | AS-to-Client response has media-type "application/ace+json". | |||
This implies that, within the JSON object specified as message | This implies that, within the JSON object specified as message | |||
payload, the parameter 'access_token' has as a value a text string | payload, the 'access_token' parameter has as a value a text string | |||
TEXT. In particular: | TEXT. In particular: | |||
- If the access token is a JWT, then TEXT is the text string that | - If the access token is a JWT, then TEXT is the text string that | |||
encodes the JWT. | encodes the JWT. | |||
- If the access token is a CWT, then TEXT is the base64url- | - If the access token is a CWT, then TEXT is the base64url- | |||
encoded text string of BYTES, which is the binary | encoded text string of BYTES, which is the binary | |||
representation of the CWT (i.e., of the CBOR array that encodes | representation of the CWT (i.e., of the CBOR array that encodes | |||
the untagged CWT) or of a tagged access token with the CWT as | the untagged CWT) or of a tagged access token with the CWT as | |||
the innermost tag content. | the innermost tag content. | |||
skipping to change at line 567 ¶ | skipping to change at line 567 ¶ | |||
In accordance with the used transport profile of ACE (e.g., | In accordance with the used transport profile of ACE (e.g., | |||
[RFC9202], [RFC9203], [RFC9431]), the RS receives a piece of token- | [RFC9202], [RFC9203], [RFC9431]), the RS receives a piece of token- | |||
related information hereafter denoted as TOKEN_INFO. | related information hereafter denoted as TOKEN_INFO. | |||
In particular: | In particular: | |||
* If the AS-to-Client response was encoded in CBOR, then TOKEN_INFO | * If the AS-to-Client response was encoded in CBOR, then TOKEN_INFO | |||
is the value of the CBOR byte string conveyed by the | is the value of the CBOR byte string conveyed by the | |||
'access_token' parameter of that response. That is, TOKEN_INFO is | 'access_token' parameter of that response. That is, TOKEN_INFO is | |||
the binary representation of the (tagged) access token. | the binary representation of the access token. | |||
* If the AS-to-Client response was encoded in JSON and the access | * If the AS-to-Client response was encoded in JSON and the access | |||
token is a JWT, then TOKEN_INFO is the binary representation of | token is a JWT, then TOKEN_INFO is the binary representation of | |||
the text string conveyed by the 'access_token' parameter of that | the text string conveyed by the 'access_token' parameter of that | |||
response. That is, TOKEN_INFO is the binary representation of the | response. That is, TOKEN_INFO is the binary representation of the | |||
access token. | access token. | |||
* If the AS-to-Client response was encoded in JSON and the access | * If the AS-to-Client response was encoded in JSON and the access | |||
token is a CWT, then TOKEN_INFO is the binary representation of | token is a CWT, then TOKEN_INFO is the binary representation of | |||
the base64url-encoded text string that encodes the binary | the base64url-encoded text string that encodes the binary | |||
representation of the (tagged) access token. That is, TOKEN_INFO | representation of the access token. That is, TOKEN_INFO is the | |||
is the binary representation of the base64url-encoded text string | binary representation of the base64url-encoded text string | |||
conveyed by the 'access_token' parameter. | conveyed by the 'access_token' parameter. | |||
The following overviews how the above specifically applies to the | The following overviews how the above specifically applies to the | |||
existing transport profiles of ACE: | existing transport profiles of ACE: | |||
* The (tagged) access token can be uploaded to the RS by means of a | * The access token can be uploaded to the RS by means of a POST | |||
POST request to the /authz-info endpoint (see Section 5.10.1 of | request to the /authz-info endpoint (see Section 5.10.1 of | |||
[RFC9200]), using a CoAP Content-Format or HTTP media-type that | [RFC9200]), using a CoAP Content-Format or HTTP media-type that | |||
reflects the format of the access token, if available (e.g., | reflects the format of the access token, if available (e.g., | |||
"application/cwt" for CWTs), or "application/octet-stream" | "application/cwt" for CWTs), or "application/octet-stream" | |||
otherwise. When doing so (e.g., like in [RFC9202]), TOKEN_INFO is | otherwise. When doing so (e.g., like in [RFC9202]), TOKEN_INFO is | |||
the payload of the POST request. | the payload of the POST request. | |||
* The (tagged) access token can be uploaded to the RS by means of a | * The access token can be uploaded to the RS by means of a POST | |||
POST request to the /authz-info endpoint, using the media-type | request to the /authz-info endpoint, using the media-type | |||
"application/ace+cbor". When doing so (e.g., like in [RFC9203]), | "application/ace+cbor". When doing so (e.g., like in [RFC9203]), | |||
TOKEN_INFO is the value of the CBOR byte string conveyed by the | TOKEN_INFO is the value of the CBOR byte string conveyed by the | |||
'access_token' parameter, within the CBOR map specified as payload | 'access_token' parameter, within the CBOR map specified as payload | |||
of the POST request. | of the POST request. | |||
* The (tagged) access token can be uploaded to the RS during a DTLS | * The access token can be uploaded to the RS during a DTLS session | |||
session establishment, e.g., like it is defined in Section 3.2.2 | establishment, e.g., like it is defined in Section 3.2.2 of | |||
of [RFC9202]. When doing so, TOKEN_INFO is the value of the | [RFC9202]. When doing so, TOKEN_INFO is the value of the | |||
'psk_identity' field of the ClientKeyExchange message (when using | 'psk_identity' field of the ClientKeyExchange message (when using | |||
DTLS 1.2 [RFC6347]) or of the 'identity' field of a PSKIdentity, | DTLS 1.2 [RFC6347]) or of the 'identity' field of a PSKIdentity, | |||
within the PreSharedKeyExtension of a ClientHello message (when | within the PreSharedKeyExtension of a ClientHello message (when | |||
using DTLS 1.3 [RFC9147]). | using DTLS 1.3 [RFC9147]). | |||
* The (tagged) access token can be uploaded to the RS within the | * The access token can be uploaded to the RS within the MQTT CONNECT | |||
MQTT CONNECT packet, e.g., like it is defined in Section 2.2.4.1 | packet, e.g., like it is defined in Section 2.2.4.1 of [RFC9431]. | |||
of [RFC9431]. When doing so, TOKEN_INFO is specified within the | When doing so, TOKEN_INFO is specified within the 'Authentication | |||
'Authentication Data' field of the MQTT CONNECT packet, following | Data' field of the MQTT CONNECT packet, following the property | |||
the property identifier 22 (0x16) and the token length. | identifier 22 (0x16) and the token length. | |||
Note that, if the access token is a CWT, it is specifically tagged as | ||||
defined in Section 3. | ||||
4.1.3. Design Rationale | 4.1.3. Design Rationale | |||
Considering the possible variants discussed above, it must always be | Considering the possible variants discussed above, it must always be | |||
ensured that the same HASH_INPUT value is used as input for | ensured that the same HASH_INPUT value is used as input for | |||
generating the token hash of a given access token, by the AS that has | generating the token hash of a given access token, by the AS that has | |||
issued the access token and by the registered devices to which the | issued the access token and by the registered devices to which the | |||
access token pertains (both client and RS). | access token pertains (both client and RS). | |||
This is achieved by building HASH_INPUT according to the content of | This is achieved by building HASH_INPUT according to the content of | |||
the 'access_token' parameter in the AS-to-Client responses because | the 'access_token' parameter in the AS-to-Client responses because | |||
that is what the AS, the client, and the RS are all able to see. | that is what the AS, the client, and the RS are all able to see. | |||
4.2. Hash Input on the Client and the AS | 4.2. Hash Input on the Client and the AS | |||
The client and the AS consider the content of the 'access_token' | The client and the AS consider the content of the 'access_token' | |||
parameter in the AS-to-Client response, in which the (tagged) access | parameter in the AS-to-Client response, in which the access token is | |||
token is included and provided to the requester client. | included and provided to the requester client. Note that, if the | |||
access token is a CWT, it is specifically tagged as defined in | ||||
Section 3. | ||||
The following defines how the client and the AS determine the | The following defines how the client and the AS determine the | |||
HASH_INPUT value to use as input for computing the token hash of the | HASH_INPUT value to use as input for computing the token hash of the | |||
conveyed access token, depending on the AS-to-Client response being | conveyed access token, depending on the AS-to-Client response being | |||
encoded in CBOR (see Section 4.2.1) or in JSON (see Section 4.2.2). | encoded in CBOR (see Section 4.2.1) or in JSON (see Section 4.2.2). | |||
Once the HASH_INPUT is determined, the client and the AS use it to | Once the HASH_INPUT is determined, the client and the AS use it to | |||
compute the token hash of the conveyed access token as defined in | compute the token hash of the conveyed access token as defined in | |||
Section 4.4. | Section 4.4. | |||
4.2.1. AS-to-Client Response Encoded in CBOR | 4.2.1. AS-to-Client Response Encoded in CBOR | |||
If the AS-to-Client response is encoded in CBOR, then HASH_INPUT is | If the AS-to-Client response is encoded in CBOR, then HASH_INPUT is | |||
defined as follows: | defined as follows: | |||
* BYTES denotes the value of the CBOR byte string conveyed in the | * BYTES denotes the value of the CBOR byte string conveyed in the | |||
parameter 'access_token'. | 'access_token' parameter. | |||
With reference to the example in Figure 3, BYTES is the bytes | With reference to the example in Figure 3, BYTES is the bytes | |||
{0xd8 0x3d 0xd0 ... 0x64 0x3b}. | {0xd8, 0x3d, 0xd0, ..., 0x64, 0x3b}. | |||
Note that BYTES is the binary representation of the tagged access | Note that BYTES is the binary representation of the tagged access | |||
token if this is a CWT (as per Section 3) or of the access token | token if this is a CWT (as per Section 3) or of the access token | |||
if this is a JWT. | if this is a JWT. | |||
* HASH_INPUT_TEXT is the base64url-encoded text string that encodes | * HASH_INPUT_TEXT is the base64url-encoded text string that encodes | |||
BYTES. | BYTES. | |||
* HASH_INPUT is the binary representation of HASH_INPUT_TEXT. | * HASH_INPUT is the binary representation of HASH_INPUT_TEXT. | |||
skipping to change at line 868 ¶ | skipping to change at line 873 ¶ | |||
sha-256 as specified in [SHA-256] is mandatory to implement. | sha-256 as specified in [SHA-256] is mandatory to implement. | |||
The AS specifies the used hash function to registered devices during | The AS specifies the used hash function to registered devices during | |||
their registration procedure (see Section 10). | their registration procedure (see Section 10). | |||
5. Token Revocation List (TRL) | 5. Token Revocation List (TRL) | |||
Upon startup, the AS creates a single Token Revocation List (TRL) | Upon startup, the AS creates a single Token Revocation List (TRL) | |||
encoded as a CBOR array. | encoded as a CBOR array. | |||
Each element of the array is a CBOR byte string with value the token | Each element of the array is a CBOR byte string, whose value is the | |||
hash of an access token. The CBOR array MUST be treated as a set, | token hash of an access token. The CBOR array MUST be treated as a | |||
i.e., the order of its elements has no meaning. | set, i.e., the order of its elements has no meaning. | |||
The TRL is initialized as empty, i.e., its initial content MUST be | The TRL is initialized as empty, i.e., its initial content MUST be | |||
the empty CBOR array. The TRL is accessible through the TRL endpoint | the empty CBOR array. The TRL is accessible through the TRL endpoint | |||
at the AS. | at the AS. | |||
5.1. Update of the TRL | 5.1. Update of the TRL | |||
The AS updates the TRL in the following two cases: | The AS updates the TRL in the following two cases: | |||
* When a non-expired access token is revoked, the token hash of the | * When a non-expired access token is revoked, the token hash of the | |||
skipping to change at line 898 ¶ | skipping to change at line 903 ¶ | |||
encoding the TRL. | encoding the TRL. | |||
The AS MAY perform a single update to the TRL such that one or more | The AS MAY perform a single update to the TRL such that one or more | |||
token hashes are added or removed at once. For example, this can be | token hashes are added or removed at once. For example, this can be | |||
the case if multiple access tokens are revoked or expire at the same | the case if multiple access tokens are revoked or expire at the same | |||
time or within an acceptably narrow time frame. | time or within an acceptably narrow time frame. | |||
6. The TRL Endpoint | 6. The TRL Endpoint | |||
Consistent with Section 6.5 of [RFC9200], all communications between | Consistent with Section 6.5 of [RFC9200], all communications between | |||
a requester towards the TRL endpoint and the AS MUST be encrypted, as | the AS and a requester interacting with the TRL endpoint at the AS | |||
well as integrity and replay protected. Furthermore, responses from | MUST be encrypted, as well as integrity and replay protected. | |||
the AS to the requester MUST be bound to the corresponding requests. | Furthermore, responses from the AS to the requester MUST be bound to | |||
the corresponding requests. | ||||
Following a request to the TRL endpoint, the corresponding success | Following a request to the TRL endpoint, the corresponding success | |||
response messages sent by the AS use Content-Format "application/ace- | response messages sent by the AS use Content-Format "application/ace- | |||
trl+cbor". Their payload is formatted as a CBOR map, and the CBOR | trl+cbor". Their payload is formatted as a CBOR map, and the CBOR | |||
values used to abbreviate the parameters included therein are defined | values used to abbreviate the parameters included therein are defined | |||
in Section 12. | in Section 12. | |||
The AS MUST implement measures to prevent access to the TRL endpoint | The AS MUST implement measures to prevent access to the TRL endpoint | |||
by entities other than registered devices and authorized | by entities other than registered devices and authorized | |||
administrators (see Section 10). | administrators (see Section 10). | |||
skipping to change at line 922 ¶ | skipping to change at line 928 ¶ | |||
The TRL endpoint supports only the GET method, and allows two types | The TRL endpoint supports only the GET method, and allows two types | |||
of queries of the TRL: | of queries of the TRL: | |||
1. Full query: the AS returns the token hashes of the revoked access | 1. Full query: the AS returns the token hashes of the revoked access | |||
tokens currently in the TRL and pertaining to the requester. | tokens currently in the TRL and pertaining to the requester. | |||
The AS MUST support this type of query. The processing of a full | The AS MUST support this type of query. The processing of a full | |||
query and the related response format are defined in Section 7. | query and the related response format are defined in Section 7. | |||
2. Diff query: the AS returns a list of diff entries. Each diff | 2. Diff query: the AS returns a list of diff entries. Each diff | |||
entry is related to one update to the TRL, and it contains a set | entry is related to one update that occurred to the TRL, and it | |||
of token hashes pertaining to the requester. In particular, all | contains a set of token hashes pertaining to the requester. In | |||
such token hashes were added to the TRL or removed from the TRL | particular, all such token hashes were added to the TRL or | |||
at the update related to the diff entry in question. | removed from the TRL at the update related to the diff entry in | |||
question. | ||||
The AS MAY support this type of query. In such a case, the AS | The AS MAY support this type of query. In such a case, the AS | |||
maintains the history of updates to the TRL as defined in | maintains the history of updates to the TRL as defined in | |||
Section 6.2. The processing of a diff query and the related | Section 6.2. The processing of a diff query and the related | |||
response format are defined in Section 8. | response format are defined in Section 8. | |||
If it supports diff queries, the AS MAY additionally support its | If it supports diff queries, the AS MAY additionally support its | |||
"Cursor" extension, which has two benefits: | "Cursor" extension, which has two benefits: | |||
1. The AS can avoid excessively long messages when several diff | 1. The AS can avoid excessively long messages when several diff | |||
skipping to change at line 1064 ¶ | skipping to change at line 1071 ¶ | |||
particular method used to achieve this is implementation specific. | particular method used to achieve this is implementation specific. | |||
Each time the TRL changes, the AS performs the following operations | Each time the TRL changes, the AS performs the following operations | |||
for each requester: | for each requester: | |||
1. The AS considers the subset of the TRL pertaining to that | 1. The AS considers the subset of the TRL pertaining to that | |||
requester. If the TRL subset is not affected by this TRL update, | requester. If the TRL subset is not affected by this TRL update, | |||
the AS stops the processing for that requester. Otherwise, the | the AS stops the processing for that requester. Otherwise, the | |||
AS moves to step 2. | AS moves to step 2. | |||
2. The AS creates two sets "trl_patch" of token hashes, i.e., one | 2. The AS creates two trl_patch sets of token hashes, i.e., one | |||
"removed" set and one "added" set, as related to this TRL update. | "removed" set and one "added" set, as related to this TRL update. | |||
3. The AS fills the two sets with the token hashes of the removed | 3. The AS fills the two sets with the token hashes of the removed | |||
and added access tokens, respectively, from/to the TRL subset | and added access tokens, respectively, from/to the TRL subset | |||
considered at step 1. | considered at step 1. | |||
4. The AS creates a new series item that includes the two sets from | 4. The AS creates a new series item that includes the two sets from | |||
step 3. | step 3. | |||
5. If the update collection associated with the requester currently | 5. If the update collection associated with the requester currently | |||
skipping to change at line 1087 ¶ | skipping to change at line 1094 ¶ | |||
6. The AS adds the series item to the update collection associated | 6. The AS adds the series item to the update collection associated | |||
with the requester as the last (most recent) entry. | with the requester as the last (most recent) entry. | |||
6.2.1. Supporting the "Cursor" Extension | 6.2.1. Supporting the "Cursor" Extension | |||
If it supports the "Cursor" extension for diff queries, the AS also | If it supports the "Cursor" extension for diff queries, the AS also | |||
performs the following actions: | performs the following actions: | |||
The AS defines the single constant unsigned integer MAX_INDEX <= | The AS defines the single constant unsigned integer MAX_INDEX <= | |||
((2^64) - 1), where "^" is the exponentiation operator. The value of | ((2^64) - 1). The value of MAX_INDEX is REQUIRED to be at least | |||
MAX_INDEX is REQUIRED to be at least (MAX_N - 1) and is RECOMMENDED | (MAX_N - 1) and is RECOMMENDED to be at least ((2^32) - 1). | |||
to be at least ((2^32) - 1). MAX_INDEX SHOULD be orders of magnitude | MAX_INDEX SHOULD be orders of magnitude greater than MAX_N. | |||
greater than MAX_N. | ||||
The following applies separately for each requester's update | The following applies separately for each requester's update | |||
collection: | collection: | |||
* Each series item X in the update collection is also associated | * Each series item X in the update collection is also associated | |||
with an unsigned integer 'index', whose minimum value is 0 and | with an unsigned integer 'index', whose minimum value is 0 and | |||
whose maximum value is MAX_INDEX. The first series item ever | whose maximum value is MAX_INDEX. The first series item ever | |||
added to the update collection MUST have an 'index' with a value | added to the update collection MUST have an 'index' with a value | |||
of 0. | of 0. | |||
skipping to change at line 1177 ¶ | skipping to change at line 1183 ¶ | |||
maximum number of diff entries that a (notification) response | maximum number of diff entries that a (notification) response | |||
should include. | should include. | |||
If the AS does not support diff queries, it ignores the 'diff' | If the AS does not support diff queries, it ignores the 'diff' | |||
query parameter when present in the GET request and proceeds like | query parameter when present in the GET request and proceeds like | |||
when processing a full query of the TRL (see Section 7). | when processing a full query of the TRL (see Section 7). | |||
Otherwise, the AS MUST return a 4.00 (Bad Request) response in | Otherwise, the AS MUST return a 4.00 (Bad Request) response in | |||
case the 'diff' query parameter of the GET request specifies a | case the 'diff' query parameter of the GET request specifies a | |||
value that is neither 0 nor a positive integer, irrespective of | value that is neither 0 nor a positive integer, irrespective of | |||
the presence of the 'cursor' parameter and its value (see below). | the presence of the 'cursor' query parameter and its value (see | |||
The response MUST have Content-Format set to "application/concise- | below). The response MUST have Content-Format set to | |||
problem-details+cbor", and its payload is formatted as defined in | "application/concise-problem-details+cbor", and its payload is | |||
Section 6.1. Within the Custom Problem Detail entry 'ace-trl- | formatted as defined in Section 6.1. Within the Custom Problem | |||
error', the value of the 'error-id' field MUST be set to 0 | Detail entry 'ace-trl-error', the value of the 'error-id' field | |||
("Invalid parameter value"), and the 'cursor' field MUST NOT be | MUST be set to 0 ("Invalid parameter value"), and the 'cursor' | |||
present. | field MUST NOT be present. | |||
* 'cursor': if included, perform a diff query of the TRL together | * 'cursor': if included, perform a diff query of the TRL together | |||
with the "Cursor" extension, as defined in Section 9.2. Its value | with the "Cursor" extension, as defined in Section 9.2. Its value | |||
MUST be either 0 or a positive integer. If the 'cursor' query | MUST be either 0 or a positive integer. If the 'cursor' query | |||
parameter is included, then the 'diff' query parameter MUST also | parameter is included, then the 'diff' query parameter MUST also | |||
be included. | be included. | |||
If included, the 'cursor' query parameter specifies an unsigned | If included, the 'cursor' query parameter specifies an unsigned | |||
integer value that was provided by the AS in a previous response | integer value that was provided by the AS in a previous response | |||
from the TRL endpoint (see Sections 9.1, 9.2.2, and 9.2.3). | from the TRL endpoint (see Sections 9.1, 9.2.2, and 9.2.3). | |||
skipping to change at line 1216 ¶ | skipping to change at line 1222 ¶ | |||
If the AS supports both diff queries and the "Cursor" extension, | If the AS supports both diff queries and the "Cursor" extension, | |||
and the GET request specifies the 'cursor' query parameter, then | and the GET request specifies the 'cursor' query parameter, then | |||
the AS MUST return a 4.00 (Bad Request) response in case any of | the AS MUST return a 4.00 (Bad Request) response in case any of | |||
the conditions below holds. | the conditions below holds. | |||
The 4.00 (Bad Request) response MUST have Content-Format set to | The 4.00 (Bad Request) response MUST have Content-Format set to | |||
"application/concise-problem-details+cbor", and its payload is | "application/concise-problem-details+cbor", and its payload is | |||
formatted as defined in Section 6.1. | formatted as defined in Section 6.1. | |||
- The GET request does not specify the 'diff' query parameter, | - The GET request does not specify the 'diff' query parameter, | |||
irrespective of the value of the 'cursor' parameter. | irrespective of the value of the 'cursor' query parameter. | |||
Within the Custom Problem Detail entry 'ace-trl-error', the | Within the Custom Problem Detail entry 'ace-trl-error', the | |||
value of the 'error-id' field MUST be set to 1 ("Invalid set of | value of the 'error-id' field MUST be set to 1 ("Invalid set of | |||
parameters"), and the 'cursor' field MUST NOT be present. | parameters"), and the 'cursor' field MUST NOT be present. | |||
- The 'cursor' query parameter has a value that is neither 0 nor | - The 'cursor' query parameter has a value that is neither 0 nor | |||
a positive integer; otherwise, it has a value strictly greater | a positive integer; otherwise, it has a value strictly greater | |||
than MAX_INDEX (see Section 6.2.1). | than MAX_INDEX (see Section 6.2.1). | |||
Within the Custom Problem Detail entry 'ace-trl-error', the | Within the Custom Problem Detail entry 'ace-trl-error', the | |||
value of the 'error-id' field MUST be set to 0 ("Invalid | value of the 'error-id' field MUST be set to 0 ("Invalid | |||
parameter value"). The entry 'ace-trl-error' MUST include the | parameter value"). The entry 'ace-trl-error' MUST include the | |||
'cursor' field, whose value is either: | 'cursor' field, whose value is either: | |||
o the CBOR simple value null (0xf6), if the update collection | o the CBOR simple value null (0xf6), if the update collection | |||
associated with the requester is empty; or | associated with the requester is empty; or | |||
o the corresponding current value of 'last_index'. | o the corresponding current value of 'last_index'. | |||
- All of the following hold: the update collection associated | - All of the following hold: the update collection associated | |||
with the requester is not empty; no wraparound of its 'index' | with the requester is not empty; no wraparound of the 'index' | |||
value has occurred; and the 'cursor' query parameter has a | value has occurred; and the 'cursor' query parameter has a | |||
value strictly greater than the current 'last_index' on the | value strictly greater than the current 'last_index' on the | |||
update collection (see Section 6.2.1). | update collection (see Section 6.2.1). | |||
Within the Custom Problem Detail entry 'ace-trl-error', the | Within the Custom Problem Detail entry 'ace-trl-error', the | |||
value of the 'error-id' field MUST be set to 2 ("Out of bound | value of the 'error-id' field MUST be set to 2 ("Out of bound | |||
cursor value"), and the 'cursor' field MUST NOT be present. | cursor value"), and the 'cursor' field MUST NOT be present. | |||
7. Full Query of the TRL | 7. Full Query of the TRL | |||
skipping to change at line 1267 ¶ | skipping to change at line 1273 ¶ | |||
device to perform the necessary filtering on the TRL content. | device to perform the necessary filtering on the TRL content. | |||
* If the requester is an administrator, HASHES specifies all the | * If the requester is an administrator, HASHES specifies all the | |||
token hashes currently in the TRL. | token hashes currently in the TRL. | |||
2. The AS sends a 2.05 (Content) response to the requester. The | 2. The AS sends a 2.05 (Content) response to the requester. The | |||
response MUST have Content-Format set to "application/ace- | response MUST have Content-Format set to "application/ace- | |||
trl+cbor". The payload of the response is a CBOR map, which MUST | trl+cbor". The payload of the response is a CBOR map, which MUST | |||
be formatted as follows. | be formatted as follows. | |||
* The 'full_set' parameter MUST be included and specifies a CBOR | * The 'full_set' parameter MUST be included and MUST encode a | |||
array 'full_set_value'. Each element of 'full_set_value' is a | CBOR array 'full_set_value'. Each element of 'full_set_value' | |||
CBOR byte string with a value of one of the token hashes from | is a CBOR byte string with a value of one of the token hashes | |||
the set HASHES. If the set HASHES is empty, the 'full_set' | from the set HASHES. If the set HASHES is empty, the | |||
parameter specifies the empty CBOR array. | 'full_set' parameter specifies the empty CBOR array. | |||
The CBOR array MUST be treated as a set, i.e., the order of | The CBOR array MUST be treated as a set, i.e., the order of | |||
its elements has no meaning. | its elements has no meaning. | |||
* The 'cursor' parameter MUST be included if the AS supports | * The 'cursor' parameter MUST be included if the AS supports | |||
both diff queries and the related "Cursor" extension (see | both diff queries and the related "Cursor" extension (see | |||
Sections 6.2 and 6.2.1). Its value is set as specified in | Sections 6.2 and 6.2.1). Its value is set as specified in | |||
Section 9.1 and provides the requester with information for | Section 9.1 and provides the requester with information for | |||
performing a follow-up diff query using the "Cursor" extension | performing a follow-up diff query using the "Cursor" extension | |||
(see Section 9.2). | (see Section 9.2). | |||
skipping to change at line 1350 ¶ | skipping to change at line 1356 ¶ | |||
The prepared diff entries are related to the U most recent TRL | The prepared diff entries are related to the U most recent TRL | |||
updates pertaining to the requester, as maintained in the update | updates pertaining to the requester, as maintained in the update | |||
collection for that requester (see Section 6.2). In particular, | collection for that requester (see Section 6.2). In particular, | |||
the first diff entry refers to the most recent of such updates, | the first diff entry refers to the most recent of such updates, | |||
the second diff entry refers to the second from last of such | the second diff entry refers to the second from last of such | |||
updates, and so on. | updates, and so on. | |||
Each diff entry is a CBOR array 'diff_entry', which includes the | Each diff entry is a CBOR array 'diff_entry', which includes the | |||
following two elements: | following two elements: | |||
a. A 'trl_patch' set of token hashes encoded as a CBOR array | a. A trl_patch set of token hashes encoded as a CBOR array | |||
'removed'. Each element of the array is a CBOR byte string | 'removed'. Each element of the array is a CBOR byte string, | |||
with value the token hash of an access token such that it | whose value is the token hash of an access token such that it | |||
pertains to the requester and was removed from the TRL during | pertains to the requester and was removed from the TRL during | |||
the update associated with the diff entry. | the update associated with the diff entry. | |||
b. A 'trl_patch' set of token hashes encoded as a CBOR array | b. A trl_patch set of token hashes encoded as a CBOR array | |||
'added'. Each element of the array is a CBOR byte string | 'added'. Each element of the array is a CBOR byte string, | |||
with value the token hash of an access token such that it | whose value is the token hash of an access token such that it | |||
pertains to the requester and was added to the TRL during the | pertains to the requester and was added to the TRL during the | |||
update associated with the diff entry. | update associated with the diff entry. | |||
The CBOR arrays 'removed' and 'added' MUST be treated as sets, | The CBOR arrays 'removed' and 'added' MUST be treated as sets, | |||
i.e., the order of their elements has no meaning. | i.e., the order of their elements has no meaning. | |||
4. The AS prepares a 2.05 (Content) response for the requester. The | 4. The AS prepares a 2.05 (Content) response for the requester. The | |||
response MUST have Content-Format set to "application/ace- | response MUST have Content-Format set to "application/ace- | |||
trl+cbor". The payload of the response is a CBOR map, which MUST | trl+cbor". The payload of the response is a CBOR map, which MUST | |||
be formatted as follows: | be formatted as follows: | |||
* The 'diff_set' parameter MUST be present and specifies a CBOR | * The 'diff_set' parameter MUST be present and MUST encode a | |||
array 'diff_set_value' of U elements. Each element of | CBOR array 'diff_set_value' of U elements. Each element of | |||
'diff_set_value' specifies one of the CBOR arrays 'diff_entry' | 'diff_set_value' specifies one of the CBOR arrays 'diff_entry' | |||
prepared above as a diff entry. Note that U might have a | prepared above as a diff entry. Note that U might have a | |||
value of 0; in this case, 'diff_set_value' is the empty CBOR | value of 0; in this case, 'diff_set_value' is the empty CBOR | |||
array. | array. | |||
Within 'diff_set_value', any 'diff_entry' CBOR arrays MUST be | Within 'diff_set_value', any 'diff_entry' CBOR arrays MUST be | |||
sorted to reflect the corresponding updates to the TRL in | sorted to reflect the corresponding updates to the TRL in | |||
reverse chronological order. That is, the first 'diff_entry' | reverse chronological order. That is, the first 'diff_entry' | |||
element of 'diff_set_value' relates to the most recent TRL | element of 'diff_set_value' relates to the most recent TRL | |||
update pertaining to the requester. The second 'diff_entry' | update pertaining to the requester. The second 'diff_entry' | |||
skipping to change at line 1478 ¶ | skipping to change at line 1484 ¶ | |||
9.1. Response to Full Query | 9.1. Response to Full Query | |||
When processing a full query request to the TRL endpoint, the AS | When processing a full query request to the TRL endpoint, the AS | |||
composes a response as defined in Section 7. | composes a response as defined in Section 7. | |||
In particular, the 'cursor' parameter included in the CBOR map | In particular, the 'cursor' parameter included in the CBOR map | |||
carried in the response payload specifies either the CBOR simple | carried in the response payload specifies either the CBOR simple | |||
value null (0xf6) or a CBOR unsigned integer. | value null (0xf6) or a CBOR unsigned integer. | |||
The 'cursor' parameter MUST specify the CBOR simple value null (0xf6) | The 'cursor' parameter MUST encode the CBOR simple value null (0xf6) | |||
in case there are currently no TRL updates pertaining to the | in case there are currently no TRL updates pertaining to the | |||
requester, i.e., the update collection for that requester is empty. | requester, i.e., the update collection for that requester is empty. | |||
This is the case from when the requester registers at the AS until | This is the case from when the requester registers at the AS until | |||
the first update pertaining to that requester occurs to the TRL. | the first update pertaining to that requester occurs to the TRL. | |||
Otherwise, the 'cursor' parameter MUST specify a CBOR unsigned | Otherwise, the 'cursor' parameter MUST encode a CBOR unsigned | |||
integer. This MUST take the 'index' value of the last series item in | integer. The unsigned integer MUST take the 'index' value of the | |||
the update collection associated with the requester (see | last series item in the update collection associated with the | |||
Section 6.2.1) as corresponding to the most recent TRL update | requester (see Section 6.2.1) as corresponding to the most recent TRL | |||
pertaining to the requester. In fact, such a value is the current | update pertaining to the requester. In fact, such a value is the | |||
value of 'last_index' for the update collection associated with the | current value of 'last_index' for the update collection associated | |||
requester. | with the requester. | |||
9.2. Response to Diff Query | 9.2. Response to Diff Query | |||
When processing a diff query request to the TRL endpoint, the AS | When processing a diff query request to the TRL endpoint, the AS | |||
composes a response as defined in the following subsections. | composes a response as defined in the following subsections. | |||
9.2.1. Empty Collection | 9.2.1. Empty Collection | |||
If the update collection associated with the requester has no | If the update collection associated with the requester has no | |||
elements, the AS returns a 2.05 (Content) response. The response | elements, the AS returns a 2.05 (Content) response. The response | |||
MUST have Content-Format set to "application/ace-trl+cbor", and its | MUST have Content-Format set to "application/ace-trl+cbor", and its | |||
payload MUST be a CBOR map formatted as follows: | payload MUST be a CBOR map formatted as follows: | |||
* The 'diff_set' parameter MUST be included and specifies the empty | * The 'diff_set' parameter MUST be included and MUST encode the | |||
CBOR array. | empty CBOR array. | |||
* The 'cursor' parameter MUST be included and specifies the CBOR | * The 'cursor' parameter MUST be included and MUST encode the CBOR | |||
simple value null (0xf6). | simple value null (0xf6). | |||
* The 'more' parameter MUST be included and specifies the CBOR | * The 'more' parameter MUST be included and MUST encode the CBOR | |||
simple value false (0xf4). | simple value false (0xf4). | |||
Note that the above applies when the update collection associated | Note that the above applies when the update collection associated | |||
with the requester has no elements, regardless of whether or not the | with the requester has no elements, regardless of whether or not the | |||
'cursor' query parameter is included in the diff query request and | 'cursor' query parameter is included in the diff query request and | |||
irrespective of the specified unsigned integer value if present. | irrespective of the specified unsigned integer value if present. | |||
9.2.2. Cursor Not Specified in the Diff Query Request | 9.2.2. Cursor Not Specified in the Diff Query Request | |||
If the update collection associated with the requester is not empty | If the update collection associated with the requester is not empty | |||
skipping to change at line 1542 ¶ | skipping to change at line 1548 ¶ | |||
pertaining to the requester. | pertaining to the requester. | |||
If U > MAX_DIFF_BATCH, the prepared diff entries are the eldest of | If U > MAX_DIFF_BATCH, the prepared diff entries are the eldest of | |||
the last U series items in the update collection associated with | the last U series items in the update collection associated with | |||
the requester, as corresponding to the first L of the U most | the requester, as corresponding to the first L of the U most | |||
recent TRL updates pertaining to the requester. | recent TRL updates pertaining to the requester. | |||
* At step 4, the CBOR map to carry in the payload of the 2.05 | * At step 4, the CBOR map to carry in the payload of the 2.05 | |||
(Content) response MUST be formatted as follows: | (Content) response MUST be formatted as follows: | |||
- The 'diff_set' parameter MUST be present and specifies a CBOR | - The 'diff_set' parameter MUST be present and MUST encode a CBOR | |||
array 'diff_set_value' of L elements. Each element of | array 'diff_set_value' of L elements. Each element of | |||
'diff_set_value' specifies one of the CBOR arrays 'diff_entry' | 'diff_set_value' specifies one of the CBOR arrays 'diff_entry' | |||
prepared as a diff entry. | prepared as a diff entry. | |||
- The 'cursor' parameter MUST be present and specifies a CBOR | - The 'cursor' parameter MUST be present and MUST encode a CBOR | |||
unsigned integer. This MUST take the 'index' value of the | unsigned integer. The unsigned integer MUST take the 'index' | |||
series item of the update collection included as first diff | value of the series item of the update collection included as | |||
entry in the 'diff_set_value' CBOR array, which is specified by | first diff entry in the 'diff_set_value' CBOR array, which is | |||
the 'diff_set' parameter. That is, the 'cursor' parameter | specified by the 'diff_set' parameter. That is, the 'cursor' | |||
takes the 'index' value of the series item in the update | parameter takes the 'index' value of the series item in the | |||
collection corresponding to the most recent TRL update | update collection corresponding to the most recent TRL update | |||
pertaining to the requester and returned in this diff query | pertaining to the requester and returned in this diff query | |||
response. | response. | |||
Note that the 'cursor' parameter takes the same 'index' value | Note that the 'cursor' parameter takes the same 'index' value | |||
of the last series item in the update collection when U <= | of the last series item in the update collection when U <= | |||
MAX_DIFF_BATCH. | MAX_DIFF_BATCH. | |||
- The 'more' parameter MUST be present and MUST specify the CBOR | - The 'more' parameter MUST be present. The parameter MUST | |||
simple value false (0xf4) if U <= MAX_DIFF_BATCH or the CBOR | encode the CBOR simple value false (0xf4) if U <= | |||
simple value true (0xf5) otherwise. | MAX_DIFF_BATCH; otherwise, it MUST encode the CBOR simple value | |||
true (0xf5). | ||||
If the 'more' parameter in the payload of the received 2.05 (Content) | If the 'more' parameter in the payload of the received 2.05 (Content) | |||
response has a value of true, the requester can send a follow-up diff | response has a value of true, the requester can send a follow-up diff | |||
query request including the 'cursor' query parameter with the same | query request including the 'cursor' query parameter with the same | |||
value of the 'cursor' parameter specified in this diff query | value of the 'cursor' parameter specified in this diff query | |||
response. As defined in Section 9.2.3, this would result in the AS | response. As defined in Section 9.2.3, this would result in the AS | |||
transferring the following subset of series items as diff entries, | transferring the following subset of series items as diff entries, | |||
thus resuming from where interrupted in the previous transfer. | thus resuming from where interrupted in the previous transfer. | |||
9.2.3. Cursor Specified in the Diff Query Request | 9.2.3. Cursor Specified in the Diff Query Request | |||
skipping to change at line 1593 ¶ | skipping to change at line 1600 ¶ | |||
the requester. This occurs when the item Y (and possibly | the requester. This occurs when the item Y (and possibly | |||
further ones after it) has been previously removed from the | further ones after it) has been previously removed from the | |||
update collection for that requester (see step 5 at | update collection for that requester (see step 5 at | |||
Section 6.2). | Section 6.2). | |||
In this case, the AS returns a 2.05 (Content) response. The | In this case, the AS returns a 2.05 (Content) response. The | |||
response MUST have Content-Format set to "application/ace- | response MUST have Content-Format set to "application/ace- | |||
trl+cbor", and its payload MUST be a CBOR map formatted as | trl+cbor", and its payload MUST be a CBOR map formatted as | |||
follows: | follows: | |||
* The 'diff_set' parameter MUST be included and specifies | * The 'diff_set' parameter MUST be included and MUST encode | |||
the empty CBOR array. | the empty CBOR array. | |||
* The 'cursor' parameter MUST be included and specifies the | * The 'cursor' parameter MUST be included and MUST encode | |||
CBOR simple value null (0xf6). | the CBOR simple value null (0xf6). | |||
* The 'more' parameter MUST be included and specifies the | * The 'more' parameter MUST be included and MUST encode the | |||
CBOR simple value true (0xf5). | CBOR simple value true (0xf5). | |||
With the combination ('cursor', 'more') = (null, true), the | With the combination ('cursor', 'more') = (null, true), the | |||
AS is indicating that the update collection is, in fact, not | AS is indicating that the update collection is, in fact, not | |||
empty, but that one or more series items have been lost due | empty, but that one or more series items have been lost due | |||
to their removal. These include the item with 'index' value | to their removal. These include the item with 'index' value | |||
(P + 1) % (MAX_INDEX + 1) that the requester wished to | (P + 1) % (MAX_INDEX + 1) that the requester wished to | |||
obtain as the first one following the specified reference | obtain as the first one following the specified reference | |||
point with 'index' value P. | point with 'index' value P. | |||
skipping to change at line 1650 ¶ | skipping to change at line 1657 ¶ | |||
If SUB_U > MAX_DIFF_BATCH, the prepared diff entries are | If SUB_U > MAX_DIFF_BATCH, the prepared diff entries are | |||
the eldest of the last SUB_U series items in the update | the eldest of the last SUB_U series items in the update | |||
collection associated with the requester, corresponding | collection associated with the requester, corresponding | |||
to the first L of the SUB_U most recent TRL updates | to the first L of the SUB_U most recent TRL updates | |||
pertaining to the requester. | pertaining to the requester. | |||
* At step 4, the CBOR map to carry in the payload of the | * At step 4, the CBOR map to carry in the payload of the | |||
2.05 (Content) response MUST be formatted as follows: | 2.05 (Content) response MUST be formatted as follows: | |||
- The 'diff_set' parameter MUST be present and specifies | - The 'diff_set' parameter MUST be present and MUST | |||
a CBOR array 'diff_set_value' of L elements. Each | encode a CBOR array 'diff_set_value' of L elements. | |||
element of 'diff_set_value' specifies one of the CBOR | Each element of 'diff_set_value' specifies one of the | |||
arrays 'diff_entry' prepared as a diff entry. Note | CBOR arrays 'diff_entry' prepared as a diff entry. | |||
that L might have value 0, in which case | Note that L might have value 0, in which case | |||
'diff_set_value' is the empty CBOR array. | 'diff_set_value' is the empty CBOR array. | |||
- The 'cursor' parameter MUST be present and MUST | - The 'cursor' parameter MUST be present and MUST encode | |||
specify a CBOR unsigned integer. In particular: | a CBOR unsigned integer. In particular: | |||
o If L is equal to 0, i.e., the series item X is the | o If L is equal to 0, i.e., the series item X is the | |||
last one in the update collection, then the | last one in the update collection, then the | |||
'cursor' parameter MUST take the same 'index' value | 'cursor' parameter MUST take the same 'index' value | |||
of the last series item in the update collection. | of the last series item in the update collection. | |||
In fact, such a value is the current value of | In fact, such a value is the current value of | |||
'last_index' for the update collection. | 'last_index' for the update collection. | |||
o If L is different than 0, then the 'cursor' | o If L is different than 0, then the 'cursor' | |||
parameter MUST take the 'index' value of the series | parameter MUST take the 'index' value of the series | |||
skipping to change at line 1681 ¶ | skipping to change at line 1688 ¶ | |||
the 'cursor' parameter takes the 'index' value of | the 'cursor' parameter takes the 'index' value of | |||
the series item in the update collection | the series item in the update collection | |||
corresponding to the most recent TRL update | corresponding to the most recent TRL update | |||
pertaining to the requester and returned in this | pertaining to the requester and returned in this | |||
diff query response. | diff query response. | |||
Note that the 'cursor' parameter takes the same | Note that the 'cursor' parameter takes the same | |||
'index' value of the last series item in the update | 'index' value of the last series item in the update | |||
collection when SUB_U <= MAX_DIFF_BATCH. | collection when SUB_U <= MAX_DIFF_BATCH. | |||
- The 'more' parameter MUST be present and MUST specify | - The 'more' parameter MUST be present. The parameter | |||
the CBOR simple value false (0xf4) if SUB_U <= | MUST encode the CBOR simple value false (0xf4) if | |||
MAX_DIFF_BATCH, or the CBOR simple value true (0xf5) | SUB_U <= MAX_DIFF_BATCH; otherwise, it MUST encode the | |||
otherwise. | CBOR simple value true (0xf5). | |||
If the 'more' parameter in the payload of the received 2.05 | If the 'more' parameter in the payload of the received 2.05 | |||
(Content) response has value true, the requester can send a | (Content) response has value true, the requester can send a | |||
follow-up diff query request including the 'cursor' query | follow-up diff query request including the 'cursor' query | |||
parameter with the same value of the 'cursor' parameter | parameter with the same value of the 'cursor' parameter | |||
specified in this diff query response. This would result in | specified in this diff query response. This would result in | |||
the AS transferring the following subset of series items as | the AS transferring the following subset of series items as | |||
diff entries, thus, resuming from where interrupted in the | diff entries, thus, resuming from where interrupted in the | |||
previous transfer. | previous transfer. | |||
skipping to change at line 1760 ¶ | skipping to change at line 1767 ¶ | |||
To this end, the AS may rely on a local access control list or | To this end, the AS may rely on a local access control list or | |||
similar, which specifies the authentication credentials of trusted, | similar, which specifies the authentication credentials of trusted, | |||
authorized administrators. In particular, the AS verifies the | authorized administrators. In particular, the AS verifies the | |||
requester to the TRL endpoint as an authorized administrator only if | requester to the TRL endpoint as an authorized administrator only if | |||
the access control list includes the same authentication credential | the access control list includes the same authentication credential | |||
used by the requester when establishing the mutually authenticated | used by the requester when establishing the mutually authenticated | |||
secure communication association with the AS. | secure communication association with the AS. | |||
Further details about the registration process at the AS are out of | Further details about the registration process at the AS are out of | |||
scope for this specification. Note that the registration process is | scope for this specification. Note that the registration process is | |||
also out of the scope of the ACE framework for Authentication and | also out of the scope of the ACE framework (see Section 5.5 of | |||
Authorization (see Section 5.5 of [RFC9200]). | [RFC9200]). | |||
11. Notification of Revoked Access Tokens | 11. Notification of Revoked Access Tokens | |||
Once registered at the AS, the administrator or registered device can | Once registered at the AS, the administrator or registered device can | |||
send a GET request to the TRL endpoint at the AS. The request can | send a GET request to the TRL endpoint at the AS. The request can | |||
express the wish for a full query (see Section 7) or a diff query | express the wish for a full query (see Section 7) or a diff query | |||
(see Section 8) of the TRL. Also, the request can include the CoAP | (see Section 8) of the TRL. Also, the request can include the CoAP | |||
Observe Option set to 0 (register) in order to start an observation | Observe Option set to 0 (register) in order to start an observation | |||
of the TRL endpoint as per Section 3.1 of [RFC7641]. | of the TRL endpoint as per Section 3.1 of [RFC7641]. | |||
In case the request is successfully processed, the AS replies with a | In case the request is successfully processed, the AS replies with a | |||
response specifying the CoAP response code 2.05 (Content). In | 2.05 (Content) response. In particular, if the AS supports diff | |||
particular, if the AS supports diff queries but not the "Cursor" | queries but not the "Cursor" extension (see Sections 6.2 and 6.2.1), | |||
extension (see Sections 6.2 and 6.2.1), then the payload of the | then the payload of the response is formatted as defined in Sections | |||
response is formatted as defined in Sections 7 or 8, in case the GET | 7 or 8, in case the GET request has yielded the execution of a full | |||
request has yielded the execution of a full query or of a diff query | query or of a diff query of the TRL, respectively. Instead, if the | |||
of the TRL, respectively. Instead, if the AS supports both diff | AS supports both diff queries and the related "Cursor" extension, | |||
queries and the related "Cursor" extension, then the payload of the | then the payload of the response is formatted as defined in | |||
response is formatted as defined in Section 9. | Section 9. | |||
In case a requester does not receive a response from the TRL endpoint | In case a requester does not receive a response from the TRL endpoint | |||
or it receives an error response from the TRL endpoint, the requester | or it receives an error response from the TRL endpoint, the requester | |||
does not make any assumptions or draw any conclusions regarding the | does not make any assumptions or draw any conclusions regarding the | |||
revocation or expiration of its pertaining access tokens. The | revocation or expiration of its pertaining access tokens. The | |||
requester MAY try again by sending a new request to the TRL endpoint. | requester MAY try again by sending a new request to the TRL endpoint. | |||
When the TRL is updated (see Section 5.1), the AS sends Observe | When the TRL is updated (see Section 5.1), the AS sends Observe | |||
notifications to the observers whose pertaining subset of the TRL has | notifications to the observers whose pertaining subset of the TRL has | |||
changed. Observe notifications are sent as per Section 4.2 of | changed. Observe notifications are sent as per Section 4.2 of | |||
[RFC7641]. If supported by the AS, an observer may configure the | [RFC7641]. If supported by the AS, an observer may configure the | |||
behavior according to which the AS sends those Observe notifications. | behavior according to which the AS sends those Observe notifications. | |||
To this end, a possible way relies on the conditional control | To this end, a possible way relies on the conditional control | |||
attribute "c.pmax" defined in [CoRE-ATTRIBUTES], which can be | attribute "c.pmax" defined in [CoRE-ATTRIBUTES], which can be | |||
included as a "name=value" query parameter in an Observation Request. | included as a "name=value" query parameter in an Observation Request. | |||
This ensures that no more than c.pmax seconds elapse between two | This ensures that no more than c.pmax seconds elapse between two | |||
consecutive notifications sent to that observer, regardless of | consecutive notifications sent to that observer, regardless of | |||
whether or not the TRL has changed. | whether or not the TRL has changed. | |||
Following a first exchange with the AS, an administrator or a | Following a first exchange with the AS, an administrator or a | |||
registered device can send additional GET (Observation) requests to | registered device can send additional GET requests to the TRL | |||
the TRL endpoint at any time, analogously to what is defined above. | endpoint at any time, analogously to what is defined above. When | |||
When doing so, the requester towards the TRL endpoint can perform a | doing so, the requester towards the TRL endpoint can perform a full | |||
full query (see Section 7) or a diff query (see Section 8) of the | query (see Section 7) or a diff query (see Section 8) of the TRL. In | |||
TRL. In the latter case, the requester can additionally rely on the | the latter case, the requester can additionally rely on the "Cursor" | |||
"Cursor" extension (see Sections 6.3 and 9.2). | extension (see Sections 6.3 and 9.2). | |||
As specified in Section 6.2, an AS supporting diff queries maintains | As specified in Section 6.2, an AS supporting diff queries maintains | |||
an update collection of maximum MAX_N series items for each | an update collection of maximum MAX_N series items for each | |||
administrator or registered device, hereafter referred to as a | administrator or registered device, hereafter referred to as a | |||
"requester". In particular, if an update collection includes MAX_N | "requester". In particular, if an update collection includes MAX_N | |||
series items, adding a further series item to that update collection | series items, adding a further series item to that update collection | |||
results in deleting the oldest series item from that update | results in deleting the oldest series item from that update | |||
collection. | collection. | |||
From then on, the requester associated with the update collection | From then on, the requester associated with the update collection | |||
will not be able to retrieve the deleted series item when sending a | will not be able to retrieve the deleted series item when sending a | |||
new diff query request to the TRL endpoint. If that series item | new diff query request to the TRL endpoint. If that series item | |||
reflected the revocation of an access token pertaining to the | reflected the revocation of an access token pertaining to the | |||
requester, then the requester will not learn about that when | requester, then the requester will not learn about that when | |||
receiving the corresponding diff query response from the AS. | receiving the corresponding diff query response from the AS. | |||
Sending a diff query request specifically as an Observation Request, | Sending a diff query request specifically as an Observation Request, | |||
and, thus, relying on Observe notifications, largely reduces the | and, thus, relying on Observe notifications, largely reduces the | |||
chances for a requester to miss updates to its associated update | chances for a requester to miss updates that have occurred to its | |||
collection. In turn, this relies on the requester successfully | associated update collection. In turn, this relies on the requester | |||
receiving the Observe notification responses from the TRL (see also | successfully receiving the Observe notification responses from the | |||
Section 14.3). | TRL (see also Section 14.3). | |||
In order to limit the amount of time during which the requester is | In order to limit the amount of time during which the requester is | |||
unaware of pertaining access tokens that have been revoked but are | unaware of pertaining access tokens that have been revoked but are | |||
not expired yet, a requester SHOULD NOT rely solely on diff query | not expired yet, a requester SHOULD NOT rely solely on diff query | |||
requests. In particular, a requester SHOULD also regularly send a | requests. In particular, a requester SHOULD also regularly send a | |||
full query request to the TRL endpoint according to a related | full query request to the TRL endpoint according to a related | |||
application policy. | application policy. | |||
11.1. Handling of Revoked Access Tokens and Token Hashes | 11.1. Handling of Revoked Access Tokens and Token Hashes | |||
skipping to change at line 1937 ¶ | skipping to change at line 1944 ¶ | |||
2. is uploaded at the RS for the first time after it has been | 2. is uploaded at the RS for the first time after it has been | |||
revoked and later expired, and | revoked and later expired, and | |||
3. has the sequence number encoded in the 'cti' claim (for CWTs) or | 3. has the sequence number encoded in the 'cti' claim (for CWTs) or | |||
in the 'jti' claim (for JWTs) greater than the highest sequence | in the 'jti' claim (for JWTs) greater than the highest sequence | |||
number among the expired access tokens specifying the 'exi' claim | number among the expired access tokens specifying the 'exi' claim | |||
for the RS (see Section 5.10.3 of [RFC9200]). That is, the RS | for the RS (see Section 5.10.3 of [RFC9200]). That is, the RS | |||
would not accept such a revoked and expired access token as long | would not accept such a revoked and expired access token as long | |||
as it stores the corresponding token hash. | as it stores the corresponding token hash. | |||
In order to further limit such a risk, when receiving an access token | This risk can be further limited. Specifically, if token | |||
that specifies the 'exi' claim and for which a corresponding token | introspection is implemented by both the RS and the AS, the RS can | |||
hash is not stored, the RS can introspect the access token (see | introspect the access token (see Section 5.9 of [RFC9200]) when | |||
Section 5.9 of [RFC9200]), if token introspection is implemented by | receiving an access token that specifies the 'exi' claim and for | |||
both the RS and the AS. | which a corresponding token hash is not stored. | |||
When, due to the stored and corresponding token hash th2, an access | When, due to the stored and corresponding token hash th2, an access | |||
token t2 that includes the 'exi' claim is expunged or is not accepted | token t2 that includes the 'exi' claim is expunged or is not accepted | |||
upon its upload, the RS retrieves the sequence number sn2 encoded in | upon its upload, the RS retrieves the sequence number sn2 encoded in | |||
the 'cti' claim (for CWTs) or in the 'jti' claim (for JWTs) (see | the 'cti' claim (for CWTs) or in the 'jti' claim (for JWTs) (see | |||
Section 5.10.3 of [RFC9200]). Then, the RS stores sn2 as associated | Section 5.10.3 of [RFC9200]). Then, the RS stores sn2 as associated | |||
with th2. If expunging or not accepting t2 yields the deletion of | with th2. If expunging or not accepting t2 yields the deletion of | |||
th2, then the RS MUST associate sn2 with th2 before continuing with | th2, then the RS MUST associate sn2 with th2 before continuing with | |||
the deletion of th2. | the deletion of th2. | |||
skipping to change at line 2016 ¶ | skipping to change at line 2023 ¶ | |||
+-------+---------------------------+ | +-------+---------------------------+ | |||
| 2 | Out of bound cursor value | | | 2 | Out of bound cursor value | | |||
+-------+---------------------------+ | +-------+---------------------------+ | |||
Table 2: ACE Token Revocation | Table 2: ACE Token Revocation | |||
List Error Identifiers | List Error Identifiers | |||
14. Security Considerations | 14. Security Considerations | |||
The protocol defined in this document inherits the security | The protocol defined in this document inherits the security | |||
considerations from the ACE framework for Authentication and | considerations from the ACE framework [RFC9200], the usage of CWTs | |||
Authorization [RFC9200], the usage of CWTs from [RFC8392], the usage | from [RFC8392], the usage of JWTs from [RFC7519] and [RFC8725], the | |||
of JWTs from [RFC7519] and [RFC8725], the usage of CoAP Observe from | usage of CoAP Observe from [RFC7641], and computation of the token | |||
[RFC7641], and computation of the token hashes from [RFC6920]. The | hashes from [RFC6920]. The following considerations also apply. | |||
following considerations also apply. | ||||
14.1. Content Retrieval from the TRL | 14.1. Content Retrieval from the TRL | |||
The AS MUST ensure that each registered device can access and | The AS MUST ensure that each registered device can access and | |||
retrieve only its pertaining subset of the TRL. To this end, the AS | retrieve only its pertaining subset of the TRL. To this end, the AS | |||
can always perform the required filtering based on the authenticated | can always perform the required filtering based on the authenticated | |||
identity of the registered device, i.e., a (non-public) identifier | identity of the registered device, i.e., a (non-public) identifier | |||
that the AS can securely relate to the registered device and the | that the AS can securely relate to the registered device and the | |||
secure association that they use to communicate. | secure association that they use to communicate. | |||
skipping to change at line 2104 ¶ | skipping to change at line 2110 ¶ | |||
* the access token has been revoked, the RS has become aware of it, | * the access token has been revoked, the RS has become aware of it, | |||
and the RS has expunged the access token, but the client is not | and the RS has expunged the access token, but the client is not | |||
aware of this (yet). | aware of this (yet). | |||
* the access token is still valid, but an on-path active adversary | * the access token is still valid, but an on-path active adversary | |||
might have injected a forged 4.01 (Unauthorized) response or the | might have injected a forged 4.01 (Unauthorized) response or the | |||
RS might have deleted the access token from its local storage due | RS might have deleted the access token from its local storage due | |||
to its dedicated storage space being all consumed. | to its dedicated storage space being all consumed. | |||
In either case, if the client believes that the access token is still | In either case, if the client believes that the access token is still | |||
valid, it SHOULD NOT immediately ask for a new access token to the | valid, it SHOULD NOT immediately ask for a new access token to the AS | |||
authorization server upon receiving a 4.01 (Unauthorized) response | upon receiving a 4.01 (Unauthorized) response from the RS. Instead, | |||
from the RS. Instead, the client SHOULD send a request to the TRL | the client SHOULD send a request to the TRL endpoint at the AS. If | |||
endpoint at the AS. If the client gains knowledge that the access | the client gains knowledge that the access token is not valid | |||
token is not valid anymore, the client expunges the access token and | anymore, the client expunges the access token and can ask for a new | |||
can ask for a new one. Otherwise, the client can try again to upload | one. Otherwise, the client can try again to upload the same access | |||
the same access token to the RS or request a new one. | token to the RS or request a new one. | |||
14.5. Vulnerable Time Window at the RS | 14.5. Vulnerable Time Window at the RS | |||
A client may attempt to access a protected resource at an RS after | A client may attempt to access a protected resource at an RS after | |||
the access token allowing such an access has been revoked but before | the access token allowing such an access has been revoked but before | |||
the RS is aware of the revocation. | the RS is aware of the revocation. | |||
In such a case, if the RS is still storing the access token, the | In such a case, if the RS is still storing the access token, the | |||
client will be able to access the protected resource even though it | client will be able to access the protected resource even though it | |||
should not. Such access is a security violation, even if the client | should not. Such access is a security violation, even if the client | |||
skipping to change at line 2214 ¶ | skipping to change at line 2220 ¶ | |||
While this asymmetry cannot be avoided altogether, the method defined | While this asymmetry cannot be avoided altogether, the method defined | |||
for the AS and the client in Section 4.2 deliberately penalizes the | for the AS and the client in Section 4.2 deliberately penalizes the | |||
case where the RS uses JWTs as access tokens. In such a case, the RS | case where the RS uses JWTs as access tokens. In such a case, the RS | |||
effectively neutralizes the attack described above by computing and | effectively neutralizes the attack described above by computing and | |||
storing two token hashes associated with the same access token (see | storing two token hashes associated with the same access token (see | |||
Section 4.3.2). | Section 4.3.2). | |||
Conversely, this design deliberately favors the case where the RS | Conversely, this design deliberately favors the case where the RS | |||
uses CWTs as access tokens, which is a preferable option for | uses CWTs as access tokens, which is a preferable option for | |||
resource-constrained RSs as well as the default case in the ACE | resource-constrained RSs as well as the default case in the ACE | |||
framework for Authentication and Authorization (see Section 3 of | framework (see Section 3 of [RFC9200]). That is, if an RS uses CWTs | |||
[RFC9200]). That is, if an RS uses CWTs as access tokens, then the | as access tokens, then the RS is not exposed to the attack described | |||
RS is not exposed to the attack described above; thus, it safely | above; thus, it safely computes and stores only one token hash per | |||
computes and stores only one token hash per access token (see | access token (see Section 4.3.1). | |||
Section 4.3.1). | ||||
14.8. Additional Security Measures | 14.8. Additional Security Measures | |||
By accessing the TRL at the AS, registered devices and administrators | By accessing the TRL at the AS, registered devices and administrators | |||
are able to learn that their pertaining access tokens have been | are able to learn that their pertaining access tokens have been | |||
revoked. However, they cannot learn the reason why, including when | revoked. However, they cannot learn the reason why, including when | |||
that reason is the compromise, misbehavior, or decommissioning of a | that reason is the compromise, misbehavior, or decommissioning of a | |||
registered device. | registered device. | |||
In fact, even the AS might not know that a registered device to which | In fact, even the AS might not know that a registered device to which | |||
skipping to change at line 2280 ¶ | skipping to change at line 2285 ¶ | |||
Encoding considerations: Must be encoded as a CBOR map containing | Encoding considerations: Must be encoded as a CBOR map containing | |||
the protocol parameters defined in RFC 9770. | the protocol parameters defined in RFC 9770. | |||
Security considerations: See Section 14 of this document. | Security considerations: See Section 14 of this document. | |||
Interoperability considerations: N/A | Interoperability considerations: N/A | |||
Published specification: RFC 9770 | Published specification: RFC 9770 | |||
Applications that use this media type: The type is used by | Applications that use this media type: The type is used by | |||
authorization servers, clients, and resource servers that support | authorization servers, clients, and RSs that support the | |||
the notification of revoked access tokens according to a Token | notification of revoked access tokens according to a Token | |||
Revocation List maintained by the authorization server as | Revocation List maintained by the authorization server as | |||
specified in RFC 9770. | specified in RFC 9770. | |||
Fragment identifier considerations: N/A | Fragment identifier considerations: N/A | |||
Additional information: N/A | Additional information: N/A | |||
Person & email address to contact for further information: ACE WG | Person & email address to contact for further information: ACE WG | |||
mailing list (ace@ietf.org) or IETF Applications and Real-Time | mailing list (ace@ietf.org) or IETF Applications and Real-Time | |||
Area (art@ietf.org) | Area (art@ietf.org) | |||
skipping to change at line 2665 ¶ | skipping to change at line 2670 ¶ | |||
Since the update collection associated with each requester includes | Since the update collection associated with each requester includes | |||
up to MAX_N series items, the AS deletes the oldest series item when | up to MAX_N series items, the AS deletes the oldest series item when | |||
a new one is generated and added to the end of the update collection, | a new one is generated and added to the end of the update collection, | |||
due to a new TRL update pertaining to that requester (see | due to a new TRL update pertaining to that requester (see | |||
Section 6.2). This addresses the question "When can the server | Section 6.2). This addresses the question "When can the server | |||
decide to no longer retain older items?" raised in Section 3.2 of | decide to no longer retain older items?" raised in Section 3.2 of | |||
[STP]. | [STP]. | |||
Furthermore, performing a diff query of the TRL together with the | Furthermore, performing a diff query of the TRL together with the | |||
"Cursor" extension, as specified in Section 9, in fact, relies on the | "Cursor" extension, as specified in Section 9, in fact, relies on the | |||
"Cursor" pattern of the STP (see Section 3.3 of [STP]). | "cursor" pattern of the STP (see Section 3.3 of [STP]). | |||
Appendix B. Local Supportive Parameters of the TRL Endpoint | Appendix B. Local Supportive Parameters of the TRL Endpoint | |||
Table 3 provides an aggregated overview of the local supportive | Table 3 provides an aggregated overview of the local supportive | |||
parameters that the AS internally uses at its TRL endpoint when | parameters that the AS internally uses at its TRL endpoint when | |||
supporting diff queries (see Section 6) and the "Cursor" extension | supporting diff queries (see Section 6) and the "Cursor" extension | |||
(see Section 6.2.1). | (see Section 6.2.1). | |||
Except for MAX_N defined in Section 6.2, all the other parameters are | Except for MAX_N defined in Section 6.2, all the other parameters are | |||
defined in Section 6.2.1 and are used only if the AS supports the | defined in Section 6.2.1 and are used only if the AS supports the | |||
skipping to change at line 2693 ¶ | skipping to change at line 2698 ¶ | |||
a parameter whose value does not change after its initialization. | a parameter whose value does not change after its initialization. | |||
Single instance: "Y" if there is a single parameter instance | Single instance: "Y" if there is a single parameter instance | |||
associated with the TRL or "N" if there is one parameter instance | associated with the TRL or "N" if there is one parameter instance | |||
per update collection (i.e., per requester). | per update collection (i.e., per requester). | |||
Description: A short description of the parameter. | Description: A short description of the parameter. | |||
Values: The unsigned integer values that the parameter can assume, | Values: The unsigned integer values that the parameter can assume, | |||
where LB and UB denote the inclusive lower bound and upper bound, | where LB and UB denote the inclusive lower bound and upper bound, | |||
respectively, and "^" is the exponentiation operator. | respectively. | |||
+================+==========+====================+==================+ | +================+==========+====================+==================+ | |||
| Name | Single | Description | Values | | | Name | Single | Description | Values | | |||
| | instance | | | | | | instance | | | | |||
+================+==========+====================+==================+ | +================+==========+====================+==================+ | |||
| MAX_N | Y | Max number of | LB = 1 | | | MAX_N | Y | Max number of | LB = 1 | | |||
| | | series items in | | | | | | series items in | | | |||
| | | the update | If supporting | | | | | the update | If supporting | | |||
| | | collection of | "Cursor", then | | | | | collection of each | the "Cursor" | | |||
| | | each requester | UB = MAX_INDEX+1 | | | | | requester | extension, then | | |||
| | | | UB = | | ||||
| | | | MAX_INDEX+1 | | ||||
+----------------+----------+--------------------+------------------+ | +----------------+----------+--------------------+------------------+ | |||
| MAX_DIFF_BATCH | N | Max number of | LB = 1 | | | MAX_DIFF_BATCH | N | Max number of diff | LB = 1 | | |||
| | | diff entries | | | | | | entries included | | | |||
| | | included in a | UB = MAX_N | | | | | in a diff query | UB = MAX_N | | |||
| | | diff query | | | ||||
| | | response when | | | | | | response when | | | |||
| | | using "Cursor" | | | | | | using the "Cursor" | | | |||
| | | extension | | | ||||
+----------------+----------+--------------------+------------------+ | +----------------+----------+--------------------+------------------+ | |||
| MAX_INDEX | Y | Max value of each | LB = MAX_N-1 | | | MAX_INDEX | Y | Max value of each | LB = MAX_N-1 | | |||
| | | instance of the | | | | | | instance of | | | |||
| | | 'index' parameter | UB = (2^64)-1 | | | | | 'index' | UB = (2^64)-1 | | |||
+----------------+----------+--------------------+------------------+ | +----------------+----------+--------------------+------------------+ | |||
| index | N | Value associated | LB = 0 | | | index | N | Value associated | LB = 0 | | |||
| | | with a series | | | | | | with a series item | | | |||
| | | item of an update | UB = MAX_INDEX | | | | | of an update | UB = MAX_INDEX | | |||
| | | collection | | | | | | collection | | | |||
+----------------+----------+--------------------+------------------+ | +----------------+----------+--------------------+------------------+ | |||
| last_index | N | The 'index' value | LB = 0 | | | last_index | N | The 'index' value | LB = 0 | | |||
| | | of the most | | | | | | of the most | | | |||
| | | recently added | UB = MAX_INDEX | | | | | recently added | UB = MAX_INDEX | | |||
| | | series item in an | | | | | | series item in an | | | |||
| | | update collection | | | | | | update collection | | | |||
+----------------+----------+--------------------+------------------+ | +----------------+----------+--------------------+------------------+ | |||
Table 3: Local Supportive Parameters of the TRL Endpoint | Table 3: Local Supportive Parameters of the TRL Endpoint | |||
skipping to change at line 2761 ¶ | skipping to change at line 2768 ¶ | |||
* a 'max_n' parameter specifying the value of MAX_N, i.e., the | * a 'max_n' parameter specifying the value of MAX_N, i.e., the | |||
maximum number of series items that the AS retains in the update | maximum number of series items that the AS retains in the update | |||
collection associated with a registered device (see Section 8); | collection associated with a registered device (see Section 8); | |||
* possible further parameters related to the registration process. | * possible further parameters related to the registration process. | |||
Furthermore, 'h(x)' refers to the hash function used to compute the | Furthermore, 'h(x)' refers to the hash function used to compute the | |||
token hashes, as defined in Section 4 of this specification and | token hashes, as defined in Section 4 of this specification and | |||
according to [RFC6920]. Assuming the usage of CWTs transported in | according to [RFC6920]. Assuming the usage of CWTs transported in | |||
AS-to-Client responses encoded in CBOR (see Section 4.2.1), | AS-to-Client responses encoded in CBOR (see Section 4.2.1), | |||
'bstr.h(t1)' and 'bstr.h(t2)' denote the CBOR byte strings with value | 'bstr.h(t1)' and 'bstr.h(t2)' denote the CBOR byte strings, whose | |||
the token hashes of the access tokens t1 and t2, respectively. | values are the token hashes of the access tokens t1 and t2, | |||
respectively. | ||||
C.1. Full Query with Observe | C.1. Full Query with Observe | |||
Figure 10 shows an interaction example considering a CoAP observation | Figure 10 shows an interaction example considering a CoAP observation | |||
and a full query of the TRL. | and a full query of the TRL. | |||
In this example, the AS does not support the "Cursor" extension. | In this example, the AS does not support the "Cursor" extension. | |||
Hence, the 'cursor' parameter is not included in the payload of the | Hence, the 'cursor' parameter is not included in the payload of the | |||
responses to a full query request. | responses to a full query request. | |||
skipping to change at line 2963 ¶ | skipping to change at line 2971 ¶ | |||
| e'diff_set' : [ | | | e'diff_set' : [ | | |||
| [ [bstr.h(t2)], [] ], | | | [ [bstr.h(t2)], [] ], | | |||
| [ [bstr.h(t1)], [] ], | | | [ [bstr.h(t1)], [] ], | | |||
| [ [], [bstr.h(t2)] ] | | | [ [], [bstr.h(t2)] ] | | |||
| ] | | | ] | | |||
| } | | | } | | |||
| | | | | | |||
Figure 11: Interaction for Diff Query with Observe | Figure 11: Interaction for Diff Query with Observe | |||
C.3. Full Query with Observe Plus Diff Query | C.3. Full Query with Observe and Diff Query | |||
Figure 12 shows an interaction example of a CoAP observation and a | Figure 12 shows an interaction example of a CoAP observation and a | |||
full query of the TRL. | full query of the TRL. | |||
The example also shows one of the notifications from the AS getting | The example also shows one of the notifications from the AS getting | |||
lost in transmission; thus, it does not reach the RS. | lost in transmission; thus, it does not reach the RS. | |||
When this happens, and after a waiting time defined by the | When this happens, and after a waiting time defined by the | |||
application has elapsed, the RS sends a GET request with no Observe | application has elapsed, the RS sends a GET request with no Observe | |||
Option to the AS to perform a diff query of the TRL. The RS | Option to the AS to perform a diff query of the TRL. The RS | |||
skipping to change at line 3085 ¶ | skipping to change at line 3093 ¶ | |||
| Payload: { | | | Payload: { | | |||
| e'diff_set' : [ | | | e'diff_set' : [ | | |||
| [ [bstr.h(t2)], [] ], | | | [ [bstr.h(t2)], [] ], | | |||
| [ [bstr.h(t1)], [] ], | | | [ [bstr.h(t1)], [] ], | | |||
| [ [], [bstr.h(t2)] ], | | | [ [], [bstr.h(t2)] ], | | |||
| [ [], [bstr.h(t1)] ] | | | [ [], [bstr.h(t1)] ] | | |||
| ] | | | ] | | |||
| } | | | } | | |||
| | | | | | |||
Figure 12: Interaction for Full Query with Observe Plus Diff Query | Figure 12: Interaction for Full Query with Observe and Diff Query | |||
C.4. Diff Query with Observe and "Cursor" | C.4. Diff Query with Observe and "Cursor" Extension | |||
In this example, the AS supports the "Cursor" extension. Hence, the | In this example, the AS supports the "Cursor" extension. Hence, the | |||
CBOR map conveyed as payload of the registration response | CBOR map conveyed as payload of the registration response | |||
additionally includes a "max_diff_batch" parameter. This specifies | additionally includes a "max_diff_batch" parameter. This specifies | |||
the value of MAX_DIFF_BATCH, i.e., the maximum number of diff entries | the value of MAX_DIFF_BATCH, i.e., the maximum number of diff entries | |||
that can be included in a response to a diff query request from this | that can be included in a response to a diff query request from this | |||
RS. | RS. | |||
Figure 13 shows an interaction example of a CoAP observation and a | Figure 13 shows an interaction example of a CoAP observation and a | |||
diff query of the TRL. | diff query of the TRL. | |||
The RS specifies the query parameter 'diff' with a value of 3, i.e., | The RS specifies the 'diff' query parameter with a value of 3, i.e., | |||
the maximum number of diff entries to be specified in a response from | the maximum number of diff entries to be specified in a response from | |||
the AS. | the AS. | |||
If the RS has not received a notification from the AS after a waiting | If the RS has not received a notification from the AS after a waiting | |||
time defined by the application, the RS sends a GET request with no | time defined by the application, the RS sends a GET request with no | |||
Observe Option to the AS to perform a diff query of the TRL. | Observe Option to the AS to perform a diff query of the TRL. | |||
This is followed up by a further diff query request that specifies | This is followed up by a further diff query request that specifies | |||
the query parameter 'cursor'. Note that the payload of the | the 'cursor' query parameter. Note that the payload of the | |||
corresponding response differs from the payload of the response to | corresponding response differs from the payload of the response to | |||
the previous diff query request. | the previous diff query request. | |||
RS AS | RS AS | |||
| | | | | | |||
| Registration: POST | | | Registration: POST | | |||
+------------------------------------------------------->| | +------------------------------------------------------->| | |||
| | | | | | |||
|<-------------------------------------------------------+ | |<-------------------------------------------------------+ | |||
| 2.01 Created | | | 2.01 Created | | |||
skipping to change at line 3251 ¶ | skipping to change at line 3259 ¶ | |||
| 2.05 Content | | | 2.05 Content | | |||
| Content-Format: application/ace-trl+cbor | | | Content-Format: application/ace-trl+cbor | | |||
| Payload: { | | | Payload: { | | |||
| e'diff_set' : [], | | | e'diff_set' : [], | | |||
| e'cursor' : 3, | | | e'cursor' : 3, | | |||
| e'more' : false | | | e'more' : false | | |||
| } | | | } | | |||
| | | | | | |||
Figure 13: Interaction for Diff Query with Observe and "Cursor" | Figure 13: Interaction for Diff Query with Observe and "Cursor" | |||
Extension | ||||
C.5. Full Query with Observe Plus Diff Query with "Cursor" | C.5. Full Query with Observe and Diff Query with "Cursor" Extension | |||
In this example, the AS supports the "Cursor" extension. Hence, the | In this example, the AS supports the "Cursor" extension. Hence, the | |||
CBOR map conveyed as payload of the registration response | CBOR map conveyed as payload of the registration response | |||
additionally includes a "max_diff_batch" parameter. This specifies | additionally includes a "max_diff_batch" parameter. This specifies | |||
the value of MAX_DIFF_BATCH, i.e., the maximum number of diff entries | the value of MAX_DIFF_BATCH, i.e., the maximum number of diff entries | |||
that can be included in a response to a diff query request from this | that can be included in a response to a diff query request from this | |||
RS. | RS. | |||
Figure 14 shows an interaction example of a CoAP observation and a | Figure 14 shows an interaction example of a CoAP observation and a | |||
full query of the TRL. | full query of the TRL. | |||
The example also shows some of the notifications from the AS getting | The example also shows some of the notifications from the AS getting | |||
lost in transmission; thus, they do not reach the RS. | lost in transmission; thus, they do not reach the RS. | |||
When this happens, and after a waiting time defined by the | When this happens, and after a waiting time defined by the | |||
application has elapsed, the RS sends a GET request with no Observe | application has elapsed, the RS sends a GET request with no Observe | |||
Option to the AS, to perform a diff query of the TRL. In particular, | Option to the AS, to perform a diff query of the TRL. In particular, | |||
the RS specifies: | the RS specifies: | |||
* The query parameter 'diff' with a value of 8, i.e., the maximum | * The 'diff' query parameter with a value of 8, i.e., the maximum | |||
number of diff entries to be specified in a response from the AS. | number of diff entries to be specified in a response from the AS. | |||
* The query parameter 'cursor' with a value of 2, thus requesting | * The 'cursor' query parameter with a value of 2, thus requesting | |||
from the update collection the series items following the one with | from the update collection the series items following the one with | |||
the 'index' value equal to 2 (i.e., following the last series item | the 'index' value equal to 2 (i.e., following the last series item | |||
that the RS successfully received in an earlier notification | that the RS successfully received in an earlier notification | |||
response). | response). | |||
The response from the AS conveys a first batch of MAX_DIFF_BATCH = 5 | The response from the AS conveys a first batch of MAX_DIFF_BATCH = 5 | |||
series items from the update collection corresponding to the RS. The | series items from the update collection corresponding to the RS. The | |||
AS indicates that further series items are actually available in the | AS indicates that further series items are actually available in the | |||
update collection by setting the 'more' parameter of the response to | update collection by setting the 'more' parameter of the response to | |||
true. Also, the 'cursor' parameter of the response is set to 7, | true. Also, the 'cursor' parameter of the response is set to 7, | |||
i.e., to the 'index' value of the most recent series item included in | i.e., to the 'index' value of the most recent series item included in | |||
the response. | the response. | |||
After that, the RS follows up with a further diff query request | After that, the RS follows up with a further diff query request | |||
specifying the query parameter 'cursor' with a value of 7 in order to | specifying the 'cursor' query parameter with a value of 7 in order to | |||
retrieve the next and last batch of series items from the update | retrieve the next and last batch of series items from the update | |||
collection. | collection. | |||
RS AS | RS AS | |||
| | | | | | |||
| Registration: POST | | | Registration: POST | | |||
+-------------------------------------------------------------->| | +-------------------------------------------------------------->| | |||
| | | | | | |||
|<--------------------------------------------------------------+ | |<--------------------------------------------------------------+ | |||
| 2.01 Created | | | 2.01 Created | | |||
skipping to change at line 3516 ¶ | skipping to change at line 3525 ¶ | |||
| e'diff_set' : [ | | | e'diff_set' : [ | | |||
| [ [bstr.h(t6)], [] ], | | | [ [bstr.h(t6)], [] ], | | |||
| [ [bstr.h(t5)], [] ], | | | [ [bstr.h(t5)], [] ], | | |||
| [ [], [bstr.h(t5), bstr.h(t6)] ] | | | [ [], [bstr.h(t5), bstr.h(t6)] ] | | |||
| ], | | | ], | | |||
| e'cursor' : 10, | | | e'cursor' : 10, | | |||
| e'more' : false | | | e'more' : false | | |||
| } | | | } | | |||
| | | | | | |||
Figure 14: Interaction for Full Query with Observe Plus Diff | Figure 14: Interaction for Full Query with Observe and Diff Query | |||
Query with "Cursor" | with "Cursor" Extension | |||
Appendix D. CDDL Model | Appendix D. CDDL Model | |||
full_set = 0 | full_set = 0 | |||
diff_set = 1 | diff_set = 1 | |||
cursor = 2 | cursor = 2 | |||
more = 3 | more = 3 | |||
ace-trl-error = 1 | ace-trl-error = 1 | |||
End of changes. 83 change blocks. | ||||
220 lines changed or deleted | 229 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. |