addressing Andrew's comment

Author: BasileiosKal

draft-irtf-cfrg-bbs-signatures.md

@@ -1675,7 +1675,7 @@ The following sections will describe possible privacy threats, resulting from su
 
 ## Header and Presentation Header
 
-As mentioned in Section (#header-and-presentation-header), the `header` value is chosen by the Signer and bound to a BBS Signature and proof. Consequently, it must be revealed to the Verifier, together with a BBS proof. If that `header` value is chosen to have high entropy (i.e., unique per credentiak, Prover or small group of Provers), it can be used as a correlation vector to trace and link together all BBS proofs made by a signature bound to that `header` value. This will result to significantly worst privacy guarantees, by allowing adveraries to trace and link together all generated proofs bound to that `header` value (for example, if a random `header` is used during each BBS signature generation, adversaries will be able to link and trace the BBS proofs generated from that signature). The Issuer MUST choose a low entropy `header` value and it MUST be the same for a large number of users (Provers). Acceptable values include an application identifier, a country identifier etc.. Unacceptable values include random values, high cardinality expiration dates, the Prover's email address etc..
+As mentioned in Section (#header-and-presentation-header), the `header` value is chosen by the Signer and bound to a BBS Signature and proof. Consequently, it must be revealed to the Verifier, together with a BBS proof. If that `header` value is chosen to have high entropy (i.e., unique per credential, Prover or small group of Provers), it can be used as a correlation vector to trace and link together all BBS proofs made by a signature bound to that `header` value. This will result to significantly worst privacy guarantees, by allowing adversaries to trace and link together all generated proofs bound to that `header` value (for example, if a random `header` is used during each BBS signature generation, adversaries will be able to link and trace the BBS proofs generated from that signature). The Issuer MUST choose a low entropy `header` value and it MUST be the same for a large number of users (Provers). Acceptable values include an application identifier, a country identifier etc.. Unacceptable values include random values, high cardinality expiration dates, the Prover's email address etc..
 
 On the other hand, the misuse of a `presentation_header`, chosen by the Prover and only bound to a BBS proof, does not incur as many privacy risks as the `header` value. For example, since a new `presentation_header` can be chosen each time a BBS proof is generated, random values are a viable choice. Still, to not break the unlinkability property, care must be taken that the `presentation_header` does not identify a single or small group of Provers. Acceptable values include random octet strings (possibly received from the Verifier, prior to the generation of the BBS proof), or more generally, any message the Prover may want to protect its integrity when presenting a BBS proof (note that the `presentation_header` value, when used, can be considered as "signed" by the Prover). Unacceptable values include the Prover's phone number, their complete physical address, their date of their birth etc..