Skip to content
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

Add suggestion on how malicious issuers can be detected. #161

Merged
merged 4 commits into from
Apr 16, 2024
Merged
Changes from 1 commit
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
21 changes: 14 additions & 7 deletions index.html
Original file line number Diff line number Diff line change
Expand Up @@ -1167,15 +1167,22 @@ <h3>Malicious Issuers and Verifiers</h3>
tracking or sharing the presentation of particular credentials.
</p>
<p>
A malicious [=issuer=] might intentionally attack group privacy by creating a
unique status list per credential issued in order to establish a one-to-one mapping to track
when a [=verifier=] processes a specific credential. Similarly, they could establish
another a one-to-one mapping by using a different cryptographic key for every credential
issued that is tracked in a status list.
A malicious [=verifier=] might intentionally attack group privacy by sharing
information from presented credentials with a malicious [=issuer=]. This
sort of collusion is difficult to detect as it is typically performed in a
msporny marked this conversation as resolved.
Show resolved Hide resolved
secure communication channel between the [=issuer=] and the [=verifier=].
</p>
<p>
A malicious [=verifier=] might intentionally attack group privacy by sharing
information from presented credentials with a malicious [=issuer=].
A malicious [=issuer=] might intentionally attack group privacy by creating a
unique status list per credential issued in order to establish a one-to-one
msporny marked this conversation as resolved.
Show resolved Hide resolved
mapping to track when a [=verifier=] processes a specific credential. Similarly,
msporny marked this conversation as resolved.
Show resolved Hide resolved
they could establish another a one-to-one mapping by using a different
msporny marked this conversation as resolved.
Show resolved Hide resolved
cryptographic key for every credential issued that is tracked in a status list.
msporny marked this conversation as resolved.
Show resolved Hide resolved
This sort of collusion can be detected by [=holder=] software by detecting
if the global identifiers used within a [=verifiable credential=] are shared
by other credentials. [=Holders=] could then be warned when presenting a
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry but I do not follow this. Assuming most holders only get a single credential from each issuer then how is this possible? Furthermore even if they obtain multiple credentials from one issuer, then it is unlikely they will all have the same unique identifiers in them.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

An individual holder (a user of holder software) is not expected to be able to do this, but holder software (that services multiple holders) potentially could. As an example, holder software could offer an opt-in tool that could perform this analysis across multiple holders and report back its findings.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

And which users are going to trust holder software that is shared by multiple users and that scans the wallets of multiple users?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

And which users are going to trust holder software that is shared by multiple users and that scans the wallets of multiple users?

Most of them, I'd expect. Most people accept this kind of analysis from the most popular Web browsers, probably often without knowing it. Hopefully wallet providers will do better, especially when it is easier to provide alternatives (that don't do it at all) than it is to compete in the browser market.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are you saying that web browsers scan a user's PC and converse between themselves about the contents? (as this is the scenario that you are proposing for wallets). If so, it surprises me, as I was not aware of this.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@David-Chadwick, @dlongley — Please pick up this thread below, following the suggestions I first made based on the thread above and then modified based on reactions from @David-Chadwick

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@TallTed, the text below looks ok to me modulo the change from "unique" to "shared" ... I'll comment down there on that.

@David-Chadwick,

Are you saying that web browsers scan a user's PC and converse between themselves about the contents?

I'm not implying anything as specific as "scan a user's PC", but rather, that some Web browsers (and some search engines) collect information based on your behavior and various inputs, aggregate it with information from other users, and send it somewhere for analysis, yes.

[=verifiable credential=] that contains global identifiers that are unique to
that credential.
msporny marked this conversation as resolved.
Show resolved Hide resolved
</p>
</section>

Expand Down
Loading