Add first cut at verifiable accreditation section. #29

msporny · 2025-08-10T21:08:34Z

This PR attempts to suggest a non-centralized mechanism for a root authority to grant an issuer the right to issue specific types of credentials.

The section can be previewed here: https://pr-preview.s3.amazonaws.com/w3c-ccg/verifiable-issuers-verifiers/pull/29.html#decentralized-verifiable-roles

Preview | Diff

David-Chadwick

Subject to proposed edits

index.html

David-Chadwick · 2025-08-11T20:43:07Z

Note. We will need to check that the data model contains the properties of the issuer introduced in this example

Co-authored-by: David Chadwick <[email protected]>

index.html

David-Chadwick

A few edits are still needed

index.html

Co-authored-by: Ted Thibodeau Jr <[email protected]>

msporny · 2025-08-23T21:43:08Z

@dmitrizagidulin I have added an issue and the issue marker that you requested during the last call.

@jandrieu I have added the issue marker and attempted to refactor the language to speak about "accreditation" over "authorities", "grants", etc.

I've also merged in changes requested by @David-Chadwick and @TallTed.

We'll review this PR again this week and see if it's good enough to be merged.

David-Chadwick

This set of changes appears to be a retrograde step. The concept of roles is part of the VCDM, and therefore it is appropriate to have roles in this document.
Verifiable lists can be of any of the roles: issuer, verifier, holder/wallets.
Unless I am mistaken, the new text appears to focus more on the issuer role, but to rename it an accreditation.
I would like all these changes to be reversed.

TallTed

Looks reasonable overall. One tweak to make a sentence say what I think it was meant to say.

TallTed · 2025-08-25T19:14:10Z

index.html

+A [=verifiable accreditation=] can be provided to an [=issuer=] to recognize it
+to issue certain types of [=verifiable credentials=]. A [=verifier=] would


Suggested change

A [=verifiable accreditation=] can be provided to an [=issuer=] to recognize it

to issue certain types of [=verifiable credentials=]. A [=verifier=] would

A [=verifiable accreditation=] can be provided to an [=issuer=] to recognize its credible

authority to issue certain types of [=verifiable credentials=]. A [=verifier=] would

David-Chadwick · 2025-08-28T18:57:13Z

index.html

+      <h3>Verifiable Accreditation</h3>
+
+      <p>
+A <dfn>verifiable accreditation</dfn> is a recognition by an [=issuer=] that a


Suggested change

A <dfn>verifiable accreditation</dfn> is a recognition by an [=issuer=] that a

A <dfn>verifiable accreditation</dfn> is a recognition by a [=list operator=] that a

As I read all this, "list operator" doesn't seem like the right title. Maybe "list manager" or "list curator" or "list maintainer"...? If this title is already set in spec, could we get a link to where it's been defined (the "trust service data model"?) and see how it's used there?

I don't like "list operator" either... it presumes a list and the operation thereof. While we can say "a list of one still needs operating", it takes us back to centralized language, which many of us want to avoid.

List operator is the current terminology in the spec. So I am using this to be consistent throughout the entire spec. I suggest you make the change now to be consistent with the rest of the spec, and then raise an issue to change the name of list operator to something else which the group can agree on.

"accreditor" was that suggested change. We don't want this to be about centralized lists. Let's hear what others have to say about the change. I'll change it if we have agreement from others that "list operator" is a better direction from "accreditor". Perhaps just raising an issue to say that "list operator" and "accreditor" are both being challenged so we can merge and move on to the next phase is best.

Raising an issue is the best approach. But for now, let's not introduce another term such as accreditor when there is already a term defined in the document. Let's use the existing term to make the document consistent throughout and then make a global change of the term "list operator" when a new one is agreed upon.

David-Chadwick · 2025-08-28T18:59:06Z

index.html

+      <p class="note"
+         title="Trust decisions are always local and can be overridden">
+Ecosystem participants are advised that all trust decisions are local and can be
+overridden. Different [=verifiers=] might use different accreditors and


Suggested change

overridden. Different [=verifiers=] might use different accreditors and

overridden. Different [=verifiers=] might use different [=list operators] and

David-Chadwick · 2025-08-28T18:59:34Z

index.html

+         title="Trust decisions are always local and can be overridden">
+Ecosystem participants are advised that all trust decisions are local and can be
+overridden. Different [=verifiers=] might use different accreditors and
+have risk profiles that might not require any accreditor at all. Further,


Suggested change

have risk profiles that might not require any accreditor at all. Further,

have risk profiles that might not require any [=list operator=] at all. Further,

David-Chadwick · 2025-08-28T19:00:11Z

index.html

+overridden. Different [=verifiers=] might use different accreditors and
+have risk profiles that might not require any accreditor at all. Further,
+some [=verifiers=] might have additional requirements that reject [=verifiable
+credentials=] even if they were issued by a trusted accreditor. Certain


Suggested change

credentials=] even if they were issued by a trusted accreditor. Certain

credentials=] even if they were issued by a trusted [=list operator=]. Certain

David-Chadwick · 2025-08-28T19:00:54Z

index.html

+        <h4>Issuing Accreditation</h4>
+
+        <p>
+A [=verifiable accreditation=] can be provided to an [=issuer=] to recognize it


Suggested change

A [=verifiable accreditation=] can be provided to an [=issuer=] to recognize it

A [=verifiable accreditation=] can be provided by a [=list operator=] to an [=issuer=] to recognize it

David-Chadwick · 2025-08-28T19:04:24Z

index.html

+each [=issuer=]. The [=issuer=] can then provide the [=verifiable
+accreditation=] to the [=holders=], who would then present the credential to the
+[=verifier=]. An example of such a [=verifiable credential=] issued by a trusted
+accreditor to an [=issuer=] is shown below. This system is similar in many


Suggested change

accreditor to an [=issuer=] is shown below. This system is similar in many

[=list operator=] to an [=issuer=] is shown below. This system is similar in many

David-Chadwick · 2025-08-28T19:11:18Z

index.html

+    "VerifiableCredential",
+    "AccreditationCredential"
+  ],
+  "issuer": "did:web:accreditor.example",


Suggested change

"issuer": "did:web:accreditor.example",

"issuer": { "TSLVersionIdentifier": "1",

"TSLSequenceNumber": "1",

"TSLType": "https://w3c.org/ccg/TSLv1",

"ListOperatorName": "example name",

"ListName": "EduCertify Education Trust List",

"id":"did:web:accreditor.example"},

Note that we are using the data model to describe the attributes of the list operator and this list.

-1 to this change, it goes beyond the purpose of this PR, which was to create a minimum viable VC for decentralized use. The data modelling here is problematic and would need much more discussion before we pull it into the example, which again, is supposed to be the minimum viable example (not a fully formed example pulling in the rest of the TRAIN terms).

I suggest raising an issue that proposes this change and we can go from there.

David-Chadwick · 2025-08-28T19:18:03Z

index.html

+  "validFrom": "2025-01-01T00:00:00Z",
+  "validUntil": "2030-01-01T00:00:00Z",
+  "credentialSubject": {
+    "id": "did:web:issuer.example",


Suggested change

"id": "did:web:issuer.example",

"TrustServiceProvider": {

"TSPInfo": {

"UUID": "123435",

"TSPName": "EduCertify Inc.",

"TSPTradeName": "EduCertify",

"id": "did:web:issuer.example"},

Note that the credential subject is the trust service provider, so we use the existing data model to describe it.

-1 to this change, again, the data modeling is problematic and it would take us a lot of time to have a discussion over fixing it. This opens up the discussion to the entire specification, and I'd rather avoid that since the PR was intended to be a minimum viable example.

I suggest raising an issue that proposes this change and we can go from there.

You can certainly create a minimum viable example by using the attributes/properties of the existing data model. You do not need to invent new attributes which simply duplicate what the existing attributes do.

So I will support your example if you revise it to use existing data model properties.

David-Chadwick · 2025-08-28T19:20:14Z

index.html

+  "validUntil": "2030-01-01T00:00:00Z",
+  "credentialSubject": {
+    "id": "did:web:issuer.example",
+    "type": "Issuer",


remove line 1362 because it is covered by the TSP service type identifier

The agreement we seemed to have during the last call was to change the type to something like "AccreditedIssuer"

I think the agreement was that the data model should be the same for both centralised and distributed lists.
So if you want to propose changes to the data model to address your example, please raise an issue for this. My changes use the same data for both examples, so this is the correct way to proceed.

David-Chadwick · 2025-08-28T19:23:59Z

index.html

+  "credentialSubject": {
+    "id": "did:web:issuer.example",
+    "type": "Issuer",
+    "accreditation": [{


Suggested change

"accreditation": [{

"TSPServices": [

{

"TSPService": {

"ServiceTypeIdentifier": "https://w3c.org/ccg/st/trusted_issuer",

"ServiceName": "Education Credential Issuer",

"ServiceCurrentStatus": "Active",

"StatusStartingTime": "2024-01-01T00:00:00Z",

"ServiceDefinitionURIs": [

"https://educertify.com/services/credential-issuer/metadata",

"https://educertify.com/services/credential-issuer/schema"

],

"ServiceSupplyPoints": [

"https://issuer.com/OnlinePortal"

],

"ServiceDigitalIdentity":

{

"DID": "did:web:educertify.com"

}

],

"AdditionalServiceInformation": {

"ServiceIssuedCredentialTypes": [

"Masters"

]

}

}

}

The accreditation is of Trust Service. So we use the attributes of the trust service data model to describe the accreditation.

We need to do the same for the second accreditation as well.

Then the issued VC conforms to the proposed data model for trusted lists.

-1, this changes the data model proposed for the decentralized model completely and results in something we can't use in our implementations.

I suggest raising an issue that proposes this change and we can go from there.

We have a data model for trusted entities. Whether the trusted list contains one entry (as in the distributed case) or thousands of entries (as in the centralised case), the data that is needed to assess the trustworthiness of both the list issuer and each entity in the list is the same. So I do not agree with the example you have provided since it uses a completely different data model. My revised example uses the same data model for both a centralised list and a distributed list. So this PR should not be merged at the current time

msporny · 2025-09-01T15:12:45Z

Based on @David-Chadwick's most recent request for changes, it's becoming clear that perhaps we have a fundamental disagreement on the purpose of this PR and the core data model in the specification. We'll discuss if there is a way to align these different perspectives on the upcoming call. I have raised the following issues to help us navigate the discussion on the upcoming call:

Add first cut at decentralized issuance grants.

403ce7f

msporny requested review from BigBlueHat, David-Chadwick, PatStLouis, bparth24, dlongley, dmitrizagidulin, hendersonweb, jandrieu and kezike August 10, 2025 21:09

David-Chadwick approved these changes Aug 11, 2025

View reviewed changes

index.html Outdated Show resolved Hide resolved

index.html Outdated Show resolved Hide resolved

index.html Outdated Show resolved Hide resolved

Clarify how many VCs the root authority issues.

d1f3351

Co-authored-by: David Chadwick <[email protected]>

David-Chadwick approved these changes Aug 13, 2025

View reviewed changes

TallTed suggested changes Aug 14, 2025

View reviewed changes

index.html Outdated Show resolved Hide resolved

index.html Outdated Show resolved Hide resolved

index.html Outdated Show resolved Hide resolved

David-Chadwick self-requested a review August 15, 2025 21:00

David-Chadwick reviewed Aug 18, 2025

View reviewed changes

index.html Outdated Show resolved Hide resolved

index.html Outdated Show resolved Hide resolved

msporny and others added 3 commits August 23, 2025 16:47

Update grant explanation language.

ca49c40

Co-authored-by: Ted Thibodeau Jr <[email protected]>

Shift to "accreditation" language.

c7bb963

Add issue markers to track improvements to the specification.

26a166f

msporny changed the title ~~Add first cut at decentralized issuance grants.~~ Add first cut at verifiable accreditation section. Aug 23, 2025

David-Chadwick requested changes Aug 23, 2025

View reviewed changes

TallTed suggested changes Aug 25, 2025

View reviewed changes

David-Chadwick requested changes Aug 28, 2025

View reviewed changes

msporny mentioned this pull request Sep 1, 2025

Provide minimal viable examples #34

Open

		A [=verifiable accreditation=] can be provided to an [=issuer=] to recognize it
		to issue certain types of [=verifiable credentials=]. A [=verifier=] would

	A <dfn>verifiable accreditation</dfn> is a recognition by an [=issuer=] that a
	A <dfn>verifiable accreditation</dfn> is a recognition by a [=list operator=] that a

	overridden. Different [=verifiers=] might use different accreditors and
	overridden. Different [=verifiers=] might use different [=list operators] and

	have risk profiles that might not require any accreditor at all. Further,
	have risk profiles that might not require any [=list operator=] at all. Further,

	credentials=] even if they were issued by a trusted accreditor. Certain
	credentials=] even if they were issued by a trusted [=list operator=]. Certain

	accreditor to an [=issuer=] is shown below. This system is similar in many
	[=list operator=] to an [=issuer=] is shown below. This system is similar in many

-  "issuer": "did:web:accreditor.example",
+  "issuer": {     "TSLVersionIdentifier": "1",
+      "TSLSequenceNumber": "1",
+      "TSLType": "https://w3c.org/ccg/TSLv1",
+      "ListOperatorName": "example name",
+  "ListName": "EduCertify Education Trust List",
+  "id":"did:web:accreditor.example"},

-    "id": "did:web:issuer.example",
+"TrustServiceProvider": {
+              "TSPInfo": {
+                  "UUID": "123435",
+                  "TSPName": "EduCertify Inc.",
+                  "TSPTradeName": "EduCertify",
+    "id": "did:web:issuer.example"},

-    "accreditation": [{
+    "TSPServices": [
+                  {
+                      "TSPService": {
+                          "ServiceTypeIdentifier": "https://w3c.org/ccg/st/trusted_issuer",
+                          "ServiceName": "Education Credential Issuer",
+                          "ServiceCurrentStatus": "Active",
+                          "StatusStartingTime": "2024-01-01T00:00:00Z",
+                          "ServiceDefinitionURIs": [
+                              "https://educertify.com/services/credential-issuer/metadata",
+                              "https://educertify.com/services/credential-issuer/schema"
+                          ],
+                          "ServiceSupplyPoints": [
+                              "https://issuer.com/OnlinePortal"
+                          ],
+                          "ServiceDigitalIdentity":
+                              {
+                                  "DID": "did:web:educertify.com"
+                              }
+                          ],
+                          "AdditionalServiceInformation": {
+                              "ServiceIssuedCredentialTypes": [
+                                  "Masters"
+                              ]
+                          }
+                      }
+                  }

Add first cut at verifiable accreditation section. #29

Are you sure you want to change the base?

Add first cut at verifiable accreditation section. #29

Uh oh!

Conversation

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

Uh oh!

Uh oh!

David-Chadwick left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

David-Chadwick commented Aug 11, 2025

Uh oh!

Uh oh!

Uh oh!

Uh oh!

David-Chadwick left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

msporny commented Aug 23, 2025

Uh oh!

David-Chadwick left a comment

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!

David-Chadwick Aug 28, 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!

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!

msporny Aug 28, 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!

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!

David-Chadwick Aug 28, 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!

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!

msporny Aug 29, 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!

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!

David-Chadwick Aug 28, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

msporny commented Aug 10, 2025 •

edited by pr-preview bot

Loading

David-Chadwick Aug 28, 2025 •

edited

Loading

msporny Aug 28, 2025 •

edited

Loading

David-Chadwick Aug 28, 2025 •

edited

Loading

msporny Aug 29, 2025 •

edited

Loading

David-Chadwick Aug 28, 2025 •

edited

Loading

msporny commented Sep 1, 2025 •

edited

Loading