Here is a new review - the sooner you ask about anything that is unclear the more likely I will remember what I was referring to.
Jim * In figure 4: The CDDL is not correct. "2*role" should be "2*role:tstr" or role should be defined as a separate item * Section 3.2 - The third to last paragraph is incorrect, the token should have the expires AT not the expires IN parameter. There is a solid assumption that in this case there is a common idea of a wall clock between all of the servers and there for stating a hard expiration time is more appropriate than an expires in moment. Additionally, tokens will generally not include the rs_cnf even if it is in the response message and will include a cnf for an asymmetric key. In short, this paragraph is just plain wrong. * In section 3.2 - Why is the AS not allowed to return the same authorization token to the same request assuming that things such as the amount of time left before it expires would seem reasonable. I am not sure why this is a requirement let along one in this draft. Additionally, it says nothing about re-use of the same secret for a symmetric algorithm which also might be something that needs to be said. * In Section 3.3 - As an input to your "make it an array" decisions, remember that the order of scope elements that the client gave to the AS are not necessarily the same order as are in the token. I think you might just need to collapse all three arrays into a single value in the map. * In section 3.3 - Move the data structure of sign_info to section 3.3.1 * In section 3.3 - Move the data structure description of pub_key_enc to section 3.3.2 * In section 3.3.3 - I think you might want to rename the 'rsnonce' to be something that is KDC specific. * In section 4.1 - I am not sure that I like the idea of reserving /ace-group against all comers, esp. as this is not the resource name that is being used by the OSCORE version of the document. You can talk to the core people, but a better way of saying that this is a specific interface is to defined that as a property ("if=....") and register that interface name. If you really do mean to reserve this name against all comers then you need to make a registration in the well-known registry as part of the IANA sections. The last paragraph may or may not reverse the section on /ace-group. * In section 4.1.2.1 - You cannot really reference cnonce to the framework document as you are going to be using a different content-format and therefore a new identifier is needed. * In section 4.1.2.1 - See issue #60 on github about when credential verification is needed. * In section 4.1.2.1 - Please insert a forward pointer on 'control_path' to a section which describes exactly what this is supposed to be doing because it is not clear from this text. I think it will need more than a single paragraph to do so. * In section 4.1.2.1 - What happens if a 'control_path' is provided but not supported - does that mean a bad request? * In section 4.1.2.1 - /assigns a name NAME to the node/ is this assigning a name to the node or to the join result? I don't know what the node would be but I may have missed a definition. * In section 4.1.2.1 - Unless you have a reason for allowing floating point for 'exp', make it integer only. * In section 4.1.2.1 - For control_path, I assume that fragment is not supported - are paramenters? The problem is that you say "URI path" which has a meaning. * In section 4.1.2.1 - Mismatch between NAME and NODENAME in the text - need to harmonize * In Section 4.1.2.1 - I believe that the minimal content for a join request is an empty map. I believe that the minimal content for a join response is an empty map. The first makes sense as authorization comes from else where and so can the public key if it is needed. I am not so sure that an empty response makes a great deal of sense for a response but it may be what you intended. * In Section 4.1.2.2 - I am not sure that it makes sense to return key material to a client for which the scope permits it to join, but which has not actually done the join process. * In section 4.1.3.1 - I would like to have the ability to do a fetch based on the roles of the client associated with the public key. That is I would like to retrieve only those public keys associated with a requestor. * In section 4.1.4.1 - Is there any information in the policies which is sensitive? Is there a reason not to return this info to everybody? * In section 4.1.5.1 - Should this be restricted to group members? * In section 4.1.6.1 - This is be restricted to just the correct client - That is subscriber #2 should not be able to access subscriber #1's resource here. * In section 4.1.6.3 - The third paragraph is redundant as this is already covered by the first paragraph * In section 4.1.6.3 - The second and fourth paragraph are not making any sense. There is no body for a DELETE handler. * In section 4.1.7.1 - If a public key is replaced, does this constitute a reason that a key roll over is going to be required? Is this something that needs to be distributed proactively if it is allowed by the server since otherwise things may be really messed up? * In section 4.3 - I don't know if this is worth while thinking about or not. There may want to be two different expiration values that are defined in the system. When you stop sending using the key material and when you stop receiving using the keying material. These values would need to be contingent on a "key revocation" event as well. The delta could be setup as a new group parameter with a default value set by the document. * In section 4.5 - Fetch should return 2.05 (content) not 2.01 (Created). Nothing was modified on the server. * In Section 5 - For bullet 1 of bullet 3 - I think that the reasoning behind not authorized needs to be expanded. For example it might say, the node is no longer authorized for that group. * In section 5 - For bullet 2 of bullet 3 - This sentence seems to be an oxymoron - how can it still be valid and expired at the same time? Note - I am not sure that introspection actually separates these two different cases, but I have not gone back to read the framework document on that point. * In section 7 - para #1 - This need to be explained a bit more. I know what this is talking about but my first thought was how can it be a replay if this is the first time I have seen it? This should probably also note the possible mitigation that it is limited by the time since the last time the key was rolled over. * Section 7.1 - In the third paragraph, there is a discussion of CoAP retransmissions, this is causing a bit of a frisson in my mind as, at least for multicast, this would not be something that happens. The retransmission would need to occur at the application level instead. * Section 8. - In term of the name, what about doing the encoding in JSON? s/minum/minimum/ _______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace