incorp @Andrei-Popov's comments - thx!

Author: JeffH

draft-ietf-tokbind-https-09.xml

@@ -392,10 +392,11 @@
         <t>The scoping of Token Binding key pairs generated by Web browsers for use in 
         first-party and federation use cases defined in this 
         specification (<xref target="federation"/>, below), and intended for 
-        binding HTTP cookies, MUST be at the 
-        granularity of "effective top-level domain (public suffix) + 1" (eTLD+1).
+        binding HTTP cookies, MUST be no wider than the 
+        granularity of "effective top-level domain (public suffix) + 1" (eTLD+1). 
           I.e., at the same granularity at which cookies can be set 
-          (see <xref target="RFC6265"/>).</t> 
+          (see <xref target="RFC6265"/>).
+          Though, this scoping MAY be more narrow if cookies are scoped more narrowly.</t> 
 
         <t>Key pairs used to bind other application
           tokens, such as OAuth tokens or Open ID Connect "ID Tokens", SHOULD generally
@@ -485,7 +486,8 @@
 	connection between the client and the Relying Party, thus
 	ensuring that only said client can use the identity token; the
 	Relying Party will compare the Token Binding ID (or a cryptographic 
-	hash of it) in the identity token with the Token Binding ID of the 
+	hash of it) in the identity token with the Token Binding ID (or a hash
+	thereof) of the 
 	TLS connection between it and the client.</t>
 	<t>This is an example of a federation scenario, which more
 	generally can be described as follows:
@@ -968,7 +970,7 @@ contexts. Other approaches are possible, but are outside the scope of this speci
           the man-in-the-middle controls the redirect URL and can tamper with
           any redirect URL issued by the Token Consumer (as well as with any
           Javascript running in the origin of the Token Consumer). The goal of
-          the man-in-the-middle is to trick the Token Provider to issuing a token
+          the man-in-the-middle is to trick the Token Provider into issuing a token
           bound to its Token Binding ID, not to
           the Token Binding ID of the legitimate client. To thwart this goal
           of the man-in-the-middle, the client's referred Token Binding ID