diff --git a/README.org b/README.org
index 523654c..832301c 100644
--- a/README.org
+++ b/README.org
@@ -60,8 +60,12 @@ not specified:
 #     "clean agreement" on how to attach signatures *to* posts yet.
 #   - authorization is not specified
 
- - Authentication is not specified.  Authentication is important to
-   verify "did this entity really say this thing".[fn:did-you-say-it]
+ - Identity verification is not specified.
+   ("Identity verification" is the same as "authentication", but since
+   "authentication" sounds confusingly too similar to "authorization",
+   we are not generally using that term in this document.)
+   Identify verification is important to verify "did this entity
+   really say this thing".[fn:did-you-say-it]
    However, the community has mostly converged on using [[https://tools.ietf.org/html/draft-cavage-http-signatures-11][HTTP Signatures]]
    to sign requests when delivering posts to other users.
    The advantage of HTTP Signatures is that they are extremely simple
@@ -76,20 +80,19 @@ not specified:
    all users have a library for in their language, so Linked Data Proofs
    have not as of yet caught on as popularly as HTTP Signatures.
 
- - Authorization is also not specified.  (Authentication and
-   authorization are frequently confused (especially because in
-   English, the words are so similar) but mean two very different
-   things: the former is checking who said/did a thing, the latter is
-   checking whether they are allowed to do a thing.)  As of right now,
-   authorization tends to be extremely ad-hoc in ActivityPub systems,
-   sometimes as ad-hoc as unspecified heuristics from tracking who
-   received messages previously, who sent a message the first time,
-   and so on.  The primary way this is worked around is sadly that
+ - Authorization is also not specified.
+   As of right now, authorization tends to be extremely ad-hoc in
+   ActivityPub systems, sometimes as ad-hoc as unspecified heuristics
+   from tracking who received messages previously, who sent a message
+   the first time, and so on.
+   The primary way this is worked around is sadly that
    interactions which require richer authorization simply have not
    been rolled out onto the ActivityPub network.
 
 Compounding this situation is the general confusion/belief that
-authorization must stem from authentication.
+authorization must stem from identity verification (again, partly
+because "authentication" is often used for "identity verification",
+and that term /sounds/ in English too similar to "authorization").
 This document aims to show that not only is this not true, it is also
 a dangerous assumption with unintended consequences.
 An alternative approach based on "object capabilities" is
@@ -544,12 +547,12 @@ In no way do Access Control Lists follow the
 to be able to sensibly trust their computing systems in this modern
 age.
 
-To be sure, we need authentication when it is important to know that a
-certain entity "said a particular thing", but it is important to
-understand that this is not the same as knowing whether a particular
-entity "can do a certain thing".
+To be sure, we need identity verification when it is important to know
+that a certain entity "said a particular thing", but it is important
+to understand that this is not the same as knowing whether a
+particular entity "can do a certain thing".
 
-Mixing up authentication with authorization is how we get ACLs,
+Mixing up identity verification with authorization is how we get ACLs,
 and ACLs have serious problems.
 
 For instance, consider that Solitaire (Solitaire!) can steal all your