Add credential deletion section. #491

msporny · 2025-06-22T16:03:09Z

This PR is an attempt to address issue #407 by adding a credential deletion section.

dlongley · 2025-06-23T16:32:41Z

index.html

+The <dfn>verifier service</dfn> 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


Suggested change

the VC; leaving the Verifier Coordinator to finish Applying any business rules

the VC; leaving the Verifier Coordinator to finish applying any business rules

dlongley · 2025-06-23T16:34:07Z

index.html

-          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


Suggested change

recommended to refer to external well known specifications, such as the

recommended to refer to external well-known specifications, such as the

The word order I suggest makes it (somewhat) less likely that well-known specifications will be read as a unit, thus not referencing only specifications that relate to the .well-known space.

Suggested change

recommended to refer to external well known specifications, such as the

recommended to refer to well-known external specifications, such as the

dlongley · 2025-06-23T16:36:29Z

index.html

+<a href="https://en.wikipedia.org/wiki/Right_to_be_forgotten">
+the right to be forgotten</a>. See Section [[[#deletion]]] for additional
+considerations related to the removal of [=verifiable credentials=] from
+systems.


+1 to this. We might want to consider some additional feature which would be more of a "prune" operation than a "delete", whereby the VC isn't deleted entirely, but its credentialId and any status entries information remain (information required for the application of uniqueness constraints and the maintenance of status lists, etc.).

@PatStLouis noted that deleting the VC would need to delete any "linked" information -- including possibly revoking the credential?

The group discussed some of this on the 2025-06-24 call and came to the following conclusions:

The difference between DELETE and "prune" is that the latter does not revoke the credential, and the former revokes the credential.

Deleting any "higher level" linked information is the responsibility of the issuer coordinator and not the issuer service.

Deleting might not be a good option if there are audit requirements (especially due to regulatory burdens).

I don't know that an issuer instance would necessarily "know" to "revoke" (or change any other status bit for any other status "purpose") when deletion is performed.

I think an individual implementation could implement some stops/checks that would prevent deletion via a special configuration, but I don't think it would necessarily be easy to have some default behavior based solely on the "revocation" purpose. What about "suspension"? What about other custom purposes? It seems setting an expectation or special case for "revocation" would lead to more confusion with the DELETE function, not less.

I would say, instead, that we should keep the deletion operation at this level separate and simple. We should say that custom configurations can prevent deletion for any reason (including checking arbitrary status values or for other existing "linked" information) and provide an appropriate error that would signal that a client needs to run other operations using the VC API (e.g., flip status bits) in order to enable deletion. This approach would also avoid creating multiple ways / mechanisms for changing status.

TallTed

Editorial tweaks, mostly minor, a couple more broad.

TallTed · 2025-06-23T18:44:26Z

index.html

-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 <dfn>issuer service</dfn> takes requests to issue VCs from authorized Issuer
+Coordinators and returns well-formed, signed Verifiable Credentials. This


It seems odd to have this Verifiable Credentials where the rest of the paragraph uses the VC abbreviation. I'm suggesting to abbreviate this one, to make the paragraph internally consistent, believing that there's a Verifiable Credentials (VCs) or similar earlier in the document. The whole document should optimally be made consistent, likely with <dfn> tags applied to the appropriate (usually first) instance and <a> tags applied to the rest, and using VC in most instances.

Suggested change

Coordinators and returns well-formed, signed Verifiable Credentials. This

Coordinators and returns well-formed, signed VCs. This

TallTed · 2025-06-23T18:46:37Z

index.html

+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.


Is there an appropriate link for WebKMS, to serve with <a > or [[? ]], as appropriate?

TallTed · 2025-06-23T18:53:43Z

index.html

+the VC; leaving the Verifier Coordinator to finish Applying any business rules
+needed.


As used here, the semicolon should separate two complete sentences. The leaving... section could be reworded to start with something like the Verifier Coordinator is left to finish support this use, but going with the comma (as I've suggested below) is the smaller change to make the sentence correct.

Suggested change

the VC; leaving the Verifier Coordinator to finish Applying any business rules

needed.

the VC, leaving the Verifier Coordinator to finish applying any necessary

business rules.

TallTed · 2025-06-23T18:56:16Z

index.html

+demonstrate control over DIDs prior to issuance and with Verifiers to present
+specific VCs.


Suggested change

demonstrate control over DIDs prior to issuance and with Verifiers to present

specific VCs.

demonstrate control over DIDs prior to VC issuance and with Verifiers to

present specific VCs.

TallTed · 2025-06-23T19:01:20Z

index.html

-        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 <dfn>status service</dfn> provides a privacy-preserving means for publishing


Suggested change

The <dfn>status service</dfn> provides a privacy-preserving means for publishing

The <dfn>status service</dfn> provides a privacy-preserving means of publishing

TallTed · 2025-06-23T19:02:38Z

index.html

-          <strong>Storage Service (Issuer) &bull;Storage Service
-            (Verifier) &bull; Storage Service (Holder)
-          </strong>
+<strong>Storage Service (Issuer) &bull;Storage Service (Verifier) &bull; Storage


Suggested change

<strong>Storage Service (Issuer) •Storage Service (Verifier) • Storage

<strong>Storage Service (Issuer) • Storage Service (Verifier) • Storage

TallTed · 2025-06-23T19:03:32Z

index.html

-access to those exchanges to any party.
+The <dfn>workflow service</dfn> 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


Suggested change

Verifier) can run their own Workflow Service to create and manage exchanges that

Verifier) can run their own workflow service to create and manage exchanges that

TallTed · 2025-06-23T19:05:04Z

index.html

+create exchanges at their Workflow Service and give authorized access to those
+exchanges to any party.


Suggested change

create exchanges at their Workflow Service and give authorized access to those

exchanges to any party.

create exchanges at their workflow service and give access to those exchanges

to any authorized party.

TallTed · 2025-06-23T19:06:55Z

index.html

+it can be useful to delete such a [=verifiable credential=]. An [=issuer=]
+might need to do so because of regulatory requirements such as
+<a href="https://en.wikipedia.org/wiki/Right_to_be_forgotten">


Suggested change

it can be useful to delete such a [=verifiable credential=]. An [=issuer=]

might need to do so because of regulatory requirements such as

<a href="https://en.wikipedia.org/wiki/Right_to_be_forgotten">

it can be useful to delete such a [=verifiable credential=]; for instance,

an [=issuer=] might need to do so because of regulatory requirements such

as <a href="https://en.wikipedia.org/wiki/Right_to_be_forgotten">

Add credential deletion section.

c3a8e2c

msporny requested review from dlongley, dmitrizagidulin, TallTed, wes-smith, eric-schuh and PatStLouis June 22, 2025 16:03

dlongley approved these changes Jun 23, 2025

View reviewed changes

TallTed suggested changes Jun 23, 2025

View reviewed changes

	the VC; leaving the Verifier Coordinator to finish Applying any business rules
	the VC; leaving the Verifier Coordinator to finish applying any business rules

	recommended to refer to external well known specifications, such as the
	recommended to refer to external well-known specifications, such as the

	recommended to refer to external well known specifications, such as the
	recommended to refer to well-known external specifications, such as the

	Coordinators and returns well-formed, signed Verifiable Credentials. This
	Coordinators and returns well-formed, signed VCs. This

		the VC; leaving the Verifier Coordinator to finish Applying any business rules
		needed.

-the VC; leaving the Verifier Coordinator to finish Applying any business rules
-needed.
+the VC, leaving the Verifier Coordinator to finish applying any necessary
+business rules.

		demonstrate control over DIDs prior to issuance and with Verifiers to present
		specific VCs.

	The <dfn>status service</dfn> provides a privacy-preserving means for publishing
	The <dfn>status service</dfn> provides a privacy-preserving means of publishing

	<strong>Storage Service (Issuer) •Storage Service (Verifier) • Storage
	<strong>Storage Service (Issuer) • Storage Service (Verifier) • Storage

	Verifier) can run their own Workflow Service to create and manage exchanges that
	Verifier) can run their own workflow service to create and manage exchanges that

		create exchanges at their Workflow Service and give authorized access to those
		exchanges to any party.

Add credential deletion section. #491

Are you sure you want to change the base?

Add credential deletion section. #491

Conversation

msporny commented Jun 22, 2025 • edited by pr-preview bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

dlongley Jul 1, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

TallTed left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

msporny commented Jun 22, 2025 •

edited by pr-preview bot

Loading

dlongley Jul 1, 2025 •

edited

Loading