Following the procedures defined in [RFC 9202
], a Client can retrieve an access token from an Authorization Server in order to establish a security association with a specific Resource Server. The ace_profile
parameter in the Client-to-AS request and AS-to-Client response is used to determine the ACE profile that the Client uses towards the Resource Server.
parameter indicates the use of the DTLS profile for ACE, as defined in [RFC 9202
]. Therefore, the Client typically first tries using DTLS to connect to the Resource Server. If this fails, the Client MAY
try to connect to the Resource Server via TLS.
As resource-constrained devices are not expected to support both transport layer security mechanisms, Clients and Resource Servers SHOULD
support DTLS and MAY
support TLS. A Client that implements either TLS or DTLS but not both might fail in establishing a secure communication channel with the Resource Server altogether. Nonconstrained Clients and Resource Servers SHOULD
support both TLS and DTLS.
Note that a communication setup with an a priori unknown Resource Server typically employs an initial unauthorized resource request, as illustrated in Section 2
of RFC 9202
. If this message exchange succeeds, the Client SHOULD
first use the same underlying transport protocol for the establishment of the security association to the Resource Server (i.e., DTLS for UDP, and TLS for TCP).
As a consequence, the selection of the transport protocol used for the initial unauthorized resource request also depends on the transport layer security mechanism supported by the Client. Clients that support either DTLS or TLS but not both SHOULD
use the transport protocol underlying the supported transport layer security mechanism for an initial unauthorized resource request to the Resource Server, as in Section 2
of RFC 9202