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.

  1. 01Capture

    ~ValueCaptureProtocol

    Creates the TimeSlice, actor attribution, proof references, community context, and immutable ProtocolLinkId.

  2. 02Interpret

    ~WellbecomingProtocol

    Routes the occurrence through one primary Wellbecoming node. Private inner-state records remain private by default.

  3. 03Validate

    ~SAOcommons

    For Performance only, applies a Learning, Earning, or OrgBuilding policy and produces a governed attestation.

  4. 04Project

    ~WellbeingIdentity

    Receives the validated skill or certification into Skills and EarnedIdentity without making the complete identity public.

  5. 05Issue

    OpenCred

    Packages the approved claim as a holder-controlled verifiable credential after the upstream judgment is complete.

  6. 06Resolve

    DeDi

    Lets a verifier discover community authority, issuer key, schema, policy version, and current status.

Runtime boundary: Word Wallet owns the active private projection and disclosure. Value Log owns private evidence and append-only audit records. Foundation renders only minimized, owner-approved public output.

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.

RegistryPurposeMinimum public fieldsExample
communities-v1Recognised IoV community expressions.community_id, canonical_name, community_type, governance_uri, authority_scope, status, validityhouseofbros; growth-flow-engineering; iov-research-foundation
credential-issuers-v1Which DID may issue which credential type.issuer_did, community_ref, credential_types, public_key_ref, policy_refs, statusGFE issuer authorised for GfeSkillAttainmentCredential
credential-schemas-v1Exact machine-readable credential contract.schema_id, credential_type, version, context_uri, json_schema_uri, status, supersedesiov:gfe-skill-attainment:0.1
skill-frameworks-v1Community level system and assessment rubric.framework_id, axes, level_scale, rubric_uri, version, content_hash, statusGFE-x.y.z; Marketing, Sales, Finance; L0-L4
credential-status-services-v1Issuer status or revocation service without a subject roster.service_id, issuer_did, purpose, endpoint, mechanism, version, statusOpenCred 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 constraints

06 · 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.

  1. 01

    Observed

    A private occurrence is recorded. No credential exists.

  2. 02

    Validated

    The community applies a declared policy; an append-only attestation records the decision.

  3. 03

    Issued

    OpenCred packages the approved, minimized claim for the holder.

  4. 04

    Presented

    The holder chooses a verifier, purpose, scope, and presentation.

  5. 05

    Challenged

    A dispute references the original attestation and policy; prior history is preserved.

  6. 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

  1. 01Which W3C VC data-model version and credential formats does OpenCred support?
  2. 02Which issuance and presentation protocols are supported, including OID4VCI or OID4VP if applicable?
  3. 03Which DID methods, proof suites, selective-disclosure formats, and wallet hand-offs are supported?
  4. 04What is OpenCred’s status and revocation mechanism, and how does zero storage coexist with issuer audit obligations?
  5. 05How should DeDi represent issuer delegation, key rotation, schema supersession, and status-service discovery?
  6. 06What proof does a DeDi lookup return, and which verifier library or endpoint should relying parties use?
  7. 07Which sandbox, rate limits, webhook signatures, data-residency terms, and production guarantees apply?

09 · Pilot acceptance

Evidence that the bridge works

  1. 01A relying party resolves GFE’s recognised community and issuer authority through DeDi.
  2. 02The party verifies one OpenCred credential without contacting GFE manually.
  3. 03The verifier resolves the exact GFE schema, rubric, policy version, and issuance key.
  4. 04No Value Log narrative, private Wellbecoming state, validator reasoning, or complete Wellbeing Identity enters DeDi.
  5. 05A correction or revocation is observable while original records remain auditable.
  6. 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.