By Arne Rutjes, Filipp Valovich, John Pater
Not your keys, not your data. How do we bring that concept to an industry blockchain?
The first part of this article series provided an overview of the problem statement and a solution towards securely identifying a user in industrial applications. The second part will focus on a technical solution combining blockchain and SSI, to let users represent their company on the blockchain in a trusted and privacy-friendly way.
Components
A user, let’s take the foreman from the previous example, uses a web application on a laptop on the construction site to order concrete. The application connects to a blockchain to query and submit trusted data according to the rules of a smart contract. To give the control of the private key to the user, we’re adding two components: a cloud agent in the same domain as the web application and the Certificate Authority, and a wallet app in full control of the user.
Two processes are worth looking into: onboarding and submitting a transaction.
Onboarding
All users who (indirectly) interact with the permissioned blockchain will need a mobile wallet app. The app has all the basic features of a common SSI app, extended with the onboarding and signing functionality discussed here. Before starting the onboarding process, the wallet must contain SSI credentials that prove their role in the company (for instance using the vLEI credential mentioned earlier). How these are obtained is out of scope for this article.
- The web application requests an invitation code to show to the user as a QR code.
- The user scans the QR code with his wallet app; this establishes a secure connection between the mobile app and the cloud agent.
- The cloud agent requests proof (for instance: name, role and company, as attested to by a known vLEI issuer). It also shares some info about its Certificate Authority.
- The wallet app creates a proof presentation based on the credential in the wallet
- The wallet app creates and stores a new private key
- The wallet app creates a Certificate Signing Request (CSR)
- The wallet app asks the user to verify the information and approve sharing.
- The user approves.
- The app shares the proof and CSR with the cloud agent.
- The cloud agent verifies the proof, and if the info in the CSR is the same, forwards the CSR to the Certificate Authority.
- It then sends the certificate back to the wallet, who stores it for later use.
From now on, the user has a private key and corresponding (validated!) certificate in his wallet that makes him a known member of the blockchain.
Submitting a transaction
- The foreman uses the web application to order concrete.
- The web application shares the parameters (e.g. counterparty, price, amount) with the cloud agent.
- The cloud agent asks the wallet to create a transaction and sign it on behalf of the foreman.
- The foreman verifies the parameters and approves the transaction.
- The wallet creates and signs a transaction, based on the approved parameters and the certificate in the wallet.
- The wallet sends the signed transaction to the cloud agent.
- The cloud agent submits the transaction to the blockchain.
- The blockchain peers verify the signature and certificate, and execute the transaction.
Trust model
All engineering is about tradeoffs, and 100% security is an illusion. When establishing digital trust, we should aim for reasonable assurance instead of absolute assurance (see Trust over IP design principle #11). However, when applying a system like described above, the underlying assumptions must be made explicit to determine the level of assurance that can be achieved.
First of all, there is the condition that the wallet app is secure and that the credential is issued in a trusted way (there is quite a lot to this condition, but many smart people are working on it). Otherwise someone could pretend to be our foreman during onboarding and continue to perform blockchain transactions in his name. Secondly, the user still has to trust the organization that provides access to the blockchain to accurately present information and to not refuse to submit their transactions
With these caveats out of the way, what we can prove with a fair amount of certainty now, is that the transaction is approved and signed by this particular user, and has not been tampered with; because only the user has access to the private key signs the transaction and that is linked to their identity via the onboarding procedure. This provides a much higher level of assurance than what we can ever reach when the keys are managed by the SaaS application.
Conclusion
We described an innovative solution with an intuitive user experience that combines the privacy and security aspects of SSI with those of a permissioned blockchain, and provides the assurance needed in a typical multiparty business environment. With this solution, it is possible to authenticate and authorize users for their blockchain transactions while keeping the self-sovereignty of users’ data.
If you are intrigued by this approach and want to collaborate on this, then we are happy to connect with you! Please contact us via our social media accounts.
At NEXPLORE, we are building technology products to digitize the construction industry. We are always looking for the most innovative technologies in order to move forward on the cutting edge.
