Subject: Re: [Ace] Home Automation Use Case

From: Stefanie Gerdes <[email-masked]>
Date: Tue, 09 Dec 2014 11:22:57 +0100

Hi Luwig,

Am 09.12.2014 08:56 schrieb Ludwig Seitz <[email-masked]>:
>
> On 12/08/2014 06:26 PM, Stefanie Gerdes wrote: 
> > Hi all, 
> > 
> > On 12/08/2014 10:07 AM, Ludwig Seitz wrote: 
> >> On 12/06/2014 01:12 PM, Hannes Tschofenig wrote: 
> > 
> >>> 
> >>> 
> >>>      o  U2.7 The access control policies need to be easy to edit, even 
> >>>         remotely and it needs to be easy to get access with correct 
> >>>         authorization. 
> >>> 
> >>> This problems deals with the UI of the authorization policy editor and 
> >>> this is clearly outside the scope of our work. 
> > 
> > I don't think we should dismiss UI problems so easily as not in scope. 
> > An important limitation of constrained devices is that they may not have 
> > any user interfaces. An authorization solution needs to deal with that fact. 
> > 
> > Moreover, I don't think that this section is primarily about UI 
> > problems. It states two problems: Remotely editing the authorization 
> > policies and usability for authorized users. Maybe some rephrasing would 
> > help. 
> > How about: 
> > 
> > U2.7.1 The home users want to be able to configure authorization 
> > policies remotely. 
> > U2.7.2 Home Users may have litte technical skills. 
> > U2.7.3 Authorized users want to be able to obtain access with little effort. 
> > 
>
> Alternatively we could dedicate a paragraph to UI problems and usability 
> in the security considerations. I don't deny these are important 
> problems (and I don't think Hannes does either), but I'm unsure it is 
> within the scope of ACE to solve them.

The use cases document is not the charter. If we are not sure whether a certain problem is in scope it is a good idea to mention it.

That home users may have little technical skills is a major security problem in home scenarios. I can't really imagine that it would be a good idea to design a solution without being aware of this problem. I don't see a reason to omit that fact in the respective use cases.

To additionally mention usability problems in the security considerations is a good idea, though. We already have some text about that in 3.3. Do we need to extend it?

>
> >>> 
> >> 
> >> Both correct, I'll remove them. 
> >> 
> >> 
> >>>      o  U2.8 The owners of the automated home wants to prevent 
> >>>         eavesdroppers form being able to deduce behavioral profiles from 
> >>>         the home network. 
> >>> 
> >>> I believe this item calls for a communication security solution. Right? 
> >> 
> >> If I recall correctly, we introduced this as a reaction to comments, 
> >> that we also should address privacy concerns. Perhaps this would be 
> >> better addressed in the "Privacy Considerations" section. 
> > 
> > I think privacy is essential to consider, especially for home use cases. 
> > Therefore it is a good idea to mention it in the problem summary section 
> > for the home automation use case. 
> > 
> > I don't think it is a problem if the use case document states problems 
> > that may be solved by a communication security solution. But I think it 
> > is a problem if we don't see the relevant problems when we try to design 
> > an authorization solution. I guess an authorization solution would use 
> > communication security at some point, e.g. DTLS. So it would be helpful 
> > to have in mind why we need it. 
> > 
> > If we really don't want to address specific problems in ACE, we might 
> > just say so. That might be more helpful than to pretend that some 
> > problems are not there. 
> > 
>
> I don't pretend these problems do not exist, I just suggested we move 
> the description to the Privacy Considerations section, in order to avoid 
> bloating the use cases.

Stating the relevant problems for a use case is not bloating. I think it is a mistake to remove relevant problems from the use cases sections.

Steffi