How Truvity Can Improve Permissions Security

As digital transactions and identity verification technology develop, Truvity aims to streamline and make more effective the way financial services interface with users. Utilising the principles of Self-Sovereign Identity (SSI), this initiative explores an improved process wherein a bank and its customer interact through secure and verified digital channels to facilitate payment instructions and confirmations effectively. This partnership seeks to redefine security protocols and enhance user experience in banking operations by employing cutting-edge technologies.

This case study is based around the principles of identification, authentication, and authorisation as distinct processes towards the development of secure permissions. These terms can often be found being conflated or used interchangeably, however, here they are broken down into their substantive roles and definitions to make their application and significance clear.

The SSI framework utilized in this context transforms traditional banking procedures by introducing decentralised identifiers (DIDs) and verifiable credentials that facilitate secure digital communication via DIDComm messaging. In this proposed framework, both the bank and the customer are represented as tenants within the Truvity system—an environment that ensures each participant and document is verified and secure. The essence of this interaction is captured through the use of DIDs and VCs, which authenticate and authorize each step of the transaction, ensuring that all parties are precisely who they claim to be, and that each transaction is executed as intended.

This not only supports the creation and verification of payment instructions and confirmations but also enforces robust security measures through the stages of identification, authentication, and authorisation. Each layer serves a specific function, from establishing identity to verifying access rights, thereby reducing the potential for fraud and enhancing the integrity of digital transactions.

Through this exploration, Truvity aims to not only innovate but also illuminate the path forward in digital identity management within the financial sector, and pave the way for a detailed discussion on the separation of identification, authentication, and authorisation in secure environments.

A Banking Permissions Scenario

Explore the following scenario with Truvity.

Two actors: "Bank" (B) and "Customer of Bank" (C). Two documents: "Payment Instruction" (PI) and "Payment Confirmation" (PC).

The actor (C) would like to generate (PI) and send it to the actor (B). The actor (B) would like to verify (PI), perform payment, generate (PC) and send it to the actor (C).

In SSI-terms:

• "Bank" (B) and "Customer of Bank" (C) represented (in target-state) as the Truvity tenant
• "Payment Instruction" (PI) and "Payment Confirmation" (PC) are represented as verifiable credentials
• The process of sending data between (B) and (C) represented as didcomm messaging
• The process of "generation" of (PI) and (PC) represented as credential issue by specific key-pair against specific DID-Document
• The process of "verification" of (PI) and (PC) is represented as credential verification.

Distinction between Identification, Authentication and Authorization

We must separate the three layers to understand specific mechanics and decisions.

• Identification
• Authentication a.k.a. AuthN
• Authorization a.k.a. AuthZ

These concepts are similar and can cause much confusion, but there is a clear separation of understanding.

Consider the following scenario: you are visiting a military base.

For badge issuance, the security service asks you to provide your passport to identify you as the subject/person. The issued badge gives you access to the military base. You pass Identification once, and after that, you are given a badge to wear.

Personnel inside the military do not perform Identification again but instead, check your badge to perform the Authentication process. Authentication is a process for checking the existence of an internal system identity.

While walking around the military base, you want to enter a particular building. This building has an additional soldier at the entrance. This soldier performs the Authentication process by checking the badge you wear, and after that, they again check your Authentication against some list of "persons authorised to enter the building". If your name is listed, you can enter— access granted. Access is denied as your name is not listed— you may not enter. This process compares your Authentication information against Authorization Policies (the list of approved names) known as Authorization.

Now imagine that while walking around the base, you found someone else's badge and decided to use it for further access to the premises. Without additional verification of your passport, it would be impossible to determine that this badge does not belong to you because Authentication does not include the Identification process. This very situation is applicable in the case of DIDs (Decentralised Identifiers); SSI does not describe the mechanisms by which one could identify the subject and cross-reference this information with the digital DID. The procedure for verifying the identity of the subject/person (for example, during KYC processes) occurs outside of the SSI specification.

SSI does not cover the Identification process. An outside third party always manages the Identification process within an SSI platform. Identification establishes trust between a particular person or organisation and a DID. SSI itself does not have a way to provide that step, and relies on a third party to produce trusted Identification for them.

SSI does cover the Authentication process. The “proof” field contained within VCs (Verifiable Credentials) authenticates the VC’s signature against a DID. An SSI platform could only then verify that a particular DID has generated the signature. Still, the SSI platform needs to learn about the signer’s identity. The connection between a DID and some natural person or organisation is stored somewhere outside an SSI platform.

The Authorization protocols within an SSI platform are presented in two ways:

• Authorization Capabilities for Linked Data v0.3, aka, ZCAP-LD
• Decentralized Identifiers (DIDs) v1.0, aka, as "did-core" => 5.1.2 DID Controller

In Summary

The integration of Self-Sovereign Identity principles into the banking sector, as demonstrated by Truvity, is positioned as a significant advancement in the way financial transactions are conducted. By leveraging decentralized identifiers and verifiable credentials, this partnership ensures that payment instructions and confirmations are securely issued, verified, and exchanged between banks and their customers. This progressive approach not only enhances the efficiency of the payment process but also fortifies it against fraud through robust authentication and authorization protocols. By clearly distinguishing between identification, authentication, and authorization, the system ensures that each step is meticulously verified, fostering a higher level of trust and security in digital banking operations.

The case study exemplifies how the adoption of SSI frameworks can transform traditional financial services. Truvity showcases a future where digital identity and secure communications are paramount, setting a new standard for the banking industry. By embracing these advanced technologies, banks can offer more secure, transparent, and user-friendly services. This approach not only aligns with the growing demand for digital solutions but also addresses critical security challenges, paving the way for a more resilient and trustworthy financial ecosystem. As the banking sector continues to evolve, such tecnological collaborations will be crucial in driving forward the digital transformation and ensuring that security and efficiency go hand in hand.