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

From: Göran Selander <[email-masked]>
Date: Mon, 2 Feb 2015 07:52:09 +0000

Hi Steffi,

OK, I’ll wait with further comments until the next update then.

Best regards
Göran

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

>Hi Göran,
>
>We are currently preparing an update of the use cases draft that
>hopefully will address some of the issues we discussed earlier.
>
>On 01/29/2015 05:42 PM, Göran Selander wrote:
>> 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.
>
>If there is a problem missing from the use cases, please provide details
>about this problem so that we can add it. For your lock example, we
>might add to the home automation use case that the smartphone of Alice's
>parents needs to make sure that it is communicating with the right lock.
>Is that what you are aiming at?
>
>> 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.
>
>As far as I'm aware of, the use cases draft uses the REST definition of
>the term "resource". I didn't see evidence that it is used incorrectly.
>But if I missed something, please point me to the respective section.
>
>I think RFC7252 uses the term "resource representation" to refer to a
>copy of the data of a resource. Maybe you can use this to describe your
>problem?
>
>I'm not sure if I understand what you mean with "symmetric problem". I
>think we agree that the two parties that participate in a communication
>may have different authorization problems. E.g., patients may want to
>restrict who is able to access their medical data while practitioners
>may want to make sure that their devices only accept authorized medical
>data. In this case we have two endpoints whose principals need different
>problems to be solved.
>
>Each participating party may need to authorize the other party. Is that
>what you mean with "symmetric"?
>
>> 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.
>>
>>
>>
>> On 2015-01-26 15:23, "Stefanie Gerdes" <[email-masked]> wrote:
>>
>>> Hi Göran,
>>>
>>>
>>> On 01/26/2015 09:27 AM, Göran Selander wrote:
>>>> 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?
>>> 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.
>> Yes, that is fine. They provide different services. If we have a
>>solution
>> to the "provider authorizes user problem" we can apply it twice.
>
>I can't really imagine how this would work in praxis. But this would be
>one possible solution to address this problem, I guess. As far as I'm
>aware of, the use cases draft doesn't prevent this kind of solution.
>
>>> 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?
>> 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>
>>
>>>>> 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.
>>>> 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).
>>> 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.
>> 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.
>
>I don't quite understand what the definition of "user" is in your
>proposed terminology. Is "user" a principal, i.e. a human being in your
>scenario or is it a device/endpoint? If the user is a principal, it will
>have some kind of endpoint that communicates with another endpoint. If
>the user is an endpoint, it will have a principal. In both cases the
>principal may want to make sure that her endpoint is only communicating
>with authorized endpoints.
>
>I don't know what "user domain internal problem" refers to in this
>scenario. Regardless of how you name this problem, it is an
>authorization problem and thus is listed in the use cases draft. It is
>the purpose of the draft to list authorization problems. A solution
>might not address all of the listed problems but I don't think it is a
>good idea to leave out problems because a certain solution might not
>address them.
>
>>>>> 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.
>>>> 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.
>>> 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.
>> 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.
>
>It seems to me that you are trying to find a terminology where we only
>have one party with an authorization problem.
>
>>
>>>>> 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.
>>>> 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”.
>>> 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?
>> 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.
>>
>>>>> 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.
>>>> 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.
>>> Okay, so we agree that we need a solution that addresses the
>>> 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.
>
>I don't see how this contradicts the authorization problems listed in
>the authorization problems summary section of the personal health
>monitoring use case. It uses the term "principal" to refer to the person
>that wants to protect the medical data.
>
>Do you suggest to add the scenario you are describing to the personal
>health monitoring use case?
>
>Do you think that a problem is missing from the personal health
>monitoring use case and if so, could you describe the problem that is
>missing?
>
>>>>> 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.
>>>> 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?
>>> I meant that practitioner will want to be sure that the data
>>>transmitted
>>> 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”?
>
>User (human being) interaction is one possible solution for
>authorization for cases where we have an active user. In M2M scenarios,
>this might not always be applicable.
>
>>>>> 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.
>>>> 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?
>>> 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.
>> I think that would be helpful.
>
>I think the use cases document already states the problems of the
>different involved principals where this is possible. E.g., the home
>automation use case states problems that home owners have. If you think
>that we missed to state a problem of a particular stakeholder, please
>provide details on this problem so that we can add it or explain it more
>clearly.
>
>
>Best regards,
>Steffi

---

From: Ludwig Seitz <[email-masked]>
Date: Mon, 02 Feb 2015 10:14:02 +0100

If the terminology threatens to become an advanced persistent threat to 
consensus, we could perhaps reach a compromise by doing the following:

Instead of trying to agree on specific terminology in the use case 
draft, we use the names of the specific actors in each use case to 
describe the authentication and authorization problems (like e.g. "the 
fruit vendor", "the shipping company" etc).

Do you think that would work as a compromise? My guess is that the 
specific terminology is not that important for the use cases, it will 
get important when we talk solutions.

Regards,

Ludwig Seitz

-- 
Ludwig Seitz, PhD
SICS Swedish ICT AB
Ideon Science Park
Building Beta 2
Scheelevägen 17
SE-223 70 Lund

Phone +46(0)70-349 92 51
http://www.sics.se

---

From: Stefanie Gerdes <[email-masked]>
Date: Mon, 02 Feb 2015 13:51:38 +0100

Hi Göran,

On 01/29/2015 05:42 PM, Göran Selander wrote:
> accessing a sensor measurement. Or providing access to an actuator service
> that you intend to open it. Or what exactly is the relevant problem on the

> 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
> allow these distinctions to be made so that the different problems can be

> “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.
>
>
>
>>> Regarding the remaining argumentation I’m sad to say that I’m still not
>>> there is some problem with the application of the terminology to the use
>>> cases.
>>>
>>> In the use cases we focus on “things" like sensors (temperature sensors,
>>> 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.
>>>
>>> “provider” (of sensor/actuator services) and “user” (of sensor/actuator
>>> services). One important security problem in scope of this working group
>>> actuator. In detail this means for example that a device associated to a
>>> provider of actuator services.  There may be other security problems as
>> Moreover, one of the endpoints may be a sensor while the other may be an
> Yes, that is fine. They provide different services. If we have a solution

>> allowed to read/write the item on one side" you are only addressing half
> 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
> rename terms, but for now it is just a matter of having terms that clearly
>>>> scenario where two different parties may be involved, one that requests
>>>> representation, these two parties may have different interests and thus
>>>> solution. Thus, the resource owner's problems are not the only problems
>>>> we need to consider.
>>> 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
> request/response protocol. I have a problem with “authorization to request
> 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.

>>>> resource, you are the resource owner as long as you control the access
>>>> permissions for this resource. If you are transmitting data to someone
>>> needs to be integrity protected, etc. But I’m not sure I understand what
>>> scope of this working group, isn’t it? Isn’t that more like an agreement
>> exchanging an item of interest. Each one of these parties may have their

>>>> permissions for this data on all devices where the data is transmitted
>>>> can control access policies for the data on the client. You may control
>>> access policies “. Is there some confusion about the term “caregiver”? I
>>> meant the administrative representative of the doctor etc. - roughly the
> have different agreements between patient and caregiver etc. However, with
>>>> information while it is on the heart rate monitor. He wants to control
>>> the practitioner as “user”.  The second problem is with the practitioner
>>> as provider (trusted proxy), but how that data is used is not described
>>> 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
>>> practitioner about the practitioner acting provider for this data, but I
> Let me add that I find the example a bit "made up". What I’m familiar with
> This is a more natural situation, because then the caregiver can assume a
> agreement between patient and caregiver in the country in question can be
> applied, including who has the rights to set access control policies. The

>>>> You may say that you only want to solve John's problem, i.e. protecting
>> I meant that practitioner will want to be sure that the data transmitted
> 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

>>>> clear which device will be the client and which will be the server. It
>>> Let’s try the terminology above: the heart rate sensor is a "provider of
>> Hm, I don't see how this helps us. If you want to be able to distinguish

Best regards,
Steffi

---

From: Stefanie Gerdes <[email-masked]>
Date: Mon, 02 Feb 2015 15:53:12 +0100

Hi Ludwig,

On 02/02/2015 10:14 AM, Ludwig Seitz wrote:
> If the terminology threatens to become an advanced persistent threat 
> to consensus, we could perhaps reach a compromise by doing the following:
>

For the principals this might work in the problem summary sections. It 
might even make it easier to understand them. We would need to make sure 
that we don't lose important information.

For some use cases we need client and server (or resource server) to 
express the problem that needs to be solved, e.g. U5.7. I am not sure 
about 2.7.

We would also need a term for resources and resource representations (or 
items of interest), since this is necessary to describe the problems.

In the security considerations section we try to derive facts from the 
use cases and would therefore need to use a more general terminology for 
principals (e.g. the term principal).

Best regards,
Steffi