- Problem Statement
- Concept of Claim, Attestation and Verification
- Objective of PoC
- PoC High-level Architecture
- PoC High-level Workflow
- Demo Video
- Beyond the PoC
- Afterword
The downside to a centralized ID management means that it is susceptible to a single source of failure. In event that the central ID provider is made unavailable and rendered non-recoverable, the central ID provider/agency will not be able to perform trust attestation or authentication of users and devices.
Thus, the solution has to explore adopting a decentralised model of doing trust attestation such as using blockchains, smart contracts and immutable user profiles to ensure that users and devices connecting to government networks are authorised, authenticated, secured and security posture validated constantly. New users and devices can also be added to the blockchain via peer-to-peer validation.
There are 3 roles in a transaction :
- Claimer : A claimer is an entity that is claiming a credential and requesting an attestment for the credential.
- Verifier : A verifier is an entity that is verifying the credential through querying the blockchain for the validity of the attestation of the credential.
- Attester : An Attester is an entity that has the ability to attest to a credential and write to the blockchain a proof of attestation.
Our Proof of Concept (PoC) seeks to illustrate how the concept above can be used to address the following problems in the problem statement :
- Adding of new users to blockchain via P2P validation (Credential Attestation)
- Authentication and authorisation to service (Credential Verification)
- Constant validation of security posture (Credential Revocation)
Although security of user and/or device is not demonstrated in our PoC, a high-level suggestion - Securing P2P Communication has been provided below. Additionally, Beyond the PoC section will explain additional mechanisms not illustrated by the PoC.
Usage instructions of our PoC can be found in our Quickstart.
Shown below is a use case diagram which will form the basis of our PoC.
| Use Case | |
|---|---|
| Credential Attestation |  |
| Credential Verification |  |
| Credential Revocation |  |
To demonstrate clearly the workflow as well as for ease of development, the PoC is built like a traditional client-server architecture but with a slight twist.
As can be seen above :
- Client communicates with Attestation Webserver/Service like any Client-Server architecture.
- Instead of an centralised authentication database / oauth system, webserver directly querying the blockchain
- Frontend : HTML/CSS/Javascript
- Middleware : NodeJS/HAPI
- Backend : Kilt-Protocol 0.28
- User will enter and send their claim through POST request to server
- Server will store the claim as a string in a temp file.
- Attester will access the webserver through the Attester dashboard, and read the temp file for attestation request.
- Once Attester validated the information provided, it will write the attestation onto the blockchain.
- Blockhain will return the hash back to the attester.
- Attester then sends the credential with the attesment hash back to the client.
- User will be presented a login page.
- User enter and sends in credential and mnemonic of DID that claimed the credential via a POST request
- Server received POST request, check's if it is the correct CType (credential format) and verifies the credential by querying the blockchain for it's attestation.
- If verification is successful, server allows access to service. Else access to service is denied.
- In the same attester portal, an attester can revoke credentials that they attested.
- When credentials are removed or revoked, they are not removed on the user-end, changes are made on the blockchain
- There is a remove attestation function which was not implemented in the PoC.
- The difference between revoking and removing is :
- Revoke : The attestation is still present on the blockchain but with a
"revoked":falseflag set. - Remove : Attestation is removed from the blockchain.
- Revoke : The attestation is still present on the blockchain but with a
This section will talk about ideas and Kilt-Protocol mechanisms in terms of scaling and security not shown in the PoC.
In Kilt-Protocol, any user with Full DID will be able to do trust attestation. This in itself is a benefit as now any users will be able to attest for claims where there are other use cases for example digital signing, but this is beyond the scope of our problem statement.
The issue with trust attestation by any Full DID is the issue of legitimacy of the attestation. This is easily solved by verifying the DID of the attester.
As seen above, in an attested credential, the DID of the attester will always be revealed and if we know that the Attester ID can be trusted (DID can be posted on Official pages, hard-coded into an address book etc.), then the attestation is valid.
Then a new problem arises - what if the attester is not an individual but an organisation? How then can we scale up the number of attesters but not need to keep a big address book? Kilt has 2 solutions for this and they are Delegation and Virtual Credential Organisation (not implemented yet in Kilt)
Delegation hierarchy organise their members in a traditional hierarchical structure, and are modeled as a Tree data structure (see diagram above).
There are 2 kinds of rights that can be given
- The root of the delegation and it's assigned "delegator" can assign delegation and/or attest rights to it's child.
- Referring to the diagram above, Attester 2 has the rights to delegate attester and delegation rights to more DIDs, but Attester 3 is only given the right to delegate more Attesters but not Attest for Attester 1 itself.
- Attester 4 and 5 is given attest rights by Attester 3 to only attest credentials for Attester 1 but not delegate attester/delegator rights.
Only the parents of a given Attester can change or remove the Attester's delegation itself or any of its children.
For example, Attester 2 cannot change the delegation information for Attester 4, but Attester 1 and Attester 3 can both remove Attester 4 from the organization, or give them permission to also delgate new people.
Credential revocation works similarly, where the credential can be revoked by any parent or by the original attester.
For example, Attester 2 cannot revoke credentials issued by Attester 1, 3, 4 and 5. Attester 1 can revoke any credentials and Attester 4 and 5 can only revoke credentials that they attest but not each others'.
In the other implementations of Kilt-Protocol as seen in socialKYC, users, attesters and verifiers are secured by an external extension the Sporran Wallet. Therefore, it is viable that in a custom implementation some form of "Cold Wallet" can be implemented to ensure the safe storage of the Account and Credentials as well as a means of accessing services.
P2P communication between Attester and User, Verifier and User is done over HTTP and naturally has to be secured by SSL (HTTPS).
An additional layer of security is also provided at Application Level in the Messaging API which gives additional encapsulation for user credentials and accounts.
Examples of its implementations can be found here.
Apart from what the PoC has attempted to illustrate, in actual implementation a web3name is suggested to be linked to the Attester/Verifier instance. This web3name can then be verified by the user similar to what is done in this quickstart documentation done by the Kilt Team.
Lastly, an additional verification step can be implemented like above (similar to a 2-way SSL authentication) and it can better help in preventing malicious acts such as phishing as user can now verify if the service they giving their credentials to is legitimate or not.
Most of the functions (i.e claiming, attesting, delegation, revocation and verification) can be deployed on FaaS (e.g AWS lamda, Google Cloud Functions or Azure Functions) as the aforementioned functions can be easily designed:
- To make use of short and single purpose APIs or webservices.
- To be stateless such that local resources and processes are not reused.
Therefore, a serverless architecure can provide better :
- availability as there is no server downtime, and we we solely depend on CSPs SLA Uptime which is at least 99.95%.
- scalability as functions in FaaS can be spun up as quickly as the CSPs can handle
- security and privacy[1] [2] as
- we eliminate the need to secure the infrastructure (OS hardening, patching, server configurations etc).
- ephemeral execution makes attacks difficult as the amount of time in the system is restricted to the timeout set.
- ephemeral execution makes data private as it is destroyed and not stored in the memory
- fine-grained security controls with IAM will restrict the impact of an attack.
- short and single purpose APIs introduces less bugs as compared to monolithic applications
- Focused on securing solely the endpoints, code, storage and accessibility of data.
- lower cost as FaaS services charges based on per invocation basis and StaaS charges based on per Gb data stored and per 1000 requests.
Following this guide, as well as the fact that Kilt is a parachain of Polkadot blockchain, built using Substrate, it will be possible to deploy a private or hybrid blockchain. A private blockchain can focus mainly on access control and performance which is essential in DID. Whereas, hybrid network focuses on flexible infrastructure settings. To understand which network is required, we will have to look at the potential of this POC.
One of the biggest problem in Singapore is phishing websites. Humans are not able to verify the integrity of the website and fail to identify a phishing site. However, with DIDs, it is possible for user to identify an official site. Here's a brief description on how it can be done.
- Every website is considered a claimer. Each claimer will send a set of site credentials for an attester to approve.
- Once the website is approved by an attester, it will be stored in the blockchain while returning the credential to the site
- Any individual that visit the site will be known as a verifier. A verifier can request a check on credential from the site and match it with the blockchain. If it matches, the site is valid, else it is a phishing site
Since there are both public and private facing items, a hybrid blockchain will be required for this setup. A set of permissions are required for attesters to approve the credentials submitted by claimers while the public facing blockchain is open for verifiers to request for a check.
For the longest time, IoTs are managed by IP based access controls. It is insufficient to have IP based access control as well. However with DIDs, we can assign role based access control to IoTs. Here's a brief description on how it can be done.
- Every IoTs is considered a claimer/verifier. Each IoTs will send a set of credentials for an attester to approve.
- Upon approval, these credentials will be store in a blockchain.
- If an IoT goes rogue and tries to access other network, the role based access control will kick in and deny the process before the IP based access control kicks in
In this scenario, there isn't any public facing items. Furthermore, asset ownership and access control is important in managing this group of IoTs. Therefore private blockchain can be used.
As we come to a close to the hackathon, this is a reflection of our development and thought process.
As we wanted to do a project related to blockchain, choosing Problem Statement 2 is a given.
In our initial research, we shortlisted 2 frameworks which we think best fits the problem statement and they are Kilt Protocol and Hyperledger Indy. Of these 2 frameworks, Kilt has the better documentation, better support, shorter learning curve and uses a less complex set-up as compared to Hyperledger Indy.
Additionally, Kilt SDK uses Javascript/Typescript which we are already familiar with as compared to Hyperledger which uses Rust where we do not have the luxury of time to figure out. As most of our team members are undergradutaes, the hackathon clashes with exams and FYP presentations. We had to juggle with learning about the protocol, building the PoC as well as schoolwork. Learning a new programming language will naturally be something left for another day. Kilt is therefore the go-to for understanding DID as well as for building our PoC.
Furthermore, Kilt has 2 testnets which we could use immediately, and we do not need to set up our own testnet. Having an actual testnet (over the internet) not only alleviates the the skill issue of deploying and connecting to a node but also allows us to simulate an actual network which we hoped would bring out the decentralised feature of our PoC.
Even though Kilt has a shorter learning curve there is still quite a bit of unexplored features like service endpoints, digital signing, encrypted messaging and delegation. We were only able to grasp the core features Claim, Attest, Revoke, Verify, Light DID and Full DID and are starting to learn about the features mentioned above.
As Kilt is still undergoing active development, we also faced the problem of breaking changes in the protocol in the midst of the hackathon. Kilt SDK 0.29 was released in the middle of the hackathon. As we are unable to afford human and time capital to reconfigure our setup, we chose to remain with Kilt SDK 0.28 to showcase the core features of Kilt Protocol. Even though we might say "breaking changes" the main change that affects our PoC is the removal of Demo Keystore.
Due to the challenges faced above, we decided to build a PoC first to check out the core features of Kilt protocol as well as the feasibility to build what we proposed in Beyond the PoC. Through our PoC, we believe that Kilt Protocol can truly be used for Phishing prevention and IoTs role-based access control.
We seek to improve on our current work and hope to be able to build a working prototype which can be deployed where necessary e.g IoT DID, Phishing prevention, Personal DID.