Draft: draft-ietf-core-object-security

Commentary: Solves issue ( from review comments by : ) 
 In section 5.4 you have the text requestpiv : contains the value of the ' Partial IV ' in the COSE object of the request ( see Section 5 ) , with one exception : in case of protection or verification of Observe cancellations , the requestpiv contains the value of the ' Partial IV ' in the COSE object of the corresponding registration ( see Section 4.1.3.5.1 ) . I am unclear how / why this is different for observations . A cancelation is a message , so the IV is the request . A re - registration is a request message , any response would correspond to that request . The only interesting question has to do with updating the MID on a re - registration but not how PIVs work for this field . 
 Another case to make sure that works Client - please cancel my observation  - I do n't have an observation for you , but sure I am willing to tell you I canceled it . What request PIV would I use in the AAD ? 
 Yes , the verification of cancellation would fail since the server does not have the initial registration 's partial iv saved , if it does not have the observation stored . So OSCORE would fail , which is not right . We have reverted to previous version ( request_piv is not exception for cancellations ) in , but we want to add some security considerations about Observe and cancellations before closing this issue .
Mailing list commentary: Section 4.1.3.1 - I am unclear why an OSCORE error response can be cached by an OSCORE unaware intermediate would be cached , but a success message is never going to be cached . Based on this , I do n't plan to set an outer option . In section 5.4 you have the text requestpiv : contains the value of the ' Partial IV ' in the COSE object of the request ( see Section 5 ) , with one exception : in case of protection or verification of Observe cancellations , the requestpiv contains the value of the ' Partial IV ' in the COSE object of the corresponding registration ( see Section 4.1.3.5.1 ) . I am unclear how / why this is different for observations . A cancelation is a message , so the IV is the request . A re - registration is a request message , any response would correspond to that request . The only interesting question has to do with updating the MID on a re - registration but not how PIVs work for this field . Section 6.1 - Is a registry needed for the leading byte of compression ? Behavior if bits 0 , 1 , or 2 is set in the flags byte on decode ? Section C - given the way that my system is implemented , it would be nice if the outputs included the first full IV to be used for both the sender and the recipient . That would allow for a test that the combination of ids and common ivs is done correctly . In my case I do not have the shared IV available for testing as I immediately or in the i d.
Paragraph (version A):
Every time a client issues a new Observe request, a new Partial IV
MUST be used (see cose-object), and so the payload and OSCORE option
are changed.  The server uses the Partial IV of the new request as
the 'request_piv' of all associated notifications (see AAD).  The
Partial IV of the registration is also used as 'request_piv' of
associated cancellations (see AAD).
Paragraph (version B):
Every time a client issues a new Observe request, a new Partial IV
MUST be used (see cose-object), and so the payload and OSCORE option
are changed.  The server uses the Partial IV of the new request as
the 'request_piv' of all associated notifications (see AAD).
Paragraph (version A):
request_piv: contains the value of the 'Partial IV' in the COSE
object of the request (see cose-object), with one exception: in
case of protection or verification of Observe cancellations, the
request_piv contains the value of the 'Partial IV' in the COSE
object of the corresponding registration (see observe-
registration).
Paragraph (version B):
request_piv: contains the value of the 'Partial IV' in the COSE
object of the request (see cose-object).