Transaction Author Agreement

Story
As a steward of an Indy network, I want transaction authors to agree that the information they submit to the ledger meets the requirements outlined by ledger governance for the current transaction to minimize the liability that stewards accept when storing the data on an immutable ledger.

Acceptance Criteria

• An author agreement which covers all transaction types is anchored to the domain ledger or plugin ledgers. (Might also include the hash to save on future computation.)
• The text is available to be looked up from the ledger for audit purposes.
• When the author agreement is written to the ledger, it must be signed by a configurable number of TRUSTEEs.
• New versions of the agreement can be added to the ledger, but previous versions are retained.
• The transaction format on the domain ledger has a field that contains a hash indicating the acceptance of the author agreement. This hash is signed when the transaction is signed with the private key of the DID that will make the future writes to the ledger.
• The digital signature and hash is created by the transaction author who is submitting the transaction and explicitly ties the transaction to the specific agreement that was accepted in order to submit the transaction.
• The transaction will only be accepted with the current version of the agreement.
• The transaction format should record the timestamp when the agreement was accepted by a user in a UI.
• The timestamp must be in a UTC ISO format. It should pass basic validation: that it is not more than two minutes in the future (allowing for minor clock skew), or more than two minutes before the time the current agreement was submitted to the ledger. If it has an invalid time, the transaction should be rejected with a clear error: "Transaction rejected because the timestamp for accepting the author agreement is invalid."
• The transaction format should include a field that contains the label of one of the agreement acceptance mechanisms enumerated on the list of valid values.
• The list of valid agreement acceptance mechanisms must be anchored on the config ledger. Each mechanism includes a label (max 64 characters) and a description (max 256 characters).
  Initial mechanisms will include:
  • Label: Product EULA, Description: Included in the EULA for the product being used.
  • Label: Service Agreement, Description: Included in the agreement with the service provider managing the transaction.
  • Label: Click Agreement, Description: Agreed through the UI at the time of submission.
  • Label: Session Agreement, Description: Agreed at wallet instantiation or login.
• The list of valid agreement acceptance mechanisms includes a link to an off-ledger document containing additional information about the acceptance mechanisms such as how the agreement must be displayed in order to be legally meaningful.
• Documentation exists for how to put the transaction author agreement and agreement acceptance mechanism list onto the config ledger.
• If there is no Transaction Author Agreement registered on the ledger, then transactions should be accepted with an empty hash, empty acceptance timestamp, and empty agreement mechanism. (This is the new developer testing use case.)
• If there is a Transaction Author Agreement registered on the ledger, but no list of valid agreement mechanisms, then all transactions should be rejected.

Questions
Q. Is it sufficient to accept the agreement at the time a new DID is written to the ledger rather than for each transaction?
A. No it is not sufficient. We need confidence that users remember their acceptance for each transaction they right. We also want to avoid having to create a mechanism for having users re-accept the agreement when it changes.

Q. Is the signature of acceptance of the transaction author agreement an additional signature, or is the current transaction signature sufficient? Is it a new set of keys, or is it the same set of keys necessary for submitting the transaction?
A. The transaction author agreement is signed with the same set of keys that signs the transaction for submission to the ledger. As a result, the current transaction signature is sufficient. When we separate transaction authors from endorsers (INDY-1999), we will have to ensure that the author key is still used to sign the author agreement.

Q. Do we need acceptance for the Transaction Author Agreement for every transaction type, or just transactions that allow writing arbitrary data to the ledger?
A. We need acceptance of the agreement for all transaction types, as encryption keys are considered personal data and require acceptance of the agreement.

Q. Do plugin ledgers require the same agreement as writes to the domain ledger?
A. Yes. We expect to have a single agreement for all transactions for the foreseeable future.

Architecture question:

• What transaction type is best?
• Which ledger is best to store this transaction?