The following is a list of use cases that are intended to help define/explore the work to be done in 2025 in the GATF. Each use case provides a simple explanation (as simple as possible, but no simpler) of the instance of use and also indicates which of the deliverables of the GATF charter the use case is relevant for.

The deliverables are defined in the GATF charter here: GSWG Governance Architecture Task Force (GATF) | Deliverables

They are (at the time of copying the text):

“…For each topic, the consideration is “the role and implementation of governance in …”

1. Trustworthy interactions across independent ecosystems

2. Enabling trust in Verifiers and Issuers in cross-ecosystem governance

3. Enabling cross-ecosystem meaning exchange (vocabulary and semantics)

4. Enabling Trustworthy governance architecture for verifiable identifiers”

All members of GATF are encouraged to contribute/comment on this page.

Instructions:

1. Please use Heading 1 level for each new use case and start the heading with “Use Case <n>: “

2. Reference which of the deliverables of the GATF this use case will help to explore

List of Use Cases:

Use Case 1: Holder from EcoA Requesting a Credential from an Issuer in EcoB

A leftover from discussions on Issuer, Holder, and Verifier (interacting with “Trust Establishment ‘plumbing’”) is establishing that:

• Holder 42A from EcoA is verifiable from EcoB

  • Has an Identifier resolvable by entities in EcoB

    • That can be confirmed as a Verifiable Identifier by entities in EcoB

  • A valid Entity in EcoA (some basic level of VCs from EcoA?)

  • Is entitled to receive credentials (from EcoB?)

• Issuer 17B from Eco B

  • Has verifiable credentials that 42A can confirm from EcoA, interacting with trust services in EcoB trusted by EcoA, as being a valid Issuer for X

  • …

• …

Use Case 2: Holder from EcoA interacts with Services from EcoB

Similar questions and issues to Use Case 1.

• 42A connects with a service 67B, a Verifier in EcoB

  • 42A can validate 67B as a Service and Verifier in EcoB, compliant with EcoA requirements

  • 67B can validate 42A with their criteria (which may require 42A to have VCs from either EcoA or EcoB, such as a “person credential” (prove you’re not an Aigent)

  • …

• …

Use Case 3: Aigent for a Holder (42A) in EcoA, can prove they are an authorized Aigent for 42A to Verifiers in EcoB

Continuation of the Use Cases 1, 2