Skip to main content
Version: v2

References

Signature​

A signature in AQP is a cryptographic signature generated by public-private key pair. The protocol should be abstract, where it will support ‘Method’ in later iterations. This will allow us to use different types of implementations such as: PGP signatures, Ethereum, or Bitcoin wallet ’s signatures.

In this specification, we use the AQP reference implementation’s signing method, which is via an Ethereum wallet.

signature_hash = calculate_hash_sum(
    signature + public_key
)

The signature is generated by a wallet signing the following message:

I sign the following page verification_hash:" +[0x0x9dab72<revision_verification_hash>]

Wallet​

A wallet is a software for protecting and managing private cryptographic keys (of private-public key pairs) which are used to govern digital assets. This is done by authorization of transactions via digital signatures or by initiating decryption processes to access data.

See Separation of Concerns.

Account​

We are following Ethereum's account definition:

In general, there are two types of accounts. Externally owned accounts, controlled by private keys. And contract accounts, controlled by their contract code -- Ethereum Whitepaper

In general, we can't prove if an account owner is a person or a machine. With advancements in AI, it will become increasingly difficult to prove that a human is a human. Attempts are being made to increase trustworthiness of accounts which fall short in questions of privacy and security as they make public claims. Traditional know your customer (KYC) combined with the AQP and Aqua Identity Protocol (AIP) identification processes can provide similar "proof of being human" which can be attested to an account. This allows us to outsource the problem of identification, where we only focus on unique accounts which are sufficient for data accounting independent of humans or machines. Identity claims issued via the AIP will help to provide the context required to meaningfully interact between accounts.

For more on this topic, please read the Aqua Identity Protocol.

Domain​

A domain is a unique namespace attributed to an account. It allows us to manage services and files within that namespace creating a domain of data governance After granted permissions, additional accounts can be added to share control over a domain or singular assets. To enforce boundaries of a domain, additional software like the Guardian is required.

E.g. by setting up the a data vault with your account it becomes your domain of data governance.

Transaction Security​

Transaction security is an economic measure of the level of integrity assurance for a transaction. It is defined as the cost required to forge a transaction. The transaction security can be increased by cryptographic security and by strong replication of transactions. Public distributed ledger systems are highly suitable for providing very high level of transaction security at the cost of privacy and immutability (data can't be changed or deleted). Today, public distributed ledgers such as Bitcoin and Ethereum provide the highest level of transaction security.

Data Asset​

Data turns into a valuable asset if it is accounted for. In an accounted form it can be easily priced, exchanged or traded.

Data Vault​

Software used to store and manage data with an account. The software must apply a secure architecture and measures for keeping data assets safe. This is achieved through encryption, strong authentication and restrictive access to keep data private by default.

See Design Principles / Separation of Account and Service

Metadata​

metadata_hash = calculate_hash_sum(
    domain_id + time_stamp + previous_verification_hash
)

Description:

  • metadata_hash: The check sum for all metadata data fields. It simplifies the hash construction and the ability to identify data corrupton in this part of the verification structure.
  • domain_id: 10 digits hexadecimal randomly generated to identify the host system that runs the AQP service.
  • time_stamp: time-stamp of the current revision (decimal numbers YYYYMMDDHHMMSS e.g. 20211128092608).
  • previous_verification_hash: previous_revision_verification_hash if present

Witness​

Witnessing allows one to undeniably prove the existence of a dataset (represented as a portable hash chain). To complete the witnessing process, a Domain Snapshot is created. This is a collection of all revision hashes within one domain. A Merkle tree is used to unify all hashes of the latest revisions of all portable hash chains within a domain into a single hash value.

The witness_event_verification_hash is written to the Witness Network. The witness_event_verification_hash is then generated by using the domain_snapshot_genesis_hash and the merkle_root hash together. This allows the page snapshot itself to also be witnessed.

A single revision which has been witnessed, will not store the whole Merkle tree, but only its relevant path to the Merkle root. Performing a Merkle proof means that its revision is included in the Merkle tree.

witness_hash = calculate_hash_sum(
    domain_snapshot_genesis_hash + merkle_root +
    witness_network + witness_event_transaction_hash
)

Witness network​

We are using the Ethereum Network as an optional Witness Network for cryptographic time-stamping.

Encryption​

according to wikipedia

In cryptography, encryption (more specifically, encoding) is the process of transforming information in a way that, ideally, only authorized parties can decode. This process converts the original representation of the information, known as plaintext, into an alternative form known as ciphertext. Despite its goal, encryption does not itself prevent interference but denies the intelligible content to a would-be interceptor.

Hash​

according to investopedia

A hash is a mathematical function that converts an input of arbitrary length into an encrypted output of a fixed length. Thus, regardless of the original amount of data or file size involved, its unique hash will always be the same size. Moreover, secure hashes cannot be "reverse-engineered" to get the input from the hashed output, at least with current technology.

If you use a specific function on the same data, its hash will be identical, so you can validate that the data is the same (i.e., unaltered) if you already know its hash. A different function would deliver a different hash.

Verification Process​

The verification process is a redo of the verification data generation process, and additionally a comparison of their results.

Verification of Content

All hashes are recalculated in a separate client implementation, and compared with the ones sent via the API. If the data was not altered or corrupted; nor was there a difference in the process to calculate the hash, they will match. This will create a high level of assurance that the integrity and history of the portable hash chain in question has not been altered.

Verification of Account

We cryptographically verify that the revision signature is indeed generated by the account specified in the verification data.

Verification of Time

To verify that the witness event included in a revision is correct, a lookup and comparison of the witness_event_verification_hash on-chain is performed and compared with the recalculated event.