From c3a8e2c95ce59006455332d554b1911c946adee8 Mon Sep 17 00:00:00 2001 From: Manu Sporny Date: Sun, 22 Jun 2025 12:01:41 -0400 Subject: [PATCH] Add credential deletion section. --- holder.yml | 4 ++- index.html | 86 +++++++++++++++++++++++++++++++++--------------------- 2 files changed, 55 insertions(+), 35 deletions(-) diff --git a/holder.yml b/holder.yml index 156dd78d..46e58bdc 100644 --- a/holder.yml +++ b/holder.yml @@ -52,7 +52,9 @@ paths: - oAuth2: [] - zCap: [] summary: Deletes a credential or verifiable credential by ID. To delete a credential that does not have credential.id set but has an associated credentialId value, pass credentialId instead. - x-expectedCaller: "Issuer Coordinator" + x-expectedCaller: + - Issuer Coordinator + - Holder Coordinator operationId: deleteCredential parameters: - $ref: "./components/parameters/path/ObjectId.yml" diff --git a/index.html b/index.html index f1f68874..89e78708 100644 --- a/index.html +++ b/index.html @@ -489,48 +489,49 @@

Services

network endpoints of services are defined herein.

-The Issuer Service takes requests to issue VCs from authorized Issuer Coordinators -and returns well-formed, signed Verifiable Credentials. This service MUST -have access to private keys (or key services which utilize private keys) -in order to create the proofs for those VCs. The API between the Issuer -service and its associated key service is believed to be out of scope for -the VC API, but may be addressed by WebKMS or similar specifications. +The issuer service takes requests to issue VCs from authorized Issuer +Coordinators and returns well-formed, signed Verifiable Credentials. This +service MUST have access to private keys (or key services which utilize private +keys) in order to create the proofs for those VCs. The API between the Issuer +service and its associated key service is believed to be out of scope for the VC +API, but may be addressed by WebKMS or similar specifications.

-The Verifier service takes requests to verify Verifiable Credentials and -Verifiable Presentations and returns the result of checking their proofs -and status (if present). The service only checks the authenticity and -timeliness of the VC; leaving the Verifier Coordinator to finish Applying any business rules needed. +The verifier service takes requests to verify Verifiable Credentials +and Verifiable Presentations and returns the result of checking their proofs and +status (if present). The service only checks the authenticity and timeliness of +the VC; leaving the Verifier Coordinator to finish Applying any business rules +needed.

- The Holder service takes requests to create Verifiable Presentations - from an optional set of VCs and returns well-formed, signed Verifiable - Presentations containing those VCs. These VPs are used with Issuers to - demonstrate control over DIDs prior to issuance and with Verifiers to - present specific VCs. +The holder service takes requests to create Verifiable Presentations +from an optional set of VCs and returns well-formed, signed Verifiable +Presentations containing those VCs. These VPs are used with Issuers to +demonstrate control over DIDs prior to issuance and with Verifiers to present +specific VCs.

Status Service

- The Status Service provides a privacy-preserving means for publishing - and checking the status of any Verifiable Credentials issued by the - Issuer. Implementers of verifier services are encouraged to understand the - privacy implications of checking status by referring to the respective - status specification used by the verifiable credential. +The status service provides a privacy-preserving means for publishing +and checking the status of any Verifiable Credentials issued by the Issuer. +Implementers of verifier services are encouraged to understand the privacy +implications of checking status by referring to the respective status +specification used by the verifiable credential.

- For specific mechanisms by which to manage Verifiable Credential statuses, - it's recommended to refer to external well known specifications, such as the - [[VC-BITSTRING-STATUS-LIST]]. +For specific mechanisms by which to manage Verifiable Credential statuses, it's +recommended to refer to external well known specifications, such as the +[[VC-BITSTRING-STATUS-LIST]].

Storage Services

- Storage Service (Issuer) •Storage Service - (Verifier) • Storage Service (Holder) - +Storage Service (Issuer) •Storage Service (Verifier) • Storage +Service (Holder) +

Each actor in the system is expected to store their own verifiable @@ -557,13 +558,13 @@

Storage Services

Workflow Service

-The Workflow Service provides a way for coordinators to automate specific -interactions for specific users. Each role (Holder, Issuer, and Verifier) -can run their own Workflow Service to create and manage exchanges that -realize particular workflows. Administrators configure the workflow system -to support particular flows. Then, when the business rules justify it, -coordinators create exchanges at their Workflow Service and give authorized -access to those exchanges to any party. +The workflow service provides a way for coordinators to automate +specific interactions for specific users. Each role (Holder, Issuer, and +Verifier) can run their own Workflow Service to create and manage exchanges that +realize particular workflows. Administrators configure the workflow system to +support particular flows. Then, when the business rules justify it, coordinators +create exchanges at their Workflow Service and give authorized access to those +exchanges to any party.

@@ -858,7 +859,7 @@

Holder Service

that is expected to call the endpoint

+ data-api-path="/credentials/derive /credentials/{id} /presentations /presentations/{id}">

Workflow Service

@@ -928,6 +929,23 @@

Update Status

data-api-endpoint="post /credentials/status">
+
+

Delete a Specific Credential

+

+An [=issuer service=] or a [=holder service=] might store an issued +[=verifiable credential=] for an extended period of time. When this is done, +it can be useful to delete such a [=verifiable credential=]. An [=issuer=] +might need to do so because of regulatory requirements such as + +the right to be forgotten. See Section [[[#deletion]]] for additional +considerations related to the removal of [=verifiable credentials=] from +systems. +

+ +
+
+