Adding the "Credential" class

[iherman]

To make the discussion in #1044 more focussed this PR represents what is proposed in that issue. Some notes are worth adding:

• There is an ambiguity on the term "VerifiablePresentation" insofar as the "Verifiable" adjective is in the name, but we did not discuss whether we want a separation of a Presentation vs. VerifiablePresentation. I propose in the PR not to go that far, although I changed the description text just a little bit to allow for, e.g., a Presentation that present only credentials.

• The PR does not propose any change on the @context file, which is a completely different animal altogether. This is on the vocabulary and the vocabulary only; it only does things (in my view) cleaner.

• The proof property does not appear in the PR, because it is not part of the vcdm vocabulary. Note also that the creators of the proof property do not define a domain for that property, which can of course be used on a Credential class instance, but can also be used on an instance of any other class in the universe. It is a different discussion to have whether we should restrict the domain of that property to credentials.

  Even if introduced a domain restriction for proof to be VerifiableCredential it is very important to understand what this means. It does not mean any type of constraints on an instance. An RDFS domain statement (as any other RDFS/OWL statement) is a license to infer. It means for a reasoner that "I see this instance of a Credential has a proof property on it, therefore I deduce this is (also) a Verifiable Credential". This is very different from a statement of the sort "I see this instance of a Credential has a proof property on it, but this is not marked to be a Verifiable Credential, therefore there is a violation". Expressing that second statement in an ontology, though possible, is very complicated and very few OWL reasoners can handle it (if any).

Practicality: the PR only shows the changes in the YML file. To see the generated HTML and other files, see:

• HTML
• JSON-LD
• TTL

[OR13]

This is wrong, presentations are made from "VerifiableCredentials"... not "Credentials".

• https://w3c.github.io/vc-data-model/#presentations

[TallTed]

[@OR13] This is wrong, presentations are made from "VerifiableCredentials"... not "Credentials".

The block you quoted (by screencap, which is rather hard to work with, and really should be copied-and-pasted text, still including the link to the original) speaks of VERIFIABLE presentations, not presentations.

PLEASE stop acting as if quite specific words and phrases (which were carefully and painfully arrived at, as I know from being a participant at the time) were meant to have less specific meaning, as I will continue to tell you, they were not, and your disingenuous quotations will only make the current process longer and more painful!

[OR13]

@TallTed there is no RDF definition for "Presentation", and the section I am commenting on is regarding the id "VerifiablePresentation".

[iherman]

Yes indeed, I had to stop on how I would have to describe a VerifiablePresentation and, indeed, the "logical" approach is to refer to Verifiable Presentations only.

However. Do we have cases when a Presentation structure is used for Credentials only? If I encapsulate a Presentation in JWT with the proof left as external, I would indeed present a credential and not a Verifiable credential, right (I am not a JWT expert)? If so, do we want to go down the (painful) route of differentiating between a Presentation and a VerifiablePresentation? Isn't that an overkill? So I ended up doing what I did, as described in the PR description above.

[iherman]

Forgot to say: it is a bit like in #1057 (comment) insofar as defining a Presentation that holds Credentials would cover all the use cases, because a VerifiableCredential is also a Credential. The only reason why I did not change the name to Presentation is because the term VerifiableCredential is already widely used, and a change of term name would create problems.

[brentzundel]

@TallTed I do not agree that Orie is acting disingenuously. If you have concerns that WG members are acting in bad faith, the appropriate step is to contact the chairs for a conversation. Making accusations in github comments is not appropriate.

[OR13]

I strongly dislike the "usually" language here...

[iherman]

This is a bit the same question as for Presentation vs. VerifiablePresentation. Do we want to have a separate CredentialGraph and a VerifiableCredentialGraph? We do not know what the future holds, and I am tempted to define a CredentialGraph only, which is used to encapsulate a graph with a single Credential. Because a VerifiableCredential is also a Credential, this covers our current usage. Hence my choice in the naming.

[OR13]

This seems like an improvement... but I note the conflict with https://github.com/w3c/vc-data-model/pull/1057/files#r1124649817

[iherman]

Conflict?

[OR13]

Sorry, more detail would have helped here...

Are VerifiablePresentations made of Credentials?

Are VerifiablePresentations made of VerifiableCredentials?

Are Presentations made of VerifiableCredentials?

Are Presentations made of Credentials?

If a VerifiableCredential is a Credential, and a VerifiablePresentations is a Presentation....

These are the conflicts I mean....

The current spec defines "VerifiablePresentations" in terms of "VerifiableCredentials", you noted the confusion here:

• Adding the "Credential" class #1057 (comment)

[TallTed]

Whenever possible, when presenting text, please present it as text. It is difficult to read the screencap, and impossible to copy-and-paste from it, which is likely to be helpful in suggesting revisions (on either side of the flagged conflict).

[OR13]

Is proof one of these claims?

[iherman]

Not specified as part of this vocabulary and, by default, yes, it can be a proof.

Never forget: a VerifiableCredential is also a Credential (that is what subclassing means).

[OR13]

I don't see the subclass as defining any new information then... and it seems... not helpful.

It leads me to consider that both names are equally useful, and as such, we need only define 1.

[OR13]

I like the attempt to define Credential in relation to VerifiableCredential.

I don't like the relation to VerifiablePresentation, but maybe I will come around to this after a while, given it is sorta similar to Bearer JWTs.

It seems weird to see VerifiableCredential replaced with Credential, but perhaps this is just an artifact of how these files are used to compile the vocabulary.

Is there a way to preview these changes as a vocabulary file / context file?

[OR13]

@iherman I really appreciate the PR description you have added for this.

One problem exists with your argument regarding proof.

• https://w3c.github.io/vc-data-model/#proofs-signatures
• https://github.com/w3c/vc-data-model/blob/main/contexts/credentials/v2#L53

I am still trying to understand this part:

It means for a reasoner that "I see this instance of a Credential has a proof property on it, therefore I deduce this is (also) a Verifiable Credential".

Today, we only see instances of VerifiableCredential with proof... so I am confused by the meaning of the sentence above.

This is very different from a statement of the sort "I see this instance of a Credential has a proof property on it, but this is not marked to be a Verifiable Credential, therefore there is a violation".

I believe this becomes an "undefined term" when JSON-LD enters the scene... hence the need to understand the context in order to agree to this PR.

[iherman]

I like the attempt to define Credential in relation to VerifiableCredential.

I don't like the relation to VerifiablePresentation, but maybe I will come around to this after a while, given it is sorta similar to Bearer JWTs.

It seems weird to see VerifiableCredential replaced with Credential, but perhaps this is just an artifact of how these files are used to compile the vocabulary.

Is there a way to preview these changes as a vocabulary file / context file?

I have created a separate vocabulary preview (HTML and JSON-LD), see the introduction of the PR.

[iherman]

I am still trying to understand this part:

It means for a reasoner that "I see this instance of a Credential has a proof property on it, therefore I deduce this is (also) a Verifiable Credential".

Today, we only see instances of VerifiableCredential with proof... so I am confused by the meaning of the sentence above.

This is very different from a statement of the sort "I see this instance of a Credential has a proof property on it, but this is not marked to be a Verifiable Credential, therefore there is a violation".

The first statement is how a RDFS/OWL (or a any ontology reasoner on the open web) works. The second statement would be a constraint checker, like SHACL which, essentially, reduces the graphs at hand to a closed world.

Let me try to explain the difference a bit further, maybe that would help, but sorry if I am verbose. Succinctness does not really work here. (Caveat: my semantic web background is a bit rusty, I hope @pchampin or @TallTed can point out if I make a mistake.)

What an open world reasoner, like RDF/OWL, essentially does is look at the available data as well as the corresponding ontologies, and attempts to deduce new relationships that are not explicit in neither of the two. To take a very simple example, if the ontology says "the (directed) relation p is transitive) and see data which says

a —p—> b
b —p—> c

the reasoner will deduce that the relationship

a —p—> c

also holds, although that relationship is not encoded in the data. This deduction possibility is what makes the linked data reasoners interesting and useful.

What does the domain RDF relationship mean? This is how it is defined in the RDFS/OWL spec family:

if the following relationship holds:
    prop —domain—> Cl
and the data has the statement
    x —prop—> y
then the following relationship also holds
    x —type—> Cl

i.e., a new relationship can be deduced from the data. Translating it to our case:

If we have
  (1) VerifiableCredential —subclassOf—> Credential
  (2) proof —domain—> VerifiableCredential
  (3) x —proof—> ProofObject

then we can deduce
  (4) x —type—> VerifiableCredential // by combining (2) and (3)
  (5) x —type—> Credential           // by combining (1) and (4)

The example also shows the danger of using the domain relationship; this means any instance can become a Credential if a proof is used for it; luckily this is not the case because, as I said in the introduction, at the moment there is no domain restriction on the proof property's definition.

That is all! Nothing more can be deduced from the available data. In particular, with such simple set of ontology statements, OWL/RDFS cannot express any kinds of constraints and therefore cannot check violations.

(Actually, the last statement is not entire true. It is possible for a reasoner to come to a conclusion that some properties that are deduced contradict one another. Ie, it is possible to express some forms of constraints on properties and classes using, for example, something called cardinality constraints. But those are usually fairly complicated, in some extreme cases so complicated that existing OWL reasoners may not even be able to handle them today. And even if they can, the user would have to use complex reasoning software for those, which is hardly worth it for our case. And these may also hit the issue of the Open World assumption: if you have a Credential instance in Austin, you may not know whether I would add a proof on it here in Aix-en-Provence...)

If we want to impose constraints, essentially turning the dataset into a closed world, we would be talking about a very different tool set (SHACL, essentially). If you remember, we did that for DID, but the problem is that SHACL is not adapted for the VC case: VC has a heavy reliance on RDF Datasets (as opposed to single graphs only) and SHACL cannot express that (see also #76).

I believe this becomes an "undefined term" when JSON-LD enters the scene... hence the need to understand the context in order to agree to this PR.

I do not see how JSON-LD would change anything here. JSON-LD is (at the heart of it) "just" a serialization of the RDF (or RDF Dataset) model in JSON, and the @context is "just" a syntactic mapping from JSON term names and objects to the URL-s and graph patterns in an RDF graph. JSON-LD does not add anything to the fundamental behaviour of RDF in this respect.

I hope this helps.

[iherman]

The example also shows the danger of using the domain relationship; this means any instance can become a Credential if a proof is used for it; luckily this is not the case because, as I said in the introduction, at the moment there is no domain restriction on the proof property's definition.

I could not resist 😀... OWL gives you another approach to describe the characterization that we are looking for without using a domain definition on the proof property. It would be possible to say something like

An instance is of type VerifiableCredential if it is a Credential and it is the subject of at least one proof property.

This makes use of what is called a "cardinality restriction" in OWL. The syntax in RDF is fairly convoluted, but a syntactic translation of what is said above in JSON-LD is:

{
    "@id": "cred:VerifiableCredential",
    "owl:equivalentClass" : {
        "owl:intersectionOf" : {
            "@list": [
                "cred:Credential",
                {
                    "@type": "owl:Restriction",
                    "owl:onProperty" : "sec:proof" ,
                    "owl:minCardinality" : {
                        "@value": "1",
                        "@type" : "xsd:nonNegativeInteger"
                    }
                }
            ]
        }

    }
}

However, this alternative to rdf:domain does not fundamentally change what I said in #1057 (comment) about what OWL would do and would not do. It just makes sec:proof free to be used for other purposes as well, the proof would not be "bound" to credentials only. This may be a good thing.

(If we decide that it is worth adding the structure above to the formal vocabulary, to make it clearer and, in a way, more complete and clean, I would have to do some work adding such a feature to the yml2vocab script. I am happy to do that, but it may take a few days...)

cc @pchampin @TallTed

[OR13]

VerifiableCredentials that have an external proof won't use the "sec:proof" property I think, so the at least 1 definition, while maybe workable in an RDF database for Data integrity proofs, does not map to the external proof cases.

Unless we change the definition of "sec:proof" to also apply to external proofs.

I'd prefer we just stop trying to define Credential or media types for it, and instead define VerifiableCredential and a media type for it, and say proof is optional.

We could even replace the word "credential" with "statement" in the spec to further separate the concepts.

[TallTed]

[@OR13] We could even replace the word "credential" with "statement" in the spec to further separate the concepts.

"statement" is commonly used as a synonym for a singular "triple" or "assertion", not for a "graph" (a collection of "triples"), which I would expect most if not all "credentials" to contain, so I would strongly object to that replacement.

I'm not sure I understand which concepts you meant to separate with that replacement, so maybe you could delve deeper into that, if your suggestion was more serious than not?

[OR13]

We keep using the words credential and verifiable credential in the spec, but maybe there are better words and better definitions we could be using.

https://csrc.nist.gov/glossary/term/credential

https://csrc.nist.gov/glossary/term/assertion

https://www.merriam-webster.com/dictionary/statement

https://datatracker.ietf.org/doc/draft-ietf-tls-subcerts/

https://www.rfc-editor.org/rfc/rfc9334.html#name-terminology

And most importantly...

https://www.rfc-editor.org/rfc/rfc4949.html

If the working group does not agree on what "credential" means, perhaps another word for the "thing that lacks authorship that can be digitally verified, but is otherwise the same as a verifiable credential" would help, especially if the other word is less similar to "verifiable credential" which is possibly not verifiable, and confusing when compared to the existing vocabularies and glossaries in the security space that define "credential".

Currently it seems there is no consensus that verifiable credentials need a proof or that credentials can have one without becoming verifiable... Making both terms less useful, and their relationship to each other ambiguous and possibly overlapping.

Additionally, W3C VCWG seems to be on the edge of defining terms (such as credential) in ways that contradict other security communities, such as NIST and IETF... With absolutely no benefit to implementers.

I suspect that most people who read the spec will be confused by these facts.

We should define only what is required, and avoid contradicting other security communities.

Defining credential seems to be taking us down a path that can maybe be avoided, by the working group choosing to only define "verifiable credential", and choosing not to define "credential" as the latter may never yield consensus, and the former is already defined in both JSON-LD and spec text, albeit with language that nobody seems to read the same way, or agree with.

[iherman]

VerifiableCredentials that have an external proof won't use the "sec:proof" property I think, so the at least 1 definition, while maybe workable in an RDF database for Data integrity proofs, does not map to the external proof cases.

You are right. My comment is moot😞

Unless we change the definition of "sec:proof" to also apply to external proofs.

I do not really see what it would mean. IMHO, we should not go there.

I'd prefer we just stop trying to define Credential or media types for it, and instead define VerifiableCredential and a media type for it, and say proof is optional.

Personally, I am fine with that approach. This may mean that this PR would probably also be moot, but that is fine with me, too.

We could even replace the word "credential" with "statement" in the spec to further separate the concepts.

Maybe. I would propose to push this question into a separate issue, though. The vocabulary only follows, and by no means replaces or leads the specification, so I do not think this is the right place to discuss this.

[OR13]

@iherman

Maybe. I would propose to push this question into a separate issue, though. The vocabulary only follows, and by no means replaces or leads the specification, so I do not think this is the right place to discuss this.

I agree, sorry for raising it here... My point was that choosing to not define Credential in detail may lead the WG towards wishing to de-emphasize credential in the core data model.

[TallTed]

Potential food for thought —

A credential without a proof is analogous to a passport application. It collects all (or at least most) of the claims (a/k/a assertions, a/k/a statements) that will be printed in the little booklet that is the form factor of most physical passports. The application is one or more pages of fill-in-the-labeled-blanks, accompanied by some evidentiary documents, and usually two prints from the same photographic negative (or similar). The application is not typically referred to as an unverifiable credential (and it might become a verifiable credential, with the issuer being the applicant, or perhaps a servicer who mediates between the applicant and the relevant state department... or it might become a verifiable presentation, since the evidentiary documents may themselves be verifiable credentials).

[iherman]

The issue was discussed in a meeting on 2023-03-14

• no resolutions were taken

View the transcript

2.5. Adding the "Credential" class (pr vc-data-model#1057)

See github pull request vc-data-model#1057.

Orie Steele: This issue 1057 is a tarpit, it probably won't go anywhere, I don't think we will succeed in adding RDF language of Credential as a class.

Brent Zundel: If folks want to jump on the queue, please do so.

Dave Longley: I'm more optimistic, given the decision, some of the things we were pushing to create explicit separations, vs. conceptual differences that we discuss in spec. If we talk about these things in spec, instead of making them explicitly in RDF vocabularies, there is a good amount of support for that approach.
… Which would mean, we don't need to add these additional things to RDF Vocabulary.

[OR13]

A credential without a proof is analogous to a passport application.

Interesting idea.

This could be a path forward, but I suspect it might further erode the value of defining credential.

Your passport is not equal to your passport application plus a proof.

They have different structure, they contain different information.

Some information from the application is present in the passport, other information is used during issuance, but not present in the final credential.

We must also consider the case of:

A credential with a proof is analogous to a passport application.

You can claim all the authority you want when submitting your application, and the issuer can reject your application if you are claiming it is "already equivalent to a passport"... In the future, they might prefer you submit a "signed passport application" which makes it clear that you have issued a self attested credential to represent the application, and you want a 3rd party attested credential in exchange (a real passport).

I think the working group will need to stop using the word credential to describe data that looks exactly like a verifiable credential... because to the average reader this will always be confusing... the "verifiable credential application" concept has a lot of value and is worth exploring.

[iherman]

For the records: looking at the discussion at the meeting on 2023-03-14 I am fine closing this PR without merge.

[msporny]

For the records: looking at the discussion at the meeting on 2023-03-14 I am fine closing this PR without merge.

As I understand it, the group will try to focus on the definitions for credential and verifiable credential next. Once we get those down, we will update the rest of the spec to align with the new definitions. Once we do that, we might revisit RDF classes for Credential... or, we might decide that we don't need to do that.

Given the above, would anyone else on this thread object to closing this PR? I'm going to give this until the end of this week (COB Friday PT) before closing the PR.

[longpd]

No objections here - close the PR.

…

On Mar 15, 2023, at 12:29 PM, Manu Sporny ***@***.***> wrote: For the records: looking at the discussion at the meeting on 2023-03-14 <https://www.w3.org/2017/vc/WG/Meetings/Minutes/2023-03-14-vcwg-special#section2-6> I am fine closing this PR without merge. Would anyone else on this thread object to closing this PR? — Reply to this email directly, view it on GitHub <#1057 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AADYBFDQXAZSQ75HL4SY22LW4HU6NANCNFSM6AAAAAAVOYTKOA>. You are receiving this because you are subscribed to this thread.

[selfissued]

I also support closing this PR without merging it.

[msporny]

@msporny wrote:

Given the above, would anyone else on this thread object to closing this PR? I'm going to give this until the end of this week (COB Friday PT) before closing the PR.

Closing.