updated General Description and Use Cases sections

pep-keysync/draft-hoeneisen-pep-keysync.mkd

@@ -112,26 +112,21 @@ not leaked or exposed to theft.
 * Beacon (message): A text message that is stored inside the mailbox of the
   Device Group, which contains control commands and serves as communication
   channel between the devices of the Device Group.
-
-[[Do we need these defined? KRB]]
-* User: An individual. Typically denoted by use of a User ID or username.
-
-* Identity: A User plus a unique address, which can be an email address, network
-  address, URI, etc. A User may have many Identities, one for each unique address.
 -->
 
 
 # General Description
 
-This section describes the general concepts of pEp KeySync, focusing
-on the main procedures in an optimal use case only. Use cases involving
-unexpected user behavior, error handling, race conditions and the like are
-omitted from this section in order to facilitate a better understanding of the
-general concepts of pEp KeySync. Some of these use cases will be discussed in
-further detail in {{implementation-description}}, ff..
+This section describes the general concepts of pEp KeySync. It
+focusing on the main procedures and on the scenarios where everything
+works. Unexpected user behavior, error handling, race conditions and
+the like are mostly omitted from this section in order to facilitate a
+better understanding of the general concepts of pEp KeySync. Some of
+these use cases will be discussed in further detail in
+{{implementation-description}}, ff.
 
 
-## Use Cases
+## Use Cases for pEp KeySync
 
 ### Forming Device Group
 
@@ -143,30 +138,30 @@ automatically generated by the pEp protocol. Neither device knows anything
 about the other.
 
 Alice wants full communication capability from both of her devices, but
-currently cannot do so, as the devices do not know about each other. Alice may
-use pEp Keysync to form a Device Group and add her devices to it, which will
-allow for the exchange of private key information among its members, thus
+currently cannot do so, as the devices do not know about each other. Alice will
+use pEp Keysync to form a Device Group and add her devices to it. This
+allows for the exchange of private key information among its members. Thus,
 allowing both devices to have full communication capability, and Alice to use
 her devices as she desires.
 
 
 ### Adding New Device to Existing Device Group
 
-Devices Alice_R and Alice_O are now part of a Device Group
-(cf. {{forming-device-group}}). Meanwhile, Alice buys another device, Alice_J,
+Sometime after devices Alice_R and Alice_O have formed a Device Group
+(cf. {{forming-device-group}}), Alice buys another device, Alice_J,
 which is also configured with pEp-implementing messaging
 clients and shares the same identity for her preferred communication channel
 (the aforementioned email address). Alice_J also has a key pair, which was
 automatically generated by the pEp protocol, just as the grouped devices
 Alice_R and Alice_O have. But while the grouped devices know each other
 and have exchanged private keys, Alice_J and the grouped
-devices don't know anything each other, and thus Alice does not have full
+devices don't know anything each other. Thus, Alice does not have full
 communication capability across the three devices.
 
 <!-- Editorial NOTE: Reference forming-device-group may change due to
 autonumbering, ensure it is pointing to the one in this section -->
 
-As before with devices Alice_R and Alice_O, Alice may use pEp Keysync to add
+As before with devices Alice_R and Alice_O, Alice will use pEp Keysync to add
 device Alice_J to the existing Device Group, allowing all three devices to
 exchange private key information, and Alice to have access to her messages
 from any of them.
@@ -180,13 +175,30 @@ All devices from Alice are part of a Device Group
 expire or get reset <!-- TODO: Key Reset Reference, when out --> ,
 occasionally new key pairs are generated. For Alice to be able to read
 all encrypted messages on all devices, any new private key needs to be
-shared with the other devices in the device group.
+shared with the other devices in the device group. All devices of Alice
+will keep the other devices updated  with the latest private keys.
 
 <!-- Editorial NOTE: References forming-device-group /
 adding-new-device-to-existing-device-group may change due to
 autonumbering, ensure it is pointing to the one in this section -->
 
 
+### Leave Device Group
+
+Alice decides that one of her devices (e.g. her mobile phone) should
+no longer be able to have acces to all private keys of the Device
+Group. Alice ensures that this device will leave the Device Group.
+
+
+### Remove other Device from Device Group
+
+A device from Alice got stolen or compromised. Thus, she has to ensure
+that this device no longer received updates on private keys from other
+devices in the same Device Group. This involves to revoke many of her
+private keys <!-- TODO: Key Reset Reference, when out -->.  Alice
+will initiates the actions to mitigate the damage.
+
+
 <!--
 
 ### Synchronizing Trust
@@ -194,13 +206,20 @@ autonumbering, ensure it is pointing to the one in this section -->
 [[KRB: Do we need to define Trust above, or possibly here? I think an explanation or
 reference to pEp trust ratings, etc. would be beneficial to understanding.]]
 
-While sending messages from her pEp KeySynced devices, Alice expects the same
-level of privacy she's accustomed to from using one device, i.e., she wants all
-of the trust she gave her contacts synchronized. That is, the trust
-should be reflected on any device she uses.
+[[HB: For the time being, this remains commented due to TrustSync not
+being implemented yet. This needs to be dealt with at the time we
+include TrustSync.]]
+
+
+While sending messages from her pEp KeySynced devices, Alice expects
+the same level of privacy she's accustomed to from using one device,
+i.e., she wants all of the trust she gave her contacts
+synchronized. Alice ensures that the public keys and trust state
+of her peers are be reflected on any device she uses.
 
 -->
 
+
 ## Interaction Diagrams
 
 The following interaction diagrams depict the implementations of the