Define "prover" in addition to "holder".

[OR13]

Everyone with access to plaintext is a holder... so the term provides very little value.

In protocols, very often the issuer is the first holder, and then they present to a second holder who is often a subject.

This second holder will then present to a verifier.

• Issuers issue credentials.
• Provers present credentials using presentations.
• Verifiers verify presentations.
• Holders are anyone who sees a credential.

Holder lacks implied directionality, in practice it has been used to root the direction arrow between a subject and a verifier.

Holder: <-> Prover (sender): -> Verifier (receiver): <-

The lack of directionality in the term holder makes it a dangerous term for protocols to rely on, unless the protocol is really intending for no directionality to be implied... which is not the case with the term today, since its only defined in the context of Verifiable Presentations which has a directionality towards a verifier... from a holder.

[dlongley]

Presenter (instead of prover) may provide a wider scope to capture more use cases and better match with the fact that they are "presenting".

[agropper]

Requester (instead of holder or prover) is the entity that is making a request of a verifier. Verifications hardly ever stand alone. I the general case, the presentation of a credential is part of a request:

• Resource or processing action desired
• Purpose of the request
• Credentials associated with the request
• Payment or refundable deposit to compensate for the significant cost of policy evaluation and verification.

Obviously, interoperability at the level of requests is complicated and domain-specific. Formulating the request has domain-specific actions (resource, purpose, and most credentials) as well as generic actions (signing and payment). This complexity promotes platforms and centralization as the client sophistication and policy evaluation are "sponsored" through surveillance capitalism and platform network effects.

Even if requests are out of scope for this WG, using Requester will help other efforts.

On Sun, Aug 7, 2022 at 1:53 PM Dave Longley @.***> wrote:

Presenter (instead of prover) may provide a wider scope to capture more use cases and better match with the fact that they are "presenting".

— Reply to this email directly, view it on GitHub https://github.com/w3c/vc-data-model/issues/902#issuecomment-1207455974, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABB4YJSJMAAHTBQPIHPXV3VX7Z2XANCNFSM552WPUHA . You are receiving this because you are subscribed to this thread.Message ID: @.***>

[TallTed]

Prover suggests to me that they are playing a specific role in the cryptographic layers, which they are not in any of the scenarios discussed in this issue (including those in comments), so I think that label would cause more confusion than it may relieve.

Similarly, requester feels like it inverts the role typically being played by an entity offering a VC/VP for verification.

Presenter seems to be the least likely to cause more confusion than it resolves.

I think further discussion along these lines would be aided by reference to (and possibly generate valuable feedback on) the mermaid diagrams that have recently been of significant help in clarifying the VC API Use Case efforts (start here and scroll down a bit....).

[vongohren]

We have touched upon similar problems and ended up with owner. But I feel presenter might be a better option. We did use receiver internally, but verifier can be just as good

[agropper]

Owner is an interesting choice. It accurately reflects the reality that an owner can delete or take the VC off-line regardless of the subject or contents. It also matches the common use or Resource Owner in OAuth, GNAP, etc...

Presenter, Holder, and Requester are different from Owner in terms of delegation. It makes little sense to delegate ownership and leads to impersonation and lack of accountability as major security flaws.

As one who argues for freedom to delegate as a human right, I would suggest we avoid Owner.

On Tue, Aug 9, 2022 at 10:46 AM Snorre Lothar von Gohren Edwin < @.***> wrote:

We have touched upon similar problems and ended up with owner. But I feel presenter might be a better option. We did use receiver internally, but verifier can be just as good

— Reply to this email directly, view it on GitHub https://github.com/w3c/vc-data-model/issues/902#issuecomment-1209477326, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABB4YLM4LWDIW3X2UGU6A3VYJVLBANCNFSM552WPUHA . You are receiving this because you commented.Message ID: @.***>

[brentzundel]

If presenter is the party who submits a presentation to the verifier, what is the name of the party that receives a credential from an issuer? My understanding was that holder (as a role) was both the party who receives the credential from an issuer and presents a proof to a verifier.

The most recent spec defines it this way:

A role an entity might perform by possessing one or more verifiable credentials and generating presentations from them. A holder is usually, but not always, a subject of the verifiable credentials they are holding. Holders store their credentials in credential repositories.

[OR13]

A - (verifiable presentation) -> B

prover / presenter / from: The party A, such that A presents to B using a verifiable presentation. verifier / receiver / recipient / to: The party B, such that B verifies a verifiable presentation from A. holder (of the bag): an ambiguous term that applies to both presenters and receivers, and conveys no directionality

There is also a need to related "holder to aud" and "verifier to aud".

Does the holder really know who (specific id) they are presenting to ?... or are they presenting to an unbounded group? (the set of all servers that process "aud" bound presentations from that holder).

domain ~= aud challenge ~= nonce

for the folks who have not yet become frustrated enough with our refusal to layer the data model and its security representations properly.

[jandrieu]

I'd like to suggest that we split "Holder" into "Recipient" and "Presenter", with the explicit understanding that it is generally assumed that these three are all the same person.

[OR13]

For the record:

PROPOSAL: define holder (undirected), receive / present (directed actions) .... receiver, presenter (directed).

[iherman]

The issue was discussed in a meeting on 2022-09-07

• no resolutions were taken

View the transcript

#### 2.3. Define "prover" in addition to "holder". (issue vc-data-model#902) _See github issue [vc-data-model#902](https://github.com/w3c/vc-data-model/issues/902)._ **Orie Steele:** We created the spec to have a term for presenting. … It's important to acknowledge the different roles for being a holder. … It's dangerous to have terms in VPs that are undirected. The holder label is undirected. … It would be better for the entity making the presentation to be able to assert that "I am presenting or I am receiving". … We want directed intentionality in the data model. … That's why we need additional terms related to the holder role. **Kristina Yasuda:** There's a suggestion to use presenter. **Joe Andrieu:** It makes sense to add both recipient and presenter for what we're currently calling holder. > *Manu Sporny:* +1 to defining the roles in a directional manner. **Joe Andrieu:** That's an iteration on this conversation. **Kristina Yasuda:** There is a consensus to have two terms. **Manu Sporny:** Are we talking about getting rid of holder or saying that holders have two things that they can do. > *Orie Steele:* +1 to the latter formulation manu. **Manu Sporny:** I wondering if issuers can receive and present as well. … It's a question we have to answer for each of the current roles we have. **Joe Andrieu:** We would benefit from keeping holder and clarifying it. > *Brent Zundel:* +1 Joe. **Joe Andrieu:** The issuer/holder/verifier is a very powerful group of terms. … We should elaborate on them. > *Joe Andrieu:* +1 to chat at TPAC. **Kristina Yasuda:** This is the first time we're talking about this issue. … Let's give people time to think about it.

[agropper]

The role of holder is the same as requester. An entity requests a VC from an issuer and may provide scope as well as authentication as part of the request. (Another) entity requests authorization from a verifier and may provide scope and purpose as well as authentication as part of the request. Unlike holder, requester is always a directed term.

[jandrieu]

So, now you do want to bikeshed?

[agropper]

It's not bike shedding to consider a directed request-based model vs. the current discussion of undirected and directed.

[logpo]

Splitting the holder definition in two will create more confusion IMO. The holder holds the credential and the means to present that credential to a verify. So they receive credentials from issuers, but they have a private key which is what separates them from anyone else who has the plaintext credential. I agree that the term isn't perfect but I'm not sure splitting the role in two fixes that.

[brentzundel]

I agree with @logpo about not wanting to split the holder role, but do feel it would be helpful to better describe the actions a holder takes when they are involved with an Issuer vs a Verifier.

[David-Chadwick]

This problem of describing the actions is compounded when subject NE holder. Describing the holder's relationship with the issuer (and subject) in this case is complex due to the different relationships there may be, and the holder may have to proove possession to the Verifier when the VC is not a bearer VC. When subject EQ holder we have the public key in the VC to prove the relationship/possession. If we mirrored this for issuing VCs to holders (NE subject) it would simplify these relationships, because the VC would contain the holder's public key and then PoP to the verifier becomes straightforward. Of course it does not deal with the subject EQ holder passing their VC to another holder (NE subject). But that is a second order issue.

[decentralgabe]

I'd like to re-define holder as one who has the cryptographic ability to prove control of a credential using a cryptographic identifier or key defined by the issuer of the credential.

[OR13]

I'd like to deprecate holder, and NOT define it normatively, instead, I would like to define only terms that have some security characteristic associated with the securing format (vp-jwt, vp-data-integrity).

Unsigned "verifiable" presentations are the only use case for the existing holder term imo.

[agropper]

There are significant human rights associations with the holder term because of the temptation to use a biometric wallet or, more literally, an ankle bracelet.

"Client credentials" is a constant challenge. To the extent that holder is a client, the relationship of the client to the human that is operating the client must be explicit in our normative statements. The risk of being expected, if not forced, to carry or use a certified client is an obvious human rights problem.

[TallTed]

The holder holds the VC. They need not be identified anywhere in the VC (though they might be). There is no global need to tie VCs to their holders, though it may be useful in some cases. Likewise, there is no global danger for holders of VCs, nor even subjects, who may not ever know they were the subject of a given VC.

I am growing increasingly weary of saying the same thing again and again, of having to defend against universals that aren't universal, certainly technologically and generally otherwise.

Please remember, we are working on the technological aspects. Concerns that amount to "government logic", akin to business logic, are pretty far outside of our scope, unless a specific harm can be identified and defined and demonstrated to be inherent to the tech, which will enable us to construct a defense against that harm, at least to the extent that we agree about its significance.

[RieksJ]

One of the above comments nicely distinguished between parties and roles. A party, whereas a role can be seen as a particular way in which it can perform. It's like a play where actors fulfill roles, which is easily transferrable to the real world (I can act in a role as 'father', 'TNO employee', etc.). The VC-image of issuer-holder-verifier is a bit misleading in the sense that many seem to interpret these roles as if they were the party itself - as little children do when they see Santa (for the Americans) or Sinterklaas (for the Dutch).

Having said this, we just need to identify the various 'parts' of the play, e.g. 'issuing', 'requesting/receiving' - whatever we choose/need to have, then properly describe these 'parts' and define a name by which we can refer to parties that will perform this part/assume this role. It doesn't really matter what the role-name is, as long as it is properly defined. But of course, it helps if these names trigger the right 'hallucinations' with readers.

[OR13]

A related issue discussed on the traceability call today:

• https://github.com/w3c-ccg/traceability-vocab/issues/521

[awoie]

I also found the term holder a bit vague. We could try to run a non-binding poll on this and ask folks how they feel about introducing a new role presenter (I also feel that prover is too narrow in scope since it is not always about verification of cryptographic proofs).

• Issuer issues VCs
• Verifier verifies VPs/VCs
• Presenter presents VPs/VCs

I'm ok with keeping the term Holder in the VCDM as non-normative text if people think this might help with establishing some reader context but if we agree on presenter, then we should probably make presenter a normative property in the VP.

[awoie]

Also note that holder has never been normatively defined in VCDM 1.1.

[OR13]

It's amazing how many critical issues there are for us to work on.

My guess is that "holder binding" would be far less contentious if we could define what a holder is first.

My sense is that "holder binding" might more accurately be titled "presenter binding".

[TallTed]

I continue to believe that "binding" is the wrong word for this association, this desired restriction (which might be the right word for it).

[OR13]

Great point about the word binding, it makes you wonder if we are trying to relate "holder binding" to "token binding" or if that relationship is not what we are hoping to accomplish:

https://www.w3.org/TR/webauthn-2/#dom-collectedclientdata-tokenbinding

[dlongley]

@OR13,

I think the "holding binding" issue(s) and related conversations started from the idea of creating a dependency of sorts on a proof of possession, but it's grown to encompass more than just that idea. Besides, that idea had some initial flaws when called "binding" that people mentioned early on as well.

I agree with @TallTed that we need a better word than "binding" -- but I'm hoping at this point that we don't try to bikeshed it but rather let something new come out of further discussion. I think there are a number of different use cases people are interested in that all fall under the umbrella of "holder binding". Some examples that come to mind:

1. Having an issuer say that they intended a particular entity to be the presenter of a VC (but in the absence of why that matters?).
2. Having an issuer say that verifiers could examine certain evidence or compare it against the presenter of a VC (perhaps running checks X, Y, Z against them) to see if they are the intended subject of the VC / some other identified and intended party.
3. Having the issuer say that they believe a particular party should be given some privilege and perhaps suggest how to authenticate that party. Note that maybe it doesn't actually matter who presents the VC unless the act of presenting itself involves sufficient authentication of said party. (There's also some tension here between what the verifier might accept as valid authentication and what the issuer might prefer or suggest they accept).

[agropper]

This ongoing discussion has not converged for as many years as I've been around. If anything, it seems to be getting fuzzier even as ACDC and other options come on the scene. The challenge from ISO mDL and OWF is also adding to the fuzz.

I think some of this is due to not treating biometrics as primary components of VCs. To help advance our discussion, I posted a slightly tongue-in-cheek perspective on digital human identifiers to CCG today. https://lists.w3.org/Archives/Public/public-credentials/2022Nov/0195.html

It's not proposing a solution, but hoping people take the question seriously and factor it into the VC 2 design.

Adrian

On Wed, Nov 30, 2022 at 5:54 PM Dave Longley @.***> wrote:

@OR13 https://github.com/OR13,

I think the "holding binding" issue(s) and related conversations started from the idea of creating a dependency of sorts on a proof of possession, but it's grown to encompass more than just that idea. Besides, that idea had some initial flaws when called "binding" that people mentioned early on as well.

I agree with @TallTed https://github.com/TallTed that we need a better word than "binding" -- but I'm hoping at this point that we don't try to bikeshed it but rather let something new come out of further discussion. I think there are a number of different use cases people are interested in that all fall under the umbrella of "holder binding". Some examples that come to mind:

1. Having an issuer say that they intended a particular entity to be the presenter of a VC (but in the absence of why that matters?).
2. Having an issuer say that verifiers could examine certain evidence or compare it against the presenter of a VC (perhaps running checks X, Y, Z against them) to see if they are the intended subject of the VC / some other identified and intended party.
3. Having the issuer say that they believe a particular party should be given some privilege and perhaps suggest how to authenticate that party. Note that maybe it doesn't actually matter who presents the VC unless the act of presenting involves sufficient authentication of said party. (There's also some tension here between what the verifier might accept as valid authentication and what the issuer might prefer or suggest they accept).

— Reply to this email directly, view it on GitHub https://github.com/w3c/vc-data-model/issues/902#issuecomment-1332838780, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABB4YKZCXIYCJZTLM4FSI3WK7LJPANCNFSM552WPUHA . You are receiving this because you commented.Message ID: @.***>

[andrewhughes3000]

At ISO SC17 WG4 For 23220-4 we are discussing the same thing. We are trying to determine whether there is value in distinguishing between the human entity whom the issuer identifies before issuance, the main subject of a credential, the entity receiving a credential directly from the issuer, the authorized user of a wallet, a human guardian of the subject, a delegated person, an entity authorized to assemble a presentation, an entity authorized to present a presentation, a prover. I might have missed some. We are going down the path of having the issuer endorse a "means to authenticate" which, when a verifier wants confirmation that the entity presenting a credential is authorized to do so, can be invoked by the which then releases a signal to the verifier that it is indeed the case. Needless to say we have a long debate ahead of us - and we have the benefit of needing to involve the issuer in the mix instead of having no guardrails.

[TallTed]

the benefit of needing to involve the issuer in the mix

That's what's known as "phoning home," which has significant privacy implications.

[andrewhughes3000]

Nope - that's not what I'm referring to. I mean that we are looking at how the issuer could pre-approve the means to confirm the "means to authenticate". So that it's not completely up to the wallet to decide how to do it. It constrains the range of options we must consider. You have to believe me when I continue to say that almost all "mDL People" dislike the "phone home" server retrieval modes. And believe it or not, all of us are very concerned about building privacy-preserving capabilities into the protocols.

[RieksJ]

@OR13 said

My guess is that "holder binding" would be far less contentious if we could define what a holder is first.

My sense is that "holder binding" might more accurately be titled "presenter binding".

My guess is that we could resolve all this by reverting to some basics.

1. First understand the generic problem, then come up with solutions, next choose which (not) to standardize. I haven't seen this so far. I have seen lots of hand-waving, lots of examples that are specific occurrences of some presumed generic problem, but no clear, simple description of the generic problem that we're trying to solve, and which of the roles (issuer/holder/verifier/presenter/...) actually suffers from that problem.

2. The semantics of every identifier that an issuer uses to identify the subject of a claim MUST be controlled by the issuer of (the credential that contains) that claim. By 'identifier semantics', I mean the mapping between the identifier and the entity that this identifier refers to. In other words, issuers MUST be the authority for dereferencing any subject identifier in a claim they author. If they do not, then they may sign a claim stating e.g., that did:ex:alice has earned some degree assuming that did:ex:alice refers to Alice, but as they do not control the semantics of did:ex:alice, this identifier may at some later point in time point to Bob, and a verifier may incorrectly assume that Bob has earned that degree (and perhaps sue the issuer for malpractice).

3. Since the issuer MUST be the authority that controls the identifier semantics of every identifier in a VC, it is also the party that MUST authoritatively determine which mechanisms (if any) other parties - specifically: verifiers - can use to learn what entity that identifier refers to. This then also holds for all subject identifiers in the claims of a VC. My sense is that issuers could add such mechanisms as part of the claims, e.g., as suggested by #760, which holders could selectively disclose to verifiers as they see fit.

My sense is that verifiers (or others) do not need to find out whether or not the holder/presenter/... is the subject of a claim, but rather that (the generic problem is that) they need to do the converse, i.e, establish which party (or other entity) is being referred to by a subject identifier. I propose that #760 has one of the solutions, and I would like to see others so we can then choose what to (not) standardize.

[David-Chadwick]

I would rename 1. as "First define the roles in the system" There are 4 roles involved, not 3 as Orie suggested. The obvious one that he has missed is the issuee role. Issuer issues VCs Issuee receives these VCs Verifier verifies VPs/VCs Presenter presents VPs/VCs

You will note that the holder role never appears in any of these 4 roles , because it is a role that is not visible outside of the wallet. i.e. whenever the wallet receives or transfers a VC or VP, it is acting in one of the above 4 roles, and is never acting as a holder. So we need to downplay or even remove the role of holder.

2. is interesting, but not sufficient. I would say that the Issuer needs to identify every role that is pertinent to the VC that it is issuing. So, an issuer could if it wishes, identify the verifier that a particular VC should be given to.

[RieksJ]

@David-Chadwick I disagree that 1. should be renamed. I can see that you need to define some roles (and perhaps some other terminology) in order to state the generic problem but skipping the formulation of the generic problem is a no-go for me.

[bumblefudge]

Big thanks to @andrewhughes3000 for lending a nuanced vocabulary!

Abbreviation	Andrew's description
A	the human entity whom the issuer identifies before issuance
B	the main subject of a credential
C	the entity receiving a credential directly from the issuer
D	the authorized user of a wallet
E	a human guardian of the subject
F	a delegated person
G	an entity authorized to assemble a presentation
H	an entity authorized to present a presentation
I	a prover

Just for the sake of spitballing, all the following statements feel reasonable to me:

1. A and B are assumed coequal by today's spec or at least my mental model of it (except dropping the word "human")
2. A == B == C == D in a lot of use cases and there may be little consensus or interest in discussing those use-cases where this is not the case! The Verite credentials we've been modeling, for instance, would be considered illegal (i.e. invalidated extra-technically, warranty voided, etc) if not, or if D were a superset of A/B/C. If anything, some implementations (in cryptocurrency-land, for example) might even include additional VCs or authZ tokens or receipts in a presentation to prove or enforce that A == B == C == D, such as a ticket from or token for or receipt of a liveness/biometric/etc authN process.
3. E and/or F and/or G would somehow need to be constrained at time of issuance for a "presenter-constraint"/"holder-binding"/etc algorithm to make sense.
4. G<>H<>I feel to me like distinct functions of the mechanics of presentation that might be done by different instances/tenants/etc in large-scale prod (in the same sense that VC API slices up roles into functions). It might make sense for constraints on delegation or distributed proofing functions to get this granular in some cases, and not to do so in others. Implementation detail? Here again I can imagine additional artefacts being thrown into a VP for the express purpose of proving any linkage between G<>H<>I to the satisfaction of the VC's constraints and/or the Verifier's requirements.

Feel free to disagree or ignore, I just found it helpful to type out my thoughts.

[David-Chadwick]

@RieksJ The generic problem from my perspective is this. How can we replace the dozens of plastic cards, paper-based and other physical credentials that we carry around with us and/or continually have to show to others, with the electronic equivalent of them. Do you agree?

[David-Chadwick]

@bumblefudge A == B == C == D will cater for the vast majority of use cases (most probably >>90%). It's the other minority of use cases that present the most complex problems to be solved and will take >>90% of our effort.

[bumblefudge]

@bumblefudge A == B == C == D will cater for the vast majority of use cases (most probably >>90%). It's the other minority of use cases that present the most complex problems to be solved and will take >>90% of our effort.

Well if that sentiment has consensus we can narrow in on a much more manageable scope for the E-thru-I constraints and proofs, at least for the purposes of this issue 😅

[TallTed]

[@andrewhughes3000] You have to believe me when I continue to say that almost all "mDL People" dislike the "phone home" server retrieval modes. And believe it or not, all of us are very concerned about building privacy-preserving capabilities into the protocols.

That's great. Your previous comment about needing to involve the issuer in the [verification] mix suggested (and suggests) otherwise. Your later statement that the issuer could pre-approve the means to confirm the "means to authenticate" does help to ease the "phone home" concern somewhat — but I hope you agree that these statements are very different, and can see why I was concerned by the earlier one.

We need to take great care in these discussions, to express exactly what we mean in a manner that is least likely to be misunderstood. This may make many comments far more verbose, but that clarity is vital if we're to reach anything approaching consensus across the various related projects, nations, and organizations involved.

[TallTed]

[@David-Chadwick] A == B == C == D will cater for the vast majority of use cases (most probably >>90%)

What tools have you used, and how broad a population did you survey, to arrive at this 90% assertion?

If, as I suspect, you simply plucked it from the air, please stop asserting it. Such evidence-free assertions do no-one any favors.

[TallTed]

Also, everyone, please note that a system designed to handle situations where each and every role (however many that may be) is filled by a different entity (e.g., A != B != C != D) may easily be used for situations where any number of those roles are filled by a single entity (e.g., A == B == C == D), but the opposite is not true.

Thus, given that we know of situations where each and every role is filled by a different entity, we SHOULD develop a solution which serves for this situation. Failing that, we MUST develop a solution which can be adapted to serve this situation in the future, without breaking any deployments that may exist at that time.

[RieksJ]

@OR13 wrote

My guess is that "holder binding" would be far less contentious if we could define what a holder is first.

VCDM defines the term, so that is NOT the problem. I do see some others.

1. terms that have a definition are not used in the meaning as defined, which causes misinterpretations and lots of needless disputes about these terms that do not get resolved (which I conclude from the fact that they keep popping up). (AnonCreds seem to do this differently, see e.g., their issue on ambiguous use of their term holder)

2. terms are introduced of which their meaning is assumed to be self-evident - i.e.: without providing a definition that actually allows others (e.g., non-native english speakers) to determine what is, and what is not an instance (example) of the term. Although the cause is different (the definition lacks), the effect is very similar, as terms are used without a proper reference to their meaning.

3. ignoring the fact that terms have a scope/context in which they have a particular meaning gives rise to misunderstandings. For example, in the context of the Dutch government, the holder (of an identity document) is defined as "the person in whose name the travel document is issued and for whom it has been issued". In VCDM terminology, that person would be referred to as the subject (of the identity document), and the holder would be the entity that possesses it and can present it, which could be, but is not necessarily its subject.

Assuming that all issues in this repo should be relevant for (the context of) VCDM, I propose that we make a real effort to use the terms that are defined ONLY in the meaning as defined in the VCDM. If additional terms are needed (or changes in existing ones), a proposal to do so should be raised in which a definition is suggested that allows people that work in the VCDM context to agree on what does, and what does not, constitute an instance/example of that term. I'm curious to see how this would affect the discussion on 'holder binding'...

[RieksJ]

@David-Chadwick

@RieksJ The generic problem from my perspective is this. How can we replace the dozens of plastic cards, paper-based and other physical credentials that we carry around with us and/or continually have to show to others, with the electronic equivalent of them. Do you agree?

Yes and No. Yes, because I cannot argue what your perspective is or isn't. No, because we should not replace all that, because many people wouldn't be able to actually use wallets. It should be an alternative that people can use.

But mainly 'No' because what I'm really looking for is a convincing and understandable argument for proposing the term "prover" (in addition to "holder") that I as a (non-code writing) member of VCC can at least understand. I have no clue what phrases such as stuff like "(implied) directionality", or "the direction arrow" refer to (they are not in the VCDM). I cannot make any sense of sentences such as "Holder lacks implied directionality, in practice it has been used to root the direction arrow between a subject and a verifier" and "The lack of directionality in the term holder makes it a dangerous term for protocols to rely on", as @OR13 wrote in the initial post. So how could I contribute?

If the problem is only an implementation issue, there is no need to introduce the term "prover" in the VCDM. If the problem is generic, i.e., relevant in the context of VCDM, I think I should be enabled to understand the problem that @OR13 attempts to address in this issue.

[bumblefudge]

Note: there seem to be, at least according to one implementer, some VC use cases where A == B == C == D == a DAO and the use case where A == B == C but D is a superset of that. They just linked to a CCG spec and sample implementation in another thread

[OR13]

Not clear what the action is here, seems blocked by holder binding debate.

[RieksJ]

The original issue by @OR13 is a terminology issue that says: he guys, the the term 'holder' is about a single role that is related to two different activities. First, it is a role that "an entity might perform by possessing one or more verifiable credentials". Second, it is a role that "an entity might perform by [...] generating presentations from them". Since these activities are distinct, it makes sense to make these roles distinct as well, and have different names for them.

Concrete action: change the VCDM spec as follows:

• split the currently defined holder role into two parts, the first one being the "possessing one or more verifiable credentials" and the other one being "generating presentations from them", and choose names for them (e.g. "holder", and "presenter").
• go through the VCDM text and replace the occurrences of 'holder' with 'presenter' wherever that is appropriate.

[Edited to add] in addition, one might ponder about the necessity to define a third role, possibly called 'issuee', as the entity "requesting/obtaining one or more verifiable credentials from an [issuer](verifiable credentials".

I would suggest to also add some text that clarifies the term 'role', inspiration for which is here and there.

[iherman]

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

• no resolutions were taken

View the transcript

#### 4.2. Define "prover" in addition to "holder". (issue vc-data-model#902) _See github issue [vc-data-model#902](https://github.com/w3c/vc-data-model/issues/902)._ **Brent Zundel:** define prover in addition to holder. What to folks think?. … not sure if we are at a point of agreement on next steps. **Orie Steele:** issue describes itself. Main problem is association with holder binding. … become inactionable due to this. … original intention was to describe that holder undirected. Might want to make it clear the direction. … suggest entire data model blocked by holder binding conversation. … don't have def with requirements at presentation layer that is useful. … hopefully untangle at f2f. **Manu Sporny:** orie took shot at high level definitions, longley added some suggestions. Sparked massive discussions. … could be that we don't need yet another role or term in ecosystem. **David Chadwick:** I think we need two new terms. Get rid of holder all together. … two new terms issuee and presenter/prover. … those roles never change. … holder always changes because vcs passed between holders. > *Juan Caballero:* +1. **David Chadwick:** holder does not participate in anything particularly. > *Phillip Long:* +1 to David C's statement about holders as indeterminate, not having a defined actionable role.. > *Juan Caballero:* good point phil-- yes, +1 to that :D. **Brent Zundel:** thanks for convo. moving on.

[mwherman2000]

Since these activities are distinct, it makes sense to make these roles distinct as well, and have different names for them.

@RieksJ Here's another approach: https://youtu.be/uo4RuT__IXw?t=575s

You may need to watch the following as background: https://youtu.be/uo4RuT__IXw?t=401s

[Sakurann]

having read the thread, I would suggest proceed as following:

• first discuss whether to break down what is currently one entity "holder" into multiple entities
• if yes, what would be the break down? suggestions seem to be three entities: an entity that receives, an entity that holds, and an entity that presents a VC. what are the terms/definitions for the new terms/
• if no, is there a need to normatively define "holder"