Subject: Re: [Ace] [ACE] Permanant client-server relations and draft-seitz-ace-oauth-authz-00

From: Göran Selander <[email-masked]>
Date: Wed, 18 Nov 2015 08:11:19 +0000

Hi Abhinav,

Thanks for kind feedback.

One of the challenging tasks that this draft is trying to address is the case of dynamic access control, in the sense of access rights not being static but may for some reason change over time. Examples of this include new clients not known the resource server (sensor/actuator) are being granted access, or changes of access policies by the resource owners which needs to be enforced in the resource servers. This applies all sorts of clients and resource servers, constrained or non-constrained, mobile or fixed.  Once the information about the access rights is communicated, e.g. by means of an access token to the resource server, the access control decision can be enforced there when the client makes a request. Depending on how long time the access right is valid, which may be arbitrarily long time, there may be no need to update this information and then these provisioned authorization rules will govern the rights to access to this sensor or actuator.  In this sense “permanent” client-server relations may be viewed as a special case of the dynamic access rights. For example, it is possible to use the protocol described in this draft to provision “permanent" authorization rules during a deployment phase which to be subsequently used throughout the lifetime of the devices. As another example it is also possible to use of permanent “access profiles” (combination of access rights to different resources grouped into a profile) predefined for a given device, and combine that with a dynamic allocation of client to respective access profile. The mapping of client to access profile could e.g. be securely carried in the access token. If, however, all access rights are pre-provisioned and static, then I don’t see the need for the protocol described in this draft (for the purpose of authorization; it may still be used for key establishment).

I don’t know if this answered your question. Please let me know otherwise.

Göran

From: Somaraju Abhinav <[email-masked]<mailto:[email-masked]>>
Date: Tuesday 17 November 2015 14:42
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: [Ace] [ACE] Permanant client-server relations and draft-seitz-ace-oauth-authz-00

Hi,

I have reviewed the draft and find that is very nicely written and easy to understand. It would be nice to see this document taken further and made into an RFC.

I have a question regarding the usage of OAuth in constrained networks. In web architectures, OAuth is used a lot. However, in the constrained world, I am not sure if it applies to every situation. Typically, in constrained networks we have three types of connections: constrained device<->central (management) server(s), constrained device<-> temporary devices (e.g. mobile apps) and constrained device<->constrained device. For the constrained device<-> temporary devices (e.g. mobile apps) OAuth seems to work quite nicely and probably even for constrained device<->central (management) server(s).

I would like to focus on the constrained device<->constrained device to case. In this case, we typically have permanent authorization rules that connect e.g. sensors to actuators (pushbuttons connected to lights). For such permanent authorization rules that do not change, does it still make sense to use OAuth. I would have thought that an access control list type solution that is managed by a central server is more suitable for this situation. I would like to understand from the authors exactly which type of communication is being targeted in this draft and if it is also applicable to create “permanent client-server authorization rules”.

Abhinav
________________________________________________________ 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.