Skip to content

Commit

Permalink
Fix/issue-325-markdowncleanup (#326)
Browse files Browse the repository at this point in the history 
* chore(markdown) Use plain latin characters for ' and " #325

* chore(markdown) Remove Unnecessary HTML markup #325

* chore(markdown) Replace <u> with normal text styling #325
  • Loading branch information
@skounis
skounis authored Nov 27, 2024
1 parent 9c6eb09 commit a617a94
Showing 1 changed file with 19 additions and 39 deletions.
58 changes: 19 additions & 39 deletions discussion-topics/a-privacy-risks-and-mitigations.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -35,11 +35,6 @@ collusion between Relying Parties or between a Relying Party and an
Attestation Provider:

<table>
<colgroup>
<col style="width: 31%" />
<col style="width: 14%" />
<col style="width: 53%" />
</colgroup>
<thead>
<tr>
<th><strong>Risk type </strong></th>
Expand All @@ -62,18 +57,15 @@ Attestation Provider:
</table>

<table>
<colgroup>
<col style="width: 100%" />
</colgroup>
<thead>
<tr>
<th><strong><u>R14. Surveillance</u></strong></th>
<th><strong>R14. Surveillance</strong></th>
</tr>
</thead>
<tbody>
<tr>
<td>Surveillance, or monitoring, is defined as the unauthorised tracking
or observation of a wallet user’s activities, communication, or data.
or observation of a wallet user's activities, communication, or data.
Surveillance is often related to inference, which is defined as the
deduction of sensitive or personal information from seemingly innocuous
data.</td>
Expand All @@ -82,18 +74,15 @@ data.</td>
</table>

<table>
<colgroup>
<col style="width: 100%" />
</colgroup>
<thead>
<tr>
<th><strong><u>SR1. Wholesale surveillance</u> </strong></th>
<th><strong>SR1. Wholesale surveillance </strong></th>
</tr>
</thead>
<tbody>
<tr>
<td>Wholesale surveillance is defined as the tracking or observation of
the activities of many users through their wallet’s communication or
the activities of many users through their wallet's communication or
data. Wholesale surveillance is often associated with surveillance (R14)
and inference at a global scale, where information about many users is
combined to deduce sensitive or personal data about users or to identify
Expand All @@ -106,11 +95,6 @@ More specifically, \[RiskRegister\] describes the following threats to a
Wallet:

<table style="width:100%;">
<colgroup>
<col style="width: 13%" />
<col style="width: 51%" />
<col style="width: 35%" />
</colgroup>
<thead>
<tr>
<th><strong>ID<br />
Expand Down Expand Up @@ -154,15 +138,15 @@ required.</td>

### 1.3. Key words

This document uses the capitalized key words ‘SHALL’, ‘SHOULD’ and ‘MAY’
This document uses the capitalized key words 'SHALL', 'SHOULD' and 'MAY'
as specified in RFC 2119, i.e., to indicate requirements,
recommendations and options specified in this document.

In addition, ‘must’ (non-capitalized) is used to indicate an external
In addition, 'must' (non-capitalized) is used to indicate an external
constraint, i.e., a requirement that is not mandated by this document,
but, for instance, by an external document such as \[ARF\]. The word
‘can’ indicates a capability, whereas other words, such as ‘will’, and
‘is’ or ‘are’ are intended as statements of fact.
'can' indicates a capability, whereas other words, such as 'will', and
'is' or 'are' are intended as statements of fact.

### 1.4. Document structure

Expand All @@ -187,11 +171,11 @@ This document is structured as follows:

This chapter describes in detail how the attestation formats currently
specified for use in the EUDI Wallet ecosystem could be misused for
tracking the User’s behaviour.
tracking the User's behaviour.

The attestation formats required to be supported in the ARF are
specified in ISO/IEC 18013-5 \[ISO18013-5\] and “SD-JWT-based Verifiable
Credentials (SD-JWT VC)” \[SD-JWT VC\]. Both of these formats enable
specified in ISO/IEC 18013-5 \[ISO18013-5\] and "SD-JWT-based Verifiable
Credentials (SD-JWT VC)" \[SD-JWT VC\]. Both of these formats enable
selective disclosure of attributes by making use of so-called
salted-attribute hashes. For more information on this technique, see
\[ETSI 119476\]. In a nutshell, the idea is that an Attestation Provider
Expand Down Expand Up @@ -326,7 +310,7 @@ presents one of the attributes of that attestation to a Relying Party,
the Attestation Provider must issue a new attestation. Otherwise, the
Wallet Unit will eventually run out of attestations. Please note that
this does not imply that the Provider must do so immediately, or that
the Provider is able to do so without requesting the User’s permission.
the Provider is able to do so without requesting the User's permission.
Different solutions can be thought of; for example, the Wallet Unit
could have a lower limit for the number of unused attestations it holds
and request a new set when the number of attestations goes below this
Expand All @@ -347,13 +331,13 @@ issued depends on the frequency of use. This has two effects:
spaced in time.

2. This method may mean imply unpredictability regarding the load on
the Attestation Provider’s systems. If a User uses their attestation
the Attestation Provider's systems. If a User uses their attestation
frequently, the Attestation Provider will have to issue many
attestations. On the flipside, if an attestation is seldomly used,
the Attestation Provider will have to issue very few attestations
per year. This is because the validity period of the attestation can
be chosen very long if an attestation is presented at most once
anyway, without negative effects to the User’s privacy.
anyway, without negative effects to the User's privacy.

The operational costs of issuing an attestation are determined to some
extent by the requirement that, for security reasons, the Wallet Unit
Expand Down Expand Up @@ -405,7 +389,7 @@ privacy is.
A third approach, finally, is where the Attestation Provider issues
attestations in batches. A Wallet Units receives such a batch and uses
these alternatingly in a random order, until it has used all
attestations in the batch once. Then it ‘resets’ the batch and starts
attestations in the batch once. Then it 'resets' the batch and starts
using them again, again in a random order. A batch may consist, for
instance, of 20 attestations. If so, any attestation given will be
presented unpredictably in 5% of all transactions between a User and a
Expand All @@ -426,7 +410,7 @@ Also, the Attestation Provider must take a decision regarding batch
size, again balancing User privacy against load on their systems.

If a batch of attestations is used in a rotating fashion, the validity
period of an attestation can be longer without impacting the User’s
period of an attestation can be longer without impacting the User's
privacy. However, every time the attestations expire, the Provider will
need to issue a full batch of attestations, instead of just a single
one. This is regardless of whether all attestations in the batch have
Expand Down Expand Up @@ -469,7 +453,7 @@ attention should be given to this process.

To the maximum extent feasible given operational constraints, the
Attestation Provider should not be able to learn anything about the
User’s use of an attestation based upon interactions between Relying
User's use of an attestation based upon interactions between Relying
Parties and the Attestation Provider related to attestation revocation
checking.

Expand Down Expand Up @@ -518,7 +502,7 @@ integration, particularly focusing on defining specific requirements for
implementing ZKPs by using any type of WSCD/WSCA.

For further details, please see the 'Cryptographers' Feedback on the EU
Digital Identity’s ARF’
Digital Identity's ARF'
[(here)](https://github.com/eu-digital-identity-wallet/eudi-doc-architecture-and-reference-framework/issues/200),
and the Commission's response to it
[here.](https://github.com/eu-digital-identity-wallet/eudi-doc-architecture-and-reference-framework/discussions/211#discussioncomment-9882388)
Expand Down Expand Up @@ -574,10 +558,6 @@ stimulate discussion.
## 6. References

<table>
<colgroup>
<col style="width: 19%" />
<col style="width: 80%" />
</colgroup>
<thead>
<tr>
<th>Reference</th>
Expand Down Expand Up @@ -613,7 +593,7 @@ proofs applied to Electronic Attestation of Attributes, v1.2.1,
</tbody>
</table>

[1] This is called the ‘saw-tooth model’ in inventory management.
[1] This is called the 'saw-tooth model' in inventory management.

[2] Note that strict compliance to this recommendation would imply that
Relying Party Instances must always have locally available the latest
Expand Down

0 comments on commit a617a94

Please sign in to comment.