(Layer 1) CANdy Acceptance Mechanism List (AML)

Acceptance Mechanism List (AML)

"Version string":"0.1",
{  
   "for_session":"The agreement was reviewed by the user and accepted at some point in the user’s session prior to submission.",
   "wallet_agreement":"The agreement was reviewed by the user and this affirmation was persisted in the user’s wallet for use during future submissions.",
   "on_file":"An authorized person accepted the agreement, and such acceptance is on file with the user’s organization."
}

General Guidance

A Transaction Author needs to review and accept the Transaction Author Agreement (TAA) before submitting write transactions to the ledger. This acceptance is indicated by including in the transaction a hash of the TAA, the date that it was accepted, and an indication of the method used to accept the agreement. The method used to accept the agreement must correspond to an entry in this Acceptance Mechanism List (AML).

The various AML choices represent different user interaction (UX) patterns. A single software package may utilize multiple acceptance mechanisms based on the UX flow followed by the user. In many cases, the user will be representing an organization who is the actual Transaction Author and may not be authorized to accept legal agreements on behalf of the organization. In these cases, an Acceptance Mechanism that is appropriate for organizational acceptance must be used and the TAA date should reflect when an authorized agent of the organization agreed to the terms (often upon completing legal review). It may be necessary for the user to enter this date through the software interface.

After the Transaction Author has accepted a version of the agreement, the Author does not need to be presented with the full text of the updated agreement. It is sufficient to notify the user of the software that the agreement was updated because the user is under the obligation to stop writing to the ledger if the Transaction Author cannot accept the updated terms. Future write transactions will include a hash of the updated agreement and the acceptance date should reflect when the notification was provided to the user.

Mechanisms Descriptions

1. For Session: The agreement was reviewed by the user and accepted at some point in the user’s session prior to submission. When starting the software session, the user is given the opportunity to review and accept the agreement as the Transaction Author. This acceptance is then stored and reused for any other writes during the current session.
2. Wallet Agreement: The agreement was reviewed by the user and this affirmation was persisted in the user’s wallet for use during future submissions. When the user attempts to write to the ledger, the client application presents the agreement for review and acceptance. The date of acceptance and TAA hash is then persisted within the wallet where it can be reused as often as necessary. When a new agreement is put on the ledger, the user is notified. The date of notification and new TAA hash is then persisted within the wallet for use during submissions.
3. On File: An authorized person accepted the agreement, and such acceptance is on file with the user’s organization. In the case that the Transaction Author is accepting the agreement outside of the software, the client software should prompt the user to enter the date when the agreement was accepted and indicate which version of the agreement is being kept on file with the user’s organization. If the agreement is updated, the user should be notified so that the organization can update the version of the agreement kept on file.