diff --git a/404.html b/404.html index cc52d5f..adee00b 100644 --- a/404.html +++ b/404.html @@ -48,7 +48,7 @@ -
+
diff --git a/categories/index.html b/categories/index.html index f978a65..46f9112 100644 --- a/categories/index.html +++ b/categories/index.html @@ -49,7 +49,7 @@
-
+
diff --git a/community/_print/index.html b/community/_print/index.html index 5a2f62f..12a770b 100644 --- a/community/_print/index.html +++ b/community/_print/index.html @@ -50,7 +50,7 @@
-
+
diff --git a/community/index.html b/community/index.html index 2499ac0..3c368b2 100644 --- a/community/index.html +++ b/community/index.html @@ -50,7 +50,7 @@
-
+
diff --git a/docs/_print/index.html b/docs/_print/index.html index 72a5118..74ca5ba 100644 --- a/docs/_print/index.html +++ b/docs/_print/index.html @@ -50,7 +50,7 @@
-
+
@@ -943,7 +943,7 @@

A side note

2.2 - Identity Protocol

-
Shows how it is possible to build an identity protocol on top of Aqua using data vaults.
+
The following text has the goal to highlight the possibility to build identity protocol functionality on top of the core verifiction protocol. This part of the project is in early stages and not mature.

The Aqua Identity Protocol (AIP) is an experimental application protocol under development for Self Sovereign Identity’s (SSIs) on top of the Aqua Protocol. This is an active field of research which is related to diff --git a/docs/contribution-guidelines/index.html b/docs/contribution-guidelines/index.html index 2af8c56..f1ca20a 100644 --- a/docs/contribution-guidelines/index.html +++ b/docs/contribution-guidelines/index.html @@ -20,10 +20,10 @@ - + - + @@ -52,7 +52,7 @@

-
+
@@ -63,7 +63,7 @@
- +
@@ -143,7 +143,7 @@

Contribution Guidelines

-Last modified June 13, 2024: Updating index (9142a62) +Last modified September 10, 2024: Update aqua-identity-protocol.md (93e95d4)
diff --git a/docs/implementations/_print/index.html b/docs/implementations/_print/index.html index de5146e..520fa5c 100644 --- a/docs/implementations/_print/index.html +++ b/docs/implementations/_print/index.html @@ -53,7 +53,7 @@
-
+
diff --git a/docs/implementations/index.html b/docs/implementations/index.html index 2a3d7e5..41f0af5 100644 --- a/docs/implementations/index.html +++ b/docs/implementations/index.html @@ -53,7 +53,7 @@
-
+
@@ -64,7 +64,7 @@
- +
@@ -154,7 +154,7 @@
-Last modified June 13, 2024: Updating index (9142a62) +Last modified September 10, 2024: Update aqua-identity-protocol.md (93e95d4)
diff --git a/docs/implementations/reference-architecture/index.html b/docs/implementations/reference-architecture/index.html index 5775209..44d739f 100644 --- a/docs/implementations/reference-architecture/index.html +++ b/docs/implementations/reference-architecture/index.html @@ -22,11 +22,11 @@ "> - + - + @@ -56,7 +56,7 @@
-
+
@@ -67,7 +67,7 @@
- +
@@ -540,7 +540,7 @@

Public-Private-Key Signatures (se
-Last modified June 13, 2024: Updating index (9142a62) +Last modified September 10, 2024: Update aqua-identity-protocol.md (93e95d4)

diff --git a/docs/index.html b/docs/index.html index 5dcc2bf..2328d68 100644 --- a/docs/index.html +++ b/docs/index.html @@ -50,7 +50,7 @@
-
+
@@ -61,7 +61,7 @@
- +
@@ -168,7 +168,7 @@
-Last modified June 13, 2024: Updating index (9142a62) +Last modified September 10, 2024: Update aqua-identity-protocol.md (93e95d4)
diff --git a/docs/overview/_print/index.html b/docs/overview/_print/index.html index f44227f..3ce6ddb 100644 --- a/docs/overview/_print/index.html +++ b/docs/overview/_print/index.html @@ -50,7 +50,7 @@
-
+
diff --git a/docs/overview/index.html b/docs/overview/index.html index e7dd909..e327a93 100644 --- a/docs/overview/index.html +++ b/docs/overview/index.html @@ -50,7 +50,7 @@
-
+
@@ -61,7 +61,7 @@
- +
@@ -172,7 +172,7 @@

The socio-technological impact
-Last modified June 13, 2024: Updating index (9142a62) +Last modified September 10, 2024: Update aqua-identity-protocol.md (93e95d4)

diff --git a/docs/protocol/_print/index.html b/docs/protocol/_print/index.html index 1c9db95..0cc8b1d 100644 --- a/docs/protocol/_print/index.html +++ b/docs/protocol/_print/index.html @@ -53,7 +53,7 @@
-
+
@@ -897,7 +897,7 @@

A side note

2 - Identity Protocol

-
Shows how it is possible to build an identity protocol on top of Aqua using data vaults.
+
The following text has the goal to highlight the possibility to build identity protocol functionality on top of the core verifiction protocol. This part of the project is in early stages and not mature.

The Aqua Identity Protocol (AIP) is an experimental application protocol under development for Self Sovereign Identity’s (SSIs) on top of the Aqua Protocol. This is an active field of research which is related to diff --git a/docs/protocol/aqua-identity-protocol/index.html b/docs/protocol/aqua-identity-protocol/index.html index 450387d..aff7d25 100644 --- a/docs/protocol/aqua-identity-protocol/index.html +++ b/docs/protocol/aqua-identity-protocol/index.html @@ -15,22 +15,22 @@ Identity Protocol | AQUA Protocol - - - + - - + - @@ -56,7 +56,7 @@

-
+
@@ -67,7 +67,7 @@
- +
@@ -177,7 +177,7 @@

Identity Protocol

-
Shows how it is possible to build an identity protocol on top of Aqua using data vaults.
+
The following text has the goal to highlight the possibility to build identity protocol functionality on top of the core verifiction protocol. This part of the project is in early stages and not mature.

The Aqua Identity Protocol (AIP) is an experimental application protocol @@ -678,7 +678,7 @@

FAQ

-Last modified June 13, 2024: Updating index (9142a62) +Last modified September 10, 2024: Update aqua-identity-protocol.md (93e95d4)
diff --git a/docs/protocol/aqua-name-resolution/index.html b/docs/protocol/aqua-name-resolution/index.html index 5e9205d..a0c6a1b 100644 --- a/docs/protocol/aqua-name-resolution/index.html +++ b/docs/protocol/aqua-name-resolution/index.html @@ -22,11 +22,11 @@ "> - + - + @@ -56,7 +56,7 @@
-
+
@@ -67,7 +67,7 @@
- +
@@ -161,7 +161,7 @@

Aqua Name Resolution (ANS)

reference implementation .

-Last modified June 13, 2024: Updating index (9142a62) +Last modified September 10, 2024: Update aqua-identity-protocol.md (93e95d4)
diff --git a/docs/protocol/assurance-levels-aal/index.html b/docs/protocol/assurance-levels-aal/index.html index 2b78a7e..f77cfaf 100644 --- a/docs/protocol/assurance-levels-aal/index.html +++ b/docs/protocol/assurance-levels-aal/index.html @@ -22,11 +22,11 @@ "> - + - + @@ -56,7 +56,7 @@
-
+
@@ -67,7 +67,7 @@
- +
@@ -206,7 +206,7 @@

Level 3

-Last modified June 13, 2024: Updating index (9142a62) +Last modified September 10, 2024: Update aqua-identity-protocol.md (93e95d4)
diff --git a/docs/protocol/data-accounting/index.html b/docs/protocol/data-accounting/index.html index 5e580ed..8ee7527 100644 --- a/docs/protocol/data-accounting/index.html +++ b/docs/protocol/data-accounting/index.html @@ -22,11 +22,11 @@ "> - + - + @@ -56,7 +56,7 @@
-
+
@@ -67,7 +67,7 @@
- +
@@ -217,7 +217,7 @@

Practical accounting

Please contribute to this article (fixing errors) by exporting it and sending it back with your improvement to community[at]inblock[dot]io.

-Last modified June 13, 2024: Updating index (9142a62) +Last modified September 10, 2024: Update aqua-identity-protocol.md (93e95d4)
diff --git a/docs/protocol/data-governance/index.html b/docs/protocol/data-governance/index.html index 13c3214..4daa7e4 100644 --- a/docs/protocol/data-governance/index.html +++ b/docs/protocol/data-governance/index.html @@ -22,11 +22,11 @@ "> - + - + @@ -56,7 +56,7 @@
-
+
@@ -67,7 +67,7 @@
- +
@@ -300,7 +300,7 @@

References

-Last modified June 13, 2024: Updating index (9142a62) +Last modified September 10, 2024: Update aqua-identity-protocol.md (93e95d4)
diff --git a/docs/protocol/delegated-witnessing/index.html b/docs/protocol/delegated-witnessing/index.html index 4caa207..521f36f 100644 --- a/docs/protocol/delegated-witnessing/index.html +++ b/docs/protocol/delegated-witnessing/index.html @@ -22,11 +22,11 @@ "> - + - + @@ -56,7 +56,7 @@
-
+
@@ -67,7 +67,7 @@
- +
@@ -157,7 +157,7 @@

Delegated Witnessing

of the Merkle proof is used as a prefix for all other included portable hash chains included in the domain snapshot.

-Last modified June 13, 2024: Updating index (9142a62) +Last modified September 10, 2024: Update aqua-identity-protocol.md (93e95d4)
diff --git a/docs/protocol/design-principles/index.html b/docs/protocol/design-principles/index.html index e507d1d..331fb8a 100644 --- a/docs/protocol/design-principles/index.html +++ b/docs/protocol/design-principles/index.html @@ -22,11 +22,11 @@ "> - + - + @@ -56,7 +56,7 @@
-
+
@@ -67,7 +67,7 @@
- +
@@ -299,7 +299,7 @@

Implementation Specifics

import / export (which means only the text not the verification data is imported / exported.

-Last modified June 13, 2024: Updating index (9142a62) +Last modified September 10, 2024: Update aqua-identity-protocol.md (93e95d4)
diff --git a/docs/protocol/guardian/index.html b/docs/protocol/guardian/index.html index ec63f6d..182bfbf 100644 --- a/docs/protocol/guardian/index.html +++ b/docs/protocol/guardian/index.html @@ -22,11 +22,11 @@ "> - + - + @@ -56,7 +56,7 @@
-
+
@@ -67,7 +67,7 @@
- +
@@ -538,7 +538,7 @@

Matrix-BOT

before it’s send to the import API) (required)
-Last modified June 13, 2024: Updating index (9142a62) +Last modified September 10, 2024: Update aqua-identity-protocol.md (93e95d4)
diff --git a/docs/protocol/immutable-hyperlinks/index.html b/docs/protocol/immutable-hyperlinks/index.html index ad75536..e4ab578 100644 --- a/docs/protocol/immutable-hyperlinks/index.html +++ b/docs/protocol/immutable-hyperlinks/index.html @@ -22,11 +22,11 @@ "> - + - + @@ -56,7 +56,7 @@
-
+
@@ -67,7 +67,7 @@
- +
@@ -225,7 +225,7 @@

Implementation

  • The verification_hash is stored in the content-slot ‘transclusion hashes’ with the internal links which referne the resource.
    • -Last modified June 13, 2024: Updating index (9142a62) +Last modified September 10, 2024: Update aqua-identity-protocol.md (93e95d4)
    diff --git a/docs/protocol/index.html b/docs/protocol/index.html index 294a9c3..8a1c6a0 100644 --- a/docs/protocol/index.html +++ b/docs/protocol/index.html @@ -53,7 +53,7 @@
    -
    +
    @@ -64,7 +64,7 @@
    - +
    @@ -159,7 +159,7 @@
    Identity Protocol
    -

    Shows how it is possible to build an identity protocol on top of Aqua using data vaults.

    +

    The following text has the goal to highlight the possibility to build identity protocol functionality on top of the core verifiction protocol. This part of the project is in early stages and not mature.

    @@ -211,7 +211,7 @@
    -Last modified June 13, 2024: Updating index (9142a62) +Last modified September 10, 2024: Update aqua-identity-protocol.md (93e95d4)
    diff --git a/docs/protocol/whitepaper/index.html b/docs/protocol/whitepaper/index.html index 458fa61..91ced33 100644 --- a/docs/protocol/whitepaper/index.html +++ b/docs/protocol/whitepaper/index.html @@ -22,11 +22,11 @@ "> - + - + @@ -56,7 +56,7 @@
    -
    +
    @@ -67,7 +67,7 @@
    - +
    @@ -1005,7 +1005,7 @@

    A side note

    attributed to its sender, avoiding fraud. This is one of many other use cases, e.g. providing trusted news via revision-controlled journalism.

    -Last modified June 13, 2024: Updating index (9142a62) +Last modified September 10, 2024: Update aqua-identity-protocol.md (93e95d4)
    diff --git a/index.html b/index.html index 22c5f3f..dbfca36 100644 --- a/index.html +++ b/index.html @@ -50,7 +50,7 @@
    -
    +
    diff --git a/offline-search-index.13c3fed2449812468a41c56080dd6761.json b/offline-search-index.bfc05a12f91c797b82d53207d70beef6.json similarity index 63% rename from offline-search-index.13c3fed2449812468a41c56080dd6761.json rename to offline-search-index.bfc05a12f91c797b82d53207d70beef6.json index 57dd9d3..eee9dc1 100644 --- a/offline-search-index.13c3fed2449812468a41c56080dd6761.json +++ b/offline-search-index.bfc05a12f91c797b82d53207d70beef6.json @@ -1 +1 @@ -[{"body":"We develop the AQUA-Protocol to increase trust and digital sovereignty for individuals and organizations.\nWe believe that this is an effective way to redefine collaboration and strengthen democracy to be more inclusive and participatory by providing accountability for data. We do this in a context where it is critical to address challenges and threats which come with the advancement of technologies (e.g. deep fake, manipulation of data, digital surveillance, monopolization).\nWith the powerful tools we provide, we can showcase how trusted data and digital sovereignty are key enablers to support the emancipation and integration of individuals and small to medium businesses into a digital economy, which is currently dominated by large players. We are showing how this is a feasible approach to empower more inclusive and democratic participation.\nWhat are exemplary applications that are meeting current organizational demands? Aside from the core features of the AQUA-Protocol and its reference implementation (to provide data integrity verification, proof of existence, and a strong identity by using public-private key infrastructure), there is an amazing potential that comes as an emergent property of the interaction of individuals using sovereign instances of Personal-Knowledge-Containers.\nThis potential lies in the ability to collaborate by exchanging verified data between independent parties to form a network of relationships as a web of trust. This allows for peer-to-peer institutions and organizations to be built fully software-defined, in traditional or network structures.\nIt is possible to model existing institutions on top of this infrastructure today. It is a free and open-source tool to provide a process to issue and verify digital certificates for various use cases. Including examples, showcased for the educational sector (school and university degrees) but the use cases go beyond this:\n Provide an infrastructure to curate knowledge and enable peer-to-peer wiki’s in which a contribution itself is attested. This has potentially huge implications, as a successfully merged contribution to a leading scientific endeavor could one could imagine this succeeding the reputational value of a university degree. Fighting fake news by providing an audible trail for the information source to the consumer and which steps have been taken, by which account, to reach its current state. E.g. an intelligence report about an ongoing conflict or crisis. Providing credible credentials to fight deep fake and impersonation. In one shocking case, this shows the danger for our political landscape. In this example the mayor of Berlin was tricked, when she had a zoom call with a fake Vladimir Klitschko (in the role of the Mayor of Kyiv, using deep fake for the video and audio to impersonate him) who tried to get money from her. Source Providing a trust infrastructure for invoice validation: Large companies are challenged by the increasing number of fraud and fishing emails to trick companies to send money to criminals. We can use the SSI-Approach of aqua to verify invoices and do automated tests towards the trustworthiness of the sender, by checking the sender’s account and the trust relationship cryptographically. Allowing for automated verification of the invoices instead of lengthy manual testing procedures or complicated processes requiring a CRM-System with an intense KYC (Know You Customer) approach. Proving where the information has originated. This can be used to protect intellectual property (IP) or to prove where data originated. This is highly relevant in various contexts, be it for the credibility of evidence in court or for whistle-blowers or investigative journalists to give their claims more credibility. The socio-technological impact on society We provide a prototype implementation of the aqua protocol with a Personal-Knowledge-Container(PKC). An approach towards digital sovereignty without compromises. It enables data accounting and with it an effective way to enable peer-to-peer trusted data generation and exchange. We showcase that it is possible to have full control over your data, you can share and govern it independently of third parties. This is essential to democratize access to the digital economy, so individuals can utilize the value of their data and do trusted interactions with each other.\nThis technology enables various applications by offering a peer-to-peer-publishing platform technology, this includes but is not limited to:\n Self-Sovereign Identity (SSI) crowdsourced knowledge management, a distributed Wikipedia crowdsourced news crowdsourced petition systems (crowdsourcing problems, solutions, decisions). This Protocol and prototype allow for the practical exploration this how this can redefine our collective sense-making by providing a rational process for forming a truth by consensus between trusted peers. This allows for the practical exploration of digital, participatory collaboration at scale, as the AQUA-Protocol can account for contributions that are currently not measurable in monetary value while those contributions provide value to society and/or nature. It seems possible to envision a different economy where data becomes a multi-dimensional currency that allows us to make better-informed decisions. It can inform us to have a greater choice in how we participate economically as service providers and/or consumers.\n What is it not yet good for?: This is an experimental protocol with a pilot implementation, which is meant for the exploration of new design principles to improve digital sovereignty and trust. This prototype is not production-grade software and should not be used outside of experimental applications. The prototype does currently (Dec'22) not include a transport layer. ","categories":"","description":"","excerpt":"We develop the AQUA-Protocol to increase trust and digital sovereignty for individuals and organizations.\nWe believe that this is an effective way to redefine collaboration and strengthen democracy to …","ref":"/docs/overview/","tags":"","title":"Overview"},{"body":"Implementation specific architecture documentation for the Aqua Data Vault ‘Personal Knowledge Container (PKC)’. In this document you will find reasoning as to why certain components were chosen to build this prototype. We have not duplicated any vendor documentation. Please find the linked-list for the documentation of the components we use here:\n MetaMask Ethereum Docker MediaWiki MediaWiki Extension: Aqua MediaWiki Skin Tweeki Pelith Eauth Server Nodejs GitHub Apache Nginx Let’s Encrypt All software components selected are open source licenses. They each have active developer communities behind them to secure future support and further development.\nWallets / Accounts Why do we use Ethereum Wallets / Accounts?\nAn identity anchor needs to be a public, private key. This allows a public component which we can share (public key) and a private component which proves ownership over that public-key. Public keys are used in Ethereum as accounts to receive and send transactions. Therefore the Ethereum ecosystem has developed standards. These have evolved to a larger eco-system involving wallet-providers which have built software and hardware wallets to securely manage those keys. We leverage one of the most vibrant developer communities and utilize these wallets. In our case they are used mainly for offline-activities (Login, Signing) which do not require connectivity to the Ethereum blockchain.\nWeb-Application (Chrome-Extension MetaMask) Was selected as it is one of the most advanced, widely used, feature-rich web-wallets. Most importantly it’s a browser-plugin which allows us to interact with browser applications. MetaMask also has the ability to connect to a hardware wallet allowing for increased security and levels of assurance.\n Large User-Base 10 Million + Hardware Wallet Support (E.g. Ledger) Large User-base 5 Million + All related source code is open source, lot’s of money behind it (future proof) SSI (Self-sovereign identity): Compatible with the DID schema did:ethr:\u003cwallet_address\u003e Fulfills SSI principles: Controlled by user, allows for creation of new accounts / wallet addresses User can create new identity anchor independent of third party Can be moved between devices by users recovery key or even to a hardware wallet (not recommended but possible: https://kryptonitelex.medium.com/how-to-transfer-your-metamask-to-a-ledger-hardware-wallet-bcece7d5567b ) Witness Network We are using the Ethereum Network as an optional Witness Network for cryptographic time-stamping.\nWhy public Blockchain? The witness event serves the purpose of being able to prove the existence of a document without the ability to deny it. This requires censorship resistance and global coverage. The security of the network, it’s distribution, and the high economical price to attack the network, are all good reasons why we want to use a public blockchain to publish highly obfuscated hashes (fingerprints). This proves the state of the data in a Data Vault (PKC).\nThe MetaMask wallet is able to publish the witness event verification hash to the public Ethereum blockchain. This completes our third important layer of integrity verification, which is to prove cryptographic time and existence of a document by writing it’s fingerprint onto the ledger. This is not done directly, but through a process which highly obfuscates the hash. This ensures that that there is no plausible attack (even if the attacker owns a powerful quantum computer) to match the fingerprint with any personal data.\nData Vault The Data Vault named ‘Personal Knowledge Container’ is creatd by using a tool for containerization called ‘Docker’. This allows us to package our application so it can be deployed to different operating system environments. Docker provides the abstraction / virtualization layer.\nInside Docker we containerized multiple services:\nMediaWiki for data governance MediaWiki is a data governance tool which has a legacy as a collaboration tool. It powers Wikipedia, the largest encyclopedia in the world. We step into this experience, and the benefits of a feature rich, battle-proven application. It’s a powerful tool to both manage and present data.\nAs MediaWiki has an active and established developer community, it is possible to tap into existing professional service companies. Supporting development and any required changes within the application.\nMediaWiki has been modified to use workflows for data processing. This will allow for implementing and testing workflows and business logic between Personal-Knowledge-Containers.\nWe use all the benefits of MediaWiki to manage and present data in the browser, while we work around one of its main limitations: Security. MediaWiki was never developed to have advanced security and permission structures, as it was built for Wikipedia - a fully public website. This has several implications for us.\nSecurity Practices:\n We assume that we can’t defend against insider attacks on the same MediaWiki instance, therefore every user has their own instance If there is a need for a collaboration space, it is possible to spawn containers for multiple accounts which trust each other to work together on shared data If you use a hosted PKC instance, assume the provider has access to your data as we don’t use homomorphic encryption nor do we have encryption implemented We are using typed and tested PHP (for MediaWiki Extension Data Accounting) to improve test coverage to increase stability and security of our application To securely exchange data between PKC’s, we implement a separate security software called Guardian. The Guardian protects the PKC and manages all access according to the accounts owners set permissions. The Guardian is under active development. It will receive the highest scrutiny and attention to ensure a minimal attack surface while allowing trust between Guardians so data can be exchanged. The Apache WebServer present in the MediaWiki container has a technological dependency and needs regular updates as Apache was effected by critical security issues like CVE-2021-44228 Therefore we do not expose the Apache web-server to the internet by default and do not recommend this to ensure that there is no unnecessary attack surface. If an organization decides to expose the web-surface of a PKC to the internet, they should expect this instance to be compromised and leak all it’s stored data. Therefore we re-emphasize: If PKC / MediaWiki is exposed to the web, there can’t be any guarantee that data can be kept private. Therefore assume your data can be leaked on a web-facing MediaWiki instance. Organizations hosting PKC’s for collaboration should do so with restricted firewall permissions, ensuring that the web-interface is only reachable for the employees authorized to see the content. MediaWiki Extension: Aqua The existing ecosystem and reference implementations around MediaWiki allowed us to quickly prototype our reference implementation for Aqua. The implementation itself allowed us to further develop the protocol. The downsides are currently old PHP code and MediaWiki’s legacy. In return we benefit from a well documented project.\nLooking forward we want to see other client-implementations in different languages independent of MediaWiki to show the potential of the Aqua Protocol. We hope to re-use part of the PHP code base to apply it to other applications, like Word-Press.\nMediaWiki Skin Choice Using Tweeki as a Bootstrap 4 compatible Skin for MediaWiki, we were able to establish contact with the chief maintainer of the extension, and were able to collaborate to solve various issues to improve the skin. We are coordinating with other parties to see how we can improve support for the Skin. In the future we are hoping to increase the maintainer base. Prospectively we want to use Tweeki as an abstraction layer from MediaWiki classic to Bootstrap 4, and respectively Bootstrap 5+.\nAuthentication For Authentication with Web-Wallets, we use https://github.com/pelith/node-eauth-server which provides us with an open source solution for a signature-response challenge. We then integrate with OAUTH2 and OIDC using existing authentication standards to achieve the login. The Pelith server provides us with the Signature-Challenge and is forwarding the access token via OAUTH2 to MediaWiki. Here we check if the user exists. If this is the case, access is granted. WebServer-Proxy / HTTPs We are using NGINX Web-Server as the proxy server. NGINX is a modern and the most popular (#1 since 2021 by share1) web-server on the web. We are using Let’s Encrypt to provide secure connections via HTTPS if a PKC is deployed to the web. Let’s encrypt serves over 260 million websites according to the vendor website.2 provides free TLS Certificates for secure HTTPS connections. The NGINX Web-Proxy allows us to ensure that we can add additional services to the PKC and redirect the services according to our needs. Software-Development We use https://github.com for software development. As we started with very little budget, we gratefully utilised free resources to develop our open source software. This allowed us to focus on being productive. Github is owned by Microsoft and is therefore subject to US policies and Microsofts interests. This itself requires us to move away to be independent or at least host a mirror instance outside of Github. The deletion of a repository or losing access could harm our development process significantly. We use GPL-V3 license on the majority of our repositories. We maintain the rights on branding We maintain more restrictive rights on deployment scripts (service provider technologies) Browser Choice We are using the Chrome-Engine as our Web-Browser of choice. It’s the most dominant web-browser on the Web, and has become the quasi standard with many different forks creating an ecosystem around it. Microsoft-Edge is actually Chrome. There are non-google chrome forks which deserve attention, funding and support (like https://github.com/Eloston/ungoogled-chromium ). This will provide us with a modern and state of the art browser architecture to work with.\nAs Chrome is the most secure and modern base to build on, we support -only- chrome. Therefore we use a chrome extension to verify the content of an Aqua file. This extension is available for download in the Google Chrome App Store, or can be built from scratch following the instructions in our repository.3\nThis allows us to provide ease of setup, as users can easily deploy the chrome extension without further effort by adding it from the google app store.\nWe are using NPM / node.js for fast prototyping. This comes with severe security implications as the npm ecosystem has been prone to various supply-chain attacks over recent months 4 .\nTechnology choices on cryptography All cryptography used in our development is based on international NIST standards and follows the international understanding for internet security. This is consistent with the perspective of the BSI in Germany, but for some specific details there are no insights provided by the ministry.\nHashing Algorithms (SHA3-512) PKC uses standard Crypto (SHA3-512) winner of the National Institute of Standards and Technology see https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.202.pdf . We do not use custom encryption as this comes at the cost of unnecessary risks.\nThis is an accepted secure and recommended standard according to BSI - Technische Richtlinie – Kryptographische Algorithmen und Schlussellängen Seite 42 .\nMerkle Tree5 We use merkle trees to be able to witness the state of all pages / files in a single hash. Used to generate a unique fingerprint of a domain (a collection of verified data hash chain’s within one domain). There is a lot of future potential in ongoing research to improve privacy and utility of merkle trees in the Aqua Protocol See related technologies and research like TAPROOT: https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki Public-Private-Key Signatures (secp256k1) Used in combination with Ethereum Accounts. It is used for signing and authentication challenges.\n in ether.js cryptography/secp256k1 see implementation related documents of the ‘Standards for Efficient Cryptography Group’ https://secg.org/ specific doc secp256k1 [ Both variants of the same standardization process of the Standards for Efficient Cryptography Group 2015, See differences P9 Supported by BSI secp256r1 but secp256k1 is not mentioned.https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/TechnischeRichtlinien/TR03116/BSI-TR-03116-4.pdf?__blob=publicationFile\u0026v=7 Request for clarification was send via E-Mail on the 3rd of November 2021 by Tim Bansemer. Answer of the BSI: Currently the BSI has no assessment or recommendation for secp256k1. For authentication with Metamask Ethereum wallets we currently use https://github.com/pelith/node-eauth-server . We are signing a unique input value with ethereum.js using the personal sign method. Once the challenge is completed successfully we receive an OAUTH token from the Eauth identity provider of the pelith Eauth server. https://linuxiac.com/nginx-most-popular-web-server/  ↩︎\n https://letsencrypt.org/  ↩︎\n https://github.com/inblockio/aqua-verifypage-chrome-extension  ↩︎\n https://duckduckgo.com/?q=npm+supply+chain+attack\u0026ia=software  ↩︎\n https://en.wikipedia.org/wiki/Merkle_tree  ↩︎\n ","categories":"","description":"Explains the technologies selected for the reference implementation and why we selected them.\n","excerpt":"Explains the technologies selected for the reference implementation and why we selected them.\n","ref":"/docs/implementations/reference-architecture/","tags":"","title":"Reference Implementation"},{"body":" Current version: Aqua Protocol v1.1 Specification Author: Tim Bansemer, Publius Dirac Date: 30.12.2021 Status: DRAFT / Experimental Implementation: https://github.com/inblockio/micro-pkc Introduction The Aqua Protocol (AQP) is a data accountability and exchange protocol between hosts in peer-to-peer environments. The AQP is used to realize the goal of accounting for data origin and history . The description for the proof-of-concept implementation of the AQP can be found in this page .\nMotivation In today’s world, there are no widely adopted trustless processes of checking if data have been manipulated or corrupted, are attributed to the wrong author, or are attributed to the wrong time. Today’s processes are dependent on centralized trusted services which retain all power over governing the data.\nThere is a lack of transparency or ability to check if data have been altered by an unauthorized party. Additionally, consumers of data are incapable of verifying if centralized services have altered the data. This leads to a world of untrustworthy information in which we don’t know how to conclude what is true.\nIn a world where every piece of information is a grain in a sandstorm, it has become impossible to navigate reality. In contrast, in a world where every piece of information is a fixed star in the sky for a lifetime, we are able to relate and make sense of the information given. The Aqua Protocol (AQP) turns grains of information into fixed stars of information.\nThe AQP adds a peer-to-peer layer of accountability, making it impossible to change data unnoticed. AQP adds an essential line of defense against attacks on data integrity, plagiarism, or misattribution. AQP is used to govern trusted data, which can be quickly verified. This includes the verification of its integrity and history, the verification of its account (the entity who creates or manipulates the data), and the verification of its existence and timestamp.\nThe Aqua Protocol provides trustworthiness to data by securing data ✅ integrity, 🔏 account and ⌚ time. In order to account data, it is necessary to track and verify its history. The AQP provides a globally unique resource identification (URI) for each revision of the verified data. This identifier is collision-free, and is referred the same way across multiple interacting hosts.\nTerminology 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.\nSee Separation of Concerns .\nAccount We are following Ethereum’s account definition:\n 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.\nFor more on this topic, please read the Aqua Identity Protocol .\nDomain 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.\nE.g. by setting up the a data vault with your account it becomes your domain of data governance.\nRevision A revision is the smallest portable entity within the AQP. Multiple revisions form a single portable hash chain which is serialized in JSON format. They have existed before in unsecured systems where multiple revisions form a file which can be displayed as a page. The AQP adds the cryptographic harness to secure it. With presenting a portable hash chain, it is possible to track all incremental changes stored in each revision to understand the history of a page and how it came to be. This allows us to have version control on digital assets being able to restore earlier states and to relate to them. This allows us to have historical evidence of digital assets.\nPage A page is a visible representation of a file containing multiple or a single revision attributed to a shared origin. A page view could also be used to create a new revision by a used service which interfaces with the file for manipulation. In AQP all revisions share a global URI hash to attribute them together called a genesis hash.\nTransaction 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.\nData Asset Data turns into a valuable asset if it is accounted for. In an accounted form it can be easily priced, exchanged or traded.\nData 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.\nSee Design Principles / Separation of Account and Service Witness We define witnessing as the process of observing an event. A witness is judged by their capability to recollect and share an observed event. In other words, witnessing is the process of storing input data for later playback to provide data symmetry around an event.\nWitness Network The digital service in a distributed ledger or similar infrastructure which provides transaction security and data symmetry for shared data within the network. An example of a witness network would be Ethereum.\nE.g. Ethereum can be used to store a digital fingerprint of a domain snapshot of a data vault. A domain snapshot is the Merklized state of all witnessed hash chains being present in the data vault. It is required to pay the witness network for its service. In the case of Ethereum, this is done using ‘Ether’. This in return allows the account owner to create an ‘undeniable’ proof that a specific revision and the previous revisions within a hash chain has existed.\nPortable Hash Chain A hash chain is a linked list where each node contains the cryptographic hash of the previous node content. A portable hash chain is a hash chain that can be moved from one host to another.\nImmutable Hyperlinks / Transclusions See Immutable Hyperlinks .\nSpecification To identify a revision with a unique fingerprint, we hash its content using the SHA3-512 hashing function which always has a 128 characters long output. This value can be used as a checksum to verify data integrity. The checksum can then be entangled in a hash-chain to create an immutable track record. We then calculate multiple properties associated with the revision, in addition to its content checksum. In the next section, we differentiate between REQUIRED and OPTIONAL properties for each revision.\nAll hashes are based on SHA3-512 . This encryption standard is used to construct portable hash chains , which are serializing of data and its history in a form that can be verified, and independent of location. The portable hash chain can be fully or partially exchanged between hosts depending on the application of the data. From here on, we refer the term “portable hash chain” as “hash chain.”\nIn order to implement the AQP, we need to utilize a software that is capable of generating portable hash chains and facilitating actions described in the AQP. We call those nodes which facilitate the Aqua Protocol ‘Aqua Data Vaults’ which given their role should be implemented as a software with secure architecture and measures for keeping data assets safe. This is achieved through encryption, authentication and restrictive access to keep data private by default.\nRevision Verification Structure A revision is RECOMMENDED to be limited to 50 Megabytes to ensure that the verification can take place on all imaginable clients which might have slow network connectivity, low memory, low cpu performance. Once a revision is verified, the next one can be verified. Clients with more performance will be able to parallelize the verification. Larger files can be chunked to be placed in multiple revisions.\nA verified data structure is identified by its URI verification_hash and grouped by its genesis_hash. The first revision created will create a verification_hash which has a special meaning and is referred to as the genesis_hash. All future revisions building upon that first revision will be attributed to the genesis_hash as a unique URI for grouping the revisions. This allows us to understand if two revisions are related without needing to verify the whole history of the hash chain.\nVerification Hash revision_verification_hash is the hash sum over the string formed by the following operation\nrevision_verification_hash = calculate_hash_sum( content_hash + metadata_hash + signature_hash + witness_hash ) The content_hash and metadata_hash are REQUIRED. The signature_hash and witness_hash are OPTIONAL.\nContent A content hash is the check sum for all content data fields which simplifies hash construction and the ability to identify data corruption in this part of the verification structure. content_hash is the hash sum over the string formed by following operation:\ncontentObj = { \"main\": content, \"extension_key_1\": content_extension_1, \"extension_key_2\": content_extension_2, ..., \"extension_key_n\": content_extension_n, } sortedContenObj = sort_by_keys(contentObj) content_hash = calculate_hash_sum( sortedContenObjValue_1, sortedContenObjValue_2, ..., sortedContenObjValue_n, ) Description:\n content: The string input of the visible page using UTF-8 encoding schema. REQUIRED. content extensions: more data MAY be encapsulated in addition to the main content. These could be a file, a stateful link, or a signature. The content extensions are sorted alphabetically by their key names. OPTIONAL. The sort_by_keys function sorts the content object elements by their keys alphabetically. The JSON input MAY be a canonical JSON, in which the keys order is already alphabetical, but we sort it always to ensure the order is correct. To see an example of contentObj of a revision, see the example section,\nMetadata metadata_hash = calculate_hash_sum( domain_id + time_stamp + previous_verification_hash ) Description:\n 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 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.\nIn this specification, we use the AQP reference implementation’s signing method, which is via an Ethereum wallet.\nsignature_hash = calculate_hash_sum( signature + public_key ) The signature is generated by a wallet signing the following message:\nI sign the following page verification_hash:\" +[0x\u003crevision_verification_hash\u003e] The revision_verification_hash MUST NOT be signed twice by the same key, to avoid information leakage of the private key.\nFor example, a wallet with an address of 0xa2026582b94feb9124231fbf7b052c39218954c2 and a public key of 0x041518581af65749b3ddc69889df3e5d229bc8ad79279a07ddeb368ade5e1592368c5ff3b69143d7a1e7cf64f7d0774a6724e6eaf138d318d07ddc30f6081ca89a signs the following message:\nI sign the following page verification_hash:\" +[0x9dab72c7635043452958c4cc2902f48ef7c4ae437058280197c6a2736ab9635f799cbf190d9d07dd76589055a8ad64e61c6bebd1487994207d4cb7918b471f57] which results in the following signature:\n0x19b5697c4541509c1add3db9fc2f678b7b80325ebffd4d945ca00db5f8b3f98a142edbf9a7faa0a0c7ec4f10ae1b64cf2ea62ce3ee73ed2e37ce916d6bd016601c 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.\nThe 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.\nA 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.\nwitness_hash = calculate_hash_sum( domain_snapshot_genesis_hash + merkle_root + witness_network + witness_event_transaction_hash ) Description:\n witness_hash: the checksum for all signature data fields. It simplifies hash construction and identifies data corruption in this part of the verification structure. domain_snapshot_genesis_hash: Refers to the URI of the page which stores the whole Merkle tree of the witness event. merkle_root: the root hash of the Merkle tree. The presence of the Merkle tree allows for lazy verification to reduce required computational steps for verification by skipping the Merkle proof as both datasets can be entangled in the chain by a newer revision and therefore be immutable. witness_network: specifies which witness network was used to store the witness_event. The following structure shows an AQP hash chain with 3 revisions which wrote the witness_event_verification_hash into the witness network. Additional context:\n relative-merkle-tree-proof: This provide the relative path with all required hashes to verify the Merkle tree root from the first node which the verification_hash of the revision as a starting point. witness_event_verification_hash: It is calculated by taking the sha3-512 checksum of the domain_snapshot_genesis_hash and the merkle_root hash. This ensures that thedomain_snapshot itself will be witnessed. Example The following structure shows an AQP hash chain with 3 revisions:\n1st Revision This revision features all REQUIRED (content, metadata) and all OPTIONAL (signature, witness) AQP data fields.\n{ \"verification_context\": { \"has_previous_signature\": false, \"has_previous_witness\": false }, \"content\": { \"rev_id\": 358, \"content\": { \"main\": \"First revision text\", \"transclusion-hashes\": \"\" }, \"content_hash\": \"ae188be061822074716b43925b3ffa90a03c530342be73c3440d8f022765ffebbb56c16552f13cd1ea61f876d2d892e0a73dcba5173fc47d371b4251d6c094da\" }, \"metadata\": { \"domain_id\": \"acfa9f682e\", \"time_stamp\": \"20220116090401\", \"previous_verification_hash\": \"\", \"metadata_hash\": \"d1025fd8866d9367735d2f6617b3aa87401e08d726f311cdf834ea9540955bfc59b428676bce5d47d5fed381394ab2ed838c5eecfc9cb37313705374752c247d\", \"verification_hash\": \"9dab72c7635043452958c4cc2902f48ef7c4ae437058280197c6a2736ab9635f799cbf190d9d07dd76589055a8ad64e61c6bebd1487994207d4cb7918b471f57\" }, \"signature\": { \"signature\": \"0x19b5697c4541509c1add3db9fc2f678b7b80325ebffd4d945ca00db5f8b3f98a142edbf9a7faa0a0c7ec4f10ae1b64cf2ea62ce3ee73ed2e37ce916d6bd016601c\", \"public_key\": \"0x041518581af65749b3ddc69889df3e5d229bc8ad79279a07ddeb368ade5e1592368c5ff3b69143d7a1e7cf64f7d0774a6724e6eaf138d318d07ddc30f6081ca89a\", \"wallet_address\": \"0xa2026582b94feb9124231fbf7b052c39218954c2\", \"signature_hash\": \"cc42f40c4452a25f9ea48a97b6dfba6f69dec347db5c1adf25475b0b4a5da36af3fe48bf9f7ea0dda6bbed9367dc9c82834dbf8cc7f6220fd190cdb729d3f4ec\" }, \"witness\": { \"witness_event_id\": \"2\", \"domain_id\": \"acfa9f682e\", \"domain_snapshot_title\": \"Data Accounting:DomainSnapshot:b33afaf53ed3d245f0319d4997db2032de9d77791ae11f5125189815eef44f2fba9633bebe2e57bc5ea4b0424872ed02fa6aa9ad909f467726b536933bf715bf\", \"witness_hash\": \"9707780cebcf6ed02b40bd7e6956b35ffe142a2b5f8cee15c703a652fa389eb118ef101e2f463e95663aa4013a42d9f1ce4a83eed3528b02bf98626e7599bbd8\", \"domain_snapshot_genesis_hash\": \"b33afaf53ed3d245f0319d4997db2032de9d77791ae11f5125189815eef44f2fba9633bebe2e57bc5ea4b0424872ed02fa6aa9ad909f467726b536933bf715bf\", \"merkle_root\": \"14f26d7dc0be77afff9131c03cab39a2fa9e1270c6face3fdc35b9b4b4ac4550d048c356a4713568c42411c3e7fe3553ec7b993c9bd7da97cb976e843d7e4d29\", \"witness_event_verification_hash\": \"67e187411f1e514f232ae2858168da29b15ddfd07523e7a7618bfbf91c583f54fe8e850146120539a92a63ce6138f96599fb8a46ed492e428fe6fde9b9ea82ae\", \"witness_network\": \"goerli\", \"smart_contract_address\": \"0x45f59310ADD88E6d23ca58A0Fa7A55BEE6d2a611\", \"witness_event_transaction_hash\": \"0x5900103adc09a789fd3bd7c23dfeff1ffce41dfba0a52b525ecc032e9279eb1f\", \"sender_account_address\": \"0xa2026582b94feb9124231fbf7b052c39218954c2\", \"source\": \"default\", \"structured_merkle_proof\": [ { \"witness_event_verification_hash\": \"67e187411f1e514f232ae2858168da29b15ddfd07523e7a7618bfbf91c583f54fe8e850146120539a92a63ce6138f96599fb8a46ed492e428fe6fde9b9ea82ae\", \"depth\": \"4\", \"left_leaf\": \"2554fb53531f4de26ff3ad1fb8c61feea6ea47c3f13c4abda385c46ef8541361f7eee42433050281714a3900115f04fe52b5a8d781a71c4c439c5de6b91cbe3c\", \"right_leaf\": \"9dab72c7635043452958c4cc2902f48ef7c4ae437058280197c6a2736ab9635f799cbf190d9d07dd76589055a8ad64e61c6bebd1487994207d4cb7918b471f57\", \"successor\": \"789e508ccb23fe053b628cebc19a2d32f34e6aa21e878e8611f7c14d891625c7b2e243b3c3105b98295333b9183e5ea272a055a84ab65ad927f7fd9c27aae48e\" }, { \"witness_event_verification_hash\": \"67e187411f1e514f232ae2858168da29b15ddfd07523e7a7618bfbf91c583f54fe8e850146120539a92a63ce6138f96599fb8a46ed492e428fe6fde9b9ea82ae\", \"depth\": \"3\", \"left_leaf\": \"789e508ccb23fe053b628cebc19a2d32f34e6aa21e878e8611f7c14d891625c7b2e243b3c3105b98295333b9183e5ea272a055a84ab65ad927f7fd9c27aae48e\", \"right_leaf\": \"c16a966333cd22ff3497875a62202874221c1dae2e74b4351d058910f8d37160be480fce9aab4ec5e725beb695509f0fd65ae581568c6f1ae25eb4f1440b287f\", \"successor\": \"80d7549af24e9a6bdfc32cefe0536d6528d665cc8e65859ef4cff87270f3db8d9b95aaecc167e10c9b5be9ce3ab36d8d880c3a518e1c5eb899ca9d95af24e9db\" }, { \"witness_event_verification_hash\": \"67e187411f1e514f232ae2858168da29b15ddfd07523e7a7618bfbf91c583f54fe8e850146120539a92a63ce6138f96599fb8a46ed492e428fe6fde9b9ea82ae\", \"depth\": \"2\", \"left_leaf\": \"80d7549af24e9a6bdfc32cefe0536d6528d665cc8e65859ef4cff87270f3db8d9b95aaecc167e10c9b5be9ce3ab36d8d880c3a518e1c5eb899ca9d95af24e9db\", \"right_leaf\": \"f4e189a08b486253ea0a5cc7bf7150055e738898115c4caf00e45634d6925539d51852409d1fe9108469e9b15668b940f3369300bb27cc292d1fabc0c07cd593\", \"successor\": \"e227dd97e5166364483b41f058f0d176e3a50a7510299038b09ae3aef2cbafb26c787afad82563a945b433fa2d1279af3535755235ab69d6e5ab089179177c14\" }, { \"witness_event_verification_hash\": \"67e187411f1e514f232ae2858168da29b15ddfd07523e7a7618bfbf91c583f54fe8e850146120539a92a63ce6138f96599fb8a46ed492e428fe6fde9b9ea82ae\", \"depth\": \"1\", \"left_leaf\": \"e227dd97e5166364483b41f058f0d176e3a50a7510299038b09ae3aef2cbafb26c787afad82563a945b433fa2d1279af3535755235ab69d6e5ab089179177c14\", \"right_leaf\": \"780f3eb08f24022be4463be141bcda6a33a157cd0fd44cf209312b8427ac4036637a63d239526555128a4e7f4bb588ebfdbd8a8cc7d797038e29b852a4fae26c\", \"successor\": \"f3bd4e82b1e3d304005a7ddf4ab940f3e4e1cf099ca1c058454c431ed3feb0674c044e53150eb5691073ba58a3491565f72f6a6c2a24562ea080b569b4496c9f\" }, { \"witness_event_verification_hash\": \"67e187411f1e514f232ae2858168da29b15ddfd07523e7a7618bfbf91c583f54fe8e850146120539a92a63ce6138f96599fb8a46ed492e428fe6fde9b9ea82ae\", \"depth\": \"0\", \"left_leaf\": \"f3bd4e82b1e3d304005a7ddf4ab940f3e4e1cf099ca1c058454c431ed3feb0674c044e53150eb5691073ba58a3491565f72f6a6c2a24562ea080b569b4496c9f\", \"right_leaf\": \"4a0c120fbdd6219b774eb2cb2076f4050d606b621e384c3ec645be0e5dbcdac3132f1f2acb531fa5ff62429907b77cf8d29a760be3765eb4decd83949a2925f8\", \"successor\": \"14f26d7dc0be77afff9131c03cab39a2fa9e1270c6face3fdc35b9b4b4ac4550d048c356a4713568c42411c3e7fe3553ec7b993c9bd7da97cb976e843d7e4d29\" } ] } } 2nd Revision This revision entangles all data fields of the previous revision. As the calculation of the revision_verification hash depends on the revision of the previous revision, it is shown in verification_context.\n{ \"verification_context\": { \"has_previous_signature\": true, \"has_previous_witness\": true }, \"content\": { \"rev_id\": 362, \"content\": { \"main\": \"First revision text\", \"signature-slot\": \"[\\n {\\n \\\"user\\\": \\\"0xa2026582b94feb9124231fbf7b052c39218954c2\\\",\\n \\\"timestamp\\\": \\\"20220116090439\\\"\\n }\\n]\", \"transclusion-hashes\": \"\" }, \"content_hash\": \"9732084a45fd344d63687ccf9b5cd942f99ffe1debd11622b05d0cd24a2de3e5608d5f5121bdd7559c0a2d39067f9258c4f9612e44728df2e8d9026a88ed650c\" }, \"metadata\": { \"domain_id\": \"acfa9f682e\", \"time_stamp\": \"20220116090439\", \"previous_verification_hash\": \"9dab72c7635043452958c4cc2902f48ef7c4ae437058280197c6a2736ab9635f799cbf190d9d07dd76589055a8ad64e61c6bebd1487994207d4cb7918b471f57\", \"metadata_hash\": \"8df483539e2f81e64c9b9df0c7e13ae7778947b5defef860fbaed1260eade794999839bb254ea5006a5d4b6a89a37980ab576dc546d6336518d65b80bf2a5cb5\", \"verification_hash\": \"296347471b33f3d3c69cc6e0699d80b4cb68ffc79c3ecce96beb659fa324fab1de7a888932fbfb7c60bb8cc83c9445ce15532987a7b59440cada649681618293\" }, \"signature\": { \"signature\": \"\", \"public_key\": \"\", \"wallet_address\": \"\", \"signature_hash\": \"\" }, \"witness\": null } 3rd Revision This revision features a transclusion-hash for an immutable link to another revision.\n{ \"verification_context\": { \"has_previous_signature\": false, \"has_previous_witness\": false }, \"content\": { \"rev_id\": 363, \"content\": { \"main\": \"First revision text\\n\\n[[File:Logo_inblockio.png]]\", \"signature-slot\": \"[\\n {\\n \\\"user\\\": \\\"0xa2026582b94feb9124231fbf7b052c39218954c2\\\",\\n \\\"timestamp\\\": \\\"20220116090439\\\"\\n }\\n]\", \"transclusion-hashes\": \"[{\\\"dbkey\\\":\\\"Logo_inblockio.png\\\",\\\"ns\\\":6,\\\"verification_hash\\\":\\\"9b2b3cafb90a07433a2b61885a9e64641a99b1e9024cf53b640501d3706b142fed7bc372300973137ef9d92584fac70976c3889d5610abcfe1f187c248263a56\\\"}]\" }, \"content_hash\": \"14b8256ccd5fa1d883983317f92f428eadb52f699f476b9be69f14c6892b41979ff7b5b7a7a978177985d6aaa0bcfd9857a2646aedc4cbb3299373daa647814b\" }, \"metadata\": { \"domain_id\": \"acfa9f682e\", \"time_stamp\": \"20220116090556\", \"previous_verification_hash\": \"296347471b33f3d3c69cc6e0699d80b4cb68ffc79c3ecce96beb659fa324fab1de7a888932fbfb7c60bb8cc83c9445ce15532987a7b59440cada649681618293\", \"metadata_hash\": \"09688c05a83bb74bb255fb0c571cb6314b65f5b7f00750547a2c43f4959d4702ae2aec019c6fb4b0e5d23adea87fd456b0eaffc6ae271163a1fa45b4bae54230\", \"verification_hash\": \"b35894d74dfcf8b41ff95eed97705e1acf9081021e0d478d8645cb04b8a0b4a013ee8f7fb6e140d149f2c92f20bba984fad5535938a5e36ae6a799a18343b806\" }, \"signature\": { \"signature\": \"\", \"public_key\": \"\", \"wallet_address\": \"\", \"signature_hash\": \"\" }, \"witness\": null } API Endpoints The AQP provides 3 API endpoints which return data from a host that runs the AQP:\nGet Hash Chain /get_hash_chain_info/{identifier}?identifier=\u003ctitle or genesis hash\u003e\nInput:\n identifier_type: the value must either be “title” or “genesis_hash” identifier: the title or genesis_hash string, e.g. “Main Page” or “02c3c2…215d8d” Returns: all context for the requested hash_chain. Example:\nAPI Request: /get_hash_chain_info/genesis_hash?identifier=dffd37be12adc9e774b51aa712f7c5bfc09f48b083540d8ca55f91f317e8685bf09daf004f7c841e53732b8c7992de3f3b9b79350d13570c3b46803ba5119c26\nAPI Response:\n{ \"genesis_hash\": \"dffd37be12adc9e774b51aa712f7c5bfc09f48b083540d8ca55f91f317e8685bf09daf004f7c841e53732b8c7992de3f3b9b79350d13570c3b46803ba5119c26\", \"domain_id\": \"acfa9f682e\", \"latest_verification_hash\": \"2554fb53531f4de26ff3ad1fb8c61feea6ea47c3f13c4abda385c46ef8541361f7eee42433050281714a3900115f04fe52b5a8d781a71c4c439c5de6b91cbe3c\", \"site_info\": { \"sitename\": \"Personal Knowledge Container\", \"dbname\": \"my_wiki\", \"base\": \"http://localhost:9352/index.php/Aqua\", \"generator\": \"MediaWiki 1.37.1\", \"case\": \"first-letter\", \"namespaces\": { \"0\": { \"case\": true, \"title\": \"\" }, \"6942\": { \"case\": true, \"title\": \"Data Accounting\" } }, \"version\": \"0.3.0\" }, \"title\": \"Aqua\", \"namespace\": 0, \"chain_height\": 3 } Get Revision Hashes /get_revision_hashes/{verification_hash} Input:\n verification_hash Returns: the revision requested if it exists and/or a list of any newer revision than the one requested. Example:\nAPI Request: /get_revision_hashes/dffd37be12adc9e774b51aa712f7c5bfc09f48b083540d8ca55f91f317e8685bf09daf004f7c841e53732b8c7992de3f3b9b79350d13570c3b46803ba5119c26\nAPI Response:\n[ \"dffd37be12adc9e774b51aa712f7c5bfc09f48b083540d8ca55f91f317e8685bf09daf004f7c841e53732b8c7992de3f3b9b79350d13570c3b46803ba5119c26\", \"f483d7746f67e7099099bcfa8ea5a93148251c598857e8fad21ce842da62794467067802ef9e818d240cd3312a3346a769f363145a87bfc1eeae19fe8d21b328\", \"2554fb53531f4de26ff3ad1fb8c61feea6ea47c3f13c4abda385c46ef8541361f7eee42433050281714a3900115f04fe52b5a8d781a71c4c439c5de6b91cbe3c\" ] Get Revision /get_revision/{verification_hash} Input:\n verification_hash Returns: the revision content together with its verification data Example: See example above.\nAPI Request: /get_revision/dffd37be12adc9e774b51aa712f7c5bfc09f48b083540d8ca55f91f317e8685bf09daf004f7c841e53732b8c7992de3f3b9b79350d13570c3b46803ba5119c26\nVerification Process The verification process is a redo of the verification data generation process, and additionally a comparison of their results.\nVerification of Content\nAll 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.\nVerification of Account\nWe cryptographically verify that the revision signature is indeed generated by the account specified in the verification data.\nVerification of Time\nTo 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.\nReference Implementation\n Command-Line-Verification-Tool https://github.com/inblockio/aqua-verifier-js Chrome Extension Verification Tool https://github.com/inblockio/aqua-verifier-webextension Appendix The following content is informational and not part of the specification. It should help to better understand utility, context and services which can be built on top of AQP.\nAqua Protocol v1.1 Changes Moving over to revision based verification. This allows:\n Bulk / in parallel verification; ensuring logarithmic verification times, not linear increasing verification times with longer history. In short: Much faster and scalable. Single revision and range verification (you want to verify a specific part of the content-chain) This is useful for verification of identity claims, where trusted parties have signed the claim and for the validator it’s sufficient to see that signature. This allows direct verification after every edit via the Guardian. This is the preparation in the interaction to provide services through the Guardian . Changing the design to include transclusions e.g. this allows the verification of subpages via their stateful links / revision_verification_hashes This also allows the inclusion of media files in the verification process You can upload pictures, PDF’s, Word-Documents and have them automatically included in the aqua protocol and therefore in the verified data-structure Introduction of verification_context which indicates if the previous revision has signature or witness data, or if the current revision has transcluded resources. This will build the correct verification structure before verification. Change in the data-structure:\n when requesting a revision this is done via the GetRevisionHandler.php the previous verification hash is always served as well if signature or witness data is present in the previous revision, there is a flag (1/0) that this revision depends on the previous revision transcluded resources will be added to the content hash for verification Data Accounting Protocol v1.2 [TBD] Generalization of the Signature-Metadata to inform which signature method was used. GPG Signatures BTC Wallet Signatures Ethereum Wallet Signatures Done by: Displaying method used for signing, displaying underlying architecture. Including Account as part of the verified data structure Defining maximum payload size per revision Services on AQP (Not yet implemented, exploration) AQP-DACS: Domain Access Control System\n See: Guardian (Acting similar to a WebApplication-Firewall)\n ANS: Name-System and Name-Registry.\n See Aqua Name Resolution AQP-SSI: Self-Sovereign-Identity Protocol for Identity Claim management\n See Aqua Identity Protocol AQP Delegated Witnessing\n See Delegated Witnessing Similar Projects None of the listed projects apply the concepts of versioning to their documents, the concept of portable hash chains, the concept of personal data vaults for data management in comparison with the AQP reference implementation.\nThis following list is not exhaustive:\n Surety The oldest blockchain-like timestamping service which has been publishing to the New York Times since 1995. OpenTimestamp A free and open-source service provided by Peter Todd using the Bitcoin network as a distributed cryptographic clock. The AQP MAY use OpenTimestamp as a witness network. OriginStamp A company providing paid timestamping services for their customers. It looks very similar to OpenTimestamps with open-source client libraries. Factom Protocol A service which creates an architecture with an extra layer of blockchain, to provide an extra layer of trusted parties while providing their own token. In our opinion, it introduces unnecessary complexity and intermediaries as dependencies compared to the AQP. OpenAttestation An implementation of a timestamping service for document certification. One application of it is for secure digital vaccination certificates by the Singaporean government. They use the MetaMask Ethereum wallet for signing documents making it the most similar project to AQP to our knowledge. Blockchain Context DISCLAIMER: AQP is not a permissionless distributed ledger. In order for the AQP to be valuable and working, a single node implementation and single node deployments are sufficient, and do not require the witnessing part. The AQP MAY benefit from being published to a distributed ledger technology (DLT)) to achieve a witness event with high transaction security. AQP does not have a token nor is it distributing data by default.\nAs some concepts are very similar as those used in DLT’s, please refer to the following:\nA portable hash chain and its revisions are similar to a blockchain structure and its blocks, which has its own root hash and a set of transactions which are included inside.\n Blockchain Term\n AQP Term\n Explanation\n Transaction\n Input Data\n In a blockchain its a signed transaction. In AQP its all the input data provided to calculate the respective content slot hashes.\n Block\n Revision\n A block contains the Merklized list of transactions. A revision contains various hashed data inputs such as\n Content slots Metadata data Signature data Witness data Genesis Block\n Genesis Revision\n The first object in the hash chain / block chain.\n Blockchain\n Hash Chain The hash chain is not distributed but by default only in the local PKC, therefore it is not a distributed ledger. Furthermore the PKC is missing a consensus algorithm to create a shared truth between notes. A side note It has not escaped our notice that the provided AQP improves the existing process of double-entry bookkeeping and provides a foundation for a new data economy. This also allows to create unforgeable invoices which can be clearly attributed to its sender, avoiding fraud. This is one of many other use cases, e.g. providing trusted news via revision-controlled journalism.\n","categories":"","description":"High level outline of Aqua Protocol (AQP) specification\n","excerpt":"High level outline of Aqua Protocol (AQP) specification\n","ref":"/docs/protocol/whitepaper/","tags":"","title":"Whitepaper"},{"body":"The Aqua Identity Protocol (AIP) is an experimental application protocol under development for Self Sovereign Identity’s (SSIs) on top of the Aqua Protocol. This is an active field of research which is related to the work of the Decentralized-Identity-Foundation (DIF)1 and the World-Wide-Web-Consortium2. As this is under active development, anything you see is experimental and subject to change. The goal is to provide a Self-Sovereign-Digital Identity Protocol to protect individual rights, freedom and the opportunity for the individual to participate in the digital economy.\nWe are building on the advancements and insights for rebooting the web-of-trust initiative3 and the definition of a Self-Sovereign-Identity provided by Christopher Allen in shortened form here.4\nSelf-Sovereign-Identity-Principles Existence: users must have an independent existence. Control: users must control their identities. Access: users must have access to their own data. Transparency: Systems and algorithms must be transparent. Persistence: Identities must be long-lived. Portability: Information and services about identity must be transportable. Interoperability: Identities should be as widely usable as possible. Consent: users must agree to the use of their identity. Minimization: Disclosure of claims must be minimized. Protection: The rights of users must be protected. Those 10 stated principles are implemented within the Aqua Protocol and it’s existing reference implementation in various degrees. They are also represented in the Design Principles .\nArchitecture For the Aqua Identity Protocol to be implemented in accordance with the above statements, SSI-Principles and critical component choices from outside the protocol need to be made, and required tools need to be provided. Data Vault’s will provide a space which is fully account controlled. Other architectural decisions enabling SSI can be found in the reference implementation PKC Architecture Documentation.\nUsage of Data Vaults to protect identity claims Pages with the namespace : must be ‘read and write able’ by only by default. This is to protect the personal-identifiable data of the user. This data should be stored in a place where only the account owner has access to. This can be achieved by having the data stored locally on a machine the account owner has, or by using cryptography which requires the account’s owner explicit interaction to decrypt it. The content should not be decrypted on the server, but within the web-browser or client-application to ensure that a potentially compromised service-provider can’t leak the sensitive information.\n Identity claims are encrypted by default and can only be decrypted by the account owner or other accounts explicitly given permission to do so. Identity claims must be given access by the account owner to e.g. let somebody else sign them. Note: There should be an extra effort by any Data Vault implementation to protect identity claims. It is recommended to strongly regulate and audit the emerging solutions to ensure a high level of protection for citizens.\nSelf Issued Identity Claims These are used to make statements about an account to form an identity. Those claims can be partially revealed on demand to other parties. Those claims can also be protected by advancements in privacy technologies like Zero-Knowledge-Proofs and ongoing advancements in key management.\nIdentity claims are sets of Verified Data which follow a structured data convention to claim or attest attributes to an account. For example, an attribute could be the year of birth of an account owner, or the legal name of an account owner. Claims should always be atomic to allow the account owner to disclose them selectivity. Different claims can be combined to represent a citizen ID or a drivers-license. Other claims can be educational certificates, like school certificates.\nIdentity claims in the Aqua Identity Protocol are always self issues. This means that the first signature on the claim needs to be from the private key which belongs to the account, i.e. the claim is issued for. This proves account ownership. This means:\n All claims can only be issued from the account which they make a claim about. A claim belongs to it’s origin account and can only be managed from it’s address. A claim can ‘accumulate trust’ by being signed by other accounts who support this claim. Self-issuance protects accounts against spam, and the issuance of fraudulent claims to an account without the knowledge of the account owner. Claim Attestation Can be completed by a Trust Authority referring to the Identity Claim in collaboration with the account owner, or a referencing statement.\nIt is possible to attest to a claim by referencing the claim’s unique revision_verification hash within the attestation. This means you can make statements about an account or about a claim without involving the account owner in that process. An attestation contains a statement about the referenced data set, and is expected to be signed by the account who makes the attestation. This ensures there is clear account attribution. Attestations without signature should be disregarded, as they have no account attribution.\n Specification for the Aqua Identity Protocol Policies for Self-Issued-Identity-Claims:\n Syntax of Title: \u003cAccount (e.g. Ethereum Wallet Address)\u003e:\u003cAttribute (English Descriptive Title)\u003e Example: 0xa2026582b94feb9124231fbf7b052c39218954c2:Birthdate The title is not protected against changes, but the content of the page is protected.*IMPORTANT: Therefore, we must compare the page stored ,. Then reassemble the title to check if they are consistent before proceeding with further validation of the identity claim.\nContent of the page\n Account: Is repeated to reassemble the title to check it. Attribute: \u003cattribute_name\u003e Is repeated to reassemble the title to check it. Value: Is the value of the claim. E.g. ‘1889’ for a year of birth. The first revision must be signed by the account owner to create a self-issued identity claim Values must not change within a hash-chain. If a value changes, the claim will be marked as invalid with the revision of the change. If a new attribute value needs to be defined for an account, this is done through a new claim. Claim issuance Process\n Claim is created (based on template) Claim is signed by issuer (first revision) Claim is registered by issuer (optional, done via Claim Registry) Claim is verified by authority to accumulate trust (this might include the requirement to hold a revocation authority on a claim registered via a Claim Registry) Trust-Chains with Identity Claims\nWill build a web of trust, which can be applicable not only for public institutions, but also for commercial organizations and private entities.\nA trust chain of identity claims for educational certificates (example) The certificate is issued as integrity verified data via the Aqua Protocol. The recipient of the certificate registers the certificate as an identity claim The certificate is signed after it was issued as an identity claim by a Trust Authority (e.g. the university professor) and the university director’s office (director) The university professor holds trust claims from the university director The university director holds trust claims by the ministry of education The educational ministry of education holds trust claims by the minister-president The minister-president holds trust claims of a verified election The chain of trust is supplied by the party signing the statement.\n IMPORTANT: The authority who is given authority needs to prove where their authority originated when they act in the function of that authority.\n E.g. the professor needs to supply the claim of the university entitling him E.g. the university director needs to supply the claim of the educational ministry E.g. the educational ministry needs to supply the claim of the minister-president. … and so on. Verification Process Claim is presented Claim integrity is validated How can you trust the content of a claim: Claim content needs to be static. E.g. a given-name claim ‘Jarred Maxim’ cannot change, even if there are many revisions to the page. If the static content HAS changed, the claim is INVALID or at least only valid until the point where it changed. In the case of such an information change, a new claim needs to be issued. Claim registry is validated (root trust) Claim signatures are validated Comparison between signature time and validity of the signing authority. Is the account authority still valid? lookup of authority claims from expected root trust? Trust in Signatures If somebody signs an identity claim, we believe they do that to\n Vouch with their account for the integrity of the presented data. This can be supported via an Authoritative Claim and a comment which gets attached to the claim itself or is issued via an Attestation. To verify the signature, we use an automated verification process. This is done through implementations of an Aqua-Verifier like https://github.com/inblockio/aqua-verifier-js or https://github.com/inblockio/aqua-VerifyPage-chrome-extension which also checks against the restrictions given by the Aqua Identity Protocol or/and additional defined policies. Add access rights to a claim by adding a Data Usage Agreement which is enforced by the Guardian. Access rights can be restricted: to specific accounts to specific domain id’s representing an instance of a Data Vault Verification: The verification process considers which account it signed, and what was stated with the signature, or with the additional data added to the claim. To consider a claim valid, the relationship between the verifying party and the Trust Authority who signed it, is essential. Can the party be trusted? Why do I trust this party? Claims can be either chained (cascaded into each other) and offline verified, and/or online verified against an existing Claim-Registry. In both cases a known trusted party account reference point is required for the verifying party to trust. Trust Authorities are accounts which have an elevated trusted position. They issue Authoritative Trust Claims to give legitimacy to a self-issued identity claim.\nWhy do you trust a professor to issue an Educational Certificate ?\nBecause the professor is able to provide a trust chain, represented by a chained Authoritative Trust Claim , proving that he has authority to attest an Educational Certificate with his signature. With his signature, he is increasing the trust of the self-issued Identity Claim to allow it to have practical utility.\nClaim Registries A claim registry in the context of the Aqua Identity Protocol is a global registry to allow for real-time global claim revocation and re-instantiation of Identity Claim’s. This solves the problems related and known to certificate revocation. The Claim Registry acts like a global Claim Revocation List (CRL)5.\nE.g. a driver’s license can be revoked by a Trust Authority and later be re-instantiated after the ‘Punishment for driving too fast’ is over. Identity claims are either valid or invalid. The Claim Registry is managing who can revoke / re-instantiate a registered claim.\nThere is ongoing research and optimizations on privacy concerns to reduce costs for on-chain Identity Claim.\nImplementation in Ethereum with Smart-Contracts (Solidity). All claims are account bound.\nClaim Registration Specification - Smart Contract Structure\n \u003crevision_verification_hash\u003e as root trust of the self-issued identity claim. A claim has to be a verified page, which is signed and timestamped. If all are present, the next page-verification hash entangles all of those properties and becomes the ‘address’ of the claim. In the receipt of the publish process for the claim, there is an attached receipt, and by writing the receipt into the claim, there is also a new revision generated. This creates the second revision of the claim, which entangles the signature and the witness event with the hash-chain to make them immutable. [type:boolean] of claim 0 - valid 1 - revoked [type: date DDMMYYYY]: if current date past expiration date, the claim is considered expired and is not accepted anymore\n \u003c owner == sender address\u003e [type:address] an account which updates the status of the claim, e.g. revocation or suspension of an account\n \u003c additional revocation authority\u003e [type:address] list of accounts which are authorized to update status of the claim other than the owner. The owner has a special right to update the list of revocation authorities to hold new addresses.\n EXAMPLE: Claim Registration Data [Receipt]\n The presence of Claim Registration Data [Receipt] means that the claim address (verification hash) has been written to a Claim Registry on a Witness Network.\nProtocol: Aqua Identity Protocol Version 1.0\nRegistration Event: 1\n Domain ID: e9ece84189 Claim address (verification hash of self-signed claim): 1db331add502cf1b1712468d1c3e5d66a0016a6f04885c5533619ffbb43fffb6dfa452e119d4bee7628e9792af69089d38d860a5f8d0708184bbb74b8cabdaf7 - Merkle Root: 7e9782fb8a6e749ef2ba48f8cd410b05335ba48b20ba42508efeb76add38b0f39e717e91381c8de34641af4c477c39fc169eaa0908dba25e0a54e8de615fcd00 - Claim Snapshot Verification Hash: 278f930a35d06d7b9d28aab37d402c147d1beffdbe53d212481c17ec686698e9469f9cf7d7d53b9a4435c4b99ca2e578b5dc5fec6c63cb802b540493fe927575 Witness Network: goerli Claim Registry Smart Contract Address: 0x45f59310ADD88E6d23ca58A0Fa7A55BEE6d2a611 Transaction Hash: 0xa572e8d6ef8d4a1bb3b5087680817e70bb79a0376c3a9be9e2c6b4d92df228a1 Sender Account Address: 0xa2026582b94feb9124231fbf7b052c39218954c2 Claim Revocation Traditional revocation:\n Traditional strategies for certificate revocation can be applied.6 Most effective are short expiration dates where possible, due to the lack of effective revocation processes for certificates without global registries. Using Distributed Ledgers\n Done via Claim Registry (indicates the global status of an identity claim to be either valid or invalid) Process:\n Locally completed (within the Self-Issued Identity Claim) by changing the status to ‘revoked’ and signing by the issuer. This adds a receipt to the identity claim, which is displayed when verifying the claim. This includes the revocation transaction for the revocation on the Identity-Registry If there is a new claim which is succeeding the previous identity claim Claim Registry , then this is also noticed within the revocation receipt under ‘Successor-Claim: . Bulk Claim Registration (Should be part of Claim Registry)\n To reduce costs during registration of the identity claims via a Claim Registry they can be clustered and registered together We use the SmartContract:Identity-Registry for this. To scale our efforts we utilize a variant of the ‘Domain-Manifest-Generator / Publisher’ which is very similar. The differences are in the selection of what can be published, and the data structure which is published to the Claim Registry instead of the witness smart contract. The Claim Snapshot Generator can only include ID claims of your own namespace. The Claim Snapshot Publisher is registering all selected claims (select them by page name (filter required) and will populate the target SmartContract:Identity-Registry . Every claim will hold the relative merkle-proof to show the path for it’s registration. Examples for Identity Claims with Aqua:\n Example Identity Documents with PKC and Data Accounting Reference:Example Identity Documents (Research) FAQ How to find Claim Registry ’s? By following the chain of trust of authoritative claims and validating them one by one. How to check if authority is still valid and how to find an authority registry? As before, by reading the chain of trust and looking up the status of the related identity claims. How to visually check authority dependencies? It is possible to visualize the links of links of links to represent the chain of trust. Important References:\n Basic intro into DID Basic intro into DIDComm W3C Verified Data Model Revocation List 2020 A privacy-preserving mechanism for revoking Verifiable Credentials DIDCOMM implementations and use-cases DIDkit Thought leader Christopher Allen:\n Self-Sovereign-Identity-Principles A bitcoin based SSI infrastructure prototype See Implementation Specific Aqua Identity Protocol Implementation in MW e\n https://identity.foundation/  ↩︎\n https://www.w3.org/  ↩︎\n https://www.weboftrust.info/  ↩︎\n https://github.com/WebOfTrustInfo/self-sovereign-identity/blob/master/self-sovereign-identity-principles.md  ↩︎\n https://www.securew2.com/blog/certificate-revocation-crl-explained  ↩︎\n https://social.technet.microsoft.com/wiki/contents/articles/34071.pki-certificate-revocation-process-explained.aspx  ↩︎\n ","categories":"","description":"Shows how it is possible to build an identity protocol on top of Aqua using data vaults.\n","excerpt":"Shows how it is possible to build an identity protocol on top of Aqua using data vaults.\n","ref":"/docs/protocol/aqua-identity-protocol/","tags":"","title":"Identity Protocol"},{"body":"This section of documentation gets into specific details about the AQUA Protocol and is meant for those doing an implementation or contributing to the Protocol itself.\n","categories":"","description":"Low level reference documentation of the AQUA Protocol\n","excerpt":"Low level reference documentation of the AQUA Protocol\n","ref":"/docs/protocol/","tags":"","title":"Protocol"},{"body":"","categories":"","description":"Details various software that is implementing the Aqua Protocol\n","excerpt":"Details various software that is implementing the Aqua Protocol\n","ref":"/docs/implementations/","tags":"","title":"Implementations"},{"body":"ANS is used to resolve hashes of various types to human readable names.\nThe following hashes are resolved by the ANS:\n wallet-addresses to names, organisations an aliases. genesis_hashes to titles. domain_ids to registered endpoints of that domain. See the reference implementation .\n","categories":"","description":"ANS is used to hashes of various types to human readable names\n","excerpt":"ANS is used to hashes of various types to human readable names\n","ref":"/docs/protocol/aqua-name-resolution/","tags":"","title":"Aqua Name Resolution (ANS)"},{"body":"How safe are the wallets to used? - Current PKC Pilot - relating to the ‘Authentication assurance level’s (AAL)’ according to the World Bank standards:\nSee short presentation Aqua_PKC_-_Wallet-Security.pdf Level 1 The Metamask wallet alone has a low (level 1 ) level of assurance. MetaMask is the most common browser blockchain wallet applications on the web and their developer teams strive for increased security to keep crypto-assets of their 10 Million+ Users safe.\nLevel 2 Metamask offers integration with Hardware-Wallets which raises the level of assurance by having at least 2 authentication factors (e.g., a token with a password or PIN) to min. level 2. The Hardware-Tokens are build to be temper proof.\nLevel 3 It is possible to integrate the different layers of security at once with Metamask (Password Protection) a hardware-token (temper proof) with PIN a one-time-password generator based on your mobile-phone (recommended is a hardened mobile phone which also uses biometrics for highest security) requires implementation of one-time-password authentication for logins after wallet-authentication see https://github.com/inblockio/micro-PKC/issues/37 Other high security options allow multi-signature logins with smart-contracts requiring multiple parties to confirm the operation to be executed. This can be defined based on the smart contract to extreme security as each of the layers mentioned above can be added to each party being involved in the multi-signature event to open a PKC or to SIGN a verified page within the PKC or to witness a data set via a witness network.\n The mentioned security model is not dependent on the security of Metamask. If Metamask is hacked it will not allow to compromise the model above as the security of the private key of the hardware token is preserved.\n ","categories":"","description":"Highlights the levels of assurances you can receive by using technology provided in the Aqua reference implementation. \n","excerpt":"Highlights the levels of assurances you can receive by using technology provided in the Aqua reference implementation. \n","ref":"/docs/protocol/assurance-levels-aal/","tags":"","title":"Assurance Levels (AAL)"},{"body":"We first exchanged goods, then we used means to exchange goods, such as shells and coins. Today we use money. We have transitioned to a world where we present and exchange data to receive goods and services.\nThe system for accounting provided by Luca Pacioli, the double-entry accounting is the foundation of our work. We present a modern way to do double-entry bookkeeping for data.\nData accounting is the process of metering data in a standardized unit of exchange, and converting it into a form which can be exchanged to provide data symmetry between accounts.\nThe unit of exchange is not measured in a numeric value as found in cash systems. Data have multi-dimensional value, which means they depends on your perspective and your relationship to data. This determines how much this data-set is worth to the individual.\nThe standard measure of exchange is a hash, representing the state of the data. A SHA3-512 hash always has 128 characters, regardless of the size of the data it is representing.\nMetering data / anchoring data in space To meter data, we can refer to them using a digital fingerprint, i.e. their hash. This allows us to refer to the data in a consistent form. The hash has captured sufficient entropy to be unique, so it becomes a unique resource locator. This ensures that it is always deterministic to what data we relate to.\nAccounting data / anchoring data to account The second step is that the data is attributed to a specific account. This is achieved by using cryptographic signatures known as public/private key encryption . The public key acts as a unique account address. It is necessary that the accounts in use are globally unique, so there is no realistic probability of a name collision between accounts. This ensures that no data is attributed by mistake to two accounts or more.\nProof of existence / anchoring data to time The last step to account data is the usage of a cryptographically secure clock, so we know which data were witnessed first. Data can be replicated, so the value lies within the social implications of the message within the published data. This cryptographic timestamping allows us to determine the first account to witness the data. The most secure witness-networks which provide a service for cryptographic witnessing of datasets are Bitcoin and Ethereum. The first known examples of partial data accounting were done by Surety in 1995 and OpenTimestamps in 2012 .\nPractical accounting The accounting book in the data accounting age is a ‘data vault’ which is controlled by one or multiple accounts. This allows both personal data vaults or organizational data vaults.\nA data vault is controlled by a cryptographic wallet. The vault has the objective to govern the data for the account owner who is associated with the vault.\nThe vault provides a capability to export and import data, so it can be exchanged between data vaults. This allows for collaboration at scale, and the usage of data as a means of exchange.\nPlease contribute to this article (fixing errors) by exporting it and sending it back with your improvement to community[at]inblock[dot]io.\n","categories":"","description":"Introduces the concept of Data Accounting\n","excerpt":"Introduces the concept of Data Accounting\n","ref":"/docs/protocol/data-accounting/","tags":"","title":"Data Accounting"},{"body":"Author: Ben Koo E-Mail: koo0905[at]gmail[dot]com Year: 2021\nData Governance identifies how to manage the value of data. A well-known turning point in history was the publication of Luca Pacioli ’s Summa de arithmetica . This encyclopedia of mathematics, had 26 pages worth of text on what we call Double-entry bookkeeping . This became the foundational literature for accounting , the progenitor of using data to assign value to accounts, and henceforth gave birth to the practice of data governance.\nAccounting as the foundation of Data Governance According to historian Jane-Gleeson White12, Pacioli’s double entry book keeping idea influenced the development of arts, sciences, and capitalism. Double-entry bookkeeping as a rigorous approach to ensure data integrity, not only influenced the practice of the accounting profession, and it had a significant impact on the the formulation of Hamiltonian Mechanics , which is a foundational theory of both classical mechanics and quantum mechanics.\nSir William Rowan Hamilton wrote a paper3 cited many many scholars to demonstrate that many ideas about complex algebraic manipulation that laid the foundation of scientific revolutions are based on the formulation of creating accountable mathematical formulation strategies through double entry book keeping. David Ellerman had a paper that explains the powers of double entry bookkeeping in sciences4. The notion that creating public addresses for transactions amongst different accounts has been documented as a scientific theory on Double Entry Book-keeping. This book can be found online5:\nDigital Governance Given the intellectual roots of data governance have strong linkages to mathematics and accounting, it is only after the introduction of personal computing devices , and later the ubiquity of Internet access that made data governance an idea relevant to public affairs. The argument is that many people’s basic privacy and property rights may be challenged by people who have access to data collection and deployment technologies. Imminent threats such as fake news, big brother monitoring practices, identity thefts, and crypto currency issuance are already challenging the stability of the existing social fabric. These type of social debates are often related to the ideas of Digital governance . At this time, digital governance has not yet become a mature field of study, and it needs to be grounded in simple principles, so that it can be transparently practiced with local adaptations.\nConceptualization of Data Governance Beside the notion of digital governance, data as an asset class must be kept accountable, so that it can be evaluated, and transferred with an objective operational framework. Knowing how to organize data in formats that satisfy consistent abstraction strategies, such as Universal Resource Identifier and Universal Resource Locator are important starting points in this field. Earlier work in data governance in a web of hyperlinked media can be traced back to Project Xanadu by Ted Nelson .\nMore recent more publications in this fields are Lessig ’s Code v2 6 and soon to be published work of Alex Pentland ’s Building the New Economy 7.\nReferences J. Gleeson-White, Double Entry: How the merchants of Venice shaped the modern world–and how their invention could make or break the planet, publisher Allen \u0026 Unwin, ISBN:978-1-74175-755-2 , November 2011 ↩︎\n J. Gleeson-White, SIX CAPITALS, or CAN ACCOUNTANTS SAVE THE PLANET?, publisher Allen \u0026 Unwin, ISBN-10:9780393246674, February 2015 ↩︎\n Hamilton, S.W.R. (1837) Theory of Conjugate Functions, or Algebraic Couples: with a Preliminary and Elementary Essay on Algebra as the Science of Pure Time, Transactions of the Royal Irish Academy, 17pp. 293–422. ↩︎\n David Ellerman, On Double-Entry Bookkeeping: The Mathematical Treatment, https://arxiv.org/pdf/1407.1898.pdf  ↩︎\n J.C. Colt, The Science of Double Entry Book-keeping, online media: https://core.ac.uk/download/pdf/56693696.pdf , last accessed: May 4th, 2021 ↩︎\n L. Lessig, Code: And Other Laws of Cyberspace, Version 2.0, Publisher: Basic Books, 2nd Revised edition, December 2006 ↩︎\n Alex Pentland, Alexander Lipton, and Thomas Hardjono, Building the New Economy, MIT Press, Work in Progress, https://wip.mitpress.mit.edu/new-economy  ↩︎\n ","categories":"","description":"Introduces the concept of Data Governance\n","excerpt":"Introduces the concept of Data Governance\n","ref":"/docs/protocol/data-governance/","tags":"","title":"Data Governance"},{"body":"Describes the process of sending a domain snapshot to a remote data vault for witnessing. The domain snapshot is then included in the witnessing event and sent back to its original data vault. This makes the domain snapshot behave like an ordinary portable hash chain that can be witnessed. The relative path of the Merkle proof is used as a prefix for all other included portable hash chains included in the domain snapshot.\n","categories":"","description":"Describes the process of sending domain snapshots to remote data vaults.\n","excerpt":"Describes the process of sending domain snapshots to remote data vaults.\n","ref":"/docs/protocol/delegated-witnessing/","tags":"","title":"Delegated Witnessing"},{"body":"The following design principles pertain to Aqua reference Implementation PKC\nPrivate is Default The principle default to private is that no data of the PKC Data vault is shared without it being explicitly authorized by the associated account.\nDomain Access Levels Levels of access are:\nPrivate: Only the account owner has access to files and services initialized by his account. Agreement / Permissioned access: The Account owner grants other Account’s access to files or services based on verifiable contracts which are themselves written with the Aqua Protocol to ensure they are forgery-proof and therefore safe. Public: Other Account’s have access to the file or service without agreements.\nOffline Capability The PKC Data Vault follow’s the principle of being able to run and be functional without internet connection after setup or through installation based on local installation files.\nThis allows PKC setups to be kept offline from any internet connectivity while still functional. This can provide the required assurances for very sensitive data.\nSeparation of Account and Service Concern: There is a trend in the DIF/WC3 Identity space that some players like to accumulate personal identifiable data (PII) inside of Wallets. We think this is a ill-fated direction and there should be a clear separation between account and service. Wallets should not hold personal identifiable data.\nBenefits:\n If the service gets hacked, no account related data is leaked if it’s not stored. Account is not compromised, as there is no password saved within the service with Password free login. Wallet ’s have one job. Keep private keys safe! (Account Management) Should be stupid, simple, safe! Allowed operations: Signing De- / Encrypt Publishing transactions to service (e.g. witness networks) Ability to choose “high level of assurance” depending on the stakes associated with the account(s) managed by the wallet Takes care of key recovery mechanisms Data Vault (Service)- Has one job: keep the data safe! Principle: Offline Capability so it can run offline; works offline on local machine All significant actions authorized and managed though the wallet Should offer good tooling for data storage and manipulation Strong access control: By Principle: Default is Private which means data is only accessible by the owner. Data is well protected The Data Vault should apply additional security features to keep the data safe. e.g. Encryption of files / databases if service is not used. e.g. Encryption of pages with web-decryption (allowing for End-to-End Encryption). Capabilities for sharing and publishing data Offers full Backup and Recovery mechanisms to move data freely Principle: Data Portability Signature Login We do not use passwords for login but instead we use a signature of a private key to authorize access to a service. This increases security and does not require the user to remember a password, creating a better user experience.\nPros:\n* Account owner uses his wallet to complete a signature challenge for login. With this challenge he proves that he owns the private key to a public key. If the public key is registered as an account at the service, the account is granted access.\n The password can’t be leaked as it does not exist. Very high security Contra:\n* Requires access to the wallet which holds the private key to authorize access\n Not commonly understood by users as a way to login (new process) Principle: Data Portability The Principle of Data Portability means that the Account owner can instruct the Service to Export all data associated with the Account and is free to move this data to a new service which is capable of importing the data.\nImplementation Specifics In PKC’s this is guaranteed by:\n* providing a Backup and restore procedure which allows to move data between PKC’s and restore them in case of a required recovery.\n providing a file import and export function providing an import / export API Furthermore we ensure with the development of the MediaWiki Data Accounting Extension, that the data is still compatible with the legacy import / export (which means only the text not the verification data is imported / exported.\n","categories":"","description":"Lists the design principles underlying our reference implementation\n","excerpt":"Lists the design principles underlying our reference implementation\n","ref":"/docs/protocol/design-principles/","tags":"","title":"Design Princiciples"},{"body":"Context It is highly problematic to expose sensitive data, such as personal identifiable data, to the internet. The service who hosts that sensitive data, needs to be compromised only for a short amount of time, to leak all the data. Often caused by configuration mistakes or by vulnerabilities being present in the used technology stack.\nWe can’t effort to have leaks on personal-identifiable data in data vaults. To raise the bar on making attacks difficult and reducing the chance of leakage of information, we introduce the Guardian as a extra security layer to protect services like the PKC from attacks.\nSummary The Guardian is a software which manages the boundaries of your digital domain. Guardians are used to connect to secure transport networks (HTTPS, Matrix Network, Didcomm) and publishing networks (e.g. Swarm.eth). The Guardian is used to build trusted connections to other Guardians via trusted transport-layers to exchange data with them. As the Guardian connects to other Guardians, it also manages all connections to services in it’s domain and access to those services.\nGoal Secure all services behind the Guardian from attacks and unauthorized access. Keep the data vault and it’s data private and safe, while enabling the ability to exchange data with other Guardians.\nHow Enforcement is handled on each connection and each data set so that services behind the Guardian are never directly exposed. This makes the Guardian the most security sensitive component in the Aqua reference implementation, as we expect the Guardian to handle all incoming and outgoing traffic. The Guardian enjoys additional attention and effort to be up to it’s task by hardening it and applying security best practices to ensure that it is fulfilling it’s security promise to keep services behind the Guardian safe.\nEvery transaction leaving or wanting to enter your domain will be supervised and checked by the Guardian. The core functionality of the Guardian is a library to verify the Aqua Protocol. Only if the verification succeeds additional steps are introduced to make decisions how the data is handled.\nThis allows the Guardian to read and understand Aqua verified data. This allows for the implementation of a wide set of behavioral rules and offers the opportunity to create various ‘Smart contract’ languages on top of it.\nThe Guardian verifies a file, reads its contents and checks it’s permissions to classify if an action is considered legal or illegal, permitted or denied. Basic functionality for a Guardian can be compared with a traditional firewall, or a application firewall but is much more sophisticated to manage access on the data-level.\nTerminology: Proving ownership over a domain by signing the domain ID with an self-issued identity claim which is also registered in a claim registry to ensure nobody claims to have owned that domain before by manipulating the digital clock and faking an earlier owner-ship claim over the domain.\nPermission Agreements / Data Usage Agreement / Access Rights are contracts which represent the terms and conditions under which files and/or services are shared with other accounts and/or their digital domains.\nBy nature those Permission Agreements will be compiled through pages and stored as files. To form an agreement, the other party must be notified about new resources as they become available. For example, when we share a page with another account. To complete a permission agreement, the counter party has to sign the permission agreement or reject it. If the permission agreement is signed, the other party enters a contractual relationship in which they will be liable for any agreement violates executed from their digital domain.\nProcesses Domain Handshake Establish trust between two Aqua domains. For this we have Alice and Bob which want to establish trust between their domains. They both have a Guardian in place to protect their data vaults.\nSteps:\n Alice: Create access contract: I \u003cAlice_account\u003e want to connect from my \u003cdomain_id\u003e to a \u003cdomain_id\u003e controlled by \u003cBobs_account\u003e with my \u003calice_domain_id\u003e via the following channel: DNS/HTTPS via \u003calice_Guardian.domain.com\u003e. Alice: sign contract Alice: SEND contract send the page via ‘mail’ / ‘matrix’ whatever to the remote PKC instance. Bob: veries the contract contract and imports it Bob: extend contract: I \u003cbobs_acocunt\u003e connect my PKC \u003cbobs_domain_id\u003e to your PKC \u003cAlice_domain_id\u003e via my Guardian_endpoint \u003cbobs_guardian.domain2.com\u003e. Bob: sign extended contract: Bob uses his wallet to sign his extended contract. Bob: send extended contract TO Alice: Bob sends his Contract to his Guardian. Bob’s Guardian: Verifies and sends the contract to Alice Guardian. Alice Guardian: Guardian verifies all data Sends OK back to Bob’s Guardian Sends Updates contract into Alice PKC Waits for Bob’s Guardian to request available pages Bob’s Guardian requests a list of pages: ' What pages do you share with me?' Alice Guardian: Returns list of accessible resources for Bob Example: Sharing a File Target: Sharing a file with another account. Using two Aqua data vaults with their two Guardians to manage access to them. We assume the Guardians already have executed a handshake to enter a trusted relationship. We also assume, that the file should underlay access basedon account restrictions and domain restrictions.\nExample 1: Sharing a file without additional constrains with another account.\nAlice wants to share her page ‘My secret research’ with Bob. Their Guardians have already formed a trusted connection. What Alice needs to do now is to add a sub-page with an immutable link under the ‘My secret research’ page and define access. To be able to define access Alice needs to have a claim over the ownership over the domain she is sharing from.\nAlice creates an Access Permission for the whole page or for a single revision by creating a page with the following syntax:\n \u003cgenesis_hash\u003e:access_contract\n To give access to the whole page with all it’s revisions.\n \u003crevision_hash\u003e:access_contract\n To give access to a specific revision.\n Content of the page:\nI Alice give access to Bob \n option 1: to the whole page including it’s history \u003cgenesis_hash\u003e option 2: to the following revision \u003crevision_hash\u003e‘My secret research’ Additional one-sided conditions:\n This access contract expires in 7 days This contract will come into place with my signature.\nThe Guardian will react to a specific syntax of pages holding contracts, agreements and access rights to adjust his network access rights accordingly to it. Alice-Guardian will respond to the question what resources are shared by Bobs-Guardian with the answer that there is a new page available according to the access contract which now gives Bobs-Guardian the ability to query the content of ‘My secure research’ from Alice according to the contract. Depending on Bobs-Guardian setting, the Guardian might automatically load the resource and forward it into the post-box of Bobs Data Vault.\nExample 2: Sharing a file with constrains forming a contract to do so.\nSame as 1 expect that for the contract to come into place, Bob needs to sign the contract from Alice containing additional constrains.\n Content of the page:\nI Alice give access to Bob \n option 1: to the whole page including it’s history \u003cgenesis_hash\u003e option 2: to the following revision \u003crevision_hash\u003e‘My secret research’ Under the following conditions:\n Do not share outside your domain \u003cBobs-domain_id\u003e Do not share with any body else (Bobs domain can’t have another account registered to it, if there is an account registered the Guardian of Bob will say that Bobs domain does not fulfill the requirements to establish this contract. Do not modify it. Delete it after 7 days. For this contract to be valid, signatures of first Alice and then Bob need to be present. This means, after Alice signed the access contract, the contract is a new available resource to Bob to be loaded. Bob can now sign the resource in his domain and return the contract. Leading to the contract send back to Alice domain and being updated there. Bob now gets access to ‘My secret research’ which has been updated as well, to contain via an immutable link the access contract.\nPermission Templates, Complex Permissions (Groups and more)\nIt is possible to apply complex permissions based on templates, or and connecting multiple access contracts by using\n instead of this syntax \u003cgenesis_hash\u003e:permission_agreement the following the syntax \u003cgenesis_hash\u003e:\u003cgenesis_hash-2\u003e in which the \u003cgenesis_hash-2\u003e contains a list of sub-pages with access contracts which can be used to apply access via permission-objects which are represented by the \u003cgenesis_hash-2\u003e page object. Alice wants to If the user wants to propose changes to the page, he will send an updated PAGE FILE to the OWNER of the PAGE. The owner can decide to ACCEPT the changes. Or to include the changes in the HISTORY File, but not COMMIT them. Or to NOT include the update of the PAGE, and disregard it. Specifications: The Guard Daemon checks if there is digital contract present in his domain. Those contracts set permissions for allowing a counter party to access a service or resource (like a file or a page, or a revision). It’s also defining the constrains under which permissions access is given. In this case it requires the digital signature of the receiving party for the agreement to come into place and be valid.\nGuardians have administrative access to the services they manage. Therefore they can supervise the activities of services and use them as triggers to e.g. provide access according to a set permission without additional user action.\nGuardian Components: APIs\n System-API to control a service via a service specific library. Each services will have their own control-library and control API to create an abstraction layer which allows for a unified control logic in the Guardian.\n E.g. an account is allowed to access a service E.g. a resource is shared with an account E.g. a trust relationship between two services is established (based on an agreement between two accounts) to exchange data Implementation Specific PKC: All interactions for system interaction with MediaWiki / PKC Execute Actions: Move, Update, Edit, Delete Pages Request send to the Guardian: Verify a specific page or a list of pages Data-API to retrieve Aqua-Data between a service and the Guardian, or between two Guardians.\n Send data to import API Read data via export API Implementation Specific PKC: Read special Pages used to give access e.g. Data Usage Agreements, Permission Agreements Aqua Verification Library to be able to verify incoming and outgoing data\n implementation of the ‘external-verifier’ in e.g. GO, Typescript or Javascript (current) Account-Registry (Holding the list of trusted keys and the relationship between them)\n This includes defined ‘trusted accounts’ Session-Handler/Registry (Acts like Stateful-Firewall on the page-object level to mange imports / exports). The Guardian verifies incoming and outgoing data and constructs sessions based on it.\n Guardian Policies: Are sets of rules followed and enforced by the Guardian. This includes set of rules used to protect the domain from unauthorized operations and access. Part of that are page access permissions which are managed by the Data Usage Agreements .\n \u003cdomain_id\u003e\u003cgenesis_hash\u003e\u003crevision_hash\u003e:\u003cdomain_id\u003e\u003cgenesis_hash\u003e\u003crevision_hash\u003e Transport Layer API’s / Sub-Modules for connectivity to distributed services\n The Guardian-to-Guardian communication handler (via DNS/HTTPS transport) Ethereum Integration, Ethereum Handler (As a witness Network) Matrix Integration, Matrix Handler (As a restrictive/ permissioned transport layer) Schwarm Integration, Swarm Handler (As a publishing network) Guardian-Integration-Services The Guardian has a modular design to support integration with many services and transport layers.\nWeb (HTTPS / DNS) Integration Goal: Have a handler to connect web-facing Guardians with each other in a safe way. Be able to run guardian procedures via two public Facing guardians which use a public DNS name and HTTPS to interconnect with each other. Guardian procedures are: Guardian handshakes to establish trust or remove trust Request or Send portable Hash-Chains based on access rights between each other\nEthereum Node Integration Goal: Connect to a self-hosted or remote Ethereum Node. Option 1: Configuration via Alchemy (Providing Keys) via Special:DataAccountingConfig Option 2: Implementation of Ethereum Node via ./setup –ethereum-node (provide container) Configuration of Connection to RPC Ethereum node via address (if in same network) The Wallet can be directly be connected to a local Ethereum node via RPC to avoid meta-data gathering of large providers, like INFURA which could potential track which IP address has created which Ethereum Transaction with which Metamask-Wallet, leading to a de-pseudonymousation of the user. ### Ethereum Node Handler Goal: Accelerate lookups of the Guardian via caching Every-time a witness contract is called, the Ethereum Node Handler will start to cache the all Ethereum-Witness events of that Witness-Contract and Index them in it’s database. This will reduce access times to ms vs potential seconds in lookup times, making the Guardian more performant and responsive. ## Matrix Node Integration Goal: Connect to a self-hosted or remote synapse-server (MATRIX) Node. Configure a remote matrix server or a local one via Guardian. Implementation of Matrix-Node deployment via ./pkc setup –matrix-node (provide container).\nMatrix Node Handler Context: We use Ethereum Wallets as Identity-Anchors as they are globally unique addresses (which are collision free) broadly adopted with supported hardware ledgers as secure hardware elements with an existing fast moving ecosystem for further development. They act as ‘web-based’ PGP-like utilities which do not need any Blockchain-Interaction for Signing messages and can be used as a valuable off-line capable identity anchor. With this step we separate Identity and Service; even in case of compromising the computer of the user or by having a breach of secrets in the Element-Client the Identity would be safe (in case a hardware wallet would be used). This also drastically reduces attack surface to phish a users credentials; as there is no Password-Login there is no way to steal the password to impersonate the user. All security assumptions of the User-Identity come back to the security of his private key. For the Kolibri/PKC project this is the foundation for using wallet-addresses as Identities to route traffic with matrix bots between PKC’s. The following actions are required to use the Ethereum Wallet as a strong Identity Anchor within Matrix.\nThis requires the following functionality:\n Register the user via an Ethereum wallet address (successfully piloted by inblockio) Detect that it is an Ethereum Wallet-Address; Verify integrity of address with the Ethereum Wallet-Address Checksum (TBD) Make username not changeable (Done via Matrix settings,successfully piloted by inblockio) Wallet login with Web-Wallet Metamask via OIDC (Open ID Connect) (successfully Piloted by inblockio) Verify Ownership of the Wallet by doing an Element-Client side Signature Challenge to the User. Challenge resolved by signing a message with sufficient entropy to not be ever the same (to protect against leakage) with the private key via the Ethereum Metamask Webwallet (or a connected Hardware-Wallet) Implement a User-to-User request of proof of Identity Users / Server can challenge other users to proof that they hold the private Wallet-Key by triggering the Signature Challenge to the User; After the challenge is done, the requested party is provided with all information to do a manual verification of the signature (the Message which was Signed, the Signature, the used method used for the signature) Matrix-BOT Context: The Matrix-Network communicates with the PKC through the Guardian who will manage all access to the MediaWiki service. The Guardian uses a Matrix-Bot (to handle the communication) and a Matrix-Integration (to be flexible to use a private synapse or a remote synapse server) to interact with the Matrix Network as a permissioned transport layer.\nReferenz-Implementation: Suitable options for a matrix-integration are ‘go-lang’ or ‘rust’. Guardian next generation Guardian will be written in Rust, so integration of security relevant components would be preferably in Rust and Webassambly. A central point to configure the guardian to connect to matrix and other services needs to be provided. The matrix server is connected to the guardian with a service bot which is able to open rooms to exchange revisions between PKC’s.\nRequired Functionality of the Matrix-Bot:\n open new room for user (required) - to share resource invite / remove other users to/ from room (required) - to set permissions who can read shared resource close room (required) - after resource share is revoked join a room the user is invited too (by other matrix-bot) *‘accept invite’ check for challenge (provided via text from remote Guardian), leave room if challenge is faulty and block user (required) delete? room / delete history? Note: Use matrix only as channel not as storage (optional) preferably the history of the channel is not kept post content of (mediawiki API query results from the Guardian) into a room (required) read content of room (send it to the Guardian for verification, before it’s send to the import API) (required) ","categories":"","description":"Shows access and transport layer logic used to interconnect data vaults\n","excerpt":"Shows access and transport layer logic used to interconnect data vaults\n","ref":"/docs/protocol/guardian/","tags":"","title":"Guardian"},{"body":"The following are documentation used to understand the AQUA Protocol and it’s implementations. AQUA is heavily under development at the moment and is evolving rapidly.\n","categories":"","description":"","excerpt":"The following are documentation used to understand the AQUA Protocol and it’s implementations. AQUA is heavily under development at the moment and is evolving rapidly.\n","ref":"/docs/","tags":"","title":"Documentation"},{"body":"Traditional hyperlinks are usually URL’s based on the DNS structure.\nThis allows the resource to be routed via DNS and specified via the URL on the remote server.\nThe limitations of URL’s is that they are not expressing a specific state of the resource they represent. There is no way to verify if the content of the page is consistent with the content of the page who send a URL. For news pages this means that the content of the page could have changed. E.g. two visitors of the same news page could see two different pages.\nWe need a better way to hyperlink so it’s sure, that what is linked is consistent across domains and users. Therefore we introduce Aqua URI’s which are used to enable the receive to verify the state of the resource.\nGoal Use Immutable Hyperlinks as Unique Resource Identifiers (URI’s) to allow a consistent referenciation of resources with the ability to verify them with the AQP.\nSuccess Criteria A Immutable Hyperlink schema which links to a specific state of a resource. Instead of a stateless hyperlink we use verification_hash as a URI which acts as the checksum to verify the retrieved revision.\nInput file upload wizard is executed with file-data and description as input file is stored with in the service triggering a hook leading to the calculation of verification_hash (calculated with the file as input for content_hash) which is stored in the revision_object (file or database) Output\n When linking the file it’s displayed in the following format: [SHA3-512 Hash|Descriptor Text]\nBoundary conditions File is too big to be hashed. We support currently up to 50 MB. File can’t be hashed for some reason (error during the process to due an unexpected code execution) File is empty (has no content) Implementation We create Immutable Hyperlinks by moving from URL’s to sha3-512 hashes as URI’s. These URI’s are globally unique and therefore collision resistant as the namespace is sufficiently large. By using the hashes as links we also refer to the state of the resource. As the hash is the verification_hash of the resource it allows us to verify the integrity of the resource with it.\nWe are referring to files with their SHA3-512 hash in this format [SHA3-512|human_readable_filename]. Displayed is the human readable filename white it’s stored with the full SHA3-512 hash which allows us to be used as Immutable Hyperlinks.\nTo allow routing between resources we can add the \u003cdomain_id\u003e as a prefix to the \u003cverification_hash\u003e resulting in the following syntax:\nexample: aqua://\u003cdomain_id\u003e/\u003cpage_verification_hash\u003e\nNote: Implementatstion specific to aqua-PKC:\n The verification_hash is stored in the content-slot ‘transclusion hashes’ with the internal links which referne the resource. ","categories":"","description":"Shows how the Aqua URI's can be used as immutable links.\n","excerpt":"Shows how the Aqua URI's can be used as immutable links.\n","ref":"/docs/protocol/immutable-hyperlinks/","tags":"","title":"Immutable Hyperlinks"},{"body":"","categories":"","description":"","excerpt":"","ref":"/docs/contribution-guidelines/","tags":"","title":"Contribution Guidelines"},{"body":" #td-cover-block-0 { background-image: url(/featured-background_hu557b5587fe5dc558d8bb115acefce0a8_95557_960x540_fill_catmullrom_top_3.png); } @media only screen and (min-width: 1200px) { #td-cover-block-0 { background-image: url(/featured-background_hu557b5587fe5dc558d8bb115acefce0a8_95557_1920x1080_fill_catmullrom_top_3.png); } } Welcome to the AQUA Protocol! Whitepaper Source Code A simple and novel approach to prove integrity of data, authorship, and time! The AQUA Protocol is an emerging open-source protocol for data verification which is built with modern cryptographic standards. The AQUA Protocol is not and does not require a blockchain!\n AQUA Protocol is made possible by crypto,\nas in cryptography! Demo PKC Node Personal Knowledge Container (PKC) is the reference implementation of AQUA Protocol.\nTry PKC now \n Contributions welcome! We welcome feedback, bug reports, ideas, or contributions code and documentation alike.\n Our Github \n Follow us on Twitter For announcements and updates about our progress on the AQUA Protocol\n Read more …\n ","categories":"","description":"A simple and novel approach to prove integrity of data, authorship, and time!","excerpt":"A simple and novel approach to prove integrity of data, authorship, and time!","ref":"/","tags":"","title":"AQUA Protocol"},{"body":"","categories":"","description":"","excerpt":"","ref":"/categories/","tags":"","title":"Categories"},{"body":"","categories":"","description":"","excerpt":"","ref":"/community/","tags":"","title":"Community"},{"body":"","categories":"","description":"","excerpt":"","ref":"/search/","tags":"","title":"Search Results"},{"body":"","categories":"","description":"","excerpt":"","ref":"/tags/","tags":"","title":"Tags"}] \ No newline at end of file +[{"body":"We develop the AQUA-Protocol to increase trust and digital sovereignty for individuals and organizations.\nWe believe that this is an effective way to redefine collaboration and strengthen democracy to be more inclusive and participatory by providing accountability for data. We do this in a context where it is critical to address challenges and threats which come with the advancement of technologies (e.g. deep fake, manipulation of data, digital surveillance, monopolization).\nWith the powerful tools we provide, we can showcase how trusted data and digital sovereignty are key enablers to support the emancipation and integration of individuals and small to medium businesses into a digital economy, which is currently dominated by large players. We are showing how this is a feasible approach to empower more inclusive and democratic participation.\nWhat are exemplary applications that are meeting current organizational demands? Aside from the core features of the AQUA-Protocol and its reference implementation (to provide data integrity verification, proof of existence, and a strong identity by using public-private key infrastructure), there is an amazing potential that comes as an emergent property of the interaction of individuals using sovereign instances of Personal-Knowledge-Containers.\nThis potential lies in the ability to collaborate by exchanging verified data between independent parties to form a network of relationships as a web of trust. This allows for peer-to-peer institutions and organizations to be built fully software-defined, in traditional or network structures.\nIt is possible to model existing institutions on top of this infrastructure today. It is a free and open-source tool to provide a process to issue and verify digital certificates for various use cases. Including examples, showcased for the educational sector (school and university degrees) but the use cases go beyond this:\n Provide an infrastructure to curate knowledge and enable peer-to-peer wiki’s in which a contribution itself is attested. This has potentially huge implications, as a successfully merged contribution to a leading scientific endeavor could one could imagine this succeeding the reputational value of a university degree. Fighting fake news by providing an audible trail for the information source to the consumer and which steps have been taken, by which account, to reach its current state. E.g. an intelligence report about an ongoing conflict or crisis. Providing credible credentials to fight deep fake and impersonation. In one shocking case, this shows the danger for our political landscape. In this example the mayor of Berlin was tricked, when she had a zoom call with a fake Vladimir Klitschko (in the role of the Mayor of Kyiv, using deep fake for the video and audio to impersonate him) who tried to get money from her. Source Providing a trust infrastructure for invoice validation: Large companies are challenged by the increasing number of fraud and fishing emails to trick companies to send money to criminals. We can use the SSI-Approach of aqua to verify invoices and do automated tests towards the trustworthiness of the sender, by checking the sender’s account and the trust relationship cryptographically. Allowing for automated verification of the invoices instead of lengthy manual testing procedures or complicated processes requiring a CRM-System with an intense KYC (Know You Customer) approach. Proving where the information has originated. This can be used to protect intellectual property (IP) or to prove where data originated. This is highly relevant in various contexts, be it for the credibility of evidence in court or for whistle-blowers or investigative journalists to give their claims more credibility. The socio-technological impact on society We provide a prototype implementation of the aqua protocol with a Personal-Knowledge-Container(PKC). An approach towards digital sovereignty without compromises. It enables data accounting and with it an effective way to enable peer-to-peer trusted data generation and exchange. We showcase that it is possible to have full control over your data, you can share and govern it independently of third parties. This is essential to democratize access to the digital economy, so individuals can utilize the value of their data and do trusted interactions with each other.\nThis technology enables various applications by offering a peer-to-peer-publishing platform technology, this includes but is not limited to:\n Self-Sovereign Identity (SSI) crowdsourced knowledge management, a distributed Wikipedia crowdsourced news crowdsourced petition systems (crowdsourcing problems, solutions, decisions). This Protocol and prototype allow for the practical exploration this how this can redefine our collective sense-making by providing a rational process for forming a truth by consensus between trusted peers. This allows for the practical exploration of digital, participatory collaboration at scale, as the AQUA-Protocol can account for contributions that are currently not measurable in monetary value while those contributions provide value to society and/or nature. It seems possible to envision a different economy where data becomes a multi-dimensional currency that allows us to make better-informed decisions. It can inform us to have a greater choice in how we participate economically as service providers and/or consumers.\n What is it not yet good for?: This is an experimental protocol with a pilot implementation, which is meant for the exploration of new design principles to improve digital sovereignty and trust. This prototype is not production-grade software and should not be used outside of experimental applications. The prototype does currently (Dec'22) not include a transport layer. ","categories":"","description":"","excerpt":"We develop the AQUA-Protocol to increase trust and digital sovereignty for individuals and organizations.\nWe believe that this is an effective way to redefine collaboration and strengthen democracy to …","ref":"/docs/overview/","tags":"","title":"Overview"},{"body":"Implementation specific architecture documentation for the Aqua Data Vault ‘Personal Knowledge Container (PKC)’. In this document you will find reasoning as to why certain components were chosen to build this prototype. We have not duplicated any vendor documentation. Please find the linked-list for the documentation of the components we use here:\n MetaMask Ethereum Docker MediaWiki MediaWiki Extension: Aqua MediaWiki Skin Tweeki Pelith Eauth Server Nodejs GitHub Apache Nginx Let’s Encrypt All software components selected are open source licenses. They each have active developer communities behind them to secure future support and further development.\nWallets / Accounts Why do we use Ethereum Wallets / Accounts?\nAn identity anchor needs to be a public, private key. This allows a public component which we can share (public key) and a private component which proves ownership over that public-key. Public keys are used in Ethereum as accounts to receive and send transactions. Therefore the Ethereum ecosystem has developed standards. These have evolved to a larger eco-system involving wallet-providers which have built software and hardware wallets to securely manage those keys. We leverage one of the most vibrant developer communities and utilize these wallets. In our case they are used mainly for offline-activities (Login, Signing) which do not require connectivity to the Ethereum blockchain.\nWeb-Application (Chrome-Extension MetaMask) Was selected as it is one of the most advanced, widely used, feature-rich web-wallets. Most importantly it’s a browser-plugin which allows us to interact with browser applications. MetaMask also has the ability to connect to a hardware wallet allowing for increased security and levels of assurance.\n Large User-Base 10 Million + Hardware Wallet Support (E.g. Ledger) Large User-base 5 Million + All related source code is open source, lot’s of money behind it (future proof) SSI (Self-sovereign identity): Compatible with the DID schema did:ethr:\u003cwallet_address\u003e Fulfills SSI principles: Controlled by user, allows for creation of new accounts / wallet addresses User can create new identity anchor independent of third party Can be moved between devices by users recovery key or even to a hardware wallet (not recommended but possible: https://kryptonitelex.medium.com/how-to-transfer-your-metamask-to-a-ledger-hardware-wallet-bcece7d5567b ) Witness Network We are using the Ethereum Network as an optional Witness Network for cryptographic time-stamping.\nWhy public Blockchain? The witness event serves the purpose of being able to prove the existence of a document without the ability to deny it. This requires censorship resistance and global coverage. The security of the network, it’s distribution, and the high economical price to attack the network, are all good reasons why we want to use a public blockchain to publish highly obfuscated hashes (fingerprints). This proves the state of the data in a Data Vault (PKC).\nThe MetaMask wallet is able to publish the witness event verification hash to the public Ethereum blockchain. This completes our third important layer of integrity verification, which is to prove cryptographic time and existence of a document by writing it’s fingerprint onto the ledger. This is not done directly, but through a process which highly obfuscates the hash. This ensures that that there is no plausible attack (even if the attacker owns a powerful quantum computer) to match the fingerprint with any personal data.\nData Vault The Data Vault named ‘Personal Knowledge Container’ is creatd by using a tool for containerization called ‘Docker’. This allows us to package our application so it can be deployed to different operating system environments. Docker provides the abstraction / virtualization layer.\nInside Docker we containerized multiple services:\nMediaWiki for data governance MediaWiki is a data governance tool which has a legacy as a collaboration tool. It powers Wikipedia, the largest encyclopedia in the world. We step into this experience, and the benefits of a feature rich, battle-proven application. It’s a powerful tool to both manage and present data.\nAs MediaWiki has an active and established developer community, it is possible to tap into existing professional service companies. Supporting development and any required changes within the application.\nMediaWiki has been modified to use workflows for data processing. This will allow for implementing and testing workflows and business logic between Personal-Knowledge-Containers.\nWe use all the benefits of MediaWiki to manage and present data in the browser, while we work around one of its main limitations: Security. MediaWiki was never developed to have advanced security and permission structures, as it was built for Wikipedia - a fully public website. This has several implications for us.\nSecurity Practices:\n We assume that we can’t defend against insider attacks on the same MediaWiki instance, therefore every user has their own instance If there is a need for a collaboration space, it is possible to spawn containers for multiple accounts which trust each other to work together on shared data If you use a hosted PKC instance, assume the provider has access to your data as we don’t use homomorphic encryption nor do we have encryption implemented We are using typed and tested PHP (for MediaWiki Extension Data Accounting) to improve test coverage to increase stability and security of our application To securely exchange data between PKC’s, we implement a separate security software called Guardian. The Guardian protects the PKC and manages all access according to the accounts owners set permissions. The Guardian is under active development. It will receive the highest scrutiny and attention to ensure a minimal attack surface while allowing trust between Guardians so data can be exchanged. The Apache WebServer present in the MediaWiki container has a technological dependency and needs regular updates as Apache was effected by critical security issues like CVE-2021-44228 Therefore we do not expose the Apache web-server to the internet by default and do not recommend this to ensure that there is no unnecessary attack surface. If an organization decides to expose the web-surface of a PKC to the internet, they should expect this instance to be compromised and leak all it’s stored data. Therefore we re-emphasize: If PKC / MediaWiki is exposed to the web, there can’t be any guarantee that data can be kept private. Therefore assume your data can be leaked on a web-facing MediaWiki instance. Organizations hosting PKC’s for collaboration should do so with restricted firewall permissions, ensuring that the web-interface is only reachable for the employees authorized to see the content. MediaWiki Extension: Aqua The existing ecosystem and reference implementations around MediaWiki allowed us to quickly prototype our reference implementation for Aqua. The implementation itself allowed us to further develop the protocol. The downsides are currently old PHP code and MediaWiki’s legacy. In return we benefit from a well documented project.\nLooking forward we want to see other client-implementations in different languages independent of MediaWiki to show the potential of the Aqua Protocol. We hope to re-use part of the PHP code base to apply it to other applications, like Word-Press.\nMediaWiki Skin Choice Using Tweeki as a Bootstrap 4 compatible Skin for MediaWiki, we were able to establish contact with the chief maintainer of the extension, and were able to collaborate to solve various issues to improve the skin. We are coordinating with other parties to see how we can improve support for the Skin. In the future we are hoping to increase the maintainer base. Prospectively we want to use Tweeki as an abstraction layer from MediaWiki classic to Bootstrap 4, and respectively Bootstrap 5+.\nAuthentication For Authentication with Web-Wallets, we use https://github.com/pelith/node-eauth-server which provides us with an open source solution for a signature-response challenge. We then integrate with OAUTH2 and OIDC using existing authentication standards to achieve the login. The Pelith server provides us with the Signature-Challenge and is forwarding the access token via OAUTH2 to MediaWiki. Here we check if the user exists. If this is the case, access is granted. WebServer-Proxy / HTTPs We are using NGINX Web-Server as the proxy server. NGINX is a modern and the most popular (#1 since 2021 by share1) web-server on the web. We are using Let’s Encrypt to provide secure connections via HTTPS if a PKC is deployed to the web. Let’s encrypt serves over 260 million websites according to the vendor website.2 provides free TLS Certificates for secure HTTPS connections. The NGINX Web-Proxy allows us to ensure that we can add additional services to the PKC and redirect the services according to our needs. Software-Development We use https://github.com for software development. As we started with very little budget, we gratefully utilised free resources to develop our open source software. This allowed us to focus on being productive. Github is owned by Microsoft and is therefore subject to US policies and Microsofts interests. This itself requires us to move away to be independent or at least host a mirror instance outside of Github. The deletion of a repository or losing access could harm our development process significantly. We use GPL-V3 license on the majority of our repositories. We maintain the rights on branding We maintain more restrictive rights on deployment scripts (service provider technologies) Browser Choice We are using the Chrome-Engine as our Web-Browser of choice. It’s the most dominant web-browser on the Web, and has become the quasi standard with many different forks creating an ecosystem around it. Microsoft-Edge is actually Chrome. There are non-google chrome forks which deserve attention, funding and support (like https://github.com/Eloston/ungoogled-chromium ). This will provide us with a modern and state of the art browser architecture to work with.\nAs Chrome is the most secure and modern base to build on, we support -only- chrome. Therefore we use a chrome extension to verify the content of an Aqua file. This extension is available for download in the Google Chrome App Store, or can be built from scratch following the instructions in our repository.3\nThis allows us to provide ease of setup, as users can easily deploy the chrome extension without further effort by adding it from the google app store.\nWe are using NPM / node.js for fast prototyping. This comes with severe security implications as the npm ecosystem has been prone to various supply-chain attacks over recent months 4 .\nTechnology choices on cryptography All cryptography used in our development is based on international NIST standards and follows the international understanding for internet security. This is consistent with the perspective of the BSI in Germany, but for some specific details there are no insights provided by the ministry.\nHashing Algorithms (SHA3-512) PKC uses standard Crypto (SHA3-512) winner of the National Institute of Standards and Technology see https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.202.pdf . We do not use custom encryption as this comes at the cost of unnecessary risks.\nThis is an accepted secure and recommended standard according to BSI - Technische Richtlinie – Kryptographische Algorithmen und Schlussellängen Seite 42 .\nMerkle Tree5 We use merkle trees to be able to witness the state of all pages / files in a single hash. Used to generate a unique fingerprint of a domain (a collection of verified data hash chain’s within one domain). There is a lot of future potential in ongoing research to improve privacy and utility of merkle trees in the Aqua Protocol See related technologies and research like TAPROOT: https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki Public-Private-Key Signatures (secp256k1) Used in combination with Ethereum Accounts. It is used for signing and authentication challenges.\n in ether.js cryptography/secp256k1 see implementation related documents of the ‘Standards for Efficient Cryptography Group’ https://secg.org/ specific doc secp256k1 [ Both variants of the same standardization process of the Standards for Efficient Cryptography Group 2015, See differences P9 Supported by BSI secp256r1 but secp256k1 is not mentioned.https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/TechnischeRichtlinien/TR03116/BSI-TR-03116-4.pdf?__blob=publicationFile\u0026v=7 Request for clarification was send via E-Mail on the 3rd of November 2021 by Tim Bansemer. Answer of the BSI: Currently the BSI has no assessment or recommendation for secp256k1. For authentication with Metamask Ethereum wallets we currently use https://github.com/pelith/node-eauth-server . We are signing a unique input value with ethereum.js using the personal sign method. Once the challenge is completed successfully we receive an OAUTH token from the Eauth identity provider of the pelith Eauth server. https://linuxiac.com/nginx-most-popular-web-server/  ↩︎\n https://letsencrypt.org/  ↩︎\n https://github.com/inblockio/aqua-verifypage-chrome-extension  ↩︎\n https://duckduckgo.com/?q=npm+supply+chain+attack\u0026ia=software  ↩︎\n https://en.wikipedia.org/wiki/Merkle_tree  ↩︎\n ","categories":"","description":"Explains the technologies selected for the reference implementation and why we selected them.\n","excerpt":"Explains the technologies selected for the reference implementation and why we selected them.\n","ref":"/docs/implementations/reference-architecture/","tags":"","title":"Reference Implementation"},{"body":" Current version: Aqua Protocol v1.1 Specification Author: Tim Bansemer, Publius Dirac Date: 30.12.2021 Status: DRAFT / Experimental Implementation: https://github.com/inblockio/micro-pkc Introduction The Aqua Protocol (AQP) is a data accountability and exchange protocol between hosts in peer-to-peer environments. The AQP is used to realize the goal of accounting for data origin and history . The description for the proof-of-concept implementation of the AQP can be found in this page .\nMotivation In today’s world, there are no widely adopted trustless processes of checking if data have been manipulated or corrupted, are attributed to the wrong author, or are attributed to the wrong time. Today’s processes are dependent on centralized trusted services which retain all power over governing the data.\nThere is a lack of transparency or ability to check if data have been altered by an unauthorized party. Additionally, consumers of data are incapable of verifying if centralized services have altered the data. This leads to a world of untrustworthy information in which we don’t know how to conclude what is true.\nIn a world where every piece of information is a grain in a sandstorm, it has become impossible to navigate reality. In contrast, in a world where every piece of information is a fixed star in the sky for a lifetime, we are able to relate and make sense of the information given. The Aqua Protocol (AQP) turns grains of information into fixed stars of information.\nThe AQP adds a peer-to-peer layer of accountability, making it impossible to change data unnoticed. AQP adds an essential line of defense against attacks on data integrity, plagiarism, or misattribution. AQP is used to govern trusted data, which can be quickly verified. This includes the verification of its integrity and history, the verification of its account (the entity who creates or manipulates the data), and the verification of its existence and timestamp.\nThe Aqua Protocol provides trustworthiness to data by securing data ✅ integrity, 🔏 account and ⌚ time. In order to account data, it is necessary to track and verify its history. The AQP provides a globally unique resource identification (URI) for each revision of the verified data. This identifier is collision-free, and is referred the same way across multiple interacting hosts.\nTerminology 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.\nSee Separation of Concerns .\nAccount We are following Ethereum’s account definition:\n 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.\nFor more on this topic, please read the Aqua Identity Protocol .\nDomain 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.\nE.g. by setting up the a data vault with your account it becomes your domain of data governance.\nRevision A revision is the smallest portable entity within the AQP. Multiple revisions form a single portable hash chain which is serialized in JSON format. They have existed before in unsecured systems where multiple revisions form a file which can be displayed as a page. The AQP adds the cryptographic harness to secure it. With presenting a portable hash chain, it is possible to track all incremental changes stored in each revision to understand the history of a page and how it came to be. This allows us to have version control on digital assets being able to restore earlier states and to relate to them. This allows us to have historical evidence of digital assets.\nPage A page is a visible representation of a file containing multiple or a single revision attributed to a shared origin. A page view could also be used to create a new revision by a used service which interfaces with the file for manipulation. In AQP all revisions share a global URI hash to attribute them together called a genesis hash.\nTransaction 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.\nData Asset Data turns into a valuable asset if it is accounted for. In an accounted form it can be easily priced, exchanged or traded.\nData 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.\nSee Design Principles / Separation of Account and Service Witness We define witnessing as the process of observing an event. A witness is judged by their capability to recollect and share an observed event. In other words, witnessing is the process of storing input data for later playback to provide data symmetry around an event.\nWitness Network The digital service in a distributed ledger or similar infrastructure which provides transaction security and data symmetry for shared data within the network. An example of a witness network would be Ethereum.\nE.g. Ethereum can be used to store a digital fingerprint of a domain snapshot of a data vault. A domain snapshot is the Merklized state of all witnessed hash chains being present in the data vault. It is required to pay the witness network for its service. In the case of Ethereum, this is done using ‘Ether’. This in return allows the account owner to create an ‘undeniable’ proof that a specific revision and the previous revisions within a hash chain has existed.\nPortable Hash Chain A hash chain is a linked list where each node contains the cryptographic hash of the previous node content. A portable hash chain is a hash chain that can be moved from one host to another.\nImmutable Hyperlinks / Transclusions See Immutable Hyperlinks .\nSpecification To identify a revision with a unique fingerprint, we hash its content using the SHA3-512 hashing function which always has a 128 characters long output. This value can be used as a checksum to verify data integrity. The checksum can then be entangled in a hash-chain to create an immutable track record. We then calculate multiple properties associated with the revision, in addition to its content checksum. In the next section, we differentiate between REQUIRED and OPTIONAL properties for each revision.\nAll hashes are based on SHA3-512 . This encryption standard is used to construct portable hash chains , which are serializing of data and its history in a form that can be verified, and independent of location. The portable hash chain can be fully or partially exchanged between hosts depending on the application of the data. From here on, we refer the term “portable hash chain” as “hash chain.”\nIn order to implement the AQP, we need to utilize a software that is capable of generating portable hash chains and facilitating actions described in the AQP. We call those nodes which facilitate the Aqua Protocol ‘Aqua Data Vaults’ which given their role should be implemented as a software with secure architecture and measures for keeping data assets safe. This is achieved through encryption, authentication and restrictive access to keep data private by default.\nRevision Verification Structure A revision is RECOMMENDED to be limited to 50 Megabytes to ensure that the verification can take place on all imaginable clients which might have slow network connectivity, low memory, low cpu performance. Once a revision is verified, the next one can be verified. Clients with more performance will be able to parallelize the verification. Larger files can be chunked to be placed in multiple revisions.\nA verified data structure is identified by its URI verification_hash and grouped by its genesis_hash. The first revision created will create a verification_hash which has a special meaning and is referred to as the genesis_hash. All future revisions building upon that first revision will be attributed to the genesis_hash as a unique URI for grouping the revisions. This allows us to understand if two revisions are related without needing to verify the whole history of the hash chain.\nVerification Hash revision_verification_hash is the hash sum over the string formed by the following operation\nrevision_verification_hash = calculate_hash_sum( content_hash + metadata_hash + signature_hash + witness_hash ) The content_hash and metadata_hash are REQUIRED. The signature_hash and witness_hash are OPTIONAL.\nContent A content hash is the check sum for all content data fields which simplifies hash construction and the ability to identify data corruption in this part of the verification structure. content_hash is the hash sum over the string formed by following operation:\ncontentObj = { \"main\": content, \"extension_key_1\": content_extension_1, \"extension_key_2\": content_extension_2, ..., \"extension_key_n\": content_extension_n, } sortedContenObj = sort_by_keys(contentObj) content_hash = calculate_hash_sum( sortedContenObjValue_1, sortedContenObjValue_2, ..., sortedContenObjValue_n, ) Description:\n content: The string input of the visible page using UTF-8 encoding schema. REQUIRED. content extensions: more data MAY be encapsulated in addition to the main content. These could be a file, a stateful link, or a signature. The content extensions are sorted alphabetically by their key names. OPTIONAL. The sort_by_keys function sorts the content object elements by their keys alphabetically. The JSON input MAY be a canonical JSON, in which the keys order is already alphabetical, but we sort it always to ensure the order is correct. To see an example of contentObj of a revision, see the example section,\nMetadata metadata_hash = calculate_hash_sum( domain_id + time_stamp + previous_verification_hash ) Description:\n 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 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.\nIn this specification, we use the AQP reference implementation’s signing method, which is via an Ethereum wallet.\nsignature_hash = calculate_hash_sum( signature + public_key ) The signature is generated by a wallet signing the following message:\nI sign the following page verification_hash:\" +[0x\u003crevision_verification_hash\u003e] The revision_verification_hash MUST NOT be signed twice by the same key, to avoid information leakage of the private key.\nFor example, a wallet with an address of 0xa2026582b94feb9124231fbf7b052c39218954c2 and a public key of 0x041518581af65749b3ddc69889df3e5d229bc8ad79279a07ddeb368ade5e1592368c5ff3b69143d7a1e7cf64f7d0774a6724e6eaf138d318d07ddc30f6081ca89a signs the following message:\nI sign the following page verification_hash:\" +[0x9dab72c7635043452958c4cc2902f48ef7c4ae437058280197c6a2736ab9635f799cbf190d9d07dd76589055a8ad64e61c6bebd1487994207d4cb7918b471f57] which results in the following signature:\n0x19b5697c4541509c1add3db9fc2f678b7b80325ebffd4d945ca00db5f8b3f98a142edbf9a7faa0a0c7ec4f10ae1b64cf2ea62ce3ee73ed2e37ce916d6bd016601c 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.\nThe 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.\nA 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.\nwitness_hash = calculate_hash_sum( domain_snapshot_genesis_hash + merkle_root + witness_network + witness_event_transaction_hash ) Description:\n witness_hash: the checksum for all signature data fields. It simplifies hash construction and identifies data corruption in this part of the verification structure. domain_snapshot_genesis_hash: Refers to the URI of the page which stores the whole Merkle tree of the witness event. merkle_root: the root hash of the Merkle tree. The presence of the Merkle tree allows for lazy verification to reduce required computational steps for verification by skipping the Merkle proof as both datasets can be entangled in the chain by a newer revision and therefore be immutable. witness_network: specifies which witness network was used to store the witness_event. The following structure shows an AQP hash chain with 3 revisions which wrote the witness_event_verification_hash into the witness network. Additional context:\n relative-merkle-tree-proof: This provide the relative path with all required hashes to verify the Merkle tree root from the first node which the verification_hash of the revision as a starting point. witness_event_verification_hash: It is calculated by taking the sha3-512 checksum of the domain_snapshot_genesis_hash and the merkle_root hash. This ensures that thedomain_snapshot itself will be witnessed. Example The following structure shows an AQP hash chain with 3 revisions:\n1st Revision This revision features all REQUIRED (content, metadata) and all OPTIONAL (signature, witness) AQP data fields.\n{ \"verification_context\": { \"has_previous_signature\": false, \"has_previous_witness\": false }, \"content\": { \"rev_id\": 358, \"content\": { \"main\": \"First revision text\", \"transclusion-hashes\": \"\" }, \"content_hash\": \"ae188be061822074716b43925b3ffa90a03c530342be73c3440d8f022765ffebbb56c16552f13cd1ea61f876d2d892e0a73dcba5173fc47d371b4251d6c094da\" }, \"metadata\": { \"domain_id\": \"acfa9f682e\", \"time_stamp\": \"20220116090401\", \"previous_verification_hash\": \"\", \"metadata_hash\": \"d1025fd8866d9367735d2f6617b3aa87401e08d726f311cdf834ea9540955bfc59b428676bce5d47d5fed381394ab2ed838c5eecfc9cb37313705374752c247d\", \"verification_hash\": \"9dab72c7635043452958c4cc2902f48ef7c4ae437058280197c6a2736ab9635f799cbf190d9d07dd76589055a8ad64e61c6bebd1487994207d4cb7918b471f57\" }, \"signature\": { \"signature\": \"0x19b5697c4541509c1add3db9fc2f678b7b80325ebffd4d945ca00db5f8b3f98a142edbf9a7faa0a0c7ec4f10ae1b64cf2ea62ce3ee73ed2e37ce916d6bd016601c\", \"public_key\": \"0x041518581af65749b3ddc69889df3e5d229bc8ad79279a07ddeb368ade5e1592368c5ff3b69143d7a1e7cf64f7d0774a6724e6eaf138d318d07ddc30f6081ca89a\", \"wallet_address\": \"0xa2026582b94feb9124231fbf7b052c39218954c2\", \"signature_hash\": \"cc42f40c4452a25f9ea48a97b6dfba6f69dec347db5c1adf25475b0b4a5da36af3fe48bf9f7ea0dda6bbed9367dc9c82834dbf8cc7f6220fd190cdb729d3f4ec\" }, \"witness\": { \"witness_event_id\": \"2\", \"domain_id\": \"acfa9f682e\", \"domain_snapshot_title\": \"Data Accounting:DomainSnapshot:b33afaf53ed3d245f0319d4997db2032de9d77791ae11f5125189815eef44f2fba9633bebe2e57bc5ea4b0424872ed02fa6aa9ad909f467726b536933bf715bf\", \"witness_hash\": \"9707780cebcf6ed02b40bd7e6956b35ffe142a2b5f8cee15c703a652fa389eb118ef101e2f463e95663aa4013a42d9f1ce4a83eed3528b02bf98626e7599bbd8\", \"domain_snapshot_genesis_hash\": \"b33afaf53ed3d245f0319d4997db2032de9d77791ae11f5125189815eef44f2fba9633bebe2e57bc5ea4b0424872ed02fa6aa9ad909f467726b536933bf715bf\", \"merkle_root\": \"14f26d7dc0be77afff9131c03cab39a2fa9e1270c6face3fdc35b9b4b4ac4550d048c356a4713568c42411c3e7fe3553ec7b993c9bd7da97cb976e843d7e4d29\", \"witness_event_verification_hash\": \"67e187411f1e514f232ae2858168da29b15ddfd07523e7a7618bfbf91c583f54fe8e850146120539a92a63ce6138f96599fb8a46ed492e428fe6fde9b9ea82ae\", \"witness_network\": \"goerli\", \"smart_contract_address\": \"0x45f59310ADD88E6d23ca58A0Fa7A55BEE6d2a611\", \"witness_event_transaction_hash\": \"0x5900103adc09a789fd3bd7c23dfeff1ffce41dfba0a52b525ecc032e9279eb1f\", \"sender_account_address\": \"0xa2026582b94feb9124231fbf7b052c39218954c2\", \"source\": \"default\", \"structured_merkle_proof\": [ { \"witness_event_verification_hash\": \"67e187411f1e514f232ae2858168da29b15ddfd07523e7a7618bfbf91c583f54fe8e850146120539a92a63ce6138f96599fb8a46ed492e428fe6fde9b9ea82ae\", \"depth\": \"4\", \"left_leaf\": \"2554fb53531f4de26ff3ad1fb8c61feea6ea47c3f13c4abda385c46ef8541361f7eee42433050281714a3900115f04fe52b5a8d781a71c4c439c5de6b91cbe3c\", \"right_leaf\": \"9dab72c7635043452958c4cc2902f48ef7c4ae437058280197c6a2736ab9635f799cbf190d9d07dd76589055a8ad64e61c6bebd1487994207d4cb7918b471f57\", \"successor\": \"789e508ccb23fe053b628cebc19a2d32f34e6aa21e878e8611f7c14d891625c7b2e243b3c3105b98295333b9183e5ea272a055a84ab65ad927f7fd9c27aae48e\" }, { \"witness_event_verification_hash\": \"67e187411f1e514f232ae2858168da29b15ddfd07523e7a7618bfbf91c583f54fe8e850146120539a92a63ce6138f96599fb8a46ed492e428fe6fde9b9ea82ae\", \"depth\": \"3\", \"left_leaf\": \"789e508ccb23fe053b628cebc19a2d32f34e6aa21e878e8611f7c14d891625c7b2e243b3c3105b98295333b9183e5ea272a055a84ab65ad927f7fd9c27aae48e\", \"right_leaf\": \"c16a966333cd22ff3497875a62202874221c1dae2e74b4351d058910f8d37160be480fce9aab4ec5e725beb695509f0fd65ae581568c6f1ae25eb4f1440b287f\", \"successor\": \"80d7549af24e9a6bdfc32cefe0536d6528d665cc8e65859ef4cff87270f3db8d9b95aaecc167e10c9b5be9ce3ab36d8d880c3a518e1c5eb899ca9d95af24e9db\" }, { \"witness_event_verification_hash\": \"67e187411f1e514f232ae2858168da29b15ddfd07523e7a7618bfbf91c583f54fe8e850146120539a92a63ce6138f96599fb8a46ed492e428fe6fde9b9ea82ae\", \"depth\": \"2\", \"left_leaf\": \"80d7549af24e9a6bdfc32cefe0536d6528d665cc8e65859ef4cff87270f3db8d9b95aaecc167e10c9b5be9ce3ab36d8d880c3a518e1c5eb899ca9d95af24e9db\", \"right_leaf\": \"f4e189a08b486253ea0a5cc7bf7150055e738898115c4caf00e45634d6925539d51852409d1fe9108469e9b15668b940f3369300bb27cc292d1fabc0c07cd593\", \"successor\": \"e227dd97e5166364483b41f058f0d176e3a50a7510299038b09ae3aef2cbafb26c787afad82563a945b433fa2d1279af3535755235ab69d6e5ab089179177c14\" }, { \"witness_event_verification_hash\": \"67e187411f1e514f232ae2858168da29b15ddfd07523e7a7618bfbf91c583f54fe8e850146120539a92a63ce6138f96599fb8a46ed492e428fe6fde9b9ea82ae\", \"depth\": \"1\", \"left_leaf\": \"e227dd97e5166364483b41f058f0d176e3a50a7510299038b09ae3aef2cbafb26c787afad82563a945b433fa2d1279af3535755235ab69d6e5ab089179177c14\", \"right_leaf\": \"780f3eb08f24022be4463be141bcda6a33a157cd0fd44cf209312b8427ac4036637a63d239526555128a4e7f4bb588ebfdbd8a8cc7d797038e29b852a4fae26c\", \"successor\": \"f3bd4e82b1e3d304005a7ddf4ab940f3e4e1cf099ca1c058454c431ed3feb0674c044e53150eb5691073ba58a3491565f72f6a6c2a24562ea080b569b4496c9f\" }, { \"witness_event_verification_hash\": \"67e187411f1e514f232ae2858168da29b15ddfd07523e7a7618bfbf91c583f54fe8e850146120539a92a63ce6138f96599fb8a46ed492e428fe6fde9b9ea82ae\", \"depth\": \"0\", \"left_leaf\": \"f3bd4e82b1e3d304005a7ddf4ab940f3e4e1cf099ca1c058454c431ed3feb0674c044e53150eb5691073ba58a3491565f72f6a6c2a24562ea080b569b4496c9f\", \"right_leaf\": \"4a0c120fbdd6219b774eb2cb2076f4050d606b621e384c3ec645be0e5dbcdac3132f1f2acb531fa5ff62429907b77cf8d29a760be3765eb4decd83949a2925f8\", \"successor\": \"14f26d7dc0be77afff9131c03cab39a2fa9e1270c6face3fdc35b9b4b4ac4550d048c356a4713568c42411c3e7fe3553ec7b993c9bd7da97cb976e843d7e4d29\" } ] } } 2nd Revision This revision entangles all data fields of the previous revision. As the calculation of the revision_verification hash depends on the revision of the previous revision, it is shown in verification_context.\n{ \"verification_context\": { \"has_previous_signature\": true, \"has_previous_witness\": true }, \"content\": { \"rev_id\": 362, \"content\": { \"main\": \"First revision text\", \"signature-slot\": \"[\\n {\\n \\\"user\\\": \\\"0xa2026582b94feb9124231fbf7b052c39218954c2\\\",\\n \\\"timestamp\\\": \\\"20220116090439\\\"\\n }\\n]\", \"transclusion-hashes\": \"\" }, \"content_hash\": \"9732084a45fd344d63687ccf9b5cd942f99ffe1debd11622b05d0cd24a2de3e5608d5f5121bdd7559c0a2d39067f9258c4f9612e44728df2e8d9026a88ed650c\" }, \"metadata\": { \"domain_id\": \"acfa9f682e\", \"time_stamp\": \"20220116090439\", \"previous_verification_hash\": \"9dab72c7635043452958c4cc2902f48ef7c4ae437058280197c6a2736ab9635f799cbf190d9d07dd76589055a8ad64e61c6bebd1487994207d4cb7918b471f57\", \"metadata_hash\": \"8df483539e2f81e64c9b9df0c7e13ae7778947b5defef860fbaed1260eade794999839bb254ea5006a5d4b6a89a37980ab576dc546d6336518d65b80bf2a5cb5\", \"verification_hash\": \"296347471b33f3d3c69cc6e0699d80b4cb68ffc79c3ecce96beb659fa324fab1de7a888932fbfb7c60bb8cc83c9445ce15532987a7b59440cada649681618293\" }, \"signature\": { \"signature\": \"\", \"public_key\": \"\", \"wallet_address\": \"\", \"signature_hash\": \"\" }, \"witness\": null } 3rd Revision This revision features a transclusion-hash for an immutable link to another revision.\n{ \"verification_context\": { \"has_previous_signature\": false, \"has_previous_witness\": false }, \"content\": { \"rev_id\": 363, \"content\": { \"main\": \"First revision text\\n\\n[[File:Logo_inblockio.png]]\", \"signature-slot\": \"[\\n {\\n \\\"user\\\": \\\"0xa2026582b94feb9124231fbf7b052c39218954c2\\\",\\n \\\"timestamp\\\": \\\"20220116090439\\\"\\n }\\n]\", \"transclusion-hashes\": \"[{\\\"dbkey\\\":\\\"Logo_inblockio.png\\\",\\\"ns\\\":6,\\\"verification_hash\\\":\\\"9b2b3cafb90a07433a2b61885a9e64641a99b1e9024cf53b640501d3706b142fed7bc372300973137ef9d92584fac70976c3889d5610abcfe1f187c248263a56\\\"}]\" }, \"content_hash\": \"14b8256ccd5fa1d883983317f92f428eadb52f699f476b9be69f14c6892b41979ff7b5b7a7a978177985d6aaa0bcfd9857a2646aedc4cbb3299373daa647814b\" }, \"metadata\": { \"domain_id\": \"acfa9f682e\", \"time_stamp\": \"20220116090556\", \"previous_verification_hash\": \"296347471b33f3d3c69cc6e0699d80b4cb68ffc79c3ecce96beb659fa324fab1de7a888932fbfb7c60bb8cc83c9445ce15532987a7b59440cada649681618293\", \"metadata_hash\": \"09688c05a83bb74bb255fb0c571cb6314b65f5b7f00750547a2c43f4959d4702ae2aec019c6fb4b0e5d23adea87fd456b0eaffc6ae271163a1fa45b4bae54230\", \"verification_hash\": \"b35894d74dfcf8b41ff95eed97705e1acf9081021e0d478d8645cb04b8a0b4a013ee8f7fb6e140d149f2c92f20bba984fad5535938a5e36ae6a799a18343b806\" }, \"signature\": { \"signature\": \"\", \"public_key\": \"\", \"wallet_address\": \"\", \"signature_hash\": \"\" }, \"witness\": null } API Endpoints The AQP provides 3 API endpoints which return data from a host that runs the AQP:\nGet Hash Chain /get_hash_chain_info/{identifier}?identifier=\u003ctitle or genesis hash\u003e\nInput:\n identifier_type: the value must either be “title” or “genesis_hash” identifier: the title or genesis_hash string, e.g. “Main Page” or “02c3c2…215d8d” Returns: all context for the requested hash_chain. Example:\nAPI Request: /get_hash_chain_info/genesis_hash?identifier=dffd37be12adc9e774b51aa712f7c5bfc09f48b083540d8ca55f91f317e8685bf09daf004f7c841e53732b8c7992de3f3b9b79350d13570c3b46803ba5119c26\nAPI Response:\n{ \"genesis_hash\": \"dffd37be12adc9e774b51aa712f7c5bfc09f48b083540d8ca55f91f317e8685bf09daf004f7c841e53732b8c7992de3f3b9b79350d13570c3b46803ba5119c26\", \"domain_id\": \"acfa9f682e\", \"latest_verification_hash\": \"2554fb53531f4de26ff3ad1fb8c61feea6ea47c3f13c4abda385c46ef8541361f7eee42433050281714a3900115f04fe52b5a8d781a71c4c439c5de6b91cbe3c\", \"site_info\": { \"sitename\": \"Personal Knowledge Container\", \"dbname\": \"my_wiki\", \"base\": \"http://localhost:9352/index.php/Aqua\", \"generator\": \"MediaWiki 1.37.1\", \"case\": \"first-letter\", \"namespaces\": { \"0\": { \"case\": true, \"title\": \"\" }, \"6942\": { \"case\": true, \"title\": \"Data Accounting\" } }, \"version\": \"0.3.0\" }, \"title\": \"Aqua\", \"namespace\": 0, \"chain_height\": 3 } Get Revision Hashes /get_revision_hashes/{verification_hash} Input:\n verification_hash Returns: the revision requested if it exists and/or a list of any newer revision than the one requested. Example:\nAPI Request: /get_revision_hashes/dffd37be12adc9e774b51aa712f7c5bfc09f48b083540d8ca55f91f317e8685bf09daf004f7c841e53732b8c7992de3f3b9b79350d13570c3b46803ba5119c26\nAPI Response:\n[ \"dffd37be12adc9e774b51aa712f7c5bfc09f48b083540d8ca55f91f317e8685bf09daf004f7c841e53732b8c7992de3f3b9b79350d13570c3b46803ba5119c26\", \"f483d7746f67e7099099bcfa8ea5a93148251c598857e8fad21ce842da62794467067802ef9e818d240cd3312a3346a769f363145a87bfc1eeae19fe8d21b328\", \"2554fb53531f4de26ff3ad1fb8c61feea6ea47c3f13c4abda385c46ef8541361f7eee42433050281714a3900115f04fe52b5a8d781a71c4c439c5de6b91cbe3c\" ] Get Revision /get_revision/{verification_hash} Input:\n verification_hash Returns: the revision content together with its verification data Example: See example above.\nAPI Request: /get_revision/dffd37be12adc9e774b51aa712f7c5bfc09f48b083540d8ca55f91f317e8685bf09daf004f7c841e53732b8c7992de3f3b9b79350d13570c3b46803ba5119c26\nVerification Process The verification process is a redo of the verification data generation process, and additionally a comparison of their results.\nVerification of Content\nAll 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.\nVerification of Account\nWe cryptographically verify that the revision signature is indeed generated by the account specified in the verification data.\nVerification of Time\nTo 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.\nReference Implementation\n Command-Line-Verification-Tool https://github.com/inblockio/aqua-verifier-js Chrome Extension Verification Tool https://github.com/inblockio/aqua-verifier-webextension Appendix The following content is informational and not part of the specification. It should help to better understand utility, context and services which can be built on top of AQP.\nAqua Protocol v1.1 Changes Moving over to revision based verification. This allows:\n Bulk / in parallel verification; ensuring logarithmic verification times, not linear increasing verification times with longer history. In short: Much faster and scalable. Single revision and range verification (you want to verify a specific part of the content-chain) This is useful for verification of identity claims, where trusted parties have signed the claim and for the validator it’s sufficient to see that signature. This allows direct verification after every edit via the Guardian. This is the preparation in the interaction to provide services through the Guardian . Changing the design to include transclusions e.g. this allows the verification of subpages via their stateful links / revision_verification_hashes This also allows the inclusion of media files in the verification process You can upload pictures, PDF’s, Word-Documents and have them automatically included in the aqua protocol and therefore in the verified data-structure Introduction of verification_context which indicates if the previous revision has signature or witness data, or if the current revision has transcluded resources. This will build the correct verification structure before verification. Change in the data-structure:\n when requesting a revision this is done via the GetRevisionHandler.php the previous verification hash is always served as well if signature or witness data is present in the previous revision, there is a flag (1/0) that this revision depends on the previous revision transcluded resources will be added to the content hash for verification Data Accounting Protocol v1.2 [TBD] Generalization of the Signature-Metadata to inform which signature method was used. GPG Signatures BTC Wallet Signatures Ethereum Wallet Signatures Done by: Displaying method used for signing, displaying underlying architecture. Including Account as part of the verified data structure Defining maximum payload size per revision Services on AQP (Not yet implemented, exploration) AQP-DACS: Domain Access Control System\n See: Guardian (Acting similar to a WebApplication-Firewall)\n ANS: Name-System and Name-Registry.\n See Aqua Name Resolution AQP-SSI: Self-Sovereign-Identity Protocol for Identity Claim management\n See Aqua Identity Protocol AQP Delegated Witnessing\n See Delegated Witnessing Similar Projects None of the listed projects apply the concepts of versioning to their documents, the concept of portable hash chains, the concept of personal data vaults for data management in comparison with the AQP reference implementation.\nThis following list is not exhaustive:\n Surety The oldest blockchain-like timestamping service which has been publishing to the New York Times since 1995. OpenTimestamp A free and open-source service provided by Peter Todd using the Bitcoin network as a distributed cryptographic clock. The AQP MAY use OpenTimestamp as a witness network. OriginStamp A company providing paid timestamping services for their customers. It looks very similar to OpenTimestamps with open-source client libraries. Factom Protocol A service which creates an architecture with an extra layer of blockchain, to provide an extra layer of trusted parties while providing their own token. In our opinion, it introduces unnecessary complexity and intermediaries as dependencies compared to the AQP. OpenAttestation An implementation of a timestamping service for document certification. One application of it is for secure digital vaccination certificates by the Singaporean government. They use the MetaMask Ethereum wallet for signing documents making it the most similar project to AQP to our knowledge. Blockchain Context DISCLAIMER: AQP is not a permissionless distributed ledger. In order for the AQP to be valuable and working, a single node implementation and single node deployments are sufficient, and do not require the witnessing part. The AQP MAY benefit from being published to a distributed ledger technology (DLT)) to achieve a witness event with high transaction security. AQP does not have a token nor is it distributing data by default.\nAs some concepts are very similar as those used in DLT’s, please refer to the following:\nA portable hash chain and its revisions are similar to a blockchain structure and its blocks, which has its own root hash and a set of transactions which are included inside.\n Blockchain Term\n AQP Term\n Explanation\n Transaction\n Input Data\n In a blockchain its a signed transaction. In AQP its all the input data provided to calculate the respective content slot hashes.\n Block\n Revision\n A block contains the Merklized list of transactions. A revision contains various hashed data inputs such as\n Content slots Metadata data Signature data Witness data Genesis Block\n Genesis Revision\n The first object in the hash chain / block chain.\n Blockchain\n Hash Chain The hash chain is not distributed but by default only in the local PKC, therefore it is not a distributed ledger. Furthermore the PKC is missing a consensus algorithm to create a shared truth between notes. A side note It has not escaped our notice that the provided AQP improves the existing process of double-entry bookkeeping and provides a foundation for a new data economy. This also allows to create unforgeable invoices which can be clearly attributed to its sender, avoiding fraud. This is one of many other use cases, e.g. providing trusted news via revision-controlled journalism.\n","categories":"","description":"High level outline of Aqua Protocol (AQP) specification\n","excerpt":"High level outline of Aqua Protocol (AQP) specification\n","ref":"/docs/protocol/whitepaper/","tags":"","title":"Whitepaper"},{"body":"The Aqua Identity Protocol (AIP) is an experimental application protocol under development for Self Sovereign Identity’s (SSIs) on top of the Aqua Protocol. This is an active field of research which is related to the work of the Decentralized-Identity-Foundation (DIF)1 and the World-Wide-Web-Consortium2. As this is under active development, anything you see is experimental and subject to change. The goal is to provide a Self-Sovereign-Digital Identity Protocol to protect individual rights, freedom and the opportunity for the individual to participate in the digital economy.\nWe are building on the advancements and insights for rebooting the web-of-trust initiative3 and the definition of a Self-Sovereign-Identity provided by Christopher Allen in shortened form here.4\nSelf-Sovereign-Identity-Principles Existence: users must have an independent existence. Control: users must control their identities. Access: users must have access to their own data. Transparency: Systems and algorithms must be transparent. Persistence: Identities must be long-lived. Portability: Information and services about identity must be transportable. Interoperability: Identities should be as widely usable as possible. Consent: users must agree to the use of their identity. Minimization: Disclosure of claims must be minimized. Protection: The rights of users must be protected. Those 10 stated principles are implemented within the Aqua Protocol and it’s existing reference implementation in various degrees. They are also represented in the Design Principles .\nArchitecture For the Aqua Identity Protocol to be implemented in accordance with the above statements, SSI-Principles and critical component choices from outside the protocol need to be made, and required tools need to be provided. Data Vault’s will provide a space which is fully account controlled. Other architectural decisions enabling SSI can be found in the reference implementation PKC Architecture Documentation.\nUsage of Data Vaults to protect identity claims Pages with the namespace : must be ‘read and write able’ by only by default. This is to protect the personal-identifiable data of the user. This data should be stored in a place where only the account owner has access to. This can be achieved by having the data stored locally on a machine the account owner has, or by using cryptography which requires the account’s owner explicit interaction to decrypt it. The content should not be decrypted on the server, but within the web-browser or client-application to ensure that a potentially compromised service-provider can’t leak the sensitive information.\n Identity claims are encrypted by default and can only be decrypted by the account owner or other accounts explicitly given permission to do so. Identity claims must be given access by the account owner to e.g. let somebody else sign them. Note: There should be an extra effort by any Data Vault implementation to protect identity claims. It is recommended to strongly regulate and audit the emerging solutions to ensure a high level of protection for citizens.\nSelf Issued Identity Claims These are used to make statements about an account to form an identity. Those claims can be partially revealed on demand to other parties. Those claims can also be protected by advancements in privacy technologies like Zero-Knowledge-Proofs and ongoing advancements in key management.\nIdentity claims are sets of Verified Data which follow a structured data convention to claim or attest attributes to an account. For example, an attribute could be the year of birth of an account owner, or the legal name of an account owner. Claims should always be atomic to allow the account owner to disclose them selectivity. Different claims can be combined to represent a citizen ID or a drivers-license. Other claims can be educational certificates, like school certificates.\nIdentity claims in the Aqua Identity Protocol are always self issues. This means that the first signature on the claim needs to be from the private key which belongs to the account, i.e. the claim is issued for. This proves account ownership. This means:\n All claims can only be issued from the account which they make a claim about. A claim belongs to it’s origin account and can only be managed from it’s address. A claim can ‘accumulate trust’ by being signed by other accounts who support this claim. Self-issuance protects accounts against spam, and the issuance of fraudulent claims to an account without the knowledge of the account owner. Claim Attestation Can be completed by a Trust Authority referring to the Identity Claim in collaboration with the account owner, or a referencing statement.\nIt is possible to attest to a claim by referencing the claim’s unique revision_verification hash within the attestation. This means you can make statements about an account or about a claim without involving the account owner in that process. An attestation contains a statement about the referenced data set, and is expected to be signed by the account who makes the attestation. This ensures there is clear account attribution. Attestations without signature should be disregarded, as they have no account attribution.\n Specification for the Aqua Identity Protocol Policies for Self-Issued-Identity-Claims:\n Syntax of Title: \u003cAccount (e.g. Ethereum Wallet Address)\u003e:\u003cAttribute (English Descriptive Title)\u003e Example: 0xa2026582b94feb9124231fbf7b052c39218954c2:Birthdate The title is not protected against changes, but the content of the page is protected.*IMPORTANT: Therefore, we must compare the page stored ,. Then reassemble the title to check if they are consistent before proceeding with further validation of the identity claim.\nContent of the page\n Account: Is repeated to reassemble the title to check it. Attribute: \u003cattribute_name\u003e Is repeated to reassemble the title to check it. Value: Is the value of the claim. E.g. ‘1889’ for a year of birth. The first revision must be signed by the account owner to create a self-issued identity claim Values must not change within a hash-chain. If a value changes, the claim will be marked as invalid with the revision of the change. If a new attribute value needs to be defined for an account, this is done through a new claim. Claim issuance Process\n Claim is created (based on template) Claim is signed by issuer (first revision) Claim is registered by issuer (optional, done via Claim Registry) Claim is verified by authority to accumulate trust (this might include the requirement to hold a revocation authority on a claim registered via a Claim Registry) Trust-Chains with Identity Claims\nWill build a web of trust, which can be applicable not only for public institutions, but also for commercial organizations and private entities.\nA trust chain of identity claims for educational certificates (example) The certificate is issued as integrity verified data via the Aqua Protocol. The recipient of the certificate registers the certificate as an identity claim The certificate is signed after it was issued as an identity claim by a Trust Authority (e.g. the university professor) and the university director’s office (director) The university professor holds trust claims from the university director The university director holds trust claims by the ministry of education The educational ministry of education holds trust claims by the minister-president The minister-president holds trust claims of a verified election The chain of trust is supplied by the party signing the statement.\n IMPORTANT: The authority who is given authority needs to prove where their authority originated when they act in the function of that authority.\n E.g. the professor needs to supply the claim of the university entitling him E.g. the university director needs to supply the claim of the educational ministry E.g. the educational ministry needs to supply the claim of the minister-president. … and so on. Verification Process Claim is presented Claim integrity is validated How can you trust the content of a claim: Claim content needs to be static. E.g. a given-name claim ‘Jarred Maxim’ cannot change, even if there are many revisions to the page. If the static content HAS changed, the claim is INVALID or at least only valid until the point where it changed. In the case of such an information change, a new claim needs to be issued. Claim registry is validated (root trust) Claim signatures are validated Comparison between signature time and validity of the signing authority. Is the account authority still valid? lookup of authority claims from expected root trust? Trust in Signatures If somebody signs an identity claim, we believe they do that to\n Vouch with their account for the integrity of the presented data. This can be supported via an Authoritative Claim and a comment which gets attached to the claim itself or is issued via an Attestation. To verify the signature, we use an automated verification process. This is done through implementations of an Aqua-Verifier like https://github.com/inblockio/aqua-verifier-js or https://github.com/inblockio/aqua-VerifyPage-chrome-extension which also checks against the restrictions given by the Aqua Identity Protocol or/and additional defined policies. Add access rights to a claim by adding a Data Usage Agreement which is enforced by the Guardian. Access rights can be restricted: to specific accounts to specific domain id’s representing an instance of a Data Vault Verification: The verification process considers which account it signed, and what was stated with the signature, or with the additional data added to the claim. To consider a claim valid, the relationship between the verifying party and the Trust Authority who signed it, is essential. Can the party be trusted? Why do I trust this party? Claims can be either chained (cascaded into each other) and offline verified, and/or online verified against an existing Claim-Registry. In both cases a known trusted party account reference point is required for the verifying party to trust. Trust Authorities are accounts which have an elevated trusted position. They issue Authoritative Trust Claims to give legitimacy to a self-issued identity claim.\nWhy do you trust a professor to issue an Educational Certificate ?\nBecause the professor is able to provide a trust chain, represented by a chained Authoritative Trust Claim , proving that he has authority to attest an Educational Certificate with his signature. With his signature, he is increasing the trust of the self-issued Identity Claim to allow it to have practical utility.\nClaim Registries A claim registry in the context of the Aqua Identity Protocol is a global registry to allow for real-time global claim revocation and re-instantiation of Identity Claim’s. This solves the problems related and known to certificate revocation. The Claim Registry acts like a global Claim Revocation List (CRL)5.\nE.g. a driver’s license can be revoked by a Trust Authority and later be re-instantiated after the ‘Punishment for driving too fast’ is over. Identity claims are either valid or invalid. The Claim Registry is managing who can revoke / re-instantiate a registered claim.\nThere is ongoing research and optimizations on privacy concerns to reduce costs for on-chain Identity Claim.\nImplementation in Ethereum with Smart-Contracts (Solidity). All claims are account bound.\nClaim Registration Specification - Smart Contract Structure\n \u003crevision_verification_hash\u003e as root trust of the self-issued identity claim. A claim has to be a verified page, which is signed and timestamped. If all are present, the next page-verification hash entangles all of those properties and becomes the ‘address’ of the claim. In the receipt of the publish process for the claim, there is an attached receipt, and by writing the receipt into the claim, there is also a new revision generated. This creates the second revision of the claim, which entangles the signature and the witness event with the hash-chain to make them immutable. [type:boolean] of claim 0 - valid 1 - revoked [type: date DDMMYYYY]: if current date past expiration date, the claim is considered expired and is not accepted anymore\n \u003c owner == sender address\u003e [type:address] an account which updates the status of the claim, e.g. revocation or suspension of an account\n \u003c additional revocation authority\u003e [type:address] list of accounts which are authorized to update status of the claim other than the owner. The owner has a special right to update the list of revocation authorities to hold new addresses.\n EXAMPLE: Claim Registration Data [Receipt]\n The presence of Claim Registration Data [Receipt] means that the claim address (verification hash) has been written to a Claim Registry on a Witness Network.\nProtocol: Aqua Identity Protocol Version 1.0\nRegistration Event: 1\n Domain ID: e9ece84189 Claim address (verification hash of self-signed claim): 1db331add502cf1b1712468d1c3e5d66a0016a6f04885c5533619ffbb43fffb6dfa452e119d4bee7628e9792af69089d38d860a5f8d0708184bbb74b8cabdaf7 - Merkle Root: 7e9782fb8a6e749ef2ba48f8cd410b05335ba48b20ba42508efeb76add38b0f39e717e91381c8de34641af4c477c39fc169eaa0908dba25e0a54e8de615fcd00 - Claim Snapshot Verification Hash: 278f930a35d06d7b9d28aab37d402c147d1beffdbe53d212481c17ec686698e9469f9cf7d7d53b9a4435c4b99ca2e578b5dc5fec6c63cb802b540493fe927575 Witness Network: goerli Claim Registry Smart Contract Address: 0x45f59310ADD88E6d23ca58A0Fa7A55BEE6d2a611 Transaction Hash: 0xa572e8d6ef8d4a1bb3b5087680817e70bb79a0376c3a9be9e2c6b4d92df228a1 Sender Account Address: 0xa2026582b94feb9124231fbf7b052c39218954c2 Claim Revocation Traditional revocation:\n Traditional strategies for certificate revocation can be applied.6 Most effective are short expiration dates where possible, due to the lack of effective revocation processes for certificates without global registries. Using Distributed Ledgers\n Done via Claim Registry (indicates the global status of an identity claim to be either valid or invalid) Process:\n Locally completed (within the Self-Issued Identity Claim) by changing the status to ‘revoked’ and signing by the issuer. This adds a receipt to the identity claim, which is displayed when verifying the claim. This includes the revocation transaction for the revocation on the Identity-Registry If there is a new claim which is succeeding the previous identity claim Claim Registry , then this is also noticed within the revocation receipt under ‘Successor-Claim: . Bulk Claim Registration (Should be part of Claim Registry)\n To reduce costs during registration of the identity claims via a Claim Registry they can be clustered and registered together We use the SmartContract:Identity-Registry for this. To scale our efforts we utilize a variant of the ‘Domain-Manifest-Generator / Publisher’ which is very similar. The differences are in the selection of what can be published, and the data structure which is published to the Claim Registry instead of the witness smart contract. The Claim Snapshot Generator can only include ID claims of your own namespace. The Claim Snapshot Publisher is registering all selected claims (select them by page name (filter required) and will populate the target SmartContract:Identity-Registry . Every claim will hold the relative merkle-proof to show the path for it’s registration. Examples for Identity Claims with Aqua:\n Example Identity Documents with PKC and Data Accounting Reference:Example Identity Documents (Research) FAQ How to find Claim Registry ’s? By following the chain of trust of authoritative claims and validating them one by one. How to check if authority is still valid and how to find an authority registry? As before, by reading the chain of trust and looking up the status of the related identity claims. How to visually check authority dependencies? It is possible to visualize the links of links of links to represent the chain of trust. Important References:\n Basic intro into DID Basic intro into DIDComm W3C Verified Data Model Revocation List 2020 A privacy-preserving mechanism for revoking Verifiable Credentials DIDCOMM implementations and use-cases DIDkit Thought leader Christopher Allen:\n Self-Sovereign-Identity-Principles A bitcoin based SSI infrastructure prototype See Implementation Specific Aqua Identity Protocol Implementation in MW e\n https://identity.foundation/  ↩︎\n https://www.w3.org/  ↩︎\n https://www.weboftrust.info/  ↩︎\n https://github.com/WebOfTrustInfo/self-sovereign-identity/blob/master/self-sovereign-identity-principles.md  ↩︎\n https://www.securew2.com/blog/certificate-revocation-crl-explained  ↩︎\n https://social.technet.microsoft.com/wiki/contents/articles/34071.pki-certificate-revocation-process-explained.aspx  ↩︎\n ","categories":"","description":"The following text has the goal to highlight the possibility to build identity protocol functionality on top of the core verifiction protocol. This part of the project is in early stages and not mature.\n","excerpt":"The following text has the goal to highlight the possibility to build identity protocol functionality on top of the core verifiction protocol. This part of the project is in early stages and not …","ref":"/docs/protocol/aqua-identity-protocol/","tags":"","title":"Identity Protocol"},{"body":"This section of documentation gets into specific details about the AQUA Protocol and is meant for those doing an implementation or contributing to the Protocol itself.\n","categories":"","description":"Low level reference documentation of the AQUA Protocol\n","excerpt":"Low level reference documentation of the AQUA Protocol\n","ref":"/docs/protocol/","tags":"","title":"Protocol"},{"body":"","categories":"","description":"Details various software that is implementing the Aqua Protocol\n","excerpt":"Details various software that is implementing the Aqua Protocol\n","ref":"/docs/implementations/","tags":"","title":"Implementations"},{"body":"ANS is used to resolve hashes of various types to human readable names.\nThe following hashes are resolved by the ANS:\n wallet-addresses to names, organisations an aliases. genesis_hashes to titles. domain_ids to registered endpoints of that domain. See the reference implementation .\n","categories":"","description":"ANS is used to hashes of various types to human readable names\n","excerpt":"ANS is used to hashes of various types to human readable names\n","ref":"/docs/protocol/aqua-name-resolution/","tags":"","title":"Aqua Name Resolution (ANS)"},{"body":"How safe are the wallets to used? - Current PKC Pilot - relating to the ‘Authentication assurance level’s (AAL)’ according to the World Bank standards:\nSee short presentation Aqua_PKC_-_Wallet-Security.pdf Level 1 The Metamask wallet alone has a low (level 1 ) level of assurance. MetaMask is the most common browser blockchain wallet applications on the web and their developer teams strive for increased security to keep crypto-assets of their 10 Million+ Users safe.\nLevel 2 Metamask offers integration with Hardware-Wallets which raises the level of assurance by having at least 2 authentication factors (e.g., a token with a password or PIN) to min. level 2. The Hardware-Tokens are build to be temper proof.\nLevel 3 It is possible to integrate the different layers of security at once with Metamask (Password Protection) a hardware-token (temper proof) with PIN a one-time-password generator based on your mobile-phone (recommended is a hardened mobile phone which also uses biometrics for highest security) requires implementation of one-time-password authentication for logins after wallet-authentication see https://github.com/inblockio/micro-PKC/issues/37 Other high security options allow multi-signature logins with smart-contracts requiring multiple parties to confirm the operation to be executed. This can be defined based on the smart contract to extreme security as each of the layers mentioned above can be added to each party being involved in the multi-signature event to open a PKC or to SIGN a verified page within the PKC or to witness a data set via a witness network.\n The mentioned security model is not dependent on the security of Metamask. If Metamask is hacked it will not allow to compromise the model above as the security of the private key of the hardware token is preserved.\n ","categories":"","description":"Highlights the levels of assurances you can receive by using technology provided in the Aqua reference implementation. \n","excerpt":"Highlights the levels of assurances you can receive by using technology provided in the Aqua reference implementation. \n","ref":"/docs/protocol/assurance-levels-aal/","tags":"","title":"Assurance Levels (AAL)"},{"body":"We first exchanged goods, then we used means to exchange goods, such as shells and coins. Today we use money. We have transitioned to a world where we present and exchange data to receive goods and services.\nThe system for accounting provided by Luca Pacioli, the double-entry accounting is the foundation of our work. We present a modern way to do double-entry bookkeeping for data.\nData accounting is the process of metering data in a standardized unit of exchange, and converting it into a form which can be exchanged to provide data symmetry between accounts.\nThe unit of exchange is not measured in a numeric value as found in cash systems. Data have multi-dimensional value, which means they depends on your perspective and your relationship to data. This determines how much this data-set is worth to the individual.\nThe standard measure of exchange is a hash, representing the state of the data. A SHA3-512 hash always has 128 characters, regardless of the size of the data it is representing.\nMetering data / anchoring data in space To meter data, we can refer to them using a digital fingerprint, i.e. their hash. This allows us to refer to the data in a consistent form. The hash has captured sufficient entropy to be unique, so it becomes a unique resource locator. This ensures that it is always deterministic to what data we relate to.\nAccounting data / anchoring data to account The second step is that the data is attributed to a specific account. This is achieved by using cryptographic signatures known as public/private key encryption . The public key acts as a unique account address. It is necessary that the accounts in use are globally unique, so there is no realistic probability of a name collision between accounts. This ensures that no data is attributed by mistake to two accounts or more.\nProof of existence / anchoring data to time The last step to account data is the usage of a cryptographically secure clock, so we know which data were witnessed first. Data can be replicated, so the value lies within the social implications of the message within the published data. This cryptographic timestamping allows us to determine the first account to witness the data. The most secure witness-networks which provide a service for cryptographic witnessing of datasets are Bitcoin and Ethereum. The first known examples of partial data accounting were done by Surety in 1995 and OpenTimestamps in 2012 .\nPractical accounting The accounting book in the data accounting age is a ‘data vault’ which is controlled by one or multiple accounts. This allows both personal data vaults or organizational data vaults.\nA data vault is controlled by a cryptographic wallet. The vault has the objective to govern the data for the account owner who is associated with the vault.\nThe vault provides a capability to export and import data, so it can be exchanged between data vaults. This allows for collaboration at scale, and the usage of data as a means of exchange.\nPlease contribute to this article (fixing errors) by exporting it and sending it back with your improvement to community[at]inblock[dot]io.\n","categories":"","description":"Introduces the concept of Data Accounting\n","excerpt":"Introduces the concept of Data Accounting\n","ref":"/docs/protocol/data-accounting/","tags":"","title":"Data Accounting"},{"body":"Author: Ben Koo E-Mail: koo0905[at]gmail[dot]com Year: 2021\nData Governance identifies how to manage the value of data. A well-known turning point in history was the publication of Luca Pacioli ’s Summa de arithmetica . This encyclopedia of mathematics, had 26 pages worth of text on what we call Double-entry bookkeeping . This became the foundational literature for accounting , the progenitor of using data to assign value to accounts, and henceforth gave birth to the practice of data governance.\nAccounting as the foundation of Data Governance According to historian Jane-Gleeson White12, Pacioli’s double entry book keeping idea influenced the development of arts, sciences, and capitalism. Double-entry bookkeeping as a rigorous approach to ensure data integrity, not only influenced the practice of the accounting profession, and it had a significant impact on the the formulation of Hamiltonian Mechanics , which is a foundational theory of both classical mechanics and quantum mechanics.\nSir William Rowan Hamilton wrote a paper3 cited many many scholars to demonstrate that many ideas about complex algebraic manipulation that laid the foundation of scientific revolutions are based on the formulation of creating accountable mathematical formulation strategies through double entry book keeping. David Ellerman had a paper that explains the powers of double entry bookkeeping in sciences4. The notion that creating public addresses for transactions amongst different accounts has been documented as a scientific theory on Double Entry Book-keeping. This book can be found online5:\nDigital Governance Given the intellectual roots of data governance have strong linkages to mathematics and accounting, it is only after the introduction of personal computing devices , and later the ubiquity of Internet access that made data governance an idea relevant to public affairs. The argument is that many people’s basic privacy and property rights may be challenged by people who have access to data collection and deployment technologies. Imminent threats such as fake news, big brother monitoring practices, identity thefts, and crypto currency issuance are already challenging the stability of the existing social fabric. These type of social debates are often related to the ideas of Digital governance . At this time, digital governance has not yet become a mature field of study, and it needs to be grounded in simple principles, so that it can be transparently practiced with local adaptations.\nConceptualization of Data Governance Beside the notion of digital governance, data as an asset class must be kept accountable, so that it can be evaluated, and transferred with an objective operational framework. Knowing how to organize data in formats that satisfy consistent abstraction strategies, such as Universal Resource Identifier and Universal Resource Locator are important starting points in this field. Earlier work in data governance in a web of hyperlinked media can be traced back to Project Xanadu by Ted Nelson .\nMore recent more publications in this fields are Lessig ’s Code v2 6 and soon to be published work of Alex Pentland ’s Building the New Economy 7.\nReferences J. Gleeson-White, Double Entry: How the merchants of Venice shaped the modern world–and how their invention could make or break the planet, publisher Allen \u0026 Unwin, ISBN:978-1-74175-755-2 , November 2011 ↩︎\n J. Gleeson-White, SIX CAPITALS, or CAN ACCOUNTANTS SAVE THE PLANET?, publisher Allen \u0026 Unwin, ISBN-10:9780393246674, February 2015 ↩︎\n Hamilton, S.W.R. (1837) Theory of Conjugate Functions, or Algebraic Couples: with a Preliminary and Elementary Essay on Algebra as the Science of Pure Time, Transactions of the Royal Irish Academy, 17pp. 293–422. ↩︎\n David Ellerman, On Double-Entry Bookkeeping: The Mathematical Treatment, https://arxiv.org/pdf/1407.1898.pdf  ↩︎\n J.C. Colt, The Science of Double Entry Book-keeping, online media: https://core.ac.uk/download/pdf/56693696.pdf , last accessed: May 4th, 2021 ↩︎\n L. Lessig, Code: And Other Laws of Cyberspace, Version 2.0, Publisher: Basic Books, 2nd Revised edition, December 2006 ↩︎\n Alex Pentland, Alexander Lipton, and Thomas Hardjono, Building the New Economy, MIT Press, Work in Progress, https://wip.mitpress.mit.edu/new-economy  ↩︎\n ","categories":"","description":"Introduces the concept of Data Governance\n","excerpt":"Introduces the concept of Data Governance\n","ref":"/docs/protocol/data-governance/","tags":"","title":"Data Governance"},{"body":"Describes the process of sending a domain snapshot to a remote data vault for witnessing. The domain snapshot is then included in the witnessing event and sent back to its original data vault. This makes the domain snapshot behave like an ordinary portable hash chain that can be witnessed. The relative path of the Merkle proof is used as a prefix for all other included portable hash chains included in the domain snapshot.\n","categories":"","description":"Describes the process of sending domain snapshots to remote data vaults.\n","excerpt":"Describes the process of sending domain snapshots to remote data vaults.\n","ref":"/docs/protocol/delegated-witnessing/","tags":"","title":"Delegated Witnessing"},{"body":"The following design principles pertain to Aqua reference Implementation PKC\nPrivate is Default The principle default to private is that no data of the PKC Data vault is shared without it being explicitly authorized by the associated account.\nDomain Access Levels Levels of access are:\nPrivate: Only the account owner has access to files and services initialized by his account. Agreement / Permissioned access: The Account owner grants other Account’s access to files or services based on verifiable contracts which are themselves written with the Aqua Protocol to ensure they are forgery-proof and therefore safe. Public: Other Account’s have access to the file or service without agreements.\nOffline Capability The PKC Data Vault follow’s the principle of being able to run and be functional without internet connection after setup or through installation based on local installation files.\nThis allows PKC setups to be kept offline from any internet connectivity while still functional. This can provide the required assurances for very sensitive data.\nSeparation of Account and Service Concern: There is a trend in the DIF/WC3 Identity space that some players like to accumulate personal identifiable data (PII) inside of Wallets. We think this is a ill-fated direction and there should be a clear separation between account and service. Wallets should not hold personal identifiable data.\nBenefits:\n If the service gets hacked, no account related data is leaked if it’s not stored. Account is not compromised, as there is no password saved within the service with Password free login. Wallet ’s have one job. Keep private keys safe! (Account Management) Should be stupid, simple, safe! Allowed operations: Signing De- / Encrypt Publishing transactions to service (e.g. witness networks) Ability to choose “high level of assurance” depending on the stakes associated with the account(s) managed by the wallet Takes care of key recovery mechanisms Data Vault (Service)- Has one job: keep the data safe! Principle: Offline Capability so it can run offline; works offline on local machine All significant actions authorized and managed though the wallet Should offer good tooling for data storage and manipulation Strong access control: By Principle: Default is Private which means data is only accessible by the owner. Data is well protected The Data Vault should apply additional security features to keep the data safe. e.g. Encryption of files / databases if service is not used. e.g. Encryption of pages with web-decryption (allowing for End-to-End Encryption). Capabilities for sharing and publishing data Offers full Backup and Recovery mechanisms to move data freely Principle: Data Portability Signature Login We do not use passwords for login but instead we use a signature of a private key to authorize access to a service. This increases security and does not require the user to remember a password, creating a better user experience.\nPros:\n* Account owner uses his wallet to complete a signature challenge for login. With this challenge he proves that he owns the private key to a public key. If the public key is registered as an account at the service, the account is granted access.\n The password can’t be leaked as it does not exist. Very high security Contra:\n* Requires access to the wallet which holds the private key to authorize access\n Not commonly understood by users as a way to login (new process) Principle: Data Portability The Principle of Data Portability means that the Account owner can instruct the Service to Export all data associated with the Account and is free to move this data to a new service which is capable of importing the data.\nImplementation Specifics In PKC’s this is guaranteed by:\n* providing a Backup and restore procedure which allows to move data between PKC’s and restore them in case of a required recovery.\n providing a file import and export function providing an import / export API Furthermore we ensure with the development of the MediaWiki Data Accounting Extension, that the data is still compatible with the legacy import / export (which means only the text not the verification data is imported / exported.\n","categories":"","description":"Lists the design principles underlying our reference implementation\n","excerpt":"Lists the design principles underlying our reference implementation\n","ref":"/docs/protocol/design-principles/","tags":"","title":"Design Princiciples"},{"body":"Context It is highly problematic to expose sensitive data, such as personal identifiable data, to the internet. The service who hosts that sensitive data, needs to be compromised only for a short amount of time, to leak all the data. Often caused by configuration mistakes or by vulnerabilities being present in the used technology stack.\nWe can’t effort to have leaks on personal-identifiable data in data vaults. To raise the bar on making attacks difficult and reducing the chance of leakage of information, we introduce the Guardian as a extra security layer to protect services like the PKC from attacks.\nSummary The Guardian is a software which manages the boundaries of your digital domain. Guardians are used to connect to secure transport networks (HTTPS, Matrix Network, Didcomm) and publishing networks (e.g. Swarm.eth). The Guardian is used to build trusted connections to other Guardians via trusted transport-layers to exchange data with them. As the Guardian connects to other Guardians, it also manages all connections to services in it’s domain and access to those services.\nGoal Secure all services behind the Guardian from attacks and unauthorized access. Keep the data vault and it’s data private and safe, while enabling the ability to exchange data with other Guardians.\nHow Enforcement is handled on each connection and each data set so that services behind the Guardian are never directly exposed. This makes the Guardian the most security sensitive component in the Aqua reference implementation, as we expect the Guardian to handle all incoming and outgoing traffic. The Guardian enjoys additional attention and effort to be up to it’s task by hardening it and applying security best practices to ensure that it is fulfilling it’s security promise to keep services behind the Guardian safe.\nEvery transaction leaving or wanting to enter your domain will be supervised and checked by the Guardian. The core functionality of the Guardian is a library to verify the Aqua Protocol. Only if the verification succeeds additional steps are introduced to make decisions how the data is handled.\nThis allows the Guardian to read and understand Aqua verified data. This allows for the implementation of a wide set of behavioral rules and offers the opportunity to create various ‘Smart contract’ languages on top of it.\nThe Guardian verifies a file, reads its contents and checks it’s permissions to classify if an action is considered legal or illegal, permitted or denied. Basic functionality for a Guardian can be compared with a traditional firewall, or a application firewall but is much more sophisticated to manage access on the data-level.\nTerminology: Proving ownership over a domain by signing the domain ID with an self-issued identity claim which is also registered in a claim registry to ensure nobody claims to have owned that domain before by manipulating the digital clock and faking an earlier owner-ship claim over the domain.\nPermission Agreements / Data Usage Agreement / Access Rights are contracts which represent the terms and conditions under which files and/or services are shared with other accounts and/or their digital domains.\nBy nature those Permission Agreements will be compiled through pages and stored as files. To form an agreement, the other party must be notified about new resources as they become available. For example, when we share a page with another account. To complete a permission agreement, the counter party has to sign the permission agreement or reject it. If the permission agreement is signed, the other party enters a contractual relationship in which they will be liable for any agreement violates executed from their digital domain.\nProcesses Domain Handshake Establish trust between two Aqua domains. For this we have Alice and Bob which want to establish trust between their domains. They both have a Guardian in place to protect their data vaults.\nSteps:\n Alice: Create access contract: I \u003cAlice_account\u003e want to connect from my \u003cdomain_id\u003e to a \u003cdomain_id\u003e controlled by \u003cBobs_account\u003e with my \u003calice_domain_id\u003e via the following channel: DNS/HTTPS via \u003calice_Guardian.domain.com\u003e. Alice: sign contract Alice: SEND contract send the page via ‘mail’ / ‘matrix’ whatever to the remote PKC instance. Bob: veries the contract contract and imports it Bob: extend contract: I \u003cbobs_acocunt\u003e connect my PKC \u003cbobs_domain_id\u003e to your PKC \u003cAlice_domain_id\u003e via my Guardian_endpoint \u003cbobs_guardian.domain2.com\u003e. Bob: sign extended contract: Bob uses his wallet to sign his extended contract. Bob: send extended contract TO Alice: Bob sends his Contract to his Guardian. Bob’s Guardian: Verifies and sends the contract to Alice Guardian. Alice Guardian: Guardian verifies all data Sends OK back to Bob’s Guardian Sends Updates contract into Alice PKC Waits for Bob’s Guardian to request available pages Bob’s Guardian requests a list of pages: ' What pages do you share with me?' Alice Guardian: Returns list of accessible resources for Bob Example: Sharing a File Target: Sharing a file with another account. Using two Aqua data vaults with their two Guardians to manage access to them. We assume the Guardians already have executed a handshake to enter a trusted relationship. We also assume, that the file should underlay access basedon account restrictions and domain restrictions.\nExample 1: Sharing a file without additional constrains with another account.\nAlice wants to share her page ‘My secret research’ with Bob. Their Guardians have already formed a trusted connection. What Alice needs to do now is to add a sub-page with an immutable link under the ‘My secret research’ page and define access. To be able to define access Alice needs to have a claim over the ownership over the domain she is sharing from.\nAlice creates an Access Permission for the whole page or for a single revision by creating a page with the following syntax:\n \u003cgenesis_hash\u003e:access_contract\n To give access to the whole page with all it’s revisions.\n \u003crevision_hash\u003e:access_contract\n To give access to a specific revision.\n Content of the page:\nI Alice give access to Bob \n option 1: to the whole page including it’s history \u003cgenesis_hash\u003e option 2: to the following revision \u003crevision_hash\u003e‘My secret research’ Additional one-sided conditions:\n This access contract expires in 7 days This contract will come into place with my signature.\nThe Guardian will react to a specific syntax of pages holding contracts, agreements and access rights to adjust his network access rights accordingly to it. Alice-Guardian will respond to the question what resources are shared by Bobs-Guardian with the answer that there is a new page available according to the access contract which now gives Bobs-Guardian the ability to query the content of ‘My secure research’ from Alice according to the contract. Depending on Bobs-Guardian setting, the Guardian might automatically load the resource and forward it into the post-box of Bobs Data Vault.\nExample 2: Sharing a file with constrains forming a contract to do so.\nSame as 1 expect that for the contract to come into place, Bob needs to sign the contract from Alice containing additional constrains.\n Content of the page:\nI Alice give access to Bob \n option 1: to the whole page including it’s history \u003cgenesis_hash\u003e option 2: to the following revision \u003crevision_hash\u003e‘My secret research’ Under the following conditions:\n Do not share outside your domain \u003cBobs-domain_id\u003e Do not share with any body else (Bobs domain can’t have another account registered to it, if there is an account registered the Guardian of Bob will say that Bobs domain does not fulfill the requirements to establish this contract. Do not modify it. Delete it after 7 days. For this contract to be valid, signatures of first Alice and then Bob need to be present. This means, after Alice signed the access contract, the contract is a new available resource to Bob to be loaded. Bob can now sign the resource in his domain and return the contract. Leading to the contract send back to Alice domain and being updated there. Bob now gets access to ‘My secret research’ which has been updated as well, to contain via an immutable link the access contract.\nPermission Templates, Complex Permissions (Groups and more)\nIt is possible to apply complex permissions based on templates, or and connecting multiple access contracts by using\n instead of this syntax \u003cgenesis_hash\u003e:permission_agreement the following the syntax \u003cgenesis_hash\u003e:\u003cgenesis_hash-2\u003e in which the \u003cgenesis_hash-2\u003e contains a list of sub-pages with access contracts which can be used to apply access via permission-objects which are represented by the \u003cgenesis_hash-2\u003e page object. Alice wants to If the user wants to propose changes to the page, he will send an updated PAGE FILE to the OWNER of the PAGE. The owner can decide to ACCEPT the changes. Or to include the changes in the HISTORY File, but not COMMIT them. Or to NOT include the update of the PAGE, and disregard it. Specifications: The Guard Daemon checks if there is digital contract present in his domain. Those contracts set permissions for allowing a counter party to access a service or resource (like a file or a page, or a revision). It’s also defining the constrains under which permissions access is given. In this case it requires the digital signature of the receiving party for the agreement to come into place and be valid.\nGuardians have administrative access to the services they manage. Therefore they can supervise the activities of services and use them as triggers to e.g. provide access according to a set permission without additional user action.\nGuardian Components: APIs\n System-API to control a service via a service specific library. Each services will have their own control-library and control API to create an abstraction layer which allows for a unified control logic in the Guardian.\n E.g. an account is allowed to access a service E.g. a resource is shared with an account E.g. a trust relationship between two services is established (based on an agreement between two accounts) to exchange data Implementation Specific PKC: All interactions for system interaction with MediaWiki / PKC Execute Actions: Move, Update, Edit, Delete Pages Request send to the Guardian: Verify a specific page or a list of pages Data-API to retrieve Aqua-Data between a service and the Guardian, or between two Guardians.\n Send data to import API Read data via export API Implementation Specific PKC: Read special Pages used to give access e.g. Data Usage Agreements, Permission Agreements Aqua Verification Library to be able to verify incoming and outgoing data\n implementation of the ‘external-verifier’ in e.g. GO, Typescript or Javascript (current) Account-Registry (Holding the list of trusted keys and the relationship between them)\n This includes defined ‘trusted accounts’ Session-Handler/Registry (Acts like Stateful-Firewall on the page-object level to mange imports / exports). The Guardian verifies incoming and outgoing data and constructs sessions based on it.\n Guardian Policies: Are sets of rules followed and enforced by the Guardian. This includes set of rules used to protect the domain from unauthorized operations and access. Part of that are page access permissions which are managed by the Data Usage Agreements .\n \u003cdomain_id\u003e\u003cgenesis_hash\u003e\u003crevision_hash\u003e:\u003cdomain_id\u003e\u003cgenesis_hash\u003e\u003crevision_hash\u003e Transport Layer API’s / Sub-Modules for connectivity to distributed services\n The Guardian-to-Guardian communication handler (via DNS/HTTPS transport) Ethereum Integration, Ethereum Handler (As a witness Network) Matrix Integration, Matrix Handler (As a restrictive/ permissioned transport layer) Schwarm Integration, Swarm Handler (As a publishing network) Guardian-Integration-Services The Guardian has a modular design to support integration with many services and transport layers.\nWeb (HTTPS / DNS) Integration Goal: Have a handler to connect web-facing Guardians with each other in a safe way. Be able to run guardian procedures via two public Facing guardians which use a public DNS name and HTTPS to interconnect with each other. Guardian procedures are: Guardian handshakes to establish trust or remove trust Request or Send portable Hash-Chains based on access rights between each other\nEthereum Node Integration Goal: Connect to a self-hosted or remote Ethereum Node. Option 1: Configuration via Alchemy (Providing Keys) via Special:DataAccountingConfig Option 2: Implementation of Ethereum Node via ./setup –ethereum-node (provide container) Configuration of Connection to RPC Ethereum node via address (if in same network) The Wallet can be directly be connected to a local Ethereum node via RPC to avoid meta-data gathering of large providers, like INFURA which could potential track which IP address has created which Ethereum Transaction with which Metamask-Wallet, leading to a de-pseudonymousation of the user. ### Ethereum Node Handler Goal: Accelerate lookups of the Guardian via caching Every-time a witness contract is called, the Ethereum Node Handler will start to cache the all Ethereum-Witness events of that Witness-Contract and Index them in it’s database. This will reduce access times to ms vs potential seconds in lookup times, making the Guardian more performant and responsive. ## Matrix Node Integration Goal: Connect to a self-hosted or remote synapse-server (MATRIX) Node. Configure a remote matrix server or a local one via Guardian. Implementation of Matrix-Node deployment via ./pkc setup –matrix-node (provide container).\nMatrix Node Handler Context: We use Ethereum Wallets as Identity-Anchors as they are globally unique addresses (which are collision free) broadly adopted with supported hardware ledgers as secure hardware elements with an existing fast moving ecosystem for further development. They act as ‘web-based’ PGP-like utilities which do not need any Blockchain-Interaction for Signing messages and can be used as a valuable off-line capable identity anchor. With this step we separate Identity and Service; even in case of compromising the computer of the user or by having a breach of secrets in the Element-Client the Identity would be safe (in case a hardware wallet would be used). This also drastically reduces attack surface to phish a users credentials; as there is no Password-Login there is no way to steal the password to impersonate the user. All security assumptions of the User-Identity come back to the security of his private key. For the Kolibri/PKC project this is the foundation for using wallet-addresses as Identities to route traffic with matrix bots between PKC’s. The following actions are required to use the Ethereum Wallet as a strong Identity Anchor within Matrix.\nThis requires the following functionality:\n Register the user via an Ethereum wallet address (successfully piloted by inblockio) Detect that it is an Ethereum Wallet-Address; Verify integrity of address with the Ethereum Wallet-Address Checksum (TBD) Make username not changeable (Done via Matrix settings,successfully piloted by inblockio) Wallet login with Web-Wallet Metamask via OIDC (Open ID Connect) (successfully Piloted by inblockio) Verify Ownership of the Wallet by doing an Element-Client side Signature Challenge to the User. Challenge resolved by signing a message with sufficient entropy to not be ever the same (to protect against leakage) with the private key via the Ethereum Metamask Webwallet (or a connected Hardware-Wallet) Implement a User-to-User request of proof of Identity Users / Server can challenge other users to proof that they hold the private Wallet-Key by triggering the Signature Challenge to the User; After the challenge is done, the requested party is provided with all information to do a manual verification of the signature (the Message which was Signed, the Signature, the used method used for the signature) Matrix-BOT Context: The Matrix-Network communicates with the PKC through the Guardian who will manage all access to the MediaWiki service. The Guardian uses a Matrix-Bot (to handle the communication) and a Matrix-Integration (to be flexible to use a private synapse or a remote synapse server) to interact with the Matrix Network as a permissioned transport layer.\nReferenz-Implementation: Suitable options for a matrix-integration are ‘go-lang’ or ‘rust’. Guardian next generation Guardian will be written in Rust, so integration of security relevant components would be preferably in Rust and Webassambly. A central point to configure the guardian to connect to matrix and other services needs to be provided. The matrix server is connected to the guardian with a service bot which is able to open rooms to exchange revisions between PKC’s.\nRequired Functionality of the Matrix-Bot:\n open new room for user (required) - to share resource invite / remove other users to/ from room (required) - to set permissions who can read shared resource close room (required) - after resource share is revoked join a room the user is invited too (by other matrix-bot) *‘accept invite’ check for challenge (provided via text from remote Guardian), leave room if challenge is faulty and block user (required) delete? room / delete history? Note: Use matrix only as channel not as storage (optional) preferably the history of the channel is not kept post content of (mediawiki API query results from the Guardian) into a room (required) read content of room (send it to the Guardian for verification, before it’s send to the import API) (required) ","categories":"","description":"Shows access and transport layer logic used to interconnect data vaults\n","excerpt":"Shows access and transport layer logic used to interconnect data vaults\n","ref":"/docs/protocol/guardian/","tags":"","title":"Guardian"},{"body":"The following are documentation used to understand the AQUA Protocol and it’s implementations. AQUA is heavily under development at the moment and is evolving rapidly.\n","categories":"","description":"","excerpt":"The following are documentation used to understand the AQUA Protocol and it’s implementations. AQUA is heavily under development at the moment and is evolving rapidly.\n","ref":"/docs/","tags":"","title":"Documentation"},{"body":"Traditional hyperlinks are usually URL’s based on the DNS structure.\nThis allows the resource to be routed via DNS and specified via the URL on the remote server.\nThe limitations of URL’s is that they are not expressing a specific state of the resource they represent. There is no way to verify if the content of the page is consistent with the content of the page who send a URL. For news pages this means that the content of the page could have changed. E.g. two visitors of the same news page could see two different pages.\nWe need a better way to hyperlink so it’s sure, that what is linked is consistent across domains and users. Therefore we introduce Aqua URI’s which are used to enable the receive to verify the state of the resource.\nGoal Use Immutable Hyperlinks as Unique Resource Identifiers (URI’s) to allow a consistent referenciation of resources with the ability to verify them with the AQP.\nSuccess Criteria A Immutable Hyperlink schema which links to a specific state of a resource. Instead of a stateless hyperlink we use verification_hash as a URI which acts as the checksum to verify the retrieved revision.\nInput file upload wizard is executed with file-data and description as input file is stored with in the service triggering a hook leading to the calculation of verification_hash (calculated with the file as input for content_hash) which is stored in the revision_object (file or database) Output\n When linking the file it’s displayed in the following format: [SHA3-512 Hash|Descriptor Text]\nBoundary conditions File is too big to be hashed. We support currently up to 50 MB. File can’t be hashed for some reason (error during the process to due an unexpected code execution) File is empty (has no content) Implementation We create Immutable Hyperlinks by moving from URL’s to sha3-512 hashes as URI’s. These URI’s are globally unique and therefore collision resistant as the namespace is sufficiently large. By using the hashes as links we also refer to the state of the resource. As the hash is the verification_hash of the resource it allows us to verify the integrity of the resource with it.\nWe are referring to files with their SHA3-512 hash in this format [SHA3-512|human_readable_filename]. Displayed is the human readable filename white it’s stored with the full SHA3-512 hash which allows us to be used as Immutable Hyperlinks.\nTo allow routing between resources we can add the \u003cdomain_id\u003e as a prefix to the \u003cverification_hash\u003e resulting in the following syntax:\nexample: aqua://\u003cdomain_id\u003e/\u003cpage_verification_hash\u003e\nNote: Implementatstion specific to aqua-PKC:\n The verification_hash is stored in the content-slot ‘transclusion hashes’ with the internal links which referne the resource. ","categories":"","description":"Shows how the Aqua URI's can be used as immutable links.\n","excerpt":"Shows how the Aqua URI's can be used as immutable links.\n","ref":"/docs/protocol/immutable-hyperlinks/","tags":"","title":"Immutable Hyperlinks"},{"body":"","categories":"","description":"","excerpt":"","ref":"/docs/contribution-guidelines/","tags":"","title":"Contribution Guidelines"},{"body":" #td-cover-block-0 { background-image: url(/featured-background_hu557b5587fe5dc558d8bb115acefce0a8_95557_960x540_fill_catmullrom_top_3.png); } @media only screen and (min-width: 1200px) { #td-cover-block-0 { background-image: url(/featured-background_hu557b5587fe5dc558d8bb115acefce0a8_95557_1920x1080_fill_catmullrom_top_3.png); } } Welcome to the AQUA Protocol! Whitepaper Source Code A simple and novel approach to prove integrity of data, authorship, and time! The AQUA Protocol is an emerging open-source protocol for data verification which is built with modern cryptographic standards. The AQUA Protocol is not and does not require a blockchain!\n AQUA Protocol is made possible by crypto,\nas in cryptography! Demo PKC Node Personal Knowledge Container (PKC) is the reference implementation of AQUA Protocol.\nTry PKC now \n Contributions welcome! We welcome feedback, bug reports, ideas, or contributions code and documentation alike.\n Our Github \n Follow us on Twitter For announcements and updates about our progress on the AQUA Protocol\n Read more …\n ","categories":"","description":"A simple and novel approach to prove integrity of data, authorship, and time!","excerpt":"A simple and novel approach to prove integrity of data, authorship, and time!","ref":"/","tags":"","title":"AQUA Protocol"},{"body":"","categories":"","description":"","excerpt":"","ref":"/categories/","tags":"","title":"Categories"},{"body":"","categories":"","description":"","excerpt":"","ref":"/community/","tags":"","title":"Community"},{"body":"","categories":"","description":"","excerpt":"","ref":"/search/","tags":"","title":"Search Results"},{"body":"","categories":"","description":"","excerpt":"","ref":"/tags/","tags":"","title":"Tags"}] \ No newline at end of file diff --git a/search/index.html b/search/index.html index 7b72e66..d346ba2 100644 --- a/search/index.html +++ b/search/index.html @@ -20,10 +20,10 @@ - + - + @@ -52,7 +52,7 @@
    -
    +
    diff --git a/sitemap.xml b/sitemap.xml index ca4a03e..f5b96d2 100644 --- a/sitemap.xml +++ b/sitemap.xml @@ -1 +1 @@ -https://aqua-protocol.org/docs/overview/2024-06-13T18:06:19+02:00https://aqua-protocol.org/docs/implementations/reference-architecture/2024-06-13T18:06:19+02:00https://aqua-protocol.org/docs/protocol/whitepaper/2024-06-13T18:06:19+02:00https://aqua-protocol.org/docs/protocol/aqua-identity-protocol/2024-06-13T18:06:19+02:00https://aqua-protocol.org/docs/protocol/2024-06-13T18:06:19+02:00https://aqua-protocol.org/docs/implementations/2024-06-13T18:06:19+02:00https://aqua-protocol.org/docs/protocol/aqua-name-resolution/2024-06-13T18:06:19+02:00https://aqua-protocol.org/docs/protocol/assurance-levels-aal/2024-06-13T18:06:19+02:00https://aqua-protocol.org/docs/protocol/data-accounting/2024-06-13T18:06:19+02:00https://aqua-protocol.org/docs/protocol/data-governance/2024-06-13T18:06:19+02:00https://aqua-protocol.org/docs/protocol/delegated-witnessing/2024-06-13T18:06:19+02:00https://aqua-protocol.org/docs/protocol/design-principles/2024-06-13T18:06:19+02:00https://aqua-protocol.org/docs/protocol/guardian/2024-06-13T18:06:19+02:00https://aqua-protocol.org/docs/2024-06-13T18:06:19+02:00https://aqua-protocol.org/docs/protocol/immutable-hyperlinks/2024-06-13T18:06:19+02:00https://aqua-protocol.org/docs/contribution-guidelines/2024-06-13T18:06:19+02:00https://aqua-protocol.org/2024-06-13T18:06:19+02:00https://aqua-protocol.org/categories/https://aqua-protocol.org/community/2024-06-13T18:06:19+02:00https://aqua-protocol.org/search/2024-06-13T18:06:19+02:00https://aqua-protocol.org/tags/ \ No newline at end of file +https://aqua-protocol.org/docs/overview/2024-09-10T02:21:48+08:00https://aqua-protocol.org/docs/implementations/reference-architecture/2024-09-10T02:21:48+08:00https://aqua-protocol.org/docs/protocol/whitepaper/2024-09-10T02:21:48+08:00https://aqua-protocol.org/docs/protocol/aqua-identity-protocol/2024-09-10T02:21:48+08:00https://aqua-protocol.org/docs/protocol/2024-09-10T02:21:48+08:00https://aqua-protocol.org/docs/implementations/2024-09-10T02:21:48+08:00https://aqua-protocol.org/docs/protocol/aqua-name-resolution/2024-09-10T02:21:48+08:00https://aqua-protocol.org/docs/protocol/assurance-levels-aal/2024-09-10T02:21:48+08:00https://aqua-protocol.org/docs/protocol/data-accounting/2024-09-10T02:21:48+08:00https://aqua-protocol.org/docs/protocol/data-governance/2024-09-10T02:21:48+08:00https://aqua-protocol.org/docs/protocol/delegated-witnessing/2024-09-10T02:21:48+08:00https://aqua-protocol.org/docs/protocol/design-principles/2024-09-10T02:21:48+08:00https://aqua-protocol.org/docs/protocol/guardian/2024-09-10T02:21:48+08:00https://aqua-protocol.org/docs/2024-09-10T02:21:48+08:00https://aqua-protocol.org/docs/protocol/immutable-hyperlinks/2024-09-10T02:21:48+08:00https://aqua-protocol.org/docs/contribution-guidelines/2024-09-10T02:21:48+08:00https://aqua-protocol.org/2024-09-10T02:21:48+08:00https://aqua-protocol.org/categories/https://aqua-protocol.org/community/2024-09-10T02:21:48+08:00https://aqua-protocol.org/search/2024-09-10T02:21:48+08:00https://aqua-protocol.org/tags/ \ No newline at end of file diff --git a/tags/index.html b/tags/index.html index cf1a9ed..30da2e8 100644 --- a/tags/index.html +++ b/tags/index.html @@ -49,7 +49,7 @@
    -
    +