Outline considerations that are out of scope

[msporny]

As Steve notes here:

https://lists.w3.org/Archives/Public/public-credentials/2023Mar/0039.html

It's important for the specification to draw a clear line wrt. what's in scope (the format and semantics of the list and items in the list) and what's out of scope (APIs for managing the list, governance models for managing the list, etc.).

We should add a section to the introduction of the specification that highlights what the spec does and does not address.

[bobwyman]

Given the example of a "List of Credible Issuers who issue Credibility VCs," (as discussed on the mailing list), someone using the list is given no reason to trust that members of the list are, in fact, Credible Issuers. A list user can "trust," at most, that the creator of the list has, in fact, included the members in the list.

The procedure for including some Issuer on that list might be purely random selection, it might involve detailed manual verification of claims made by a potential member, or it might involve a simple automated procedure such as "include any Issuer who has been issued a Credibility VC by some other Issuer." Inclusion on the list says nothing about the list vetting procedure that was employed.

[msporny]

Inclusion on the list says nothing about the list vetting procedure that was employed.

Note that each entry in the list can include the operational scheme (aka governance) and accreditation body for the list entry (such as an issuer):

    "usesOperationalScheme": [{
      "id": "http://oid-info.com/get/1.2.3.4.5",
      "name": "Utopian Trust Scheme 819-4"
    }],

    "accreditation": [{
      "id": "https://utopia.gov.example/accreditations/123"
    }],

Whether or not either of those fields means anything to the Verifier, though, is another matter. :)

[RieksJ]

@bobwyman wrote

A list user can "trust," at most, that the creator of the list has, in fact, included the members in the list

Slide 12 in the presentation Verifiable Issuers and Verifiers v0.1.pdf states that a list operator is expected to work according to the List Operation Policy (LOP) that is published (shared) within the community. If a party decides to trust the list operator to work according to the OP it has published, it can then also trust it to everything that is stated in the OP. The figure suggests that this corresponds with being a member of such a community.

Looking at the slide, you may note that there is a correspondence with PKI stuff. The policy operator corresponds with a PKI Registration Authority (RA), the policy itself to a PKI Certificate Practice Statement (CPS), while the authority that draws up the LOP (on behalf of the community is similar to the PKI Certification Authority (CA). The comment you make (and my remarks) would apply equally well to such PKI bodies. In fact, there even are communities (consisting of the users of the various browsers, the producers of which have 'trusted CA/RA lists' that their browsers consult).

I would argue that it would be within within the scope of this work to define a minimum set of such policies, each with

• a statement of its purpose, and what parties can(not) expect it to do;
• criteria for deciding what goes in there (and what not),
• the name for a role that a party will perform as it takes on the responsibility for creating and maintaining such policies.

I consider it to be outside the scope of this work to define actual content for such policies, or to dive into the various processes for governing, managing and operating such policies.

However, if we do this right, this work might perhaps serve as a stepping stone (or template) that communities may use as they realize they might need other policies as well - after all, PKI contexts are known to have multiple policies the PKI context, there are various policies: the Certificate Policy (CP), Certificate Practice Statement (CPS), revocation policies, key-management policies, security policies, and perhaps others. In Communities such as these, there are various other things that communities may want/need to organize - see this paper on Decentralized SSI Governance