Apply suggestions from code review

Co-Authored-By: Trishank Karthik Kuppusamy <[email protected]>

candidate-keyid-tap.md

@@ -119,7 +119,7 @@ to verify a signature more than once, they must additionally check that all keys
 applied to a signature threshold are unique. So, the specification should
 additionally require that "Clients MUST use each key only once during a given
 signature verification." During this de-duplication check, the client should use
-a standardized format for keys, like the [modulus and exponent for RSA](https://cryptography.io/en/latest/hazmat/primitives/asymmetric/rsa/#numbers)
+a standardized representation for keys, like the [modulus and exponent for RSA](https://cryptography.io/en/latest/hazmat/primitives/asymmetric/rsa/#numbers)
 or the [point and curve for ECC](https://cryptography.io/en/latest/hazmat/primitives/asymmetric/ec/#cryptography.hazmat.primitives.asymmetric.ec.EllipticCurvePublicNumbers).
 All metadata definitions would remain the same, but
 the client’s verification process would track keyids within each metadata file
@@ -136,7 +136,7 @@ signatures in A that list a keyid of K. This means that if another metadata file
 M delegates to A, it would be able to use the same keyid with a different key.
 However, clients must ensure that duplicate keys are not applied to the same
 signature threshold. To do so, they must additionally keep track of the keys
-used to verify a signature using a standardized format as discussed above. Once
+used to verify a signature using a standardized representation as discussed above. Once
 the signatures for A and B have been checked,
 the client no longer needs to store the keyid mapping listed in T. During the
 preorder depth-first search of targets metadata, the keyids from each targets