Speak to graph quoting in credential section.

Author: msporny

index.html

@@ -787,14 +787,15 @@ <h3>Claims</h3>
         <h3>Credentials</h3>
 
         <p>
-A [=credential=] is a set of one or more [=claims=] made by the same
-[=entity=]. [=Credentials=] might also include an identifier and metadata
-to describe properties of the [=credential=], such as the
-[=issuer=], the validity date and time period, a representative image,
-[=verification material=], the revocation
-mechanism, and so on. The metadata might be signed by the [=issuer=]. A
-[=verifiable credential=] is a set of tamper-evident [=claims=] and
-metadata that cryptographically prove who issued it.
+A [=credential=] is a set of one or more [=claims=] made by the same [=entity=].
+[=Credentials=] might also include an identifier and metadata to describe
+properties of the [=credential=], such as the [=issuer=], the validity date and
+time period, a representative image, [=verification material=], status
+information, and so on. The metadata might be signed by the [=issuer=]. A
+[=verifiable credential=] is a set of tamper-evident [=claims=] and metadata
+that cryptographically prove who issued it. Examples of [=verifiable
+credentials=] include digital employee identification cards, digital birth
+certificates, and digital educational certificates.
         </p>
 
         <figure id="basic-vc">
@@ -807,19 +808,6 @@ <h3>Credentials</h3>
           </figcaption>
         </figure>
 
-        <p>
-Examples of [=verifiable credentials=] include digital employee
-identification cards, digital birth certificates, and digital educational
-certificates.
-        </p>
-
-        <p class="note">
-[=Credential=] identifiers are often used to identify specific instances
-of a [=credential=]. These identifiers can also be used for correlation. A
-[=holder=] wanting to minimize correlation is advised to use a selective
-disclosure scheme that does not reveal the [=credential=] identifier.
-        </p>
-
         <p>
 <a href="#basic-vc"></a> above shows the basic components of a
 [=verifiable credential=], but abstracts the details about how [=claims=]
@@ -828,14 +816,17 @@ <h3>Credentials</h3>
 </p>
         <p>
 <a href="#info-graph-vc"></a> below shows a more complete depiction of a
-[=verifiable credential=] using an [=embedded proof=] based on [[?VC-DATA-INTEGRITY]].
-It is composed of at least two information [=graphs=].
-The first of these information [=graphs=], the [=verifiable credential graph=] (which is the [=default graph=]),
-expresses the [=verifiable credential=] itself, through [=credential=] metadata and other [=claims=].
-The second information [=graph=], referred to by the `proof` property, is the <dfn>proof graph</dfn>
-of the [=verifiable credential=], and is a separate [=named graph=].
-The [=proof graph=] expresses the digital proof, which, in this case, is a digital
-signature.
+[=verifiable credential=] using an [=embedded proof=] based on
+[[[?VC-DATA-INTEGRITY]]]. It is composed of at least two information [=graphs=].
+The first of these information [=graphs=], the [=verifiable credential graph=]
+(which is the [=default graph=]), expresses the [=verifiable credential=]
+itself, through [=credential=] metadata and other [=claims=]. The second
+information [=graph=], referred to by the `proof` property, is the
+<dfn>proof graph</dfn> of the [=verifiable credential=], and is a separate
+[=named graph=]. The [=proof graph=] expresses the digital proof, which, in this
+case, is a digital signature. Readers that are interested in the need for
+multiple information graphs can refer to Section
+[[[#verifiable-credential-graphs]]].
         </p>
 
         <figure id="info-graph-vc">
@@ -894,6 +885,13 @@ <h3>Credentials</h3>
           </figcaption>
         </figure>
 
+        <p class="note">
+[=Credential=] identifiers are often used to identify specific instances
+of a [=credential=]. These identifiers can also be used for correlation. A
+[=holder=] wanting to minimize correlation is advised to use a selective
+disclosure scheme that does not reveal the [=credential=] identifier.
+        </p>
+
         <p class="note">
 It is possible to have a [=credential=], such as a marriage certificate,
 containing multiple [=claims=] about different [=subjects=] that are not
@@ -1365,7 +1363,7 @@ <h3>Identifiers</h3>
 <a href="#identifier-based-correlation"></a> carefully when considering such
 scenarios. There are also other types of access and correlation mechanisms documented
 in Section <a href="#privacy-considerations"></a> that create privacy concerns.
-Where privacy is a strong consideration, it is permissible to omit the 
+Where privacy is a strong consideration, it is permissible to omit the
 `id` [=property=]. Some use cases do not need, or explicitly need to omit,
 the `id` [=property=]. Similarly, special attention is to be given to the choice between
 publicly resolvable URLs and other forms of identifiers. Publicly resolvable URLs can
@@ -3061,7 +3059,7 @@ <h3>Trust Model</h3>
 either of the following:
             <ul>
               <li>
-An [=issuer=] is expected to secure a [=credential=] with a 
+An [=issuer=] is expected to secure a [=credential=] with a
 <a href="#securing-mechanisms">securing mechanism</a> which establishes
 that the [=issuer=] generated the [=credential=]. (In other words, an
 [=issuer=] is expected to [=issue=] a [=verifiable credential=].)
@@ -5906,7 +5904,7 @@ <h3>Data Theft</h3>
 [=verifiable presentations=] are valuable since they contain authentic
 statements made by trusted third parties, such as [=issuers=], or
 individuals, such as [=holders=] and [=subjects=]. The storage and
-acessibility of this data can inadvertently create honeypots of 
+acessibility of this data can inadvertently create honeypots of
 sensitive data for malicious actors. These adversaries often seek to
 exploit such resevoirs of sensitive information, aiming to
 acquire and exchange that data for financial gain.
@@ -5917,9 +5915,9 @@ <h3>Data Theft</h3>
 manage the status and revocation of those credentials. Similarly,
 [=issuers=] are advised to avoid the practice of creating publicly
 resolvable credentials that include personally identifiable information
-(PII) or other sensitive data. Software implementers are advised 
-to safeguarded [=verifiable credentials=] using robust consent 
-and access control measures, ensuring that they remain 
+(PII) or other sensitive data. Software implementers are advised
+to safeguarded [=verifiable credentials=] using robust consent
+and access control measures, ensuring that they remain
 inaccessible to unauthorized entities.
         </p>
         <p>
@@ -6451,7 +6449,7 @@ <h3>Code Injection</h3>
 Despite the ability to encode information as HTML, implementers are strongly
 discouraged from doing so, for the following reasons:
         </p>
-        
+
         <ul>
           <li>
 It requires some version of an HTML processor, which increases the burden of