Here are some comments on this draft. 1. I find it difficult to call this a profile of the Oauth document in one way. This looks to me more of a "This is how you use the Oauth" document. This echoes a comment that I made on the ACE base Oauth document.
2. Introduction: I think you should give a (very) brief introduction into the pub sub system here rather than assuming that people are going to read the pub/sub draft first. 3. Overview: I have a slight problem with the title of this section. To me I would expect an "Overview" and an "Introduction" to be the same section. Think about combining the sections together or rename this section to be more specific. 4. Overview: this is a nit - I think that you want a different term than scenario here. 5. Overview: You need to expand and define RS and AS on first usage. 6. Overview: One of the things that I am not currently happy with is that you are looking at AS1 and AS2 as being independent appliers of access control logic without any communication between them. I think that AS1 needs the ability to give policy to AS2 on a topic after it has been created and before any subscribers get keys. In the case they are co-resident this is trivial, in other cases it may not be. 7. Overview: It is not clear to me that your allocation of roles to AS1 and AS2 I correct. If you have a second publisher, does it need to talk to both AS1 and AS2 or just to AS2? Is this really an AS1 controls creation of topics and AS2 controls publishing and subscribing to topics? If the publisher loses its membership in the group for any reason, should it be able to publish willy-nilly anyway? I.e. should AS2 be able to "revoke" the publishers right to publish? 8. Overview: I don't think the picture is correct at the bottom of the section. You have a Publisher-Subscriber client/client association 9. Overview: Is there any expectation that the broker should be notified on a "revocation" of a publisher's right to publish? (As opposed to the right just expiring.) There is no need to enforce subscribers right to subscribe since a key roll over means that they are getting gibberish. 10. Section 3 - I would remove 'D' from the picture as it gets a confusion between updating the tokens and publishing content. It is covered just fine by the core document. If you are using it as a 'publish' operation, then it does not belong in the first bullet point. It could also be the difference between pushing the token and getting a session. Again I don't think these need to be separate, that is clear from the core document and you are not doing anything different. 11. Section 3.1 - I don't' think that the returned info on the first request is going to be the same for publishers and subscribers. Not sure what this should really look like. 12. Section 3.1 - I am unsure what you believe is going to be accomplished by doing a RD lookup. You can get the name of the resource, but it would not necessarily return the AS1, AS2 strings. 13. Section 3.1 - On the unauthorized response, I think you want to be returning different responses to subscriber vs the broker. A subscriber does not need to know about AS1. Also I think you should be using the same tag as the base profile for at least one of them - probably the first one you would contact. 14. Section 3.1 - I am not sure that it makes any sense to set an audience. If the scope is the topic then all information exists. The audience really the subscriber. 15. Section 3.1 - You state that the algorithm must be a CE algorithm, but I think you mean a signing algorithm. 16. Section 3.1 - why not use the cnf return value for the key? Also there is no reason to make it a bstr rather than a map. 17. Section 3.1 - need to define a signers_keys element which returns all of the signing keys. Defined as an array of keys. Return other signers for multiple publishers. 18. Section 3.2 - see above about strings to be returned here. 19. Section 5 - Need to talk about how to deal with multiple publishers - are you assigning different keys or are you using different IV sections? Need to ensure that you don't have an error from using the same key/iv pair. 20. Section 5 - Are you containing a coap payload or a complete coap message in the payload. 21. Section 5. Do you want to talk about coordination of the observer number and the iv of a message? _______________________________________________ Ace mailing list [email protected] https://www.ietf.org/mailman/listinfo/ace
