fixing docs
diff --git a/docs/d-ta-overview.md b/docs/d-ta-overview.md
index a80e058..8a042a6 100644
--- a/docs/d-ta-overview.md
+++ b/docs/d-ta-overview.md
@@ -3,35 +3,50 @@
title: Decentralized Trust Authority Overview
sidebar_label: D-TA Overview
---
+### VERSION: ALPHA RELEASE
+NOTES: The Alpha Release of the D-TA is not for production use.
+
+#### Release Schedule:
+
+Beta Release: 1st week October 2019
+
+RC1 Release: 1st week November 2019
+
# Introduction
The Apache Milagro (Incubating) Decentralized Trust Authority (D-TA) is a collaborative key management server. It has two primary functions.
1. **Issue** shares of identity-based Type-3 pairing secrets for initializing zero-knowledge proof multi-factor authentication (ZKP-MFA) networks of clients and authentication servers.
-2. **Safeguard** shares of generic secrets, acting independently but in conjunction with other D-TA nodes, for the benefit of other D-TA nodes.
+2. **Safeguards** shares of generic secrets, acting independently but in conjunction with other D-TA nodes, for the benefit of other D-TA nodes.
-In the use case where it issues shares, the D-TA holds nothing except for its Master Secret and acts as a distributed private key generation server. In the use case where it is safeguarding shares of secrets, it is up to the application developer to implement back-end application logic to hold those shares securely. Examples can include using Hardware Security Modules (HSMs) via an on-board PKCS#11 implementation to create a realm of key encryption keys.
+In the use case where it issues shares, the D-TA holds nothing except for its Master Secret and acts as a distributed private key generation server. In the use case where it is safeguarding shares of secrets, it is up to the application developer to implement back-end application logic to hold those shares securely. Examples include using Hardware Security Modules (HSMs) via an on-board PKCS#11 implementation to create a realm of key encryption keys, or multi-party computation through BLS signature aggregation.
-## Roles
+# Roles
-Operators of Decentralized Trust Authorities
+Operators of Decentralized Trust Authorities are segmented into three roles.
-A D-TA facilitates secure and auditable communication between someone who wants to use a key pair (the Principal) and service providers who can keep secret keys safe (Master Fiduciary). It is written in Go and uses REST services based on the GoKit microservices framework, it uses IPFS to create a shared immutable log of transactions and relies on Milagro-Crypto-C for it's crypto.
+1. **Principals** - These entities operate a Milagro D-TA node to securely communicate with other D-TA nodes (Fiduciaries), employing them to issues shares of secrets or safeguard shares of secrets.
+
+2. **Fiduciaries** - These entities operate \\( 1 + n \\) Milagro D-TAs to issue shares of secrets or safeguard shares of secrets.
+
+3. **Beneficiaries** - These entities receive shares of secrets from Fiduciaries.
+
+A D-TA facilitates secure and auditable communication between entities and service providers who can keep shares of secret keys safe (Fiduciaries). The D-TA is written in Go and uses REST services based on the GoKit microservices framework. The D-TA uses IPFS to create a shared immutable log of transactions and relies on Milagro-Crypto-C for it's crypto. Future release candidates will incorporate Tendermint for consensus protocol.
# Safeguarding Secrets
-In order to safeguard a secret using the D-TA a minimum of two roles are required: a client (refered to as the Principal) and a server (refered to as a Master Fiduciary). In addition a third party can be nominated as the ultimate recipient of the secret (refered to as the Beneficiary). You can run a single D-TA to provide all three roles if you want to see it in action. See the [quick start guide](/docs/dta-details/quickstart) for instructions on how to do that.
+In order to safeguard a secret using the D-TA a minimum of two roles are required: a client (Principal) and a server (Fiduciary). In addition a third party can be nominated as the ultimate recipient of the secret (Beneficiary). You can run a single D-TA to provide all three roles if you want to see it in action. See the [quick start guide](/docs/dta-details/quickstart) for instructions on how to do that.
-This system can be imagined like a "network HSM". Here is a VERY simplified overview of the process:
+This system can be imagined like a "network HSM". Below is a VERY simplified overview of the process:
## Milagro D-TA Security
-The **Seed** is the focus of the system - the D-TA provides a method for Principals to communicate with Master Fiduciares who can secure their secret keys, it does not prescribe how the securing should be done. The most basic implementation of a D-TA should secure seeds in an HSM using a PKCS#11 interface.
+The **Seed** is the focus of the system - the D-TA provides a method for Principals to communicate with Fiduciaries who can secure their secrets, it does not prescribe how the securing should be done. The most basic implementation of a D-TA should secure seeds in an HSM using a PKCS#11 interface.
We hope that many custodial services will adopt the Milagro D-TA as a communication protocol and that they will bring a profusion of security paradigms, by working together we can make a dynamic market place for custodial services and together make the Internet a safer place.
## The Milagro D-TA Communication Protocol
-The D-TA provides a secure, distributed method of communication between beneficiaries, principals and fiduciaries. It aims to solve the following problems:
+The D-TA provides a secure, distributed method of communication between Beneficiaries, Principals and Fiduciaries. It aims to solve the following problems:
1. How can actors in the system be identified and trusted?
diff --git a/docs/dta-details/quickstart.md b/docs/dta-details/quickstart.md
index df25f69..19842e7 100644
--- a/docs/dta-details/quickstart.md
+++ b/docs/dta-details/quickstart.md
@@ -5,7 +5,7 @@
---
## Docker
-The easiest way to see a D-TA in action is to run it in a Docker container. The default settings will run a single D-TA that acts as Principal, Master Fiduciary and Beneficiary. The default settings include an embeded IPFS node connected to a private IPFS network and an embedded "Bolt" database. This will get you up and running quickly but is **not recommended for production use!**
+The easiest way to see a D-TA in action is to run it in a Docker container. The default settings will run a single D-TA that acts as Principal, Master Fiduciary and Beneficiary. The default settings include an embedded IPFS node connected to a private IPFS network and an embedded "Bolt" database. This will get you up and running quickly but is **not recommended for production use!**
Please see the repo's [README](https://github.com/apache/incubator-milagro-dta) for alternative build instructions.
@@ -38,11 +38,11 @@
## Plugins
-The Milagro D-TA comes with two aditional plugins out-of-the box, which are intended to demonstrate how it can be extended.
+The Milagro D-TA comes with two additional plugins out-of-the box, which are intended to demonstrate how it can be extended.
**To Run Safeguard Secret**
-The Safeguard Secret plugin encrypts a string with the public key and decrypts it when the Master Fiducuiary returns the secret key.
+The Safeguard Secret plugin encrypts a string with the public key and decrypts it when the Master Fiduciary returns the secret key.
```
docker run -it -p 5556:5556 milagrodta -service safeguardsecret
@@ -50,16 +50,16 @@
**To Run Bitcoin Wallet**
-Bitcon Wallet uses the public key to create a Bitcoin address. When you want to spend your bitcoins you can get the secret key from the Master Fiduciary
+Bitcoin Wallet uses the public key to create a Bitcoin address. When you want to spend your bitcoins you can get the secret key from the Master Fiduciary
```
docker run -it -p 5556:5556 milagrodta -service bitcoinwallet
```
You can confirm that the plugins have loaded by hitting [http://localhost:5556/v1/status](http://localhost:5556/v1/status)
-## Hitting the API
+## D-TA API
-The details of the API can be [seen here...](/swagger/index.html)
+A Swagger description of the API is accessed [via this link.](/swagger/index.html)
The Milagro D-TA can easily be integrated with an existing back office system, called from a front-end application or called from CURL, Postman, Swagger etc.
