Summary
This post describes a proof of concept for a personal learning system called a student profile. The student profile gives students control over their personal information, including learning activities, and demonstrates how other parties can trust learning records kept in the student profile and shared by the student. This is a critical factor in creating personal learning environments that support life-long learning and give the university greater flexibility in system architecture.
In Sovrin Use Cases: Education, I broadly outlined how a decentralized identity ledger, Sovrin, could provide the tools necessary to build a decentralized university. This post takes the next step by laying out a three phase project to provide a proof of concept.
Background
Teaching students to be life-long learners in a digital age includes giving them tools and techniques they can use after they leave the university. We do students a disservice when we supply them with only enterprise-level tools that they lose access to once they've graduated. Learning management systems are fine, but they're not a personal tool that supports life-long learning. BYU has been exploring personal leaning environments and operates a thriving Domain of One's Own program in support of this ideal.
Architected correctly, personal learning environments provide additional, important benefits. For example, we're exploring the use of decentralized personal student profiles to create a virtual university using programs, certifications, and courses from several different institutions.
A Proof of Concept
In Sovrin Use Cases: Education, I wrote:
The idea is to create a decentralized system of student profiles that contain both profile data as well as learning records. These learning records can attest to any kind of learning activity from the student having read a few paragraphs to the completion of her degree. By making the student the point of integration, we avoid having to do heavy, expensive point-to-point integrations between all the student information systems participating in the educational initiative.
The architecture relies on being able to write verifiable claims about learning activities and other student attributes. A verifiable claim allows the student to be the source of information about themselves that other parties can trust. Without this property, the decentralized approach doesn't work. I describe the details here: A Universal Trust Framework.
The proof of concept has three phases that are described below. When finished, we will have a prototype system that demonstrates all the technology and interactions required to put this architecture into use. The things we learn in the proof of concept will guide us as we roll the architecture out globally.
Phase 0: A Learning Record Store
The goal of Phase 0 is to build a basic student profile that has an API manager, learning record store, and some system for storing basic profile information.
The system produced in Phase 0 is foundational. The student profile and learning record store (I'll use "student profile" to inclusively talk about the entire system from now on) provide the repository of student data. The student profile provides an API that supports event-based notification (mostly through the xAPI).
The requirements for the system built in Phase 0 include the following:
- API Manager—the student profile will include a simple API manager.
- Profile data—the student profile will be capable of storing and providing (through an API) basic profile data.
- Learning record store—the student profile will include an xAPI-compatible LRS.
- xAPI notifications from Canvas—The student profile should accept xAPI calls from the University's test instance of Canvas and make, as necessary, University API calls to other campus systems.
- Permissioned Access—The student profile should support OAuth-based access to data.
- Open source—Components of the student profile should be open source so that they can be modified to meet the needs of the proof of concept.
- Hostable—The overall student profile should be built so as to allow it to be run in a variety of cloud environments.
Phase 1: Creating Claims
The goal of Phase 1 is to introduce Sovrin agents for both the student and BYU, and use those agents to create claims about some of the learning records in the student's LRS.
The system produced in Phase 1 uses the Sovrin identity network to manage the claim creation process. Both BYU and the student profile will use what Sovrin calls an agent to interact with the network. The agent represents the entity (in our case either BYU or the student) to the Sovrin identity network. The agent is also responsible for managing any claims that the entity makes or possesses.
The requirements for the system built in Phase 1 include the following:
- Identity on the network—The system should support entities creating identities in the form of Decentralized Identifiers (DIDs).
- Student profile makes claim requests (2)—The student profile (through its agent) should be able to make claim requests of BYU's agent about any statement in the LRS.
- Claim requests are validated (3a)—BYU's agent validates claim requests before issuing the claim.
- Claims are issued (3b)—BYU's agent issues claims to the student's agent.
- Claims are stored—The student agent stores claims it receives.
- Claims are backed by pre-registered schema—Any claim issued by BYU will be based on claim schemas pre-registered in the Sovrin ledger. They can be BYU's or other's claim schemas, but the actual registering of the schema in the ledger is out of scope.
In Phase 1, any interactions with the student will be stubbed out with a default response.
Phase 2: Using Claims
The goal of Phase 2 is to provide proofs to another party about claims in the student profile.
The requirements for the system built in Phase 2 include the following:
- Relying Party with an Agent—A relying party, meant to simulate another school, uses an agent to interact with the ledger and other agents.
- Student client—A student uses a client capable of interacting with the student's agent.
- Student with multiple DIDs—The student uses different DIDs for interacting with BYU than she does for interacting with the relying party.
- Relying Party asks for proof of some assertion (4)—The relying party can ask the student agent for proof of some assertion they have a claim for.
- The student's agent asks the student client for permission (5 & 6)—The agent interacts with the client to get the student's permission to create a proof from the claim.
- Agent creates proof (7)—The student agent creates a proof from an existing claim and returns it to the relying party.
- Relying party validates the proof (8)—The relying party's agent uses the ledger to validate the proof. For the proof of concept, we can assume the relying party knows BYU (by its DID) and trusts BYU.
- Generalizable—The system is capable of supporting multiple relying parties and BYU's agent can accept claims from them. The foundational evidence for the claim at the relying party can be mocked up, it doesn't need to come from Canvas or some other system.
Bonus Phase: Self-Issued Claims as a Personal API
Matthew Hailstone made an interesting point on a draft of this post: proof requests amount to a very flexible personal API. This bonus phase explores that idea.
The requirements for the system built in the Bonus Phase include the following:
- Student can self-issue claims (9)—The student can create claims based on information in the student profile.
- Relying parties use claims (10-14)—Relying parties can use self-issued claims in the same way they can in Phase 2.
- Self-issued claims are backed by pre-registered schema—Any claim issued by the student will be based on claim schemas pre-registered in the Sovrin ledger.
Sovrin proofs based on claims can be thought of as a very flexible personal API where any claim schemas the student profile supports become valid requests.
Future Work
The following is reserved for future work and is outside the scope of the proof of concept.
- Using public keys for authentication—An entity's DID is linked not only to it's agent, but also to a public key that has been created specifically for that identifier. These public keys could be very useful for authenticating the various entities in the system. The proof of concept won't do that unless specifically required for issuing and using claims.
- Social Login—the profile doesn't have to support OAuth-based login or OpenID Connect for use as an authentication platform.
- Domains—The proof of concept does not have to be hostable on Cpanel-based hosting system like BYU's Domains system.
Photo Credit: Student in Class from Albert Herring (CC BY 2.0)
.jpg){kind=link}