Draft: draft-ietf-ace-oscore-profile

Commentary: Nits and editorials from LC comments  of the requirement on token encryption ( covered by the framework ) Fix examples where token is supposed to be encrypted IANA review fixes 
 " Figure 6 shows an example CWT , containing the necessary OSCORE parameters in the ' cnf ' claim " The CWT contains OSCORE parameters that not always need to be in the ' cnf ' claim , without explaining why they are necessary in this case and could thus be misleading . E.g. replacing " containing the necessary " with " including relevant " circumvents this problem . 
   for Ops - Dir review : It seems to me there are 4 columns but I ca n't understand the meaning of the values under 1st , 2nd , and 3rd columns . I think clarifying in the caption of figure 7 ( and possibly the text above ) that this is the output of CBOR encoded bytes , formatted for easiness of readability , might help the reader . 
 It seems like it ca n't hurt , yes . 
 Nits / editorial comments from Elwyn Davies : [ x ] s1 : Need to expand CoAP on first use.[x ] s1 : Need to expand CBOR on first use.[x ] s1.2 , CDDL : It would useful to mention that the predefined type names from CDDL , especially bstr for byte strings and tstr for text strings , are used extensively in the document . [ x ] s2 , para 1 : s / overview on how / overview of how/[x ] s2 , para 1 : s / as well as OSCORE setup / as well as the OSCORE setup/[x ] s2 , para 2 : s / that's / that is/[x ] s2 , para 8 : Need to expand AEAD on first use.[x ] s2 and Figure 1 : It would be helpful to the reader if Figure 1 and its descriptive paragraph was placed closer to the beginning of s2 . Otherwise things like Client C ' need more explanation to point the reader at the figure . [ x ] s2 , para 3 : This says : To determine the AS in charge of a resource hosted at the RS , the client C MAY send an initial Unauthorized Resource Request message to the RS . The RS then denies the request and sends the address of its AS back to the client C as specified in section 5.1 of [ I - D.ietf - ace - oauth - authz ] . The access token request and response MUST be confidentiality - protected and ensure authenticity I found the combination of the Unauthorized Requst and the confidentiality - protected etc confusing . If the last sentence does apply to the Unuthorized Request it would be helpful to make it clear that this is not just a generic statement but does apply to the Unauthorized Request as well . [ x ] Figure1 : For consistency the first line should say Unauthorized Rsource Request . I would also suggest explaining the mapping between what is said in the text and the terms ' Ceation Hints ' and ' Access Information ' used in the figure . [ x ] s3.1 , para after Figure 2 : The term ' audience ' appears in this paragraph without any context indicating what it means . Later in s3.2 it appears that audience is associated with CBOR web tokens ( RFC 8392 ) . But it may also might also be realted to draft - oauth - token exchange . The appropriate reference ahould be and should be explained in s3.1 . [ x ] Figure 3 : Should IdContext be ContextId ? ContextId is used evrywhere else.[x ] s3.2 : Expand HKDF on first use ( in second set of bullets).[x ] s3.2 , para after 2nd set of bullets : I think the four instances of ' may ' ought to be ' MAY ' . [ x ] s3.2.1 : It would be helpful to provide references to the online versions of the IANA registries ( 3 places ) . [ x ] s4.2 , para 1 : A foward reference to s5 where the comunication mechanisms needed for introspection are described . [ x ] s4.1 , para 2 : s / from what described / from what is described/[x ] s4.2 , para 5 : s / that's / that is/[x ] s4.2 , last para ; s / This simplifies for the RS track / This simplies the process needed by the RS to keep track/ [ x ] s8 , para 6 : s / tasked of / tasked with/[x ] s9.3 : I do n't think the Value Type for nonce is ' IESG ' ! lol 
 salt in OSCORE Security Context is defined as : But it is used as one of the inputs to OSCORE Master Salt ... should we rephrase this definition ? ( Also requires editorial modifications to make it correct in the rest of the text ) . 
 Rephrasing the definition seems like the right thing to do . There 's probably some flexibility about whether we literally say " an input to the OSCORE Master Salt " , " unique per - token salt " , or something else . 
 I like " an input to the OSCORE Master Salt " . Thanks ! 
 For  ID : do we want to add CoAP client / server ? ( and same for Recipient ID ) This is related to the discussion with and 
 Suggestion : " OSCORE sender ID of the ACE client that requested the token , OSCORE recipient ID of the ACE RS " " CoAP client / server " would not really help , as in future communication that 's exactly what can switch . ( I tried to shorten the wording , but stopped when it occurred to me that the original RS could , during role - reversed communication , try to upgrade its own client credentials on the OSCORE context , and that 's where terminology gets messy . ) 
  yes that would be more precise in this document , but I was hoping to get a more general definition ( not based on Ace roles ) in case we would want to use this same structure ( OSCORESecurityContext ) elsewhere , where  roles would not apply ... to me it would be CoAP Client and  implying at the time of sending / receiving ... 
 One way to make it more generic would be to do a bit like in EDHOC and speak of parties A and B , and say in the application to ACE - OSCORE that party A is the client and party B is the server . ( But given the structure is not defined for this more general purpose here , that 'd be a hard sell . ) 
 Right ... I guess we could keep " client " and " server " terminology here ( which is willingly ambiguous ) in the IANA registration , and in the text where these fields are used add some clarification that those terms in this document refer to the Ace client and server to the   server . 
 Change value type IESG to bstr 
 [ x ] Update reference to the right section in the framework : s / section 8.7 / section 8.8 [ x ] Fix the fields : s / Profile ID / CBOR Value ; remove   ; s / Specification Document(s)/reference 
 Even though the spec clearly mandates encryption of the token ( as it 's transported in the open to the RS ) , several examples have a token as h ' ... ' , which contains the { 3:"tempSens ... " } string and thus indicates an unprotected token . The hex representation of a suitable encrypted CWT ( which AFAICT would still start as valid CBOR but contain an Encrypt0 structure ) would probably fit there .
Paragraph (version A):
This memo specifies a profile of the ACE framework I-D.ietf-ace-
oauth-authz.  In this profile, a client and a resource server use
CoAP RFC7252 to communicate.  The client uses an access token, bound
to a key (the proof-of-possession key) to authorize its access to the
resource server.  Note that this profile uses a symmetric-crypto-
based scheme, where the symmetric secret is used as input material
for keying material derivation.  In order to provide communication
security, proof of possession, and server authentication the client
and resource server use Object Security for Constrained RESTful
Environments (OSCORE) RFC8613.  Note that the proof of possession is
not done by a dedicated protocol element, but rather occurs
implicitly, based on knowledge of the security keying material.
Paragraph (version B):
This memo specifies a profile of the ACE framework I-D.ietf-ace-
oauth-authz.  In this profile, a client and a resource server use the
Constrained Application Protocol (CoAP) RFC7252 to communicate.  The
client uses an access token, bound to a key (the proof-of-possession
key) to authorize its access to the resource server.  Note that this
profile uses a symmetric-crypto-based scheme, where the symmetric
secret is used as input material for keying material derivation.  In
order to provide communication security, proof of possession, and
server authentication the client and resource server use Object
Security for Constrained RESTful Environments (OSCORE) RFC8613.  Note
that the proof of possession is not done by a dedicated protocol
element, but rather occurs implicitly, based on knowledge of the
security keying material.
Paragraph (version A):
Concise Data Definition Language (CDDL) RFC8610 is used in this
specification.
Paragraph (version B):
Concise Binary Object Representation (CBOR) I-D.ietf-cbor-7049bis and
Concise Data Definition Language (CDDL) RFC8610 are used in this
specification.  CDDL predefined type names, especially bstr for byte
strings and tstr for text strings, are used extensively in the
document.
Paragraph (version A):
This section gives an overview on how to use the ACE Framework I-
D.ietf-ace-oauth-authz to secure the communication between a client
and a resource server using OSCORE RFC8613.  The parameters needed by
the client to negotiate the use of this profile with the
authorization server, as well as OSCORE setup process, are described
in detail in the following sections.
Paragraph (version A):
The RS maintains a collection of OSCORE Security Contexts with
associated authorization information for all the clients that it is
communicating with.  The authorization information is maintained as
policy that's used as input to processing requests from those
clients.
Paragraph (version A):
This profile requires a client to retrieve an access token from the
AS for the resource it wants to access on a RS, using the token
endpoint, as specified in section 5.6 of I-D.ietf-ace-oauth-authz.
To determine the AS in charge of a resource hosted at the RS, the
client C MAY send an initial Unauthorized Resource Request message to
the RS.  The RS then denies the request and sends the address of its
AS back to the client C as specified in section 5.1 of I-D.ietf-ace-
oauth-authz.  The access token request and response MUST be
confidentiality-protected and ensure authenticity.  This profile
RECOMMENDS the use of OSCORE between client and AS, but other
protocols (such as TLS or DTLS) can be used as well.
Paragraph (version B):
This section gives an overview of how to use the ACE Framework I-
D.ietf-ace-oauth-authz to secure the communication between a client
and a resource server using OSCORE RFC8613.  The parameters needed by
the client to negotiate the use of this profile with the
authorization server, as well as the OSCORE setup process, are
described in detail in the following sections.
Paragraph (version B):
The RS maintains a collection of OSCORE Security Contexts with
associated authorization information for all the clients that it is
communicating with.  The authorization information is maintained as
policy that is used as input to processing requests from those
clients.
Paragraph (version B):
This profile requires a client to retrieve an access token from the
AS for the resource it wants to access on a RS, by sending an access
token request to the token endpoint, as specified in section 5.6 of
I-D.ietf-ace-oauth-authz.  To determine the AS in charge of a
resource hosted at the RS, the client MAY send an initial
Unauthorized Resource Request message to the RS.  The RS then denies
the request and sends the address of its AS back to the client as
specified in section 5.1 of I-D.ietf-ace-oauth-authz.  The access
token request and response MUST be confidentiality-protected and
ensure authenticity.  This profile RECOMMENDS the use of OSCORE
between client and AS, but other protocols (such as TLS or DTLS) can
be used as well.
Paragraph (version A):
The use of random nonces during the exchange prevents the reuse of an
AEAD nonces/key pair for two different messages.  This situation
might occur when client and RS derive a new Security Context from an
existing (non-expired) access token, as might occur when either party
has just rebooted.  Instead, by using random nonces as part of the
Master Salt, the request to the authz-info endpoint posting the same
token results in a different Security Context, by OSCORE
construction, since even though the Master Secret, Sender ID and
Recipient ID are the same, the Master Salt is different (see
Section 3.2.1 of RFC8613).  Therefore, the main requirement for the
nonces is that they have a good amount of randomness.  If random
nonces were not used, a node re-using a non-expired old token would
be susceptible to on-path attackers provoking the creation of OSCORE
messages using old AEAD keys and nonces.
Paragraph (version B):
The use of random nonces during the exchange prevents the reuse of an
Authenticated Encryption with Associated Data (AEAD) nonces/key pair
for two different messages.  This situation might occur when client
and RS derive a new Security Context from an existing (non-expired)
access token, as might occur when either party has just rebooted.
Instead, by using random nonces as part of the Master Salt, the
request to the authz-info endpoint posting the same token results in
a different Security Context, by OSCORE construction, since even
though the Master Secret, Sender ID and Recipient ID are the same,
the Master Salt is different (see Section 3.2.1 of RFC8613).
Therefore, the main requirement for the nonces is that they have a
good amount of randomness.  If random nonces were not used, a node
re-using a non-expired old token would be susceptible to on-path
attackers provoking the creation of OSCORE messages using old AEAD
keys and nonces.
Paragraph (version A):
An overview of the profile flow for the OSCORE profile is given in
prof-overview.
Paragraph (version B):
An overview of the profile flow for the OSCORE profile is given in
prof-overview.  The names of messages coincide with those of I-
D.ietf-ace-oauth-authz when applicable.
Paragraph (version A):
If the client wants to update its access rights without changing an
existing OSCORE Security Context, it MUST include in its POST request
to the token endpoint a req_cnf object.  The req_cnf MUST include a
kid field carrying a bstr-wrapped CBOR array object containing the
client's identifier (assigned as discussed in as-c) and the context
identifier (if assigned as discussed in as-c).  The CBOR array is
defined in kid, and follows the notation of RFC8610.  These
identifiers, together with other information such as audience, can be
used by the AS to determine the shared secret bound to the proof-of-
possession token and therefore MUST identify a symmetric key that was
previously generated by the AS as a shared secret for the
communication between the client and the RS.  The AS MUST verify that
the received value identifies a proof-of-possession key that has
previously been issued to the requesting client.  If that is not the
case, the Client-to-AS request MUST be declined with the error code
'invalid_request' as defined in Section 5.6.3 of I-D.ietf-ace-oauth-
authz.
Paragraph (version B):
If the client wants to update its access rights without changing an
existing OSCORE Security Context, it MUST include in its POST request
to the token endpoint a req_cnf object.  The req_cnf MUST include a
kid field carrying a bstr-wrapped CBOR array object containing the
client's identifier (assigned as discussed in as-c) and the context
identifier (if assigned as discussed in as-c).  The CBOR array is
defined in kid, and follows the notation of RFC8610.  These
identifiers, together with other information such as audience (see
Section 5.6.1 of I-D.ietf-ace-oauth-authz), can be used by the AS to
determine the shared secret bound to the proof-of-possession token
and therefore MUST identify a symmetric key that was previously
generated by the AS as a shared secret for the communication between
the client and the RS.  The AS MUST verify that the received value
identifies a proof-of-possession key that has previously been issued
to the requesting client.  If that is not the case, the Client-to-AS
request MUST be declined with the error code 'invalid_request' as
defined in Section 5.6.3 of I-D.ietf-ace-oauth-authz.
Paragraph (version A):
The OSCORE_Security_Context is a CBOR map object, defined in oscore-
sec-ctx.  This object is transported in the 'cnf' parameter of the
access token response as defined in Section 3.2 of I-D.ietf-ace-
oauth-params, as the value of a field named 'osc', registered in osc-
cwt and osc-jwt.  The master secret MUST be communicated as the 'ms'
field in the 'osc' field in the 'cnf' parameter of the access token
response as defined in Section 3.2 of I-D.ietf-ace-oauth-params.  The
AEAD algorithm may be included as the 'alg' parameter in the
OSCORE_Security_Context; the HKDF algorithm may be included as the
'hkdf' parameter of the OSCORE_Security_Context, a salt may be
included as the 'salt' parameter of the OSCORE_Security_Context, and
the OSCORE version number may be included as the 'version' parameter
of the OSCORE_Security_Context.
Paragraph (version A):
The same parameters MUST be included as part of the access token.
This profile RECOMMENDS the use of CBOR web token (CWT) as specified
in RFC8392.  If the token is a CWT, the same OSCORE_Security_Context
structure defined above MUST be placed in the 'osc' field of the
'cnf' claim of this token.  The access token MUST be encrypted, since
it will be transferred from the client to the RS over an unprotected
channel.
Paragraph (version A):
The AS MUST also assign an identifier to the RS (serverId), and to
the client (clientId), and MAY assign an identifier to the context
(contextId).  These identifiers are then used as Sender ID, Recipient
ID and ID Context in the OSCORE context as described in section 3.1
of RFC8613.  Applications need to consider that these identifiers are
sent in the clear and may reveal information about the endpoints, as
mentioned in section 12.8 of RFC8613.  The pair (client identifier,
context identifier) MUST be unique in the set of all clients for a
single RS.  Moreover, clientId, serverId and (when assigned)
contextId MUST be included in the OSCORE_Security_Context, as defined
in oscore-sec-ctx.
Paragraph (version B):
This data is transported in the the OSCORE_Security_Context.  The
OSCORE_Security_Context is a CBOR map object, defined in oscore-sec-
ctx.  This object is transported in the 'cnf' parameter of the access
token response as defined in Section 3.2 of I-D.ietf-ace-oauth-
params, as the value of a field named 'osc', registered in osc-cwt
and osc-jwt.
Paragraph (version B):
The AS MUST assign an identifier to the RS (server identifier), and
to the client (client identifier), and MAY assign an identifier to
the context (context identifier).  These identifiers are then used as
Sender ID, Recipient ID and ID Context in the OSCORE context as
described in section 3.1 of RFC8613: specifically, the server
identifier is used as Sender ID of the node acting as RS in this
profile, and the client identifier is used as Sender ID of the node
acting as ACE client.  These parameters are sent as clientId,
serverId and (when assigned) contextId in the
OSCORE_Security_Context.  ClientId and serverId MUST be included in
the OSCORE_Security_Context, contextId MUST be included when
assigned.  The applications need to consider that these identifiers
are sent in the clear and may reveal information about the endpoints,
as mentioned in section 12.8 of RFC8613.  The pair (client
identifier, context identifier) MUST be unique in the set of all
clients for a single RS.
Paragraph (version B):
The master secret MUST be communicated as the 'ms' field in the 'osc'
field in the 'cnf' parameter of the access token response.  If
included, the AEAD algorithm is sent in the 'alg' parameter in the
OSCORE_Security_Context; the HKDF algorithm in the 'hkdf' parameter
of the OSCORE_Security_Context; a salt in the 'salt' parameter of the
OSCORE_Security_Context; and the OSCORE version in the 'version'
parameter of the OSCORE_Security_Context.
Paragraph (version B):
The same parameters MUST be included in the claims associated with
the access token.  This profile RECOMMENDS the use of CBOR web token
(CWT) as specified in RFC8392.  If the token is a CWT, the same
OSCORE_Security_Context structure defined above MUST be placed in the
'osc' field of the 'cnf' claim of this token.
Paragraph (version A):
ex2 shows an example CWT, containing the necessary OSCORE parameters
in the 'cnf' claim, in CBOR diagnostic notation without tag and value
abbreviations.
Paragraph (version A):
The same CWT token as in ex2, using the value abbreviations defined
in I-D.ietf-ace-oauth-authz and RFC8747 and encoded in CBOR is shown
in ex2-cbor.
Paragraph (version B):
ex2 shows an example CWT Claims Set, including the relevant OSCORE
parameters in the 'cnf' claim, in CBOR diagnostic notation without
tag and value abbreviations.
Paragraph (version B):
The same CWT Claims Set as in ex2, using the value abbreviations
defined in I-D.ietf-ace-oauth-authz and RFC8747 and encoded in CBOR
is shown in ex2-cbor.  The bytes in hexadecimal are reported in the
first column, while their corresponding CBOR meaning is reported
after the '#' sign on the second column, for easiness of readability.
Paragraph (version A):
ex6 shows an example CWT, containing the necessary OSCORE parameters
in the 'cnf' claim for update of access rights, in CBOR diagnostic
notation without tag and value abbreviations.
Paragraph (version B):
ex6 shows an example CWT Claims Set, containing the necessary OSCORE
parameters in the 'cnf' claim for update of access rights, in CBOR
diagnostic notation without tag and value abbreviations.
Paragraph (version A):
This parameter identifies the OSCORE HKDF Algorithm.  For more
information about this field, see section 3.1 of RFC8613.  The
values used MUST be registered in the IANA "COSE Algorithms"
registry and MUST be HMAC-based HKDF algorithms.  The value can
either be the integer or the text string value of the HMAC-based
HKDF algorithm in the "COSE Algorithms" registry.  In JSON, the
"hkdf" value is a case-sensitive ASCII string or an integer.  In
CBOR, the "hkdf" type is tstr or int, and has label 4.
Paragraph (version A):
This parameter identifies the OSCORE AEAD Algorithm.  For more
information about this field, see section 3.1 of RFC8613 The
values used MUST be registered in the IANA "COSE Algorithms"
registry and MUST be AEAD algorithms.  The value can either be the
integer or the text string value of the HMAC-based HKDF algorithm
in the "COSE Algorithms" registry.  In JSON, the "alg" value is a
case-sensitive ASCII string or an integer.  In CBOR, the "alg"
type is tstr or int, and has label 5.
Paragraph (version A):
This parameter identifies the OSCORE Master Salt value, which is a
byte string.  For more information about this field, see section
byte string.  In CBOR, the "salt" type is bstr, and has label 6.
Paragraph (version B):
This parameter identifies the OSCORE HKDF Algorithm.  For more
information about this field, see section 3.1 of RFC8613.  The
values used MUST be registered in the IANA "COSE Algorithms"
registry (see COSE.Algorithms) and MUST be HMAC-based HKDF
algorithms.  The value can either be the integer or the text
string value of the HMAC-based HKDF algorithm in the "COSE
Algorithms" registry.  In JSON, the "hkdf" value is a case-
sensitive ASCII string or an integer.  In CBOR, the "hkdf" type is
tstr or int, and has label 4.
Paragraph (version B):
This parameter identifies the OSCORE AEAD Algorithm.  For more
information about this field, see section 3.1 of RFC8613 The
values used MUST be registered in the IANA "COSE Algorithms"
registry (see COSE.Algorithms) and MUST be AEAD algorithms.  The
value can either be the integer or the text string value of the
HMAC-based HKDF algorithm in the "COSE Algorithms" registry.  In
JSON, the "alg" value is a case-sensitive ASCII string or an
integer.  In CBOR, the "alg" type is tstr or int, and has label 5.
Paragraph (version B):
This parameter identifies an input to the OSCORE Master Salt
value, which is a byte string.  For more information about this
field, see section 3.1 of RFC8613.  In JSON, the "salt" value is a
Base64 encoded byte string.  In CBOR, the "salt" type is bstr, and
has label 6.
Paragraph (version A):
Note that the use of the payload and the Content-Format is different
from what described in section 5.8.1 of I-D.ietf-ace-oauth-authz,
which only transports the token without any CBOR wrapping.  In this
profile, the client MUST wrap the token and N1 in a CBOR map.  The
client MUST use the Content-Format "application/ace+cbor" defined in
section 8.14 of I-D.ietf-ace-oauth-authz.  The client MUST include
the access token using the "access_token" parameter and N1 using the
'nonce1' parameter defined in nonce1.
Paragraph (version B):
Note that the use of the payload and the Content-Format is different
from what is described in section 5.8.1 of I-D.ietf-ace-oauth-authz,
which only transports the token without any CBOR wrapping.  In this
profile, the client MUST wrap the token and N1 in a CBOR map.  The
client MUST use the Content-Format "application/ace+cbor" defined in
section 8.14 of I-D.ietf-ace-oauth-authz.  The client MUST include
the access token using the "access_token" parameter and N1 using the
'nonce1' parameter defined in nonce1.
Paragraph (version A):
The access token MUST be encrypted, since it is transferred from the
client to the RS over an unprotected channel.
Paragraph (version A):
introspection request to validate the token before responding to the
POST request to the authz-info endpoint.
Paragraph (version B):
introspection request (see Section 5.7.1 of I-D.ietf-ace-oauth-authz)
to validate the token before responding to the POST request to the
authz-info endpoint.
Paragraph (version A):
If the RS receives the token in a OSCORE protected message, it means
that the client is requesting an update of access rights.  The RS
MUST discard any nonce in the request, if any was sent.  The RS MUST
check that the "kid" of the "cnf" parameter of the new access token
matches the OSCORE Security Context used to protect the message.  If
that's the case, the RS MUST discard the old token and associate the
new token to the Security Context identified by "kid".  The RS MUST
respond with a 2.01 (Created) response protected with the same
Security Context, with no payload.  If any verification fails, the RS
MUST respond with a 4.01 (Unauthorized) error response.
Paragraph (version B):
If the RS receives the token in a OSCORE protected message, it means
that the client is requesting an update of access rights.  The RS
MUST discard any nonce in the request, if any was sent.  The RS MUST
check that the "kid" of the "cnf" parameter of the new access token
matches the OSCORE Security Context used to protect the message.  If
that is the case, the RS MUST discard the old token and associate the
new token to the Security Context identified by "kid".  The RS MUST
respond with a 2.01 (Created) response protected with the same
Security Context, with no payload.  If any verification fails, the RS
MUST respond with a 4.01 (Unauthorized) error response.
Paragraph (version A):
As specified in section 5.8.1 of I-D.ietf-ace-oauth-authz, when
receiving an updated access token with updated authorization
information from the client (see c-as), it is recommended that the RS
overwrites the previous token, that is only the latest authorization
information in the token received by the RS is valid.  This
simplifies for the RS to keep track of authorization information for
a given client.
Paragraph (version B):
As specified in section 5.8.1 of I-D.ietf-ace-oauth-authz, when
receiving an updated access token with updated authorization
information from the client (see c-as), it is recommended that the RS
overwrites the previous token, that is only the latest authorization
information in the token received by the RS is valid.  This
simplifies the process needed by the RS to keep track of
authorization information for a given client.
Paragraph (version A):
Although encrypted, the token is sent in the clear to the authz-info
endpoint, so if a client uses the same single token from multiple
locations with multiple Resource Servers, it can risk being tracked
by the token's value.
Paragraph (version A):
The AS is the party tasked of assigning the identifiers used in
OSCORE, which are privacy sensitive (see Section 12.8 of RFC8613),
and which could reveal information about the client, or may be used
for correlating requests from one client.
Paragraph (version B):
The token is sent in the clear to the authz-info endpoint, so if a
client uses the same single token from multiple locations with
multiple Resource Servers, it can risk being tracked by the token's
value even when the access token is encrypted.
Paragraph (version B):
The AS is the party tasked with assigning the identifiers used in
OSCORE, which are privacy sensitive (see Section 12.8 of RFC8613),
and which could reveal information about the client, or may be used
for correlating requests from one client.