Verifiable Credentials Doctype

[sylar217]

---

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:

"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": "<IPLD hash of the above claims content>"
}

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 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.

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.

[oed]

Cool, this seems like a good start for supporting credentials and revocation on Ceramic! Sorry for not getting to this sooner @sylar217! Few questions:

1. Why does this have to be it's own doctype? It seems like it could just use tile since we're only storing the json data of a VC?
2. You mention that JWT would not work. Why couldn't both the json-ld and the jwt represetnations of VCs be supported?
3. So for the claimsHash, this property will always be there. However sometimes the claims property might not be present?
4. How does a claim get revoked? Would there be a new property, something like revoked: true. Or do you imagine some other method being used?

[sylar217]

@oed thanks for reviewing this. My thoughts on the questions would be:

1. Yes, even I think we can use the tile doctype itself, but one doubt I had was regarding signing of the claims. How would we support different signing methods which provide advanced functionality like ZK-proofs, etc. The proofs requirement for a VC could also require it be signed by multiple issuers. So in this case, should the complete payload along with the proof should be abstracted out of ceramic? and the signing of ceramic documents could be optional in this case?
2. Yeah i guess we can support JWT representation too. Maybe add another property specifying the format?
3. I guess we should enforce for claims to be always present? Any use case for someone to create an empty VC document?
4. Initial thought was if the claimHash presented by the holder doesn't match with the latest version of the document, we consider it changed/revoked. But adding a property makes more sense. The W3C data-model specification suggests this way: CredentialStatusList

[oed]

1. I guess that depends a lot on the use case for the credential? I don't know enough about all of the different scenarios to give a comprehensive answer.
2. Yep, that makes sense.
3. I mean if you want to store the claim privately you may only want to have the hash of the claim in the document for privacy reasons?
4. Makes sense to use that 👍