Subject: Re: [Ace] Scope of the ACE Charter

From: Stefanie Gerdes <[email-masked]>
Date: Fri, 07 Mar 2014 11:11:06 +0000

Hi all,

maybe it helps to discuss using the different roles a device might have.
This might make the discussion a bit easier because we know at each point if we are talking about a constrained device or not.

In my understanding we have four roles: the client and resource server which are constrained and the "wise elders" which are unconstrained. A device has one or more roles.

A client might at the same time be the Authorization Manager and will then be a less-constrained device. The Resource Server might at the same time be the Authorization Server.

Roles:

> >>
> >>     +---------------+                     +---------------+ 
> >>    Authorization                  | Authorization | 
> >>     Manager  +---------------->|  Server       | 
> >>    +---------------+    (I.2)          +---------------+ 
> >>            |                                  ^ 
> >>            |                                  | 
> >>            |                                  | 
> >>            |  (I.1)                         | III 
> >>            |                                  | 
> >>            |                                  | 
> >>            |                                  | 
> >>            v                                  v 
> >>       +-----------+                     +-----+-----+ 
> >>       |           |      II             | Resource  | 
> >>       |   Client  | <..................>| Server    | 
> >>       +-----------+                     +-----------+

> >> 
> >> I: This is the interaction where keying and authorization information
I.1: between a constrained devices and its "wise elder"
I.2: between the less-constrained devices belonging to different security domains

> >> is provided to the client. 
> >> 
> >> II: This is the resource access. 
> >> 
> >> III: This is a potential exchange necessary for having the resource 
> >> server interacting with the authorization server for authenticating 
> >> the client and for authorizing the client. 
> >> 
> >> (The exact details of the interaction depend on the specific 
> >> solution, of course.) 
> >> 
> >> As you can see in the figure, there are various places where DTLS and 
> >> CoAP should or shouldn't be used. 
> >> 
> >> A few persons said that they want to use other protocols besides CoAP 
> >> and DTLS. 
> >> 
> >> Please explain me where you would like to other protocols being taken 
> >> into consideration. What protocols are you considering in which of 
> >> these interfaces? 
> >>

Best Regards,
Steffi