The Rise of new DID Authorization Mechanism in Client-Server model

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

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]

The OAuth 2.0 authorization and authentication flow

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.

  • 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.
The confirmation popup that greets user requests to sign in to the Feeds Capsule
The authorization and authentication flow between Feeds Capsule and resource owner
The confirmation popup when the Feeds Capsule implicitly signs in to the remote Feeds service.
The new DID authorization and authentication flow in the client-server model
  • 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.

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.

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.

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.

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.

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Zlong

Zlong

Web3 = Decentralized + Privacy + Ownership