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

    1. 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]]].
    2. @@ -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]]].