"bound"/"binding" terminology is a significantly stronger relationship than is actually present between VCs and their Subjects *or* Holders

[TallTed]

Originally posted by @TallTed in #818 (comment)

I am mostly concerned about the "bound"/"binding" terminology in use here, which I think is a significantly stronger relationship than is actually present between these VCs and their Subjects or Holders. I think it would be better to say that xyz property/ies in the Credentials under specific discussion are (or SHOULD be or MUST be) set to strings or URIs which identify the Holder who is expected to Present the VC to any Verifiers downstream. Then, the Verifier is expected to check that either some other qrs property/ies were (or SHOULD have been or MUST have been) set to strings or URIs which identify the Subject, OR the Subject is always the same as the Holder identified by the values of xyz property/ies, ... Or something along those lines.

I think that "anoncreds aren't bound to a subject, but are rather issued to the subject, so binding to the holder is a way to accomplish connection of the credential to the subject" translates roughly to "anoncreds are Issued to their Subject, which is defined as a sapient being, and which is not identified as the Subject within the VC. Identifying the Holder is an indirect way to accomplish association of the VC with its Subject," which Subject is not really obscured by this method, since the identified Holder is always the Subject and anyone who can access the value of the field identifying the Holder is thereby able to access to identifier of the Subject. Leading to another concern with this section, since it seems that the Subject anonymity desired to be delivered through ZKP, at least in part by identifying one Holder who must be the Subject, instead of identifying the Subject, isn't actually delivered.

I'm sure I'm missing something exceedingly clever, and I hope someone can explain it in terms I can understand and that we can swiftly adopt (and/or edit slightly to adopt) for this section.

[iherman]

The issue was discussed in a meeting on 2021-09-29

• no resolutions were taken

View the transcript

2.1. "bound"/"binding" terminology is a significantly stronger relationship than is actually present between VCs and their Subjects or Holders (issue vc-data-model#821)

See github issue #821.

Wayne Chang: Can you give us context TallTed?

Ted Thibodeau Jr.: Binding is a much stronger relationship than any of the relationships that we've been discussing... we can associate, but bind is a bit too strong.
… I haven't done anything yet, just the terminology is bad.

Dave Longley: I agree with Ted, this comment was on a PR that was talking about binding language, might not have "binding" language in the spec. We should consider being careful with this language and avoid "binding" terminology because it's too strong.

Ted Thibodeau Jr.: I thought binding language wasn't in v1.0, but it is in another PR?

Wayne Chang: The PR where it was first brought up was targeting v1.1, so we might need to resolve this.

Dave Longley: #818 did not introduce "binding" ... is there another PR?

Wayne Chang: #818 (comment)

Brent Zundel: 818 doesn't introduce binding language, there are some language that raised questions for Ted. My response brought up the whole binding language and that turned into "how much do we want to talk about the holder and how they're connected to the credentials" etc.
… I don't think there are changes that need to be made to v1.0, v1.1, or v1.2 to correct any language that exists in the spec, let's refine language moving forward, can be done substantively or editorially.

Wayne Chang: An important distinction that emerged from discussion, it's not within the literal text, doesn't need to be fully resolved. Anyone have a recommended next step?

Brent Zundel: One possible next step, this issue serving as a place where the discussion can occur for how we want to refer to holders in the spec. Do we want to think about, suggestion in some of the community, normatively say something? This is a place where those conversations can happen. Not really a v1.1 or v1.2 issue.
… depends on where people think a solution should go?

Wayne Chang: Could be clarification

Manu Sporny: My suggestion is that we defer to v2. Primarily because this feels like a broader discussion, like a spec philosophy discussion. It's a good, broad discussion to have and therefore doesn't seem appropriate for v1.1 or v1.2.

Brent Zundel: +1 on defer to V2. Need to have the conversation, and the broader the group the better.

David Chadwick: +1 to manu

Manu Sporny: There are many people that have opinions about how holder association or "binding" should be done. I think we need a section in the spec about that, it can't be addressed with a few sentences.

Wayne Chang: I'm ok with that, any objections to defer to v2? Looks like there is support to deferring to v2.

[agropper]

I suggest a two-step process. Regardless of 1.1, 1.2, or v2, can we have a list of reasons why Holder is a normative term in the spec? If we had consensus on the purposes of Holder being different from Subject it would help us clarify the language. For example, - ZKP depend on Holder being separate from the VC Subject because... - Things (as in the contents of a box) as a VC Subject depend on Holder because... - A normative Holder property in a VC improves privacy over VC Subject alone because... - etc...

…

On Wed, Sep 29, 2021 at 12:17 PM Ivan Herman ***@***.***> wrote: The issue was discussed in a meeting <https://www.w3.org/2017/vc/WG/Meetings/Minutes/2021-09-29-vcwg#section2-1> on 2021-09-29 - no resolutions were taken *View the transcript* 2.1. "bound"/"binding" terminology is a significantly stronger relationship than is actually present between VCs and their Subjects *or* Holders (issue vc-data-model#821) *See github issue #821 <#821>.* *Wayne Chang:* Can you give us context TallTed? *Ted Thibodeau Jr.:* Binding is a much stronger relationship than any of the relationships that we've been discussing... we can associate, but bind is a bit too strong. … I haven't done anything yet, just the terminology is bad. *Dave Longley:* I agree with Ted, this comment was on a PR that was talking about binding language, might not have "binding" language in the spec. We should consider being careful with this language and avoid "binding" terminology because it's too strong. *Ted Thibodeau Jr.:* I thought binding language wasn't in v1.0, but it is in another PR? *Wayne Chang:* The PR where it was first brought up was targeting v1.1, so we might need to resolve this. *Dave Longley:* #818 <#818> did not introduce "binding" ... is there another PR? *Wayne Chang:* #818 (comment) <#818 (comment)> *Brent Zundel:* 818 doesn't introduce binding language, there are some language that raised questions for Ted. My response brought up the whole binding language and that turned into "how much do we want to talk about the holder and how they're connected to the credentials" etc. … I don't think there are changes that need to be made to v1.0, v1.1, or v1.2 to correct any language that exists in the spec, let's refine language moving forward, can be done substantively or editorially. *Wayne Chang:* An important distinction that emerged from discussion, it's not within the literal text, doesn't need to be fully resolved. Anyone have a recommended next step? *Brent Zundel:* One possible next step, this issue serving as a place where the discussion can occur for how we want to refer to holders in the spec. Do we want to think about, suggestion in some of the community, normatively say something? This is a place where those conversations can happen. Not really a v1.1 or v1.2 issue. … depends on where people think a solution should go? *Wayne Chang:* Could be clarification *Manu Sporny:* My suggestion is that we defer to v2. Primarily because this feels like a broader discussion, like a spec philosophy discussion. It's a good, broad discussion to have and therefore doesn't seem appropriate for v1.1 or v1.2. *Brent Zundel:* +1 on defer to V2. Need to have the conversation, and the broader the group the better. *David Chadwick:* +1 to manu *Manu Sporny:* There are many people that have opinions about how holder association or "binding" should be done. I think we need a section in the spec about that, it can't be addressed with a few sentences. *Wayne Chang:* I'm ok with that, any objections to defer to v2? Looks like there is support to deferring to v2. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#821 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABB4YPKZFFNBJJYQB5DNLLUEM3YHANCNFSM5ECXBODA> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.

[TallTed]

@agropper -- I've numbered these because assigning letter-number pairs to statements seems to make a difference to you. --

HS1. The Subject(s) is/are the entity/ies about which the Claims/Statements in the Credential are made.

HS2. The Holder(s) is/are the entity/ies which Hold the Credential, for some or all of its lifespan.

HS3. A/the Subject may be the same entity as a/the Holder for any given Credential.

HS4. There is no requirement that the Subject of any given Credential be the same entity as any Holder of that Credential.

HS5. Every Credential has at least one Subject, and at least one Holder, in its lifespan.

HS6. The Subject and Holder are not distinguished in our model because that distinction improves privacy, nor because ZKP requires them to be distinct. They are distinguished simply because they are distinct.

[agropper]

@TallTed - Thank you for engaging.

On Wed, Sep 29, 2021 at 3:29 PM Ted Thibodeau Jr ***@***.***> wrote: @agropper <https://github.com/agropper> -- I've numbered these because assigning letter-number pairs to statements seems to make a difference to you. -- HS1. The Subject(s) is/are the entity/ies about which the Claims/Statements in the Credential are made.

Absolutely.

HS2. The Holder(s) is/are the entity/ies which Hold the Credential, for some or all of its lifespan.

Who cares? (I'm not being flip)

HS3. A/the Subject *may* be the same entity as a/the Holder for any given Credential.

Sure, but that's not a reason to have a Holder as a normative aspect of the spec.

HS4. There is no requirement that the Subject of any given Credential be the same entity as any Holder of that Credential.

Of course, but that's not a reason to have a Holder as a normative aspect of the spec. Even if we're talking about a thing as a VC Subject, who cares about the holder (little h) and why?

HS5. Every Credential has at least one Subject, and at least one Holder, in its lifespan.

Every Credential also has an Issuer. The Issuer could be considered a Holder since they have the information in the VC and can prove authenticity. Why is Holder useful?

HS6. The Subject and Holder are not distinguished in our model because that distinction improves privacy, nor because ZKP requires them to be distinct. They are distinguished simply because *they are distinct*.

That seems like a circular argument. I could probably invent other roles that are distinct from the Subject. For example, Guardian. A Guardian is a very useful legal distinction and every Subject could also have a Guardian or not. Should we introduce Guardian as a normative component of the VC spec? - Adrian

…

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#821 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABB4YPSTNHWLYEXTE3A2RLUENSKLANCNFSM5ECXBODA> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.

[brentzundel]

related to issue #789

[jandrieu]

@agropper The holder is a normative term because it defines a role that participates in normative interactions.

[agropper]

@joe Andrieu ***@***.***> I think much of the discussion around holder is bikeshedding that does not adequately consider the confusion of contexts and interests for VCs https://lists.w3.org/Archives/Public/public-credentials/2022Sep/0046.html

…

On Wed, Sep 7, 2022 at 12:02 PM Joe Andrieu ***@***.***> wrote: @agropper <https://github.com/agropper> The holder is a normative term because it defines a role that participates in normative interactions. — Reply to this email directly, view it on GitHub <#821 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABB4YLR73ERRZJ6VSQLFPDV5C375ANCNFSM5ECXBODA> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[TallTed]

@agropper -- Please visit the GitHub website, and edit your latest comment. @joe Andrieu in the first line should be @jandrieu. @joe is a GitHub user who is not a member of relevant groups, etc.

(Email responses to GitHub threads seem convenient, but do not handle markdown, and are chockablock with other issues that I think near-completely negate any convenience they offer, as evidenced here, where their quote of @jandrieu's comment does not include his GitHub handle for use in your reply.)

[jandrieu]

I'm not bikeshedding here. I'm responding to your direct question:

can we have a
list of reasons why Holder is a normative term in the spec?

I gave you one reason, which is, on its own sufficient to justify defining "Holder" normatively.

Issuers issue VCs to Holders. That's a defining act.
Verifiers verify VCs presented by Holders. That's a defining act.

The rest of the work in these specs is describing how these interactions happen and what data elements are involved. Without the defining term, we can't do that: we need the term to describe the rest of the system. That's why "Holder" is defined normatively.

[agropper]

and my point is that using the same term across both issue and verification is a confusing strategy relative to the big picture of VC adoption. (I understand that my model for standardized digital credentials is different from the SSI community so I limit my live participation. I will limit my written comments as well if others find them distracting.)

…

On Wed, Sep 7, 2022 at 12:38 PM Joe Andrieu ***@***.***> wrote: I'm not bikeshedding here. I'm responding to your direct question: can we have a list of reasons why Holder is a normative term in the spec? I gave you one reason, which is, on its own sufficient to justify defining "Holder" normatively. Issuers issue VCs to Holders. That's a defining act. Verifiers verify VCs presented by Holders. That's a defining act. The rest of the work in these specs is describing how these interactions happen and what data elements are involved. Without the defining term, we can't do that: we need the term to describe the rest of the system. That's why "Holder" is defined normatively. — Reply to this email directly, view it on GitHub <#821 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABB4YKSOGC45QLX5GMSHCDV5DAKFANCNFSM5ECXBODA> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[jandrieu]

I agree that people get confused, because the holder term is derived from the notion of the holder of a degree, the legitimate recipient of the credential and yet the holder has fundamental different roles in issuance and verification. I believe this is an unavoidable topological complexity: it is innate to the interactions we are describing.

Whatever term we use for it, the Holder is the unifying link between the recipient and the presenter. They are expected to be the same person. It is a potential attack vector when that expectation is violated. In some cases it is a problem (falsely presenting someone else's VC Driver's License as my own), in other cases, it is not (my travel agent presenting the same VC to the airline as proof of my identity for travel).

Whether or not a holder got a VC legitimately is a separate question of whether or not they are using it legitimately. Both of these questions depend on understanding that the recipient may not be the presenter, and we need a term to refer to that situation.

Without that common term linking recipient & presenter, we can't even talk about it.

So, the holder is anyone who holds a VC. They have in their digital possession the serialization of that VC.
The recipient becomes a holder upon issuance.
The presenter starts as a holder because they provide the VC that is presented to the Verifier.

These are topological fundamentals that describe the necessary flow of information. These terms are what allow us to then answer policy questions like "How is a holder authenticated before issuance?" and "How is the holder's identity confirmed before issuance?" which can easily be stated as "How is a recipient authenticated before issuance?" and "How is the recipient's identity confirmed before issuance?".

Note that these cannot be stated in the form "How is a requester authenticated before issuance?" and "How is the requester's identity confirmed before issuance?". Because the requester (the initiator of a flow) may or may not be the holder.

Adding the clarifying roles of recipient and presenter also leads us to the more interesting set of questions:
"How is a presenter authenticated before issuance?" and "How is the presenter's identity confirmed before issuance?"

The answer to both of these is that they are not. The presenter cannot be known at the time of issuance. The expectation is the presenter is the recipient, but that is a desired state, not a guaranteed one and when violated it should be perceivable in operations and discussable in collaborations.

What seems to be a disconnect is that you don't seem willing to accept the topology of VCs. That the means to provide agency is to sever the link between Issuer and Verifier so that the Holder gets to decide which of each they want to work with and which data they want to expose to whom. Verifiers should NOT get VCs except those that come from the legitimate recipient and the Issuers are not involved directly in verification. It is this separation of concerns that underpins the entire notion of agency that VCs enable.

It is a huge contrast from the OAuth model of deferring to the Issuer/IDP in real-time with the user in the loop, which itself is an improvement over the data brokerage pattern of deferring to a 3rd party without involving the user. This evolution:

no involvement => authorization of direct data exchange => direct exchange of data with independent verification

THIS is the change in data architecture enabled by VCs. Without the holder as the unifying term for the recipient and presenter, such an evolution is almost impossible to talk about. As I think you've found. Most of us simply don't understand what you are asking for in light of these fundamental, topological notions of how VCs work: how the data flows between parties from Issuer to Holder to Verifier.

When you argue that "Holder" is invalid, many of us, including me, hear that as the "topology of enabling users to control information disclosures by putting the user in the custody loop" is invalid. Which is a non-starter because this topology is the whole point of the approach.