Add section on privacy considerations for replay protection

draft-ietf-rats-eat.md

@@ -2018,6 +2018,21 @@ Implementers should consider laws and regulations governing the transmission of
 Implementers should consider using location management facilities offered by the operating system on the entity generating the attestation.
 For example, many mobile phones prompt the user for permission when before sending location data.
 
+## Replay Protection and Privacy (#replayprivacyconsiderations)
+
+EAT offers 2 primary mechanisms for token replay protection (also sometimes
+known as token "freshness"):  the cti/jti claim and the nonce claim.  The cti/jti claim
+in a CWT/JWT is a field that may be optionally included in the EAT and is in general
+derived on the same device in which the entity is instantiated.  The nonce claim is based
+on a value that is usually derived remotely (outside of the entity).  These claims can be used
+to extract and convey personally-identifying information either inadvertently or by intention.  For instance,
+an implementor may choose a cti that is equivalent to a username associated with the device (e.g., account
+login).  If the token is inspected by a 3rd-party then this information could be used to identify the source
+of the token or an account associated with the token (e.g., if the account name is used to derive the nonce).  In order
+to avoid the conveyance of privacy-related information in either the cti/jti or nonce claims, these fields
+should be derived using a salt that originates from a true and reliable random number generator or any other
+source of randomness that would still meet the target system requirements for replay protection.
+
 # Security Considerations {#securitycons}
 
 The security considerations provided in Section 8 of {{RFC8392}} and Section 11