Content and Service Model
There exists a wide spectrum of online educational content resources at different levels of granularity, reaching from individual paragraphs of text to complete courses. Many of these resources are not just static files, but include interactivity. While much of that is possible on the user’s computer, more advanced resources require interaction with the server, including storage of user data; the resource actually is a service, combining content and functionality. This brings up issues of user identity, and — in a classic client-server architecture — logins, sessions, and the associated privacy and data security concerns.
The traditional way to connect with educational services is through service-specific usernames and passwords or through Single Sign-On (SSO). The latter requires a centralized identity provider, which is both a single point-of-failure and an entity which could track all connected services that the learner uses.
Getting any performance data from services back to the home institution of the learner, for example to prove that a project was accomplished or a homework problem solved, requires behind-the-scenes connections, for example using the Learning Tool Interoperability (LTI) standard. Some data might be stored with the service, but eventually, a user’s accomplishments and performance data are stored with the home institution. The left panel of the figure illustrates this; the folder symbol indicates the location of the authoritative copy of the data.
Arguably, the current mechanism might be one of the reasons why Open Educational Resources (OERs) have not gathered the momentum they deserve. While resources that are static or only provide client-side interactivity can essentially be hosted on any web server, where they can be made accessible without authentication or sessions, any advanced educational resources that require server-side functionality tend to exist inside particular environments, for example course management systems. The specificity of the environment can reduce re-usability, and the requirement for authentication raises privacy and data security concerns. Finally, the requirement for an LTI-connection might require systems engineering, and it is not transparent to the learner which information gets shared behind-the-scenes.
By contrast, in the self-sovereign model, the user is the connecting element, as shown in the right panel of the figure. He or she connects to the resource using an untraceable Decentralized Identifier (DID), there are no usernames and no logins. Upon completion of a task the service would issue a Verifiable Credential (VC), which gets stored with the user. Later, the user can present this VC to the home institution, for example, to eventually get course credit when all requirements of the course have been fulfilled.
In this model, educational resources and services just exist anywhere on the internet as part of the ecosystem, they are another entity to which the learner connects. To participate, educational resources need to have their own DIDs and be able to speak the language of VCs. While this sounds daunting, existing educational resource can participate in the ecosystem simply by attaching a cloud agent. This agent would be an intermediary or proxy: toward the existing service, it would open sessions under anonymous usernames (or usernames derived from the DIDs) and for example make use of LTI, while toward the ecosystem, it would connect via DIDs.
Essentially, the pre-SSI educational resource becomes an entity by providing its own runtime environment and providing a cloud agent. Since many of the course management systems in use today have been designed around the turn of the millennium, they are so lightweight by today’s standards that they can run in a container; this means that every educational resource can provide its own instance of a (correctly configured) course management system without having to rely on a centralized installation at some institution.