On 2016-10-10 09:02, Somaraju Abhinav wrote: > Hi, I have been looking into this draft, which is very well written, > and I would like a clarification regarding the workflow in figure 1 > of the draft. > > This workflow is a bit different to the typical one I imagine for > constrained clients/servers. Such devices would typically be > provisioned from some kind of a commissioning tool and the tool would > also initiate the provisioning process. Therefore, would it not be > better to have a protocol flow that is not necessarily initiated by > the client device?
If I understand you correctly, you are suggesting to provision either the grant or the access token during the commissioning process. Our idea was to use the client credentials grant instead (not shown in our figure 1) and have the AS decide what access tokens to grant purely based on the credentials presented by the client. This way you don't have to provision anything, except for base credentials to a client. The underlying idea is that the RO would configure access control policies at the AS during the commissioning procedure. The AS uses these to determine what kind of access tokens to grant to the client, when it requests one. [AS] Okay. This makes sense. I did not understand this from the text and maybe some clarification in the text could help. For example, in figure 2, how does the client know what to write in the "aud" field. In the Figure 3, the grant_type says "token" and I am not sure how this would work. In general, this Section is a little unclear to me and maybe an example in the Appendix of how a commissioning tool would be used to provision the system might help with the readability of the document. You could of course also provision a long term access token to the client during commissioning (I think we mentioned that somewhere, or at least thought of it), so your proposed option 2 would also be valid, and I think they would work just as well with the rest of the framework. I would suggest to add a step before (A) then, were the RO requests an access token from the AS on behalf of the client. [AS] Okay. This could work but maybe the CoAP server/client interaction needs a little bit more work (e.g. how can the AS initiate an interaction with the client without needing the client to send a GET request). As for option 1, I am not sure what the advantage would be of provisioning a grant to the client as opposed to using the client credentials grant. Could you elaborate on that? [AS] Now that I understand your idea better (i.e. use of client credentials and the fact that the commissioning tool tells the AS the access rights of the client), I don't think Option 2 is required. I was thinking of a situation where the commissioning tool is not permanently available. With Option 2, the commissioning tool could be available during the initial provisioning and during this time it could provide every client with an authorization grant that includes in the "claims" the access rights of the client. This authorization grant could then be used in the token request from client to AS, which then provides the access tokens. ________________________________________________________ The contents of this e-mail and any attachments are confidential to the intended recipient. They may not be disclosed to or used by or copied in any way by anyone other than the intended recipient. If this e-mail is received in error, please immediately notify the sender and delete the e-mail and attached documents. Please note that neither the sender nor the sender's company accept any responsibility for viruses and it is your responsibility to scan or otherwise check this e-mail and any attachments.
_______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
