Skip to content

Latest commit

 

History

History
149 lines (109 loc) · 16.5 KB

solid-vc.md

File metadata and controls

149 lines (109 loc) · 16.5 KB
Raw

SolidVC: A Decentralized Verifiable Credentials Management System

By Kayode Ezike

Introduction

Credentials are an integral part of our lives. They express our capabilities and consequently determine our access to restricted activities and privileges. For a while, there had not been a very coherent process for securely and privately expressing, distributing, and verifying credentials on the Web, a convenience that would otherwise automate and disencumber the process of granting access to specialized services. To address this apparent deficiency, the World Wide Web Consortium (W3C) proposed the Verifiable Credentials specification. This specification laid out a cogent framework for the issuance, storage, presentation, and verification of credentials on the Web.

SolidVC is a decentralized Verifiable Credentials platform built with the open protocols of the Web and for the open community that the Web was intended to serve. It enables the unilateral issuance and presentation of credentials by anyone running the software locally, as well as verification of these credentials against an open credential status document. SolidVC is implemented in the context of Solid, a Web technology developed at MIT in 2016 that allows decentralized applications to interact with personal data on behalf of users in an access controlled environment. In this paper, I discuss the motivation of SolidVC, provide sufficient background of supporting technologies, present my contribution, outline a real use case, and discuss future improvements to the platform.

Related Work

The notion of Web based credentials is not entirely new. Many specifications and implementations have addressed this issue in one way or another. I have already referenced Verifiable Credentials, but even before that specification, there was the Open Badges specification, which took an initial stab at standardizing achievement credentials on the Web by proposing an ontology that supports such an ecosystem. At its peak, Mozilla Backpack, an implementation of Open Badges, enjoyed participation from thousands of organizations worldwide and generated an order of badge instances in the millions.

Additionally, Massive Open Online Courses (MOOC) have contributed formatively to the Web credential ecosystem by opening up the private silos of knowledge to the world and allowing for students to share achievement credentials across various platforms. Coursera and edX are some of the early examples of MOOCs that enable the exportation of certificates to other personal and professional platforms, such as LinkedIn.

With time, the credentials community evolved, identifying and avoiding some of the shortcomings of earlier solutions, which largely restricted the issuance functionality to established institutions and constrained the storage of credentials to a single platform (enabling exportation to a few compatible sites at best). Many certification and credential management platforms that have surfaced to address some of these issues have emerged largely from the domains of Self-Sovereign Identity (SSI) and/or Distributed Ledger Technology (DLT). These include the Credential Handler API, uPort, [Blockcerts](https://www. blockcerts.org), and [Hypercerts](https://github.com/inesc-id/dclaims-pm/blob/master/ thesis-project-doc/Hypercerts_project.pdf). In this paper, I will discuss a solution that combines many of the tenets and benefits of its predecessors to provide an open and accessible framework for storing, exchanging and verifying self-contained credentials on the Web.

SolidVC

In this section, I present SolidVC, a decentralized implementation of the Verifiable Credentials specification that leverages various ontologies, protocols, and specifications of the Web to deliver a robust and extensible credentialing system. By the end of this section, the hope is that the reader understands the various entity roles, procedures, and use cases that are spanned by the SolidVC ecosystem.

Stakeholders

There are three primary stakeholders in the SolidVC ecosystem: Subject1, Issuer, and Verifier. These roles are no different than those specified in the Verifiable Credentials specification. In a later section, I will specify the behavior of each of these user types.

Ontology

In SolidVC, I represent credentials with a custom ontology called svc2. The svc ontology defines terms that represent the credential type (i.e., Education, Health, Finance, etc.), the embedded claims, the Subject, the Issuer, and the proof.

Figure 1: Sample Credential

The primary resource types in svc are Credential and CredentialStatusList. Credential represents the self-sufficient credentials that are requested, issued, shared, and verified in SolidVC. Some of the key properties of this resource are id, domain, issuerId, and subjectId. Meanwhile, the CredentialStatusList resource type represents the evolving status of a credential and includes properties such as credentialStatus, credentialId, revocationReason, and revocationDate.

Protocols

SolidVC consists of a number of well-defined protocols for handling credentials. In this section, I will outline these protocols in detail.

Setup

Prior to using SolidVC, there are a number of dependencies that the user must install in their local environment (henceforth, svcLocal) and in a public SolidVC-provisioned folder that resides in the user's Solid pod (henceforth, svcRemote). The software package includes a script (henceforth, svcSetup) that checks and establishes that mission-critical prerequisites and constraints are maintained in svcLocal and svcRemote. Some of the functionalities of svcSetup are the following:

  • Authentication of the user to their Solid account in order to enable privileged access to resources
  • Generation of a cryptographic key pair for signing and verifying credentials on the platform
  • Publication of the user's public key to a user-defined folder that resides within svcRemote
  • Update of the user’s Solid profile document to point to their previously published public key
  • Configuration of a credential status folder in a user-defined folder that resides within svcRemote
  • Persistence of the user's relevant information to a configuration file

Request

Although the Verifiable Credentials specification imposes no requirement for credential request, SolidVC includes it as a convenience nevertheless. In the Subject app interface, the user can explicitly request a credential from the Issuer via Linked Data Notifications (LDN). Because a credential requires the verifiable completion of a set of achievements, the Subject is encouraged to provide minimally sufficient data for the sake of efficient authentication and capability determination.


Figure 2: Request and Issuance Protocols

The structure of a credential request is a lot like that of a credential proper. Not only does it include much of the same metadata, such as the domain, title, description, and Issuer ID, but it is also signed by the creator. The latter condition enables the detection of the scenario in which a malicious user sends a request for a credential on behalf of another unsuspecting user. Without this provision, users might be prone to a form of Denial of Service (DoS) attack that involves launching credential requests from multiple different Issuers, who might respond to the victim in quick succession.

Issuance

In the Issuer app interface, the user can directly create, sign, and issue a credential to a knowingly deserving Subject. This interface is useful if the Issuer already has the proof and user information that they need to reward a Subject with a credential and, consequently, a credential request would be superfluous.

Figure 3: Issuance Interface

The Issuance protocol consists of the following detailed steps:

  1. Parse N3-serialized credential into rdflib quad store.
  2. Add credential metadata (i.e., id, domain, and credentialStatus) statements to quad store.
  3. Serialize credential quad store into JSON-LD in preparation for digital signing via [jsonld-signatures](https://github. com/digitalbazaar/jsonld-signatures).
  4. Load key pair from svcLocal.
  5. Sign credential with key pair.
  6. Submit signed credential to Subject of interest.
  7. Instantiate new rdflib quad store that will contain credential status metadata.
  8. Add credential status metadata (i.e., credentialId and credentialStatus) to quad store. Note that the Issuer has complete freedom over the choice of credential ID, as there is no expectation that this ID be dereferenceable on the Web, considering the sovereignty of credentials on the platform.
  9. Serialize credential status quad store into N3.
  10. Submit new credential status document to credential status folder in svcRemote.

Sharing

Sharing credentials in SolidVC is rather simple.

Figure 4: Sharing Interface

There are two ways to share credentials with other stakeholders:

  1. File Upload: In this mode, the Subject wielding control over the credential can upload a local credential-bearing file that was previously downloaded from SolidVC to their computer.
  2. URI Provision: In this mode, the Subject wielding control over the credential provides the URI of the credential and the ID of the stakeholder, often a Verifier. This triggers a fetch of the credential from the URI and an LDN-supported communication of the content.

Verification

In order to verify the provenance and integrity of a credential, the user simply needs to enter its URL.


Figure 5: Verification Protocol

The Verification protocol involves a number of key steps:

  1. Fetch credential from user-provided URL.
  2. Search credential for Issuer ID.
  3. Discover Issuer public key from Issuer ID via LDN.
  4. Search credential for URL of its status document.
  5. Fetch credential status (i.e., ACTIVE, EXPIRED, REVOKED, etc.) and related metadata, (i.e., expiryDate, revocationReason, etc.) from remote credential status folder established during svcSetup.
  6. Search credential for jsonld-signatures proof.
  7. Use combination of public key and proof to verify that the nominal Issuer was indeed the Issuer of the credential.

Figure 6: Verification Interface Upon Success

Revocation

The Verifiable Credentials specification prescribes the use of the credentialStatus property to augment the credential with useful metadata. This field references a special type of credential that describes the state of the original credential of interest. In SolidVC, there is provision for this notion in the svc ontology. For the user's perspective, the revocation interface simply prompts them to enter the ID of the credential and the reason for revocation. The following is a comprehensive outline of the technical steps involved in the Revocation protocol:

  1. Fetch local credential status folder into local rdflib quad store.
  2. Search for credential status document with credential ID provided by the user.
  3. If credential ID is not present in the user’s credential status folder, return and report to the user. Otherwise, prepare to update the relevant credential status document with revocation metadata.
  4. Load revocation metadata into a local rdflib quad store. Relevant metadata include reason and date of revocation, as well as the REVOKED state among other things. In a separate quad store, load RDF statements that may be living in the credential status document, but is incongruent with a revoked credential. Such data includes the previous state (i.e., ACTIVE or EXPIRED) or other metadata associated with that state.
  5. Submit a SPARQL PATCH request including these insertions and deletions to the credential status.
  6. Report whether credential status update was successfully recorded.

Use Case: Driving License

In this section, I provide a discussion of a typical use case of SolidVC in the context of driving certification. The point of the featured scenario is to give readers insight into the kind of credentialing activity that SolidVC supports.3

Setup

Alice is interested in receiving a driving license in the state of Massachusetts. In order to begin this process with the Massachusetts Registry of Motor Vehicles (RMV), she first needs to download SolidVC and execute svcSetup. Fortunately for Alice, she only needs to run svcSetup once in order to gain long-term access to the SolidVC ecosystem with a single Solid account.

Request

Alice visits the SolidVC Subject interface; enters the WebID of the RMV, a SolidVC-compliant Issuer; and selects the Transportation option. She proceeds to enter the relevant request metadata, including the WebID of an RMV employee named Chris, and an optional title and description for the request.

Issuance

During a cursory review of his SolidVC inbox, Chris notices Alice's recent request. Upon reviewing the request and the attached information, he immediately returns a rejection notice, explaining that Alice must complete a month-long driving course and take an hour-long driving test in person. Alice uses the linked resources in the rejection notice to apply for the driving course and prepare for the driving test.

After a month, Alice has completed the course and taken the test. She reaches out to Chris again, who confirms that she is now certified to drive in the State of Massachusetts. Chris proceeds to the Issue panel of the Issuer interface to create, sign, and deliver a new driving license to Alice.

Verification/Revocation

On her way home from an evening outing with her friends, Alice is stopped by Victor, an officer of the Boston Police Department. The officer suspected and confirmed that she was driving under the influence (DUI). After ascertaining the validity of her license via the SolidVC Verifier interface, Victor reported Alice’s poor behavior to Chris from the RMV, who subsequently revoked the new license using SolidVC’s revocation function. The result is a status of REVOKED, which would appear in the credential status document associated with Alice’s license

Figure 7: Verification Interface Upon Failure

Future Work

There are a number of improvements that I envision for SolidVC. Here is a brief outline of some that come to mind:

  • One-to-many SolidVC-Solid account mapping
  • Extended RDF serialization support
  • Issuer Discovery
  • Credential persistence
  • Credential expiry support
  • Command line interface
  • Overall extensibility

At RWoT9, I am open to engagements of varying degrees of formality around items of relevance presented in this paper and beyond.

Footnotes

1In an earlier draft of Verifiable Credentials, there was a clear delineation drawn between Subject and Holder, in which the former is the user that is being described in the credential (e.g., child, dog) and the latter is the controller of the credential (e.g., parent, pet owner). In the latest version of the specification, the Subject role seems to be deprecated in favor of the Holder. For simplicity, I have decided to use Subject to describe the persona that encompasses functions from both of these roles in the specification.

2The latest version of svc will most reliably be located in the GitHub repo, while the domain referenced above will be updated periodically to reflect the latest changes. Note that the latter contains a stale version of the ontology at the time of this publication.

3Many of the claims in this section, such as personal names, institutional policies, and organizational affiliations with SolidVC are fictional, but are referenced here as real for demonstrative purposes.

References