Fix a typo, small changes to wording.

clients/Introduction-Client.md

@@ -104,12 +104,12 @@ There is no assurance of confidentiality with respect to the introducer, for any
 
 There is no assurance of integrity or authenticity with respect to the introducer, for any messages sent between the introducees via the introducer as part of this protocol. In particular, the introducer may carry out a **man-in-the-middle attack** against the introducees, by introducing each introducee to an identity controlled by the introducer. In this scenario the introducees will believe that they are communicating with each other via the introducer, when in fact they are communicating with identities controlled by the introducer. The introducer can replace the transport properties sent by the introducees with transport properties controlled by the introducer, so that after the introduction has been completed the introducees will continue to communicate with the introducer instead of with each other. This allows the man-in-the-middle attack to continue against all subsequent communication between the introducees.
 
-To carry out such an attack, the introducee must create two identities that are distinct from the identities of the introducees, and must include these identities in the initial request messages sent to the introducees.
+To carry out such an attack, the introducer must create two identities that are distinct from the identities of the introducees, and must include these identities in the initial request messages sent to the introducees.
 
-If the introducees meet in person at any time after the introduction has been completed, they can check that the introducer did not carry out a man-in-the-middle attack by comparing each other's identities with the identities received from the introducer.
+If the introducees meet in person at any time after the introduction has been completed, they can check that the introducer did not carry out a man-in-the-middle attack by comparing each other's identities with the identities they received from the introducer.
 
 The transport keys that the introducees derive during the introduction are used to ensure the confidentiality, integrity and authenticity of communication between the introducees after the introduction has been completed. To ensure the forward secrecy of this subsequent communication, the introducees must both delete their ephemeral private keys before using the transport keys.
 
-Each introducee can ensure that the transport keys are not used until the ephemeral private keys have been deleted by marking the transport keys as inactive (ie not eligible to be used for securing outgoing BTP streams) until either (a) the other introducee's activate message is received via the introducer and its MAC is validated, or (b) an incoming BTP stream secured with the transport keys in question is received.
+Each introducee can ensure that the transport keys are not used until both ephemeral private keys have been deleted by marking the transport keys as ineligible to be used for securing outgoing BTP streams until either (a) the other introducee's activate message has been received via the introducer and its MAC has been validated, or (b) an incoming BTP stream secured with the transport keys in question has been received.
 
 In the latter case, receipt of a stream secured with the transport keys indirectly indicates that the other introducee has received and validated this introducee's activate message and sent its own activate message, and thus the keys are safe to use, even though the other introducee's activate message may still be in transit.