"Verifiable Claim" as a concept without a direct data model mapping

[dlongley]

I think that "Verifiable Claim" is a concept that does not actually have a direct mapping in our data model, yet we are trying to shoehorn it in. The implementations don't support it. I think we're (mistakenly) trying to say "Here is where the verifiable claim is in the data model" simply because the work is called "Verifiable Claims Data Model".

Instead, we should embrace that "Verifiable Claims" is an overarching concept only. You do not make a claim "verifiable" by putting it into a "Verifiable Claim" or anything of that sort. You do not simply attach a signature to a claim to make it "Verifiable" in our data model.

Instead, you create an "Entity Credential", which includes a number of other important properties (such as the issuer of the credential) and you place one or more claims inside of it. Then the credential is signed, making the entire element verifiable -- a "Verifiable Credential".

We should not have a "Verifiable Claim" in the data model. In my view, we should have: "Claim", "Verifiable Credential", and "Verifiable Profile".

A Claim is simply a statement about a particular subject, the subject having a typically pseudonymous identifier.

A Verifiable Credential includes N Claims, who made those claims, expiry information, revocation information, (so on) and a mechanism (e.g. a digital signature) for verifying authorship. Most of our data model revolves around this.

A Verifiable Profile includes N Claims, which may be backed by M Verifiable Credentials (thus making the Profile verifiable) that can be used to verify the authorship of those Claims, and a mechanism (e.g. a digital signature) for verifying proof of possession of the pseudonymous identifier that links all of the Claims together.

[jandrieu]

I think the distinction we need to preserve is that the architecture mustn't require that credentials--as issued--be presented directly to inspectors. If we do that, we are replicating the passport/driver's license paradigm and will leak personal information in the same way.

To support selective disclosure, the holder needs to be able to present just some claims / proofs from any originating credential that supports it. (Some credentials of course will only have one atomic claim.)

There are several ways to achieve this, but my understanding was that the simplest is to assure independent verifiability of claims, so the claims get bundled into a profile and the inspector can then verify each claim independent of the credentials which sourced those claims. Or the originating credential is used to generate proofs and those proofs are selectively presented to the inspector. In neither case does the inspector see the originating credential.

Perhaps I'm not following what you're calling a credential. Are you suggesting that Profiles include not just claims but also the originating credential? That seems flawed to me.

[dlongley]

@jandrieu,

To support selective disclosure, the holder needs to be able to present just some claims / proofs from any originating credential that supports it. (Some credentials of course will only have one atomic claim.)

There are multiple ways of accomplishing this with varying levels of cryptographic (and other) complexity. I agree that we should try hard to ensure our architecture enables all of them.

There are several ways to achieve this, but my understanding was that the simplest is to assure independent verifiability of claims, so the claims get bundled into a profile and the inspector can then verify each claim independent of the credentials which sourced those claims. Or the originating credential is used to generate proofs and those proofs are selectively presented to the inspector. In neither case does the inspector see the originating credential.

This would not be the simplest way. You do not need to make Claims independently verifiable from their source Credentials.

The simplest way to do selective disclosure is for issuers to atomize claims such that each credential has a single claim in it. So, for example, when issuing credentials to a holder, the issuer may issue both complex, comprehensive credentials and atomized ones for each individual claim (where it makes sense to do so).

Other ways to do selective disclosure involve using special signature/proof mechanisms that allow the credentials to be manually decomposed without losing the ability to verify them. There are a number of these approaches being explored by the Credentials CG.

We can support the "simplest way" and the more complex ways with the same model, namely:

If you want to make the claims in a Profile verifiable, you add a claim that there is a certain set of Credentials asserting those claims. Those Credentials may have just one Claim each and those Credentials can be the "originating" Credentials. This is the "simplest way" to selective disclose Claims; to use Credentials containing just one Claim. More complex ways may present "originating" Credentials that have been decomposed or redacted in some way -- or they may present dynamically generated Credentials that contain only whatever information the holder decided to disclose.

This does not require that Credentials be presented as issued, but note that they can be without violating selective disclosure, provided that the Issuer atomized them. If the Issuer did not, we must rely on either advanced cryptography or additional protocols that can dynamically rewrite Credentials to perform selective disclosure.

So I am advocating that presenting originally issued Credentials is a perfectly appropriate use case. There are other use cases where it is more appropriate to present decomposed or dynamically generated Credentials.

[dlongley]

A more concise way of describing my position:

We should not require advanced cryptographic methods or highly available infrastructure to share credentials simply because the presence of both of these eliminates the need for Issuers to atomize credentials. Our architecture should not assume these features exist everywhere people want to use credentials in the ecosystem. We can have simpler primitives.

[jandrieu]

This seems rooted in semantic ambiguity. My understanding had been that the defining characteristic of a credential is that it is a bundle of claims, but you're discussing a very different kind of credential. I also understand that a claim is a statement about a subject and a verifiable claim contained whatever additional meta-data was required to assure inspectors that the claim was made by the issuer and remains unrevoked.

I'm not sure that redefining credential==verifiable claim helps.

With your def (if I am following), issuers now must issue multiple credentials if they want to enable minimal disclosure of given claims. When these multiple credentials logically/conceptually comprise the same real-world "credential", like a degree, what do you then call the amalgam of credentials? At least before, I could understand that a degree might be published as a credential and include claims such as graduation date, field of study, type of degree, and GPA, and each claim could be independently presented and verified.

I am not suggesting we need advanced crypto. Simply ensuring each claim can be independently verified allows credentials to be published with multiple claims and holders can select which claims to present.

[dlongley]

"verifiable claim contained whatever additional meta-data was required to assure inspectors that the claim was made by the issuer and remains unrevoked." <-- That's a "credential". This is the essence of this very issue.

[dlongley]

With your def (if I am following), issuers now must issue multiple credentials if they want to enable minimal disclosure of given claims.

Must? No. That is just one approach.

When these multiple credentials logically/conceptually comprise the same real-world "credential", like a degree, what do you then call the amalgam of credentials?

A set of credentials. Logically/conceptually in the graph (and using JSON-LD tools that merge graphs), they will combine to form the same document (e.g. educational degree) that would have been formed by the credential that contained all of the claims at once. The data model is compositional. It doesn't matter if you've got four credentials with each talking about a single statement about the degree or one credential that has all four statements. The statements are all about the same subject so they will conceptually refer to the same node in the graph.

At least before, I could understand that a degree might be published as a credential and include claims such as graduation date, field of study, type of degree, and GPA, and each claim could be independently presented and verified.

There are signature mechanisms that can allow this to happen. This hasn't changed. But it can get really tricky -- where issuers do not want you to be able to break apart credentials into individual claims because you could potentially reassemble them in ways to make new assertions that the issuer never intended. For example, putting together your GPA from one degree with the GPA from another degree. So the issuer would need to atomize credentials for you in a way that they understood to be valid.

I am not suggesting we need advanced crypto. Simply ensuring each claim can be independently verified allows credentials to be published with multiple claims and holders can select which claims to present.

But that statement is vacuous with respect to the cryptographic implementation details. And those are vital. How would you allow the claims to be separated? That how is the "advanced crypto" I'm referring to. It may not be CL signatures (crypto heavy), but you do need to at least devise a scheme to make use of available crypto primitives to accomplish the task.

For example, put a signature on every single claim. But, you can't just sign every single claim, you also have to sign the issuer of the claim. Well, now you've got a credential. If you want to sign each claim + the issuer, just issue N credentials. That's what they are anyway.

[burdges]

If you want a scheme that does not overtly harm users, like by enabling tracking, or even identity theft, then you need the specification to mandate specific "advanced crypto" and you need years more cryptographic research to know what it should say.

Imho, it's a mistake to even try this now because any generic scheme needs to something like verifying a certificate chain in zero-knowledge, while more specialized schemes can do much more efficient things, like single-use anonymous tokens or ring signatures.

[jandrieu]

I still don't think you're adding anything by proposing a change. The current terminology section says

entity credential
A set of one or more claims made by the same entity about a subject.
https://w3c.github.io/vc-data-model/WD/2017-08-03/#terminology

You are proposing we change that, but so far I only see splitting semantic differences. While we can discuss the system with any consistent set of definitions, constantly changing definitions doesn't help anyone.

You ask

How would you allow the claims to be separated? That how is the "advanced crypto" I'm referring to.

You gave the simple answer. The "claims" property in the credential contains a set of independently verifiable claims, each signed. No advanced crypto at all. That is what is specified in the Entity Credential Model and the Verifiable Claims Model. I don't see that you also need to sign the issuer, however. The issuer ID should resolve to provide what you need to verify the signature. If you assume a simple public key / private key architecture, the subject ID simply needs to resolve to the public key of matching the private key that generated the signature.

Yes issuers would have to decide the granularity they want to enable and which decomposition/recompositions are appropriate. That's true no matter the data model.

I did just realize that throughout the spec we sometimes say "claims" when I thought we meant verifiable claims. For example, I think it would be more accurate to say

entity credential
A set of one or more verifiable claims made by the same entity about a subject.

But now what I see between the Entity Credential Model and the Verifiable Claims Model is that credentials are sets of claims, some of which may be verifiable.

So... the current language supports what I've argued about a credential containing multiple independent claims, although I don't see why we should ever support non-verifiable claims.

However, you're wrong in the title

"Verifiable Claim" as a concept without a direct data model mapping

It is literally in the data model section.

[msporny]

Hey @jandrieu, I think there's a lot of miscommunication happening between you and @dlongley. I'll try to submit a PR that clarifies what @dlongley is talking about to give us something concrete to comment on.

Here's the bottom line: About 18 months ago, we changed from talking about "Credentials" (which were verifiable) to "Verifiable Claims" against our better judgement, because there was pressure from the big players to rename our spec. In hindsight, that renaming has led to a number of confusions, some of which are easily identifiable in this thread. One of the problems is that without a very thorough knowledge of how the data model and signature schemes work, it's easy to come to different conclusions about what a "verifiable claim" is and isn't.

In any case, I'll try to suggest some changes to the spec in a PR so that we can discuss against a more fully baked proposal. I don't have an ETA on when I'll be able to put the text together, but revamping the Core Data Model section is the very next thing on my todo list for the VC Data Model spec.

[dlongley]

@jandrieu,

I don't see that you also need to sign the issuer, however. The issuer ID should resolve to provide what you need to verify the signature. If you assume a simple public key / private key architecture, the subject ID simply needs to resolve to the public key of matching the private key that generated the signature.

Having the the "subject ID resolve" to a particular document is something specific to Linked Data Signatures. We want to also support other mechanisms. It's simpler, and therefore less error prone, to implementers (and verifiers) if you sign all of the metadata.

However, you're wrong in the title

"Verifiable Claim" as a concept without a direct data model mapping
It is literally in the data model section.

We're miscommunicating. I'm saying that what's written in the spec currently tries to shoehorn "Verifiable Claim" into the data model not because it makes sense to implementers, but because the title of the work includes "Verifiable Claim" in it. Implementations don't use "Verifiable Claim" how it's currently expressed in the data model (in prose and pictorial) -- and I doubt that they ever will. They use "Entity Credential".

You'll note that the examples we have in the spec (JSON and JSON-LD) for Verifiable Claims are actually just Entity Credentials. When you try to express a Verifiable Claim, you end up expressing an Entity Credential. There's no actual distinction when implementing.

[jandrieu]

Ok. Cool. It sounds like there's a clarification coming soon.

Just one note: I said "subject ID to resolve" rather than the even simpler, subject ID is the public key itself. As long as you can start with the ID and eventually get to checking the sig, there still doesn't seem to be a reason to sign the ID. Who is signing it?

[stonematt]

@msporny and @jandrieu -- since the PR67 is merged, does that indicate that his issue can be closed?