Does calling something "verifiable" indicate a proof somewhere of some kind associated with it

[mprorock]

PR #1055 has led to interesting discussion around some proposed language:

<p>
          When defining a media type for use with verifiable credentials — for instance, in a 
          specification that defines a specific syntax — use of the term `verifiable` implies
          the presence of a <a href="#proofs-signatures">proof</a> with the credential.  
          This also applies when the term is abbreviated, as in other specifications, 
          such as in the [[VC-JWT]] specification's use of `vc+ld+json`.
          Use of media types identified as `verifiable` in this way MUST correspond to
          the use of one or more proofs with the credential.
</p>

Let's discuss and hash our some language that works

[awoie]

I wouldn't agree with proof property. But I would agree with a proof in general. A proof allows a verifier to verify integrity, authorship etc.

[mprorock]

I wouldn't agree with proof property. But I would agree with a proof in general. A proof allows a verifier to verify integrity, authorship etc.

+1 that is my take as well, but we will need to identify some language that is suitable for that - In the text above i suggested a link to the to proof-signatures section since that lays out both embedded and external, but that apparently is causing some consternation. @OR13 any suggested text here?

[bumblefudge]

Would this work? I think Oliver is right that calling it proof could be confused for a reference to the proof property, but maybe just calling it a proof mechanism and clarifying that said mechanism is part of what you need to specify when you specify a media type would help?

<p> When defining a media type for use with verifiable credentials — for
instance, in a  specification that defines a specific syntax — use of the term
`verifiable` implies the presence of a per-credential <a href="#proofs-
signatures">proof mechanism</a> specific to that media type.   This also applies
when the term is abbreviated, as in other specifications,  such as in the [[VC-
JWT]] specification's use of `vc+ld+json`. Use of media types identified as
`verifiable` in this way MUST correspond to the use of one or more proofs with
the credential. </p>

[TallTed]

Does calling something "verifiable" indicate a proof somewhere of some kind associated with it?

No.

It indicates that there is a process by which the thing can be verified, which may or may not be successful.

This process might be a (broadly applicable to a class (a/k/a type) of verifiable things) "proof mechanism" which might require some sort of (per verifiable thing) "proof material", which seems to be the default we're aiming toward.

I do not think that we can or should say anything about what other specifications mean, unless they are sub-specs of this one.

[OR13]

We really need to update this section of the spec....

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

[awoie]

We really need to update this section of the spec....

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

If we change the section above, then we should also change the issuer section of the specification since proofs should be there to verify authorship but the issuer section currently doesn't say anything how it relates to proofs and vice versa.

[longpd]

use of the termverifiable implies the presence of a per-credential proof mechanism specific to that media type.

@TallTed Is the quoted description by @bumblefudge saying simply that a verifiable credential is a credential that has a process which evaluates a proof and if untampered with will verify? If there is no such proof mechanism we would call it simply 'a credential'?

[TallTed]

@longpd wrote —

@TallTed Is the quoted description by @bumblefudge saying simply that a verifiable credential is a credential that has a process which evaluates a proof and if untampered with will verify? If there is no such proof mechanism we would call it simply 'a credential'?

Roughly, yes.

There needs to be both such a mechanism, which might be identified by/within the credential or might be communicated out-of-band (for instance, in a scenario where the issuer only intends their credentials to be verified by a known set of verifiers, which might be preset or might grow over time as new presentees dereference the link to the method (if present) and follow such instructions as may be there...), and whatever crypto or other material is necessary to apply the mechanism, whether this crypto or other material is within or external to the (verifiable?) credential.

There are MANY valid usage scenarios which may evolve over time. Some will be strongly privacy protecting; others may be strongly privacy breaking. The choice to participate in any of these will need to be negotiated somehow among the issuer, holder, and verifier. Eventually (sooner is better), we'll probably need to spell out some way for holders (and/or subjects) to discover details about whatever VCs they're holding and/or described by. This discussion will get deep into the weeds, and I don't think we're ready for it quite yet, but it seems better to mention it now than to wait.

[iherman]

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

• no resolutions were taken

View the transcript

4.3. Does calling something "verifiable" indicate a proof somewhere of some kind associated with it (issue vc-data-model#1060)

See github issue vc-data-model#1060.

Brent Zundel: Does calling something verifiable imply a proof is associated with it?

Brenz: anyone want to be assigned to this issue?

Dave Longley: +1 to orie that we've hashed this out elsewhere and +1 to close.

Orie Steele: this seems to be a straggler left over from media type discussion. Calling something verifiable doesn't tell you anything about. vc+ld+json doesn't tell you if it does or does not contain a proof.

Manu Sporny: +1 to orie and dlongley.

Orie Steele: can't infer anything from vc+ld+json about presence or absence of a proof.

Brent Zundel: are issues open to address updating terminology - no objections to mark as pending close.

[TallTed]

See my previous comments on this issue... which I'll rehash and embellish a bit here, again.

"Verifiable" doesn't imply nor require anything about the presence or absence of a proof.

"Verifiable" just means that there exists a way to provide a proof which may then be proven.

It's a process/structure label; not a presence/lack label.

UID+PWD can be secure(ish) -- but it doesn't guarantee that strong username or password strings are used by users nor required by sysadmins! Yes, various restrictive enforcement tools can be brought to bear, requiring some number of characters, including some number of digits, alphas, symbols, etc., expiring after some period, etc. But as the endless series of UID/PWD files on the internet demonstrate, it's all but inevitable that some user is going to use PASSWORD or some derivation thereof.

application/vc+ld+json is a strong hint by the system or tool that assigned that media type to a resource, that any system or tool that consumes that resource should be able to find sufficient details in and around that resource to verify that its payload is as issued, and optimally the issuing entity.

[brentzundel]

Additional comments have not indicated a need for any action to be taken to address this Issue.
No objections raised to closing since being marked pending close.
Closing.