diff --git a/README.md b/README.md
index e6f0e30ab..6faaa9976 100644
--- a/README.md
+++ b/README.md
@@ -29,3 +29,33 @@ mailing list as well.
 
 ### Other useful links
 * [Public group email archive](https://lists.w3.org/Archives/Public/public-vc-wg/)
+
+## Process Overview for VC Data Model Pull Requests
+1. For now, we will focus only on merging new errata PRs into this repository,
+but encourage activity related to new features.
+2. Once a PR is opened, chairs and editors make judgement call on whether
+changes are substantive or editorial.
+<dl>
+  <dt>Editorial</dt>
+  <dd>Mark with "editorial" tag, merge into branch "v1.1"</dd>
+  <dt>Substantive</dt>
+  <dd>Mark with "substantial" tag. Bugfixes are merged into separate branch "v1.2". New Features stay around as an open PR.</dd>
+</dl>
+3. W3C CCG is notified of PRs that will be merged in the next 14 days if there
+are no objections.
+4. When it's determined a new reccomendation should go out, the W3C Verifiable
+Credentials Working Group members meet, review all the PRs that have been
+merged, and make a formal recommendation if agreement is reached.
+
+### Roadmap for 2021
+- 1 editorial update (v1.1?)
+- 1 substantive update (v1.2?)
+- VC Test Suite Refactoring
+- Start planning VC v2 Work, request a rechartering 3-6 months before end of
+  year to keep VC WG functioning.
+
+### Focus areas
+- [v1] Fixing a specific bug
+- [v1] Update examples in the spec to make them modern
+- [v2] VC `@context` needs updating, possibly with security vocab modularized
+  into smaller components instead of all included into a large context file.
diff --git a/index.html b/index.html
index eb967034d..31b83fff3 100644
--- a/index.html
+++ b/index.html
@@ -335,6 +335,9 @@ <h3>Ecosystem Overview</h3>
 A role an <a>entity</a> might perform by possessing one or more
 <a>verifiable credentials</a> and generating <a>verifiable presentations</a>
 from them. Example holders include students, employees, and customers.
+Issuers can bind a <a>verifiable credential</a> to the holder to which it is issued,
+and the holder can prove that binding using the <code>proof</code> property of a 
+<a>verifiable presentation</a>.
           </dd>
           <dt><a>issuer</a></dt>
           <dd>
@@ -445,6 +448,10 @@ <h3>Use Cases and Requirements</h3>
 <a>verifiable presentation</a>.
           </li>
           <li>
+<a>Verifiable credentials</a> are sometimes associated by the <a>issuer</a> with
+a specific <a>holder</a> at issuance time.
+          </li>           
+          <li>
 <a>Issuers</a> can issue <a>verifiable credentials</a> about any <a>subject</a>.
           </li>
           <li>
@@ -1032,7 +1039,15 @@ <h3>Concrete Lifecycle Example</h3>
   }
 }
         </pre>
-
+        <p>
+In this example, the <a>issuer</a> has bound the <a>verifiable credential</a> to
+the <a>holder</a> (Pat) using the
+<code>credentialSubject.id</code> property (rather than using the
+<code>holder.id</code> property). The second <code>proof</code> property in the
+<a>verifiable presentation</a> (with <code>proofPurpose</code> of
+<code>"authentication"</code>) is used by Pat to prove their relationship to the
+<a>credentialSubject.id</a> and thus, that they are the intended <a>holder</a>.
+        </p> 
         <p class="note">
 Implementers that are interested in understanding more about the
 <code>proof</code> mechanism used above can learn more in
@@ -1946,9 +1961,13 @@ <h3>Presentations</h3>
           </dd>
           <dt><var>proof</var></dt>
           <dd>
-If present, the value of the <code>proof</code> <a>property</a> ensures that
-the <a>presentation</a> is <a>verifiable</a>. For details related to the use of
-this property, see Section <a href="#proofs-signatures"></a>.
+If present, the value of the <code>proof</code> <a>property</a> ensures that the
+<a>presentation</a> is <a>verifiable</a>. Where the issuer has bound the
+<a>verifiable credential</a> being presented to a specific <a>holder</a>, the
+<code>proof</code> <a>property</a>
+contains <a>verifiable</a> data to prove the indicated <a>holder</a> is
+presenting the proof. For details related to the use of this property, see
+Section <a href="#proofs-signatures"></a>.
           </dd>
         </dl>
 
@@ -2070,6 +2089,10 @@ <h3>Lifecycle Details</h3>
 any other actions involving a <a>credential</a>.
           </li>
           <li>
+In some cases, a <a>holder</a> might transfer to another <a>holder</a> one or more of its
+<a>verifiable credentials</a> that have not been bound by the <a>issuer</a> to that <a>holder</a>.
+          </li>
+          <li>
 A <a>holder</a> might <dfn data-lt="transfers">transfer</dfn> one or more of
 its <a>verifiable credentials</a> to another <a>holder</a>.
           </li>
@@ -2187,6 +2210,13 @@ <h2>Trust Model</h2>
 <a>entities</a>.
           </li>
           <li>
+In many cases, the <a>verifier</a> trusts the <a>issuer</a> to issue each
+<a>verifiable credential</a> to its intended <a>holder</a> (often the
+<a>subject</a>) and, where appropriate, to provide a <a>verifiable</a> binding
+in the
+<a>verifiable credential</a> to that <a>holder</a>.
+          </li>
+          <li>
 The <a>holder</a> and <a>verifier</a> trust the <a>issuer</a> to issue
 true (that is, not false) <a>credentials</a> about the <a>subject</a>, and to
 revoke them quickly when appropriate.
@@ -2931,7 +2961,7 @@ <h3>Zero-Knowledge Proofs</h3>
           <li>
 Combine multiple <a>verifiable credentials</a> from multiple <a>issuers</a> into
 a single <a>verifiable presentation</a> without revealing
-<a>verifiable credential</a> or <a>subject</a> identifiers to the
+<a>verifiable credential</a> or <a>holder</a> identifiers to the
 <a>verifier</a>. This makes it more difficult for the <a>verifier</a> to collude
 with any of the issuers regarding the issued <a>verifiable credentials</a>.
           </li>
@@ -3970,9 +4000,11 @@ <h3>Identifier-Based Correlation</h3>
 
       <p>
 <a>Subjects</a> of <a>verifiable credentials</a> are identified using the
-<code>credential.credentialSubject.id</code> field. The identifiers used to
-identify a <a>subject</a> create a greater risk of correlation when the
-identifiers are long-lived or used across more than one web domain.
+<code>credential.credentialSubject.id</code> field. <a>Holders</a> of
+<a>verifiable credentials</a> are identified using the
+<code>credential.holder.id</code> field. The identifiers used to identify a
+<a>subject</a> and/or <a>holder</a> create a greater risk of correlation when
+the identifiers are long-lived or used across more than one web domain.
       </p>
 
       <p>
@@ -4035,10 +4067,10 @@ <h3>Signature-Based Correlation</h3>
       <h3>Long-Lived Identifier-Based Correlation</h3>
 
       <p>
-<a>Verifiable credentials</a> might contain long-lived identifiers that could
-be used to correlate individuals. These types of identifiers include
-<a>subject</a> identifiers, email addresses, government-issued identifiers,
-organization-issued identifiers, addresses, healthcare vitals,
+<a>Verifiable credentials</a> might contain long-lived identifiers that could be
+used to correlate individuals. These types of identifiers include
+<a>subject</a> and <a>holder</a> identifiers, email addresses, government-issued
+identifiers, organization-issued identifiers, addresses, healthcare vitals,
 <a>verifiable credential</a>-specific JSON-LD contexts, and many other sorts of
 long-lived identifiers.
       </p>
@@ -4181,9 +4213,8 @@ <h3>Bearer Credentials</h3>
 
       <p>
 <a>Verifiable credentials</a> that are <a>bearer credentials</a> are made
-possible by not specifying the <a>subject</a> identifier, expressed using the
-<code>id</code> <a>property</a>, which is nested in the
-<code>credentialSubject</code> <a>property</a>. For example, the following
+possible by not specifying either the <code>credentialSubject.id</code> or
+<code>holder.id</code> identifiers. For example, the following
 <a>verifiable credential</a> is a <a>bearer credential</a>:
       </p>
 
@@ -4405,8 +4436,8 @@ <h3>Usage Patterns</h3>
 <a>subject</a> across multiple <a>presentations</a> or <a>verifiers</a>. Even
 when different <a>credentials</a> are presented, if the <a>subject</a>
 identifier is the same, <a>verifiers</a> (and those with access to
-<a>verifier</a> logs) could infer that the <a>holder</a> of the
-<a>credential</a> is the same person.
+<a>verifier</a> logs) could infer that the <a>subject</a> of the
+<a>credential</a> is the same person. Likewise for <a>holder</a> identifiers.
         </li>
         <li>
 The underlying information in a <a>credential</a> can be used to identify an
@@ -4435,8 +4466,8 @@ <h3>Usage Patterns</h3>
 
       <ul>
         <li>
-Using a globally-unique identifier as the <a>subject</a> for any given
-<a>credential</a> and never re-use that <a>credential</a>.
+Using a globally-unique identifier as the <a>subject</a> and/or <a>holder</a>
+for any given <a>credential</a>, and never re-using that <a>credential</a>.
         </li>
         <li>
 If the <a>credential</a> supports revocation, using a globally-distributed
@@ -5026,19 +5057,23 @@ <h2>Validation</h2>
       </p>
 
       <section class="informative">
-        <h3>Credential Subject</h3>
+        <h3>Holder</h3>
 
         <p>
-In the <a>verifiable credentials</a> presented by a <a>holder</a>, the value
-associated with the <code>id</code> <a>property</a> for each
-<code>credentialSubject</code> is expected to identify a <a>subject</a> to the
-<a>verifier</a>. If the <a>holder</a> is also the <a>subject</a>, then
-the <a>verifier</a> could authenticate the <a>holder</a> if they have
-public key metadata related to the <a>holder</a>. The <a>verifier</a> could then
-authenticate the <a>holder</a> using a signature generated by the <a>holder</a>
-contained in the <a>verifiable presentation</a>. The <code>id</code>
-<a>property</a> is optional. <a>Verifiers</a> could use other <a>properties</a>
-in a <a>verifiable credential</a> to uniquely identify a <a>subject</a>.
+An <a>issuer</a> may indicate that a <a>verifiable credential</a> has been
+issued to a specific <a>holder</a> using the <code>holder</code>
+<a>property</a>. Alternatively, when the <a>holder</a> is the <a>subject</a>,
+the <code>credentialSubject.id</code> <a>property</a> could be used for the same
+purpose, ideally paired with the <code>nonTransferable</code> <a>property</a>.
+When such <a>verifiable credentials</a> are used to produce a <a>verifiable
+presentation</a>, the
+<a>verifier</a> may authenticate the <a>holder</a> (or holder <a>subject</a>)
+using a <a>holder</a>-generated signature in the <code>proof</code> <a>property</a> of
+the <a>verifiable presentation</a>.
+
+Where there is no <a>issuer</a>-designated <a>holder</a> the <a>verifiable
+credential</a> can be transferred to other <a>holders</a>, and no <a>holder</a>
+authentication is necessary by the <a>verifier</a>.
         </p>
 
         <p class="note">
@@ -5049,6 +5084,20 @@ <h3>Credential Subject</h3>
 
       </section>
 
+      <section class="informative">
+        <h3>Credential Subject</h3>
+
+        <p>
+In the <a>verifiable credentials</a> presented by a <a>holder</a>, the value
+associated with the <code>id</code> property for each
+<code>credentialSubject</code> is expected to identify a <a>subject</a> to the
+<a>verifier</a>. The <code>id</code> property is optional. <a>Verifiers</a>
+could use other properties in a <a>verifiable credential</a> to uniquely
+identify a subject.
+        </p>
+
+      </section>
+
       <section class="informative">
         <h3>Issuer</h3>