updating top level README

README.md

@@ -1,34 +1,25 @@
+**N.B. The project is a work in progress and is not ready for production.**
+
 # Notary
 
 ## Overview
 
-Notary Server manages trust metadata as a complementary service to the registry.
-It implements all endpoints under the `_trust` segment of the registry URLs.
-Notary Server expects to manage TUF metadata and will do validation of one parent
-level of content for any data uploaded to ensure repositories do not become
-corrupted. This means either the keys in the root.json file will be used to
-validate the uploaded role, or the keys in the immediate delegate parent will
-be used.
+The Notary project comprises server and client tools for running and interacting
+with trusted collections. Please see the READMEs for the individual tools for
+more information on their specifics.
 
-Uploading a new root.json will be validated using the same token mechanism
-present in the registry. A user having write permissions on a repository
-will be sufficient to permit the uploading of a new root.json.
+## Goals
 
-## Timestamping
+Notary aims to make the internet more secure by making it easy for people to
+publish and verify content. We often rely on TLS to secure our communications
+with a web server which is inherently flawed, as any compromise of the server
+enables malicious content to be substituted for the legitimate content.
 
-TUF requires a timestamp file be regularly generated. To achieve any ease
-of use, it is necessary that Notary Server is responsible for generating the
-timestamp.json based on the snapshot.json created and uploaded by the
-repository owner.
+With Notary, publishers can sign their content offline using keys kept highly
+secure. Once the publisher is ready to make the content available, they can
+push their signed trusted collection to a Notary Server.
 
-It is bad policy to place any signing keys in frontline servers. While
-Notary Server is capable of supporting this behaviour we recommend using a
-separate service and server with highly restricted permissions. Rufus
-is provided as a reference implementation of a remote signer. An
-implementation that satisfies the gRPC interface defined in Rufus will
-satisfy Notary Server's requirements.
-
-# Running
-
-`# docker-compose build`
-`# docker-compose up`
+Consumers, having acquired the publisher's public key through a secure channel,
+can then communicate with any notary server or (insecure) mirror, relying
+only on the publisher's key to determine the validity and integrity of the
+received content.