Change:
Not much here, though a couple points I'll leave some further comments on, as the proper disposition is not entirely clear.
If you agree NAME I would go ahead and merge this PR (excluding the "update of access rights" change at l.776).
Sorry, I missed this when it came in. Please go ahead.

Discussion:
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 <del> client's identifier (assigned as discussed in as-c) and optionally the context identifier (if assigned as discussed in as-c).  The CBOR array is defined in kid, and follows the notation of RFC8610.  These </del> <ins> 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 </ins> 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

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- <del> oauth-params, as value of a field named 'osc' registered in osc-cwt and osc-jwt.  The master secret MUST be communicated as the 'ms' </del> <ins> 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' </ins> 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

client identifier and the context identifier (if it was set and included in the initial access token response by the AS) in the 'kid' field in the 'cnf' parameter of the token, with the same structure <del> defined in kid.  These identifiers need to be included in the response, in order for the RS to identify the previously generated Security Context. </del> <ins> defined in kid.  These identifiers need to be included in the token in order for the RS to identify the previously generated Security Context. </ins> ex5 shows an example of such an AS response, with payload in CBOR diagnostic notation without the tag and value abbreviations.  The

OSCORE (Section 3.1 of RFC8613).  In particular, the OSCORE_Security_Context object is defined to be serialized and transported between nodes, as specified by this document, but can <del> also be used in this way by other specifications if needed.  The OSCORE_Security_Context object can either be encoded as a JSON object or as a CBOR map.  The set of common parameters that can appear in an OSCORE_Security_Context object can be found in the IANA "OSCORE Security Context Parameters" registry (sec-ctx-params-reg), defined for extensibility, and is specified below.  All parameters are optional.  table-key-labels provides a summary of the OSCORE_Security_Context parameters defined in this section. </del> <ins> also be used as a representation of Security Context state by other specifications if needed.  The OSCORE_Security_Context object can either be encoded as a JSON object or as a CBOR map.  The set of common parameters that can appear in an OSCORE_Security_Context object can be found in the IANA "OSCORE Security Context Parameters" registry (sec-ctx-params-reg), defined for extensibility, and is specified below.  All parameters are optional.  table-key-labels provides a summary of the OSCORE_Security_Context parameters defined in this section. </ins> This parameter identifies the OSCORE Version number, which is an int.  For more information about this field, see section 5.4 of

and response to the authz-info endpoint between client and RS.  The client generates a nonce N1, and posts it together with the token that includes the materials (e.g., OSCORE parameters) received from <del> the AS to the RS.  The RS then generates a nonce N2, and use </del> <ins> the AS to the RS.  The RS then generates a nonce N2, and uses </ins> Section 3.2 of RFC8613 to derive a security context based on a shared master secret and the two nonces, established between client and server.  The nonces are encoded as CBOR bstr if CBOR is used, and as

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 <del> the access token using the correct CBOR label (e.g., "cwt" for CWT, "jwt" for JWT) and N1 using the 'nonce1' parameter defined in nonce1. </del> <ins> the access token using the "access_token" parameter and N1 using the 'nonce1' parameter defined in nonce1. </ins> The authz-info endpoint is not protected, nor are the responses from this resource.

If the exchange was an update of access rights, i.e., a new Security Context was derived from a client that already had a Security Context in place, the RS is RECOMMENDED to delete the old Security Context <del> after OSCORE verification and verification of access rights succeed. The RS MUST delete the Security Context if it deletes the access token associated to it. </del> <ins> after OSCORE verification succeeds.  The RS MUST delete the Security Context if it deletes the access token associated to it. </ins> 4.4.