Schema (v3.2)
The schema documentation below outlines the five types of revisions (file, content, signature, witness, link and form) and their respective properties. This schema defines a structure for atomic revisions of aqua secured files. Each revision is uniquely identified by a hash and contains metadata specific to its type.Overview
The revision is identified by a unique hash which is also used to verify the integrity of the revision. It acts as a globally unique identifier. Unique identifiers are used as unique references to link revisions together or to perform operations on them (transport, access control, etc.).
Revision Types
There are five main types of revisions:- Content Revision (1.1 Form Revision - a special type of content revision for layer 2 applications)
- Signature Revision
- Witness Revision
- Link Revision
Common Properties
All revision types share properties which are common forming a hash-chain:previous_verification_hash: (String) The hash of the previous revision in the chain. Empty for the first revision.local_timestamp: (String) The UTC timestamp of the revision in YYYYMMDDHHMMSS format.revision_type: (String) The type of revision.version: (String) The schema version and hashing method used.
Hashing Methods
The hashing method used is SHA256. The revision object sorts all key-values as ‘Canonical JSON’ this ensures no whitespaces, sorted keys, no floating-point ambiguity and unicode normalization.Hashing Types
Scalar
Simple hash of the stringified revision object. This is the default method for performance reasons.
Tree
Creates a merkle tree of all the values. This allows a more granular verification and is used for selective disclosure.
Hash Security
1. Content Revision
A Content Revision represents the initial or updated state of a file which is secured by the Aqua-Protocol. It includes metadata about the file: its hash and index. The index is a mutable part of the data structure, it allows to update file location and the services which handle the file.Properties
previous_verification_hash: (String) The hash of the previous revision in the chain. Empty for the first revision (genesis revision).local_timestamp: (String) The UTC timestamp of the revision in YYYYMMDDHHMMSS format. It’s a local timestamp of the server running the aqua-service. For cryptographically secured timestamps the witness revision is used.revision_type: (String) The type of revision, always “content” for this type.file_hash: (String) The hash of the file content.file_nonce: (String) A unique nonce associated with the file. This is used to ensure that additional entropy is added to the hash to make it globally unique.version: (String) The schema version and hashing method used.
Example File Revision
File Revision
A File Revision includes the file’s content or reference, hash and nonce.Properties
previous_verification_hash: (String) The hash of the previous revision in the chain.local_timestamp: (String) The timestamp of the revision in YYYYMMDDHHMMSS format.revision_type: (String) The type of revision, always “file” for this type.content: (String) The content of the file.file_hash: (String) The hash of the file content.file_nonce: (String) A unique nonce associated with the file.version: (String) The schema version and hashing method used.
1.1 Form Revision
Form revisions are a special type of content revision for layer 2 applications. They are used to create a form that can be signed by the user.Native Layer 2 applications are aqua identity and aqua access control. The tree verification structure allows for selective disclosure of the form data.
Example Form Revision
2. Signature Revision
A Signature Revision represents a digital signature applied to a file revision. It includes the signature, public key, and wallet address of the signer.Properties
previous_verification_hash: (String) The hash of the previous revision in the chain.local_timestamp: (String) The timestamp of the revision in YYYYMMDDHHMMSS format.revision_type: (String) The type of revision, always “signature” for this type.signature: (String) The digital signature.signature_public_key: (String) The public key of the signer.signature_wallet_address: (String) The wallet address of the signer.signature_type: (String) The type of signature (e.g., “ethereum:eip-191”). This allows for different signature types to be added to Aqua Protocol.version: (String) The schema version and hashing method used.
Example Signature Revision
3. Witness Revision
A Witness Revision represents a record of a witness event, such as a blockchain transaction. It includes metadata about the witness event, such as the transaction hash and network.Properties
previous_verification_hash: (String) The hash of the previous revision in the chain.local_timestamp: (String) The timestamp of the revision in YYYYMMDDHHMMSS format.revision_type: (String) The type of revision, always “witness” for this type.version: (String) The schema version and hashing method used.witness_merkle_root: (String) The Merkle root of the witness event.witness_timestamp: (Number) The timestamp of the witness event.witness_network: (String) The network where the witness event occurred (e.g., “sepolia”).witness_smart_contract_address: (String) The address of the smart contract involved.witness_transaction_hash: (String) The hash of the transaction.witness_sender_account_address: (String) The address of the sender’s account.witness_merkle_proof: (Array) An array of Merkle proofs.
Example Witness Revision
4. Link Revision
A Link Revision represents a record of other revisions belonging to other or the same AquaTree structure. This serves two distinct purposes:- To be able to reference other AquaTree objects in a verifiable way.
- To acknowledge forks within an AquaTree which could be removed without recognition without a link revision to “merge” those revisions into the continuous hash-chain structure.
Example Link Revision
Other Metadata and its Role
File Index
Thefile_index object maps revision hashes to file names in a mutable form. This allows for files to be reorganized or to be associated with various services. As the revision is immutable, it is required that this is external to the revision.
Example File Index
Tree Structure
Thetree object represents the hierarchical structure of revisions. Each node contains a hash and an array of children.
Example Tree Structure
Tree Mapping
ThetreeMapping object provides paths to specific revisions and identifies the latest revision hash.
Properties
paths: (Object) Maps revision hashes to their paths in the tree.latestHash: (String) The hash of the latest revision.