Tech Concepts acting as building blocks of Gaia-X

Zero Knowledge Proof: 

Imagine you visit a Bar with your friends and are stopped at the Gate. You are all required to show an “Age Proof” before you can enter. What would you do? Almost all people in such scenarios would flash any valid document that shows their Date of Birth, e.g. Passport. Now think again, were you required to share your D.O.B or only to prove that your age was above 21 years?

A Zero Knowledge proof means when you can prove to that gatekeeper at the bar that you are of an age above the permissible age limit and can be permitted to go inside, without actually having to share your D.O.B or any other information. In other words, such a solution can be used to protect data privacy and sovereignty while still being able to share meaningful information derived using that data.   

Hash Function:

A Hash function generates an output for each given input data. And it generates the same output each time you feed the same input. The smallest change in input data will result in a totally different output. 

Let us take an example to understand how this simple function works and can be useful. 

Case: Company A and Company B have negotiated a contract. The terms of the contract have been discussed and during their last meeting, the contract document was read and finalized by both parties in tandem. Now, the meeting took place at the premises of Company A. So, it is decided that the Company A representative will get the contract digitally signed by their CEO and send the signed document to Company B for their CEO’s signature. 

On receiving the Signed digital contract from Company A, Company B has two concerns:

• To ensure that nothing has been changed in the final approved draft document
• To verify that the Signature belongs to the CEO of Company A and is valid and enforceable.

So, Company B asks for two things from Company A:

1. A proof of Signature of the CEO of Company A (a secret/password not shared publicly)
2. A Hash is generated by inputting the contract data along with the secret 

Company B then goes on to generate a Hash themselves using the Draft copy of the contract they had from the last meeting and the secret/password shared by Company A. If both Hashes match, they have verified that the signature was from the CEO and that the contract is exactly what they had approved. 

Thus, Hash Functions can help you verify two things:

1. Who sent the data
2. The sent data is as promised and not modified. 

The only problem in using Hash functions is that the password / secret message was required to be shared by Company A CEO. PKIs help achieve the above two without sharing the password / secret. 

Understanding Public Key Infrastructure (PKIs)

PKIs are built on Public Key Cryptography or Asymmetric Cryptography, which uses Key Pair to solve the above problem. A key pair is generated, with one public key and one private key. 

• The Private Key remains private with the entity that generates it. It is used as a means to sign any claims they raise with respect to the data they share or with  any shared identity. 
• Public Key can be shared with anyone (public) safely. It can also be used to verify the Signature done by a holder using a matching private key. 

There are two things that the key pairs enable:

1. Data can be encrypted using a Public Key. The only way to decrypt the data is by using the corresponding Private key.
2. The owner  of Private Key can sign some data with Private Key. Anyone who knows the public key can verify the signature and confirm the private key was used to sign it. 

Now let us go back to the above Case. If Company A had the key pair, they would share the Public Key and the contract signed using the Private Key with Company B. Company B could verify the signature using the Public Key of Company A and compare the Hash of both documents, the one received with signature and the draft copy they have. If signature verification and Hash matching both work, they can trust that:

1. Company A signature is trustworthy
2. Contract terms have not been altered. 

In addition to the above, key pairs and thus PKIs have another important property called 

non-repudiation, i.e. - A private key holder cannot deny the fact that they signed some data. 

Further, if Company B wants to share some data with Company A and restrict the access of this data to Company A only, they can do so by encrypting the data using Public Key of Company A. The only way to decrypt such data would be by using the Private Key held by Company A and hence the data would not be accessible to anyone other than Company A. 

Certificates:

In simple terms, certificates are data structures that bind the name to a public key of an entity or individual. It is accompanied by the signature of the issuer. The signature is done by the issuer using their private key. Certificates are the best way to identify code and devices, and identity is super useful for security, monitoring, metrics, and a million other things.

In order to understand this, let us compare the issuance of your passport with a certificate in your name:

Now, if I trust the passport issuing authority, I can trust your claim on your name, address etc by matching your photo on the passport with your face. Likewise, if I have the public key of the issuer of the certificate, I can verify their signature using the public key and trust the claim about your public key. 

Thus, if any document/data is received from you with your signature done using your private key, accompanied by your certificate, I can trust that the document has been signed by you by verifying your signature using your public key on the certificate. But for this to hold true, I should trust the issuer of the certificate. The issuers share their  certificate, i.e. Root Certificate along with the issued certificate to facilitate verification of their signature against their Public key. This needs to be hosted publicly for anyone to verify the authenticity. 

Thus, once you have a certificate issued by a CA to you, you can use your private key to sign any claim you make or data you generate, and the user/receiver of the data can verify that it is signed by you with the help of your Public Key on the certificate, as long as they trust the issuer of your certificate. 

DID, VC / VP:

Until now, we have understood how a certificate issued by an issuer can have identifiers that help to identify a person, entity, or thing. The certificate can be physical, for example passport / driving license etc or digital credential issued by a Certificate Authority like Let’s Encrypt or T - System (trusted partner of eIDAS). Once such a digital certificate is received by your company however, unlike physical certificates, now it is possible for you to use this Private Key to sign various documents / claims, which can be verified using your public key. But first, this certificate along with your public key as well as the root certificate of the issuer is required to be hosted somewhere so it can be fetched and checked at any stage. In case of Gaia - X, the same is done by creating a Domain for the subject (person, company etc).

The DID stands for Decentralized Identifier. It consists of three main parts in form of text strings in a format example given below:

Did:example:123456789abcde

Here, DID is the URI (unified resource identifier) scheme identifier, ‘example’ is the identifier of ‘DID Method’ and ‘123456789abcde’ is ‘DID Method specific identifier’. There are many types of DID Methods, one of which is WEB, and it is this method of DID that has been chosen by Gaia - X as the valid DID Method for all its transactions. Most importantly, the DID is self generated i.e. - You issue it to yourself. Thus you can control the information you want to share while generating the DID. 

The DID:Web thus created can be resolved in a browser using a Universal Resolver, which basically means it resolves to show a DID Document. This DID Document usually has the DID, the issuer ID as well as the Verification Method which encompasses the Public Key. Ideally, it should also have a URL to access the Root Certificate of the issuer of certificate, which is also required to be hosted by the Subject. It can, however, have more information than this. If it also has a claim added to it, it is called a verifiable claim.

Let us take an example to understand this. You completed your degree from Harvard Law School. The college provided you with the Degree certificate and the Transcript. Now, while applying for a job, you share copies of these documents with your employer, say, BCG. BCG has to ensure two things:

• The Degree and Transcript submitted by you belong to you
• They are valid and actually issued by Harvard Law School.

Verification of both these in the traditional case of physical documents is time consuming and manual. However, the college can now issue a verifiable claim instead of the two documents, which can have all the information that the two documents had. In this case, the College will be the issuer, you will be the subject, and the information in the document (that you cleared the exams, marks obtained, tenure of course etc) the Claim. Like your physical certificates, the college will then sign this claim using their private key before giving the same to you. Such a document is called a verifiable certificate or VC. And you will sign the VC with your private key before submitting the same to BCG. Such a self signed VC is called a Verifiable Presentation or VP. 

When this DID is now resolved by BCG, they will be able to check the subject (you), along with your DID (of yourself). On resolving your DID, they will be able to see your public key and the issuer sign as well as the issuer root certificate. If they trust the issuer, they can trust your public key and use it to verify your signature in the VP. 

Thus, by doing this, they can verify that the degree belongs to ‘you’. 

Furthermore, in the same manner, they can resolve the DID of the college and verify their signature to confirm that the college issued the VC. 

The only difference between the two scenarios is that, in the case of the VC/ VP, it can all be done by machines and can be achieved in a matter of seconds!

DSC / EDC

Data space connectors (DSC) act as logical gatekeepers that integrate into each participant’s infrastructure and communicate with each other.

• A connector provides capabilities of connecting, discovering, automated contract negotiation, policy enforcement and auditing processes besides actual data transfer.
• Any such data sharing system requires a protocol implementation for policy enforcement among participants. 

Built on the foundation of DSCs, the EDC (Eclipse Dataspace ConnectorComponent) was established, enabling the adoption of IDS (International Data Spaces) standards and other pertinent protocols like Gaia X. EDC expands and improves upon DSCs by making it possible to support approaches like WEB-DID (identity) or Federated Catalog, and thus, implementation of policy enforcement as per Gaia X framework. 

Gaia X

A massive undertaking has been initiated in the EU with global aspirations in the form of the Regulatory Trust Framework named Gaia - X. 

• Gaia - X promises to solve the issue of identity, trust, sovereignty and interoperability while storing and sharing data. The trust framework permits making the W3C standards as base with DID-Web being the preferred mode of identification. 
• Gaia - X provides the framework for identification and registration of Business entities that declare to follow its standards and practices. 
• The identification is made possible by having Trust Anchors that act as authorities that ensures verification of participant’s identity.
• All the necessary rules, and data, is stored in Gaia - X Registry and all input information is verified against it.
• The Data sharing and usage contracts signed by participants are all stored with Gaia - X and help to examine accountability when needed.
• The involvement of the EU and national governments makes it possible to enforce consequences of making false promises by participants. 
• All this is achieved by using EDCs that allow organizations to exchange data compliant to rules and policies of Gaia - X. 

Further, in order to understand Gaia X implementation, it helps to define the following terms:

1. SHACL Files - These act as molds against which all input data is compared to verify if requirements are met as per set down rules. They are prepared based on the rules laid down by Policy and Trust Framework of Gaia X.
2. Gaia X Registry - The Gaia-X Registry is a publicly distributed, non-repudiable, immutable, permissionless database with a decentralized infrastructure and the capacity to automate code execution. 
   1. It stores the rules of the Gaia X Trust framework and has respective molds stored against which the input SHACL are compared. 
   2. This also stores all the data w.r.t to all participants in the entire process and their interactions / promises / declarations / roles etc 
3. Gaia X Compliance - They are responsible for ensuring that all requirements are met w.r.t. Framework laid down by Gaia X. 
   1. They play the role of accepting or rejecting a claim raised by an entity within the ecosystem 
4. Trust Anchor - They are the bodies authorized by Gaia X to carry out verification of Identity of all members trying to onboard with Gaia X, be it a natural person (Human Being) or Legal Entity (any type of company / trust / firm / group / association etc). Trust anchors also ensure verification of Legal Registration Number.