Verifiable Credentials Doctype

---

cip:
title: Verifiable Credential Doctype
author: Anmol Agarwala (@sylar217)
status: Idea
category: Standards
type: RFC
created: 2020-08-31
requires: Doctypes (CIP-5)

---

## Simple Summary

This CIP describes the `Verifiable Credential` doctype, which contains signed claims, subject and issuer that can be presented and verified as ceramic documents.

## Abstract

The `Verifiable Credential` doctype stores signed claims issued by one DID(issuer) against another DID(subject) in W3C Credential format. This allows applications built on top of ceramic to store and present claims natively. The document would also store a content hash derived from the claims, making the revocation of claims easy as issuer who owns the document could update the claim changing the content hash.

## Motivation

The use cases for Verifiable Credentials(VC) are enormous and out of scope for this document but adding a native support in ceramic to support these cases will be great. For an eg. it fits really well where an user can store VC like university degree, driver license, etc. as ceramic documents and then present the same document across various applications which can be verified independently. Privacy and security of these documents is something that still has to be decided as to which layer should it be handled. Either re-use access control which could be provided by ceramic core or build one separately for VC documents along with encryption.

## Specification

Below is a possible record format for `Verifiable Credential` doctype. It highlights the owner, claims and the claim hash properties.

### Record Formats

The **Genesis Record** has the following required properties:

- `doctype` - Must be equal to `VerifiableCredential`
- `owners` - The list of issuers DID string issuing the claim.
- `tag` - Must contain `VerifiableCredential`.
- `data` - Must contain two properties `claims` and `claimsHash` containing claims in W3C format and the hash of the contents of the claims respectvely.

An example document could like this:
```json
"doctype": "VerifiableCredential"
"tag": ["VerifiableCredential"]
"owners": ["did:3:bafyreifiups3vbub2tk3n2lcachw6gdbqstchrfuvoj3verjku4vbnt2ru"]
"data": {
"claims": "{
'type': [
'VerifiableCredential'
],
'proof': {
'jws': 'eyJhbGciOiJFUzI1NksifQ.eyJAY29udGV4dCI6WyJodHRwczovL3d3dy53My5vcmcvMjAxOC9jcmVkZW50aWFscy92MSJdLCJjcmVkZW50aWFsU3ViamVjdCI6eyIiOnsibmFtZSI6IiIsInR5cGUiOiIifSwiaWQiOiJkaWQ6MzpiYWZ5cmVpZml1cHMzdmJ1YjJ0azNuMmxjYWNodzZnZGJxc3RjaHJmdXZvajN2ZXJqa3U0dmJudDJydSJ9LCJpc3N1YW5jZURhdGUiOiIyMDIwLTA5LTA2VDE5OjA3OjI4LjUyNFoiLCJpc3N1ZXIiOnsiaWQiOiJkaWQ6MzpiYWZ5cmVpZml1cHMzdmJ1YjJ0azNuMmxjYWNodzZnZGJxc3RjaHJmdXZvajN2ZXJqa3U0dmJudDJydSJ9LCJ0eXBlIjpbIlZlcmlmaWFibGVDcmVkZW50aWFsIl19.0nt9epapsSJPsw9AFMxHhkaL6C9BJEaxN8yodkI-kEO_9Zl2wTjMvBPlX2FFj6Y85SozRU2J1LSuGT1SYoC3Ag',
'type': 'Secp256k1VerificationKey2018',
'created': '2020-09-06T19:07:28.524Z',
'proofPurpose': 'assertionMethod',
'verificationMethod': 'did:3:bafyreifiups3vbub2tk3n2lcachw6gdbqstchrfuvoj3verjku4vbnt2ru#signingKey'
},
'issuer': {
'id': 'did:3:bafyreifiups3vbub2tk3n2lcachw6gdbqstchrfuvoj3verjku4vbnt2ru'
},
'@context': [
'https://www.w3.org/2018/credentials/v1'
],
'issuanceDate': '2020-09-06T19:07:28.524Z',
'credentialSubject': {
'id': 'did:3:bafyreig47wtmufh63mdabhrxe5v5be6kcq65pb2bctub3vhlcuh6k245su',
'attended': {
'name': 'HackFS',
'type': 'Hackathon'
}
}
}",
"claimsHash": ""
}
```

Finally the genesis record is signed and encoded using dag-jose. Rest of the record formats and state transistion should follow as per the specs.

## Rationale

How to store claims in the document and in what format was something that was discussed. One approach was to store it as JWT token, which can then directly be presented and verified. This approach was limiting to what JWT supports and didn't fit quite well in Linked Data Format. We thought of rather storing the entire claim as W3C format which would contain [Linked Data proofs](https://w3c-ccg.github.io/ld-proofs/) which supports advanced use cases like ZK Proofs, Derived Predicates, etc.
For revocation of a claim, we wanted to avoid any dependency between various parties involved in the process or multiple hops needed in some of the existing solutions. We chose to use hash derived from the claim content which could serve if the claim is valid. The issuer could later invalidate the claim content which would change the hash, making it revoked.

## Implementation

As part of HackFS an implementation for the same could be found [here](https://github.com/cod1ng-earth/filDID/tree/main/ceramic-doctype-verifiable-credential).
> Note: The above link to repository is just for reference and needs to be updated.

## Security Considerations

Given the use cases of Verifiable Credentials as well as what it contains, security is definitely that needs to be thought through without compromising the basic use cases. Few of the things that needs to be closed on are:

- Encrypting the VC doctype.
- Storing VC doctype privately.
- Access control.

Ceramic supports DID format called 3ID, allowing VC Doctype to linked to it and use the key-chain it contains to encrypt, sign and verify content. Its still has to be closed as to what features might be available as part of ceramic core and the rest might have to be a part of doctype implementation.

## Copyright
Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).