Subject: [Ace] Use Case Draft

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 03 Mar 2015 10:33:18 +0100

Hi Use Case Draft Authors,

I read through the latest version of the document and I noticed a few
things.

a) In http://www.ietf.org/mail-archive/web/ace/current/msg00901.html I
suggested to add another scenario to the home automation use case. I
don't think it has been added (at least I couldn't see it). Did you miss
it or did it not find enough interest?

b) I am not convinced about the use case in Section 2.6 "Sports &
Entertainment". To me it reads more like a multi-user operating system
feature rather than something we develop. I am also not sure it "sells"
well as a use case since it is functionality users wouldn't expect to
experience today. If you give your 400 EUR watch to your friend are you
really worried about your 4 training runs that are stored on that watch?
Today, the person who has the watch can see the data on it and change
(some) settings. What you cannot do (today) is to see your "training
plan" since that wouldn't be stored on the watch anyway.

I am not sure what a useful use case for this type of sports equipment
actually is (in context of ACE).

c) The 'owner' terminology still confuses me. There is the implicit
assumption that the owner can configure policies and then there are
non-owners that cannot. I don't think that ownership has anything to do
with policy configuration.

d) Here is a question for my own personal interest. I would like to
understand the container use case better and I believe the slides
presented at various IETF meetings showed the use case a bit better (at
least the involved parties). Is there anywhere (e.g., papers) a
description about the actual 'user experience' (by user I mean the
experience the different parties have). For example, the supermarket
chain will have to receive information about the containers it can track
at some point in time. I assume they will have to have an "account" with
some company (whom?) to actually query the data while the containers are
in transit. Someone will have to configure the policies for each of the
involved parties at some authorization server. Who is that party?

Ciao
Hannes

---

From: Ludwig Seitz <[email-masked]>
Date: Tue, 03 Mar 2015 11:40:49 +0100

> it or did it not find enough interest?

We (the editors) discussed it in comparison to the current 'remote 
authorization grant' scenario. Obviously including both scenarios would 
not be useful, since they are too similar, therefore we have to weigh 
them against each other.

The main difference between the currently included scenario and your 
proposal is that the latter uses proximity based technologies to 
transfer the authorization information, while in the former the 
authorization information is transferred over the Internet.
We felt that removing the Internet aspect form this scenario would be a 
bit like removing the "Internet" from the "Internet of Things".

Personally I don't have a big issue with replacing the current scenario 
with the one you propose (there is already plenty of Internet in the 
other scenarios), but I think Steffi feels a bit stronger about this.

> actually is (in context of ACE).

Our aim with this use case was to introduce some scenario with lower 
security requirements, but were privacy issues still makes security 
"nice to have".

As we can expect this type of devices to become more ubiquitous, more 
and more privacy relevant information will be gathered, which might be 
innocuous  on its own, but allow to generate profiles of the user when 
combined.

Apparently the use case doesn't make this case convincingly, do you 
suggest we update it or would you advocate removing it?

> with policy configuration.

The terminology has been subject of some controversy between the 
authors. The main issue, as I see it, is that specific terminology might 
favor specific solutions.

As you suggested earlier, some additional reviews of the document could 
be helpful to give us new perspectives.

> involved parties at some authorization server. Who is that party?
I think this would be best answered by Steffi.

/Ludwig

-- 
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: Tue, 03 Mar 2015 13:29:09 +0100

Hi Hannes and Ludwig,

> bit like removing the "Internet" from the "Internet of Things".

I would like to add that we changed the scenario as a response to your 
suggestions and removed the part where Jane's parents download an 
application that lets them communicate with Jane's door lock. You stated 
in your e-mail that the scenario requires a messaging infrastructure to 
exist and hopefully removing that part already helps things.

If it is important to you, I guess we can use both scenarios and state 
that the remote scenario is the more sophisticated one?

>> actually is (in context of ACE).

I think it is interesting to consider. We already see a lot of "smart" 
sports equipment. The more health related or otherwise personal data is 
collected by these devices the more important it will be to protect 
them. Moreover, as Ludwig says, consolidating data of many different 
devices will reveal even more about a person.

Even if you are not that concerned that the person you give your watch 
to reads your personal data (even if it costs only 80 EUR), you might 
not want everyone else to also be able to do so. In this case implicit 
authorization (an authenticated person can see everything on the device) 
may be sufficient.

The interesting aspects about this use case are that users want to grant 
access dynamically when needed with little effort. Moreover, since the 
shoes do not have a display, configuring authorization might be a bit 
more difficult than for e.g. a smartphone. Somehow the shoes need to 
know that they are allowed to talk to the watch.

For the user experience it would be helpful to have a solution that is 
able to automatically authorize devices of a certain person. If I trust 
my best friend with my data I would appreciate it if her devices are 
authorized automatically and I don't have to authorize every single one 
of it manually.

>> with policy configuration.

Yes, owner might not be the best of terms. Maybe the term "principal" 
would be better for the person that is in charge of a device / endpoint 
/ resource. As far as I understood it the controversy Ludwig mentions is 
about whether the problems of client owners are in scope or not and not 
that the term "principal" in itself is offending.

>> involved parties at some authorization server. Who is that party?

There are several aspects to this scenario. I guess you want to know how 
the fruit vendor keeps track of the state of the goods? As far as I know 
it, the data of the banana sensors can be queried remotely while the 
bananas are on the ship. Since the sensors belong to the fruit vendor 
and the fruit vendor requests the current state of the goods, I guess it 
is safe to assume that the fruit vendor is the one that will control the 
access policies in this particular conversation.

For the communication between the banana sensors and the ventilation 
system in the containers a local connection is used (which makes sense 
since a server in the Internet might not always be reachable during the 
shipment). Container monitoring is still in an early stage and as far as 
I know, there is no solution yet for authorization. From a security 
point of view, both the container owner and the fruit vendor will have 
to make sure that their devices only send data to and receive data from 
authorized devices.

Does that answer your question? Maybe the paper that is referenced in 
the draft ("Communication techniques and challenges for wireless food 
quality monitoring") helps?

Best regards,
Steffi

---

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

Hi Ludwig,

thanks for the quick response.

> other scenarios), but I think Steffi feels a bit stronger about this.

I actually never intended to replace the existing scenario but rather to
enhance the existing scenario.

I thought that the off-line delegation could be interesting. The rest of
the scenario may still involve the Internet. Maybe it is only slightly
different than the current scenario and therefore not worth listing it
as an extra scenario.

> suggest we update it or would you advocate removing it?

Good question. I was not able to come up with a useful alternative. I
will keep thinking about it and maybe someone else in the group has a
suggestion that fits into the wearable category.

> be helpful to give us new perspectives.

Let's see what the other folks in the group think.
> I think this would be best answered by Steffi.

Thanks.

Ciao
Hannes

> 
> 
> /Ludwig
> 
> 
> 
> _______________________________________________
> Ace mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ace
>

---

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

Hi Steffi,

also thanks to you for the quick response.

> that the remote scenario is the more sophisticated one?

The current version is certainly more sophisticated than the scenario I
proposed since it requires more players to interact. The different
"transport" of the authorization credentials using short range radio vs.
the Internet might not be sufficient to turn it into a new scenario. I
don't know whether the delegation aspect where one party acts as a local
authorization server adds much more value.

> authorized automatically and I don't have to authorize every single one

I get the idea. Will think about some potential alternatives that are
easier to "sell".

> that the term "principal" in itself is offending.

In GEOPRIV we called the party that configures the authorization
policies the "Rule Maker". You probably don't like that term too much
but it focuses on the aspect that is most important, namely who create
the authorization policies.

> to make sure that their devices only send data to and receive data from

From a monitoring point of view I guess the fruit vendor will configure
access to the data of the fruits as well as the containers rather than
having those monitored by different parties. While the fruit vendor may
not need to own the containers they will probably be rented.

I see the communication internally within the container as a separate
problem, more like a "how to configure a small wireless adhoc network".

I could even imagine that the (temperature/humidity) sensors are not
with the bananas themselves but rather with the container.

> quality monitoring") helps?

I should probably look at that again.

Ciao
Hannes