Clarification needed on the ease of deducing that a subject is the holder.

[RieksJ]

Section C.1 of the VCDM says: "The most common relationship is when a subject is the holder. In this case, a verifier can easily deduce that a subject is the holder if the verifiable presentation is digitally signed by the holder and all contained verifiable credentials are about a subject that can be identified to be the same as the holder."

The fact that VC's (as such) are not about a subject (claims in VCs are) is already being discussed in w3c/vc-imp-guide#70, so no need to do that here as well.

The last sentence states "it is easy to deduce that a subject is the holder if [...] a subject [...] can be identified to be the same as the holder." While that is obviously true (an inference of the form X --> X is always true), I do not see how this would imply that a subject can be identified to be the same as the holder. I would like to see some clarification of how this would then be easy.

Note that using the nonTransferable property doesn't help here, because there is no general way by which a verifier can determine whether or not a VP proof/signature was made by the subject of (supposedly the only claim in) the credential (see #960). That is because the subject identifier can be any identifier - it need not be a DID, public key or similar.

[TallTed]

fwiw, I also take issue with the first sentence of the quoted segment. I believe that the assertion that "The most common relationship is when a subject is the holder" is entirely baseless (beyond the belief of the writer), and should be changed to at least start with "A common relationship..." instead of "The most common relationship...".

[dlongley]

I think saying that such a relationship is "common" or "most common" is unnecessary (and would be missing a citation and could change over time). It would be better to say "One supported relationship" or "One possible relationship" instead -- and just keep it within the domain of what the spec / tech supports instead.

[David-Chadwick]

If we introduce the role of issuee, which is a genuine role that currently exists in the eco-system but is not described in the VCDM (but it is in ACDC) then we can remove the concept of tying the credential subject to the holder as the holder can change, whereas the issuee can never change.

[TallTed]

I'm not fully convinced about issuee. I'm wondering whether the role of VC issuee is basically the same as VP presentee, and if so, whether these should be defined and named the same.

If WG decides to make these one role, I'd suggest the role and the associated property be VC/VP receiver

If WG decides to keep these distinct as now, I'd suggest the associated properties to be VC issuedTo and VP presentedTo as these will be harder to misread as VC issuer and VP presenter than VC issuee and VP presentee.

[David-Chadwick]

I'm not fully convinced about issuee. I'm wondering whether the role of VC issuee is basically the same as VP presentee, and if so, whether these should be defined and named the same.

I think they are entirely different. The issuee is the entity the issuer is communicating with. The presentee is the entity the holder is communicating with. Note these are roles that entities take, and entities may take on different roles at different times

[David-Chadwick]

I can agree that issuedTo is clearer than issuee. But in the same vane, the property of issuer would then become issuedBy

[jandrieu]

I'm sorry, I think this is still trying to solve the problem at the wrong layer.

A statement is a statement, regardless of the initial recipient. The veracity of the utterance and the issuer's willingness to stand by that utterance have nothing to do with the initial or intended recipient.

IssuedTo is a non-starter. If you want to issue it to the subject, then do so. If not, don't. But adding a property to a statement about the intended audience moves us into DRM and censorship territory. There's no way we should be embracing arbitrary restrictions on information flow.

The common way to provide evidence that the current presenter/holder is the subject is to use a cryptographic identifier as the subject. That allows the creator of the VP to use the same cryptographic identifier as the subject to demonstrate they are the same party.

If you don't use a cryptographic identifier, then there is no way in the VC framework to verify the subject. As one should expect.

[David-Chadwick]

@jandrieu Good point. So the issuee/issuedTo claim should be part of the proof (external or internal).

[jandrieu]

How would the issuee change the proof in a VC?

A statement is a statement regardless of the initial recipient.

Although, if you mean in the proof of a VC, that is essentially where identity binding happens today. Unfortunately, it is restricted to a limited notion of when VP creator == VC subject.

What we should probably be doing is enabling the presenter to assert their relationship to any entities in any of the VCs in a VP. This is covered by a number of other issues, including #860 and #882

[David-Chadwick]

How would the issuee change the proof in a VC?

It would not. The issuer issues the VC to the issuee and places the id of the issuee in the LD proof section or as a JWT claim.

Clearly we have it wrong by thinking that the VC subject is either the holder of the issuee. It may be neither. e.g. dog=subject and dog owner=issuee.

So the subject/holder binding is the wrong paradigm. It should be issuee/holder binding at presentation time.

[RieksJ]

@jandrieu wrote:

The common way to provide evidence that the current presenter/holder is the subject is to use a cryptographic identifier as the subject. That allows the creator of the VP to use the same cryptographic identifier as the subject to demonstrate they are the same party.

The issuer must be the authority regarding the semantics of the entire claim, including of the subject identifier (in other words: the issuer gets to decide to which subject the subject identifier refers), because if this is not the case, the issuer cannot vouch for the correctness/truth of such a claim.

The idea behind cryptographic identifiers (e.g., DIDs) is that their semantics (i.e.: the entity that such an identifier refers to) is specified by the party that controls the identifier, i.e. that can show it can access the associated private key material. Often though, people even seem to expect it to actually refer to the party that controls the identifier.

Now, let's assume that a cryptographic identifier refers to the party that controls it. Then, suppose an issuer would first make sure Alice controls some cryptographic identifier CI, and then use it as a subject identifier in the claim (CI, has diploma, X), thereby asserting that Alice has diploma X, and issuing it as a credential to Alice. Then, when Alice transfers control of CI to Mallory, the credential suddenly means "Mallory has diploma X". Or at least, that is what Mallory (as the creator of a VP in which the credential appears) is allowed to do to demonstrate he is the subject.

The fundamental mistake here is to confuse the authority of determining the semantics of the subject identifier with controlling the subject identifier.

[jandrieu]

@RieksJ

The issuer must be the authority regarding the semantics of the entire claim, including of the subject identifier (in other words: the issuer gets to decide to which subject the subject identifier refers), because if this is not the case, the issuer cannot vouch for the correctness/truth of such a claim.

Yes, but it is the presenter who gets to explain to the verifier what their relationship is to the VC in question. This is a necessary (and underspecified) part of the Verifiable Presentation.

Unfortunately, the only hack we have in common use is assuming that if a VC's subject id == the VP creator id, then the presenter is the subject of the credential. This deserves better distinctions for other configurations, including multiple VCs issued to different ids controlled by the same person.

See @awoie's issue #882 for more discussion.

@RieksJ :

The fundamental mistake here is to confuse the authority of determining the semantics of the subject identifier with controlling the subject identifier.

I disagree. Proof of control is a fine way to determine if the subject is participating in an interaction if proof-of-control is appropriate for the identifier used. The fundamental mistake was assuming that's the only mechanism we need and therefore it can be implicit. Especially when the identifier must be a URL, which, in general, have no standards way to perform proof of control. On that I agree: since we can have identifiers that don't support proof-of-control, it's an unfortunate hack that proof-of-control is the only supported subject authentication mechanism.

It's been clear to me for a while now that we need an affirmative statement of the relationship between the holder/presenter and information contained in the presented VCs. The hack of presuming the identifiers should match just isn't flexible enough.

[RieksJ]

@jandrieu

Yes, but it is the presenter who gets to explain to the verifier what their relationship is to the VC in question.

There is a subtle, but nevertheless important difference between how you phrase this and the statement "Yes, but it is the presenter who gets to answer the request of the verifier regarding what it needs to know about the various subjects in the claim for which it is requesting a presentation".

The difference is similar as with the issuer not caring who the holder is as it is expressing statements in the form of claims and wrapping and signing it to become a VC. In principle, the verifier does not care who the presenter is, as long as the verifier is capable to determine:

• who the (real-world) entities are about which the various claims in the VP have been made. That is: the verifier would need the ability to identify (at least some of) them, and perhaps acquire certainty about that (authenticate them). One of these entities could be the presenter, but that's just a specific case. The fact that it is also (perhaps) a common case does not warrant building a specification around that case, thereby ignoring the general case.
• whether or not the subject identifiers that are used in different claims within a VP refer to one and the same entity about which these claims are made.

The verifier may only be interested in the holder insofar as it can help the verifier in making such determinations. This is obviously the case where the presenter is one of the subjects of some claim in the VP. It is perhaps a bit less obvious in the case where the presenter is in the company of a person or thing (e.g., its dog, when visiting the vet), and I suppose there are many other, different cases, where the presenter may help the verifier do this. It's why I also raised w3c/vc-imp-guide#69.

I'm aware of @awoie's issue #882, which is also the topic of the RWOT paper that he leads (and I am contributing to).

[RieksJ]

@jandrieu

I disagree. Proof of control is a fine way to determine if the subject is participating in an interaction if proof-of-control is appropriate for the identifier used.

I contend that you do not prove that you are the entity about which the issuer made a claim just by proving that you control (the private key material associated with) the identifier. Here are two examples:

In a previous comment, I showed that an issuer can make a claim about Alice using a cryptographic identifier that she controls. So far, you are right. But then, she can transfer control of her cryptographic identifiers (e.g. DIDs), to another person (Mallory). Then Mallory can proof he controls the identifier, and it is obviously then NOT a fine way to determine if the subject (which still is Alice) is the one (which is Mallory) that participates in the interaction.

In another example, control of DIDs had the use case that one or both parents would control the DIDs of their children (presumably relinquishing control to the children when they come of age). There, proof of control is also not a fine way to determine if the subject is participating in an interaction.

You could argue that in these cases, 'proof-of-control' is not appropriate for the identifier used. But then, how would a verifier know in what cases cryptographic identifiers such as DIDs are appropriate, or not?

[David-Chadwick]

Handing over "your" VCs to someone who is not the subject is a validation issue, not a verification issue, and a property such as Non Transferrable can be added to the VC to indicate this is not allowed. But just as is the case with credit cards (giving it and the PIN to someone else) passing on VCs cannot be prevented technically at the moment. Even if the VC is locked to the phone I can still give my phone away. Locking the phone to the holder's single unique biometric could be introduced but that has usability issues. Adding a real time subject verification with the issuer before the VC is released is another solution, but some do not like the wallet calling home everytime the VC is released. So I tend to agree with @jandrieu that prooving possession of the private key is the best we can do at the moment.

[RieksJ]

@David-Chadwick: This issue is about clarifying the ease of deducing that a subject is the holder (it's not about validation or verification), and I can see that proving possession (control) is an easy way of doing things. I am reluctant to admit that it is the best we can do, because if that were the case, many of the VC use-cases (a particularly nice one would be the KYC use-case in the finance section) would not work in the sense that it would be easy to commit fraud. I'm sure we can do better. It might mean that the 'ease of deducing that a subject is the holder' becomes more difficult though.

[TallTed]

I submit that this issue is less about "Clarification needed on the ease of deducing that a subject is the holder" and more about "Clarification needed on how a verifier can deduce whether the holder/presenter is a/the subject of a VC/VP; and when/whether an issuer should rely on such verifier deduction or should use explicit identifiers for all statements/claims in a VC" (possibly needing some further expansion).

I think that some detailed use cases/stories are likely to be of help, in guiding both our work now and developer/implementer work in the future.

[RieksJ]

The RWOT paper that @awoie and some others (including me) are writing will have some. Perhaps @awoie can make a (reviewable) version of the document available?

[David-Chadwick]

@RieksJ "deducing that a subject is the holder" is not always the best (or correct) thing to do.
What a verifier needs to know primarily is, "Is the current holder the same entity (the issuee) that the issuer originally gave the VC to". If you only concentrate on subject=holder then you omit use cases of animal lover holding the VC of their pet, parent holding the VC of their child etc. After checking that the VC has not been transferred to another entity after issuing (by checking that issuee=holder), the verifier may then in addition check if the issuee is the subject.

[RieksJ]

@David-Chadwick, I very much agree that "deducing that a subject is the holder" is not always the best (or correct) thing to do. In fact, I think that from the perspective of a holder this is what (s)he thinks that the verifier is doing (e.g. Alice wants to enroll for a course that Bob gives), but if you look at it from the verifier's perspective, (s)he usually couldn't care less about who the holder is (Bob doesn't care whether it is Alice that produces the claims from which Bob can determine that Alice qualifies to be enrolled; for all he cares, it could be someone else, as long as the claims are issued by a trusted issuer and ensure Alice qualifies). Of course, Bob will care who the subject of these claims is, but whether or not that happens to (also) be the holder is typically irrelevant.

Similarly, I haven't found any use-case in which the verifier would be interested to learn that 'holder=issuee', that is to say that the characteristic of having received a VC and presenting it, is relevant for a verifier. The use-cases I've seen can also be phrased as the verifier being able to verify links between the subjects of claims in one, or multiple VCs. So while 'holder=issuee' may be relevant from the holder's perspective, I very much question whether verifiers feel the same.

Could you elaborate (one of) the use-cases you mention a bit more, being precise about which VC contains which claims, and to come up with what it is that a verifier specifically needs to know for what specific purpose, and from there, provide a solid argument as to why we really need to be able to do 'holder=issuee' (as opposed to 'subject-id (sid) of some claim == sid of some other claim', or 'sid of claim1 has relation x with sid of claim 2').

[David-Chadwick]

Here is a use case we built for a hospital. The hospital wanted to allow patients to arrange their own appointments online and to order their own repeat prescriptions. In order to do this, the patient had to present 2 VCs, first an "NHS patient" VC in order to login to the Hospital IS (HIS). i.e. only NHS patients were granted access to the private (non public) pages. Once logged in, the patient was presented with a menu of different options (Pathology, Radiography, Diabetes etc.) Each one these required a different VC issued by that department to that patient, in order for the patient to see the specific personalised menu from that department. (This VC could have been marked "non-transferrable" but we did not need it as this was built into the verification process.) This VC contained the ID of the patient (subject) which allowed the HIS to look up the patient's record in that department. Then the patient was shown a menu specific to them e.g. date/time of their next appointment, drugs available to them for repeat prescription etc. In this case the holder must equal the subject in order for the user to see the correct menu (note that the concept of the issuee role was not proposed at that time, otherwise now I would have used it) as the hospital did not want anyone booking appointments for anyone else or ordering drugs for anyone else (or even knowing what drugs other people were taking, which would have been possible with holder NE subject.) (BTW, This is written up as a journal publication.)

[RieksJ]

@David-Chadwick It's clear enough that there are lots of cases where a verifier needs to establish that 'holder=subject'. I'm looking for cases where the verifier needs to establish 'holder=issuee'.

In your example, hospital departments issue VCs that I gather contain claims of which the subject-id is the same as that in the NHC patient VC. Even if they would issue such VCs only to the patient, I do not see any relevance for having/knowing the 'issuee', because when the VC is used, the verifier needs to establish 'holder=subject' and that's all there is to it. Or am I missing something?

[David-Chadwick]

@RieksJ You are correct for the hospital use case that I provided above. But if we extend the use case to that of a patient being incapacitated or unable to use the Internet and/or smart phone, and delegates this to a trusted person to act on their behalf, then in this case the issuer would validate that the trusted person is allowed to receive the patient's VC (e.g. by power of attorney in the UK), then set the issuee to the trusted person. Now in this situation the verfier would check who the subject is (to obtain the correct patient record) and check that the issuee=holder to verify that the issuer authorised this person to act on behalf of the subject. This same verification procedure (by the verifier) will work regardless of who the issuer issued the VC to (subject or trusted other).

[RieksJ]

@David-Chadwick: From what you say I get that the verifier (the department) first ensures that a particular party is delegated the right to see the specific personalised menu from that department, or to set a date/time of their next appointment, etc., on behalf of the patient (for which there are various ways of doing that), and then issues a VC to that party that has some modifications (which you state to be an 'issuee' attribute), the effect of which is that this other party can now do some stuff on the patient's behalf.

Modifying the VC by using an 'issuee' attribute works in this particular case, but it has limitations. For example, if the patient were to only want to delegate a subset of its rights, e.g., delegate making new appointments, and see what drugs have been provided, but not allow for requesting repeat-prescriptions.

There also exist other ways in which this could work, e.g., add a claim to the VC that states the patient as the subject of the claim, and have attributes for (a) the rights that are delegated (all if the attribute is omitted) and (b) the party to which such rights are delegated (e.g. by providing a DID, or some other way by which the party can be identified and authenticated). This would be a more generic approach.

[David-Chadwick]

@RieksJ Issuee is not there to provide delegation as you imply (although it may be used to good effect in delegated scenarios). Rather, Issuee is one of the fundamental roles of the VC ecosystem. It has always been so. It is just that currently it has not been documented. Instead the role of holder is documented and because different entities can hold this role for the same VC at different times, it has caused some confusion. The role of issuee for a VC is fixed for all time, regardless of who the holder is. So I am suggesting that we document this role, and, add it as an optional property of the VC if the issuer want to insert it there.

[RieksJ]

I have no objections at all to using the term 'issuee' as a role (as I also do not object to having a role of 'presenter', which I can think of as being distinct from 'holder', but that's another discussion), and document such roles.

However, I will support having such properties in the data model only if there is a realistic/practical/relevant use-case that you can do if you have that property, but you cannot do without it.

[David-Chadwick]

We already have lots of use cases in which the "non-transferrable" property is required (as you will see by inspecting the plastic cards in your leather wallet). All of these (with plastic cards) refer to the subject of the card. So if the issuee = subject, and non-transferrable is set, the verifier can easily determine if the issuer's policy has been obeyed, by checking that holder=subject. And so the issuee property is not needed (as issuee = subject).
However, if the issuee NE subject and the issuer still requires to insert the non-transferrable property into the VC, then the issuer needs a way of signalling that the subject NE issuee. This is one example of when the issuer will insert the issuee property into the issued VC. I gave one example of this above when a close relative (say) acts on behalf of an ill patient (say) when interacting with a hospital information system.
No doubt there are other examples that we have not yet thought of (which is always the case with popular standards - once users start to use a standard, then they think of use cases that the standard's writers never thought of). So by acknowledging the existence of the issuee property and documenting it we are facilitating these use cases as well.

[RieksJ]

For the example you gave, I showed that you can also do this without having the 'issuee' property (even in a more general fashion), so it doesn't qualify as a use-case that I am looking for. I agree there might be other examples that we have not yet thought of and that might qualify, but I would first like to see at least one of them before supporting the 'issuee' property. I'm not looking for use-cases that might have a use for that property, but for use-cases that cannot do without it.

[jandrieu]

However, if the issuee NE subject and the issuer still requires to insert the non-transferrable property into the VC, then the issuer needs a way of signalling that the subject NE issuee. T

This continues to be a layer violation.

The VC itself has no place for a non-transferable property because we have no technical means of enforcing that. The credential is a data object that can, inevitably, be transferred. Even proof-of-control won't prevent transferring of the actual VC. If we add such a property, people will misuse it, believing that it means what it sounds like: a mechanism to control the distribution of the statement.

That feature is desired by many (control is a popular idea), but it is not appropriate at this layer as controlling the distribution of information manifests as censorship and digital rights management and is outside the scope of this work, which is to enable anyone to say anything in a verifiable way, not to control the flow of information. Censorship is anathema to decentralized technology while DRM is a digital perpetual motion machine that many would like, but is, in fact, impossible in any system that actually presents information to a human user through physical senses.

What is desired by the use case is worth addressing, but this framing as "non-transferable" is, IMO, a non-starter.

I think we can describe the actual desired use case as: the verifier wishes to validate a business rule which includes evaluating if the current presenter/holder is the entity for whom a privilege in the credential should be recognized.

This includes two things:

1. What is the scope of the privilege intended by the VC, as described in its claims?
2. What is the intended assertion of the presenter/holder relative to the VCs presented?

For the first point, the claims should describe the boundaries of the privileges. It could be to a specific person, it could be to the "bearer", it could be restricted to normal business hours, etc. For those VCs that represent a privilege, then it is entirely appropriate for the VC to describe the bounds of those privileges within the claims. Since those restrictions could be ANYTHING, it would be a mistake to cherry pick a few restrictions and elevate them to properties of the VC rather than enabling the open-world semantics of the claims handle it.

For the second point, we must provide a means for the presenter/holder to make their own statements about their relationship to those VCs. As we see in the Citizenship use case https://www.w3.org/TR/vc-use-cases/#citizenship-by-parentage there can be rich and varied reasons for someone who is neither the subject nor the "issuee" to present a VC. Such VCs must be able to be verified (statement untampered, statement not withdrawn) so that it can then be used to validate that particular use according to the verifier's business rules.

[David-Chadwick]

@jandrieu Putting the non-transferrable property to one side, as this is clearly a very contentious issue, returning to the issuee property, then I think you will acknowledge that the issuer can make any statement it wants about anyone to anyone. The DM already contains "about anyone" but not "to anyone". So I am asserting that an issuer may want to insert into the VC both of these properties i.e. the credentialSubject and the issuee. This says nothing about verification, or how the VC can be transferred. It is simply a statement of fact made by the issuer.

[awoie]

I believe this issue has to be moved to the implementer's guide since Section C was moved.

[iherman]

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

• no resolutions were taken

View the transcript

1.17. Clarification needed on the ease of deducing that a subject is the holder. (issue vc-data-model#959)

See github issue vc-data-model#959.

Kristina Yasuda: About clarification on subject and holder. Last comment was to move this to Implementer's Guide. Any objections to doing that?.

Orie Steele: I noticed that in the context definition for VC, "holder" is defined, and I wanted to share that. It seemed odd to me that a VC would have a "holder" property in the context but no indication or examples in the spec text that this is legal..

Orie Steele: https://github.com/w3c/vc-data-model/blob/main/contexts/credentials/v2#L36.

Orie Steele: It raises questions about the "holder" property and holder binding..
… The "holder" property should be removed from VC, or the spec should comment on when it is appropriate to do that..

David Chadwick: My opinion is there should be no "holder" property. We don't know who the holder is, that's the point of VCs. You can have "issuee", but that's only a holder temporarily..

Orie Steele: I agree with David, I don't understand why holder property in the v2 context, as a property of VerifiableCredential.

David Chadwick: As issuer I give the VC to an issuee, but don't know what happens afterwards..

Manu Sporny: +1 to what Orie said, +1 to some of what DavidC said.
… I think originally this was meant VP and it may have accidentally slipped into VC..

Dave Longley: +1 to manu.

Manu Sporny: +1 to removing it from VC.

Markus Sabadello: +1, this is my understanding too.

Oliver Terbu: (withdraw my comment).

Kristina Yasuda: Anyone willing to volunteer for it?.

Orie Steele: I'm almost done with a PR..

Kristina Yasuda: Will assign you for now, thank you Orie..

Orie Steele: PR is up: #1076.

Ivan Herman: If we do that, then we also have to remove it from official vocabulary document. It's defined as a term. Or we have to deprecate it. This is okay, we can do it, but shouldn't forget..

Orie Steele: yes, https://www.w3.org/2018/credentials/#holder.

Orie Steele: domain says: "Union of: cred:VerifiableCredential cred:VerifiablePresentation".

Oliver Terbu: Did we really define "holder" for VC?.

Ivan Herman: It's certainly in the vocabulary.

Manu Sporny: The reference is here: https://w3c.github.io/vc-data-model/#presentations-0.

Oliver Terbu: But is it in the VCDM spec? Is there a normative reference? I couldn't find any such reference..

Orie Steele: oliver AFAIK, no... holder only shows up in VP section, and is optional.

Oliver Terbu: That's not normative..

Manu Sporny: Right, there was an expectation that it might become normative. So we put it in the JSON-LD context..
… ivan, because it's defined in core spec, I think we should not remove it.

Ivan Herman: I said deprecated.

Manu Sporny: It shouldn't be deprecated either, it can be in VP..
… We're talking about holder in VC, not about removing holder from VP..

Ivan Herman: So we have to look at the domain..

Manu Sporny: Exactly.

Ivan Herman: Ok, I will do it.

[iherman]

The issue was discussed in a meeting on 2023-06-07

• no resolutions were taken

View the transcript

2.5. Clarification needed on the ease of deducing that a subject is the holder. (issue vc-data-model#959)

See github issue vc-data-model#959.

Brent Zundel: current assigned to Orie.
… it is marked ready for PR, Orie what is the status?

Orie Steele: Joe pointed out that we already have this in a section in the spec. Willing to compare current section with this issue. Should be current CR work.

Brent Zundel: Adding before CR label to issue.

[iherman]

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

• no resolutions were taken

View the transcript

2.1. Clarification needed on the ease of deducing that a subject is the holder. (issue vc-data-model#959)

See github issue vc-data-model#959.

Orie Steele: several PRs are open regarding "holder".

Orie Steele: people asked in its related to #1199 ... it is.

Kristina Yasuda: where are we on this issue?
… Does 1199 directly address this issue?

Orie Steele: Brent clarified some of this in another PR, PR1199 also clarifies parts of this, I don't know if it's sufficient to close the issue... let's try to close this issue if PR 1199 does address this issue.

Kristina Yasuda: Ok, makes sense, marked as pr exists.
… direction is to close issue when PR 1199 is merged.

[iherman]

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

• no resolutions were taken

View the transcript

4.3. Clarification needed on the ease of deducing that a subject is the holder. (issue vc-data-model#959)

See github issue vc-data-model#959.

Brent Zundel: issue 959. says PR exists.
… If we merge that PR we can close this?

Orie Steele: that was the intent.

[msporny]

PR #1199 was merged, which addressed this issue. Closing.