Subject: [Ace] [ACE] Review of draft-ietf-ace-actors-02

From: Somaraju Abhinav <[email-masked]>
Date: Tue, 17 Nov 2015 11:05:36 +0000

Hi All,
Please see below for a review of the ace actors draft.
Regards,
Abhinav

It is very difficult for me to understand what this document is trying to achieve and exactly what benefits the document provides. It feels like the document is trying to do a little bit of everything without doing a good job of anything. The confusion begins with the title and abstract. Based on the title it seems to me that the authors are trying to address some or all of the following aspects: terminology, actors, elements (not sure what "elements" means) the architecture is trying to address, a problem statement, some aspects of an architecture. I do not know understand what value such a document brings to the working group because I do not know how to judge it and more importantly, I do not know how and when I should be using it.

If the authors can give a simple answer to the question "how and when should I be using the contents of this draft", it would be very helpful.

I will try to address each of these aspects as far as I understood in the draft

Terminology

-          Resource, resource server, client is already defined in RFC7231/RFC7252, why define it again

-          Constrained device is already defined, why do we need to define constrained node?

-          Authenticated Authorization:  A synthesis of mechanisms for authentication and authorization. The statement makes no sense to me.

-          I do not understand why the paragraph regarding "client-side aspect of Authorization" included in the terminology section? If you want to redefine the term authorization and include it in the terminology section then please give a proper definition. I think a large part of the confusion regarding the need for CAS could be fixed if the authors provide a simple definition for what is meant by "client-side aspect of Authorization" in the terminology section.

-          Undefinded terms: controlling principal on P.5 (what is the difference to principle)

Elements of an architecture

-          The abstract says "the elements that an architecture needs to address" but Section 2.1 is titled "elements of an architecture". I do not know what each statement means and what is the relation between the two.

-          How should I judge only parts of an architecture if the whole thing is not present?

-          I do not understand  "Objectives of type 2: C is exchanging information with (sending a  request to, accepting a response from) a resource only where it can ascertain that RqP has authorized the exchange with R."

o   The client always initiates any interaction with a server. So the "client authorization" is implicit in the design of restful protocols. It is only server side authorization policies that need to be added additionally. I can see a reason for the client to authenticate a server but I do not understand what client side authorization is required that is over and above what already comes implicitly with RESTful protocols ala something/someone triggers a client to access resources on a particular server. Authorization policies are required on the server side because they should be ready to accept new requests. With this in mind, I do not understand what exactly the CAS is supposed to accomplish other than help with authenticating the server.

o In the introduction the authors say Authorization is about who can do what to which objects.

o

Problem Statement

-          "The problem statement for authorization in constrained environments can be summarized as follows" is not true. This document focuses on one problem in the set of all problems in the constrained networks. Missing problems for example include secure bootstrap, group communication etc. Maybe the authors what to say that they are focusing on one problem statement in the constrained environment.

-          "The interaction between potentially constrained endpoint controlled by control information provided by less-constrained nodes on behalf of the principals of the endpoints." Assumes one particular architecture. There are several options here and I do not understand how a working group draft regarding the problem statements in the constrained network can assume one architectural proposal.

-architecture:
How can I judge "elements of an architecture"? I do not see any benefit in specifying only small parts of an architecture-I need the whole thing to understand if it works or not.

I do not understand    o  Objectives of type 2: C is exchanging information with (sending a

      request to, accepting a response from) a resource only where it

      can ascertain that RqP has authorized the exchange with R.

Actors

-          This section is the only Section that I found useful in the document and introduces terms such as CAS and AS which are less constrained.

-          I do not understand the role that CAS plays as far as authorization is concerned. However, CAS could play a role with regards to helping the constrained client authenticate the remote server.

Other points:

4.  Authentication and Authorization

-          The authors mention nothing about "client side authorization in the section". The server side authorization and the link of authorization to authentication is well know. This Section would be a good place to explain the role of the CAS.

6.  Kinds of Protocols

-          What is this section trying to achieve. There is absolutely nothing mentioned in the introduction or abstract regarding this Section and I do not see any benefit of including it.

7.  Elements of a Solution & 8.  Assumptions and Requirements

-          In a document trying to identify a problem statement/actors I do not see the need to also add a section that addresses some aspects of a solution

-          "Without anticipating specific solutions" is not an accurate statement. Using a CAS already assumes a specific type of solution.

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