3 Types of Claims

[ChristopherA]

Repeatedly when talking to various people using claims, largely from communities doing reputation systems, they make distinctions between 3 types of claims.

R3, a consortium of banks, at https://bitsonblocks.net/2017/05/17/a-gentle-introduction-to-self-sovereign-identity/ says:

Claims would be stored by typing text into standardised text fields, and saving photos
or scans of documents.

Proofs would be stored by saving scans or photos of proof documents. However this
would be for backward compatibility, because digitally signed attestations remove the
need for proofs as we know them today.

Attestations – and here’s the neat bit – would be stored in this wallet too. These would be 
machine readable, digitally signed pieces of information, valid within certain time windows.
The relevant authority would need to sign these with digital signatures – for example,
passport agencies, hospitals, driving licence authorities, police, etc.

Need to know, but not more: Authorities could provide “bundles” of attested claims, such
as “over 18”, “over 21”, “accredited investor”, “can drive cars” etc, for the user to use as they
see fit. The identity owner would be able to choose which piece of information to pass to
any requester. For example, if you need to prove you are over 18, you don’t need to share
your date of birth, you just need a statement saying you are over 18, signed by the relevant 
authority.

This also come up with the Portable Reputation Toolkit from #RebootingWebOfTrust at https://github.com/WebOfTrustInfo/rebooting-the-web-of-trust-fall2016/blob/master/final-documents/reputation-toolkit.pdf

A user creates a Distributed Identifier (DID).
They get an accompanying private key that they use
to sign assertions.

A user makes an *Assertion* using a JSON-LD claim
format. It is signed with their DID and timestamped
with a decentralized timestamping service like Open
Timestamps. The assertion includes the submitter’s
DID and a target identifier that the the assertion is
about. Later claims can evaluate or invalidate the
statements by pointing to the assertion.

Users publish *Evidence JSON-LD claims. Evidence
is signed by a user’s DID. Evidence JSON-LD claims
link to media, with a unique identifier. The evidence
doesn’t have to be related to any assertion initially.
Evidence can be related to any assertion at any time
using an evaluation.

Any user can challenge or support an earlier
assertion with an *Evaluation*. An evaluation
references an assertion and evidence. It supports or
refutes the assertion. This evaluation will always
point to an assertion, and have a true/false or 0-1
float value judging its "truthfulness". Evaluations
are signed by the creators DID and timestamped.

The end user validates the truthfulness of an
assertion by querying evaluations and evidence
associated with it using an algorithm called a Filter.
Users can develop a list of trusted evaluators for
themselves, import a list from others, or use a filter
template that includes evaluator trust parameters
and weightings. The filter factors in the evidence,
the evaluations, and the trust in the reputation of
each of these to determine the truth or falsehood of
the assertion. The user can apply multiple filters and
audit the Filter to gain multiple perspectives.

[dlongley]

+1 for a section mapping these common terms to how they fit into the VC data model terminology

[jandrieu]

+1 for a section. I concur with the observation mentioned on the call today that all three types of claims can be made within the framework of a verifiable claim, but we don't make that clear. In fact, sometimes we obfuscate it completely. A claim, as currently defined, is always an assertion by the issuer. Assertions could be about other claims and thereby provide evidence or evaluation/refutation.

It would be useful to show example claims that are about other claims, for example, providing evidence for a claim issued by someone else.

[stonematt]

does ProofPurpose fully address this need?

[jandrieu]

This brings up https://github.com/w3c/vc-data-model/issues/118 where I describe how the three different types of claims can be presented using the existing spec.

@ChristopherA spoke about this and boiled it down to (1) a disparate set of terms used differently for similar ideas in different systems and (2) the need for examples to illustrate, in JSON-LD, how the current spec (with or without ProofPurpose) might achieve these three different types of claims.

My contention remains that ProofPurpose creates an added layer of ambiguous complexity and that all of the existing use cases can be implemented with the singular semantic that the proof in a VC means the controller of the proofing credentials uttered the statement embodied in the claims. Disputes, endorsements, evaluations, and evidence are best implemented as new credentials that are about other credentials and not as a bolted on property to the original credential. The signature on these commentary credentials means the signer utters the statement and the claims in the statement express the dispute or endorsement or whatever the comment is.

Chris made a point that some meta-data might be required by a given cryptographic suite. We ran out of time before we could unpack whether or not that makes a coherent case for varied meanings of ProofPurpose.

We'll work on examples.

[burnburn]

@ChristopherA @jandrieu can you guys give an update on this?

[burnburn]

@jandrieu ping again.

[msporny]

The VCWG discussed this on the call today. We are seeking feedback on concrete specification changes that the original issue submitters would like. We have not seen anything in two years on this issue. The VCWG is marking this issue as pending close and will close the issue in 30 days if we don't have engagement from the @ChristopherA and @jandrieu.

[iherman]

The issue was discussed in a meeting on 2021-06-14

• no resolutions were taken

View the transcript

#### 3.3. 3 Types of Claims _See github issue [#47](https://github.com/w3c/vc-data-model/issues/47)._ **Brent Zundel:** recommending changes to the proof property **Manu Sporny:** we have asked for feedback, none has been received, recommended to close if not actioned

[brentzundel]

No engagement since being marked pending close. 30-day window has elapsed. Closing.