From f6c16b1cf4c04c0d5b49273fefff4a90951c3657 Mon Sep 17 00:00:00 2001
From: Manu Sporny
Date: Sat, 24 Aug 2024 10:58:39 -0400
Subject: [PATCH] Rename VC-SPECS reference to VC-EXTENSIONS.
---
index.html | 55 +++++++++++++++++++++++++++---------------------------
1 file changed, 27 insertions(+), 28 deletions(-)
diff --git a/index.html b/index.html
index 6735bbbda..067f5958b 100644
--- a/index.html
+++ b/index.html
@@ -42,8 +42,8 @@
// extend the bibliography entries
localBiblio: {
- "VC-SPECS": {
- title: "Verifiable Credential Specifications Directory",
+ "VC-EXTENSIONS": {
+ title: "Verifiable Credential Extensions",
href: "https://w3c.github.io/vc-specs-dir/",
authors: [
"Manu Sporny"
@@ -1178,8 +1178,8 @@ Getting Started
would then be replaced with the URL of a use-case-specific context. This
process is covered in Section [[[#extensibility]]]. Alternatively,
developers can reuse existing vocabulary and context files that happen to fit
-their use case. They can explore the [[[VC-SPECS]]] [[VC-SPECS]] for reusable
-resources.
+their use case. They can explore the [[[VC-EXTENSIONS]]]
+for reusable resources.
@@ -2169,11 +2169,10 @@ Status
-Defining the data model, formats, and protocols for status schemes is out of
-the scope of this specification. A Verifiable Credential Specifications Directory
-[[?VC-SPECS]] contains available status schemes
-for implementers who want to implement [=verifiable credential=]
-status checking.
+Defining the data model, formats, and protocols for status schemes is out of the
+scope of this specification. The [[[?VC-EXTENSIONS]]] document contains
+available status schemes for implementers who want to implement [=verifiable
+credential=] status checking.
@@ -2880,7 +2879,7 @@
Extensibility
Support multiple types of cryptographic proof formats through the use of
[[[VC-JOSE-COSE]]], [[[VC-DATA-INTEGRITY]]], and a variety of cryptographic
-suites listed in the [[[?VC-SPECS]]].
+suites listed in the [[[?VC-EXTENSIONS]]] document.
Provide all of the extensibility mechanisms outlined above in a data format that
@@ -3016,9 +3015,9 @@ Extensibility
specification, such as in Sections [[[#status]]], [[[#data-schemas]]],
[[[#securing-mechanisms]]], [[[#refreshing]]], [[[#terms-of-use]]], and
[[[#evidence]]]. While this specification does not define concrete
-implementations for those extension points, the Verifiable Credential
-Specifications Directory [[?VC-SPECS]] provides an unofficial, curated list of
-extensions that developers can use from these extension points.
+implementations for those extension points, the [[[?VC-EXTENSIONS]]] document
+provides an unofficial, curated list of extensions that developers can use from
+these extension points.
@@ -3933,9 +3932,9 @@ Reserved Extension Points
An unofficial list of specifications that are associated with the extension
points defined in this specification, as well as the reserved extension points
-defined in this section, can be found in the Verifiable Credentials
-Specifications Directory [[?VC-SPECS]]. Items in the directory that refer to
-reserved extension points SHOULD be treated as experimental.
+defined in this section, can be found in the [[[?VC-EXTENSIONS]]]. Items in the
+directory that refer to reserved extension points SHOULD be treated as
+experimental.
@@ -4146,8 +4145,8 @@ Securing Mechanism Specifications
Securing mechanism specifications SHOULD register the securing mechanism in the
-Securing Mechanisms section
-of the [[[?VC-SPECS]]] [[?VC-SPECS]].
+Securing Mechanisms
+section of the [[[?VC-EXTENSIONS]]] document.
Securing Mechanism Specifications
[[[VC-DATA-INTEGRITY]]] [[VC-DATA-INTEGRITY]] and [[[VC-JOSE-COSE]]]
[[VC-JOSE-COSE]]. Other securing mechanisms that are known to the community
can be found in the
-Securing Mechanisms section
-of the [[[?VC-SPECS]]] [[?VC-SPECS]].
+Securing Mechanisms
+section of the [[[?VC-EXTENSIONS]]] document.
@@ -4694,10 +4693,10 @@ Verification
-
Set the |verifyProof| function by using the |inputMediaType| and the
-Securing Mechanisms section of
-the [[[?VC-SPECS]]] [[?VC-SPECS]], or other mechanisms known to the
-implementation, to determine the cryptographic suite to use when verifying
-the securing mechanism. The |verifyProof| function MUST implement the interface
+Securing Mechanisms
+section of the [[[?VC-EXTENSIONS]]] document, or other mechanisms known to the
+implementation, to determine the cryptographic suite to use when verifying the
+securing mechanism. The |verifyProof| function MUST implement the interface
described in [[[#securing-mechanism-specifications]]].
-
@@ -6013,18 +6012,18 @@
Replay Attack
not used more than a certain number of times. For example, a [=verifiable
credential=] representing an event ticket might allow entry to multiple
individuals if presented multiple times, undermining the purpose of the ticket
-from the perspective of its [=issuer=]. To prevent such replay attacks,
+from the perspective of its [=issuer=]. To prevent such replay attacks,
[=verifiers=] require [=holders=] to include additional security measures
in their [=verifiable presentations=]. Examples include the following:
-
-A challenge
+A challenge
provided by the [=verifier=], which the [=holder=] incorporates into
a [=verifiable presentation=]. The [=verifier=] enforces challenge
uniqueness to prevent replay attacks.
-
-A validity period, limiting the window
+A validity period, limiting the window
during which the [=verifiable presentation=] is valid.
@@ -6473,7 +6472,7 @@ Credential Type
[=holder=], they can specify the type of credential(s)
that they would like to receive. Credential types, as well as validation schemas
for each type and each of their [=claims=], are defined by specification authors
-and are published in places like the [[[VC-SPECS]]].
+and are published in places like the [[[VC-EXTENSIONS]]].