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)
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:
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)