rfc9200v2.txt   rfc9200.txt 
skipping to change at line 368 skipping to change at line 368
The key bound to the token (the PoP key) may use either symmetric The key bound to the token (the PoP key) may use either symmetric
or asymmetric cryptography. The appropriate choice of the kind of or asymmetric cryptography. The appropriate choice of the kind of
cryptography depends on the constraints of the IoT devices as well cryptography depends on the constraints of the IoT devices as well
as on the security requirements of the use case. as on the security requirements of the use case.
Symmetric PoP key: Symmetric PoP key:
The AS generates a random, symmetric PoP key. The key is The AS generates a random, symmetric PoP key. The key is
either stored to be returned on introspection calls or included either stored to be returned on introspection calls or included
in the token. Either the whole token or only the key MUST be in the token. Either the whole token or only the key MUST be
encrypted in the latter case. The PoP key is also returned to encrypted in the latter case. The PoP key is also returned to
client together with the token. client together with the token, protected by the secure
channel.
Asymmetric PoP key: Asymmetric PoP key:
An asymmetric key pair is generated by the client and the An asymmetric key pair is generated by the client and the
public key is sent to the AS (if it does not already have public key is sent to the AS (if it does not already have
knowledge of the client's public key). Information about the knowledge of the client's public key). Information about the
public key, which is the PoP key in this case, is either stored public key, which is the PoP key in this case, is either stored
to be returned on introspection calls or included inside the to be returned on introspection calls or included inside the
token and sent back to the client. The resource server token and sent back to the client. The resource server
consuming the token can identify the public key from the consuming the token can identify the public key from the
information in the token, which allows the client to use the information in the token, which allows the client to use the
skipping to change at line 760 skipping to change at line 761
Note: These conditions ensure that the RS can handle requests Note: These conditions ensure that the RS can handle requests
autonomously once access was granted and a secure channel has been autonomously once access was granted and a secure channel has been
established between the C and RS. The authz-info endpoint, as part established between the C and RS. The authz-info endpoint, as part
of the process for authorizing to protected resources, is not itself of the process for authorizing to protected resources, is not itself
a protected resource and MUST NOT be protected as specified above a protected resource and MUST NOT be protected as specified above
(cf. Section 5.10.1). (cf. Section 5.10.1).
Unauthorized Resource Request messages MUST be denied with an Unauthorized Resource Request messages MUST be denied with an
"unauthorized_client" error response. In this response, the resource "unauthorized_client" error response. In this response, the resource
server SHOULD provide proper "AS Request Creation Hints" to enable server SHOULD provide proper AS Request Creation Hints to enable the
the client to request an access token from the RS's AS, as described client to request an access token from the RS's AS, as described in
in Section 5.3. Section 5.3.
The handling of all client requests (including unauthorized ones) by The handling of all client requests (including unauthorized ones) by
the RS is described in Section 5.10.2. the RS is described in Section 5.10.2.
5.3. AS Request Creation Hints 5.3. AS Request Creation Hints
The "AS Request Creation Hints" are sent by an RS as a response to an The AS Request Creation Hints are sent by an RS as a response to an
Unauthorized Resource Request message (see Section 5.2) to help the Unauthorized Resource Request message (see Section 5.2) to help the
sender of the Unauthorized Resource Request message acquire a valid sender of the Unauthorized Resource Request message acquire a valid
access token. The "AS Request Creation Hints" are a CBOR or JSON access token. The AS Request Creation Hints are a CBOR or JSON map,
map, with an OPTIONAL element "AS" specifying an absolute URI (see with an OPTIONAL element AS specifying an absolute URI (see
Section 4.3 of [RFC3986]) that identifies the appropriate AS for the Section 4.3 of [RFC3986]) that identifies the appropriate AS for the
RS. RS.
The message can also contain the following OPTIONAL parameters: The message can also contain the following OPTIONAL parameters:
* An "audience" element contains an identifier the client should * An audience element contains an identifier the client should
request at the AS, as suggested by the RS. With this parameter, request at the AS, as suggested by the RS. With this parameter,
when included in the access token request to the AS, the AS is when included in the access token request to the AS, the AS is
able to restrict the use of the access token to specific RSs. See able to restrict the use of the access token to specific RSs. See
Section 6.9 for a discussion of this parameter. Section 6.9 for a discussion of this parameter.
* A "kid" (key identifier) element contains the key identifier of a * A kid (key identifier) element contains the key identifier of a
key used in an existing security association between the client key used in an existing security association between the client
and the RS. The RS expects the client to request an access token and the RS. The RS expects the client to request an access token
bound to this key in order to avoid having to reestablish the bound to this key in order to avoid having to reestablish the
security association. security association.
* A "cnonce" element contains a client-nonce. See Section 5.3.1. * A cnonce element contains a client-nonce. See Section 5.3.1.
* A "scope" element contains the suggested scope that the client * A scope element contains the suggested scope that the client
should request towards the AS. should request towards the AS.
Table 1 summarizes the parameters that may be part of the "AS Request Table 1 summarizes the parameters that may be part of the AS Request
Creation Hints". Creation Hints.
+==========+==========+=====================+ +==========+==========+=====================+
| Name | CBOR Key | Value Type | | Name | CBOR Key | Value Type |
+==========+==========+=====================+ +==========+==========+=====================+
| AS | 1 | text string | | AS | 1 | text string |
+----------+----------+---------------------+ +----------+----------+---------------------+
| kid | 2 | byte string | | kid | 2 | byte string |
+----------+----------+---------------------+ +----------+----------+---------------------+
| audience | 5 | text string | | audience | 5 | text string |
+----------+----------+---------------------+ +----------+----------+---------------------+
skipping to change at line 822 skipping to change at line 823
Table 1: AS Request Creation Hints Table 1: AS Request Creation Hints
Note that the schema part of the AS parameter may need to be adapted Note that the schema part of the AS parameter may need to be adapted
to the security protocol that is used between the client and the AS. to the security protocol that is used between the client and the AS.
Thus, the example AS value "coap://as.example.com/token" might need Thus, the example AS value "coap://as.example.com/token" might need
to be transformed to "coaps://as.example.com/token". It is assumed to be transformed to "coaps://as.example.com/token". It is assumed
that the client can determine the correct schema part on its own that the client can determine the correct schema part on its own
depending on the way it communicates with the AS. depending on the way it communicates with the AS.
Figure 2 shows an example for an "AS Request Creation Hints" payload Figure 2 shows an example for an AS Request Creation Hints payload
using CBOR [RFC8949] diagnostic notation, using the parameter names using CBOR [RFC8949] diagnostic notation, using the parameter names
instead of the CBOR keys for better human readability. instead of the CBOR keys for better human readability.
4.01 Unauthorized 4.01 Unauthorized
Content-Format: "application/ace+cbor" Content-Format: "application/ace+cbor"
Payload : Payload :
{ {
"AS" : "coaps://as.example.com/token", / AS / 1 : "coaps://as.example.com/token",
"audience" : "coaps://rs.example.com" / audience / 5 : "coaps://rs.example.com"
"scope" : "rTempC", / scope / 9 : "rTempC",
"cnonce" : h'e0a156bb3f' / cnonce / 39 : h'e0a156bb3f'
} }
Figure 2: AS Request Creation Hints Payload Example Figure 2: AS Request Creation Hints Payload Example
In the example above, the response parameter "AS" points the receiver In the example above, the response parameter AS points the receiver
of this message to the URI "coaps://as.example.com/token" to request of this message to the URI "coaps://as.example.com/token" to request
access tokens. The RS sending this response uses an internal clock access tokens. The RS sending this response uses an internal clock
that is not synchronized with the clock of the AS. Therefore, it that is not synchronized with the clock of the AS. Therefore, it
cannot reliably verify the expiration time of access tokens it cannot reliably verify the expiration time of access tokens it
receives. Nevertheless, to ensure a certain level of access token receives. Nevertheless, to ensure a certain level of access token
freshness, the RS has included a cnonce parameter (see Section 5.3.1) freshness, the RS has included a cnonce parameter (see Section 5.3.1)
in the response. (The hex sequence of the cnonce parameter is in the response. (The hex sequence of the cnonce parameter is
encoded in CBOR-based notation in this example.) encoded in CBOR-based notation in this example.)
Figure 3 illustrates the mandatory use of binary encoding of the Figure 3 illustrates the mandatory use of binary encoding of the
skipping to change at line 878 skipping to change at line 879
5.3.1. The Client-Nonce Parameter 5.3.1. The Client-Nonce Parameter
If the RS does not synchronize its clock with the AS, it could be If the RS does not synchronize its clock with the AS, it could be
tricked into accepting old access tokens that are either expired or tricked into accepting old access tokens that are either expired or
have been compromised. In order to ensure some level of token have been compromised. In order to ensure some level of token
freshness in that case, the RS can use the cnonce (client-nonce) freshness in that case, the RS can use the cnonce (client-nonce)
parameter. The processing requirements for this parameter are as parameter. The processing requirements for this parameter are as
follows: follows:
* An RS sending a cnonce parameter in "AS Request Creation Hints" * An RS sending a cnonce parameter in an AS Request Creation Hints
MUST store information to validate that a given cnonce is fresh. message MUST store information to validate that a given cnonce is
How this is implemented internally is out of scope for this fresh. How this is implemented internally is out of scope for
specification. Expiration of client-nonces should be based this specification. Expiration of client-nonces should be based
roughly on the time it would take a client to obtain an access roughly on the time it would take a client to obtain an access
token after receiving the "AS Request Creation Hints", with some token after receiving the AS Request Creation Hints, with some
allowance for unexpected delays. allowance for unexpected delays.
* A client receiving a cnonce parameter in "AS Request Creation * A client receiving a cnonce parameter in an AS Request Creation
Hints" MUST include this in the parameters when requesting an Hints message MUST include this in the parameters when requesting
access token at the AS, using the cnonce parameter from an access token at the AS, using the cnonce parameter from
Section 5.8.4.4. Section 5.8.4.4.
* If an AS grants an access token request containing a cnonce * If an AS grants an access token request containing a cnonce
parameter, it MUST include this value in the access token, using parameter, it MUST include this value in the access token, using
the cnonce claim specified in Section 5.10. the cnonce claim specified in Section 5.10.
* An RS that is using the client-nonce mechanism and that receives * An RS that is using the client-nonce mechanism and that receives
an access token MUST verify that this token contains a cnonce an access token MUST verify that this token contains a cnonce
claim, with a client-nonce value that is fresh according to the claim, with a client-nonce value that is fresh according to the
information stored at the first step above. If the cnonce claim information stored at the first step above. If the cnonce claim
skipping to change at line 997 skipping to change at line 998
For the AS to be able to issue a token, the client MUST be For the AS to be able to issue a token, the client MUST be
authenticated and present a valid grant for the scopes requested. authenticated and present a valid grant for the scopes requested.
Profiles of this framework MUST specify how the AS authenticates the Profiles of this framework MUST specify how the AS authenticates the
client and how the communication between the client and AS is client and how the communication between the client and AS is
protected, fulfilling the requirements specified in Section 5. protected, fulfilling the requirements specified in Section 5.
The default name of this endpoint in a url-path SHOULD be '/token'. The default name of this endpoint in a url-path SHOULD be '/token'.
However, implementations are not required to use this name and can However, implementations are not required to use this name and can
define their own instead. define their own instead.
The figures of this section use CBOR diagnostic notation without the The figures of this section use CBOR diagnostic notation additionally
integer abbreviations for the parameters or their values for providing the textual representation of claims or parameters in
illustrative purposes. Note that implementations MUST use the comments for illustrative purposes. Note that implementations MUST
integer abbreviations and the binary CBOR encoding if the CBOR use the integer abbreviations and the binary CBOR encoding if the
encoding is used. CBOR encoding is used.
5.8.1. Client-to-AS Request 5.8.1. Client-to-AS Request
The client sends a POST request to the token endpoint at the AS. The The client sends a POST request to the token endpoint at the AS. The
profile MUST specify how the communication is protected. The content profile MUST specify how the communication is protected. The content
of the request consists of the parameters specified in the relevant of the request consists of the parameters specified in the relevant
subsection of Section 4 of the OAuth 2.0 specification [RFC6749], subsection of Section 4 of the OAuth 2.0 specification [RFC6749],
depending on the grant type, with the following exceptions and depending on the grant type, with the following exceptions and
additions: additions:
* The parameter grant_type is OPTIONAL in the context of this * The parameter grant_type is OPTIONAL in the context of this
framework (as opposed to REQUIRED in [RFC6749]). If that framework (as opposed to REQUIRED in [RFC6749]). If that
parameter is missing, the default value "client_credentials" is parameter is missing, the default value "client_credentials" is
implied. implied.
* The audience parameter from [RFC8693] is OPTIONAL to request an * The audience parameter from [RFC8693] is OPTIONAL to request an
access token bound to a specific audience. access token bound to a specific audience.
* The cnonce parameter defined in Section 5.8.4.4 is REQUIRED if the * The cnonce parameter defined in Section 5.8.4.4 is REQUIRED if the
RS provided a client-nonce in the "AS Request Creation Hints" RS provided a client-nonce in the AS Request Creation Hints
(Section 5.3). message (Section 5.3).
* The scope parameter MAY be encoded as a byte string instead of the * The scope parameter MAY be encoded as a byte string instead of the
string encoding specified in Section 3.3 of [RFC6749] or in order string encoding specified in Section 3.3 of [RFC6749] or in order
to allow compact encoding of complex scopes. The syntax of such a to allow compact encoding of complex scopes. The syntax of such a
binary encoding is explicitly not specified here and left to binary encoding is explicitly not specified here and left to
profiles or applications. Note specifically that a binary encoded profiles or applications. Note specifically that a binary encoded
scope does not necessarily use the space character '0x20' to scope does not necessarily use the space character '0x20' to
delimit scope-tokens. delimit scope-tokens.
* The client can send an empty (null value) ace_profile parameter to * The client can send an empty (null value) ace_profile parameter to
skipping to change at line 1057 skipping to change at line 1058
When HTTP is used as a transport, then the client makes a request to When HTTP is used as a transport, then the client makes a request to
the token endpoint; the parameters MUST be encoded as defined in the token endpoint; the parameters MUST be encoded as defined in
Appendix B of [RFC6749]. Appendix B of [RFC6749].
The following examples illustrate different types of requests for The following examples illustrate different types of requests for
proof-of-possession tokens. proof-of-possession tokens.
Figure 4 shows a request for a token with a symmetric proof-of- Figure 4 shows a request for a token with a symmetric proof-of-
possession key. The content is displayed in CBOR diagnostic possession key. The content is displayed in CBOR diagnostic
notation, without abbreviations for better readability. notation, with the textual representation in comments for better
readability.
Header: POST (Code=0.02) Header: POST (Code=0.02)
Uri-Host: "as.example.com" Uri-Host: "as.example.com"
Uri-Path: "token" Uri-Path: "token"
Content-Format: "application/ace+cbor" Content-Format: "application/ace+cbor"
Payload: Payload:
{ {
"client_id" : "myclient", / client_id / 24 : "myclient",
"audience" : "tempSensor4711" / audience / 5 : "tempSensor4711"
} }
Figure 4: Example Request for an Access Token Bound to a Figure 4: Example Request for an Access Token Bound to a
Symmetric Key Symmetric Key
Figure 5 shows a request for a token with an asymmetric proof-of- Figure 5 shows a request for a token with an asymmetric proof-of-
possession key. Note that, in this example, OSCORE [RFC8613] is used possession key. Note that, in this example, OSCORE [RFC8613] is used
to provide object-security; therefore, the Content-Format is to provide object-security; therefore, the Content-Format is
"application/oscore" wrapping the "application/ace+cbor" type "application/oscore" wrapping the "application/ace+cbor" type
content. The OSCORE option has a decoded interpretation appended in content. The OSCORE option has a decoded interpretation appended in
skipping to change at line 1093 skipping to change at line 1095
Uri-Host: "as.example.com" Uri-Host: "as.example.com"
Uri-Path: "token" Uri-Path: "token"
OSCORE: 0x09, 0x05, 0x44, 0x6C OSCORE: 0x09, 0x05, 0x44, 0x6C
(h=0, k=1, n=001, partialIV= 0x05, kid=[0x44, 0x6C]) (h=0, k=1, n=001, partialIV= 0x05, kid=[0x44, 0x6C])
Content-Format: "application/oscore" Content-Format: "application/oscore"
Payload: Payload:
0x44025d1 ... (full payload omitted for brevity) ... 68b3825e 0x44025d1 ... (full payload omitted for brevity) ... 68b3825e
Decrypted payload: Decrypted payload:
{ {
"client_id" : "myclient", / client_id / 24 : "myclient",
"req_cnf" : { / req_cnf / 4 : {
"COSE_Key" : { / COSE_Key / 1 : {
"kty" : "EC", / kty / 1 : 2 / EC2 /,
"kid" : h'11', / kid / 2 : h'11',
"crv" : "P-256", / crv / -1 : 1 / P-256 /,
"x" : b64'usWxHK2PmfnHKwXPS54m0kTcGJ90UiglWiGahtagnv8', / x / -2 : b64'usWxHK2PmfnHKwXPS54m0kTcGJ90UiglWiGahtagnv8',
"y" : b64'IBOL+C3BttVivg+lSreASjpkttcsz+1rb7btKLv8EX4' / y / -3 : b64'IBOL+C3BttVivg+lSreASjpkttcsz+1rb7btKLv8EX4'
} }
} }
} }
Figure 5: Example Token Request Bound to an Asymmetric Key Figure 5: Example Token Request Bound to an Asymmetric Key
Figure 6 shows a request for a token where a previously communicated Figure 6 shows a request for a token where a previously communicated
proof-of-possession key is only referenced using the req_cnf proof-of-possession key is only referenced using the req_cnf
parameter from [RFC9201]. parameter from [RFC9201].
Header: POST (Code=0.02) Header: POST (Code=0.02)
Uri-Host: "as.example.com" Uri-Host: "as.example.com"
Uri-Path: "token" Uri-Path: "token"
Content-Format: "application/ace+cbor" Content-Format: "application/ace+cbor"
Payload: Payload:
{ {
"client_id" : "myclient", / client_id / 24 : "myclient",
"audience" : "valve424", / audience / 5 : "valve424",
"scope" : "read", / scope / 9 : "read",
"req_cnf" : { / req_cnf / 4 : {
"kid" : b64'6kg0dXJM13U' / kid / 3 : b64'6kg0dXJM13U'
} }
} }
Figure 6: Example Request for an Access Token Bound to a Key Figure 6: Example Request for an Access Token Bound to a Key
Reference Reference
Refresh tokens are typically not stored as securely as proof-of- Refresh tokens are typically not stored as securely as proof-of-
possession keys in requesting clients. Proof-of-possession-based possession keys in requesting clients. Proof-of-possession-based
refresh token requests MUST NOT request different proof-of-possession refresh token requests MUST NOT request different proof-of-possession
keys or different audiences in token requests. Refresh token keys or different audiences in token requests. Refresh token
skipping to change at line 1216 skipping to change at line 1218
| cnf | [RFC9201] | | cnf | [RFC9201] |
+-------------------+--------------+ +-------------------+--------------+
| rs_cnf | [RFC9201] | | rs_cnf | [RFC9201] |
+-------------------+--------------+ +-------------------+--------------+
Table 2: Access Information Table 2: Access Information
Parameters Parameters
Figure 7 shows a response containing a token and a cnf parameter with Figure 7 shows a response containing a token and a cnf parameter with
a symmetric proof-of-possession key, which is defined in [RFC9201]. a symmetric proof-of-possession key, which is defined in [RFC9201].
Note that the key identifier 'kid' is only used to simplify indexing Note that the key identifier kid is only used to simplify indexing
and retrieving the key, and no assumptions should be made that it is and retrieving the key, and no assumptions should be made that it is
unique in the domains of either the client or the RS. unique in the domains of either the client or the RS.
Header: Created (Code=2.01) Header: Created (Code=2.01)
Content-Format: "application/ace+cbor" Content-Format: "application/ace+cbor"
Payload: Payload:
{ {
"access_token" : b64'SlAV32hkKG ... / access_token / 1 : b64'SlAV32hkKG ...
(remainder of CWT omitted for brevity; (remainder of CWT omitted for brevity;
CWT contains COSE_Key in the "cnf" claim)', CWT contains COSE_Key in the cnf claim)',
"ace_profile" : "coap_dtls", / ace_profile / 38 : "coap_dtls",
"expires_in" : "3600", / expires_in / 2 : 3600,
"cnf" : { / cnf / 8 : {
"COSE_Key" : { / COSE_Key / 1 : {
"kty" : "Symmetric", / kty / 1 : 4 / Symmetric /,
"kid" : b64'39Gqlw', / kid / 2 : b64'39Gqlw',
"k" : b64'hJtXhkV8FJG+Onbc6mxCcQh' / k / -1 : b64'hJtXhkV8FJG+Onbc6mxCcQh'
} }
} }
} }
Figure 7: Example AS Response with an Access Token Bound to a Figure 7: Example AS Response with an Access Token Bound to a
Symmetric Key Symmetric Key
5.8.3. Error Response 5.8.3. Error Response
The error responses for interactions with the AS are generally The error responses for interactions with the AS are generally
skipping to change at line 1385 skipping to change at line 1387
Clients that want the AS to provide them with the ace_profile Clients that want the AS to provide them with the ace_profile
parameter in the access token response can indicate that by sending parameter in the access token response can indicate that by sending
an ace_profile parameter with a null value for CBOR-based an ace_profile parameter with a null value for CBOR-based
interactions, or an empty string if CBOR is not used, in the access interactions, or an empty string if CBOR is not used, in the access
token request. token request.
5.8.4.4. Client-Nonce 5.8.4.4. Client-Nonce
This parameter MUST be sent from the client to the AS if it This parameter MUST be sent from the client to the AS if it
previously received a cnonce parameter in the "AS Request Creation previously received a cnonce parameter in the AS Request Creation
Hints" (Section 5.3). The parameter is encoded as a byte string for Hints (Section 5.3). The parameter is encoded as a byte string for
CBOR-based interactions and as a string (base64url without padding CBOR-based interactions and as a string (base64url without padding
encoded binary [RFC4648]) if CBOR is not used. It MUST copy the encoded binary [RFC4648]) if CBOR is not used. It MUST copy the
value from the cnonce parameter in the "AS Request Creation Hints". value from the cnonce parameter in the AS Request Creation Hints.
5.8.5. Mapping Parameters to CBOR 5.8.5. Mapping Parameters to CBOR
If CBOR encoding is used, all OAuth parameters in access token If CBOR encoding is used, all OAuth parameters in access token
requests and responses MUST be mapped to CBOR types, as specified in requests and responses MUST be mapped to CBOR types, as specified in
the registry defined by Section 8.10, using the given integer the registry defined by Section 8.10, using the given integer
abbreviation for the map keys. abbreviation for the map keys.
Note that we have aligned the abbreviations corresponding to claims Note that we have aligned the abbreviations corresponding to claims
with the abbreviations defined in [RFC8392]. with the abbreviations defined in [RFC8392].
skipping to change at line 1463 skipping to change at line 1465
Table 5: CBOR Mappings Used in Token Requests and Responses Table 5: CBOR Mappings Used in Token Requests and Responses
5.9. The Introspection Endpoint 5.9. The Introspection Endpoint
Token introspection [RFC7662] MAY be implemented by the AS and the Token introspection [RFC7662] MAY be implemented by the AS and the
RS. When implemented, it MAY be used by the RS and to query the AS RS. When implemented, it MAY be used by the RS and to query the AS
for metadata about a given token, e.g., validity or scope. Analogous for metadata about a given token, e.g., validity or scope. Analogous
to the protocol defined in [RFC7662] for HTTP and JSON, this section to the protocol defined in [RFC7662] for HTTP and JSON, this section
defines adaptations to more constrained environments using CBOR and defines adaptations to more constrained environments using CBOR and
leaving the choice of the application protocol to the profile. leaving the choice of the application protocol to the profile. The
client MAY also implement and use introspection analogously to the RS
to obtain information about a given token.
Communication between the requesting entity and the introspection Communication between the requesting entity and the introspection
endpoint at the AS MUST be integrity protected and encrypted. The endpoint at the AS MUST be integrity protected and encrypted. The
communication security protocol MUST also provide a binding between communication security protocol MUST also provide a binding between
requests and responses. Furthermore, the two interacting parties requests and responses. Furthermore, the two interacting parties
MUST perform mutual authentication. Finally, the AS SHOULD verify MUST perform mutual authentication. Finally, the AS SHOULD verify
that the requesting entity has the right to access introspection that the requesting entity has the right to access introspection
information about the provided token. Profiles of this framework information about the provided token. Profiles of this framework
that support introspection MUST specify how authentication and that support introspection MUST specify how authentication and
communication security between the requesting entity and the AS is communication security between the requesting entity and the AS is
implemented. implemented.
The default name of this endpoint in a url-path SHOULD be The default name of this endpoint in a url-path SHOULD be
'/introspect'. However, implementations are not required to use this '/introspect'. However, implementations are not required to use this
name and can define their own instead. name and can define their own instead.
The figures of this section use the CBOR diagnostic notation without The figures of this section use the CBOR diagnostic notation with the
the integer abbreviations for the parameters and their values for textual respresentation of the parameters and their values in
better readability. comments for better readability.
5.9.1. Introspection Request 5.9.1. Introspection Request
The requesting entity sends a POST request to the introspection The requesting entity sends a POST request to the introspection
endpoint at the AS. The profile MUST specify how the communication endpoint at the AS. The profile MUST specify how the communication
is protected. If CoAP is used, the payload MUST be encoded as a CBOR is protected. If CoAP is used, the payload MUST be encoded as a CBOR
map with a "token" entry containing the access token. Further map with a token entry containing the access token. Further optional
optional parameters representing additional context that is known by parameters representing additional context that is known by the
the requesting entity to aid the AS in its response MAY be included. requesting entity to aid the AS in its response MAY be included.
For CoAP-based interaction, all messages MUST use the content type For CoAP-based interaction, all messages MUST use the content type
"application/ace+cbor". For HTTP, the encoding defined in "application/ace+cbor". For HTTP, the encoding defined in
Section 2.1 of [RFC7662] is used. Section 2.1 of [RFC7662] is used.
The same parameters are required and optional as in Section 2.1 of The same parameters are required and optional as in Section 2.1 of
[RFC7662]. [RFC7662].
For example, Figure 8 shows an RS calling the token introspection For example, Figure 8 shows an RS calling the token introspection
endpoint at the AS to query about an OAuth 2.0 proof-of-possession endpoint at the AS to query about an OAuth 2.0 proof-of-possession
skipping to change at line 1517 skipping to change at line 1521
Uri-Host: "as.example.com" Uri-Host: "as.example.com"
Uri-Path: "introspect" Uri-Path: "introspect"
OSCORE: 0x09, 0x05, 0x25 OSCORE: 0x09, 0x05, 0x25
Content-Format: "application/oscore" Content-Format: "application/oscore"
Payload: Payload:
... COSE content ... ... COSE content ...
Figure 8: Example Introspection Request Figure 8: Example Introspection Request
{ {
"token" : b64'7gj0dXJQ43U', / token / 11 : b64'7gj0dXJQ43U',
"token_type_hint" : "PoP" / token_type_hint / 33 : 2 / PoP /
} }
Figure 9: Decoded Payload Figure 9: Decoded Payload
5.9.2. Introspection Response 5.9.2. Introspection Response
If the introspection request is authorized and successfully If the introspection request is authorized and successfully
processed, the AS sends a response with the response code equivalent processed, the AS sends a response with the response code equivalent
to the CoAP code 2.01 (Created). If the introspection request was to the CoAP code 2.01 (Created). If the introspection request was
invalid, not authorized, or couldn't be processed, the AS returns an invalid, not authorized, or couldn't be processed, the AS returns an
skipping to change at line 1548 skipping to change at line 1552
ace_profile: ace_profile:
This parameter is OPTIONAL. This indicates the profile that the This parameter is OPTIONAL. This indicates the profile that the
RS MUST use with the client. See Section 5.8.4.3 for more details RS MUST use with the client. See Section 5.8.4.3 for more details
on the formatting of this parameter. If this parameter is absent, on the formatting of this parameter. If this parameter is absent,
the AS assumes that the RS implicitly knows which profile to use the AS assumes that the RS implicitly knows which profile to use
towards the client. towards the client.
cnonce: cnonce:
This parameter is OPTIONAL. This is a client-nonce provided to This parameter is OPTIONAL. This is a client-nonce provided to
the AS by the client. The RS MUST verify that this corresponds to the AS by the client. The RS MUST verify that this corresponds to
the client-nonce previously provided to the client in the "AS the client-nonce previously provided to the client in the AS
Request Creation Hints". See Sections 5.3 and 5.8.4.4. Its value Request Creation Hints. See Sections 5.3 and 5.8.4.4. Its value
is a byte string when encoded in CBOR and is the base64url is a byte string when encoded in CBOR and is the base64url
encoding of this byte string without padding when encoded in JSON encoding of this byte string without padding when encoded in JSON
[RFC4648]. [RFC4648].
cti: cti:
This parameter is OPTIONAL. This is the cti claim associated to This parameter is OPTIONAL. This is the cti claim associated to
this access token. This parameter has the same meaning and this access token. This parameter has the same meaning and
processing rules as the jti parameter defined in Section 3.1.2 of processing rules as the jti parameter defined in Section 3.1.2 of
[RFC7662] except that its value is a byte string when encoded in [RFC7662] except that its value is a byte string when encoded in
CBOR and is the base64url encoding of this byte string without CBOR and is the base64url encoding of this byte string without
padding when encoded in JSON [RFC4648]. padding when encoded in JSON [RFC4648].
exi: exi:
This parameter is OPTIONAL. This is the expires-in claim This parameter is OPTIONAL. This is the expires_in claim
associated to this access token. See Section 5.10.3. associated to this access token. See Section 5.10.3.
Furthermore, [RFC9201] defines more parameters that the AS MUST be Furthermore, [RFC9201] defines more parameters that the AS MUST be
able to use when responding to a request to the introspection able to use when responding to a request to the introspection
endpoint. endpoint.
For example, Figure 10 shows an AS response to the introspection For example, Figure 10 shows an AS response to the introspection
request in Figure 8. Note that this example contains the cnf request in Figure 8. Note that this example contains the cnf
parameter defined in [RFC9201]. parameter defined in [RFC9201].
Header: Created (Code=2.01) Header: Created (Code=2.01)
Content-Format: "application/ace+cbor" Content-Format: "application/ace+cbor"
Payload: Payload:
{ {
"active" : true, / active / 10 : true,
"scope" : "read", / scope / 9 : "read",
"ace_profile" : "coap_dtls", / ace_profile / 38 : 1 / coap_dtls /,
"cnf" : { / cnf / 8 : {
"COSE_Key" : { / COSE_Key / 1 : {
"kty" : "Symmetric", / kty / 1 : 4 / Symmetric /,
"kid" : b64'39Gqlw', / kid / 2 : b64'39Gqlw',
"k" : b64'hJtXhkV8FJG+Onbc6mxCcQh' / k / -1 : b64'hJtXhkV8FJG+Onbc6mxCcQh'
} }
} }
} }
Figure 10: Example Introspection Response Figure 10: Example Introspection Response
5.9.3. Error Response 5.9.3. Error Response
The error responses for CoAP-based interactions with the AS are The error responses for CoAP-based interactions with the AS are
equivalent to the ones for HTTP-based interactions, as defined in equivalent to the ones for HTTP-based interactions, as defined in
skipping to change at line 1853 skipping to change at line 1857
The RS must recognize value of the scope claim. If that is not The RS must recognize value of the scope claim. If that is not
the case, the RS MUST discard the token. If this was an the case, the RS MUST discard the token. If this was an
interaction with authz-info, the RS MUST also respond with a interaction with authz-info, the RS MUST also respond with a
response code equivalent to the CoAP code 4.00 (Bad Request). The response code equivalent to the CoAP code 4.00 (Bad Request). The
RS MAY provide additional information in the error response to RS MAY provide additional information in the error response to
clarify what went wrong. clarify what went wrong.
Additional processing may be needed for other claims in a way Additional processing may be needed for other claims in a way
specific to a profile or the underlying application. specific to a profile or the underlying application.
Note that the Subject (sub) claim cannot always be verified when the Note that the sub (Subject) claim cannot always be verified when the
token is submitted to the RS since the client may not have token is submitted to the RS since the client may not have
authenticated yet. Also note that a counter for the expires_in (exi) authenticated yet. Also note that a counter for the exi (expires in)
claim MUST be initialized when the RS first verifies this token. claim MUST be initialized when the RS first verifies this token.
Also note that profiles of this framework may define access token Also note that profiles of this framework may define access token
transport mechanisms that do not allow for error responses. transport mechanisms that do not allow for error responses.
Therefore, the error messages specified here only apply if the token Therefore, the error messages specified here only apply if the token
was sent to the authz-info endpoint. was sent to the authz-info endpoint.
When sending error responses, the RS MAY use the error codes from When sending error responses, the RS MAY use the error codes from
Section 3.1 of [RFC6750] to provide additional details to the client. Section 3.1 of [RFC6750] to provide additional details to the client.
skipping to change at line 1945 skipping to change at line 1949
* The RS verifies the validity of the token by performing an * The RS verifies the validity of the token by performing an
introspection request, as specified in Section 5.9. This requires introspection request, as specified in Section 5.9. This requires
the RS to have a reliable network connection to the AS and to be the RS to have a reliable network connection to the AS and to be
able to handle two secure sessions in parallel (C to RS and RS to able to handle two secure sessions in parallel (C to RS and RS to
AS). AS).
* In order to support token expiration for devices that have no * In order to support token expiration for devices that have no
reliable way of synchronizing their internal clocks, this reliable way of synchronizing their internal clocks, this
specification defines the following approach: The claim exi specification defines the following approach: The claim exi
("expires in") can be used to provide the RS with the lifetime of (expires in) can be used to provide the RS with the lifetime of
the token in seconds from the time the RS first receives the the token in seconds from the time the RS first receives the
token. This mechanism only works for self-contained tokens, i.e., token. This mechanism only works for self-contained tokens, i.e.,
CWTs and JWTs. For CWTs, this parameter is encoded as an unsigned CWTs and JWTs. For CWTs, this parameter is encoded as an unsigned
integer, while JWTs encode this as JSON number. integer, while JWTs encode this as JSON number.
* Processing this claim requires that the RS does the following: * Processing this claim requires that the RS does the following:
- For each token the RS receives that contains an exi claim, keep - For each token the RS receives that contains an exi claim, keep
track of the time it received that token and revisit that list track of the time it received that token and revisit that list
regularly to expunge expired tokens. regularly to expunge expired tokens.
skipping to change at line 2130 skipping to change at line 2134
replace credentials that are suspected to have been compromised or replace credentials that are suspected to have been compromised or
that have been lost. that have been lost.
Operators also SHOULD have procedures for decommissioning devices Operators also SHOULD have procedures for decommissioning devices
that include securely erasing credentials and other security-critical that include securely erasing credentials and other security-critical
material in the devices being decommissioned. material in the devices being decommissioned.
6.4. Unprotected AS Request Creation Hints 6.4. Unprotected AS Request Creation Hints
Initially, no secure channel exists to protect the communication Initially, no secure channel exists to protect the communication
between the C and RS. Thus, the C cannot determine if the "AS between the C and RS. Thus, the C cannot determine if the AS Request
Request Creation Hints" contained in an unprotected response from the Creation Hints contained in an unprotected response from the RS to an
RS to an unauthorized request (see Section 5.3) are authentic. unauthorized request (see Section 5.3) are authentic. Therefore, the
Therefore, the C MUST determine if an AS is authorized to provide C MUST determine if an AS is authorized to provide access tokens for
access tokens for a certain RS. How this determination is a certain RS. How this determination is implemented is out of scope
implemented is out of scope for this document and left to the for this document and left to the applications.
applications.
6.5. Minimal Security Requirements for Communication 6.5. Minimal Security Requirements for Communication
This section summarizes the minimal requirements for the This section summarizes the minimal requirements for the
communication security of the different protocol interactions. communication security of the different protocol interactions.
C-AS C-AS
All communication between the client and the authorization server All communication between the client and the authorization server
MUST be encrypted and integrity and replay protected. MUST be encrypted and integrity and replay protected.
Furthermore, responses from the AS to the client MUST be bound to Furthermore, responses from the AS to the client MUST be bound to
skipping to change at line 2234 skipping to change at line 2237
6.7. Combining Profiles 6.7. Combining Profiles
There may be use cases where different transport and security There may be use cases where different transport and security
protocols are allowed for the different interactions, and, if that is protocols are allowed for the different interactions, and, if that is
not explicitly covered by an existing profile, it corresponds to not explicitly covered by an existing profile, it corresponds to
combining profiles into a new one. For example, a new profile could combining profiles into a new one. For example, a new profile could
specify that a previously defined MQTT-TLS profile is used between specify that a previously defined MQTT-TLS profile is used between
the client and the RS in combination with a previously defined CoAP- the client and the RS in combination with a previously defined CoAP-
DTLS profile for interactions between the client and the AS. The new DTLS profile for interactions between the client and the AS. The new
profile that combines existing profiles MUST specify how the existing profile that combines existing profiles MUST specify how the existing
profiles' security properties are achieved. Therefore, any profile profiles' security requirements remain satisfied. Therefore, any
MUST clearly specify its security requirements and MUST document if profile MUST clearly specify its security requirements and MUST
its security depends on the combination of various protocol document if its security depends on the combination of various
interactions. protocol interactions.
6.8. Unprotected Information 6.8. Unprotected Information
Communication with the authz-info endpoint, as well as the various Communication with the authz-info endpoint, as well as the various
error responses defined in this framework, potentially includes error responses defined in this framework, potentially includes
sending information over an unprotected channel. These messages may sending information over an unprotected channel. These messages may
leak information to an adversary or may be manipulated by active leak information to an adversary or may be manipulated by active
attackers to induce incorrect behavior. For example, error responses attackers to induce incorrect behavior. For example, error responses
for requests to the authorization information endpoint can reveal for requests to the authorization information endpoint can reveal
information about an otherwise opaque access token to an adversary information about an otherwise opaque access token to an adversary
skipping to change at line 2303 skipping to change at line 2306
If the audience addresses a group of resource servers, the mapping of If the audience addresses a group of resource servers, the mapping of
a group identifier to an individual RS has to be provisioned to each a group identifier to an individual RS has to be provisioned to each
RS before the group-audience is usable. Managing dynamic groups RS before the group-audience is usable. Managing dynamic groups
could be an issue if any RS is not always reachable when the groups' could be an issue if any RS is not always reachable when the groups'
memberships change. Furthermore, issuing access tokens bound to memberships change. Furthermore, issuing access tokens bound to
symmetric proof-of-possession keys that apply to a group-audience is symmetric proof-of-possession keys that apply to a group-audience is
problematic, as an RS that is in possession of the access token can problematic, as an RS that is in possession of the access token can
impersonate the client towards the other RSs that are part of the impersonate the client towards the other RSs that are part of the
group. It is therefore NOT RECOMMENDED to issue access tokens bound group. It is therefore NOT RECOMMENDED to issue access tokens bound
to a group audience and symmetric proof-of possession keys. to a group-audience and symmetric proof-of possession keys.
Even the client must be able to determine the correct values to put Even the client must be able to determine the correct values to put
into the audience parameter in order to obtain a token for the into the audience parameter in order to obtain a token for the
intended RS. Errors in this process can lead to the client intended RS. Errors in this process can lead to the client
inadvertently obtaining a token for the wrong RS. The correct values inadvertently obtaining a token for the wrong RS. The correct values
for audience can either be provisioned to the client as part of its for audience can either be provisioned to the client as part of its
configuration or dynamically looked up by the client in some configuration or dynamically looked up by the client in some
directory. In the latter case, the integrity and correctness of the directory. In the latter case, the integrity and correctness of the
directory data must be assured. Note that the audience hint provided directory data must be assured. Note that the audience hint provided
by the RS as part of the "AS Request Creation Hints" (Section 5.3) is by the RS as part of the AS Request Creation Hints (Section 5.3) is
not typically source authenticated and integrity protected and should not typically source authenticated and integrity protected and should
therefore not be treated a trusted value. therefore not be treated a trusted value.
6.10. Denial of Service Against or with Introspection 6.10. Denial of Service Against or with Introspection
The optional introspection mechanism provided by OAuth and supported The optional introspection mechanism provided by OAuth and supported
in the ACE framework allows for two types of attacks that need to be in the ACE framework allows for two types of attacks that need to be
considered by implementers. considered by implementers.
First, an attacker could perform a denial-of-service attack against First, an attacker could perform a denial-of-service attack against
skipping to change at line 2382 skipping to change at line 2385
attacker able to obtain the access tokens will be able to link the attacker able to obtain the access tokens will be able to link the
requests or even to determine the client's identity. requests or even to determine the client's identity.
An unprotected response to an unauthorized request (see Section 5.3) An unprotected response to an unauthorized request (see Section 5.3)
may disclose information about the RS and/or its existing may disclose information about the RS and/or its existing
relationship with the C. It is advisable to include as little relationship with the C. It is advisable to include as little
information as possible in an unencrypted response. Even the information as possible in an unencrypted response. Even the
absolute URI of the AS may reveal sensitive information about the absolute URI of the AS may reveal sensitive information about the
service that the RS provides. Developers must ensure that the RS service that the RS provides. Developers must ensure that the RS
does not disclose information that has an impact on the privacy of does not disclose information that has an impact on the privacy of
the stakeholders in the "AS Request Creation Hints". They may choose the stakeholders in the AS Request Creation Hints. They may choose
to use a different mechanism for the discovery of the AS if to use a different mechanism for the discovery of the AS if
necessary. If means of encrypting communication between the C and RS necessary. If means of encrypting communication between the C and RS
already exist, more detailed information may be included with an already exist, more detailed information may be included with an
error response to provide the C with sufficient information to react error response to provide the C with sufficient information to react
on that particular error. on that particular error.
8. IANA Considerations 8. IANA Considerations
This document creates several registries with a registration policy This document creates several registries with a registration policy
of Expert Review; guidelines to the experts are given in of Expert Review; guidelines to the experts are given in
skipping to change at line 2767 skipping to change at line 2770
Published specification: RFC 9200 Published specification: RFC 9200
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 resource servers that support
the ACE framework with CBOR encoding, as specified in RFC 9200. the ACE framework with CBOR encoding, as specified in RFC 9200.
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: Person & email address to contact for further information: IESG <ies
IESG <iesg@ietf.org> g@ietf.org>
Intended usage: COMMON Intended usage: COMMON
Restrictions on usage: none Restrictions on usage: none
Author: Ludwig Seitz <ludwig.seitz@combitech.se> Author: Ludwig Seitz <ludwig.seitz@combitech.se>
Change controller: IETF Change controller: IETF
8.16. CoAP Content-Formats 8.16. CoAP Content-Formats
skipping to change at line 3579 skipping to change at line 3582
set to "tempSensorInLivingRoom", a value that the temperature set to "tempSensorInLivingRoom", a value that the temperature
sensor identifies itself with. The AS evaluates the request and sensor identifies itself with. The AS evaluates the request and
authorizes the client to access the resource. authorizes the client to access the resource.
B: The AS responds with a 2.05 (Content) response containing the B: The AS responds with a 2.05 (Content) response containing the
Access Information, including the access token. The PoP access Access Information, including the access token. The PoP access
token contains the public key of the client, and the Access token contains the public key of the client, and the Access
Information contains the public key of the RS. For communication Information contains the public key of the RS. For communication
security, this example uses DTLS RawPublicKey between the client security, this example uses DTLS RawPublicKey between the client
and the RS. The issued token will have a short validity time, and the RS. The issued token will have a short validity time,
i.e., "exp" close to "iat", in order to mitigate attacks using i.e., exp close to iat, in order to mitigate attacks using stolen
stolen client credentials. The token includes claims, such as client credentials. The token includes claims, such as scope,
scope, with the authorized access that an owner of the with the authorized access that an owner of the temperature
temperature device can enjoy. In this example, the scope claim device can enjoy. In this example, the scope claim issued by the
issued by the AS informs the RS that the owner of the token that AS informs the RS that the owner of the token that can prove the
can prove the possession of a key is authorized to make a GET possession of a key is authorized to make a GET request against
request against the /temperature resource and a POST request on the /temperature resource and a POST request on the /firmware
the /firmware resource. Note that the syntax and semantics of resource. Note that the syntax and semantics of the scope claim
the scope claim are application specific. are application specific.
Note: In this example, it is assumed that the client knows what Note: In this example, it is assumed that the client knows what
resource it wants to access and is therefore able to request resource it wants to access and is therefore able to request
specific audience and scope claims for the access token. specific audience and scope claims for the access token.
Authorization Authorization
Client Server Client Server
| | | |
|<=======>| DTLS Connection Establishment |<=======>| DTLS Connection Establishment
| | and mutual authentication | | and mutual authentication
skipping to change at line 3612 skipping to change at line 3615
| | Payload: <Request-Payload> | | Payload: <Request-Payload>
| | | |
B: |<--------+ Header: 2.05 Content B: |<--------+ Header: 2.05 Content
| 2.05 | Content-Format: "application/ace+cbor" | 2.05 | Content-Format: "application/ace+cbor"
| | Payload: <Response-Payload> | | Payload: <Response-Payload>
| | | |
Figure 11: Token Request and Response Using Client Credentials Figure 11: Token Request and Response Using Client Credentials
The information contained in the Request-Payload and the Response- The information contained in the Request-Payload and the Response-
Payload is shown in Figure 12. Note that the rs_cnf parameter from Payload is shown in Figure 12. Note that the parameter rs_cnf from
[RFC9201] is used to inform the client about the resource server's [RFC9201] is used to inform the client about the resource server's
public key. public key.
Request-Payload : Request-Payload :
{ {
"audience" : "tempSensorInLivingRoom", / audience / 5 : "tempSensorInLivingRoom",
"client_id" : "myclient", / client_id / 24 : "myclient",
"req_cnf" : { / req_cnf / 4 : {
"COSE_Key" : { / COSE_Key / 1 : {
"kid" : b64'1Bg8vub9tLe1gHMzV76e8', / kid / 2 : b64'1Bg8vub9tLe1gHMzV76e8',
"kty" : "EC", / kty / 1 : 2 / EC2 /,
"crv" : "P-256", / crv / -1 : 1 / P-256 /,
"x" : b64'f83OJ3D2xF1Bg8vub9tLe1gHMzV76e8Tus9uPHvRVEU', / x / -2 : b64'f83OJ3D2xF1Bg8vub9tLe1gHMzV76e8Tus9uPHvRVEU',
"y" : b64'x_FEzRu9m36HLN_tue659LNpXW6pCyStikYjKIWI5a0' / y / -3 : b64'x_FEzRu9m36HLN_tue659LNpXW6pCyStikYjKIWI5a0'
} }
} }
} }
Response-Payload : Response-Payload :
{ {
"access_token" : b64'0INDoQEKoQVNKkXfb7xaWqMTf6 ...', / access_token / 1 : b64'0INDoQEKoQVNKkXfb7xaWqMTf6 ...',
"rs_cnf" : { / rs_cnf / 41 : {
"COSE_Key" : { / COSE_Key / 1 : {
"kid" : b64'c29tZSBwdWJsaWMga2V5IGlk', / kid / 2 : b64'c29tZSBwdWJsaWMga2V5IGlk',
"kty" : "EC", / kty / 1 : 2 / EC2 /,
"crv" : "P-256", / crv / -1 : 1 / P-256 /,
"x" : b64'MKBCTNIcKUSDii11ySs3526iDZ8AiTo7Tu6KPAqv7D4', / x / -2 : b64'MKBCTNIcKUSDii11ySs3526iDZ8AiTo7Tu6KPAqv7D4',
"y" : b64'4Etl6SRW2YiLUrN5vfvVHuhp7x8PxltmWWlbbM4IFyM' / y / -3 : b64'4Etl6SRW2YiLUrN5vfvVHuhp7x8PxltmWWlbbM4IFyM'
} }
} }
} }
Figure 12: Request and Response Payload Details Figure 12: Request and Response Payload Details
The content of the access token is shown in Figure 13. The content of the access token is shown in Figure 13.
{ {
"aud" : "tempSensorInLivingRoom", / aud / 3 : "tempSensorInLivingRoom",
"iat" : "1563451500", / iat / 6 : 1563451500,
"exp" : "1563453000", / exp / 4 : 1563453000,
"scope" : "temperature_g firmware_p", / scope / 9 : "temperature_g firmware_p",
"cnf" : { / cnf / 8 : {
"COSE_Key" : { / COSE_Key / 1 : {
"kid" : b64'1Bg8vub9tLe1gHMzV76e8', / kid / 2 : b64'1Bg8vub9tLe1gHMzV76e8',
"kty" : "EC", / kty / 1 : 2 / EC2 /,
"crv" : "P-256", / crv / -1 : 1 / P-256 /,
"x" : b64'f83OJ3D2xF1Bg8vub9tLe1gHMzV76e8Tus9uPHvRVEU', / x / -2 : b64'f83OJ3D2xF1Bg8vub9tLe1gHMzV76e8Tus9uPHvRVEU',
"y" : b64'x_FEzRu9m36HLN_tue659LNpXW6pCyStikYjKIWI5a0' / y / -3 : b64'x_FEzRu9m36HLN_tue659LNpXW6pCyStikYjKIWI5a0'
} }
} }
} }
Figure 13: Access Token Including Public Key of the Client Figure 13: Access Token Including Public Key of the Client
Messages C and F are shown in Figures 14 and 15. Messages C and F are shown in Figures 14 and 15.
C: The client then sends the PoP access token to the authz-info C: The client then sends the PoP access token to the authz-info
endpoint at the RS. This is a plain CoAP POST request, i.e., no endpoint at the RS. This is a plain CoAP POST request, i.e., no
skipping to change at line 3808 skipping to change at line 3811
| 2.05 | Payload: <Response-Payload> | 2.05 | Payload: <Response-Payload>
| | | |
Figure 16: Token Request and Response Using Client Credentials Figure 16: Token Request and Response Using Client Credentials
The information contained in the Request-Payload and the Response- The information contained in the Request-Payload and the Response-
Payload is shown in Figure 17. Payload is shown in Figure 17.
Request-Payload: Request-Payload:
{ {
"client_id" : "keyfob", / client_id / 24 : "keyfob",
"audience" : "PACS1337" / audience / 5 : "PACS1337"
} }
Response-Payload: Response-Payload:
{ {
"access_token" : b64'VGVzdCB0b2tlbg==', / access_token / 1 : b64'VGVzdCB0b2tlbg==',
"cnf" : { / cnf / 8 : {
"COSE_Key" : { / COSE_Key / 1 : {
"kid" : b64'c29tZSBwdWJsaWMga2V5IGlk', / kid / 2 : b64'c29tZSBwdWJsaWMga2V5IGlk',
"kty" : "oct", / kty / 1 : 4 / Symmetric /,
"alg" : "HS256", / k / -1 : b64'ZoRSOrFzN_FzUA5XKMYoVHyzff5oRJxl-IXRtztJ6uE'
"k": b64'ZoRSOrFzN_FzUA5XKMYoVHyzff5oRJxl-IXRtztJ6uE'
} }
} }
} }
Figure 17: Request and Response Payload for the C Offline Figure 17: Request and Response Payload for the C Offline
In this case, the access token is just an opaque byte string In this case, the access token is just an opaque byte string
referencing the authorization information at the AS. referencing the authorization information at the AS.
C: Next, the client POSTs the access token to the authz-info C: Next, the client POSTs the access token to the authz-info
skipping to change at line 3848 skipping to change at line 3850
assumed to have performed mutual authentication using a pre- assumed to have performed mutual authentication using a pre-
shared security context (PSK, RPK, or certificate) with the RS shared security context (PSK, RPK, or certificate) with the RS
acting as the DTLS client. acting as the DTLS client.
E: The AS provides the introspection response (2.05 Content) E: The AS provides the introspection response (2.05 Content)
containing parameters about the token. This includes the containing parameters about the token. This includes the
confirmation key (cnf) parameter that allows the RS to verify the confirmation key (cnf) parameter that allows the RS to verify the
client's proof of possession in step F. Note that our example in client's proof of possession in step F. Note that our example in
Figure 19 assumes a preestablished key (e.g., one used by the Figure 19 assumes a preestablished key (e.g., one used by the
client and the RS for a previous token) that is now only client and the RS for a previous token) that is now only
referenced by its key identifier 'kid'. referenced by its key identifier kid.
After receiving message E, the RS responds to the client's POST After receiving message E, the RS responds to the client's POST
in step C with the CoAP response code 2.01 (Created). in step C with the CoAP response code 2.01 (Created).
Resource Resource
Client Server Client Server
| | | |
C: +-------->| Header: POST (T=CON, Code=0.02) C: +-------->| Header: POST (T=CON, Code=0.02)
| POST | Uri-Path:"authz-info" | POST | Uri-Path:"authz-info"
| | Payload: b64'VGVzdCB0b2tlbg==' | | Payload: b64'VGVzdCB0b2tlbg=='
skipping to change at line 3884 skipping to change at line 3886
| 2.01 | | 2.01 |
| | | |
Figure 18: Token Introspection for the C Offline Figure 18: Token Introspection for the C Offline
The information contained in the Request-Payload and the Response- The information contained in the Request-Payload and the Response-
Payload is shown in Figure 19. Payload is shown in Figure 19.
Request-Payload: Request-Payload:
{ {
"token" : b64'VGVzdCB0b2tlbg==', / token / 11 : b64'VGVzdCB0b2tlbg==',
"client_id" : "FrontDoor", / client_id / 24 : "FrontDoor",
} }
Response-Payload: Response-Payload:
{ {
"active" : true, / active / 10 : true,
"aud" : "lockOfDoor4711", / aud / 3 : "lockOfDoor4711",
"scope" : "open, close", / scope / 9 : "open, close",
"iat" : 1563454000, / iat / 6 : 1563454000,
"cnf" : { / cnf / 8 : {
"kid" : b64'c29tZSBwdWJsaWMga2V5IGlk' / kid / 2 : b64'c29tZSBwdWJsaWMga2V5IGlk'
} }
} }
Figure 19: Request and Response Payload for Introspection Figure 19: Request and Response Payload for Introspection
The client uses the symmetric PoP key to establish a DTLS The client uses the symmetric PoP key to establish a DTLS
PreSharedKey secure connection to the RS. The CoAP request PUT is PreSharedKey secure connection to the RS. The CoAP request PUT is
sent to the uri-path /state on the RS, changing the state of the door sent to the uri-path /state on the RS, changing the state of the door
to locked. to locked.
 End of changes. 52 change blocks. 
158 lines changed or deleted 160 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/