Update EIP-4973: Define initial criteria of a privacy considerations section

EIPS/eip-4973.md

@@ -185,7 +185,25 @@ You can find an implementation of this standard in [../assets/eip-4973](../asset
 
 ## Security Considerations
 
-There are no security considerations related directly to the implementation of this standard.
+### Privacy Considerations
+
+#### Storing Personally Identifiable Information (PII) on-chain presents privacy risks
+
+Data stored within an account-bound token often times are claims which are directly associated with an account. In general, it's a privacy concern to directly store PII related to a person on-chain or to link data directly to an identifier like an Ethereum account. Doing so would make it impossible for a user to invoke their right to be forgotten which is necessary under GDPR and could place dApp developers under scrutiny if they do so. Even in the case where data is generally regarded as public knowledge, public attributes contained in an account-bound token shouldn't be published on chain as this can lead unexpected behavior that could leak user behavior or insights which can be used to later harm the controller of the account. Instead, dApp developers should consider providing an opaque URL to an off chain storage solution so that the data is not published immutably on chain so that the claim can either be updated, refuted, or forgotten in compliance with GDPR. 
+
+Additionally, the data contained in the off-chain storage provider requires some sort of costs in order to store the data and as such storage providers that are storing these account bound tokens may be incentivized to store this data on behalf of users for free in exchange for the right to process this data. In general, this practice is likely deceptive in nature and should be discouraged. Instead dApp developers issuing account bound tokens should look to encrypt this data at rest. It's recommended that the keys used to perform this are derived or managed by the controller of the ethereum account that the account bound token is being issued to rather than the issuer themselves.
+
+#### Requiring authorization of data before releasing it to third-party providers
+
+Furthermore, the off chain storage solution should perform a consent check which has been authorized by the controller of the account before revealing the data to a third party data processor. This check should perform some basic authorization checks which ensure that the controller of the account has authorized the third party data processor access to the data.
+
+#### Identifier-based correlation of attributes stored in various account-bound tokens
+
+Since account based tokens shared a strongly correlating identifier, the ethereum account, dApp developers should be aware of the correlation that's incurred by issuing attributes to the same ethereum account even if they are not all within the same account bound token. Multiple account bound tokens that are linked to the same long lived ethereum identifier will enable the possibility that behavioral data (e.g. commonly visiting a location if multiple location credentials are linked to the ethereum account) or inferential data (inferring a users time zone based on when they commonly use their ethereum account) can be used to deduce further correlation of a user in a way that the user did not consent to. In order to prevent these concerns, dApp developers should leverage the techniques of data minimization so that only the minimal necessary information is included in the account bound token.
+
+#### Validity of account bound tokens for data processors
+
+Due to the inherent nature of the claims made in a particular attribute of an account bound token, it should not be assumed that the account bound token is considered valid or authentic unless the data processor trusts the issuer and their processes for validating the data of the account bound token. Data processors are encouraged to reject account bound tokens that produce privacy violations or that enable bad privacy practices based on the reputation of the issuer of the account bound token.
 
 ## Copyright