Draft: draft-ietf-ace-oauth-authz

Commentary: Thank you  .
Authorization is the process for granting approval to an entity to
access a resource RFC4949.  The authorization task itself can best be
described as granting access to a requesting client, for a resource
hosted on a device, the resource server (RS).  This exchange is
mediated by one or multiple authorization servers (AS).  Managing
authorization for a large number of devices and users is a complex
task.
While prior work on authorization solutions for the Web and for the
mobile environment also applies to the IoT environment many IoT
devices are constrained, for example in terms of processing
capabilities, available memory, etc.  For web applications on
constrained nodes this specification makes use of CoAP RFC7252.
Authorization is the process for granting approval to an entity to
access a resource RFC4949.  The authorization task itself can best be
described as granting access to a requesting client, for a resource
hosted on a device, the resource server (RS).  This exchange is
mediated by one or multiple authorization servers (AS).  Managing
authorization for a large number of devices and users can be a
complex task.
While prior work on authorization solutions for the Web and for the
mobile environment also applies to the IoT environment, many IoT
devices are constrained, for example, in terms of processing
capabilities, available memory, etc.  For web applications on
constrained nodes, this specification makes use of CoAP RFC7252.
Since we describe exchanges as RESTful protocol interactions HTTP
RFC7231 offers useful terminology.
Since we describe exchanges as RESTful protocol interactions, HTTP
RFC7231 offers useful terminology.
We call the specifications of this memo the "framework" or "ACE
framework".  When referring to "profiles of this framework" we mean
additional memo's that define the use of this specification with
concrete transport, and communication security protocols (e.g.  CoAP
over DTLS).
We call the specifications of this memo the "framework" or "ACE
framework".  When referring to "profiles of this framework" we mean
additional specifications that define the use of this specification
with concrete transport, and communication security protocols (e.g.,
CoAP over DTLS).
Another building block is the lightweight web transfer protocol CoAP
RFC7252 for those communication environments where HTTP is not
appropriate.  CoAP typically runs on top of UDP which further reduces
overhead and message exchanges.  While this specification defines
extensions for the use of OAuth over CoAP, we do envision further
underlying protocols to be supported in the future, such as HTTP/2,
MQTT and QUIC.
A third building block is CBOR RFC7049 for encodings where JSON
RFC7159 is not sufficiently compact.  CBOR is a binary encoding
designed for small code and message size, which may be used for
encoding of self contained tokens, and also for encoding CoAP POST
parameters and CoAP responses.
Another building block is the lightweight web transfer protocol CoAP
RFC7252, for those communication environments where HTTP is not
appropriate.  CoAP typically runs on top of UDP, which further
reduces overhead and message exchanges.  While this specification
defines extensions for the use of OAuth over CoAP, we do envision
further underlying protocols to be supported in the future, such as
HTTP/2, MQTT and QUIC.
A third building block is CBOR RFC7049, for encodings where JSON
RFC7159 is not sufficiently compact.  CBOR is a binary encoding
designed for small code and message size, which may be used for
encoding of self contained tokens, and also for encoding CoAP POST
parameters and CoAP responses.
A fourth building block is the compact CBOR-based secure message
format COSE RFC8152, which enables application layer security as an
alternative or complement to transport layer security (DTLS RFC6347
or TLS RFC5246).  COSE is used to secure self contained tokens such
as proof-of-possession (PoP) tokens, which is an extension to the
OAuth access tokens, and "client tokens" which are defined in this
framework (see clientToken).  The default access token format is
defined in CBOR web token (CWT) I-D.ietf-ace-cbor-web-token.
Application layer security for CoAP using COSE can be provided with
OSCOAP I-D.ietf-core-object-security.
A fourth building block is the compact CBOR-based secure message
format COSE RFC8152, which enables application layer security as an
alternative or complement to transport layer security (DTLS RFC6347
or TLS RFC5246).  COSE is used to secure self-contained tokens such
as proof-of-possession (PoP) tokens, which is an extension to the
OAuth access tokens, and "client tokens" which are defined in this
framework (see clientToken).  The default access token format is
defined in CBOR web token (CWT) I-D.ietf-ace-cbor-web-token.
Application layer security for CoAP using COSE can be provided with
OSCOAP I-D.ietf-core-object-security.
Luckily, not every IoT device suffers from all constraints.  The ACE
framework nevertheless takes all these aspects into account and
allows several different deployment variants to co-exist rather than
mandating a one-size-fits-all solution.  We believe this is important
to cover the wide range of possible interworking use cases and the
different requirements from a security point of view.  Once IoT
deployments mature, popular deployment variants will be documented in
form of ACE profiles.
Luckily, not every IoT device suffers from all constraints.  The ACE
framework nevertheless takes all these aspects into account and
allows several different deployment variants to co-exist, rather than
mandating a one-size-fits-all solution.  We believe this is important
to cover the wide range of possible interworking use cases and the
different requirements from a security point of view.  Once IoT
deployments mature, popular deployment variants will be documented in
the form of ACE profiles.
The key bound to the access token (aka PoP key) may be based on
symmetric as well as on asymmetric cryptography.  The appropriate
choice of security depends on the constraints of the IoT devices
as well as on the security requirements of the use case.
The key bound to the access token (the PoP key) may use either
symmetric or asymmetric cryptography.  The appropriate choice of
the kind of cryptography depends on the constraints of the IoT
devices as well as on the security requirements of the use case.
The access token is either a simple reference, or a structured
information object (e.g.  CWT I-D.ietf-ace-cbor-web-token),
protected by a cryptographic wrapper (e.g.  COSE RFC8152).  The
choice of PoP key does not necessarily imply a specific credential
type for the integrity protection of the token.
The access token is either a simple reference, or a structured
information object (e.g., CWT I-D.ietf-ace-cbor-web-token),
protected by a cryptographic wrapper (e.g., COSE RFC8152).  The
choice of PoP key does not necessarily imply a specific credential
type for the integrity protection of the token.
The values of the scope parameter are expressed as a list of
space- delimited, case-sensitive strings, with a semantic that is
well-known to the AS and the RS.  More details about the concept
of scopes is found under Section 3.3 in RFC6749.
The values of the scope parameter are expressed as a list of
space-delimited, case-sensitive strings, with a semantic that is
well-known to the AS and the RS.  More details about the concept
of scopes is found under Section 3.3 in RFC6749.
Information carried in the access token or returned from
introspection, called claims, is in the form of type-value pairs.
An access token may, for example, include a claim identifying the
AS that issued the token (via the "iss" claim) and what audience
the access token is intended for (via the "aud" claim).  The
audience of an access token can be a specific resource or one or
many resource servers.  The resource owner policies influence what
claims are put into the access token by the authorization server.
Information carried in the access token or returned from
introspection, called claims, is in the form of name-value pairs.
An access token may, for example, include a claim identifying the
AS that issued the token (via the "iss" claim) and what audience
the access token is intended for (via the "aud" claim).  The
audience of an access token can be a specific resource or one or
many resource servers.  The resource owner policies influence what
claims are put into the access token by the authorization server.
While the structure and encoding of the access token varies
throughout deployments, a standardized format has been defined
with the JSON Web Token (JWT) RFC7519 where claims are encoded as
a JSON object.  In I-D.ietf-ace-cbor-web-token an equivalent
format using CBOR encoding (CWT) has been defined.
While the structure and encoding of the access token varies
throughout deployments, a standardized format has been defined
with the JSON Web Token (JWT) RFC7519 where claims are encoded as
a JSON object.  In I-D.ietf-ace-cbor-web-token, an equivalent
format using CBOR encoding (CWT) has been defined.
CoAP is an application layer protocol similar to HTTP, but
specifically designed for constrained environments.  CoAP typically
uses datagram-oriented transport, such as UDP, where reordering and
loss of packets can occur.  A security solution need to take the
latter aspects into account.
While HTTP uses headers and query-strings to convey additional
information about a request, CoAP encodes such information into
header parameters called 'options'.
CoAP supports application-layer fragmentation of the CoAP payloads
through blockwise transfers RFC7959.  However, block-wise transfer
does not increase the size limits of CoAP options, therefore data
encoded in options has to be kept small.
Transport layer security for CoAP can be provided by DTLS 1.2 RFC6347
or TLS 1.2 RFC5246.  CoAP defines a number of proxy operations which
requires transport layer security to be terminated at the proxy.  One
approach for protecting CoAP communication end-to-end through
proxies, and also to support security for CoAP over a different
transport in a uniform way, is to provide security on application
layer using an object-based security mechanism such as COSE RFC8152.
CoAP is an application layer protocol similar to HTTP, but
specifically designed for constrained environments.  CoAP typically
uses datagram-oriented transport, such as UDP, where reordering and
loss of packets can occur.  A security solution needs to take the
latter aspects into account.
While HTTP uses headers and query strings to convey additional
information about a request, CoAP encodes such information into
header parameters called 'options'.
CoAP supports application-layer fragmentation of the CoAP payloads
through blockwise transfers RFC7959.  However, blockwise transfer
does not increase the size limits of CoAP options, therefore data
encoded in options has to be kept small.
Transport layer security for CoAP can be provided by DTLS 1.2 RFC6347
or TLS 1.2 RFC5246.  CoAP defines a number of proxy operations that
require transport layer security to be terminated at the proxy.  One
approach for protecting CoAP communication end-to-end through
proxies, and also to support security for CoAP over a different
transport in a uniform way, is to provide security at the application
layer using an object-based security mechanism such as COSE RFC8152.
The ACE framework is based on the OAuth 2.0 protocol interactions
using the token and introspect endpoints.  A client obtains an access
token from an AS using the token endpoint and subsequently presents
the access token to a RS to gain access to a protected resource.  The
RS, after receiving an access token, may present it to the AS via the
introspect endpoint to get information about the access token.  In
other deployments the RS may process the access token locally without
the need to contact an AS.  These interactions are shown in
fig:protocolFlow.  An overview of various OAuth concepts is provided
in oauth2Overview.
The ACE framework is based on the OAuth 2.0 protocol interactions
using the token and introspect endpoints.  A client obtains an access
token from an AS using the token endpoint and subsequently presents
the access token to a RS to gain access to a protected resource.  The
RS, after receiving an access token, may present it to the AS via the
introspect endpoint to get information about the access token.  In
other deployments, the RS may process the access token locally
without the need to contact an AS.  These interactions are shown in
fig:protocolFlow.  An overview of various OAuth concepts is provided
in oauth2Overview.
constrained.  In such a case the resource owner or another person on
his or her behalf have arranged with the authorization server out-of-
band, which is often accomplished using a commissioning tool.
constrained.  In such a case, the resource owner or another person on
his or her behalf have arranged with the authorization server out-of-
band, which is often accomplished using a commissioning tool.
The consent of the resource owner, for giving a client access to a
protected resource, can be provided dynamically as in the traditional
OAuth flows, or it could be pre-configured by the resource owner as
authorization policies at the AS, which the AS evaluates when a token
request arrives.  The resource owner and the requesting party (i.e.
client owner) are not shown in fig:protocolFlow.
The consent of the resource owner, for giving a client access to a
protected resource, can be provided dynamically as in the traditional
OAuth flows, or it could be pre-configured by the resource owner as
authorization policies at the AS, which the AS evaluates when a token
request arrives.  The resource owner and the requesting party (i.e.,
client owner) are not shown in fig:protocolFlow.
This framework supports a wide variety of communication security
mechanisms between the ACE entities, such as client, AS, and RS.  We
assume that the client has been registered (also called enrolled or
onboarded) to an AS using a mechanism defined outside the scope of
this document.  In practice, various techniques for onboarding have
been used, such as factory-based provisioning or the use of
commissioning tools.  Regardless of the onboarding technique, this
registration procedure implies that the client and the AS share
credentials, and configuration parameters.  These credentials are
used to mutually authenticate each other and to protect messages
exchanged between the client and the AS.
This framework supports a wide variety of communication security
mechanisms between the ACE entities, such as client, AS, and RS.  We
assume that the client has been registered (also called enrolled or
onboarded) to an AS using a mechanism defined outside the scope of
this document.  In practice, various techniques for onboarding have
been used, such as factory-based provisioning or the use of
commissioning tools.  Regardless of the onboarding technique, this
provisioning procedure implies that the client and the AS exchange
credentials and configuration parameters.  These credentials are used
to mutually authenticate each other and to protect messages exchanged
between the client and the AS.
At the start of the protocol there is an optional discovery step
where the client discovers the resource server and the resources this
server hosts.  In this step the client might also determine what
permissions are needed to access the protected resource.  A generic
procedure is described in asDiscovery, profiles MAY define other
procedures for discovery.
At the start of the protocol, there is an optional discovery step
where the client discovers the resource server and the resources this
server hosts.  In this step, the client might also determine what
permissions are needed to access the protected resource.  A generic
procedure is described in asDiscovery, profiles MAY define other
procedures for discovery.
For IoT we cannot generally assume that the client and RS are part
of a common key infrastructure, so the AS provisions credentials
or associated information to allow mutual authentication.  These
credentials need to be provided to the parties before or during
the authentication protocol is executed, and may be re-used for
subsequent token requests.
The ACE framework by default implements proof-of-possession for
access tokens, i.e. that the token holder can prove being a holder
of the key bound to the token.  The binding is provided by the
"cnf" claim I-D.jones-ace-cwt-proof-of-possession indicating what
key is used for proof-of-possession.  If clients need to update a
token, e.g. to get additional rights, they can request that the AS
binds the new access token to the same key as the previous token.
The following sections detail the profiling and extensions of OAuth
framework.
For IoT, we cannot generally assume that the client and RS are
part of a common key infrastructure, so the AS provisions
credentials or associated information to allow mutual
authentication.  These credentials need to be provided to the
parties before or during the authentication protocol is executed,
and may be re-used for subsequent token requests.
The ACE framework, by default, implements proof-of-possession for
access tokens, i.e., that the token holder can prove being a
holder of the key bound to the token.  The binding is provided by
the "cnf" claim I-D.jones-ace-cwt-proof-of-possession indicating
what key is used for proof-of-possession.  If clients need to
update a token, e.g., to get additional rights, they can request
that the AS binds the new access token to the same key as the
previous token.
For details on the different grant types see the OAuth 2.0 framework.
The OAuth 2.0 framework provides an extension mechanism for defining
additional grant types so profiles of this framework MAY define
additional grant types if needed.
Authentication of the client is mandatory independent of the grant
type when requesting the access token from the token endpoint.  In
the case of client credentials grant type the authentication and
grant coincides.
The OAuth framework, RFC6749, defines one client credential type,
client id and client secret.  Profiles of this framework MAY extend
with additional client credentials such as DTLS pre-shared keys or
client certificates.
Client credential does not by default authenticate the AS that the
client connects to.  In classic OAuth the AS is authenticated with a
TLS server certificate.
Profiles of this framework MUST specify how clients authenticate the
AS and how communication security is implemented, otherwise server
side TLS certificates as defined by OAuth 2.0 is required.
The authorization endpoint is used to interact with the resource
owner and obtain an authorization grant in certain grant flows.
Since it requires the use of a user agent (i.e. browser), it is not
expected that these types of grant flow will be used by constrained
clients.  This endpoint is therefore out of scope for this
specification.  Implementations should use the definition and
recommendations of RFC6749 and RFC6819.
For details on the different grant types, see the OAuth 2.0
framework.  The OAuth 2.0 framework provides an extension mechanism
for defining additional grant types so profiles of this framework MAY
define additional grant types, if needed.
Authentication of the client is mandatory independent of the grant
type when requesting the access token from the token endpoint.  In
the case of client credentials grant type, the authentication and
grant coincide.
The OAuth framework RFC6749 defines one client credential type,
client id and client secret.  Profiles of this framework MAY extend
with additional client credentials such as DTLS pre-shared keys or
client certificates.
Client credential does not, by default, authenticate the AS that the
client connects to.  In classic OAuth, the AS is authenticated with a
TLS server certificate.
Profiles of this framework MUST specify how clients authenticate the
AS and how communication security is implemented, otherwise server
side TLS certificates, as defined by OAuth 2.0, are required.
The authorization endpoint is used to interact with the resource
owner and obtain an authorization grant in certain grant flows.
Since it requires the use of a user agent (i.e., browser), it is not
expected that these types of grant flow will be used by constrained
clients.  This endpoint is therefore out of scope for this
specification.  Implementations should use the definition and
recommendations of RFC6749 and RFC6819.
In plain OAuth 2.0 the AS provides the token endpoint for submitting
access token requests.  This framework extends the functionality of
the token endpoint, giving the AS the possibility to help client and
RS to establish shared keys or to exchange their public keys.
Furthermore this framework defines encodings using CoAP and CBOR, as
a substitute for HTTP and JSON.
For the AS to be able to issue a token the client MUST be
authenticated and present a valid grant for the scopes requested.
Profiles of this framework MUST specify how the AS authenticates the
client and how the communication between client and AS is protected.
The figures of this section uses CBOR diagnostic notation without the
integer abbreviations for the parameters or their values for
illustrative purposes.  Note that implementations MUST use the
integer abbreviations and the binary CBOR encoding.
The client sends a CoAP POST request to the token endpoint at the AS,
the profile MUST specify the Content-Type and wrapping of the
payload.  The content of the request consists of the parameters
specified in section 4 of the OAuth 2.0 specification RFC6749 encoded
as a CBOR map.
OPTIONAL.  Specifies the audience for which the client is
requesting an access token.  If this parameter is missing it is
assumed that the client and the AS have a pre-established
understanding of the audience that an access token should address.
If a client submits a request for an access token without
specifying an "aud" parameter, and the AS does not have a default
"aud" value for this client, then the AS MUST respond with an
error message with the CoAP response code 4.00 (Bad Request).
In standard OAuth 2.0, the AS provides the token endpoint for
submitting access token requests.  This framework extends the
functionality of the token endpoint, giving the AS the possibility to
help the client and RS to establish shared keys or to exchange their
public keys.  Furthermore, this framework defines encodings using
CoAP and CBOR, as a substitute for HTTP and JSON.
For the AS to be able to issue a token, the client MUST be
authenticated and present a valid grant for the scopes requested.
Profiles of this framework MUST specify how the AS authenticates the
client and how the communication between client and AS is protected.
The figures of this section use CBOR diagnostic notation without the
integer abbreviations for the parameters or their values for
illustrative purposes.  Note that implementations MUST use the
integer abbreviations and the binary CBOR encoding.
The client sends a CoAP POST request to the token endpoint at the AS.
The profile MUST specify the Content-Type and wrapping of the
payload.  The content of the request consists of the parameters
specified in section 4 of the OAuth 2.0 specification RFC6749,
encoded as a CBOR map.
OPTIONAL.  Specifies the audience for which the client is
requesting an access token.  If this parameter is missing, it is
assumed that the client and the AS have a pre-established
understanding of the audience that an access token should address.
If a client submits a request for an access token without
specifying an "aud" parameter, and the AS does not have a default
"aud" value for this client, then the AS MUST respond with an
error message with the CoAP response code 4.00 (Bad Request).
Note that the AS decides which token type and profile to use when
issuing a successful response.  It is assumed that the AS has prior
knowledge of the capabilities of the client, and the RS (see
app:registration.  This prior knowledge may, for example, be set by
the use of a dynamic client registration protocol exchange RFC7591.
Note that the AS decides which token type and profile to use when
issuing a successful response.  It is assumed that the AS has prior
knowledge of the capabilities of the client and the RS (see
app:registration.  This prior knowledge may, for example, be set by
the use of a dynamic client registration protocol exchange RFC7591.
OPTIONAL.  By default implementations of this framework SHOULD
assume that the token_type is "pop".  If a specific use case
requires another token_type (e.g.  "Bearer") to be used then this
parameter is REQUIRED.
OPTIONAL.  By default implementations of this framework SHOULD
assume that the token_type is "pop".  If a specific use case
requires another token_type (e.g., "Bearer") to be used then this
parameter is REQUIRED.
The error code (i.e. value of the "error" parameter) MUST be
abbreviated as specified in fig:cborErrorCodes.
The error code (i.e., value of the "error" parameter) MUST be
abbreviated as specified in fig:cborErrorCodes.
The token_type parameter is defined in RFC6749, allowing the AS to
indicate to the client which type of access token it is receiving
(e.g. a bearer token).
The token_type parameter is defined in RFC6749, allowing the AS to
indicate to the client which type of access token it is receiving
(e.g., a bearer token).
Token introspection RFC7662 is used by the RS and potentially the
client to query the AS for metadata about a given token e.g. validity
or scope.  Analogous to the protocol defined in RFC 7662 RFC7662 for
HTTP and JSON, this section defines adaptations to more constrained
environments using CoAP and CBOR.
Token introspection RFC7662 is used by the RS and potentially the
client to query the AS for metadata about a given token e.g.,
validity or scope.  Analogous to the protocol defined in RFC 7662
RFC7662 for HTTP and JSON, this section defines adaptations to more
constrained environments using CoAP and CBOR.
The RS sends a CoAP POST request to the introspection endpoint at the
AS, the profile MUST specify the Content-Type and wrapping of the
payload.  The payload MUST be encoded as a CBOR map with a "token"
parameter containing either the access token or a reference to the
token (e.g. the cti).  Further optional parameters representing
additional context that is known by the RS to aid the AS in its
response MAY be included.
The RS sends a CoAP POST request to the introspection endpoint at the
AS, the profile MUST specify the Content-Type and wrapping of the
payload.  The payload MUST be encoded as a CBOR map with a "token"
parameter containing either the access token or a reference to the
token (e.g., the cti).  Further optional parameters representing
additional context that is known by the RS to aid the AS in its
response MAY be included.
An RS is able to perform introspection, it MUST do so immediately
after receiving an access token, in order to be able to return a
potential client token in the response.  This does not preclude the
RS to perform additional introspection asynchronously, e.g. when the
token is later used.
An RS is able to perform introspection, it MUST do so immediately
after receiving an access token, in order to be able to return a
potential client token in the response.  This does not preclude the
RS to perform additional introspection asynchronously, e.g., when the
token is later used.
The method consists of an authz-info endpoint, implemented by the RS.
A client using this method MUST make a POST request to the authz-info
endpoint at the RS with the access token in the payload.  The RS
receiving the token MUST verify the validity of the token.  If the
token is valid, the RS MUST respond to the POST request with 2.01
(Created).  This response MAY contain the identifier of the token
(e.g. the cti for a CWT) as a payload.
If the token is not valid, the RS MUST respond with the CoAP response
code 4.01 (Unauthorized).  If the token is valid but the audience of
the token does not match the RS, the RS MUST respond with the CoAP
response code 4.03 (Forbidden).  If the token is valid but is
associated to claims that the RS cannot process (e.g. an unknown
scope) the RS MUST respond with the CoAP response code 4.00 (Bad
Request).  In the latter case the RS MAY provide additional
information in the error response, in order to clarify what went
wrong.
The method consists of an authz-info endpoint, implemented by the RS.
A client using this method MUST make a POST request to the authz-info
endpoint at the RS with the access token in the payload.  The RS
receiving the token MUST verify the validity of the token.  If the
token is valid, the RS MUST respond to the POST request with 2.01
(Created).  This response MAY contain the identifier of the token
(e.g., the cti for a CWT) as a payload.
If the token is not valid, the RS MUST respond with the CoAP response
code 4.01 (Unauthorized).  If the token is valid but the audience of
the token does not match the RS, the RS MUST respond with the CoAP
response code 4.03 (Forbidden).  If the token is valid but is
associated to claims that the RS cannot process (e.g., an unknown
scope) the RS MUST respond with the CoAP response code 4.00 (Bad
Request).  In the latter case the RS MAY provide additional
information in the error response, in order to clarify what went
wrong.
The token is a CWT and includes a "exp" claim and possibly the
"nbf" claim.  The RS verifies these by comparing them to values
from its internal clock as defined in RFC7519.  In this case the
RS's internal clock must reflect the current date and time, or at
least be synchronized with the AS's clock.  How this clock
synchronization would be performed is out of scope for this memo.
The token is a CWT and includes an "exp" claim and possibly the
"nbf" claim.  The RS verifies these by comparing them to values
from its internal clock as defined in RFC7519.  In this case the
RS's internal clock must reflect the current date and time, or at
least be synchronized with the AS's clock.  How this clock
synchronization would be performed is out of scope for this memo.
If a token, that authorizes a long running request such as e.g. a
CoAP Observe RFC7641, expires, the RS MUST send an error response
with the response code 4.01 Unauthorized to the client and then
terminate processing the long running request.
If a token that authorizes a long running request such as a CoAP
Observe RFC7641 expires, the RS MUST send an error response with the
response code 4.01 Unauthorized to the client and then terminate
processing the long running request.
There may exist reasonable use cases where implementers want to
combine different profiles of this framework, e.g. using an MQTT
profile between client and RS, while using a DTLS profile for
interactions between client and AS.  Profiles should be designed in a
way that the security of a protocol interaction does not depend on
the specific security mechanisms used in other protocol interactions.
There may exist reasonable use cases where implementers want to
combine different profiles of this framework, e.g., using an MQTT
profile between client and RS, while using a DTLS profile for
interactions between client and AS.  Profiles should be designed in a
way that the security of a protocol interaction does not depend on
the specific security mechanisms used in other protocol interactions.
The AS is in a very central position can potentially learn sensitive
information about the clients requesting access tokens.  If the
client credentials grant is used, the AS can track what kind of
access the client intends to perform.  With other grants this can be
prevented by the Resource Owner.  To do so the resource owner needs
to bind the grants it issues to anonymous, ephemeral credentials,
that do not allow the AS to link different grants and thus different
access token requests by the same client.
If access tokens are only integrity protected and not encrypted, they
may reveal information to attackers listening on the wire, or able to
acquire the access tokens in some other way.  In the case of CWTs the
token may e.g. reveal the audience, the scope and the confirmation
method used by the client.  The latter may reveal the client's
identity.
Clients using asymmetric keys for proof-of-possession should be aware
of the consequences of using the same key pair for proof-of-
possession towards different RS.  A set of colluding RS or an
attacker able to obtain the access tokens will be able to link the
requests, or even to determine the client's identity.
The AS is in a very central position and can potentially learn
sensitive information about the clients requesting access tokens.  If
the client credentials grant is used, the AS can track what kind of
access the client intends to perform.  With other grants this can be
prevented by the Resource Owner.  To do so, the resource owner needs
to bind the grants it issues to anonymous, ephemeral credentials that
do not allow the AS to link different grants and thus different
access token requests by the same client.
If access tokens are only integrity protected and not encrypted, they
may reveal information to attackers listening on the wire, or able to
acquire the access tokens in some other way.  In the case of CWTs the
token may e.g., reveal the audience, the scope and the confirmation
method used by the client.  The latter may reveal the client's
identity.
Clients using asymmetric keys for proof-of-possession should be aware
of the consequences of using the same key pair for proof-of-
possession towards different RSs.  A set of colluding RSs or an
attacker able to obtain the access tokens will be able to link the
requests, or even to determine the client's identity.
Name of token type as registered in the OAuth token type registry
e.g.  "Bearer".
Name of token type as registered in the OAuth token type registry
e.g., "Bearer".
OAuth Parameter name, refers to the name in the OAuth parameter
registry e.g. "client_id".
OAuth Parameter name, refers to the name in the OAuth parameter
registry e.g., "client_id".
Name of the response parameter as defined in the "OAuth Token
Introspection Response" registry e.g. "active".
Name of the response parameter as defined in the "OAuth Token
Introspection Response" registry e.g., "active".