SkyID: How to Make Decentralized Identity using Skynet

Today we are going to discuss an approach to decentralized identity which takes advantage of the unique properties of Skynet. All of the technology discussed in this post has been implemented in SkyID, a Skynet application (Skapp) that is ready for use in production.

But before we fully dive into SkyID and how it works, I would like to take a moment to discuss the importance of identity and how decentralized identity can benefit the Internet as a whole.

Identity on the internet today is fragmented across many centralized services, each with its own set of user data. Signing up for a new service requires making a brand new identity and re-entering all of your information. This is not only tedious but also means that a user’s identity is going to be inconsistent between services because they are not always going to update key information on every single service every time that something changes.

On Skynet, user information can all be aggregated into a single place that is fully under user control. User information such as preferred name, preferred avatar, and even sensitive information such as preferred credit card and billing address can all be managed by a single decentralized application. Controls can be put in place to ensure that sensitive information is only revealed to trusted parties, while general information is available to everyone. The user’s experience is greatly simplified when all of their key information exists in only one place.

In the centralized world, each service is individually responsible for protecting user credentials. Properly protecting user credentials is difficult, and each year billions of user records are exposed through database breaches. This creates a great burden for users, who are now expected to use a different secure password on every single website and application. To the extent that the user doesn’t follow secure practices, they are exposed to hackers and identity theft. Data breach risk isn’t just a burden for users, it’s also a liability for application developers. Data breaches can sometimes cost companies hundreds of millions of dollars.

On Skynet, users only ever need to keep track of a single set of credentials. Those credentials can be managed by a single client-side application that gives out authorization to other applications. This eliminates the need for password management, allowing users to enjoy significant improvements to both security and convenience. User data is managed by users, which reduces liability for companies and simplifies applications for developers. And because each user manages their own credentials, hackers can at best steal one set of credentials at a time, versus the centralized world where a lucky strike can steal hundreds of millions of user credentials all at once.

Decentralized identity is more convenient for users, is more convenient for developers, and is safer for the bottom lines of corporations. Decentralization is going to win not because there is an inherent demand for decentralization, but because it is a simply superior way to build the Internet.

The Architecture of SkyID

SkyID is going to be a single application existing at the domain sia://skyaccounts.hns (soon to be sia://sky-id.hns). This application will be responsible for the user’s primary login and will be used to authorize all other applications that the user interacts with. This means that the user only needs to remember a single login - their login for SkyID.

SkyID lives in its own subdomain, which means that modern web browsers will allow it to store cookies and local storage privately. A user only needs to log into SkyID a single time and then SkyID can safely remember who they are. Other applications will not be able to see the user’s credentials and instead will need to ask SkyID for authorization.

Other applications can make requests to SkyID using cross-origin communication. Communication happens using window.addEventListener and window.opener.postmessage, allowing applications to receive authorization details from SkyID without ever getting access to a user’s core credentials.

When an application requests authorization from SkyID, they will need to specify what domain they want to be authorized to access and modify. SkyID will open in a separate window and ask the user if the user wishes to allow this application to be authorized on those domains. If the user consents, SkyID will use window.opener.postmessage to send authorization details to the calling application.

SkyID uses SkyDB to store a record of which applications the user has authorized or denied in the past, allowing SkyDB to automatically approve or deny requests from applications that have previously asked for permission, even if the user has switched devices or portals.

Authorization takes the form of a cryptographic secret key. When an application receives authorization, it is actually given secret keys that allow it to sign updates on behalf of the user. This is because all data on Skynet is user-owned, and can only be verified by the user if it is signed.

Authorization is split into distinct domains. For example, the SkyMessage application may store all of its data in the “SkyMessage” domain. SkyID keeps a master key and uses that key to derive a separate key specific to each domain. Applications can request access to any domain they want. For example, an app called SkyMessagePlus may want access to the “SkyMessage” domain, so that everything it does is compatible with the SkyMessage ecosystem. The user has control over whether or not an application is allowed to receive the secret keys for a given domain.

Though the derivation process is deterministic, we could not find a safe way to derive child pubkeys without knowing the secret. HD keys as a technology doesn’t work, because if you know the child secret key and also the master public key, you can derive other child secret keys, which breaks our security scheme. Instead, SkyID keeps a file in SkyDB which lists out all of the public keys a user has derived. This file is only necessary so that users can see which applications and domains other users are using.

How to Use SkyID

As an application developer, there are a couple of advantages to using SkyID. The most significant is that your users will not need to remember a set of login credentials that are specific to your application. This reduces friction and should increase the total number of users on your application.

A second benefit is that it significantly increases interoperability with other Skynet applications. If you store data in SkyDB using SkyID, other applications can easily find your data, and you can more easily pull data from other applications yourself.

And the final reason to use SkyID is that a robust identity system for your users has already been implemented, which is work that you will not need to do yourself to create an application with secure user data storage.

You will need to import SkyID into your application as a javascript library, then you can use the library to fetch a SkyDB domain from SkyID. Before the domain is ready for use, you will need to call sessionStart. A pop-up will appear asking the user for authorization as soon as sessionStart is called. See the code below for an example of initializing the domain.

<script src="https://skyaccounts.hns.siasky.net/skyid.js"></script>
<script>
    var domain = new SkyID('App name')
    domain.sessionStart()
</script>

Once your domain is initialized, you can call setFile to store or update a file in SkyDB within that domain. Other applications with access to the same domain will be able to see that data.

domain.setFile('filename', jsonData, function(response) {
     if (response != true) {
         alert('Upload failed')
     }
})

It’s that simple! To see a working example of an application using SkyID, check out sia://skyacc.hns, with the full set of working code available on github.

Security Considerations

The most important thing to know about SkyID is that the user public key is going to be published broadly, meaning it can be easily targeted by attackers. This is okay as long as the public key is derived using a secure seed or password, but any user using a weak password is almost certainly going to have their account stolen.

For this reason, we strongly recommend that users use a randomly generated seed, just like they would for a cryptocurrency wallet. Though this is a little bit more annoying than a typical username+password login, a user only needs to keep track of one such seed for use across all SkyID applications on Skynet.

Another limitation of SkyID is the portals themselves. SkyID is open source and runs purely client-side, allowing users to audit the code and be certain that it is securely handling secrets. Unfortunately, however, a vanilla web browser has no way to verify that the Skynet portal is serving the actual SkyID code. A malicious portal could steal key user credentials. This security issue may be able to be resolved with a browser extension.

Finally, applications that receive authorization get full control over the domains that they are authorized to access. If a malicious application receives access to a domain, it could easily delete all of the user’s data in that domain, or steal sensitive user information. Users still need to be careful when authorizing applications and make sure that it is a trusted application, or that it is only being given access to a domain that does not overlap with other applications.

Though out of scope for this particular post, Skynet could build a verification system for developers, and SkyID could potentially integrate with that verification system, giving users additional protection against potentially malicious applications.

Final Remarks

SkyID has been designed in a way that is intended to be compatible with other decentralized identity solutions that are being developed. SkyID itself is less about defining the details of identity and is instead more focused on establishing a single set of login credentials and then giving the user control over how each application is allowed to access their data.

Our ultimate goal with Skynet is to make the Internet more user friendly and more developer-friendly. A single global login with app permissions is a big step in that direction and is one of many additional steps to come.

Perhaps the most exciting thing to me about SkyID is that it is entirely built on the native Skynet stack. There is no special core developer knowledge required to make SkyID, and in fact, most of the concepts in the code are accessible to entry-level javascript developers. Anybody could have made SkyID, and anybody could make a better version of SkyID. When it comes to the ease of making fully decentralized web3 applications, Skynet is truly a standout platform.

For this reason, I believe that the next 6 months are going to be some of the most important months in the entire history of web3. The face of the Internet is going to begin changing very rapidly as the power of Skynet is made available to more developers and more startups. I am very excited about the future, especially because that future is almost here. The wait for a usable and competitive web3 is over. Skynet has arrived.

I would like to give a special highlight to DaWe, as many of the important ideas from this post are his and not mine. He is also the one who stepped up and put in a massive sprint to get SkyID implemented and ready for use prior to our “SkyDB Debut” hackathon. His prior accomplishments include making the very first live-streaming platform built on top of Skynet, as well as the very first Skynet search engine. If you want to stay on top of the latest and greatest on Skynet, he is a good person to follow!