I have some comments on this draft that I have gotten from implementation attempts.
Major Issues: Section 2 talks about looking things up in the resource directory, but it does not say what one would be looking for. Is this material which should be in the generic document? Section 2 - I see a potential interop problem w/ the MAY about transferring the access token or PSK. Does a client try it and if it does not work do it the other way or is it always going to post unless it has some external indicator that it can take the "shortcut" method? Section 2.1 - I do not understand why this is not in the mail document rather than in this profile. Section 2.1 - The list of three items seems to be overly restrictive on what is allowed. I believe that you are missing the case of no token because no token is needed (which would apply to /authz-info as well). You have previously stated that going to /.well-known/core may be something that is desirable - either that or I completely miss understood what was being said above. Section 2.2 - I do not see the AS_Info map defined anyplace. Am I missing something? Section 2.1 - I am not sure - is the case of no valid access token supposed to cover cases where the token has expired? Are there other cases that one needs to think about here? Would it not be better to close the DTLS connection in the event that the last valid token expires? Section 2.1 - You do not state if an AS_Info map should be returned for all three cases of failures. I assume that it should be, but at the current level of information it might not be totally useful. Section 2.2 - You might want to differentiate on the setoff AS_info fields that would be returned in an unsecured vs secured channel. That is, if I have a DTLS connection and try to do an operation that fails - then more info could be returned as it is not generally available. Section 2.2. - I have no idea how to use this nonce value so that it ends up in the access token. Section 2.3 - I have no idea what item #3 is supposed to be saying. How can an RS determine if it is the destination under normal circumstances? Section 3 - I am not sure that the Note text really makes any sense. If the client implements Edwards rather than classic EC curves this makes no sense to offer. Section 4.1 - the psk_identity field in TLS is a binary field - why do the base64 encoding - need to justify this. Also the current text means that I suddenly have three different things that can be in this field. This is not the type of thing hat would make me happy. Where you want me to do this is not the easiest place to suddenly do the processing needed to validate a new access token. Section 4.1 - I don't understand what the text around COSE_Encrypt is supposed to be doing. It makes little sense to me but I have not tried to think about it deeply. Section 4.2 - I don't know that a reference to 5746 is going to be any good long term. Section 4.2 - need to distinguish between cases where the permissions are update vs where the key is updated. The former SHOULD NOT require a new session to be established. Section 5.1 - I am not sure what this means. I assume that this text should say that a client should only deal with an AS for which it has a security relationship. Note that it might be an idea to be able to copy the AS from the RS into the AS request in the event that they do not match so that four corner authorization can be supported. Minor Issues: * I would stop the PSK and RPK paragraphs in the introduction so that they are in the same order as in sections 3 and 4. * In the introduction - clean up the last two paragraphs. The reference # is off as is the extra line in the Note * Remove the mention of OSCOAP in section 4 - If you want to say another profile exists, do it in the introduction. Jim _______________________________________________ Ace mailing list [email protected] https://www.ietf.org/mailman/listinfo/ace
