Do we have to introduce the `Credential` class in the VCDM vocabulary?

(This discussion may belong to the comment thread of #1014, but it is not commenting on the main line of the discussion. I have therefore decided to create a separate issue.)

As a result of the introduction of credentials+ld+json there is now a discrepancy between the media types used in the spec and the vcdm vocabulary. I do not think that is healthy.

At present, there is no class for a Credential in the vocabulary (although it is there between the lines, i.e., in the term definitions). We only have a VerifiableCredential term. Now that we have a a separate media type for credentials, i.e., a (non-verifiable) credential is now a separate "thing", we may want to consider introducing a separate Credential class to the vocabulary.

However, if we do this, we have several issues that we have to consider. These issues reflect the discussions we have in #1014. (Note that this is not only boring question of RDF; the vocabulary is a (simple) ontology, i.e., it forces us to pin down the exact relationships of the various terms we are using.)

The fundamental question is: is a VerifiableCredential a subclass of Credential or not? This is, essentially, the counterpart of the question whether (if we go down that route) we would have verifiable+credential+ld+json or verifiable-credential+ld+json, respectively. The alternatives on the vocabulary are:

VerifiableCredential is a subclass of Credential
From the vocabulary point of view, this is a relatively simple thing. Most properties (credentialStatus, validFrom, etc.) have Credential as a domain; by virtue of subclassing using those terms on VerifiableCredential instances is perfectly fine. One would be tempted to refer to proof as the outlier, but the domain of that property, which is defined in the Security Vocabulary is not defined explicitly, probably because the idea is that the term proof could be used on other concepts than credentials. I.e., even if we introduce a restriction whereby a proof must not be used on a Credential, that statement may remain "outside" the formal ontology. (Alternatively, there may be some complicated OWL2 statement that would lead to a contradiction if proof was used on a Credential, but I am not sure it would be worth it; it would probably be of a form that simple OWL2 reasoners could not handle, so would be ignored in practice).
VerifiableCredential is not a subclass of Credential
From a vocabulary point of view, what it would mean is that all aforementioned properties would have, as domain definition, a disjunction, something akin to "VerifiableCredential or Credential". Which is fine. However, a further question is: are VerifiableCredential and Credential disjoint? It certainly feel like this would be the case; luckily, OWL can express that easily, the only practical obstacle is that the yaml2vocab script we use should be extended to introduce such extra restriction (but that can be solved).

Note that the introduction of Credential may affect the examples in the spec which, for now are all of the form:

   …
   "type": ["VerifiableCredential", …],
   …

which may have to use Credential instead. But, I believe, by virtue of having credentials+ld+json separately this makes sense in any case...

@dlongley @msporny @OR13 @mprorock @brentzundel

Thank you for filing this. Still digesting it.

Similar to the argument regarding media types, we should avoid creating new RDF classes if we don't need them.

As a personal opinion (i.e., with my staff contact's hat put down) I would be strongly in favour of the first alternative, ie, the subclassing approach. It keeps the vocabulary simple, and it corresponds, ontologically, to the fact that a verifiable credential is a credential...

IFF we introduce the Credential term, then I agree with Ivan's statement that

VerifiableCredential is a subclass of Credential

That said, my opinion is that we should NOT introduce the term. I'm in favor of only having VerifiableCredential defined. It simplifies the spec on multiple aspects. I would also be favorable to renaming the VerifiableCredential term to something else, that doesn't elevate the verification aspect above other normatively required properties.

Let me elaborate on why I think we should only have a single term.

We can informatively refer to something as a Credential, with the understanding that it's a VerifiableCredential without proof associated with it. But to refer to it normatively, then I ask myself the following: Which required fields justify having a separate term to describe an object where that field isn't present? For example, what is a VerifiableCredential without @context? Is that a SemanticlessVerifiableCredential? Would a TypelessVerifiableCredential make sense? A SubjectlessCredential? AnonCredential (perhaps one without an issuer and without a proof)?

The conclusion I arrive to is that there already exists a brand (which is also a normative term) called VerifiableCredential, and we're giving special treatment to the proof field only because the brand name is the composition of two words (Verifiable and Credential). I don't know the history as to why that name was chosen, and that's something I'd love to learn. If today we were referring to VCs with the alternative brand names (like w3c-creds, a made up word like Vecred, or a completely different term like Ocred), then it is my belief that it would be clear that a new term is not needed.

Furthermore, I would suggest we replace the use of the term Credential in the spec (like what's used in the examples), and instead use the term Unsecured VC.

@msporny @dlongley would love to hear your thoughts on this.

I would prefer not to make implementations more complicated by having to use Credential in the type field. I think we can solve this problem by ensuring the vocab says VerifiableCredential is a subclass of Credential and then we continue to just use VerifiableCredential in the type field.

I would prefer not to make implementations more complicated by having to use Credential in the type field. I think we can solve this problem by ensuring the vocab says VerifiableCredential is a subclass of Credential and then we continue to just use VerifiableCredential in the type field.

@dlongley just to understand what you propose:

We do introduce an explicit Credential class in the vocabulary, as a superclass to VerifiableCredential, and modify the vocabulary that way (ie, by adjusting the domains and ranges accordingly
We do not really refer this class in the examples of the core spec not to mess up the casual reader/implementer

I do have a clear opinion on (1) (which is a "yes!") but I do not have a clear opinion on (2), so I let you guys decide on that. I am not a VC implementer, nor am I a familiarity with that community, and I am obviously biased by my background...

@iherman,

Yes, to 1 and 2 -- I'm trying to find a middle ground where we can do the vocabulary properly and keep implementations simple.

I'll be saying similar things to the following in a few threads, I think, as overlapping topics are being covered in multiple issues...

We must remember that classes and subclasses (a/k/a types and subtypes) do not necessarily require differentiation in their Media Types, and in fact, some subtypes SHOULD NOT have a Media sub-Type — such as the EncryptedStrawManDocument subtype of StrawManDocument — because the encryption changes the content of an application/encrypted+credential+ld+json document sufficiently that trying to fall back and handle it as an unencrypted application/credential+ld+json document will be an utter failure — unless the encrypted payload (which might have any of a number of Media Types (a/k/a formats)) is just one piece of the application/credential+ld+json.

I am firmly convinced that we need Credential and VerifiableCredential types. I am less convinced though leaning toward Presentation and VerifiablePresentation types. I am becoming significantly less convinced of the utility — not to mention compliance with Media Type rules — of application/verifiable+presentation+ld+json vs application/presentation+ld+json.

This comment does not represent completed thoughts, but I thought it more important to start others thinking about the same things, than to finish the picture myself.

The issue was discussed in a meeting on 2023-02-28

no resolutions were taken

View the transcript

### 1. Add normative requirements regarding media type and proof (pr vc-data-model#1014) _See github pull request [vc-data-model#1014](https://github.com/w3c/vc-data-model/pull/1014)._ _See github pull request [vc-data-model#1034](https://github.com/w3c/vc-data-model/pull/1034)._ _See github issue [vc-data-model#1044](https://github.com/w3c/vc-data-model/issues/1044)._ **Brent Zundel:** There is a long conversation in the PR, goal of this meeting is to hash out what different sides of debate are, and can then try to come to proposals, recommendations on how to move forward.. **Manu Sporny:** There are a couple of threads for this discussion. One of the threads is "hey, we should have a media type for unsecured credentials and we should have one for secured ones. Those are the two classes we should have.". … "If we are going to do that then the unsecured credentials should have no securing mechanism in them." That's the argument for `application/credential+ld+json` MUST NOT or SHOULD NOT have a `proof` property in it.. … The other argument is `application/credential+ld+json` has an extension mechanism and one of those might add a securing mechanism in it and we can't predict what mechanisms other people do, there might be new ones people define in the future and the language can't stop that from happening even if we put text in the spec.. … Even if we say you can't put `proof` in there, we can't know all the different mechanisms that might happen in the future. The other part of that argument is, "well, you can have very deeply nested and structured VCs and we already have examples of things that learner records and transcripts that might have badges, workforce skills credentials, things that have embedded proofs in them and that's a valid use case.". … Potentially the outer envelope is not secured but the inner ones are.. … So that's kind of the argument for "they may contain proofs".. … So we're looking at `application/credential+ld+json` either: "MUST NOT/SHOULD NOT have proof" or "MAY HAVE proof".. **Michael Prorock:** I think that's a reasonably good summary, in my mind, it's a more fundamental question. What is a credential? What makes it a verifiable credential?. … The way I think of it, once you add a signature, it goes from credential to verifiable credential. Once I see `application/credential+ld+json`, that's a credential, is an input type.. … once you sign it... it becomes a verifiable credential. We can define what goes into the process, what makes something a VC, and if we can drive that line, we should do that. We can't cover non-compliant stuff w/ the spec, but we should cover cases that we know of.. **Dave Longley:** I think it's good to avoid confusion where we can, we have to be careful about avoiding confusion when we're talking about secured vs. unsecured or trusted vs. untrusted data... the recipient of the data needs to have an expectation about what they're receiving. They can't just accept whatever the sender sends, that opens the door to potential vulnerabilities.. … Another thing to consider around type is that a VC can be seen as a subtype of credentials, that concept allows for different use cases. Different parties might care about different types of credentials or not. If you have a VC or a credential, a digital wallet can display both.. … People might want to accept things that accept VCs or credentials and add proofs -- so proof chaining, timestamp proofs, and we should be careful to not close the door to innovation, but we should be careful to think that we /can/ close that door. If we put in prohibitive statements, someone will figure out a way to get around it if it gets in the way. For example, someone could do a `proof2` field to get around something that says that `proof` isn't allowed.. **David Waite:** Some of this may be defining the behaviour when you have multiple proofs by default, I can remove one of the proofs and it's still verifiable, just with less mechanisms.. … The guidance on what to do when there are multiple proofs -- pick your favorite one, do them all for higher assurance, that would be helpful for this discussion, proofs can be dependent on other proofs as well. I have a proof that is protecting other existing proofs, those can't be removed. So some of the assumptions about difference between VC and credential and having proofs, really are in the eye of the verifier.. … Some of the idea here is "if I have something like a JWS wrapping an external proof, and the proofs inside, what are the semantics that people should assume?" If we can't provide semantics that have value, maybe it's not legal in that case.. **Michael Prorock:** The PR here is explicit around one line related to `application/credential+ld+json` media type. Those of us that are planning on using that tend to feel strongly, either this is input into something that gets linked data signature, or have external signature... not sure why we would `application/verifiable-credential*` or some structure that signifies that you have proof there, additional semantics, etc. Avoiding the fact that we can be clear here bothers me, frustrating to me that we can't be explicitly clear about desire to just have credential format w/o proof in it. There are representations that have proof block in there, media type used in cty/typ or other use cases.. **Manu Sporny:** So I want to agree with what David Waite was saying.. … That the difference between a VC and a credential is in the eye of the verifier. I think that's interesting there, I don't know how I feel with that as an absolute statement, but that resonates with me. There could be a VC with multiple proofs on it, but the verifier only wants to check 2 of them.. … Maybe one is BBS, one is post quantum, one is ECDSA.. … The verifier in that case may only case about ECDSA. They may choose to ignore the other proofs ... or they may choose to look at a proof further down the tree.. … Mike, to look at the use case that you highlighted. ... Here's a concrete use case. If I have a learner record in the education space. The outer thing has no proof, but the inner one has all the classes I took this year and there are class descriptions and skillsets all with proofs.. … Is that thing with 50 proofs at the second level ... is that top level thing a credential or a verifiable credential?. … You could argue this. I think it's problematic ... I think the PR language doesn't seem to give us an answer for that use case.. … I think it doesn't give us an answer for that use case or use cases where there are other securing mechanisms used. And ultimately, it's up to the verifier to figure out which proofs it cares about.. … It might be then that sometimes different mechanisms determine whether it's viewed as verifiable or not. It's the compound / complex objects that have signatures at the leaves that could be impacted negatively by this language. If we can be more specific we should be.. … Mike's argument for having two different media types for verifiable vs. credentials resonates with me to communicate more specific media types for what I mean.. … Remember, we have `application/credential+ld+json` which means you can process as JSON, JSON-LD, or as a credential in the VCDM.. … We have that concept.. **Dave Longley:** media types are not necessarily the right tool to make sure that something is an input to an API. The media type is a way to identify the type of content and how it would be parsed and used, regardless of what API you're using it in. It's a more encompassing thing, not for just one particular use case, one particular API, it's not the right tool for accomplishing that.. > *Michael Prorock:* [https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Accept](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Accept) etc. of course multiple use cases. **Dave Longley:** That said, APIs have their own shape, can provide their own restrictions, you can do that, that's not a problem and that might be the right way to define that, you can do that via API schemas to accomplish that goal.. **Kristina Yasuda:** Manu's comment confused me. I do not understand the concept of top level, secondary level proofs, one of the things we did in data model v2 is we separated data model in how we sign/secure it. The notion that something that conceptually is not supposed to be signed can have this proof is very confusing to me.. … That's a use case we need to pay attention to -- is that a valid use case? We have `proof` in data model, we should move it down to proof formats. I don't think anything related to signatures belongs there.. **Michael Prorock:** Big +1 to what Kristina said, building on that, we have a good model if we accept this PR, core data model defines what a credential is, and how different specifications might process that... what's expected, in VC-JWT there is a clean way of specifying media types, what to expect when, JWS, or something COSE related, since we have a nice data integrity spec, perhaps we should put media types w/ proofs in a credential, people know how to deal with that information.. **Manu Sporny:** To address Kristina's concern. We have a concept here -- and JWTs deal with it differently. With Data Integrity proofs, you can have documents that nest other documents and each can nest proofs at every layer.. … We have examples like learner records where that's a reality. Talking about it like "are we going to allow it or not" isn't the right framing because it's already a reality today. It doesn't matter if this group says that structure is illegal, people already find it useful and do it.. … They don't have to base64 at each level and things of that nature.. … We do need to get to the bottom of that and making stuff like that illegal would be a much bigger issue than just this PR.. … The other thing we should consider is that people might use a VP proof and then put a JWT on top of that. I know some people don't want to see that happen, but others might. Given the way things are going in the ecosystem it's probably inevitable that we'll see things like that.. > *Kerri Lemoie:* Learner record spec from 1EdTech doing the embedded VCs that Manu described: [http://www.imsglobal.org/spec/clr/v2p0/](http://www.imsglobal.org/spec/clr/v2p0/). **Manu Sporny:** Saying `proof` doesn't belong in the core data model and we should put it in Data Integrity, etc. then we shouldn't be making it illegal to include a `proof` either. That would be a weird layering violation.. … I think this is us thinking that we have the ability to use a media type to enforce something that people will probably ignore if we write the wrong thing here. I think if we say that the `application/credential+ld+json` must not have any securing mechanism in it, people will ignore that, the use cases are valid.. **Dave Longley:** big +1 to what manu said... if we moved proof into data integrity, it would further undercut case for restricting `credential+ld+json` in this PR, you wouldn't have anything to point to to do it. We should embrace the subclass concept. I'm tagging media type that's specific... another thing to have a less restrictive media type. To provide an analogy -- you can have applications that have rectangles, application accepts it... squares are a more specific type of rectangles... you should be able to use your rectangle library on a square. That's ok, that's what subclass mechanism gives us.. … We have an extensible data model, people will want to know why we added prohibitive statements about use cases they want to do in the future.. **Kristina Yasuda:** To clarify -- not questioning legitimacy of use case where there are nested data integrity proofs -- what I'm not understanding is credential that is conceptually not supposed to be signed, including a proof property? That's what clearly separates credential from verifiable credential. Let's not completely remove proof from data model, remove it from section 4 to section 6.. > *Michael Prorock:* +1 Kristina. **Kristina Yasuda:** Imagine a JSON structure that includes proof property... and that is signed by JWS... if that enters JWS processor, that doesn't understand proof claim, it'll ignore it. In which case, signature is entirely being ignored, which I'm concerned about. Is there a way to resolve that? Happy to hear solutions.. **Michael Prorock:** No one is saying these are not valid use cases, we want a clear and valid media type. … Wanting a media type that doesn't have an embedded proof in it, that's a valid use case as well.. **David Waite:** In the spec we talk about embedded proofs and external proofs, way to state the same thing... embedded proof is a way to extract proof and recanonicalize to create an external proof over the document. It comes down to giving recommendations --- if one proof is chaining, pointing into another, you cannot express outer proof w/o inner one, but you can strip off outer proof, so when people embed a data integrity protected VC inside a JWT, they need to understand that they're requiring twice as much security processing logic... that may affect full stack decisions, or they could just discard the JWT and send credential and data integrity around and they need to decide if it's appropriate or not. If we do have it, we should have a SHOULD NOT with guidance.. **Dave Longley:** There are going to be many applications that can accept a credential whether or not it has a proof attached to it, important that base media type supports that... if there are other applications that want to have a media type that specifically says "this property is not allowed in this media type" - I think we can do that, but I recommend against it, I don't think it's a good idea. I don't think we should call that out on the base media type. Maybe have base media type to be superclass of other things, someone could create a media type for their other applications, can't have specific property.. … I don't think anyone would want to create 10 different media types for data they don't want their applications to accept, media type isn't the right tool for that.. > *Paul Dietrich:* +1 dlongley. **Dave Longley:** "What if this verifier receives something where a signature has been stripped?" -- verifiers need to know what to expect from a holder. They will know what proofs they need to look for, they need to know which issuers to trust, how many signatures to expect, etc... we should remember that we're defining a base data model here, there are things that people don't necessarily process in a credential... base media type that's a super class allows that to happen, I don't think there's a problem there.. > *Kristina Yasuda:* interesting - i though in the open world model, any proof type can enter verifier's system. **Kristina Yasuda:** yes, but what they accept is up to them. **Manu Sporny:** I think we need to look at the PR. The PR is specifically talking about the `application/credential+ld+json` and saying that it can't have `proof` in it.. … Mike, I think you're talking about something else, a media type for a verifiable credential and at this moment in time I agree with you. I definitely agree with JWTs there because it's a base64-encoded dotted string, not JSON.. … That's not true of the Data Integrity secured VCs though.. > *Kristina Yasuda:* `@dlongley` if verifier only supports JWS it will not know it accepted DI proof signed as JWS, so they can't even make a decision whether to accept or not. **Manu Sporny:** So I think the thing you mentioned is a different conversation and that I agree with you more over there, than on this PR. This PR says, we're going to single out this one property and makes it illegal.. … David Waite's SHOULD NOT makes it a little closer, maybe we can do that, but lots people in the ecosystem might just ignore it. I think a lot of people will want to back into what Dave Longley is talking about and that the verifier is going to know what it's expecting.. … Otherwise you're allowing the attacker to choose the attack on your system. You can't trust the media type that the attacker is sending to you. You can't trust that the attack is peeling off a proof, etc. You have to know what you accept.. … You can't trust the incoming media type, the attacker gets to choose it, you can't trust that the thing has the right number of signatures on it, because you can't trust that as well. This goes back to David Waite's comment that the verifier gets to decide what the valid thing is.. > *Ted Thibodeau Jr.:* +1 manu. **Manu Sporny:** I think we're trying to use media types to signal things that we shouldn't rely on, it gives power to the attacker.. > *Dave Longley:* +1 manu. **Michael Prorock:** I don't think anyone is disagreeing on the multiple layers on security checks, not trusting inputs, I would hope all of us in this group are familiar with those concepts.. > *Dave Longley:* kristina: if the verifier supports JWS then if the JWS proof verifies, they are happy, they don't have to care about the DI proof.. > *Kristina Yasuda:* dlongley: i don't agree.. not validating proof/signature is one of the biggest attack vectors (ignoring == not validating here). security analysis needed to say "they don't need to care". Proof by the issuer has a very important meaning in VC ecosystem - verifier ignoring it undermines trust model of three party model. > *Dave Longley:* kristina: that's the two-party model :) ... verifier needs to know what they accept and what they don't. > *Kristina Yasuda:* dlongley: nope, not two party model :). **Michael Prorock:** What I'm concerned about is saying that something should not have a proof in any way shape or form, perhaps from a consensus standpoint we end up in SHOULD NOT. If we want to think about a variety of things, no one here wants a proliferation of media types for every options, No one is asking for a proliferation of business rules defined in the spec. If it is implicitly confusing that receives a proof in it, or embedded in a VC-JWT, what proof type comes first. If we don't have a clear way of saying: "Don't do this, you're going to confuse the user"... it's highly concerning to me. If we leave it up to verifier, certain issuers are going to assume one type of security model might be required w/o clean mechanism to know that they're doing that. Let's try to get explicitly clear about what a credential is before it becomes a VC and then be very clear about that as well.. **Tobias Looker:** I'm still catching up on this issue, so might have perspective that's invalid -- my interpretation of text in PR doesn't insinuate that it makes embedded proofs illegal, media type doesn't establish any semantics around inclusion of property of what it means. If I sent application/json, and data is customer record, that is at a different layer semantically. Embedded proof might have something secured, media type isn't going to communicate presence or processing logic to do anything w/ that.. > *Michael Prorock:* +1 tplooker. > *Dave Longley:* +1 i think i agree with tplooker too, but also that it doesn't support the prohibition statement. **Ted Thibodeau Jr.:** Media types don't do these things... media types don't say "in this structure of file you can only have X field name". Media types give you the structure of the file so you can deal w/ it's contents. If you feed a .zip archive to Excel, it's going to choke because it doesn't know how to deal w/ that content.. > *Dave Longley:* +1 to TallTed. **Ted Thibodeau Jr.:** Vice versa, unzip cannot do anything for you with the contents of an excel file... it's not the structure of the document it works on, the structure is the thing that matters here. Subtypes in the mediatype universe are limited not in what fields they can have and the contents of what they could be... bigger type might allow larger number of rearrangements, smaller more focused might allow less.. > *Dave Longley:* +1 to TallTed. **Ted Thibodeau Jr.:** Media types don't care about proofs, or business logic, or anything like that. Trying to make them do that job, we're going to break all sorts of security models. It don't work that way.. > *Dave Longley:* +1 to TallTed. **Ted Thibodeau Jr.:** I've said in a number of times, a number of places, people don't seem to understand how media types work, if you don't understand how this stuff works, and we try to spec with it, we're going to break something.. **Tobias Looker:** Further the point that I'm making, don't think media type should rule out in an extensible data model technology whether or not the member of an element should /shouldn't make something illegal. I don't think media type should reach into the data representation technology and says "this should never exist". I think that messes w/ data extensibility model in JSON.. > *Dave Longley:* +1 to tplooker and TallTed, media type is the wrong tool for this. **Tobias Looker:** The media type doesn't convey that, media type doesn't tell you anything about what the media type tells you that... it could just be a string w/ some other meaning attached to it. That's all I take the language to mean in this PR. It doesn't communicate anything about the presence of an embedded proof or not.. **Manu Sporny:** +1 to tplooker, Tallted.. **David Waite:** One of the ongoing concerns, we're trying to define an extensible data model to use it in ways that we haven't imagined... even extension points we have, like `termsOfUse`, if there are extensions that you don't understand, what are you supposed to do as a holder or verifier when you see those?. … In Holder Binding, one of the big concerns is if I have an outer proof of VC-JWT, and I have an inner data integrity proof of the same object/document, what does that mean, what does it imply in terms of issuer instructions of understanding that?. … To manu's point, you have to define what sort of verification is expected that issuer expects you to do for verifier to trust that information hasn't been modified. So chained proofs, if that's there, with external proofs and chained proofs, we really need to define behaviour of all of those extension points so people know how to act even if they don't understand what that extension is.. > *Ted Thibodeau Jr.:* can't force that business rule on the verifier. **Michael Prorock:** Is there an approach that might work? If media type is used, embedded proof must be ignored by processor by verifier? This is a reasonably complex thing we're trying to say.. **Kristina Yasuda:** I think we double clicked on statements meant by tobias and tallted -- JWT registered `application/jwt` -- in header, but you can also use `application/jwt` in HTTP response to indicate that's the thing being returned... I thought we dug into that at F2F? That seems to be misaligned as well.. … maybe we can discuss thing from Mike Prorock. > *Dave Longley:* -1 to telling verifiers that the *have* to ignore a proof. **Brent Zundel:** Jump on PR and try to refine some language.. > *Dave Longley:* dlongley: that's more violation of the three party model, IMO. **Brent Zundel:** See everyone on the call tomorrow.. ---

I am opposed to defining RDF that has no impact or use for implementers.

I am opposed to an RDF type called Credential that would contain proof just like VerifiableCredential currently does.

I agree with @OR13 that having an RDF type called Credential that contains a proof would be misleading.

@OR13 @awoie — VerifiableCredential contains proof and is a subtype of Credential so Credential MAY contain proof. Your stated opposition above (@OR13, @awoie) is illogical.

@TallTed There is no @context definition for Credential...

Your assertion that https://www.w3.org/2018/credentials#Credential exists and is a subtype is false, that is a proposal (discussed in this issue).

Only https://www.w3.org/2018/credentials#VerifiableCredential exists.

I assume eventually this issue will become a PR to create the subtype relationship or it will be closed.

That PR would need to modify this vocabulary: https://www.w3.org/2018/credentials/

I am not sure what the controversy is all about, @OR13 @TallTed. This issue asks whether there is a need for a separation between the Credential and VerifiableCredential types. I have the feeling that there is a relative consensus that yes, that would be good. If that is correct, I am happy to do a PR that puts that into practice. If it is incorrect, I do not do anything...

If Credential is like VerifiableCredential but does not contain proof, what other use will this Class have?

I am in favor of creating clarity if the classes will have some use to implementers, and if they do not create further semantic confusion.

Option 1:

"Credential": {
      "@id": "https://www.w3.org/2018/credentials#Credential",
      "@context": {
        "@protected": true,

        "id": "@id",
        "type": "@type",

        "credentialSchema": {
          "@id": "https://www.w3.org/2018/credentials#credentialSchema",
          "@type": "@id"
        },
        "credentialStatus": {
          "@id": "https://www.w3.org/2018/credentials#credentialStatus",
          "@type": "@id"
        },
        "credentialSubject": {
          "@id": "https://www.w3.org/2018/credentials#credentialSubject",
          "@type": "@id"
        },
        "description": {
          "@id": "https://schema.org/description",
          "@type": "http://www.w3.org/2001/XMLSchema#string"
        },
        "evidence": {
          "@id": "https://www.w3.org/2018/credentials#evidence",
          "@type": "@id"
        },
        "holder": {
          "@id": "https://www.w3.org/2018/credentials#holder",
          "@type": "@id"
        },
        "issued": {
          "@id": "https://www.w3.org/2018/credentials#issued",
          "@type": "http://www.w3.org/2001/XMLSchema#dateTime"
        },
        "issuer": {
          "@id": "https://www.w3.org/2018/credentials#issuer",
          "@type": "@id"
        },
        "name": {
          "@id": "https://schema.org/description",
          "@type": "http://www.w3.org/2001/XMLSchema#string"
        },
        "proof": { // proof is included here....
          "@id": "https://w3id.org/security#proof",
          "@type": "@id",
          "@container": "@graph"
        },
        "refreshService": {
          "@id": "https://www.w3.org/2018/credentials#refreshService",
          "@type": "@id"
        },
        "termsOfUse": {
          "@id": "https://www.w3.org/2018/credentials#termsOfUse",
          "@type": "@id"
        }
      }
    },

Option 2

"Credential": {
      "@id": "https://www.w3.org/2018/credentials#Credential",
      "@context": {
        "@protected": true,

        "id": "@id",
        "type": "@type",
        // proof has been removed here.
        "credentialSchema": {
          "@id": "https://www.w3.org/2018/credentials#credentialSchema",
          "@type": "@id"
        },
        "credentialStatus": {
          "@id": "https://www.w3.org/2018/credentials#credentialStatus",
          "@type": "@id"
        },
        "credentialSubject": {
          "@id": "https://www.w3.org/2018/credentials#credentialSubject",
          "@type": "@id"
        },
        "description": {
          "@id": "https://schema.org/description",
          "@type": "http://www.w3.org/2001/XMLSchema#string"
        },
        "evidence": {
          "@id": "https://www.w3.org/2018/credentials#evidence",
          "@type": "@id"
        },
        "holder": {
          "@id": "https://www.w3.org/2018/credentials#holder",
          "@type": "@id"
        },
        "issued": {
          "@id": "https://www.w3.org/2018/credentials#issued",
          "@type": "http://www.w3.org/2001/XMLSchema#dateTime"
        },
        "issuer": {
          "@id": "https://www.w3.org/2018/credentials#issuer",
          "@type": "@id"
        },
        "name": {
          "@id": "https://schema.org/description",
          "@type": "http://www.w3.org/2001/XMLSchema#string"
        },
        "refreshService": {
          "@id": "https://www.w3.org/2018/credentials#refreshService",
          "@type": "@id"
        },
        "termsOfUse": {
          "@id": "https://www.w3.org/2018/credentials#termsOfUse",
          "@type": "@id"
        }
      }
    },

The "controversy" is some working group members appear to want to have the word "credential" and "verifiable credential" apply to the exact same bytes. Other working group members feel this is confusing and undermines the meaning of both terms.

This confusion is playing out in "media types", "spec definitions" and "rdf classes".

@dlongley @msporny Do you think adding option 1 would help clarify your postion that "credential" can have a "proof?... Do you agree we should attempt to define "Credential" in RDF?

I am most inclined to drop VerifiableCredential (and application/verifiable+credential+ld+json, application/vc+ld+json, etc.), and keep Credential (and application/credential+ld+json, etc.).

Whether or not it's verifiable is not a question of its structure, which goes to media type, but a question of the bits held in that structure, which goes to business logic.

It may not be worth having a media type for this at all.

@OR13 wrote:

I am opposed to an RDF type called Credential that would contain proof just like VerifiableCredential currently does.

I don't think anyone is saying "would"... folks seem to be saying "could"... because it's an open world model... any subject can be associated with any predicate unless there is a higher level rule that says it shouldn't... but that's not enforced at the RDF or JSON-LD layer... it's enforced at the VC Data Model layer.

So, for example, if we are producing a JSON-LD Context for Credential, your Option 2 is probably fine as long as we don't prohibit someone from pulling in another JSON-LD Context that allows proof on Credential. <-- I believe that's the thing that most of the folks arguing against banning proof in Credential are saying... but I cringe saying all of that because I don't think most developers will care that much about Credential being defined in the JSON-LD Context since they'll largely be working with VerifiableCredentials... Credentials by themselves have very limited value in the real world, IMHO. The class /does/ have value in the RDF model, however, because it provides a very clear mapping between the terminology in the spec and the RDF classes in the data model.

IOW, we were explicit in conceptually differentiating a credential from a verifiable credential in the v1.0 and v1.1 specification because it was a question that came up repeatedly. The specification makes this distinction one hundred and seventeen (117) times (I just went through and counted). So, and I'm not saying anyone is asserting this, but just to be clear -- I don't think the WG made that distinction on accident. :)

@dlongley @msporny Do you think adding option 1 would help clarify your postion that "credential" can have a "proof?... Do you agree we should attempt to define "Credential" in RDF?

I think we should define Credential in RDF so the formal data model hangs together, and I think we should not add it to the JSON-LD Context (because I don't expect developers to find it useful in practice). If developers want to use Credential, they can create their own JSON-LD Context for it.

We should separate at least three of the discussions that are happening here:

How is Credential and VerifiableCredential modeled from an RDF perspective? (this is largely an academic discussion, but an important one to ensure we're going to be logically consistent in how the entire spec is written). At present, we're logically consistent (or very close) w/ the usage of credential vs. verifiable credential in the spec today.
How are we going to construct the JSON-LD Context for Credential (is it necessary to do so)? (this is largely an implementation consideration)
Is the data structure for Credential useful to developers? (this is largely an academic consideration)

I'll try to provide thoughts on each one separately:

How is Credential and VerifiableCredential modeled from an RDF perspective? (this is largely an academic discussion, but an important one to ensure we're going to be logically consistent in how the entire spec is written).

We make the distinction between credential and verifiable credential around 117 times in the spec today. We shouldn't remove the distinction. Since there is a distinction, it makes sense to reflect that in the RDF vocabulary.

How are we going to construct the JSON-LD Context for Credential (is it necessary to do so)? (this is largely an implementation consideration)

I don't think we have anyone using Credential today (because it's not defined), and if we were to define it, I'm struggling to understand what use case it helps developers solve. I'd venture to guess that most developers today care about creating VerifiableCredentials... not Credentials. The only use of Credential that I can think of is to be academically pure in creating something that you send into a piece of software that immediately turns it into a VerifiableCredential. The benefits of referring to something as a Credential seem to be slim to none.

As such, I don't see a need to put this in the base JSON-LD Context... but we shouldn't prevent someone from creating their own JSON-LD Context that uses the concept. Perhaps when VC v3.0 rolls around, there'll be a set of use cases that demonstrate why having Credential in the base context is useful.

Is the data structure for Credential useful to developers? (this is largely an academic consideration)

Same argument as above... I expect the answer to be: "It's not useful at this point in time other than to convey the logical data model for the ecosystem".

So, to summarize:

Define Credential and VerifiableCredential in the data model.
Do not define Credential in the JSON-LD Context.

... with the caveat that I might feel differently about this next week. :P

@TallTed wrote:

I am most inclined to drop VerifiableCredential (and application/verifiable+credential+ld+json, application/vc+ld+json, etc.), and keep Credential (and application/credential+ld+json, etc.).

I think I'm inclined to go the other way, @TallTed. Let's define application/vc+ld+json, which MUST/SHOULD contain proof and drop application/credential+ld+json... and use the same logic you applied above:

Whether or not it's verifiable is not a question of its structure, which goes to media type, but a question of the bits held in that structure, which goes to business logic.

I'd rather optimize for what developers will be working with most of the time, which is to use and express verifiable credentials... the whole concept of a Credential is interesting, but largely useless when it comes to what implementations will be dealing with the vast majority of the time.

To answer the question of "Well, then what media type do you send an HTTP endpoint to add a proof to a credential" could be: application/ld+json ... or even application/json. Thoughts?

@OR13,

You are presenting two JSON-LD @context files, and that is not relevant here. @context ≠ vocabulary. I am talking about the underlying vocabulary, which is a different thing altogether.

If Credential is like VerifiableCredential but does not contain proof, what other use will this Class have?

The vocabulary/ontology is there to clarify our thoughts, first of all, and I would not underestimate that. But, from a practical point of view, if the vocabulary is used as an ontology for reasoning in a Linked Data context, an RDFS/OWL reasoner would deduce, when seeing a proof property on a credential, that it is indeed a verifiable credential. This is how the deduction mechanism works in RDF/RDFS/OWL & Co. Whether this is something useful in the VC case, I cannot judge; whether it is useful if a VC is included in a larger knowledge graph: probably; whether a VC is ever included in a knowledge graph: I have no idea.

@msporny,

I think I'm inclined to go the other way, @TallTed. Let's define application/vc+ld+json, which MUST/SHOULD contain proof and drop application/credential+ld+json...

This ship may have sailed already... but I sympathize with your opinion. The only thing this issue says: if we do make this strong separation between credentials and verifiable credentials conceptually, the vocabulary should reflect that (at least in my view). If we decide that we keep vc+ld+json only, then this specific issue is moot.

I'd rather optimize for what developers will be working with most of the time, which is to use and express verifiable credentials... the whole concept of a Credential is interesting, but largely useless when it comes to what implementations will be dealing with the vast majority of the time.

I tend to agree with you, but I am not a VC implementer...

@msporny

Let's define application/vc+ld+json, which MUST/SHOULD contain proof and drop application/credential+ld+json... and use the same logic you applied above.

I think with a MAY it aligns exactly with the current RDF definition for VerifiableCredential.

In the spec with the caveat that the "proof" can be "embedded" or "external" this aligns with the term "verifiable credential".

We need to be careful with proof since it introduces bias towards "securing formats", since some use "external proofs".

... your Option 2 is probably fine as long as we don't prohibit someone from pulling in another JSON-LD Context that allows proof on Credential.

I think this is where the strongest disagreement exists.

There are 2 considerations:

How does @protected impact this? similar to https://github.com/w3c/vc-data-model/blob/main/contexts/credentials/v2#L12
Why would an implementer not use type and multiple inheritance to add proof.
If proof is added can it be different than the proof in VerifiableCredential.
If answer to 3 is no, what are the actual differences at the information level between Credential and VerifiableCredential.

As a general rule, a new RDF type should be used when there is new information to represent.

I still don't understand what "new information" would exist, between "Credential" and "VerifiableCredential"... the current arguments in favor of allowing "proof" in "Credential" make me believe there is no new information, and we should therefore NOT define "Credential".

I think I would be fine with us dropping any formal discussion of "Credential"/"credential" and keeping all of that as informal discussion in the spec.

This would include changing application/credential+ld+json to application/vc+ld+json (if we prefer the shortened vc, but that's bikeshedding) and only using VerifiableCredential in the data model in the type field. The new "base media type" would be application/vc+ld+json (bikeshedding aside), with no other side effects to any other decisions previously made. I think this could simplify things for implementers and perhaps help address some of Orie's concerns. We already know that this is how people have been working with the 1.1 spec with success thus far.

To emphasize, it would be vital that this would not undo other decisions and create more work for the WG -- the idea here is to simplify and reduce work. So if the above would do that and we can get consensus around it, then I'd be for it.

[@msporny] Let's define application/vc+ld+json, which MUST/SHOULD contain proof and drop application/credential+ld+json

Change that MUST/SHOULD to MAY and I'm OK with it. application/vc+ld+json describes the data structure of a credential, which may (verifiable) or may not (unverifiable) include crypto signature and/or encryption.

I might be OK with SHOULD, but I'm inclined against it, and I'm definitely not OK with MUST — unless the value of proof may be NULL (or functional equivalent) in both cases.

Just as we don't know every use to which verifiable credentials may be put, I don't believe we know every use to which unverifiable credentials may be put, and I want to preserve sufficient flexibility that another "thing" won't be required to satisfy those unverifiable credential use cases.

[@OR13] We need to be careful with proof since it introduces bias towards "securing formats", since some use "external proofs".

I'd be fine with changing most, probably all, instances of proof to cryptographic signing and/or encryption information or the like.

In my opinion the confusion between credential and verifiableCredential has led to issues around which metadata was tied to the credential and which was tied to the verifiableCredential. So the validity period of the credential became confused with the validity period of the cryptographic proof, whilst the ID of the credential became confused with the ID of the proof/signature. Clearly Orie's Option 1 above continues this confusion by inserting a proof property into a credential. The credential does not have a proof property. If it does then it is by definition verifiable, so is a verifiableCredential

I have set up a PR (#1057) to focus the discussion. The possible changes (or not) on media types or context files are, though related, separate issues...

[@David-Chadwick] The credential does not have a proof property. If it does then it is by definition verifiable, so is a verifiableCredential

A proof property does not render the credential verifiable unless it has an appropriate value. An empty proof property might be included in a non-verifiable credential (or "credential") — or in a verifiable credential for which there is an associated external proof.

The presence of the proof property in a "credential" of indeterminate verifiability is not enough in itself to "by definition" make that "credential" "verifiable".

The presence of the proof property in a "credential" of indeterminate verifiability is not enough in itself to "by definition" make that "credential" "verifiable".

The spec sorta disagrees with this point, though I admit that I have seen this part of the spec consistently disputed by WG members.

At least one proof mechanism, and the details necessary to evaluate that proof, MUST be expressed for a credential or presentation to be a verifiable credential or verifiable presentation; that is, to be verifiable.

https://www.w3.org/TR/vc-data-model/#proofs-signatures

Note the use of the MUST... which is normative, and requires a "test".

Perhaps the spec text is so poor, we must admit that it is never interpreted consistently.

At least one proof mechanism, and the details necessary to evaluate that proof, MUST be expressed for a credential or presentation to be a verifiable credential or verifiable presentation; that is, to be verifiable.

This does not require that such a proof mechanism be expressed via a proof property within a credential, nor does it say that a proof property (if present) must be populated with any specific value(s).

Perhaps the spec text is so poor, we must admit that it is never interpreted consistently.

I will concede this possibility, and continue to strive for better text, toward more consistent (though perhaps never perfectly so) interpretation, particularly but not only because we are actively working on a v2 that is generally if not universally expected to improve on v1.

This does not require that such a proof mechanism be expressed via a proof property within a credential, nor does it say that a proof property (if present) must be populated with any specific value(s).

100% agree... I think the problem is that it is not clear to the WG if a "well formed" "proof" property is sufficient to satisfy the MUST.

The problem with this ambiguity is:

If a well formed data integrity proof is NOT sufficient to make a "credential" a "verifiable credential"... that seems bad.
If a well formed data integrity proof is sufficient to make a "verifiable credential"... this implies that going for 0 to 1 "proof" distinguishes between "credential" and "verifiable credential".

...

seems to not be in dispute, but it has an impact on what people expect the answer to 2 to be.
is very clearly in dispute.

A proof property does not render the credential verifiable unless it has an appropriate value.

I tend to disagree. Even if a verifiable credential has an appropriate value, the credential could still have been revoked and is therefore not verifiable (for example, an imposter could have stolen the issuer's private key, issued the VC, and then the issuer, upon finding out the theft, revokes all issued VCs).

So I maintain that a credential with a proof property is a verifiable credential. The proof property may be badly formatted, null, or use a weak algorithm with known flaws. Nevertheless it is verifiable, but the result of the verification process will yield the result of positive or negative verification.

p.s. Verifiable does not mean verified

p.s. Verifiable does not mean verified

Yes, I tend to agree with @David-Chadwick here as well.

It seems as if talking about a Credential being secured or not has turned out to be a dicey proposition.

However, talking about a VerifiableCredential tagged with a media type of application/vc+* that MUST be secured IN SOME WAY (as PR #1055 is attempting to do) as a mandatory requirement for it to be considered a "verifiable credential" is probably a conversation that could make some progress. Once we decide that, we could come back to this discussion.

I'm increasingly doubtful that normatively formalizing a Credential or a Presentation adds much value. That's not to say it has some value, but the juice doesn't seem to be worth the squeeze.

The issue was discussed in a meeting on 2023-04-12

no resolutions were taken

View the transcript

#### 4.1. Do we have to introduce the `Credential` class in the VCDM vocabulary? (issue vc-data-model#1044) _See github issue [vc-data-model#1044](https://github.com/w3c/vc-data-model/issues/1044)._ **Brent Zundel:** do we have to introduce the credential class in the vc vocab? **Dave:** suggests it be closed and don't need a resolution to do this. > *Manu Sporny:* +1 to close, that we've come to a resolution NOT to define Credential.. > *Orie Steele:* +1 dlongley. **Brent Zundel:** marked as pending closed based on that recommendation.

talking about a VerifiableCredential tagged with a media type of application/vc+* that MUST be secured IN SOME WAY (as PR https://github.com/w3c/vc-data-model/pull/1055 is attempting to do) as a mandatory requirement for it to be considered a "verifiable credential" is probably a conversation that could make some progress.

It's not going to make much progress with me.

A verifiable something is something which can be secured, to the extent that "securing" means "providing means by which to confirm that its content has not been tampered with, and to discover its issuer".

Specific use cases may choose to use weak tools of various kinds, and still work with (weakly) verifiable credentials.

The full structure of a VC can be complied with, and the V can always fail, and the document is still a VC, to my mind. What happens with the business logic thereafter is beyond our remit.

talking about a VerifiableCredential tagged with a media type of application/vc+* that MUST be secured IN SOME WAY (as PR #1055 is attempting to do) as a mandatory requirement for it to be considered a "verifiable credential" is probably a conversation that could make some progress.

It's not going to make much progress with me.

A verifiable something is something which can be secured, to the extent that "securing" means "providing means by which to confirm that its content has not been tampered with, and to discover its issuer".

I'm not sure that's a useful definition... anything can be secured, so if that's your definition, it applies to anything, which makes the distinction not worth much.

I'd argue that one of the things that makes the work this group is doing important is the notion that we're not just saying "anything can be secured"... we're saying: "We expect the VCDM to be secured in these normative ways."

Specific use cases may choose to use weak tools of various kinds, and still work with (weakly) verifiable credentials.

Yeah, that's exactly the sort of slippery slope I'd like us to stay away from, because we can already see vendors trying to rebrand their "weakly verifiable credentials" as "verifiable credentials". There's an active dilution in the sort of verifiability and interoperability that we, as a WG, expect... and that's the thing I'm taking issue with.

The full structure of a VC can be complied with, and the V can always fail, and the document is still a VC, to my mind. What happens with the business logic thereafter is beyond our remit.

Slippery slope... I get what you're saying, and don't entirely disagree with it... it's how vendors will twist your intention that worries me.

Can you think of some clauses that would make it harder for vendors to twist your intention?

PS: This is neither here nor there for this particular issue, it's marked pending close and should be closed. @TallTed I'm wondering if we need a new issue for whatever it is that we're discussing here. :)

Much like the DID Rubric, I think there are some number of attributes of VCs which represent tradeoffs relevant to different deployments/use-cases.

It's appropriate for us to make it as easy as possible for end users to evaluate the VCs from various vendors, and determine whether the strength of their signatures, encryption, etc., is sufficient for their comfort. Hopefully, there will be more than one VC implementation vendor vying for each deployment scenario, and the stronger will win out.

Though some additional comments have been made, no objections have been raised since being marked pending close, closing.

w3c / vc-data-model

Do we have to introduce the `Credential` class in the VCDM vocabulary? #1044

Option 1:

Option 2