Draft: draft-ietf-ace-oscore-profile

Commentary: OCF comments . 
 check that re - sending token triggers nonces exchange and new security context derived . 
 add a implementation note about namespaces for identifiers in case several methods are used ( EDHOC , ACE , others )
Paragraph (version A):
Moreover, implementers of this specification need to be aware that if
other authentication mechanisms are used to set up OSCORE between the
same client and RS, that do not rely on AS assigning identifiers,
collisions may happen and need to be mitigated.
Paragraph (version B):
Moreover, implementers of this specification need to be aware that if
other authentication mechanisms are used to set up OSCORE between the
same client and RS, that do not rely on AS assigning identifiers,
collisions may happen and need to be mitigated.  A mitigation example
would be to use distinct namespaces of identifiers for different
authentication mechanisms.
Paragraph (version A):
The same CWT token as in ex2, using the value abbreviations defined
in I-D.ietf-ace-oauth-authz and I-D.ietf-ace-cwt-proof-of-possession
and encoded in CBOR is shown in ex2-cbor.
Paragraph (version B):
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 A):
Note that a client may be required to re-POST the access token in
order to complete a request, since an RS may delete a stored access
token at any time, for example due to all storage space being
consumed.  This situation is detected by the client when it receives
an AS Request Creation Hints response.
Paragraph (version B):
Note that a client may be required to re-POST the access token in
order to complete a request, since an RS may delete a stored access
token (and associated Security Context) at any time, for example due
to all storage space being consumed.  This situation is detected by
the client when it receives an AS Request Creation Hints response.
Reposting the same access token will result in deriving a new OSCORE
Security Context to be used with the RS, as different nonces will be
used.
Paragraph (version B):
If the client has already posted a valid token, has already
established a security association with the RS, and wants to update
its access rights, the client can do so by posting the new token
(retrieved from the AS and containing the update of access rights) to
the /authz-info endpoint.  The client MUST protect the request using
the OSCORE Security Context established during the first token
exchange.  The client MUST only send the access token in the payload,
no nonce is sent.  After proper verification (see rs-c), the RS will
replace the old token with the new one, maintaining the same Security
Context.
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'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 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.  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.
Paragraph (version B):
the client has successfully replaced the current security context
with a newer one by posting an access token to the unprotected
/authz-info endpoint at the RS, e.g., by re-posting the same
token, as specified in c-rs.
Paragraph (version B):
Whenever one more access token is successfully posted to the RS, and
a new Security Context is derived between the client and RS, messages
in transit that were protected with the previous Security Context
might not pass verification, as the old context is discarded.  That
means that messages sent shortly before the client posts one more
access token to the RS might not successfully reach the destination.
Analogously, implementations may want to cancel CoAP observations at
the RS registered before the Security Context is replaced, or
conversely they will need to implement a mechanism to ensure that
those observation are to be protected with the newly derived Security
Context.