Subject: [Ace] U1.2 in Use Case Document

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 03 Mar 2015 14:06:58 +0100

Hi all,

let me try to see whether I understand the issue that's currently under
discussion.

It seems that the debate focuses on this requirement from the 'Container
monitoring' use case:

"
   o  U1.2 Principals want to grant different access rights for
      different resources on an endpoint.
"

The question that surfaced here is whether 'principal' is the right term
or not. The document defines principal as "A subject who is either a
resource owner or a client owner or both."

Here is a slightly modified example using a door lock scenario that may
help us see through this case. Imagine a family with a kid: Alice, Bob
and their young child Eve.

Alice and Bob bought one of these Internet connected door locks and now
want to configure it. They want to configure it in such a way that all
three can enter their house just using their smart phone (and a
specially loaded app).

Whether the authorization server is included in the door lock itself or
is part of some other home appliance does not really matter for the
moment. In any case, Alice and Bob configure the door lock in such a way
that Eve is granted access. Alice and Bob are the owner of the resource
(=door lock) but even if they do not 'own' the door lock (but have
rather rented it) does not really matter.

The authorization server does not necessarily need to know that this
access control policy is about "Eve". All it cares is that there is an
entry in the access control list that points to some credential on some
device. That credential happens to point to app on the smart phone Eve
is using.

Now, the question is how Eve, who is the client owner, fits into that
picture. She would use her phone (=client) to request access to the door
but she would not be involved in provisioning the access control policy
at the authorization server.

Did I correctly understood this issue?

Ciao
Hannes

---

From: Göran Selander <[email-masked]>
Date: Tue, 3 Mar 2015 17:03:00 +0000

Hi Hannes,

>      different resources on an endpoint.

Actually, we are not debating this U1.2 requirement. Steffi made a new set
of requirements, see
http://www.ietf.org/mail-archive/web/ace/current/msg00982.html

The debate focused on this requirement proposed by Steffi:

"U1.1a Principals such as the fruit vendor, the transloading personnel or
the container owners want to define authorizations for their resources
and endpoints."

(I insert “a”, “b”, “c” etc. to distinguish the different versions of
requirements)

Then Steffi proposed to split U1.1a in these requirements:

(http://www.ietf.org/mail-archive/web/ace/current/msg00992.html)

“U1.1b: Resource Owners want to grant different access rights for their
resources to different parties.

U1.2b: Client Owners want to define for their clients if and how they are
allowed to access resources hosted on a Resource Server."

Referring to the U1.1a, I proposed to clarify what U1.1b means in terms of
the actors and resources of the use case:
(http://www.ietf.org/mail-archive/web/ace/current/msg01000.html)

“U1.1c: Resource Owners, such as fruit vendors and container owners, want
to
grant different access rights to different parties for their respective
resources, such as temperatures and fan settings."

This was not agreed, see discussion about resource and client below.

With regards to U1.2b, I requested that this abstract statement should be
exemplified with actors and client devices from this use case to allow
everyone to form an opinion if this is a relevant access control problem
in the scope of ACE or not. If that can’t be made, then I think this
requirement is less relevant for this use case and consider leave it out.

NOTE: I’m not saying U1.2b is not a possible security concern. I’m
questioning that it is an access control problem analogous to U1.1b. The
original requirement formulation U1.1 (in the draft) and U1.1a blurs the
distinction between resource and client and gives the impression that
there is an analogous client access control problem, but I don’t see any
evidence of that from the use cases. And the current terminology is making
the distinction difficult.

Now we make the same exercise in your example below.

>rather rented it) does not really matter.

I agree about “ownership”, but let’s keep the terminology in this example.

>Did I correctly understood this issue?

I think you are correct in that the discussion is how the client owner
fits into the picture.

Whether the phone is involved or not in transporting access control policy
or other authorization information to the resource server is not the issue.

One issue we have is if the door lock can be called “Resource” or if it is
completely arbitrary which is “Resource" and which is “Client”. (I’m in
favour of the former.)

One thing we do agree about is that the tenants, Alice and Bob, should be
able to set access policies for the lock. I think this is the analogue of
U1.1b/c. But since we can’t agreed whether the lock is “Resource" or can
alternatively be “Client", I can’t use the term “Resource Owner”.  Nor can
we use the term “Client Owner”. With regards to this, I have been
questioning the usefulness of the current terminology in the draft, or how
it is applied.

Maybe we can use the qualification “lock-Resource" and “lock-Client" to
distinguish from other resources and clients? And then “lock-Resource
Owner” (Alice and Bob) and “lock-Client Owner” (Eve) would also be well
defined?

The other issue relates to what is the problem for Eve. Consider the
analogue of U1.2b above in this setting:

U1.2b: "Eve wants to define for her phone if and how it is allow to
request the lock to be opened."

To me it is quite clear that this is an awkward way of forcing an access
control problem formulation into what isn’t. When Eve wants to open a
lock, she presses a button in the app, thereby authorizes the request.
There is no need to solve this with access control policies, transport
authorization information, enforcement etc.  There is a natural asymmetry
which is clearly illustrated in the use cases. We should not hide that
behind strange terminology and formulations.

With this in mind, the term “principal” which in almost every use case in
the current version of the draft gives the false impression that there is
a symmetry in "client owner" and “resource owner”. I think we should
remove the term “principal”, express in each use case what are the access
control problems in terms of the “Resource Owners” and (if any) “Client
Owners” and in each case exemplify with the actors in the use case.

Regards,
Göran

---

From: Stefanie Gerdes <[email-masked]>
Date: Tue, 03 Mar 2015 21:17:19 +0100

Hi all,

> allowed to access resources hosted on a Resource Server."

In fact I didn't want to split U1.1a. You, Göran, proposed in 
http://www.ietf.org/mail-archive/web/ace/current/msg00991.html to 
replace U1.1 with two "requirements" as you called them. I am not happy 
with this proposal but would have agreed to it if it helped things.

The meaning of the original U1.1 problem is that principals in this use 
case want to grant different authorizations to different people / 
devices / resources (meaning that devices of company A get different 
access rights then devices of company B). It seems that it is quite 
difficult to find a neutral phrasing for this problem.

The split now shows a completely different aspect of this problem: we 
can protect the client side or we can protect the server side or both. 
These really are solution specific and as we can see, this leads to 
people wanting to defend their favorite solution. Instead of: "users 
somehow want to grant different authorizations to different people" we 
are deep into a solution space discussion about whether it is more 
useful to protect the server or the client side, if the client side even 
needs protection and so on. I would like to emphasize that this is not 
what U1.1 is about. Maybe we can still find a better phrasing that does 
not indicate a specific solution.

The different proposals for the phrasing of U1.1 indicate a different 
problem: Do we want to develop a solution that exclusively protects 
resources or do we also want to consider the client side? Most of us are 
more familiar with the protection of resources because we already know 
that from web scenarios. But in these scenarios we always have a user 
that performs authorization on the client side. For constrained 
environments, it is not always that simple. We might have true machine 
to machine (M2M) communication where a device must decide for itself 
whether something is authorized by its user or not. Moreover, devices 
might not have displays and thus it might not be possible for the user 
to directly interact with the device for authorization. Solving these 
problems is not optional. And I think it is important to be aware of 
these problems. A solution can decide if and how to solve them.

> requirement is less relevant for this use case and consider leave it out.

Imagine a specific implementation of the container scenario where the 
temperature sensor is the client and the fan actuator is the server. The 
fruit vendor wants to make sure that the temperature sensor sends the 
temperature values only to authorized fan actuator resources because she 
doesn't want unauthorized people to gain knowledge about the state of 
the goods. The container owner wants to make sure that the server only 
accepts data from authorized clients. In this case, both the client 
owner and the resource owner will need to define access policies. The 
client owner (the fruit vendor) defines a rule that states that the 
client (the temperature sensor) is allowed to do a PUT on resources that 
belong to a specific container owner. The resource owner (the container 
owner) defines a rule that states that clients of a certain fruit vendor 
are allowed to do a PUT on their resources. If the temperature sensor is 
not able to decide if a resource is authorized, it cannot enforce the 
authorization decisions of its owner.

> I think you are correct in that the discussion is how the client owner

I would also think that this is the problem. Eve uses her smartphone to 
request access to the door and is granted access depending on Alice and 
Bobs authorization. Eve has no influence on their decision. In the door 
lock case this might not a big problem. Eve actively uses her smartphone 
to interact with the door lock. The phone might also display some kind 
of dialog where Eve can decide to access the door lock or not.

If Eve doesn't use her phone but a constrained device to access, e.g. 
some sort of key fob, she might want to make sure that it doesn't 
provide her credentials to everyone who is asking.

> questioning the usefulness of the current terminology in the draft, or how

In the use cases document, we are defining use cases for constrained 
environments. Where needed, we assume CoAP as the used protocol. In CoAP 
we have two endpoints, the client and the server, that are communicating 
with each other. The server hosts resources that can be accessed by the 
client. We could define that a door lock MUST be a  CoAP server and that 
the device accessing the door lock MUST be a CoAP client or vice versa. 
If there is no strong evidence to do so, I would rather not restrict 
CoAP implementations in such a way. It seems wrong to me to say that 
CoAP is flexible enough to allow for all kinds of settings but 
unfortunately our authorization solution does not consider this 
flexibility which is why CoAP is less flexible if we are using 
authorization.

> behind strange terminology and formulations.

Yes, exactly, Eve is authorizing the request. And in this specific 
scenario implicit authorization (an authenticated device is authorized) 
might be good enough. Since Eve can decide what her smartphone is 
supposed to do, there is no need for more sophisticated authorization 
policies. This is different for other use cases.

If you think about it, there is also no need for sophisticated 
authorization on the door lock side, either. It might be sufficient if a 
device that can be authenticated is authorized to open the door. In this 
case, implicit authorization is sufficient on both sides. Again this is 
different for other use cases.

Best regards,
Steffi

---

From: Eve Maler <[email-masked]>
Date: Tue, 3 Mar 2015 19:25:27 -0800

It seems to me that Eve (ahem), as the owner of the client, is just seeking access to a resource that Alice or Bob controls access to but can't be described as an owner of anything else. There are indeed, however, several "subjects" in this picture, that is, several identities worth tracking and authenticating.

There is an inherent (and valuable for ACE purposes) asymmetry in the relationship between those who are in a position to grant access and those who seek it. If the tables are turned for some other resource, with Eve in the resource owner role and Alice in the client owner role, that doesn't make it a two-way relationship -- it's still two one-way relationships.

FWIW, here is the terminology used in UMA on the technical and contractual levels for all these concepts:

Technical             Contractual

--                    Individual (human)
--                    Non-Person Entity ("legal person" like a company)
--                    Subject (can be an individual or an NPE)
                      (all of the rest are a kind of Subject...)
resource owner        Authorizing Party
authorization server  Authorization Server Operator
resource server       Resource Server Operator
client                Client Operator (e.g. Google, running Google Apps)
requesting party      Requesting Party
--                    Requesting Party Agent (e.g. an employee of a corporate RqP)

The kind of Principal meant in the use case doc, I would argue, is exclusively the resource owner kind of principal. If you want to go back and see definitions, UMA gets its definition of resource owner from OAuth, which defines it as "An entity capable of granting access to a protected resource." The client, on the other hand, is about "making protected resource requests with the resource owner's authorization and on the requesting party's behalf." This makes the asymmetry clear.

	Eve

> On 3 Mar 2015, at 5:06 AM, Hannes Tschofenig <[email-masked]> wrote:
> 
> Hi all,
> 
> _______________________________________________
> Ace mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ace

Eve Maler | cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

---

From: Göran Selander <[email-masked]>
Date: Wed, 4 Mar 2015 07:56:37 +0000

Thank you Eve!

This is exactly what I wanted to say, but appearently didn’t manage to
formulate.

I’m happy with implementing this in the use case draft and I expect that
would resolve all of my concerns.  However, I don’t see the reason to have
both "Resource Owner”/“Authorizing Party" and “Principal” if they are
synonyms, but that is just a minor detail.

Best regards,
Göran

On 2015-03-04 04:25, "Eve Maler" <[email-masked]> wrote:

>It seems to me that Eve (ahem), as the owner of the client, is just
>seeking access to a resource that Alice or Bob controls access to but
>can't be described as an owner of anything else. There are indeed,
>however, several "subjects" in this picture, that is, several identities
>worth tracking and authenticating.
>
>There is an inherent (and valuable for ACE purposes) asymmetry in the
>relationship between those who are in a position to grant access and
>those who seek it. If the tables are turned for some other resource, with
>Eve in the resource owner role and Alice in the client owner role, that
>doesn't make it a two-way relationship -- it's still two one-way
>relationships.
>
>FWIW, here is the terminology used in UMA on the technical and
>contractual levels for all these concepts:
>
>Technical             Contractual
>
>--                    Individual (human)
>The kind of Principal meant in the use case doc, I would argue, is
>exclusively the resource owner kind of principal. If you want to go back
>and see definitions, UMA gets its definition of resource owner from
>OAuth, which defines it as "An entity capable of granting access to a
>protected resource." The client, on the other hand, is about "making
>protected resource requests with the resource owner's authorization and
>on the requesting party's behalf." This makes the asymmetry clear.
>
>	Eve
>

---

From: Olaf Bergmann <[email-masked]>
Date: Wed, 04 Mar 2015 14:51:47 +0100

Eve,

> There is an inherent (and valuable for ACE purposes) asymmetry in the relationship between those who are in a position to grant access and those who seek it. If the tables are turned for some other…

There is indeed an asymmetry, but that does not mean that there is no
authorization of communication at all. As Hannes said in his followup:
When you install a smart phone app, you have -- as a client owner in
Steffi's Terminology -- to authorize certain actions in advance. You can
do this also with constrained devices, e.g. hard-coded in the firmware
configuration. But then you are tied to those authorization rules.

You need
 1. a firmware update whenever these rules change, or
 2. to update the dynamic part of the authorization policy.

The current discussion is about whether or not we agree that 1 and 2
_exist_ as problems per se (independent of whether or not these must be
addressed by the ACE protocol in the first place).

> The kind of Principal meant in the use case doc, I would argue, is exclusively the resource owner kind of principal. If you want to go back and see definitions, UMA gets its definition of resource…

Well, "on the requesting party's behalf" already says that the client
needs to be authorized to send this request. This has been questioned
several times in the past, leading even to the attempt to remove this
entirely. Good to see that OAuth and UMA also think that the Requesting
Party needs to authorize the client's actions.

Grüße
Olaf

---

From: Göran Selander <[email-masked]>
Date: Thu, 5 Mar 2015 00:42:12 +0000

Hi Steffi and all,

Trying to catch up with the mails. I just summarize some comments on this
mail for now.

Terminology and problem statement
- - -
Current terminology, or how it is applied, is unsatisfactory, as I’ve
re-iterated a couple of times. I’ve previously been working in large
projects where terminology and problem statement was unclear and it is an
absolute waste of time. I think others in this group having similar
experiences can confirm this.

We have different options to resolve this.

1. We can remove role terminology from the use case draft and express the
problems in terms of the actors in the use cases. E.g. "fruit vendors want
to grant different access rights to different parties to measurements of
goods’ temperatures". That would save the use case document, but in this
case we don’t have a general problem statement in terms of roles, and that
then becomes then our next challenge.

2. If we instead define roles (Resource Server, Client etc.) then we must
be able to express the relevant problems based on the use cases in terms
of the roles defined. Otherwise the role definitions are not good enough.
For example "Resource Owners, such as fruit vendors, wants to grant
different access rights to different parties for their resources, such as
temperatures"

If we can’t express what are the assets and the stakeholders in a well
defined way, so that we can formulate the problem statement in terms of
these, then we have a serious problem. I advocate that we adopt an
established terminology such as OAuth or UMA. Whatever client aspects we
want to formulate can surely be expressed in any of these terminology.

Some control questions on how far we have reached in this work:

- In the container use case, can we agree that the temperature sensors and
fan actuators are the main “items of interest”.

- Can we denote the temperature sensor and fan actuators “Resources”?

- Can we, as Eve proposed, agree to view the temperature sensor - fan
actuator interaction as two one-way relationships, i.e. there are
temperature-resources and temperature-clients, as well as fan-resources
and fan-clients (some of which may be co-located).

(Maybe we can then avoid formulations such as "If the temperature sensor
is not able to decide if a resource is authorized”? See further down in
this mail.)

Constrained clients
- - -
One recurring theme in this discussion has been on constrained client
devices.  There is a question about what kind of "authorization problems”
that are relevant to the client device. It is mainly related to aspects of
a client disclosing a request. There has been repeated claims about the
need for sophisticated access control policies on the client side, in the
sense that the client actions, such as making a request, need to be
subject to access control policies, just because the devices are
constrained. But nowhere in the use case document is this claim
substantiated, i.e. that a particular use case is requiring such a
feature. There are only abstract formulations about principals, and
interpreted as resource owner as well as client owners. The motivation for
that has been that if we describe the use case in too much detail it
becomes solution specific. An alternative explanation is that only few, if
any, of the use cases actually require client side access control policies.

I think we should detach any potential access control policy problems of
the client from that related to resource access, because it is different,
it is not documented to be relevant, and it is an independent problem that
makes the problem formulation complex. Furthermore, no one actually knows
about the need and nature of policies for in these situations. It is pure
speculations. I think that if anything, some sort of "decision policies”
could potentially be useful. Formulating it as access control problem
leads to very strange statements as I showed at the end of this mail:
http://www.ietf.org/mail-archive/web/ace/current/msg01019.html

More later.

Best regards,
Göran

---

From: Göran Selander <[email-masked]>
Date: Thu, 5 Mar 2015 04:56:35 +0000

Hi all,

Please disregard "It is pure speculations." from my previous post,  an unnessecary remark due to long workshift. 

Göran

> On 5 mar 2015, at 01:42, Göran Selander <[email-masked]> wrote:
> 
> Hi Steffi and all,
> 
>

---

From: Stefanie Gerdes <[email-masked]>
Date: Thu, 05 Mar 2015 09:39:46 +0100

Hi Göran,

if we use any kind of solution specific terminology in the draft, we 
must use CoAP terminology since we want to find an authorization 
solution that fits to CoAP.

Yes, I agree that terminology and problem statement need to be clear. 
But they need to fit to the problem, not to the solution.

I am pretty sure that we will find out how a solution can be mapped to 
the use cases. But if the use cases document don't reflect how things 
work in CoAP, I don't think we will be able to find a fitting solution.

Best regards,
Steffi

-- 
Stefanie Gerdes			Tel: +49 421 218 63906
TZI Universität Bremen		E-Mail: [email-masked]
Bibliothekstr. 1, MZH 5150
28359 Bremen, Germany

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 05 Mar 2015 09:47:26 +0100

Hi Steffi, Hi Göran,

we do not want to have CoAP specific terminology in the document. While
it has to be applicable to CoAP early in the charter discussion we
wanted to also not rule out other protocols and there is nothing really
in the document that depends on CoAP.

In terms of listing the requirements in reference to the use cases, such
as saying "fruit vendors want to grant different access rights to
different parties to measurements of goods’ temperatures" sounds OK to
me. The text in the use case should anyway say what rule the fruit
vendor plays.

Ciao
Hannes

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 05 Mar 2015 09:54:25 +0100

> in the document that depends on CoAP.

1) should not depend on CoAP ≠ cannot use CoAP terminology.

2) Trying to be as general as possible here would amount to severe
mission creep.  ACE was set up to support CoAP, with a view to other
protocols, not the other way around.

(If there actually is another protocol that merits ignoring CoAP
terminology, maybe now is the time to bring it to the table.)

Grüße, Carsten

---

From: Göran Selander <[email-masked]>
Date: Fri, 6 Mar 2015 06:51:05 +0000

Hi Steffi,

We need a terminology for assets and stakeholders in the use cases to
describe the relevant access control policy problems and make security
considerations.

I propose to call all sensors and actuators (or rather assets provided by
these) “Resources”. This allows a distinction between parties providing
these assets and parties accessing these assets. In this way we can
discuss the access control policies on the asset providing side without
forcing an access control policy problem onto what isn’t, on the asset
accessing side.

Is this somehow contradicting a solution based on CoAP?

If so, why isn't there an associated contradiction between OAuth and HTTP?
(Or is there?)

Best regards,
Göran

On 2015-03-05 09:39, "Stefanie Gerdes" <[email-masked]> wrote:

>>>> Referring to the U1.1a, I proposed to clarify what U1.1b means in
>>>>terms
>>>> of
>>>> One issue we have is if the door lock can be called “Resource” or if
>>>>it
>>>> is

---

From: Göran Selander <[email-masked]>
Date: Fri, 6 Mar 2015 06:52:28 +0000

Hi Hannes,

>me. The text in the use case should anyway say what rule the fruit

It is also OK for me to remove all role terminology from a use case
document. The security considerations becomes more awkward, but I suppose
you could reason by means of examples.

Best regards,
Göran

>>>>> Actually, we are not debating this U1.2 requirement. Steffi made a
>>>>>new
>>>>> set
>>>>> of requirements, see
>>>>> "U1.1a Principals such as the fruit vendor, the transloading
>>>>>personnel
>>>>> or
>>>>> With regards to U1.2b, I requested that this abstract statement
>>>>>should
>>>>> be
>>>>> One thing we do agree about is that the tenants, Alice and Bob,
>>>>>should
>>>>> be
>>>>> able to set access policies for the lock. I think this is the
>>>>>analogue
>>>>> of
>>>>> alternatively be “Client", I can’t use the term “Resource Owner”.
>>>>>Nor
>>>>> can
>>>>> questioning the usefulness of the current terminology in the draft,
>>>>>or
>>>>> how
>>>>> it is applied.
>>>>

---

From: Stefanie Gerdes <[email-masked]>
Date: Fri, 06 Mar 2015 11:21:57 +0100

Hi Göran,

> Is this somehow contradicting a solution based on CoAP?

Let's use an example. Imagine a container scenario where the temperature 
sensor is the CoAP client and the fan actuator is the CoAP server. If 
you want to represent both the sensor values and the actuator settings 
by resources, this does not fit to CoAP where only the server has 
resources. It might be confusing for people if you want to distinguish 
between authorization resources and CoAP resources.

The interesting question for the use cases document is how things work 
in CoAP (or other protocols that serve the same purpose). We can discuss 
the solution design later when we know what the problems are.

> If so, why isn't there an associated contradiction between OAuth and HTTP?

HTTP was designed for web scenarios and not for constrained 
environments. CoAP was designed to better address the special 
characteristics of constrained environments.

OAuth was also designed for web scenarios. In web scenarios we have an 
active user. We can solve authorization problems by asking the user. The 
use cases show that we don't always have an active user in constrained 
environments. We need to deal with this fact (or we don't but then we 
likely will not find the best solution).

Best regards,
Steffi

---

From: Stefanie Gerdes <[email-masked]>
Date: Fri, 06 Mar 2015 12:56:28 +0100

Hi Hannes,

> me. The text in the use case should anyway say what rule the fruit

I already suggested an update of the problem summary section a while ago 
in http://www.ietf.org/mail-archive/web/ace/current/msg00982.html that 
favors the real actors where possible:

"U1.1 Principals such as the fruit vendor, the transloading personnel or 
the container owners want to define authorizations for their resources 
and endpoints."

If the term "Principal" is offending for some reason, we can replace 
this with:

U1.1 Fruit vendors, transloading personnel and container owners want to 
define authorizations for their resources and endpoints.

"U1.2 The fruit vendor requires the integrity of the sensor data that 
pertains the state of the goods for climate control and to ensure the 
quality of the monitored recordings.

U1.3 The container owner requires the integrity of the sensor data that 
is used for climate control.

U1.4 The fruit vendor requires the confidentiality of the sensor data 
that pertains the state of the goods.

U1.5 The fruit vendor may have several types of data that may be 
controlled by the same endpoint, e.g., sensor data and the data used for 
logistics.

U1.6 The fruit vendor requires the confidentiality of the data that is 
used to locate the goods.

U1.7 The fruit vendor requires the integrity of the data that is used to 
locate the goods.

U1.8 The transloading personnel requires the integrity of the data that 
is used to locate the goods.

U1.9 The container owner and the fruit vendor may not be present at the 
time of access and cannot manually intervene in the authorization process.

U1.10 The principals want to grant temporary access permissions to a party."

We can replace this with:

U1.10 The fruit vendor, container owner and transloading company want to 
grant temporary access permissions to a party.

"U1.11 Messages between client and resource server might need to be 
forwarded over multiple hops.

U1.12 The constrained devices might not always be able to reach the 
Internet."

What do you think?

Best regards,
Steffi

---

From: Göran Selander <[email-masked]>
Date: Fri, 6 Mar 2015 12:14:54 +0000

Hi Steffi,

>between authorization resources and CoAP resources.

So there are two different access control problems, each have their
resources. A fan-resource and a temperature-client can be co-located, or a
fan-client and temperature-server depending on where the control logic is
hosted. What is the problem?

Best regards,
Göran

---

From: Stefanie Gerdes <[email-masked]>
Date: Fri, 06 Mar 2015 15:43:24 +0100

Hi Göran,

> hosted. What is the problem?

Maybe the scenario was not clear. The temperature sensor is a CoAP 
client. It makes a PUT on the fan setting resource of the fan device. 
The client does not have a CoAP resource. Only the server has.

The use cases document describes problems in constrained environments. 
After we described the problem we can consider how solutions fit to 
these problems. I don't think it will work very well the other way around.

Best regards,
Steffi

---

From: Göran Selander <[email-masked]>
Date: Fri, 6 Mar 2015 15:59:43 +0000

>The client does not have a CoAP resource. Only the server has.

Are you thinking of a fan-client (hosted in the temperature sensor) which
makes a PUT of a fan setting to a fan-resource (fan actuator)? Or,
alternatively, there could be a temperature client (in the fan) receiving
observe notifications with temperatures from the temperature-resource
(temperature sensor) in a GET response. I’m sorry but I still don’t
understand the problem in any of these. Or maybe you wanted to exclude the
second case when you say “the client does not have a CoAP resource”? If
so, why do you make that assumption?

Best regards,
Göran

---

From: "Moore, Steve" <[email-masked]>
Date: Fri, 6 Mar 2015 16:14:36 +0000

Hi everyone (new to posting to the list, but have been watching for a bit),

It seems to me that the discussion has wandered into specific implementations of solutions to the use case. It really seems that the use case is company A has sensors in boxes that are shipped via a container that company B owns. The container has an actuator owned by company B. (I know ownership is a contested thing here...) The actuator should operated based on the values the sensors have. The logic could be in the fan, or it could be in the sensors. The directionality of the requests could be either way. Those details are up to the people designing the Banana Container Monitoring protocol which would hopefully use the ACE protocol for authentication and authorization. If I were building such a system I'd probably go with the CoAP observe route having the fan have authorization to communicate with specific sensors. There would be another set of authorizations for the guy who is loading the container to modify the sensor ID list in the fan.

In my opinion the use case should be used to highlight the types of problems the spec should provide solutions to, not dictate what the specific solutions for the use case should be.

That's the long way of saying I think I agree with Göran.
-steve

________________________________________
From: Ace <[email-masked]> on behalf of Göran Selander <[email-masked]>
Sent: Friday, March 6, 2015 10:59 AM
To: Stefanie Gerdes; Hannes Tschofenig; [email-masked]
Subject: Re: [Ace] U1.2 in Use Case Document

Best regards,
Göran

---

From: Stefanie Gerdes <[email-masked]>
Date: Fri, 06 Mar 2015 17:23:42 +0100

Hi Göran,

> so, why do you make that assumption?

 From a CoAP perspective, one possibility to implement the communication 
between the temperature sensor in the banana boxes and the fan actuator 
is that the temperature sensor is the CoAP client and the fan actuator 
is the CoAP server. A CoAP client does not have a resource. Only the 
server has a resource. Your proposal seems to exclude this configuration.

Your proposal seems to require that a device MUST always implement a 
CoAP client and a CoAP server and that they change their role within the 
communication. Otherwise we cannot have resources on both sides.

Best regards,
Steffi

---

From: Stefanie Gerdes <[email-masked]>
Date: Fri, 06 Mar 2015 17:41:27 +0100

Hi Steve,

Thank you for you comment.

> It seems to me that the discussion has wandered into specific implementations of solutions to the use case. It really seems that the use case is company A has sensors in boxes that are shipped via…

Yes, it should be up the implementor which device is the client and 
which is the server. I completely agree with this.

Göran proposes that we define that fruit vendors and container owners 
are resource owners. This implies that fruit vendors and container 
owners control the server since only CoAP servers have resources.

One possible configuration is that the temperature sensor of the fruit 
vendor is the client and the fan actuator is the server. If we define 
that fruit vendors are resource owners, this configuration would not be 
possible since clients don't have resources. We would need a client 
device between the server of the fruit vendor and the server of the 
container owner.

> In my opinion the use case should be used to highlight the types of problems the spec should provide solutions to, not dictate what the specific solutions for the use case should be.

Yes, I totally agree with this.

Thanks,
Steffi

---

From: "Moore, Steve" <[email-masked]>
Date: Fri, 6 Mar 2015 17:40:59 +0000

Ah ha, I think I now understand what the core of the discussion is. (Other
comments inline)

On 3/6/15, 11:41 AM, "Stefanie Gerdes" <[email-masked]> wrote:

>> It seems to me that the discussion has wandered into specific
>>implementations of solutions to the use case. It really seems that the
>>use case is company A has sensors in boxes that are shipped via a
>>container that company B owns. The container has an actuator owned by
>>company B. (I know ownership is a contested thing here...) The actuator
>>should operated based on the values the sensors have. The logic could be
>>in the fan, or it could be in the sensors. The directionality of the
>>requests could be either way. Those details are up to the people
>>designing the Banana Container Monitoring protocol which would hopefully
>>use the ACE protocol for authentication and authorization. If I were
>>building such a system I'd probably go with the CoAP observe route
>>having the fan have authorization to communicate with specific sensors.
>>There would be another set of authorizations for the guy who is loading
>>the container to modify the sensor ID list in the fan.
>

Just because the fruit vendor is a resource owner doesn¹t preclude it from
also being a client.
Taking the HTTP definition of resource (and hence CoAP¹s definition of
resource) as a ³network data object or service that can be identified by a
URI², I can see the issue with Œresource owner¹.
Although it should be noted that neither spec defines a Œresource owner¹
in particular, and the CoAP spec does define that requests can include a
representation of a resource.

However, if we were to imagine a system built on MQTT, they don¹t define a
resource so that issue goes away. (A bunch of others probably pop up but
that is besides the point)

I can¹t really see a good way to define a resource owner in the abstract
case that a client can send the resource on to the server that doesn¹t
conflict with the HTTP/CoAP resource definition.
Data Owner? Doesn¹t seem generic enoughŠ

-steve

>
>>
>> In my opinion the use case should be used to highlight the types of
>>problems the spec should provide solutions to, not dictate what the
>>specific solutions for the use case should be.
>
>> (temperature sensor) in a GET response. I¹m sorry but I still don¹t
>> second case when you say ³the client does not have a CoAP resource²? If

---

From: Stefanie Gerdes <[email-masked]>
Date: Fri, 06 Mar 2015 18:49:43 +0100

Hi Steve,

> Data Owner? Doesn¹t seem generic enoughŠ

Right now the use cases document uses the term "principal": A subject 
who is either a resource owner or a client owner or both.

Göran's proposal is to replace the term "principal" by "resource owner". 
This is one part of the current discussion.

Best regards,
Steffi

---

From: Göran Selander <[email-masked]>
Date: Sat, 7 Mar 2015 07:19:35 +0000

Hi Steffi, hi Steve

In the last few mails have surfaced some new aspects and I think I
understand better what you are after, Steffi. Thanks Steve for stepping in
and provided a outside view.

A lot of the discussion so far has centered on whether this issue on the
client side is an access control problem or not. I maintain it isn’t, and
I believe I have support for that opinion. Just because the client is
constrained doesn’t change that, unfortunately.

Trying to be more constructive, the similarity between the client problem
and server problem is that both are about the need for dynamic
reconfiguration of information which will impact how they act and
interact. On a high level, is this the problem you want to work on in ACE?
This is not what springs to my mind when I read the charter, but then
again, we seem to interpret "authorization" quite differently. (Let’s not
make this a “Charter and Dictionary” sequel, I’m just trying to summarize
how we got into the trenches to see if we can get out.)

Now the problem with terminology. Current terminology essentially only
uses the term “principal" which essentially means “anyone”. Since the
other terms are not used, they are redundant, so we can essentially remove
the terminology section. Actually, from a pedagogical point of view, the
current terminology makes the situation worse than no terminology at all,
since it makes the reader first focus on the distinction between resource
and client, and then in the "authorization problem summary”, without any
explanation, summarizes that everything that applies to the resource also
applies to the client. This is still a problem I have with grouping server
and client concerns in one sentence, but enough said on that.

Maybe it is good idea anyway if we leave out architecture implying
terminology in the use case document for now, or just have a term for
“stakeholder”, and first have a discussion whether we should work beyond
access control in ACE?

(A feeble thought here: rather than focus of “Resource”, one could focus
on “Source” (GET Server or PUT/POST Client) as a contast to “Sink” (GET
Client or PUT/POST Server). Then at least one gets a hint to why the
problem you want to solve is somehow intertwined in client and server.)

Best regards,
Göran

---

From: Stefanie Gerdes <[email-masked]>
Date: Sun, 08 Mar 2015 15:26:24 +0100

Hi Göran,

> and provided a outside view.

So we agree that we want to leave it to the implementers to decide which 
device is the CoAP client and which is the CoAP server?

> constrained doesn’t change that, unfortunately.

If we don't want to exclude settings where the fruit vendor's sensor is 
the client we need to make sure that the client is able to enforce the 
security policies of its owner. Authorization on the server side will 
not solve this problem. Authorization on the client side does. 
Considering this, I see no reason to exclude client side authorization.

> uses the term “principal" which essentially means “anyone”.

A principal is "a subject who is either a resource owner or a client 
owner or both" and therefore refers to the subject who controls the 
authorizations for a resource and / or a client. Since the important 
aspect is who is in charge of authorizations, I would think that this is 
exactly the term that we need here. We can remove the terms client owner 
and resource owner as you proposed and change the definition of 
principal to:

Principal: The subject who controls the authorizations for a resource 
and / or a client.

 > “stakeholder”, and first have a discussion whether we should work beyond

I don't see a need right now to discuss if we want to work on other 
things then authentication and authorization in ACE.

 > problem you want to solve is somehow intertwined in client and server.)

I prefer to describe the problems using the CoAP terminology because we 
want to find an authorization solution that works with CoAP or similar 
protocols in this area. It might be difficult to figure out how to map 
something to CoAP if we use a different terminology in the use cases.

Best regards,
Steffi

---

From: Göran Selander <[email-masked]>
Date: Sun, 8 Mar 2015 20:34:50 +0000

Hi Steffi

In my previous mail I just wanted to say that I think I understand better
what you are after. The core of the discussion is still about what is the
nature of the problem on the client side and whether that is in scope of
ACE. Since we disagree about that, I don’t find it meaningful to try to
agree on details. Let’s focus on the use case terminology and get that
done.

Your latest proposal for "principal” it is quite similar to the existing.
If you are not prepared to leave out client authorization, then better
remove principal and do as you proposed in your recent update:

http://www.ietf.org/mail-archive/web/ace/current/msg01042.html

I read through the security considerations, and it is actually quite
straightforward to remove “principal” and maintain the gist of the
message. I volunteer to do that unless someone else feels challenged.

Best regards,
Göran