Draft: draft-ietf-ace-oscore-profile

Commentary: 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 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 .
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 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 B):
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):
If the client has requested an update to its access rights using the
same OSCORE Security Context, which is valid and authorized, the AS
MUST omit the 'cnf' parameter in the response, and MUST carry 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
defined in kid.  These identifiers need to be included in the
response, in order for the RS to identify the previously generated
Security Context.
Paragraph (version B):
If the client has requested an update to its access rights using the
same OSCORE Security Context, which is valid and authorized, the AS
MUST omit the 'cnf' parameter in the response, and MUST carry 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
defined in kid.  These identifiers need to be included in the token
in order for the RS to identify the previously generated Security
Context.
Paragraph (version A):
An OSCORE_Security_Context is an object that represents part or all
of an OSCORE Security Context, i.e., the local set of information
elements necessary to carry out the cryptographic operations in
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
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.
Paragraph (version B):
An OSCORE_Security_Context is an object that represents part or all
of an OSCORE Security Context, i.e., the local set of information
elements necessary to carry out the cryptographic operations in
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
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.
Paragraph (version A):
The following subsections describe the details of the POST request
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
the AS to the RS.  The RS then generates a nonce N2, and use
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
Base64 string if JSON is used.  This security context is used to
protect all future communication between client and RS using OSCORE,
as long as the access token is valid.
Paragraph (version B):
The following subsections describe the details of the POST request
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
the AS to the RS.  The RS then generates a nonce N2, and uses
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
Base64 string if JSON is used.  This security context is used to
protect all future communication between client and RS using OSCORE,
as long as the access token is valid.
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 correct CBOR label (e.g., "cwt" for CWT,
"jwt" for JWT) 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 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):
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
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.
Paragraph (version B):
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
after OSCORE verification succeeds.  The RS MUST delete the Security
Context if it deletes the access token associated to it.