Draft: draft-ietf-ace-dtls-authorize

Commentary: 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 do n'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 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 ,  } 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 ,  } 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 on the master branch .
The access token also comprises a "cnf" claim.  This claim usually
contains a "COSE_Key" object that carries either the symmetric key
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
"COSE_Encrypt0" structure.  The AS MUST use the keying material
shared with the RS to encrypt the token.
Instead of providing the keying material, the AS MAY include a key
derivation function and a salt in the access token that enables the
resource server to calculate the keying material for the
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.
The access token also comprises a "cnf" claim.  This claim usually
contains a "COSE_Key" object that carries either the symmetric key
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
"COSE_Encrypt0" structure.  The AS MUST use the keying material
shared with the RS to encrypt the token.
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
resource server to calculate the keying material for the
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.
The ACE_Salt "cnf" structure specifying HMAC-based key derivation of
a symmetric key with SHA-256 as hash function and a random salt value
is provided in kdf-cnf.
A response that declines any operation on the requested resource is
constructed according to Section 5.2 of RFC 6749 [20], (cf.
Section 5.7.3. of draft-ietf-ace-oauth-authz [21]).
The "cnf" structure in the access token is provided in kdf-cnf.