Governance specification for the humanitarian-service-marketplace ecosystem. Defines who participates, what credentials exist, how authority is delegated, and what obligations each role carries. Generated by
/keri-c0-ecosystem.
The Humanitarian Service Marketplace trust framework establishes a KERI-native governance model for volunteer service coordination. It replaces siloed platforms and centralized trust intermediaries with cryptographically verifiable relationships using Autonomic Identifiers (AIDs), Authentic Chained Data Containers (ACDCs), and delegated authority hierarchies.
This ecosystem unifies the fragmented landscape of humanitarian service — where organizations like the Red Cross, United Way, faith-based organizations, and countless grassroots groups each operate independently — into a shared marketplace where service needs and volunteer capacity flow freely across organizational boundaries. The individual is at the center: they own their identity, credentials, and service history. Organizations become peers in a permissionless network, differentiated by reputation depth rather than gatekeeping authority.
Scope: A cross-organizational ecosystem where individuals and organizations declaratively state service needs, and credentialed volunteers contractually commit to meet those needs. Service organizations participate as peers — each credentialing and vetting volunteers according to their own governance, while service opportunities and verified service records flow freely across organizational boundaries. Trust is rooted in verifiable credentials: whoever issues a credential also verifies it. Volunteers build portable reputation through cryptographically verified service history owned by the individual.
Regulatory basis: State nonprofit reporting requirements, tax-exempt status auditing, child protection laws, OSHA regulations, SEDI frameworks, GDPR / state privacy laws.
Design principles:
This ecosystem is intentionally decentralized — there is no single governing body. Governance authority is distributed across participants according to their role and the formality of their operations.
At the grassroots level, governance is implicit: friends help friends, neighbors help neighbors, and trust is personal. As organizations scale, they adopt governance structures appropriate to their formality: KYV programs, credential standards, interoperability agreements. The largest organizations (Red Cross, United Way, faith-based institutions) serve as trust anchors not by decree but by reputation — their KYV standards carry weight because they have invested in robust vetting processes.
Government agencies provide the ultimate trust root through SEDI (State-Endorsed Digital Identity) and regulatory frameworks, but government participation is not required for the ecosystem to function at any level.
The ecosystem’s governance model is evolutionary: it meets people where they are and grows with them.
This trust framework is versioned. Changes to credential schemas, role definitions, or delegation rules require a new version published to the ecosystem’s schema registry. Participants MUST verify framework version before issuing or accepting credentials.
| Role | Display Name | Witness Pool | Watcher Network | Agent Service | ACDC Registry |
|---|---|---|---|---|---|
individual |
Individual | no | no | yes | no |
guardian |
Guardian | no | no | yes | no |
grassroots_org |
Grassroots Organization | no | no | yes | no |
service_platform |
Service Platform | yes | yes | yes | yes |
credential_provider |
Credential Provider | yes | no | yes | yes |
kyv_provider |
KYV Provider | yes | yes | yes | yes |
verification_service |
Verification Service | no | no | yes | yes |
government_agency |
Government Agency | yes | yes | yes | yes |
individual)Description: A person — can be a requester, volunteer, or both. Owns their identity, credentials, and service history. The center of the ecosystem. May hold a SEDI identity or bootstrap trust through ecosystem-native KYV credentials.
Governance obligations:
Credentials issued: service_need, equipment_inventory, guardian_delegation Credentials required to participate: (none — permissionless entry)
guardian)Description: Manages a delegated AID on behalf of someone who cannot manage their own (minor, elderly, person with disabilities). The ward retains their own AID — the guardian holds a delegated AID that acts within a cryptographically bounded scope. When the ward gains capacity, delegation can be revoked and they take full control.
Governance obligations:
Credentials issued: (none) Credentials required to participate: guardian_delegation
grassroots_org)Description: Informal groups — neighborhood clubs, homeschool co-ops, friend networks, small faith communities — that publish needs and coordinate volunteers without formal governance. Permissionless entry. Same protocols as large platforms, different scale and reputation depth.
Governance obligations:
Credentials issued: service_need, org_membership, service_record Credentials required to participate: (none — permissionless entry)
service_platform)Description: Formal organizations (Red Cross, United Way, Church of Jesus Christ of Latter-day Saints, etc.) that operate as marketplace peers — matching volunteers to needs, running KYV programs, and serving as trust anchors. Their value-add may evolve as the ecosystem matures: KYV vetting, disaster coordination at scale, government liaison, rather than simply being middlemen.
Governance obligations:
Credentials issued: org_membership, service_record, service_need, kyv_standard, interop_agreement, attribution_agreement Credentials required to participate: platform_registration
credential_provider)Description: Entities that issue skill and training credentials — trade schools, CPR trainers, online education platforms, professional licensing bodies. The issuer is also the verifier: whoever grants the credential is responsible for confirming its validity.
Governance obligations:
Credentials issued: skill_credential Credentials required to participate: (none)
kyv_provider)Description: Entities running Know Your Volunteer programs — composing background checks, training certificates, psychological evaluations, and other component credentials into a KYV credential. Multiple KYV standards coexist, each with known strengths and weaknesses. Could be a service platform, a specialized provider, or a consortium. As the ecosystem matures, high-standard KYV becomes accessible even to small organizations.
Governance obligations:
Credentials issued: kyv_credential Credentials required to participate: kyv_standard
verification_service)Description: Background check providers, identity verification services, biometric verification providers — the component suppliers that feed into KYV and other composite credentials. Specialized providers that serve multiple KYV providers and platforms.
Governance obligations:
Credentials issued: background_check, proof_of_service Credentials required to participate: (none)
government_agency)Description: Regulatory bodies that issue licenses (SEDI identity, professional licenses), receive tax reporting, and enforce child protection laws. Consumes aggregated, auditable roll-ups of service data. Benefits from KERI’s automatic verifiability — reduced accounting overhead, provable compliance.
Governance obligations:
Credentials issued: sedi_identity, platform_registration Credentials required to participate: (none)
Each credential type has a designated issuer role. Only AIDs holding the required role credential may issue that credential type. Issuance MUST:
Special considerations for this ecosystem:
rev event anchored in the issuer’s KELDisputes are resolved through cryptographic evidence. The KEL/TEL audit trail shows exactly who verified what credentials, who authorized what actions, and what proof-of-service was recorded. Duplicity (equivocation) detected by watchers constitutes automatic grounds for credential suspension.
For formal organizations, a governance body convenes a judge/jury panel to evaluate evidence. For grassroots interactions, the cryptographic record itself serves as the basis for any legal proceedings. Liability follows the audit trail — if a platform verified credentials that were fraudulent, the chain shows where fraud originated. If a platform failed to verify, that omission is equally visible.
Duplicity (equivocation) detected by watchers constitutes automatic grounds for credential suspension. The governance body convenes a judge/jury panel to evaluate duplicity evidence and render a binding judgment.
Roles operating witness pools (service_platform, credential_provider, kyv_provider, government_agency) MUST:
Roles subscribing to watcher networks (service_platform, kyv_provider, government_agency) MUST:
All roles running KERIA agents MUST:
Entities providing proof-of-service verification MUST support at least one of:
Each verification method MUST record its type and strength level in the proof-of-service credential.
Verifiers MUST request only the minimum credential fields required for their purpose. Selective disclosure credentials MUST be presented in compact form unless the verifier demonstrates a legitimate need for full disclosure.
Specific to this ecosystem:
Credential holders control presentation. No credential may be verified without the holder initiating the IPEX presentation exchange. The holder’s agent MUST prompt for consent before disclosing attributes.
Guardian-managed AIDs follow the same consent model — the guardian consents on behalf of the ward, within the scope defined by the guardian_delegation credential.
Credential issuers are liable for the accuracy of claims at the time of issuance. Issuers MUST revoke credentials when underlying facts change. In this ecosystem:
Verifiers are liable for checking revocation status and duplicity evidence before relying on a credential. Platforms that match volunteers to service needs based on credential verification carry liability proportional to their verification commitments — the cryptographic record shows exactly what was checked and what was not.
Holders are liable for maintaining key security. Compromise of a holder’s keys does not invalidate properly-issued credentials but requires immediate key rotation and re-issuance. Volunteers are liable for honoring service commitments they have cryptographically signed.
Witness pool operators are liable for availability and first-seen integrity. Watcher operators are liable for timely duplicity reporting. Proof-of-service infrastructure providers are liable for the accuracy of their verification methodology.
Service platforms that verify volunteer credentials and match them to service needs carry liability for the quality of their verification process. If a platform’s KYV standard is insufficient and a safety incident occurs, the cryptographic trail shows exactly what standard was applied and what it required. Liability follows the audit trail — not assumptions or finger-pointing.
Bridge credentials: driver_credential, vehicle_credential
Data flows:
Bridge credentials: tool_listing_credential, borrower_reputation
Data flows:
Bridge credentials: sedi_identity
Data flows:
Bridge credentials: liability_coverage_credential, workers_comp_credential
Data flows:
Bridge credentials: service_hour_aggregation, tax_deduction_certificate
Data flows:
Cross-ecosystem credential verification requires both ecosystems to publish compatible OOBIs and recognize each other’s governance frameworks. Bridge credentials MUST chain from a credential recognized in both ecosystems.
government_agency (root)
→ service_platform (scope: "Operate as recognized service marketplace", depth: 2)
→ grassroots_org (scope: "Coordinate volunteers within platform", depth: 1)
→ credential_provider (scope: "Issue credentials within licensed domain", depth: 1)
→ kyv_provider (scope: "Administer KYV programs per approved standards", depth: 1)
service_platform (root — as ecosystem trust anchor)
→ kyv_provider (scope: "Issue KYV credentials per platform's standard", depth: 1)
→ verification_service (scope: "Perform background checks for platform participants", depth: 1)
→ grassroots_org (scope: "Coordinate volunteers and publish needs on platform", depth: 1)
individual (root — self-sovereign)
→ guardian (scope: "Manage delegated AID on behalf of ward", depth: 1)
Note: The ward (person being guarded) retains their own AID. The guardian holds a delegated AID that operates within the cryptographically bounded scope defined by the guardian_delegation credential. When the ward gains capacity (a child grows up, an elderly person recovers), the delegation is revoked and they take full control of their AID.
/keri-c1-system to design services within this ecosystemcredential-catalog.md define the ACDC a block for each type