@@ -734,7 +734,7 @@ <h3>BitstringStatusListCredential</h3>
734
734
735
735
< p >
736
736
The status list is expressed inside a [=verifiable credential=] in order to
737
- enable a [=holder=] to provide it to a [=verifier=] directly . This mechanism,
737
+ enable a [=holder=] to provide it directly to a [=verifier=]. This mechanism,
738
738
sometimes called "certificate stapling", increases privacy for the [=holder=] by
739
739
ensuring that the [=verifier=] does not need to contact the [=issuer=] to
740
740
retrieve the status list. Still, a [=verifier=] might choose to ignore the
@@ -746,11 +746,12 @@ <h3>BitstringStatusListCredential</h3>
746
746
[=Issuers=] and [=verifiers=] are advised that the [=issuer=] of a
747
747
[=verifiable credential=] and the [=issuer=] of an associated
748
748
`BitstringStatusListCredential` might not be the same. There are technical,
749
- legal, institutional, and political reasons that might make it appropriate
750
- to separate the authority over the original credential from the authority to
751
- revoke such a credential. Therefore, the `issuer` value of a < a > verifiable
752
- credential</ a > containing a `BitstringStatusListEntry` MAY be different from
753
- the `issuer` value of a `BitstringStatusListCredential`.
749
+ legal, institutional, political, and other reasons that might make it
750
+ appropriate to separate the authority over the original credential from the
751
+ authority to revoke, or otherwise change the status of, such a credential.
752
+ Therefore, the `issuer` value of a [=verifiable credential=] containing a
753
+ `BitstringStatusListEntry` MAY be different from the `issuer` value of a
754
+ `BitstringStatusListCredential`.
754
755
</ p >
755
756
756
757
< p class ="issue atrisk " title ="TTL conflicts with `validUntil` ">
0 commit comments