Proposals · Networks for Humanity
From credentials to contextual trust.
A bounded interoperability proposal to Networks for Humanity: use DeDi to resolve public trust authority, OpenCred to carry approved claims, and The Internet of Value to govern the human-value process from which those claims emerge.
Working status
A credential is a signed claim. Contextual trust is the governed process that decided whether the claim deserved to be issued.
The proposal in one sentence: test whether DeDi can resolve public authority for one GFE skill issuer while OpenCred carries one minimized, holder-controlled credential produced from an IoV-governed attestation.
This page proposes technical discovery and a prototype. It does not claim an existing NFH partnership, an implemented OpenCred integration, or NFH endorsement of The Internet of Value.
Authored by Moses Sam Paul Johnraj · Published and reviewed 03 August 2026 · Working proposal v0.1
Direct answers
The proposal, without the architecture diagram.
- What is the Internet of Value proposing to Networks for Humanity?
- A bounded interoperability pilot: DeDi would resolve public community and issuer authority, OpenCred would carry one approved credential, and the IoV protocol stack would govern the evidence and validation process that precedes issuance.
- What belongs in DeDi?
- Public trust infrastructure: recognised communities, authority scopes, issuer DIDs and keys, credential schemas, policy versions, service endpoints, and revocation or supersession state.
- Should a person’s complete Wellbeing Identity be listed in DeDi?
- No. A complete Wellbeing Identity, private Wellbecoming state, Value Log evidence, validator reasoning, and public member roster are outside the proposed directory boundary.
- What is the first proposed credential?
- A synthetic or explicitly approved GFE Skill Attainment credential. Growth Flow Engineering defines the skill rubric and governs assessment; OpenCred packages the minimized approved claim for the holder.
- What role does HouseOfBros play?
- HouseOfBros is the wellbeing and wellbecoming community, not the GFE skill authority. It may publish its community authority and later issue only narrow attestations covered by its own declared policy.
- Is this already an NFH partnership or implemented integration?
- No. This is a public working proposal. OpenCred formats, APIs, status mechanisms, wallet hand-offs, and DeDi verifier details remain questions for joint technical discovery.
01 · Correct community model
HouseOfBros is the wellbeing community. GFE is the skill community.
Both can participate in the same trust infrastructure, but they do not have the same mandate. DeDi should make each authority scope explicit so recognition never becomes implied permission to issue.
Wellbecoming and wellbeing community
HouseOfBros
Validates evidence adequacy, classification adequacy, and self-observation integrity for bounded non-Performance records and owns its declared issuer policies.
Credential boundary
May later issue narrow community-role, workshop-completion, or practice attestations. It must not publish private wellbeing state, raw narratives, or a universal claim that a person is ‘well’.
Skill-based community
~Growth Flow Engineering~
Defines the GFE-x.y.z Marketing, Sales, and Finance skill signature, evidence rubric, validators, and governed level progression.
Credential boundary
Best first OpenCred pilot: a demonstrated GFE skill credential issued only after a SAOcommons Performance attestation under a versioned community policy.
Protocol steward and convenor
Internet of Value Research Foundation
Maintains the public research surface, convenes the pilot, and keeps implementation claims grounded in the canonical IoV and SAOcommons specifications.
Credential boundary
Does not silently inherit authority to assess GFE skills, validate HouseOfBros records, or disclose a participant’s Wellbeing Identity.
02 · Responsibility architecture
One claim travels. Authority remains separated.
VHTTP is proposed as the human-interaction envelope around this sequence. It does not replace W3C credentials, DeDi, OpenCred, Word Wallet, or the four canonical IoV protocols.
- 01Capture
~ValueCaptureProtocol
Creates the TimeSlice, actor attribution, proof references, community context, and immutable ProtocolLinkId.
- 02Interpret
~WellbecomingProtocol
Routes the occurrence through one primary Wellbecoming node. Private inner-state records remain private by default.
- 03Validate
~SAOcommons
For Performance only, applies a Learning, Earning, or OrgBuilding policy and produces a governed attestation.
- 04Project
~WellbeingIdentity
Receives the validated skill or certification into Skills and EarnedIdentity without making the complete identity public.
- 05Issue
OpenCred
Packages the approved claim as a holder-controlled verifiable credential after the upstream judgment is complete.
- 06Resolve
DeDi
Lets a verifier discover community authority, issuer key, schema, policy version, and current status.
03 · DeDi publication profile
Publish authority, not private identity.
The proposed verified namespace is theinternetofvalue.org. The names and fields below are a non-normative IoV profile for technical discussion with NFH.
| Registry | Purpose | Minimum public fields | Example |
|---|---|---|---|
| communities-v1 | Recognised IoV community expressions. | community_id, canonical_name, community_type, governance_uri, authority_scope, status, validity | houseofbros; growth-flow-engineering; iov-research-foundation |
| credential-issuers-v1 | Which DID may issue which credential type. | issuer_did, community_ref, credential_types, public_key_ref, policy_refs, status | GFE issuer authorised for GfeSkillAttainmentCredential |
| credential-schemas-v1 | Exact machine-readable credential contract. | schema_id, credential_type, version, context_uri, json_schema_uri, status, supersedes | iov:gfe-skill-attainment:0.1 |
| skill-frameworks-v1 | Community level system and assessment rubric. | framework_id, axes, level_scale, rubric_uri, version, content_hash, status | GFE-x.y.z; Marketing, Sales, Finance; L0-L4 |
| credential-status-services-v1 | Issuer status or revocation service without a subject roster. | service_id, issuer_did, purpose, endpoint, mechanism, version, status | OpenCred status mechanism - to confirm with NFH |
Allowed public records
Communities, issuer DIDs, public keys, schema versions, authority scopes, policy references, service endpoints, suspensions, and revocations.
Excluded by default
Names, emails, Value Logs, raw proofs, private Wellbecoming facets, WellbeingScore, complete Wellbeing Identity documents, validator reasoning, and public member rosters.
04 · Candidate credential
GFE Skill Attainment v0.1
The first pilot should use synthetic or explicitly approved test evidence. GFE defines the skill system; its authorised community process approves the level; OpenCred packages the claim.
The internal ProtocolLinkId remains inside the IoV audit chain. The credential receives an opaque attestation reference and holder-safe digest so it cannot become a lookup key for private life.
{
"@context": [
"https://www.w3.org/ns/credentials/v2",
"https://spec.theinternetofvalue.org/contexts/gfe-skill-v0.1"
],
"id": "urn:uuid:<credential-id>",
"type": ["VerifiableCredential", "GfeSkillAttainmentCredential"],
"issuer": "did:web:growthflowengineering.xyz",
"validFrom": "<RFC3339 timestamp>",
"credentialSubject": {
"id": "did:iov:member:<uuid-v4>",
"skillSystem": "GFE-x.y.z",
"marketingLevel": "Lx",
"salesLevel": "Ly",
"financeLevel": "Lz",
"community": "~Growth Flow Engineering~",
"attestationRef": "urn:iov:attestation:<opaque-id>",
"evidenceDigest": "sha256:<holder-safe-digest>",
"policy": {
"id": "gfe-skill-attestation",
"version": "<version>",
"contentHash": "sha256:<policy-hash>"
}
},
"credentialSchema": {
"id": "https://spec.theinternetofvalue.org/schemas/gfe-skill-v0.1.json",
"type": "JsonSchema"
},
"credentialStatus": {
"id": "<OpenCred status reference>",
"type": "<mechanism confirmed with NFH>"
}
}Non-normative draft. OpenCred proof format, status type, context support, and exchange protocol require NFH confirmation.
05 · Verification contract
Resolve before trusting.
Integrity is necessary. Contextual trust also resolves authority, scope, policy, freshness, status, and the holder’s presentation conditions.
GET https://api.dedi.global/dedi/
theinternetofvalue.org/
credential-issuers-v1/
growth-flow-engineering
Verifier checks:
1. DeDi response proof and LIVE registry state
2. issuer DID and public-key authorization
3. credential type + schema + policy version
4. OpenCred credential proof and status
5. holder presentation and purpose constraints06 · Lifecycle and redress
Trust continues after issuance.
Credential history, community attestation, identity projection, and directory state remain separate but traceable. Corrections create new records; they do not rewrite the past.
01
Observed
A private occurrence is recorded. No credential exists.
02
Validated
The community applies a declared policy; an append-only attestation records the decision.
03
Issued
OpenCred packages the approved, minimized claim for the holder.
04
Presented
The holder chooses a verifier, purpose, scope, and presentation.
05
Challenged
A dispute references the original attestation and policy; prior history is preserved.
06
Superseded or revoked
A new decision and status event replace the active claim without deleting the old record.
07 · HouseOfBros boundary
Recognisable as a community. Never a public wellbeing leaderboard.
Appropriate DeDi records
- Canonical community identity and type.
- Authorised issuer DID, public keys, policy references, and validity.
- Credential types and roles it is actually authorised to issue.
- Suspension, revocation, and supersession of that authority.
Prohibited or unsuitable records
- A complete Wellbeing Identity or private Aura View.
- Physiology, emotion, feeling, thought, habit, raw narrative, or validator reasoning.
- A universal “well person” credential or public human-worth score.
- A public membership roster without an explicit, purpose-bound decision.
08 · Questions for NFH
Technical discovery agenda
- 01Which W3C VC data-model version and credential formats does OpenCred support?
- 02Which issuance and presentation protocols are supported, including OID4VCI or OID4VP if applicable?
- 03Which DID methods, proof suites, selective-disclosure formats, and wallet hand-offs are supported?
- 04What is OpenCred’s status and revocation mechanism, and how does zero storage coexist with issuer audit obligations?
- 05How should DeDi represent issuer delegation, key rotation, schema supersession, and status-service discovery?
- 06What proof does a DeDi lookup return, and which verifier library or endpoint should relying parties use?
- 07Which sandbox, rate limits, webhook signatures, data-residency terms, and production guarantees apply?
09 · Pilot acceptance
Evidence that the bridge works
- 01A relying party resolves GFE’s recognised community and issuer authority through DeDi.
- 02The party verifies one OpenCred credential without contacting GFE manually.
- 03The verifier resolves the exact GFE schema, rubric, policy version, and issuance key.
- 04No Value Log narrative, private Wellbecoming state, validator reasoning, or complete Wellbeing Identity enters DeDi.
- 05A correction or revocation is observable while original records remain auditable.
- 06Word Wallet can hold or reference the credential without surrendering disclosure authority.
10 · Proposed engagement
Build the smallest credible bridge.
Architecture workshop
Confirm authority, identity, privacy, and verification boundaries.
DeDi sandbox
Create the domain namespace and minimum public registries.
OpenCred issuance
Issue one synthetic GFE credential into a test holder flow.
Adversarial lifecycle test
Challenge, suspend, supersede, and revoke without deleting history.
Word Wallet adapter
Test holder custody or reference while preserving disclosure control.
Joint learning note
Publish confirmed interoperability, limitations, and unresolved standards work.
Source of Truth (Specs)
Grounded claims and explicit hypotheses
IoV protocol names, identity nodes, Performance gating, SAOcommons attestations, and ProtocolLinkId lineage come from canonical specifications. OpenCred and DeDi details come from their official materials. Proposed registry names, schemas, and adapter behavior remain non-normative pending NFH review.
Authored by Moses Sam Paul Johnraj for the Internet of Value Research Foundation. Working proposal dated 03 August 2026. Publication does not imply endorsement or partnership by Networks for Humanity.