The Rise of DID Authorization Mechanism in Client-Server Model

Nowadays, as users surf the internet, they have no choice but to adhere
to the traditional means of authorization offered by tech giants such as
Google, Apple, Tencent, and Alibaba. Users are forced to sacrifice their privacy and ownership rights to access the business services provided therein.

Even most small companies provide similar standalone authorization systems backed by similar exploitative models. It is simply a matter of doing business in the landscape of the present-day internet. But as
decentralized identity solutions emerge, users now have an alternative
— namely, DID authorization mechanisms.

The roles of traditional authorization flow

Before addressing DID authorization flow, we will walk you through the traditional authorization flow used in the client-server model, where the
authorization flow has the following roles:

- Resource Owner: End-user who can grant access to a protected resource.
- Resource Server: Server hosting the protected resources.
- Client: Application requesting access to a protected resource on behalf of the resource owner.
- Authorization Server: The server authenticates the resource owner and issues access tokens after getting proper authorization.

First-generation authorization system

In the primitive authorization system, a user must sign up for an account with a username and password before signing into the remote server. A username is generally either an email address or phone number that can be used to recover that account. The server takes responsibility for authenticating the user’s identity and granting the requesting application an access token for reaching protected resources on the same server. Therefore, the server practically manages both the user’s credentials and resources, combining the roles of authorization server and resources server.

The first-generation authorization and authentication flow

As a resource owner, a user essentially has no control of his credentials and resources because all data is kept on the remote server owned by third-parties — not by the user.

The OAuth2.0 authorization framework

The OAuth 2.0 authorization framework is a protocol that allows a user to grant a third-party web site or application access to the user’s protected resources, without necessarily revealing their long-term credentials or even their identity. [Quoted from OAuth2 protocol]

OAuth2.0’s significant achievement is decoupling the authorization process from the resources server and becoming a standard service. Such examples include Google authentication, WeChat authentication, and others. The standalone authentication server maintains users’ credentials and authenticates the requesting clients based on those credentials. Once the authentication challenge is accepted, the authentication server will issue access tokens to authorize the client access to protected data on the resource servers owned by other companies from the authentication server.

The OAuth 2.0 authorization and authentication flow

Nowadays, companies and organizations trend to integrate the well known
OAuth2.0 services like Google, Twitter, WeChat into their authorization system to attract more users. As the primitive one, users still have no essential control of either the credentials or resources, which are still exclusively controlled by third-parties either for the authorization server or resources servers.

The new DID authorization mechanism.

“Decentralized identifiers (DIDs) are a new type of identifier that enables verifiable, decentralized digital identity”, [Quoted from W3C DIDs specification v1.0]. For more information, refer to this article, which pertains to using Elastos DIDs in the Feeds application.

It is important to understand the entire DID authorization flow in the context of the Feeds application. When using Feeds, users will observe
three different roles:

- Resource Owner: The user now totally controls the credentials and the resources published on the resource server.
- Client: A runtime instantiation of the Feeds Capsule running on a user’s device.
- Server: A running instantiation of the Feeds service deployed by the end-user, who publishes resources on the server.

Three different Elastos DIDs are required to identify each above entity respectively. In addition, there is the elastOS application, which manages the resource owner’s DID.

There are two different cases of authorization and authentication that relate to Feeds: the first takes place between the end-user and the Feeds
Capsule without any connection to the services provided.

The confirmation popup that greets user requests to sign in to the Feeds Capsule

When the user attempts to sign in to the Feeds Capsule, Feeds will request authorization on elastOS, and a confirmation pops up asking for the user’s approval as a resource owner. Internally, as the user approves the request, the capsule will be issued with a verifiable credential as authorization. After verification of the credential’s authentication, the capsule becomes an agent of the user to manipulate data on the device.

The authorization and authentication flow between Feeds Capsule and resource owner

After signing in to the Feeds Capsule, the user can browse the content that exists in the capsule. But when the user wants to make a publication or browse the content on the remote server, it will require another authorization and authentication measure.

When the Feeds Capsule implicitly attempts to sign in to the Feeds service as a client, it will request authorization to grant the capsule instant access to the resources on the target Feeds server. The confirmation pops up on elastOS with an accurate description to let the user better understand related risks, and to make a decision on whether to authorize access. Should the user approve the request, elastOS will internally issue a verifiable credential to the capsule with the user’s DID as the issuer.

The confirmation popup when the Feeds Capsule implicitly signs in to the remote Feeds service.

The capsule determines the issued credential to be a verifiable presentation and sends it to the target Feeds server. Once the target server receives the presentation, it will verify its authentication. Then, once the verification is complete, the service returns an access token to the capsule, which uses the access token to request the protected resource on the target Feeds service.

The new DID authorization and authentication flow in the client-server model

elastOS is included in the authorization flow because the elastOS essentially acts as the user-level administrative center for managing DIDs, where it prompts confirmation via popup windows to facilitate authorization requests from third-party applications — namely, the Feeds Capsule. In this model, the user clicks the confirmation button to approve the authorization. With the user’s approval, the elastOS application issues a specific verifiable credential on behalf of the user to the target DID (such as the Feeds Capsule’s DID) to authorize the requesting application to do something user-approved — for instance, to sign-in the Feeds service to access the protected resource. Thus, a standard credential requires three key components:

- The Issuer: The users and resource owner who makes the decision to approve or deny authorization.
- The Subject: The entity that requests the authorization. The Subject is generally a client application, like the Feeds Capsule running on a device.
- The Scope: The content of the Subject’s request, such as to access the protected resource on the remote resource server.

In summary, the user (the issuer) gives approval to issue a verifiable credential to the Feeds Capsule (the subject). Then, the Feeds Capsule submits this credential to the Feeds service to access the protected
resource there (the scope).

The advantages of the new DID authorization framework

Each of the authorization flows described above operates differently. What’s important to note is that traditional authorization flows conduct authorization computing on the remote authorization server. Even with a
user’s approval, the authorization server still issues a credential to the client application to access the protected resources. But as the single authority, the authorization server always makes the final decision based solely on their discretion.

Now, with the DID authorization mechanism, all the authorization computing has moved to the user’s side. No single authority has the power to make any final decisions. In Feeds, the user makes all final decisions for authorization, and all processes take place within elastOS. Furthermore,
all user credentials are managed within elastOS, and only with the user’s consent can the required credentials be sent to the resource server. No sacrifice of privacy is ever required in this model.

Realizing the New Architecture of Decentralized Social Networking

As should now be clear, the new DID authorization mechanism allows users to take back control of their credentials and privacy. Further, users spend a great deal of time and energy online, and produce tremendous amounts of data in the process. Ultimately, the owners benefit from this
generated data by selling it at scale.

With the rise of the Feeds application, the new decentralized architecture of the client-server model begins to take shape. Users can deploy their resource servers such as the Feeds service for their published data, therefore retaining ownership of it.

At the same time, users will no longer need to worry about authoritarian
censorship. There will be a multitude of Feeds services running across the world, waiting for users to connect. Users will be the primary and ultimate decision-makers on the Feeds platform.

Final Conclusions

Of course, the mechanisms and processes described in the course of this article have been simplified for the purposes of explanation, and are more complex in actuality. Feeds is the first experimental product that integrates DID authentication and authorization, especially in the context of the client-server model. Although it will not be easy, DID authorization offers a unique opportunity to take back control of our credentials and data. As an experimental, cutting edge platform, the Feeds application has many challenges ahead. The Feeds team remains hard at work, dedicated to delivering new features and an improved user experience release after release.

If you like the Feeds application, please
- Join the telegram group: https://t.me/feedscapsule.
- Download the Android native Feeds application here.
- Download the iOS Native Feeds application here.

This article is also published on Medium's subdomain.

elastOS and Feeds: Appendix of Related Terminology:

- elastOS: The standalone application built by the Elastos Foundation that manages all the DIDs of a specific user, helps the user sign in to third-party applications, or enables applications to sign in to the remote servers based on a DID authorization and authentication mechanism. elastOS has many more features than those mentioned in this article, and all users are welcome to explore the application to learn more.

- Feeds Capsule: The application that runs either inside of elastOS, as an Android native application, or even as an iOS native application. The Feeds Capsule takes the client’s role in the entire DID authorization flow and becomes the user’s agent in manipulating publication data either on the client device or remote server.

- Feeds Service: The back-end server as a daemon service run by the user anywhere. As the user publishes writing or other content, it is sent to this Feeds server to share with others via the Feeds Capsule. In Feeds, the Feeds service takes the role of the authorization server, and also takes the role of the full resource server during the DID authorization and authentication flow. This is the server deployed by the user, who can control all of the data on that Feeds server.