Rewrite authentication section; fix #2, fix #3.

index.html

@@ -1583,33 +1583,70 @@ <h2>
       </h2>
 
       <p>
-Authentication is the mechanism by which <a>DID controllers</a> can
-cryptographically prove that they are associated with a <a>DID</a>. For more
-information, see Section <a href="#binding-of-identity"></a>. 
+Authentication is a mechanism by which a <a>DID method</a> can establish
+the authority of the party attempting to authenticate. The
+<em>verifier</em> of an authentication attempt can check if the
+authenticating party is presenting a valid proof of authentication, that is,
+that they are who they say they are.
       </p>
 
-      <p class="note">
-Authentication is separate from authorization because <a>DID controllers</a>
-might wish to enable others to update their <a>DID document</a> (for example, to
-assist with key recovery, as discussed in Section
-<a href="#key-revocation-and-recovery"></a>) without enabling them to prove
-control (and thus be able to impersonate the <a>DID controller(s)</a>).
+      <p class="note" title="Uses of authentication">
+If authority is established, it is up to the <a>DID method</a> to decide
+what to do with that information. A particular <a>DID method</a> could
+decide that authenticating as a <a>DID controller</a> is sufficient to,
+for example, update or delete the <a>DID document</a>. Another <a>DID
+method</a> could require different keys, or a different verification method
+entirely, to be presented in order to update or delete the <a>DID document</a>
+than that used to authenticate. In other words, what is done <em>after</em>
+the authentication check is out of scope for the DID data model, but <a>DID
+methods</a> are expected to define this themselves.
       </p>
 
       <p>
 A <a>DID document</a> MAY include an <code>authentication</code> property.
       </p>
 
       <dl>
-        <dt><dfn>authentication</dfn></dt>
-        <dd>
-If a <a>DID document</a> includes an <code>authentication</code> property, the
-value of the property SHOULD be an array of verification methods. Each
-verification method MAY be embedded or referenced. An example verification
-method is a public key (see Section <a href="#public-keys"></a>).
-        </dd>
+          <dt><dfn>authentication</dfn></dt>
+          <dd>
+The <code>authentication</code> property is a relationship between the
+<a>DID subject</a> and a set of verification methods (such as, but not
+limited to, public keys). It means that the <a>DID subject</a> has authorized
+some set of <a>verification methods</a> (per the value of the
+<code>authentication</code> property) for the purpose of authentication. The value
+of the <code>authentication</code> property SHOULD be an array of
+<a>verification methods</a>. Each <a>verification method</a> MAY be embedded
+or referenced. An example of a <a>verification method</a> is a public key
+(see Section <a href="#public-keys"></a>).
+          </dd>
       </dl>
 
+      <p>
+This statement is useful to any "authentication verifier" that needs to check
+to see if an entity that is attempting to authenticate is, in fact, presenting
+a valid proof of authentication. When a verifier receives some data (in some
+protocol-specific format) that contains a proof that was made for the purpose
+of "authentication", and that says that an entity is identified by the <a>DID</a>,
+then that verifier checks to ensure that the proof can be verified using a
+<a>verification method</a> (e.g., public key) listed under
+<code>authentication</code> in the <a>DID Document</a>.
+      </p>
+
+      <p>
+The <a>verification method</a> indicated by the <code>authentication</code>
+property of a <a>DID document</a> can only be used to authenticate the
+<a>DID subject</a>. To authenticate the <a>DID controller</a> (in cases
+where the <a>DID controller</a> is not <em>also</em> the <a>DID subject</a>)
+the entity associated with the value of <code>controller</code> (see
+Section <a href="#authorization-and-delegation"></a>) needs to
+authenticate itself with its <em>own</em> <a>DID document</a> and attached
+<code>authentication</code> <a>verification method</a> relationship.
+      </p>
+
+      <p>
+Example:
+      </p>
+
       <pre class="example nohighlight" title="Authentication field containing three verification methods">
 {
   "@context": "https://www.w3.org/ns/did/v1",
@@ -1647,13 +1684,12 @@ <h2>
 on their behalf.
       </p>
 
-      <p class="note">
-Authorization is separate from authentication, as explained in
-Section <a href="#authentication"></a>. This is particularly important for key
-recovery, in the case of key loss, when the subject no longer has
-access to their keys, or key compromise, where the <a>DID controller</a>'s
-trusted third parties need to override malicious activity by an attacker. For
-more information, see Section <a href="#security-considerations"></a>.
+      <p class="note" title="Authorization vs authentication">
+Note that Authorization is separate from <a href="#authentication"></a>.
+This is particularly important for key recovery in the case of key loss,
+when the subject no longer has access to their keys, or key compromise,
+where the <a>DID controller</a>'s trusted third parties need to override
+malicious activity by an attacker. See Section <a href="#security-considerations"></a>.
       </p>
 
       <p>
@@ -2258,6 +2294,22 @@ <h2>
 such as update or deactivate, MUST clearly state these limitations.
       </p>
 
+      <p>
+Determining the authority of a party to carry out the operations is method-specific.
+For example, a <a>DID method</a> MAY:
+      </p>
+      <ul>
+        <li>
+use the <a>verification methods</a> listed under <a>authentication</a> to decide whether an update/deactivate operation is allowed; or
+        </li>
+        <li>
+use other constructs in the <a>DID Document</a> to decide this; or
+        </li>
+        <li>
+not use the <a>DID Document</a> at all to decide this, but have rules that are are "built into" the method.
+        </li>
+      </ul>
+
       <section>
         <h3>
 Create