Change:
The access token also comprises a "cnf" claim.  This claim usually contains a "COSE_Key" object that carries either the symmetric key <del> itself or or a key identifier that can be used by the resource server to determine the shared secret.  If the access token carries a symmetric key, the access token MUST be encrypted using a </del> <ins> itself or a key identifier that can be used by the resource server to determine the secret key shared with the client.  If the access token carries a symmetric key, the access token MUST be encrypted using a </ins> "COSE_Encrypt0" structure.  The AS MUST use the keying material shared with the RS to encrypt the token. <del> Instead of providing the keying material, the AS MAY include a key derivation function and a salt in the access token that enables the </del> <ins> A response that declines any operation on the requested resource is constructed according to Section 5.2 of RFC 6749 [18], (cf. Section 5.7.3. of draft-ietf-ace-oauth-authz [19]). The method for how the resource server determines the symmetric key from an access token containing only a key identifier is application specific, the remainder of this section provides one example. The AS and the resource server are assumed to share a key derivation key used to derive the symmetric key shared with the client from the key identifier in the access token.  The key derivation key may be derived from some other secret key shared between the AS and the resource server.  Knowledge of the symmetric key shared with the client must not reveal any information about the key derivation key or other secret keys shared between AS and resource server. In order to generate a new symmetric key to be used by client and resource server, the AS generates a key identifier and uses the key derivation key shared with the resource server to derive the symmetric key as specified below.  Instead of providing the keying material in the access token, the AS includes the key identifier in the "kid" parameter, see kdf-cnf.  This key identifier enables the </ins> resource server to calculate the keying material for the <del> communication with C from the access token.  In this case, the token contains a "cnf" structure that specifies the key derivation algorithm and the salt that the AS has used to construct the shared key.  AS and RS MUST use their shared keying material for the key derivation, and the key derivation MUST follow Section 11 of RFC 8152 [18] with parameters as specified here.  The KDF specified in the "alg" parameter SHOULD be HKDF-SHA-256.  The salt picked by the AS must be uniformly random and is carried in the "salt" parameter. </del> <ins> communication with the client from the access token using the key derivation key and following Section 11 of RFC 8152 [20] with parameters as specified here.  The KDF to be used needs to be defined by the application, for example HKDF-SHA-256.  The key identifier picked by the AS needs to be unique for each access token where a unique symmetric key is required. </ins> The fields in the context information "COSE_KDF_Context" <del> (Section 11.2 of RFC 8152 [19]) MUST have the following values: </del> <ins> (Section 11.2 of RFC 8152 [21]) have the following values: </ins> <del> AlgorithmID = "ACE-CoAP-DTLS-salt" </del> <ins> AlgorithmID = "ACE-CoAP-DTLS-key-derivation" </ins> PartyUInfo = PartyVInfo = ( null, null, null ) <del> keyDataLength is a uint equal the length of the key shared between AS and RS in bits </del> <ins> keyDataLength is a uint equal the length of the symmetric key shared between C and RS in bits </ins> protected MUST be a zero length bstr

Discussion:
The normative specification of how to use a salt for deriving a symmetric key to use between C and RS is changed into an example using cnf = COSE_key.
The text claims to present an example, but contains a lot of normative language (probably heritage from when it was normative text). I don't think that goes well together and it leaves the reader with an unclear feeling as to where the example ends and normative text resumes. I would suggest to remove all normative language from the example and make it clear at which point the example ends and normative text resumes. I do like the idea to present this mechanism as an example however, since it is really up to the applications how they retrieve a key based on a key identifier, and I believe derivation is a fine example here.
In 9624eea the normative text is removed from the example and the example is moved to the end of the section to separate the example from the rest of the text.
Just to clarify if my understanding is correct: The proposal says that if the access token contains but no , the RS needs to derive K{C, RS} in some application-specific way?
Yes, with the interpretation that "derive" could mean "look up", "retrieve" etc. I.e. the RS needs to know how to obtain k{C, RS} from kid. Can the text be further clarified?
No, this is what I also think that the text says. Thus, I am fine merging this PR.
Since two co-authors are OK I merge this now. Further comments can be added on the master branch.