Here are some comments on the draft. 1. Please change the title. It would be more appropriate to say that you are "OSCOAP profile of the Authentication and Authorization for Constrained Environments Framework". ( I will also be asking for a rename of that document to add framework to highlight it is a structure not the final document).
2. Expand ACE in the abstract. Lookup on the RFC Editor page if you need to expand OAuth as well. 3. I think that you need to distinguish between a returned key used for oscoap vs oscoap+edhoc so that the server can deal with the new key in a correct manner. (This links to a request for the profile to be in the CWT for the framework.) 4. In section 2.2.1 - this is not really a POP key, it is a shared secret and not even a symmetric key. 5. In section 2.2.1 - Is there a reason not to re-use kid for sid? 6. In Section 2.2.1 - I would change the text relating to how ids are defined. What is here is not really what we are looking for in this case as smaller ids are much nicer esp if the AS can ensure uniqueness based on some knowledge. 7. In Section 2.2.1 - Need to have some text some place to declare what to do for collisions of the rid value. 8. In Section 2.2.1 - Does it make more sense to say "client" and "server" id instead. 9. In Section 2.2.2 - This is incorrectly section numbered 10. In section 2.2.2 - Again the symmetric key is not a POP key. 11. In section 2.2.2 - for asymmetric case need to the rs_cnf parameter. <<< I need to double check this >>> 12. In section 2.2.2 - In the CWT, the specific asymmetric key used by the server in the event it has multiple 13. In section 2.2.2 - Need to make a statement about the expires_in field. Is this the expires for the original secret or for the EDHOC derived key. 14. In section 2.2.2 - I am not sure that I am thrilled by the idea of running the EDHOC protocol on the authz-info resource point. 15. In section 2.2.2 - Is there a reason for not supporting multiple edhoc negotiations w/ the same secret - it seemed to be an original mode that was supported. Jim _______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
