diff --git a/draft-saxe-wimse-token-exchange-and-translation-protocol.md b/draft-saxe-wimse-token-exchange-and-translation-protocol.md
index ec877cf..055cf64 100644
--- a/draft-saxe-wimse-token-exchange-and-translation-protocol.md
+++ b/draft-saxe-wimse-token-exchange-and-translation-protocol.md
@@ -129,7 +129,7 @@ TODO - this draft does not define normative specs for translating from arbitrary
 An AS performing token exchange SHOULD ensure it is the intended audience of a token being exchanged, and a client (whether it is an OAuth client or a workload) performing an exchange is allowed to perform such operation.
 A value in the subject_token_type parameter MUST correspond to an actual token type provided in the subject_token parameter.
 These are simple countermeasures against replay attacks and various forms of misuse, especially in cases when an AS who issued a token and an AS performing exchanges reside in different security domains.
-Typically, self-contained tokens include the aud claim (an array of strings) representing their audience.
+Typically, self-contained tokens include the aud claim (an array of strings) representing their audience (other types of tokens provide other means for the same).
 An extra care SHOULD be taken for tokens that can be passed through the front channel, and tokens that do not explicitly define their type.
 Examples here would be OpenID Connect ID Token, and various assertions represented as JWTs.