Increasing traceability: Verfiable Credentials / Verifiable Claims

[joepio]

There are many use cases for verifiable credentials.

One of the core features of Atomic Data is the Commit model, which makes data highly traceable. However, making sure that one specific value is 'accredited' by a specific individual is kind of a bothersome process: get a resource, find the commit which updated some specific field, get the agent (which inclludes the public key), check if the public key matches the property.

A single Verifiable Credential contains a Claim(s), some Proof(s) and some metadata.

Generally, I think there are two ways of thinking about credentials

Resource level

. The first one is to think of credentials as just Resources with their own properties. This approach is the most familiar - just take the W3C VC model, create some atomic properties, and we're good to go.

But this approach introduces a few difficult problems:

• Can we re-use a Credential resource as a normal property-value combination? For example, if my birthdate is actually verified by my municipality, can I still use this as a birthdate property in my profile? Should we convert all Credentials to regular property-values?

Atom level - Just use Commits

Atomic Commits are, in essence, all signed credentials. There is a date, an author, a signature, a subject, and a (set of) properti(es). This means all Atomic Data created using Commits is entirely verifiable! So we don't have to invent anything new, right? Well, with Commits we've tackled an important part of the problem already, but the next step is discoverability.

How would you know that a specific property is actually a proven, verified one, instead of something that I just made up?

We'll need a way of finding the Commit. We could use an Endpoint for that.

Path Endpoint for claim validation

One way of being able to finding credentials (the commit) for a certain atom, is by having a /verifiable-check?path="thing property" endpoint which takes an Atomic Path and returns a collection of Credentials. For example, I might try to find a signed bachelor's degree by a university by visiting /verifiable-check?path="profile bacherlors-degree. Maybe we could also filter by value. It would return the Commit(s) that match that subject / property / value combination. The client can then verify the signature, and check the set value to verify / validate the commit.