Subject: [Ace] Role terminology in use case draft (Was: Container Use Case)

From: Göran Selander <[email-masked]>
Date: Wed, 14 Jan 2015 10:25:39 +0000

Hi Steffi,

I continue the discussion of the authorization problem formulations in
this thread:

On 2015-01-13 15:37, "Stefanie Gerdes" <[email-masked]> wrote:

>>
>> - Sections 2.x.x. entitled "Authorization Problems Summary"
>> I think most of the authorization problems make more sense with "device
>> owner" replaced with "resource owner". Referring to Steffi's mail reply
>>to
>> Hannes (Subject: [ACE] Container Use Case) I think it is confusing to
>>try
>> to address server and client problems with one problem statement about
>> "device owner". I would like to separate those so it is clear to whether
>> the problem relates to server or client. Do you agree?
>>
>
>We introduced the term "principal" in the new version of the draft to
>address this problem.

>From the new version of the draft:

"Resource Owner: The subject who owns the resource and controls its access
permissions.

Device Owner: The subject who owns a certain device and controls its
access permissions.

Principal: A subject who is either a resource owner or a device owner or
both."

- I don¹t see how the term ³principal" is separating problems relating to
client from those relating to servers. Or do I misunderstand what you mean
by ³address this problem²?

- Further, what is the relationship between device access permissions and
resource access permissions?

Is it so that access a resource on a device you need both device access
permissions and resource access permissions? Would that mean that you may
not be able to access the resource despite having been granted access by
the resource owner because of not having the device authorization? And
vice versa? 

Some specific comments:

o U1.1 Principals such as the fruit vendor, the transloading personnel or
the container owners want to grant different access rights for their
resource to different parties and want to control which devices are
allowed to present data to their devices.

- Is fruit vendor ³resource owner² or ³device owner² or both? The same
question for transloading personnel and container owner.

³control which devices are allowed to present data to their devices"

- What does this correspond to in the use case?

o U1.2 Principals want to grant different access rights for different
resources on a device.

- Same question as above about what if device owner and resource owner set
incompatible access policies?

o U1.3 The principals require the integrity of sensor data.

- I understand that, for example, a client requires integrity of sensor
data, but I don¹t understand why this would be a requirement of a ³device
owner²

o  U1.4 The principals require the confidentiality of sensor data.

- I understand that the resource owner requires confidentiality of sensor
data, but I don¹t understand why this would be a requirement of a ³device
owner²

o  U3.1 A principal, such as the owner of a health monitoring device,
wants to pre-configure access rights to specific data for persons or
groups, in the context of an emergency.

- The owner of a health monitoring device may be a patient, a caregiver
organization or outsourced to a trusted third party. Independently of who
owns the device, the resource owner should be able to set the access
rights. So I think principal should be replaced by resource owner.

o  U3.2 A principal wants to selectively allow different persons or groups
to access medical data.

- As above, principal should be replaced with resource owner.

o  U5.1 Devices are installed in hostile environments where they are
physically accessible by attackers.  Principals want to make sure that an
attacker cannot use a captured device to attack other parts of their
infrastructure.

- I see this primarily as a concern of the owner of the infrastructure,
not a concern of a resource owner. Of course, if the infrastructure is
attacked the resource owner may be inflicted, but preventing this kind of
attack is nothing an entity in the role of resource owner can ³make sure².
So I propose to replace the term principal.

o  U5.2 Principals want to restrict which entities are allowed to write
data to the devices and thus ensure the integrity of the data on their
devices.

- I agree that access control to and integrity protection of utility data
is a relevant problem statement can be deduced from this use case, but I
find this formulation somewhat confusing. In the case ³principal² means
³resource owner", the formulation ³write data to the devices² or
³integrity of the data on their devices² does not make sense; the resource
owner does not necessarily own any devices and ³data on devices" would
better be formulated in terms of "resource representations² or similar.

o  U5.7 Messages between a client and the device may need to be stored and
forwarded over multiple nodes.		
	
- I think ³device² should be replaced by ³resource server². The difference
between "device" and ³node² is not clear.

Analogous comments apply to other problem statements, let me get back with
more details later.

Regards,
Göran

---

From: Stefanie Gerdes <[email-masked]>
Date: Thu, 15 Jan 2015 17:14:23 +0100

Hi Göran,

On 01/14/2015 11:25 AM, Göran Selander wrote:
> On 2015-01-13 15:37, "Stefanie Gerdes"<[email-masked]>  wrote:
>

Maybe I misunderstood your problem. In the use cases draft we discuss 
authorization problems for a setting where one or more constrained 
devices communicate with each other. CoAP is the assumed to be the 
protocol to be used. RFC7252 [1] introduces the terms "server" and 
"client" for these devices, where the server is the "destination 
endpoint of a message" and the client is the "originating endpoint of a 
request".

Authorization solutions propose other "roles" (I prefer to call them 
"actors" since the term "role" is a bit ambiguous in authorization 
because of RBAC) and functions. The use cases described in the draft 
should be independent of specific solutions and just describe problems 
in this area. That allows us to look at them with an open mind. 
Therefore it is difficult to apply the terminology of a specific 
solution to the use cases.

Moreover, the use cases currently don't indicate that there are strong 
reasons to apply even the terms that are defined in CoAP to the 
participating entities. I understand that it would be useful for the 
development of an authorization solution if we could define that but I 
don't think it is a good idea to pick one arbitrarily. If there really 
are reasons for that, we should point them out.

Another aspect of the terminology discussion is the distinction between 
the different types of "owners". During the ACE session in Honolulu, 
there was a discussion about the usage of the term Resource Owner in the 
actors draft [2]. What I took away from that discussion is that resource 
owners and device owners might differ and have different security 
objectives. Moreover, it might not even be correct to talk about owners 
at all. I don't see that there are good reasons to distinguish in the 
use cases if an issue is a resource owner or device owner problem. If 
there are good reasons to use one or the other in a use case, we should 
point this out in the document.

The term "principal" was introduced in the document as a more general 
term for cases where it is not possible to determine whether someone is 
a device or a resource owner.

> the resource owner because of not having the device authorization? And

I don't know if there are good reasons to have device access permissions 
and resource access permissions for the same device. If there are use 
cases where this is necessary, it would be useful to point them out.

You seem to assume that owners always want to authorize access to a 
resource, but that is not necessarily true. There are two parties 
communicating with each other, the client and the server. Client owners 
might want to define authorization policies for their devices, e.g. 
define when authorizations for presenting resource representations to 
the client are to be granted (see section 2 and 6.2 of [2]). Resource 
owners might want to define authorization policies for the resources on 
the server.

HTH
Steffi

[1] http://tools.ietf.org/rfc/rfc7252
[2] http://tools.ietf.org/pdf/draft-gerdes-ace-actors.pdf

---

From: Göran Selander <[email-masked]>
Date: Mon, 19 Jan 2015 08:56:59 +0000

Hi Steffi

On 2015-01-15 17:14, "Stefanie Gerdes" <[email-masked]> wrote:

>> - I don¹t see how the term "principal" is separating problems relating
>>to
>> by "address this problem"?
>

[GS] I’m not sure I understand “terminology of a specific solution”. I
think we all agree that we are assuming something like REST, that there
are resources, requests and responses. Then there needs to be some entity
that requests and some the responds etc. And then we can formulate the
authorization problems in terms of these names. Why is there are problem
separating authorization problems on the requesting side from those on the
responding side?

>are reasons for that, we should point them out.

[GS] I’m sorry but I don’t really understand this either. What is the
problem with “pick one [terminology] arbitrarily”? I believe it should be
possible to translate terminology, like has been done between UMA and
OAuth. For the use case terminology we need one so just pick one.

>objectives. 

[GS] I can’t find that in the audio recordings of the session, could you
please repeat the argument? I did find several comments about a Resource
Server having multiple Resources which may have different Resource Owners,
was this what you were referring to? I think that comment warrants the
formulation of authorization problems in terms of the Resource Owners and
Resources, not that we need to introduce another role.

>Moreover, it might not even be correct to talk about owners

[GS] As mentioned above, I miss the rationale for speaking about device
owners at all. The use of the term principal, which has multiple meanings,
is confusing the formulation of the authorization problems as I show in
the specific comments I gave on the authorization problems.

>owners might want to define authorization policies for the resources on

[GS] OK, let’s see if I understand. So “Device" may mean "Client” or
“Resource Server”. Hence “Device Owner” may mean “Client Owner” or
“Resource Server Owner”. Principal thus may mean "Client Owner” or
“Resource Owner” or “Resource Server Owner”. Is that correct?

Now, most Authorization Problems in the use case draft are formulated in
terms of “Principal”. The terms "Client Owner” and "Resource Server Owner”
are even missing from the terminology. Since most Authorization Problems
are formulated in terms of “Principal" it blurs any distinction between
“Client Owner”, “Resource Server Owner” and “Resource Owner” and you can’t
even express any specific aspects of these because of missing terminology.
So the choice of terminology is actually hiding any potential differences
between the client and resource side.

In other words, you are essentially only considering authorization
problems which are abstract enough to be symmetric in terms of client side
and resource side and don’t want to introduce terminology that allows a
distiction. 

I think the approach that you propose in your DCAF solution draft and your
Actors terminology draft is interesting. And we agreed that the
terminology in the use case draft should not promote a specific solution.
I believe you act in good faith and with all respect, I think the current
terminology and authorization problem formulation which treat the resource
side and client side in a “symmetric” way is a bit forced and not deduced
from the use cases. If not for any other reason, then simply because the
basic resource access problem is a priori not symmetric: I agree that
there may be authorization aspects also on the client side. I agree that
there are resource representations sent in both directions between client
and resource server. But I disagree with the formulation that the
authorization problems are a priori symmetric in client and resource. One
obvious reason for asymmetry is that the client requests a resource and
not vice versa. 

We have two options: 1) Either the authorization problems are different
depending on which you term “client” and which you term “resource" or 2)
there is no difference. In case 1) we should use more specific terminology
to understand the difference between the client side and the resource
side. In case 2), if there is no difference, then it doesn’t matter what
we term as “client” and “resource” in the authorization problems, does it?
So then we can assign the roles arbitrarily and formulate the
authorization problems without loss of generality. So I don’t see a
problem being more specific.

In summary, I strongly propose that instead of hiding the differences
between resource and client, make it explicit what are the problems on the
client and resource side in each use case. Then everyone can form its own
opinion about the degree of symmetry, rather than assuming beforehand that
it is symmetric. A second proposal is to use established terminology such
as OAUth or UMA. But the choice of terminology is less important since we
should be able to map between them.

Did you also intend to answer the specific comments I gave on the
authorization problems?

Regards,
Göran

---

From: Stefanie Gerdes <[email-masked]>
Date: Wed, 21 Jan 2015 12:39:49 +0100

Hi Göran,

> separating authorization problems on the requesting side from those on the

Because we don't know in the use cases which side is the requesting side
(the CoAP client) and which one is the responding (the CoAP server). If
there are good reasons to say which one is which, we should point this
out in the use cases and use the respective terminology.

I think that in the most cases this will not be possible as there might
be reasons for each setting. Moreover, a single device will at one time
act as the server while later on it will act as the client.

If you have ideas how to solve this, please provide text.

> between the client and resource side.

We can add the terms "Client Owner" and "Resource Server Owner" to the
terminology if that helps things.

Thanks,
Steffi

---

From: Stefanie Gerdes <[email-masked]>
Date: Wed, 21 Jan 2015 12:40:25 +0100

Hi Göran,

I agree that we should look over the correct usage of the terminology
for the next version. But as I stated before, I find it difficult to
define if a device is a client or a server. Maybe an example helps:

In the medical use case patients should be able to control the access
rights to their data which indicates that the patient should be the
resource owner. If this data is transmitted to the device of their
practitioner, there are two possible solutions: either the patient's
medical device is the server and the practitioner's device is the client
or the vice versa. For either case, both the practitioner and the
patient will want to make sure that the transmitted information is
transmitted securely. If the practitioner's device is the server, the
patient's device will write data to the practitioner's resource and the
practitioner will be the resource owner.

I see no reason to prohibit either version and thus I am not comfortable
with arbitrarily picking one of them.

Steffi

---

From: Göran Selander <[email-masked]>
Date: Thu, 22 Jan 2015 08:11:58 +0000

Hi Steffi,

On 2015-01-21 12:40, "Stefanie Gerdes" <[email-masked]> wrote:

>resource owner.

In 
http://kantarainitiative.org/confluence/display/uma/UMA+Trust+Model+User+gu
ide
there is a healthcare scenario where the patient is resource owner
(=authorizing party) and sets access policies.

>If this data is transmitted to the device of their
>transmitted securely.

I don’t understand what this has to do with the role allocation.

>If the practitioner's device is the server, the

I don’t understand why device ownership implies resource ownership. I
think resource ownership is a matter of legislation and agreements. If a
patient  signs up with a caregiver or some other healthcare system, it may
or may not retain its ability to set access policies (i.e. be resource
owner). 

In Sweden, the caregiver will set access policies and as a patient you are
not always and all the time entitled to your records (or resetting the
policies). This may depend on the mental condition of the patient. It may
also depend on the type of medical data, e.g. if a recent examination
indicate that you may have a lethal disease, you may not be able to look
that up before you have talked to your doctor.

But irrespective of who is resource owner, caregiver or patient, the
question of device ownership is separate.

>with arbitrarily picking one of them.

Again, look at the example from UMA. Why can’t we use that terminology?
Alternative terminology is in section 2.1.1 of
https://docs.kantarainitiative.org/uma/draft-uma-trust.html

Regards,
Göran

---

From: Göran Selander <[email-masked]>
Date: Thu, 22 Jan 2015 12:16:15 +0000

Hi Steffi,

>If you have ideas how to solve this, please provide text.

As mentioned, I propose we use an existing terminology such as OAuth or
section 2.1.1 of
https://docs.kantarainitiative.org/uma/draft-uma-trust.html and replace
the terms "principal” and “device” with terms like “resource owner” or
"resource server" or whatever is appropriate. For examples of how the text
would change, please see my detailed comments on the authorization
problems at the end of the previous mail.

I can do this exercise, but please first reply to my comments so I know
that we agree on this.

>terminology if that helps things.

I think what would help is if we first express what are the authorization
problems in terms of e.g. “Client Owner” (in a given model) instead of
expressing them in terms of  “device owner” (which gives the impression
that the authorization problems are identical on the client and resource
side).

Thanks
Göran

---

From: Olaf Bergmann <[email-masked]>
Date: Thu, 22 Jan 2015 13:28:24 +0100

> that the authorization problems are identical on the client and resource

There is an excellent I-D with well-defined terminology for this, see [0].

[0] https://tools.ietf.org/html/draft-gerdes-ace-actors

Best regards
Olaf

---

From: Stefanie Gerdes <[email-masked]>
Date: Fri, 23 Jan 2015 12:10:36 +0100

Hi Göran,

Thank you for your comments.

> question of device ownership is separate.

Yes, I agree that we should not use the term "device owner" if we are
not sure that the device owner is in control of the access permissions.
We should change this with the next version.

Nevertheless, you seem to assume that it is clear who the resource owner
(the one that controls the access policies for a resource) is in a
scenario. But it depends on the concrete solution which one of the
parties is the resource owner in a given scenario. Moreover, in a
scenario where two different parties may be involved, one that requests
a representation of the resource and one that provides the resource
representation, these two parties may have different interests and thus
have different problems that need to be solved by an authorization
solution. Thus, the resource owner's problems are not the only problems
we need to consider.

For CoAP, the entity that controls the access permissions to a CoAP
resource will likely be the resource owner, and thus the owner of the
data that is stored there. If you are transmitting data to that
resource, you are the resource owner as long as you control the access
permissions for this resource. If you are transmitting data to someone
else's CoAP resource you are giving up ownership for this copy of the data.

If you want to make sure that the owner of the data never changes you
will have to make sure that the resource owner can control the access
permissions for this data on all devices where the data is transmitted
to. Even if data is transmitted to a requesting client you are giving up
ownership for the copy of the data that you are transmitting, unless you
can control access policies for the data on the client. You may control
your own copy of the data, but not the client's copy.

I don't think it's so clear that the patient is always the resource
owner in a healthcare scenario. Let's assume that in the personal health
monitoring case, a practitioner receives data from John's heart rate
monitor with her smartphone. John is the owner of the heart rate
information while it is on the heart rate monitor. He wants to control
who is able to access this data. But I think it is unlikely that the
practitioner will let John configure access policies for data on her
device. She gains ownership for her copy of John's data since she is the
one that controls the access policies.

You may say that you only want to solve John's problem, i.e. protecting
his medical data. But then you are not considering the practitioner's
interest. She will want to be sure that only authorized data is
transmitted to her smartphone.

If you want to use CoAP for the transmission of the data, it is not even
clear which device will be the client and which will be the server. It
might be useful if the heart rate monitor is the server and the
smartphone is the client that requests data. But it might also be useful
if the heart rate monitor is the client. I don't see a good reason to
rule out one of these settings.

I guess it is not possible to reduce all authorization problems in the
use cases to the protection of resources (unless we say that we have
resources on both sides which will result in having two resource
owners). Thus it is not sufficient to only list the resource owner's
problems. The use cases must also reflect the problems of the other
involved party, regardless of how you name this one (I think your
suggestion was client owner).

Since we don't know yet which solution we will use, it might be more
useful to only use CoAP terminology:

* Endpoint: An entity participating in the CoAP protocol. Colloquially,
an endpoint lives on a "Node", although "Host" would be more consistent
with Internet standards usage, and is further identified by
transport-layer multiplexing information that can include a UDP port
number and a security association

* Client: The originating endpoint of a request; the destination
endpoint of a response.

* Server: The destination endpoint of a request; the originating
endpoint of a response

And in addition (to be able to address the owner's interest):

* Resource Principal: The subject that controls the access permissions
for a resource.
(several people remarked that the term "owner" is misleading)

* Client Principal: The subject that controls the access permissions for
a client.

* Principal: A subject that is either a resource owner or a client owner
or both.

It might also be helpful to add this to the terminology:

* Resource: An item of interest

Best regards,
Steffi

---

From: Göran Selander <[email-masked]>
Date: Mon, 26 Jan 2015 08:27:54 +0000

Hi Steffi,

Thank you for your patient explanations. I am happy that we agree to leave
out device ownership.

Regarding the remaining argumentation I’m sad to say that I’m still not
convinced. In short: I think we should have a terminology in the use case
document which allow us to express the concrete authorization problems of
the use cases in terms of this terminology. If I understand you right, you
say that we can’t express the authorization problems in terms of Resource,
Resource Owner (= Resource Principal), etc. because who is Resource Owner
may depend on solution. If that is the case, then I think we have a
problem. In my opinion, either the terminology is not appropriate, or
there is some problem with the application of the terminology to the use
cases.

To eliminate the former, allow me to take a step back and attempt a
preliminary terminology to reach a common ground of understanding. Let me
know to what extent we can agree on this:

In the use cases we focus on “things" like sensors (temperature sensors,
heart rate sensors etc.) and actuators (fan actuators, lock actuators
etc.); and related data like sensor measurements (temperatures, heart
rates, etc.) and actuator settings (fan configuration settings, lock
open/closed, etc. ). All these are "items of interest", or "assets" that
needs to be protected, some of which is in scope of this working group.

In order to distinguish between the party providing a sensor/actuator
service and the party using the service we can use the terminology
“provider” (of sensor/actuator services) and “user” (of sensor/actuator
services). One important security problem in scope of this working group
deals which devices are allowed to read from a sensor or write to an
actuator. In detail this means for example that a device associated to a
user may or may not “read" measurements from a device associated to a
provider of sensor services. Analogously a device associated to a user may
or may not “write" actuator settings to a device associated with a
provider of actuator services.  There may be other security problems as
well and we should list them and decide if they are in scope.

Are we OK on this level?

Further comments below.

>We should change this with the next version.

Good.

>parties is the resource owner in a given scenario.

I think it is important that we have term to express a role providing a
sensor/actuator service, and a role using it.

>Moreover, in a

What you just stated is very close to the point I want to make. It seems
we agree that there is a difference between the party providing and the
party requesting. Therefore we need a terminology to describe how this
difference applies to the authorization problems  (in the sections
entitled “Authorization Problem Summary” in the use case document).

>else's CoAP resource you are giving up ownership for this copy of the

I agree that sensor and actuator related data needs to be secured
end-to-end between user device and provider device, and that this is part
of the authorization problem: access control to sensor data may be of
limited value if sent in plain text; access control to actuation data
needs to be integrity protected, etc. But I’m not sure I understand what
you mean with "data ownership”. Sensor data is provided in protected form
to an authorized user, what the user does with this data is beyond the
scope of this working group, isn’t it? Isn’t that more like an agreement
between the parties? I assume you are not thinking of digital rights
management.

>owner in a healthcare scenario.

Yes, as I mentioned in my previous mail “In Sweden, the caregiver will set
access policies “. Is there some confusion about the term “caregiver”? I
meant the administrative representative of the doctor etc. - roughly the
same as your term “practitioner”.

>Let's assume that in the personal health

I see two (or one-and-a-half) authorization problems here. The first
authorization problem is with John as “provider” of sensor measurments and
the practitioner as “user”.  The second problem is with the practitioner
as provider (trusted proxy), but how that data is used is not described
(this is what I meant by “and-a-half”).

If we can have a solution to how a provider can set policies for access to
data and only grant access to authorized users, then we could apply this
solution twice: first with John as provider, then with the practitioner as
provider. Of course, there must be an agreement between John and the
practitioner about the practitioner acting provider for this data, but I
don’t think that is in scope of this working group.

>transmitted to her smartphone.

What does "authorized data” mean? With the appropriate security setup, the
smartphone (user device) could authenticate the heart rate monitor
(provider device), verify the integrity of the data, verify that it is not
a replay of an old communication, verify “freshness" of the communication
etc. But I guess you mean something else?

>rule out one of these settings.

Let’s try the terminology above: the heart rate sensor is a "provider of
sensor data" and the smartphone is a "user of sensor data". Does that make
more sense?

>suggestion was client owner).

If there is a problem with the word “resource”, maybe we could think in
terms of “assets”/“items of interest” (e.g. things and related data) on
the provider side and user side and formulate the authorization problems
in terms of these?

>* Resource: An item of interest

As a summary, I think the main purpose of the terminology in the use case
document should be to be able to express the concrete authorization
problems in sufficient detail. E.g. we should be able to distinguish
between the role associated to the device reading the sensor data from the
role associated to device from which sensor data is being read. If we can
do that with this terminology, fine. If not then we should maybe select
another?

Best regards,
Göran

---

From: Stefanie Gerdes <[email-masked]>
Date: Mon, 26 Jan 2015 15:23:42 +0100

Hi Göran,

> well and we should list them and decide if they are in scope.

I don't see how this terminology will help us with the authorization
solution. In CoAP, the server is not necessarily the sensor/actuator.
The protection of sensor or actuator values does not really fit to the
protection of CoAP resources (that are identified by a URI).

Moreover, one of the endpoints may be a sensor while the other may be an
actuator and we thus would have two providers.

I agree that we want to protect items of interest. If you want to cut
down the problem to "we protect the item of interest by defining who is
allowed to read/write the item on one side" you are only addressing half
of the problem. We don't get around the problem that there may be two
parties with different interests involved by renaming them or by trying
to fit the use cases to a model, where it is clear which party requests
and which party provides an item of interest. We will only gain an
authorization solution that restricts the possibilities of CoAP.

I don't like the term "user" since it implies the presence of a human
being. I don't know if that's what you have in mind?

> sensor/actuator service, and a role using it.

Considering what I wrote above, I don't see what we gain from
introducing these roles.

> entitled “Authorization Problem Summary” in the use case document).

I don't think that these differences apply to the security objectives
that the involved parties may want to achieve. As a principal, I don't
care whether I request an item or provide an item. Regardless of the
setting I want to make sure that my security objectives are achieved.

> between the parties? I assume you are not thinking of digital rights

I don't think the term "user" is helpful here. There may be two devices
communicating without any user interaction.

I am just trying to explain that there are two parties involved in
exchanging an item of interest. Each one of these parties may have their
own security objectives. The sender will want to make sure that the
receiver is authorized to get the data, the receiver will want to make
sure that the sender is authorized to send the data.

In a concrete use case, I see no evidence who the sender and who the
receiver will be.

> same as your term “practitioner”.

It seemed to me that you wanted to suggest that we use the terminology
from UMA where in one use case the patient is the resource owner. In
this case the patient would be the one that is in control of the access
policies.

So we agree that it's not clear whether the patient or the
caregiver/practitioner is the resource owner?

> don’t think that is in scope of this working group.

Okay, so we agree that we need a solution that addresses the
authorization problems of both endpoints in a conversation?

> etc. But I guess you mean something else?

I meant that practitioner will want to be sure that the data transmitted
to the practitioner's smartphone stems from an authorized source.

> sensor data" and the smartphone is a "user of sensor data". Does that make

Hm, I don't see how this helps us. If you want to be able to distinguish
the practitioner's security objectives from John's security objectives,
we could state that explicitely in the problem summary.

> the provider side and user side and formulate the authorization problems

At some point we will have to map it to CoAP, so I don't understand how
this exercise would be useful.

> do that with this terminology, fine. If not then we should maybe select

What do we gain from being able to distinguish the role of the device
that reads the sensor data from the role of the device that hosts the
sensor data? How do the problems of the principals of these devices differ?

Best regards,
Steffi

---

From: Göran Selander <[email-masked]>
Date: Thu, 29 Jan 2015 16:42:18 +0000

Hi Steffi

In summary, I think it is an issue that the authorization problem
formulations in the use case document does not take into account the a
priori difference between providing access to sensor measurements vs
accessing a sensor measurement. Or providing access to an actuator service
vs accessing an actuator service. For example, the authorization problem
of opening a lock on a specific request is different from the problem of
making sure that it is the right lock to open. Or revealing to the lock
that you intend to open it. Or what exactly is the relevant problem on the
accessing side? This would be good to clarify in the use case document.

There may be different solutions to the problem of the providing side and
the problem on the accessing side. Or maybe the same standardized solution
can be applied in two instances? To understand that we also need to
formulate the problems.

Furthermore, I think it is an issue with a terminology which does not
allow these distinctions to be made so that the different problems can be
formulated. I think one part of the terminology problem is that the term
“resource” is overloaded. For example, resource is used (a) in the
REST/CoAP meaning what is requested on the server side and (b)  as “item
of interest”, which could be anything on both requesting and responding
side. Since the existing authorization frameworks such as OAuth and UMA
has a built in asymmetry between authorizing party and requesting party,
the burden of proof deviating from that rests with the authors of this
draft. It could be a conclusion of the use case draft that this is a
symmetric problem, and that the problems on each side is of equal
importance. It should not be an assumption.

I proposed to switch temporarily to a different terminology based on
“provider” and “user” (a variant of that used in the SENSEI project) just
to avoid the potential problem with overloading the term "resource”. More
comments inline.

>actuator and we thus would have two providers.

Yes, that is fine. They provide different services. If we have a solution
to the "provider authorizes user problem" we can apply it twice.

>being. I don't know if that's what you have in mind?

The preliminary terminology I proposed was a variant of that used in the
SENSEI project. In that project we used the terms “Resource Provider” and
“Resource User”, but I wanted to avoid the notion of Resource as explained
above. I agree the notion “User” is not perfect. I called the terminology
“preliminary” because it was intended as a means to get around what  think
is an overload of terms in your current proposal. We could of course
rename terms, but for now it is just a matter of having terms that clearly
distinguish between the different functions.

<snip>

>setting I want to make sure that my security objectives are achieved.

I see two quite different problems: I’m fine with “authorization to
provide an item”, i.e. the provider authorizes a user with an item. This
is an inter domain problem which is naturally mapped to a RESTful
request/response protocol. I have a problem with “authorization to request
an item” i.e. that the user authorizes itself to send a request for an
item. I see that as a user domain internal problem which is not
necessarily cast in a RESTful request/response message exchange. And if it
is, then we can solve authorization of RESTful request and apply it twice:
Once on the inter-domain problem and once on the user internal user domain
problem.

>In a concrete use case, I see no evidence who the sender and who the

Maybe this is a reason why the terminology is not suitable? There is a
difference between who is providing a sensor/actuator service and who is
using it. And expressing that difference allows us to elaborate on the
roles in the use cases.

>caregiver/practitioner is the resource owner?

There are differences in legislation in different countries and you may
have different agreements between patient and caregiver etc. However, with
a given legislation and agreement, it is clear who is provider.

>authorization problems of both endpoints in a conversation?

As mentioned, I see in your example a sequence of two authorization
problems.

Let me add that I find the example a bit "made up". What I’m familiar with
from Ericsson Mobile Health is the case when the caregiver provides the
health monitor sensor to the patient (in practice the patient gets a
briefcase with one or more sensors and a cellular communication module).
This is a more natural situation, because then the caregiver can assume a
large responsibility for the measurement including equipment maintenance
and instructing the patient how to make the measurement in a correct way
given the equipment used etc. This situation has more in common with the
traditional setup between patient and caregiver, although the patient is
requested to perform simple tasks replacing a nurse. Hence a similar
agreement between patient and caregiver in the country in question can be
applied, including who has the rights to set access control policies. The
example you provide where the patient owns the heart rate monitor and
transfers rights to the set access policies to the caregiver would be a
quite different agreement.

>to the practitioner's smartphone stems from an authorized source.

It is still not clear to me what is an “authorized source” means. I
imagine the process of determining what is an "authorized source” could be
quite different from authorizing the practitioner to access patient data:
The practitioner decides when to request data from the patients device, it
could be part of that process to select which device to access, thus
“authorizing the source”?

>we could state that explicitely in the problem summary.

I think that would be helpful.

>this exercise would be useful.

An attempt to work around the current issue with the terminology.

>sensor data? How do the problems of the principals of these devices

As mentioned they are a priori different roles with different
responsibilities. The most natural candidate authorization frameworks do
not assume this symmetry. The burden of proving symmetry rests with the
one that claims it. Additionally, I think that it should be demonstrated
how a potential symmetry is useful in practice and not just as a
theoretical construction.

Best regards,
Göran