update normative statements in ZKP section #818
Conversation
| <a>verifiable credentials</a> in the <a>verifiable presentation</a> were issued | ||
| to the same <a>holder</a> without leaking personally identifiable information |
There was a problem hiding this comment.
| <a>verifiable credentials</a> in the <a>verifiable presentation</a> were issued | |
| to the same <a>holder</a> without leaking personally identifiable information | |
| <a>verifiable credentials</a> in the <a>verifiable presentation</a> were issued | |
| to the same <a>holder</a> without leaking personally identifiable information |
Somehow I missed this in previous reviews.
- Why do the
derived <a>verifiable credentials</a>have to have beenissued to the same <a>holder</a>? - Are
derived <a>verifiable credentials</a>issued at all? - Why are we checking whether the current holder was the original holder of any
<a>verifiable credentials</a>?
There was a problem hiding this comment.
Indy anoncreds zkp-credentials, which were used as the exemplar for much of the material in this section, require that issued credentials be bound to a holder. One reason for this is 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. Another is to give verifiers more confidence that credentials are linked even when the disclosed claims are kept to a minimum. Binding to a holder also makes sharing credentials more detectable and unwieldy, which is seen as valuable in the anoncreds ecosystem.
That said, there are more zkp-credential schemes now than there were when the section was written, and not all of them require holder binding, even though many still consider that best practice. This is why the MUST is being changed to a SHOULD.
There was a problem hiding this comment.
This suggestion appears to be the same as the current text in there. I presume this review comment was more about raising the questions which I think @brentzundel addressed. Please let me know if there's any additional changes that I missed to resolve this comment.
There was a problem hiding this comment.
this review comment was more about raising the questions
Correct. However, I do not think that the answers provided by @brentzundel remove my concerns with this section.
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 slighly to adopt) for this section.
There was a problem hiding this 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.
+1. And if there are cases where there aren't actually any properties in the VC itself with this information because some mechanisms include it via secrets and/or proof data, then that can be stated as an option as well. I think it's important that we indicate that we're talking about setting expectations -- and not assert a level of control that isn't possible. It's also fine to say that there are mechanisms that attempt to impede adversaries that try to subvert these expectations, but such statements should include a friendly warning that they all have limitations that need to be well understood by implementers (and readers should consult external documentation for that).
There was a problem hiding this comment.
Do we want to action this within this PR - if so can you propose some suggested changes based on the discussions so far.
There was a problem hiding this comment.
@kdenhartog -- There are no changes to make here in this PR based on this comment.
|
This confusion is related to the introduction of "holder" as a normative actor in the VC data model. https://github.com/decentralized-identity/waci-presentation-exchange/discussions/96 P1 - A verifiable credential can stand alone separately from its presentation and can participate in ZKPs regardless who "holds" it. P2 - Presentation (with or without ZKP) by a particular holder, be they the issuer, subject, or delegate is a matter of identity that is completely separable from the VC data model itself. The boundary between the VC and its derivatives is authorization. P3 - Introducing "holder" as a normative element of the VC data model brings with it certain privacy risks such as issuers and verifiers requiring "certified" holders that are therefore not self-sovereign to the VC subject. P1-P3 are an attempt at a relatively simple framing of what could be confusing about VCs. Are these statements wrong or controversial? See also: |
|
@agropper -- This is the Open World of the Web. Anyone (Issuer) can say (Issue) anything (Claims within Credentials) about anything (Subject) including anyone. The Subject has NO authority over any Issuer nor Verifier, and, in fact, has no role as an actor of any kind in the ecosystems of the Web or VCs. |
@agropper I'm afraid this is a continued area where terminology is preventing us from having a reasonable conversation. The holder is by definition the party that physically holds and later presents a credential. Therefore, P1 is not a thing. A credential is ALWAYS presented by a holder. That holder may or may not be the subject, but they are ALWAYS the holder. Second, VCs do not have derivatives. That isn't a thing. There are some notions of chains of VCs, but those are not part of the VC architecture. You can ALWAYS make a statement about another statement "Joe says that what Adrian said is brilliant" and those types of semantics could be thought of as derivative if that's what you mean, but they really are just two VCs: two statements. One the initial utterance, the second the commentary on the first. So, P2 is also not valid. Presentation is always by a holder. And delegation doesn't apply precisely because non-holders cannot present. Non-subjects can, and when they do, they are acting as the holder. Finally, "holder" is not being introduced. It is foundational to the work and its been there since well before it entered Recommendation status. The Holder is a primary role in the system, BY DEFINITION, and attempting to reject that notion rather than work within it is why it is so hard for many of us to work with you to address the meritorious parts of your concerns. I'm not sure how else to get these points across. I believe we are talking past each other, as I have explained this multiple times. I believe any attempt to remove Holder at this stage would require such a restructuring of the VC model as to make it an unworkable adjustment for the maintenance working group. Further, you seem to be the only one who perceives that the mere definition of that role creates privacy problems. It doesn't. It clarifies who is doing what at which stage in the VC lifecycle. Now, what holders, verifiers, and issuers are allowed to do can absolutely cause privacy problems, but the definition itself does not. We need to find a way to get you speaking the same language as the rest of the community or we're going to continue running this thread that only you seem to understand. Repeating conversations because of an unwillingness to adopt the common language is not a recipe for collaborative development. |
|
@joeandrieu The reason I may not be “speaking the same language as the rest
of this community” may be that I have a unique role as invited expert on
privacy. As such, I have been an active participant for about as long as
anyone and I have tried to implement the standards to the extent I have
access supported libraries. Unlike most of the folks in our community, I am
working and supporting the implementation out of my own pocket.
I am also a strong supporter of the VC and DID work and am trying to
understand it and feel comfortable explaining it to skeptics in a
convincing way. Thank you for bearing with me.
more inline….
On Fri, Sep 10, 2021 at 3:46 PM Joe Andrieu ***@***.***> wrote:
This confusion is related to the introduction of "holder" as a normative
actor in the VC data model.
decentralized-identity/waci-presentation-exchange#96
<https://github.com/decentralized-identity/waci-presentation-exchange/discussions/96>
P1 - A verifiable credential can stand alone separately from its
presentation and can participate in ZKPs regardless who "holds" it.
P2 - Presentation (with or without ZKP) by a particular holder, be they
the issuer, subject, or delegate is a matter of identity that is completely
separable from the VC data model itself. The boundary between the VC and
its derivatives is authorization.
P3 - Introducing "holder" as a normative element of the VC data model
brings with it certain privacy risks such as issuers and verifiers
requiring "certified" holders that are therefore not self-sovereign to the
VC subject.
P1-P3 are an attempt at a relatively simple framing of what could be
confusing about VCs. Are these statements wrong or controversial?
@agropper <https://github.com/agropper> I'm afraid this is a continued
area where terminology is preventing us from having a reasonable
conversation.
I’m doing my best to be reasonable.
The holder is *by definition* the party that physically holds and later
presents a credential. Therefore, P1 is not a thing. A credential is ALWAYS
presented by a holder. That holder may or may not be the subject, but they
are ALWAYS the holder.
By this definition, the Issuer is always a holder as well.
Please reword P1 in any way you would prefer.
Second, VCs do not have derivatives. That isn't a thing. There are some
notions of chains of VCs, but those are not part of the VC architecture.
You can ALWAYS make a statement about another statement "Joe says that what
Adrian said is brilliant" and those types of semantics could be thought of
as derivative if that's what you mean, but they really are just two VCs:
two statements. One the initial utterance, the second the commentary on the
first.
I’m not hung up on the “derivative” issue. I agree with your statement
above.
So, P2 is also not valid. Presentation is always by a holder. And
delegation doesn't apply precisely because non-holders cannot present.
Non-subjects can, and when they do, they are acting as the holder.
Again, as per P2, I see the issuer as a potential holder just like the
subject or their delegate. If you can reword the intent of P2 in a way you
agree with, it might help our conversation.
Finally, "holder" is not being introduced. It is foundational to the work
and its been there since well before it entered Recommendation status. The
Holder is a primary role in the system, BY DEFINITION, and attempting to
reject that notion rather than work within it is why it is so hard for many
of us to work with you to address the meritorious parts of your concerns.
I’m trying my best. I just don’t understand why my drivers license as a
verifiable credential can exist without the concept of “holder”. What am I
missing when the license is changed from a physical tamper-resistant card
to a tamper-resistant digital structure?
I'm not sure how else to get these points across. I believe we are talking
past each other, as I have explained this multiple times.
I believe any attempt to remove Holder at this stage would require such a
restructuring of the VC model as to make it an unworkable adjustment for
the maintenance working group. Further, you seem to be the only one who
perceives that the mere definition of that role creates privacy problems.
It doesn't. It clarifies who is doing what at which stage in the VC
lifecycle. Now, what holders, verifiers, and issuers are allowed to do can
absolutely cause privacy problems, but the definition itself does not.
Please, help me understand the “holder” relationship in terms that I might
relate to a skeptic. The claims in a VC are bound to the identity of a
subject. If / when a holder is introduced in a normative way, it probably
relates to the protocols for interacting with VCs rather than the VC data
model itself.
We need to find a way to get you speaking the same language as the rest of
the community or we're going to continue running this thread that only you
seem to understand. Repeating conversations because of an unwillingness to
adopt the common language is not a recipe for collaborative development.
I’ve not introduced new language. I’m just trying to keep separate the data
model concerns from the role and protocol concerns. Why is that causing a
problem?
—
… You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#818 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AABB4YMCEB5JCONJFDNKUWLUBJOB5ANCNFSM5DYMIMDQ>
.
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>.
|
Co-authored-by: Ted Thibodeau Jr <tthibodeau@openlinksw.com>
Co-authored-by: Ted Thibodeau Jr <tthibodeau@openlinksw.com>
Co-authored-by: Ted Thibodeau Jr <tthibodeau@openlinksw.com>
Co-authored-by: Ted Thibodeau Jr <tthibodeau@openlinksw.com>
Co-authored-by: Ted Thibodeau Jr <tthibodeau@openlinksw.com>
Co-authored-by: Ted Thibodeau Jr <tthibodeau@openlinksw.com>
Co-authored-by: Ted Thibodeau Jr <tthibodeau@openlinksw.com>
I don't see them as wrong for the most part (there's some edge cases I'm sure where they don't hold), but not sure how they affect the language written in the PR. Based on my reading, the language goes to further enhance these points not reduce it. What are you suggesting in terms of updates to the PR here? |
Co-authored-by: Dave Longley <dlongley@digitalbazaar.com> Co-authored-by: Brent <brent.zundel@gmail.com>
kdenhartog
added
errata
|
The issue was discussed in a meeting on 2021-09-15
View the transcript3.2. update normative statements in ZKP section (pr vc-data-model#818)See github pull request #818. Brent Zundel: PR 818. Update normative statements in the ZKP section. A little more extensive of a PR. Kyle Den Hartog: Just trying to update things as best as possible. Particularly in the normative statements, but also to go around addressing smaller fixes to make it more readable Brent Zundel: Thank you, we know it is late/early where you are
Brent Zundel: The comments were around things in the spec that this PR isn't changing. Ted Thibodeau Jr.: I'm fine with spinning it out into a different issue - I just raised the comment there because that's when I noticed it - don't know how it slipped by in past readings. Brent Zundel: I think this is an important conversation to have, ties in with other issues. Kyle Den Hartog: To add to that, I think this is an indication that ... broader changes, decoupling the subject/holder binding issue... better to address separately. Brent Zundel: Ted, if you would open a new issue... Ted Thibodeau Jr.: I'll spin one up now. |
|
If people are satisfied with the recent changes can we get some re-approvals on here? If not, please leave some suggestions and I'll plan on getting this updated before the call this week. |
Co-authored-by: Ted Thibodeau Jr <tthibodeau@openlinksw.com>
|
I think it would be best to use "needs to" or some other non normative word
choice, rather than add apossibly untestable normative statement.
…On Tue, Sep 28, 2021, 18:51 Kyle Den Hartog ***@***.***> wrote:
***@***.**** commented on this pull request.
------------------------------
In index.html
<#818 (comment)>:
> </p>
<p>
-To use zero-knowledge <a>verifiable credentials</a> the <a>issuer</a> must
-issue a <a>verifiable credential</a> in a manner that enables the <a>holder</a>
-to present the information to a <a>verifier</a> in a privacy-enhancing manner.
+For a <a>holder</a> to use a zero-knowledge <a>verifiable presentation</a>,
+the <a>issuer</a> must have issued a <a>verifiable credential</a> in a manner
@dlongley <https://github.com/dlongley> @brentzundel
<https://github.com/brentzundel> thoughts on this change? I'm pretty sure
it's testable (test if a credential can be derived), but not sure if we
want this in here.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#818 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/ACPFKP5GJQKFSKEC5U2T5N3UEJPJBANCNFSM5DYMIMDQ>
.
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>.
|
Co-authored-by: Ted Thibodeau Jr <tthibodeau@openlinksw.com>
|
Normative and substantive, multiple reviews, changes requested and made, no objections, merging. |
|
There's a linked issue with the Errata label, removing the Errata labels from the PR |
This PR is intended to be a first cut attempt to address the concerns raised in #726 in a way that generalizes the normative language in the ZKP section of the spec. I've attempted to keep all aspects of CL-Signatures system within the scope so that it's not going to exclude the usage of that system, while also trying to call out the more generic patterns of ZKP systems that are shared by BBS+-Sigs and CL-Sigs.
@brentzundel definitely looking to get your eyes across this soon so that we can hopefully get this in within the allotted time of the charter.
Also worth calling out that because I referenced the LDP-REGISTRY here this PR won't reference the Biblio section properly until #801 is merged onto V1.1 and I can rebase those changes in here. I intentionally left the Biblio portion out and didn't build on #801 in order to keep this PR focused on the content for now. Once we get that other PR through the link should work properly.
Preview | Diff