Comments (18)
An object may be "verifiable" without actually having a proof; it is the container (internal or external to the object) for the proof that matters. Verification requires that there be a proof in that container. Successful verification requires that the proof be proven. Failed verification is still an application of verifiability!
from vc-data-model.
Data Integrity proofs are in the v2 context, and in all the examples, I think your assessment is not accurate... the current spec has defects in both directions of the argument.
from vc-data-model.
There is clearly a difference between an object with a proof, meaning that it is verifiable, and an object without a proof, meaning that it is not verifiable. Since we have both of these objects in our specifications then we should be clear which term we apply to each of these objects. We cannot use the same term to apply to two objects because this introduces ambiguity.
I thought we already had an agreement that the object without the proof was to be termed "credential" and the object with the proof was to be termed "verifiableCredential"?
from vc-data-model.
You can subclass in Linked Data, so it's possible to have Credential as a parent class, and VerifiableCredential as a subclass, and by inference also a Credential.
from vc-data-model.
I look forward to the proof text being updated and then the confusion/mis-understanding between the (non)difference between the two terms will be removed
from vc-data-model.
See #1057
from vc-data-model.
This means, we should remove "Credential" entirely from the VCDM? IMO, it is confusing to have both in the VCDM, especially since the securing mechanisms are no longer part of the VCDM.
from vc-data-model.
@OR13 I fully agree we should fix that.
from vc-data-model.
I agree with ted.
I think we are making a mistake in the current spec, referring to credential and verifiable credentials separately...
Both can have proof and neither might verify, they are not useful terms for distinguishing attributes of the data model, since they support the exact same properties.
We should avoid "credential" and focus on "claims" and "verifiable credential", or we should drop the word "verifiable" from everything but the spec title, and just have claims and credentials...
I was rereading WebAuthN yesterday, and I think we have missed a huge opportunity to align better with it, due to our terminology coming from RDF instead of security vocabulary.
The minimal VerifiablePresentation is just a proof from an authenticator (signature from a credential).
The difference is web authn credentials are bound to a single RP (2 party model) and VCDM is not like that, and has more serious privacy issues because of this.
Our concept of "holder binding / confidence method" is their concept of allowedCredentials but scoped again to only authentication.
If WebAuthN didn't need the word verifiable to be successful, maybe we don't either.
from vc-data-model.
we should drop the word "verifiable" from everything but the spec title
What are the implications of dropping it from the spec title as well?
If the working group has agreed that anything can be verifiable, then there isn't much value in using that as a qualifier.
from vc-data-model.
For those less familiar with the history, we started with "Identity Credentials" back in ~2015, with the best representation of that spec I can find here via this capture from web.archive.org
(the date in the HTML auto-renders to today when I accessed it now):
Another revision with some other details:
https://www.w3.org/2017/05/vc-data-model/CGFR/2017-05-01/#expressing-identity-credentials-in-json-ld
Including as an extension to the Credential Management API (with a goal of close alignment):
https://web.archive.org/web/20190709115731/http://opencreds.org/specs/source/identity-credentials/#extension-to-credential-management-api
This naming was originally considered the most natural fit -- but the term "Identity Credentials" or using "Credential" alone came to be seen as problematic by some people from various communities for a variety of reasons. I'm sure someone could hunt down discussions from history on that as well. There was also some work in there for integrating with OpenId and Google's Macaroons at various points. Some people in the Open ID and browser communities did not want "Identity Credentials" to be used with things like the credential management API, but the landscape there has shifted.
The way we resolved all of those issues was to change the terminology to "Verifiable Credentials". Here we are today -- full circle. I'm loathe to go through that long process again :).
from vc-data-model.
@OR13 said Both can have proof
. This is clearly where there is a semantic disconnect in the group which needs to be resolved. One view is that a credential is the VCDM data object without a proof (external or internal) and that a verifiable credential is a credential with a proof. @OR13 's view appears to be that both objects are identical. If the latter is true we do not need two terms as this is confusing. If the former is true, then we do.
To the chairs. Can we resolve this with a vote please?
Note. Whether the proof is verifiable or not is irrelevant to the discussion of what data object(s) the terms refer to.
from vc-data-model.
@David-Chadwick we voted on this already...
It is the RDF data model that makes the word credential meaningless and indistinguishable from "VerifiableCredential".
I didn't agree with the decision, or the data modeling design choices, but I don't think it should be reopened.
The section of the spec that defines proof is wrong, and needs to be updated. There is no meaningful difference between credential and verifiable credential... It will continue to confuse people.
I suggest @msporny or @dlongley open the PR to fix this, since they seem to understand the data model and both objected to the working group defining credential in RDF in way that would distinguish it from VerifiableCredential.
from vc-data-model.
I also look forward to seeing this addressed
from vc-data-model.
Is this a duplicate of #1009?
from vc-data-model.
The issue was discussed in a meeting on 2023-07-12
- no resolutions were taken
View the transcript
5.5. Address "Credential" vs "VerifiableCredential" (issue vc-data-model#1126)
See github issue vc-data-model#1126.
Brent Zundel: address credential vs verifiable credential.
… we tried to address this, not sure what is left.
Manu Sporny: this is before CR.
… I can be the backstop on it.
… we have... 702 statements of the word credential "446" for verifiable credential.
… editors will need to address "credential vs verifiable credential".
… there are some issues remaining...
… we need to adjust the language of the spec, but its a lot of work.
Brent Zundel: thanks, I will try to help.
from vc-data-model.
I have opened PR #1211 in an attempt to address this issue. Once #1211 is merged, we will close this issue.
from vc-data-model.
PR #1211 has been merged, closing.
from vc-data-model.
Related Issues (20)
- JSON-only processors and VCDM 2.0 conformance HOT 29
- Multiple Credential Status Lists HOT 2
- Prefer Arrays and Objects. HOT 5
- Clarify evidence section to point to OBv3 evidence property usage
- address normative statements in non-normative sections HOT 1
- Clarify what conformance means to the issuers/verifiers HOT 1
- add explicit notes where terminology in the spec diverges from things elsewhere
- Remove the at risk issue marker for `Evidence` HOT 5
- (Editorial) Use a three level deep TOC in the VCDM spec
- Controller Documents HOT 4
- Include credentialSubject examples that use URLs rather than DIDs
- Make Section 4.1 non-normative HOT 1
- Section 3 "Core Data Model" clean up
- clarify relationship to the `proof` property and the specifications defining how to secure VCs HOT 2
- Use a better example for bidirectional text (Editorial) HOT 4
- Default context contains terms outside of the spec HOT 9
- Consider abandoning drafts for non-data-integrity-proof securing formats HOT 13
- Update 4.9 Securing Verifiable Credentials HOT 7
- Updating figures 6 and 7 HOT 4
- Cross-check the `domain`/`range` statements in the vocabulary with the VCDM spec HOT 10
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from vc-data-model.