In 30mins, I will address crucial parts of implementing Solid in Python, so attendees can understand how to build a decentralized web application with Python and get the benefits of this promising architecture.
In classical web architecture, application and data are bundled together, hence user data are naturally owned by service providers. This causes security, privacy, interoperability, and many other well-known issues for both users and service providers.
Service providers need to pay additional responsibility to protect user data in the scenario. Moreover, users cannot fully control and migrate their data without additional mechanisms provided by the service providers (GDPR tries to address this in a nontechnical way.)
With Solid, all personal data is stored in a data repository named Pod controlled by users. That could be set up on a user's server at home, or provided by a data storage supplier chosen by users – but the key is that users can decide which web applications are given access to which portions of it. Users can also revoke permissions at any time.
In this architecture, data is decentralized and decoupled from web applications, since every user and organizations store data in their Pods instead of service provider servers.
A Solid Pod provides a universal and standardized interface. Data in a Solid Pod are organized in a structured and semantic way. Application developers can focus on building their business logic without considering interoperability and compliance problems.
Even though the architecture is very different, for developers, the good news is, most protocols used in the Solid web architecture are based on and similar to web protocols we live today. W3C CG does not reinvent the wheel. To adapt existing protocols in the Solid architecture, a few of them are revised or extended to fit the new architecture. For example, we need to do access control in a decentralized way in this architecture.
In practice, to build a web app in a Solid way, developers still have to study state-of-art versions of these web protocols and standards, especially for Python developers since most of the materials and libraries are for the Javascript ecosystem currently. The primary purpose of this talk is to help Python developers to overcome those barriers.
To decouple data from applications, data have to be organized in a structuralized and interoperable way.
Solid architecture adopts Resource Description Framework (RDF) to archive this. RDF is a standard model for data interchange on the Web. The RDF specification consists of a suite of W3C Recommendations.
Solid is also based on Linked Data Platform (LDP). The LDP specification defines a set of rules for HTTP operations on web resources, some based on RDF, to provide an architecture for reading and writing Linked Data on the Web. The most important feature of LDP is that it provides us with a standard way of RESTfully writing resources (documents) on the Web.
As a Python developer, in this section, I will introduce how to manipulate data in common RDF serialization formats such as Turtle and JSON-LD.
Solid is decentralized web architecture. We need a decentralized way to do access control.
Solid adopts Web Identity and Discovery (WebID), which provides a simple universal identification mechanism that is distributed and openly extensible. Users can identify themselves to allow fine-grained access control to their information on the Web and their Solid Pod.
Solid also adopts The OAuth 2.0 [RFC6749] and OpenID Connect Core 1.0 web standards. Both of these protocols are widely adopted across the industry for authentication and authorization today, but they work differently in Solid.
In Solid architecture, OIDC and OAuth are extended and revised for working in a decentralized way, so we cannot just use common turkey solutions such as django-oauth-toolkit here.
In this section, I will introduce these protocols and corresponding extensions, e.g., WebID, OIDC Dynamic Client Registration, DPoP, PKCE, and how to combine all these things in Python.