Ambiguity of "holder" makes the spec inconsistent

[RieksJ]

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:

1. the IT component that possesses credentials, but NOT the person that possesses this IT component;
2. the person that possesses the IT component that possesses credentials, but NOT that IT component itself;
3. both the IT component and the person that possesses it.

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.

[swcurran]

We discussed this on the 2022-11-21 AnonCreds Specification Working Group Meeting and decided on the following:

• The term holder in the specification refers to the holder "IT Component" as defined by @RieksJ above. That is how it is used in the vast majority of the paper. That will be clarified in the definition of holder. That there is a controlling entity that operates the holder will be included in the definition.
• In the few places in the specification where the term holder has mistakenly been used to reference the entity that controls the holder, the text will be clarified.
• We don't plan to introduce a formal new term for the controlling entity that operates the holder since it is not used enough in the specification.
• This same clarification applies to the issuer and verifier.

[RieksJ]

Please also examine any use of the term holder and make sure it is used as intended. For example, the definition of this term states "In many use cases, the holder is also the identity subject." This is certainly no longer true for holders that are IT components, and hence will need to be changed.

Similarly, occurrences of issuer and verifier will need to be checked and changed as appropriate

[swcurran]

That is the intention.

[swcurran]

Updated the “holder” terminology in #193 and added the check for wording in the rest of the spec. to the finalization checklist #175 . Closing this issue.

[swcurran]

The submitter has requested the reopening of the issue.