"bound"/"binding" terminology is a significantly stronger relationship than is actually present between VCs and their Subjects *or* Holders #821
Comments
|
The issue was discussed in a meeting on 2021-09-29
View the transcript2.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. 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.
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. 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. 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.
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. |
|
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>.
|
|
@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. |
|
@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>.
|
|
related to issue #789 |
|
@agropper The holder is a normative term because it defines a role that participates in normative interactions. |
|
@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:
***@***.***>
|
|
@agropper -- Please visit the GitHub website, and edit your latest comment. (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.) |
|
I'm not bikeshedding here. I'm responding to your direct question:
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. 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. |
|
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:
***@***.***>
|
|
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. 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: 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: 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. |
|
I totally agree and support the imperative that issuers SHOULD NOT be aware
of verification. It's critical that all normative aspects of VCs be
consistent with this separation. My concerns and attempted contributions
are intended to drive this change that we seek. Let's call this the Prime
Directive.
Implementing the Prime Directive and adoption of VCs can be helped by:
- Avoiding the kind of things, including nomenclature, that confuse even us
after working on this for five years and more,
- Recognizing that VCs always have a subject and that subject might be a
human or a thing
- Recognizing that _any_ constraints on a human subject's ability to
delegate or otherwise involve experts and fiduciaries in receipt or
presentation will lead to unintended consequences including:
a) loss of anonymity because it's just more convenient to use a
stronger credential rather than a ZKP
b) increased surveillance when people don't bother with selective
disclosure where they might have allowed a delegate to represent and
protect them
c) explosion of biometric surveillance and associated registries as
access to non-repudiable biometrics is expanded through standardized VCs
d) the risk of certified clients becoming commonplace as a way of
ensuring chain-of-custody between receipt and presentation
e) the risks of vastly expanded and interconnected trust frameworks as
asymmetrically powerful issuers and recipients take advantage of our
standards
f) usability problems as we increase wallet complexity and people find
themselves spreading credentials among multiple wallets
g) further consolidation of essential biometric secure element
platforms as they add proprietary support for VCs
Simply put, I wholeheartedly support the Prime Directive but I also
recognize regulatory capture when I see it. Our SSI community lacks the
kind of broad community participation that DIDs and VCs need in order to be
successful. As standards developers and as a society, we need more
participants with B2C business models, more engagement with the biometric
secure element platforms, more respect for IETF processes that are designed
to reduce regulatory capture, and more scrutiny of the burdens we're
placing on human subjects as we introduce selective disclosure and
encrypted data vaults "for their benefit".
…On Thu, Sep 8, 2022 at 1:12 PM Joe Andrieu ***@***.***> wrote:
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.
—
Reply to this email directly, view it on GitHub
<#821 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AABB4YN5V7MGKHBYJVIFZJDV5INAHANCNFSM5ECXBODA>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
@jandrieu wrote
I have several troubles with such texts, e.g.,
See also #923 (comment). |
|
Regarding the term "holder", please discuss in issue #902. Going back to the original question, I think I understand the concern. would it be helpful to clarify the following? I have found it helpful:
|
|
There's a gordian (cough) tangle between #942, #1054, #821, #902, and maybe others. I don't think that any of these can be resolved on its own. This may warrant a special topic call. Though, it might still be too soon for that. Those who want what has been discussed as I think what is really wanted is something like I think |
|
It might be easier to untangle the “knot” based on what we want to avoid or
discourage.
We want to discourage the expectation that a human is carrying a secure,
certified vault locked around their neck. This should be discouraged even
if the vault features all sorts of controls for selective disclosure
because selective disclosure itself is a burden and many humans are not
experts in how to twiddle the controls.
The vault need not be physically locked around one’s neck. It could could
be an unbreakable biometric link to one’s iris, as in Worldcoin or, soon
enough, DNA.
Is our goal for VCs to create an unbreakable chain of custody between issue
and verification?
Consider, for example, including an Issuee in the VC or not. It seems
reasonable to assume that both the issuer and the verifier has access to a
Worldcoin Orb costing about as much as a top-of-the-line smartphone. The
Orb’s ID is entered as Issuee in the VC. This eliminates the need for a
vault.
Consider, at the other end of the spectrum, mandating that only DIDs can be
used in a VC. No Orb ID or DNA allowed. No drivers license or passport
number either. As DHS says: “Bring your own DID”. In this case, the vault
needs to preserve the chain of custody among DIDs. It seems that we’re
pushing the issue out of the VC and into the certification of DIDs.
The human rights respecting solution depends on being clear about how
subjects or issuees are specified in a VC. Saying that it MAY be a VC is
not helpful.
Adrian
…On Wed, Apr 12, 2023 at 5:36 PM Ted Thibodeau Jr ***@***.***> wrote:
*There's a gordian (cough) tangle between #942
<#942>, #1054
<#1054>, #821
<#821>, #902
<#902>, and maybe others. I
don't think that any of these can be resolved on its own.*
*This may warrant a special topic call. Though, it might still be too soon
for that.*
Those who want what has been discussed as holderBinding *generally* seem
to want the VC/VP presenting holder to be provably the same as the holder
who received that VC (or the VC from which that VP was derived) from the
issuer — i.e., that the issuee is also the presenter — but I think this
is a special case of a more generalizable desire, which could be
implemented in a way that delivers what these folks want *as well as*
some similar stuff that is otherwise not delivered (yet).
I think what is really wanted is something like authorizedHolder or
authorizedPresenter, which I think could be fine, and which underscores
the need for strong AuthN at all points, especially but not only issuance
and presentation times. (Note that I'm not suggesting there be one
identifier (to rule them all!) per entity; only that the presenting
entity needs a way to demonstrate to the verifier's satisfaction that
they are the same entity identified as the authorizedHolder,
authorizedPresenter, issuee, or whatever.)
I think authorizedPresenter would remove any wish or need for anything
like a nonTransferable property, and I think authorizedPresenter would do
a better job of what is wished for by nonTransferable, holderBinding,
confirmationMethod, or confidenceMethod. (A wildcard value or simple
omission of this property could address the wish for a bearerCredential
or the like.)
—
Reply to this email directly, view it on GitHub
<#821 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AABB4YPPIFDI2AMOLZVP5HTXA4N65ANCNFSM5ECXBODA>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
@TallTed I think |
|
@TallTed The main issue I have with authorisedPresenter is that the issuer is pre-determining for all time who may present this VC. This goes against the general VC philosophy that the holder chooses who and when to present the VC. "issuee" on the other hand merely states a fact about who the VC was originally issued to, and says nothing about who may subsequently hold or present the VC. So it could work in tandem with authorisedPresenter, or be separate from it, but not be replaced by it. |
We're the ones defining
So we say that
|
Correct me if I'm wrong, but aren't you the one who started the long threads about "holder binding", which was initially framed as a way for the issuer to "bind" the ability to present a VC to specific presenters (holders)? Now you're saying that you don't want presentation to be "bound"/limited to specific holders? It seems to me that Any holder, whether identified as |
This is not what is proposed in PR #1054 and I'm pretty sure about that since I proposed the PR :). @TallTed It also means that |
|
@TallTed The semantics are more nuanced than you are presenting. There certainly is a requirement for a verifier to know if the holder is authorised to present the VC (in the VP) that it has just received. But that is different from the requirement for the issuer to say who it originally gave the VC to (which the issuee property provides). The verifier may want the holder to be the issuee, or it may not. But if it does not know who the issuee is, it won't be able to determine this. Conversely, the issuer may not want the issuee to pass on the VC to anyone else, but unless it can indicate who the issuee is, it won't be able to indicate this. And if the verifier cannot determine reliably who the holder is (which confirmation method provides) it won't be able to enforce its rules either. So the two properties (issuee and confirmationMethod) are independent but can be used together, as my slides for the face to face indicated. |
|
There are a lot of different ideas wrapped up in this conversation.
To my perspective, #2 and #3 are out of scope. We have no technical way to prevent any particular holder or presenter from holding and presenting. However, But at the end of the day, it isn't WRONG for an issuer to want to specify to whom they issued the credential. And in some isolated use cases it makes a lot of sense. It's particularly useful for subjects incapable of acting on their own (pets, children, mentally disabled, etc.).
I think the biggest problem with issuee is whether or not we have multiple implementations do that. If we do, then I'd look to those implementers to propose the data model for that property. Personally, if we have an issuee, I agree with @David-Chadwick that we would be wise to re-use the confirmation method so we have the same flexible authentication. In particular, for a VC with a dog as the subject and the owner as issuee, it would be good to have a means for the owner to be able to authenticate as the owner (at least wrt to that VC). But I do want to advocate that we be careful about the implied guarantees when we talk about this stuff. #2 and #3 are not legitimate guarantees for VCs. |
Fully agree and let's have that conversation in the issue that was created for that -> #882 and the PR #1054
Fully agree and let's have that conversation in the issue that was created for that -> #942 After reading this thread, I can see that we are discussing the same things as in the issues referenced above. Since this issue does not ask for specific changes in the current spec text, I'd suggest closing this issue and keeping the conversation focused in #882, #1054 and #942 . @TallTed are you ok with that? |
I don't agree that this is a requirement -- it's more that the verifier needs to be able to decide whether they want to accept the VC or not. There is no requirement that some external party tell the verifier what to do. Thanks for your comments, I'm in agreement with them. I think there is a tendency for people to squint at VCs and try to match them up with other technologies in the ecosystem. This happens, I think, most frequently with authorization token technologies (often implemented as JWTs). But these sorts of authorization tokens are used in two party systems where all decisions are delegated to some external party (an "Authorization Server") that acts as the "issuer" of the tokens. This is very different from what VCs are and how the three party model they rely on works. We should be careful not to conflate these things by trying to bring in terminology and patterns from fundamentally different technologies (even if the differences may sometimes appear subtle). The result isn't helpful. Rather, it's harmful ... because everything doesn't actually cleanly align. People shouldn't be confused into thinking it does. I think it's a good idea to allow verifiers to increase their confidence that the entity they think some identifier refers to is the same one that the issuer thought it referred to. I also think it's a good idea to enable verifiers to gain confidence that a particular presenter is the same entity that an identifier in the VC refers to. These are useful things for verifiers to be able to do when working with statements of (claimed) truth from various issuers. However, I think it's a (really) bad idea to try to squeeze VCs into the two-party ("Authorization Server" + "Resource Server") model where the "issuer" is the authority that makes all of the decisions and the "verifier" just complies (by "confirming" this or that before proceeding). This is an application-specific, strict top-down authority model typically implemented using technologies that were designed with that primary use case in mind. VCs are designed, instead, based on an non-application specific, open world, three party model where authority is evenly distributed. |
|
@dlongley I accept your change of semantics for the verifier's requirement. Thankyou for this. The verifier does need to decide whether to accept the VP/VC or not to accept it. One component of that decision MAY be to look at any policy statements made by the issuer, and to decide whether to accept these or not. We already have real life use cases of when a verifier decides to accept the "nonTransferrable" property of the issuer (see the use cases document for the historic site and wholesaler examples) and when the verifier decides to ignore it (supermarket A accepting the discount coupon issued by supermarket B to a customer). So the verifier is in control and it makes the authz decision. |
|
The issue was discussed in a meeting on 2023-06-21
View the transcript2.5. "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 vc-data-model#821. Brent Zundel: The data model only uses the word binding within token binding. So I don't think this currently calls for any action to be taken. Kristina Yasuda: I think this was originally raised related to the zkp section. Ted Thibodeau Jr.: Yes I think we can mark this as pending close. My concern is with the use of the term holderBinding. |
|
No objections raised to closing since marked |
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.
The text was updated successfully, but these errors were encountered: