From c819a340d2ae2b97e95008a268347c3ef66a2a21 Mon Sep 17 00:00:00 2001
From: Adam Langley <agl@google.com>
Date: Thu, 16 Nov 2017 18:01:20 -0800
Subject: [PATCH] Addressing akshayku's comments on previous change.

---
 index.bs | 13 +++++--------
 1 file changed, 5 insertions(+), 8 deletions(-)

diff --git a/index.bs b/index.bs
index 66b0ac991..6157471dc 100644
--- a/index.bs
+++ b/index.bs
@@ -844,7 +844,7 @@ When this method is invoked, the user agent MUST execute the following algorithm
                     <dd>replace potentially identifying information (such as AAGUID and attestation certificates) 
                         in the [=attested credential data=] and [=attestation statement=] with blinded versions of the same data.</dd>
 
-                    <dt>If the value of |attestationPresentationPreference| is "verifiable",</dt>
+                    <dt>If the value of |attestationPresentationPreference| is "indirect",</dt>
                     <dd>potentially replace the attestation statement with a more privacy-friendly and/or more easily verifiable
                         version of the same data (for example, by employing a [=Privacy CA=]).</dd>
 
@@ -1570,15 +1570,12 @@ during credential generation.
       authenticator-generated attestation statements with attestation statements generated by a Privacy CA, in order to protect
       the privacy of the user, or to assist [=RPS=] with attestation verification in a heterogeneous ecosystem.
 
-      Note that there is no guarantee that the [=RP=] will obtain a verifiable attestation statement in this case. The authenticator
-      may use self-attestation, or the user may have opted out of relaying any kind of (identifying) attestation information to
-      the RP
+      Note that there is no guarantee that the [=RP=] will obtain a verifiable attestation statement in this case. (For
+      example, in the case that the authenticator uses self-attestation.)
     <li><dfn>direct</dfn> - indicates that the [=[RP]=] wants the attestation statement as generated by the authenticator. If
       the client returns an attestation statement to the RP in this case, it MUST be the statement generated by the authenticator.
-      Note that the user may opt out of relaying attestation information to the [=RP=], or the client might have
-      blacklisted certain types of authenticators for violating user privacy. If for whatever reason the client cannot pass on
-      the authenticator-generated attestation statement, it MUST terminate the credential generation operation with a
-      "{{NotAllowedError}}".
+      If, for whatever reason, the client cannot pass on the authenticator-generated attestation statement, it MUST terminate
+      the credential generation operation with a "{{NotAllowedError}}".
 </ul>