What is the Identity Actor?
Suppose a new customer wants to open a bank account online. Before they can do so, their identity must be verified by the bank through a process called Know Your Customer (KYC). Traditionally, KYC requires the customer to either visit the bank in person and present a government-issued identification or submit to an online video identification process. Because both processes require a person to verify their identity, they are time-intensive, costly and prone for error. But what if the customer provided a secure representation of their identity that could be verified automatically by the bank? In this scenario, opening a bank account would take the customer no longer than creating a new account on their favorite video streaming site.
To enable this, the customer needs a wallet for their identity, such as Selv, installed on their smartphone. Selv manages the customer’s IOTA-based identity and can share KYC information with the bank. To do that, both the customer and the bank need to share their decentralized identifiers (DIDs) and prove ownership of these identities. Once both sides are confident about each other’s identity, the customer asks the bank what information it needs before sending the required data to it. While this may sound complicated, the customer only has to scan a QR code to start talking to the bank and click “accept” to share the appropriate data. The rest of the operations take place in the background. However, this requires the Selv app and the bank to share a common language for sharing identities, proving ownership, and sharing data. That common language is currently being designed by the Decentralized Identity Foundation (DIF) and is called DID Communications (DID Comm).
Even if both sides speak the same language, they still need to implement software that can do something meaningful with the exchanged information. That is the role of the Identity Actor. The Identity Actor is a program that can send and receive requests and responses related to Self-Sovereign Identity (SSI) and data management. This means that the IOTA Foundation is building a program that understands how to “speak identity” with other Identity Actors.
To return to our example, scanning the bank’s QR code instructs the Identity Actor running in the Selv app to set up communications with the bank’s Identity Actor. The conversation starts with something like this:
The name of this process is DID Authentication and it proves control of identities. For example, to make sure that the customer has control of the DID that they have sent, the bank sends a challenge to the customer. The customer signs this challenge with their private key and the bank verifies the signature using the customer’s public key, stored on the Tangle. The most important property of the challenge is that it is unpredictable to the receiver.
To share the KYC information with the bank, the conversation continues:
This conversation exchanges the KYC information that the bank needs to open an account for the customer. Today, the bank verifies the customer’s identity based on a physical ID card because it trusts the government that issued the card. In the near future, the government could issue a verifiable credential confirming the customer’s name, address, and date of birth, stored by the customer on their device. The customer could also prove their identity to the bank digitally if the bank trusts the government DID that issued the credential. However, in contrast to ID cards, credentials could be issued by anyone, and the bank could choose to trust multiple issuers. Perhaps the customer is a student eligible for a free account: To digitally prove to the bank that they are a student, the customer would need to have university-issued credentials and the bank would have to trust the university’s DID.
The bank would have a list of DIDs it trusts as issuers of these credentials: trusted DIDs could also be other financial services and government agencies. As part of the interaction, it would also be possible to ask the bank to digitally sign its request for data. This makes the bank’s request non-repudiable, meaning it is unable to deny having asked for your data because the user has the digitally-signed message as proof. According to European GDPR, if it emerges that the bank has asked for more information than it requires by law, the customer has proof that the bank has broken privacy laws. This will become an important tool for protecting against abuse of self-sovereign identity.
Another important element are the hooks. These are points where the developers of the Selv app and the banking software add some extra logic to the Identity Actor. For Selv’s pre-hook, it tells the Identity Actor to wait for the user to provide explicit consent before sharing the requested data, by for example confirming the action through pressing a button or entering a locally set password to the app. This means that the default behavior of the Identity Actor needs very little customization from the developers of the Selv app. Similarly, the developers at the bank only have to enter the data they need from their new customers and the DIDs that they trust to support this use case. Adopting IOTA Identity becomes an easy and efficient process.
Flexibility and interoperability
As shown in the above example, Identity Actors understand each other's language and how to automatically respond to certain requests. This also provides natural interoperability between any application that uses the Identity Actor. The bank doesn’t care if you use Selv or another SSI wallet, as long as they speak the same language. Similarly, Selv users can use SSI features with different banks or other industries, such as webshops or ticketing services, as long as they too speak the same language. This results in strong interoperability between applications, creating an ecosystem for users and applications to join freely. The Identity Actor makes joining this ecosystem very easy. Any application can install and run an Identity Actor while hooking its own logic into conversations between the Identity Actors.
The Identity Actor is designed to achieve complete feature parity and optimal security across all platforms, no matter their computational power or provided security measurements. It can outsource tasks to other Identity Actors running on different devices to circumvent restrictions of the current environment. For example, you might be running an Identity Actor on your desktop, which securely stores your identity in a stronghold, but you want to use your identity on the web. The browser has no way of securely storing your identity, so the Identity Actor model allows the outsourcing of storage to the desktop Actor. Let us update the DID authentication example with the new setup.
The above conversation is simplified as it relies heavily on setting up secure connections between the different Identity Actors (which IOTA provides, but that’s another story). But overall it shows how the cryptographic operation is outsourced from the insecure browser environment into the much more secure desktop environment. This increases security but also allows restrictive environments such as bare-metal Internet of Things to enjoy the full scope of Identity, by outsourcing the more complicated tasks to other devices with more computational power via secure Identity Actor communications.
Managing your own identity and data
Now let's discuss the last but probably most exciting part of the Identity Actor: Data. The Identity Actor provides the ability to communicate in a standardized and interoperable manner, on different platforms and across different programming languages. It might become useful for users to start running an Identity Actor in the cloud or on an always-online physical device they control, to always have a reachable Identity Actor. Now, you could give access to your data via your Identity Actor. This Identity Actor could then store Verifiable Credentials and other personal data that is now shareable at the click of a button. At this point, people can now run a personalized data vault and server to represent you in the digital world. Why would companies need to store your data if they could receive your permission to contact your personal Identity Actor remotely to retrieve the data at any time of the day? By using that logic, they would be largely freed from any overhead of storing personally identifiable data locally, so not having to maintain GDPR-relevant data locally.
When all this is put together, we are creating a path to taking back control over your data in a way that is beyond GDPR-compliant. You’ll be able to store all your data coming from different sources, creating the richest and most trustworthy data collection about you that is available. Your data collection will be more complete and therefore attractive as a data source over Facebook and Google’s data harvesting. This will likely shift data demand from third party data collectors to you directly as the best source. This in turn provides people with the ability to make sure they are properly rewarded for sharing their data, in the form of value, services or other meaningful rewards.
To top it all off, all applications built with the Identity Actor speak the same language and will be able to send these requests to your Actor with minimum development requirements. This will make the personal identity actor easy to contact and adopt by application developers.
Hopefully, this short introduction provides an idea of what the Identity Actor is and how we envision it may be used in future products and applications. If you are interested in more information about IOTA Identity, check out our repository in which you can follow the Identity Actor’s development, or explore our Selv demos. Join our Discord and find the Identity team in the #identity-discussion channel, or join the Identity X-team!