I want to be able to create an identity document from another Go application. Ideally I would simply import the the defaultService package and call the CreateIdentity method.

Unfortunately this is not possible because:

1. I have to create a new service which involves lots of unnecessary coding.
2. It depends on the "common" package which has a dependency on IPFS, publishing the document to IPFs should be a separate call e.g.

import (
"github.com/apache/incubator-milagro-dta/pkg/identity"
"github.com/apache/incubator-milagro-dta/pkg/ipfs"
"someStorageThing"
)

myFunc() hashddress {
identityDoc, identitySecrets  := identity.CrateIdentity("name")
hashAddress := ipfs.Put(identityDoc)
store.Put(identitySecrets)
return hashAddress
}

The end result is that I have rewrite all the business logic for creating an identity document.

If I configure a D-TA to use an external fiduciary, and request an order, e.g.:

curl -X POST "http://localhost:5556/v1/order" -H "accept: application/json" -H "Content-Type: application/json" -d "{"BeneficiaryIDDocumentCID":"QmVnGYu4t9nZGPDweSDQnLxnNead1WEnggtLZSJp2ZZ3su"}"

No response is returned. The following error is returned by the D-TA:

2019-09-05T09:49:13.005 [REQ] 1afbb04d-b2e1-4994-80ac-782332a6b02b POST /v1/order
2019-09-05T09:49:14.413 [ERR] reqID: 1afbb04d-b2e1-4994-80ac-782332a6b02b, err: Fail to retrieve Order from IPFS: DecodeIDDocument Failed to Decode: Failed to Decapsulate Encrypted Text in Envelope Decode: Recipient not found
2019-09-05T09:49:14.413 [RES] 1afbb04d-b2e1-4994-80ac-782332a6b02b POST /v1/order 500 Internal Server Error (1.407253379s)

As a user, I want to have a configuration/install method that sets up the instance of the Milagro Server for my intended use.

In TravisCI we should have a job that scans all new files to ensure there are no missing headers

Currently, the Docker files, build scripts and Milagro crypto-c dependency all refer to this repo and not the official ASF source releases.

Some investigation is likely to determine whether it is possible/appropriate to change.

The DTA should maintain a list of "trusted" account ids. This list will be used to nominate beneficiaries and other actors that may participate in order fulfilment.

We should remove the identity endpoints completely and instead have. something like.

POST /trustedAccount - creates a new entry in the list of trusted accounts
Get /trustedaccount - returns a list of trusted accounts with pagination
Get /trustedaccount{accountID} - gets the details of a trusted account

As a user, I would like to deploy the Milagro Server in a Docker container.

Can we update the readme page to help developers who use macs

As a user, I want my Milagro Server's secrets protected with an HSM.

From our point of view it will be strategic to integrate Apache Milagro DTA rest api to Identity Server, https://github.com/IdentityServer/IdentityServer4 so this will open to secure any .NET apps out there.
This is an investigation that i will pursue personally.

If I set nodeType to either "master fiduciary" or "principal", http://localhost:5556/v1/status returns a 404

Trusted Authority will be in possession of a master secret
They will be required to issue cryptographic part-secrets (shares of Milagro Tokens), and to protect their own part-secrets. They will be completely law abiding within their own individual jurisdictions. They will be expected to be open and transparent, and to have a reputation for honesty.
Distributed Trust Authorities (D-TAs) - Distributed Trust Authorities are services run by the stakeholders in a Milagro partition which issue Milagro Tokens to People, Apps or Things who petition to obtain them. Distributed Trust Authorities may run their own IdPs, or outsource entirely this function.

The initial version of the D-TA should be derived from the code used in Milagro
The D-TA should be written in Golang in order to utilize this technology's strengths
The D-TA should have the following functionalities:
Generate Server Keys
Generate Client Keys
Generate Time Permits

I propose that we create a new feature that enables a DTA to store a list of "approved counterparties".

A counterparty is any actor (represented by an account ID) who the pricipal nominates to participate in creating, storing, or revealing a secretkey. Such as the masterFiduciary, beneficiary, or any entity that is required to give approval.

The default service should simply accept a post that a new id is added to a DTA counterparty list. (Plugins may add additional approval criteria)

The list is stored locally (in bolt by default)

The default service should implement the following endpoints:

POST /counterparty
{accountID string,
timeStamp int,
reference string} <- unique string to provide user friendly lookup eg "Name"

RETURNS 200

Get /counterparty?perPage=n&page=n&sortBy=dateAsc||dateDesc
RETURNS {...IDDoc}

Get /counterparty/accountID/{accountID}||/reference/{reference}
RETURNS {...IDDoc}

In this version the DTA should simply check that the accountid exists (ie just looik it up on IPFS / Tendermint) In future we may add additional verification steps (such as verifying a signature posted with the request)

The following files have been reported as not having the Apache licence header:

./.travis.yml
./.gitignore
./Dockerfile
./Dockerfile-alpine
./build-static.sh
./build.sh
./go.mod
./go.sum
./lint.sh
./report
./test.sh
./cmd/servicetester/e2e_test.sh
./cmd/servicetester/fulltest.sh
./cmd/servicetester/id_test.sh
./libs/crypto/libpqnist/CMakeLists.txt
./libs/crypto/libpqnist/CPackConfig.cmake
./libs/crypto/libpqnist/VERSION
./libs/crypto/libpqnist/cmake_uninstall.cmake.in
./libs/crypto/libpqnist/examples/CMakeLists.txt
./libs/crypto/libpqnist/include/CMakeLists.txt
./libs/crypto/libpqnist/src/CMakeLists.txt
./libs/crypto/libpqnist/test/smoke/CMakeLists.txt
./libs/crypto/libpqnist/testVectors/aes/CBCMMT256.rsp
./libs/documents/docs.pb.go
./libs/documents/docs.proto
./libs/documents/docs.validator.pb.go
./pkg/safeguardsecret/README.md
./pkg/safeguardsecret/open-api.yaml

Please add the header where possible/appropriate. Any files that can't or should not have header files should be listed here so we can document why.

We need a separate KeyStore interface for keeping secrets to use it with CreateIdentity function that sold keep the local node secrets

A DTA should only store its own identity secrets. We should remove the public endpoint for creating Identities.

The logic for creating identities should be something like this...

1. When the daemon starts up check if the config has an identity AND the secret keys are present (If there is an identity in config but no secret keys in the local store then they will have to be restored from back up)
2. If there is no id in config (e.g. the DTA is running for the first time) then run createIdentity()

In README, a sample code for docker build is provided. However, seems it is not working.

I tried to run docker build in different environment, and got "exit status 2" at step $GOPATH/bin/milagro init.

In CI process, it is Dockerfile-alpine being used, rather than Dockerfile which is used in the sample Docker build command.

As a user, I would like to configure my Milagro Server as both a principal and beneficiary, and to use another Milagro Server as the fiduciary.