Claim Doctype

[michaelsena]

cip: 
title: Claim Doctype
author: Michael Sena (@michaelsena), Joel Thorstensson (@oed)
discussions-to:
status: Idea
category: Standards
type: RFC
created: 2020-05-22
requires:
replaces: 

🚨 This is a placeholder for an idea, and we will work to draft the CIP at a later time. Feel free to leave comments and ideas on this issue.

Simple Summary

This CIP specifies a Claim Doctype which can be used for creating W3C-compliant verifiable claims as Ceramic documents.

Abstract

Motivation

Claims should be issued to a DID.

Claims assert one or more statements about an individual or organization, not a specific account. For this reason, claims should be issued to a DID. By issuing claims to a DID, the claim instantly becomes reusable across all the accounts linked to the DID and everywhere the DID authenticates. This is especially important as users begin to use more wallet addresses to interact with applications. With this model, claims issuers get more usage out of their claims since they can be used in many more environments.

Claim state should be managed on a permissionless network.

In order for claims to be usable, their current state needs to be trusted by consumers. By using Ceramic documents to store the claims themselves or the hash of the current claim, issuers can easily perform version control of their claim in a simple, permissionless, and verifiable way.

*Claims can be made public.

If claims are stored on a server or offline on a device, availability is a huge variable. By storing some claims as permissionless documents on Ceramic, claims are always available and never offline.

Claims should be updatable.

Sometimes claims need to be updated after being issued. This is extremely difficult if claims are just vanilla signed data sitting offline or inside a user's data hub. However, by issuing claims as documents on Ceramic, they can be updated (version controlled) by simply updating the document. This is especially useful for claims that include non-static values or information such as credit scores, reputation, experience points, etc.

Claims should be easily revokable.

Sometimes claims need to be revoked after being issued. This is extremely difficult if claims are issued as vanilla signed data. The verifier of the claim would always need to validate the claim against some permissionless revocation registry to determine if the claim they received is still valid. However, claims issued as Ceramic documents simplify the revocation process entirely. The issuer only needs to update the document to make the claim invalid.