-
Notifications
You must be signed in to change notification settings - Fork 24
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Ambiguity of "holder" makes the spec inconsistent #100
Comments
We discussed this on the 2022-11-21 AnonCreds Specification Working Group Meeting and decided on the following:
|
Please also examine any use of the term Similarly, occurrences of |
That is the intention. |
The submitter has requested the reopening of the issue. |
The spec defines "holder" as: "an entity that is in possession of a credential. In many use cases, the holder is also the identity subject."
Since the term "entity" isn't explicitly defined, I take it to mean "anything that someone knows to exist". That seems fair enough, since if the authors of the definition of 'holder' would have intended a specific subclass/specialization of this very generic term, they could have easily done so.
An IT component (e.g. an app on a mobile phone) that possesses credentials satisfies this definition, and hence should be considered as a holder. However, the person that possesses that IT component also satisfies this definition, as 'possession' can be argued to be transitive (if X possesses Y, and Y possesses Z, then X possesses Z).
So which is what "holder" actually refers to:
It seems to me that [1] makes the most sense. After all, the spec is highly technical, and it is obvious that things like signing and other cryptographic functions can impossibly be performed by a human (without the IT component). But there is a problem, because the IT component is typically not the entity about which claims are made. That would be the person. The statement that in many cases the holder is also the (identity) subject would then obviously be very disputable, if not outright false. Other statements, such as "logical expressions, such as the holder being older than 18 without disclosing the value.", are hard to take seriously if this 'being older than 18' pertains to the IT component (rather than the person). Yet section recovery says: "The wallets for AnonCreds shall offer recovery mechanisms for the holders to export their keys and/or link secrets to different devices.", only makes sense under option [2].
From this, we might want to go for option [3]. It allows making statements such as "The Link Secret is an input that combines data from multiple Credentials to prove that the Credentials have a common subject (the Holder)". However, a statement like this is very problematic for verifiers, because they need to know whether the claims about the 'common subject (the Holder)' are about the IT component (the mobile app), or about the person that possesses that component.
This issue calls for clearly distinguishing between IT components that perform functions such as, but not limited to the issuing, holding and verifying of AnonCreds, and the parties (people, organizations) that are typically the subjects of such credentials, and that use such IT components for performing such functions.
Doing so will set the scene for the next, related discussion, which is about how a verifier would know that a particular IT component is operating on behalf of what party.
The text was updated successfully, but these errors were encountered: