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.
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 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?
Regards, Ludwig -- Ludwig Seitz, PhD SICS Swedish ICT AB Ideon Science Park, Building Beta 2 Scheelevägen 17, SE-223 70 Lund Phone +46(0)70-349 92 51 The RISE institutes SP, Swedish ICT and Innventia are merging in order to create a unified institute sector and become a stronger innovation partner for businesses and society. At the end of the year we will change our name to RISE. Read more at www.ri.se/en/about-rise
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
