Add link to Use Cases doc, remove use cases section.

Co-authored-by: Ted Thibodeau Jr <[email protected]>

Author: brentzundel

index.html

@@ -259,10 +259,11 @@ <h2>Introduction</h2>
 An ecosystem where [=verifiable credentials=] and
 [=verifiable presentations=] are expected to be useful
         </li>
-        <li>
-The use cases and requirements that informed this specification.
-        </li>
       </ul>
+      <p>
+The use cases and requirements that informed this specification can be found
+in [[[VC-USE-CASES]]] [[?VC-USE-CASES]].
+      </p>
 
       <section class="informative">
         <h3>What is a Verifiable Credential?</h3>
@@ -427,166 +428,6 @@ <h3>Ecosystem Overview</h3>
         </p>
       </section>
 
-      <section class="informative">
-        <h3>Use Cases and Requirements</h3>
-
-        <p>
-The Verifiable Credentials Use Cases document [[VC-USE-CASES]] outlines a number
-of key topics that readers might find useful, including:
-        </p>
-
-        <ul>
-          <li>
-A more thorough explanation of the
-<a href="https://www.w3.org/TR/vc-use-cases/#user-roles">roles</a>
-introduced above
-          </li>
-          <li>
-The
-<a href="https://www.w3.org/TR/vc-use-cases/#user-needs">needs</a>
-identified in market verticals, such as education, finance, healthcare, retail,
-professional licensing, and government
-          </li>
-          <li>
-Common
-<a href="https://www.w3.org/TR/vc-use-cases/#user-tasks">tasks</a>
-performed by the roles in the ecosystem, as well as their associated
-requirements
-          </li>
-          <li>
-Common
-<a href="https://www.w3.org/TR/vc-use-cases/#user-sequences">sequences
-and flows</a> identified by the Working Group.
-          </li>
-        </ul>
-
-        <p>
-As a result of documenting and analyzing the use cases document, the following
-desirable ecosystem characteristics were identified for this specification:
-        </p>
-<!-- requirement list start -->
-        <ul>
-          <li>
-[=Verifiable credentials=] represent statements made by an [=issuer=] in
-a tamper-evident and privacy-respecting manner.
-          </li>
-          <li>
-[=Holders=] can assemble collections of [=verifiable credentials=] from
-different [=issuers=] into a single artifact, a [=verifiable presentation=].
-          </li>
-          <li>
-[=Issuers=] can issue [=verifiable credentials=] about any [=subject=].
-          </li>
-          <li>
-Acting as [=issuer=], [=holder=], or [=verifier=] requires neither
-registration nor approval by any authority, as the trust involved is bilateral
-between parties.
-          </li>
-          <li>
-[=Verifiable presentations=] allow any [=verifier=] to [=verify=] the
-authenticity of [=verifiable credentials=] from any [=issuer=].
-          </li>
-          <li>
-[=Holders=] can receive [=verifiable credentials=] from anyone.
-          </li>
-          <li>
-[=Holders=] can interact with any [=issuer=] and any [=verifier=]
-through any user agent.
-          </li>
-          <li>
-[=Holders=] can share [=verifiable presentations=], which can then be
-[=verified=] without revealing the identity of the [=verifier=] to the
-[=issuer=].
-          </li>
-          <li>
-[=Holders=] can store [=verifiable credentials=] in any location, without
-affecting their [=verifiability=] and without the [=issuer=] knowing
-anything about where they are stored or when they are accessed.
-          </li>
-          <li>
-[=Holders=] can present [=verifiable presentations=] to any
-[=verifier=] without affecting authenticity of the claims and without
-revealing that action to the [=issuer=].
-          </li>
-          <li>
-A [=verifier=] can [=verify=] [=verifiable presentations=] from any
-[=holder=], containing proofs of [=claims=] from any [=issuer=].
-          </li>
-          <li>
-[=Verification=] should not depend on direct interactions between
-[=issuers=] and [=verifiers=].
-          </li>
-          <li>
-[=Verification=] should not reveal the identity of the [=verifier=] to
-any [=issuer=].
-          </li>
-          <li>
-The specification must provide a means for [=issuers=] to issue
-[=verifiable credentials=] that support selective disclosure, without
-requiring all conformant software to support that feature.
-          </li>
-          <li>
-[=Issuers=] can issue [=verifiable credentials=] that support
-selective disclosure.
-          </li>
-          <li>
-If a single [=verifiable credential=] supports selective disclosure, then
-[=holders=] can present proofs of [=claims=] without revealing the entire
-[=verifiable credential=].
-          </li>
-          <li>
-[=Verifiable presentations=] can either disclose the attributes of a
-[=verifiable credential=], or satisfy [=derived predicates=] requested by
-the [=verifier=]. [=Derived predicates=] are Boolean conditions, such as
-greater than, less than, equal to, is in set, and so on.
-          </li>
-          <li>
-[=Issuers=] can issue revocable [=verifiable credentials=].
-          </li>
-          <li>
-The processes of cryptographically protecting and verifying
-[=verifiable credentials=] and [=verifiable presentations=] have to be
-deterministic, bi-directional, and lossless. Any
-[=verifiable credential=] or [=verifiable presentation=] has to be
-transformable to the JSON-LD data model defined in this document via a
-deterministic process so that its verification can be processed in an
-interoperable fashion.
-          </li>
-          <li>
-[=Verifiable credentials=] and [=verifiable presentations=] have to be
-serializable in one or more machine-readable data formats. The process of
-serialization and/or de-serialization has to be deterministic, bi-directional,
-and lossless. Any serialization of a [=verifiable credential=] or
-[=verifiable presentation=] needs to be transformable to the generic data
-model defined in this document in a deterministic process such that the
-resulting [=verifiable credential=] can be processed in an interoperable
-fashion. The serialized form also needs to be able to be generated from the data
-model without loss of data or content.
-          </li>
-          <li>
-The data model and serialization must be extendable with minimal coordination.
-          </li>
-          <li>
-Revocation by the [=issuer=] should not reveal any identifying information
-about the [=subject=], the [=holder=], the specific
-[=verifiable credential=], or the [=verifier=].
-          </li>
-          <li>
-[=Issuers=] can disclose the revocation reason.
-          </li>
-          <li>
-[=Issuers=] revoking [=verifiable credentials=] should distinguish between
-revocation for cryptographic integrity (for example, the signing key is
-compromised) versus revocation for a status change (for example, the driver's
-license is suspended).
-          </li>
-          <li>
-[=Issuers=] can provide a service for refreshing a
-[=verifiable credential=].
-          </li>
-        </ul>
-      </section>
-
       <section id="conformance" class="normative">
         <p>
 A <dfn>conforming document</dfn> is a