You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
A feature of interest that is part of AnonCreds V2 is called "domain proofs" or "per-verifier-id". The feature is that a verifier provides a consistent string to all holders during presentation, and a holder provides in the presentation a consistent identifier based on the string such that when they return and generate another presentation for the verifier, the verifier receives a the same identifier. Since all verifiers (should) use a different string, each verifier gets a different identifier from the holder, so unlinkability is retained.
The name "domain proof" comes (AFAIK) from the idea of the "consistent string" being the domain name of the verifier -- a string that is consistent and possibly linked to the verifier, and different from other verifiers. However, the string does not have to be a domain name.
In some use cases, the verifier might give a different string for a different presentation purpose. For example, it has been speculated that a voting system could be created by the holders receiving a "right to vote" credential, and the verifier using a different string for each purpose for voting (e.g., each election is a different purpose). The holders would create a presentation using their "right to vote" credential, and the resulting "domain proof" would be used detect multiple votes based on the same credential, with appropriate policy handling for how to count the votes (e.g., first counts, last counts, etc.).
The reason for this issue is mainly to describ the feature that is (per @mikelodder7) already part of AnonCreds V2, and to mention the following IETF draft spec. from Mattr Global about this concept in the core BBS+ Signatures specification:
A feature of interest that is part of AnonCreds V2 is called "domain proofs" or "per-verifier-id". The feature is that a verifier provides a consistent string to all holders during presentation, and a holder provides in the presentation a consistent identifier based on the string such that when they return and generate another presentation for the verifier, the verifier receives a the same identifier. Since all verifiers (should) use a different string, each verifier gets a different identifier from the holder, so unlinkability is retained.
The name "domain proof" comes (AFAIK) from the idea of the "consistent string" being the domain name of the verifier -- a string that is consistent and possibly linked to the verifier, and different from other verifiers. However, the string does not have to be a domain name.
In some use cases, the verifier might give a different string for a different presentation purpose. For example, it has been speculated that a voting system could be created by the holders receiving a "right to vote" credential, and the verifier using a different string for each purpose for voting (e.g., each election is a different purpose). The holders would create a presentation using their "right to vote" credential, and the resulting "domain proof" would be used detect multiple votes based on the same credential, with appropriate policy handling for how to count the votes (e.g., first counts, last counts, etc.).
The reason for this issue is mainly to describ the feature that is (per @mikelodder7) already part of AnonCreds V2, and to mention the following IETF draft spec. from Mattr Global about this concept in the core BBS+ Signatures specification:
https://basileioskal.github.io/bbs-per-verifier-id/draft-vasilis-bbs-per-verifier-linkability.html
The text was updated successfully, but these errors were encountered: