TROP · VCAL · OIDC FEDERATION · W3C BITSTRING STATUSComing soon

Trust between issuers and verifiers, made programmable.

Setu is the governance layer for digital credential ecosystems — the trust registry that decides which issuers are trusted, which credential types are authorised and which verifiers and wallets can participate. Not infrastructure. Trust governance.

Get notified at launchJoin waitlist
setu.sovio.id / resolve
v1.8
Overview
Receipts
Purposes
Revoke
Audit
Export
Active trust resolution
Sovio Setu
active
TROP · TRUST RESOLVE
did:example:abc123
credential type
degree · university-network
governance
v1.2 · authorised
Bitstring status listprivacy-preserving
status_list:0xabcd…12345not revoked
One registry. Many ecosystems. Programmable trust at population scale.

Setu combines TROP, VCAL, OIDC Federation and W3C Status Lists into one unified trust registry — built on the open-source CREDSEL project.

TROP · Trust Registry Query ProtocolVCAL · Verifiable Credential Authority ListOpenID Connect FederationIETF OAuth Status ListW3C Bitstring Status ListW3C Verifiable CredentialsDID · Decentralised IdentifiersCREDSEL · LF Decentralized TrustMulti-Ecosystem GovernanceTROP · Trust Registry Query ProtocolVCAL · Verifiable Credential Authority ListOpenID Connect FederationIETF OAuth Status ListW3C Bitstring Status ListW3C Verifiable CredentialsDID · Decentralised IdentifiersCREDSEL · LF Decentralized TrustMulti-Ecosystem GovernanceTROP · Trust Registry Query ProtocolVCAL · Verifiable Credential Authority ListOpenID Connect FederationIETF OAuth Status ListW3C Bitstring Status ListW3C Verifiable CredentialsDID · Decentralised IdentifiersCREDSEL · LF Decentralized TrustMulti-Ecosystem Governance
01 · The problem

Credentials are easy. Ecosystem-scale trust is not.

01
Ecosystems fail without a registry
N²bilateral trust relationships verifiers manage manually

Without a trust registry, every verifier is on their own.

There is no authoritative answer to a fundamental question: should this verifier trust this credential from this issuer? Verifiers build fragile allow-lists, duplicate verification logic and create inconsistent trust policies across the ecosystem. Trust becomes bilateral, brittle and impossible to govern.

02
Manual issuer lists don't scale
500+issuers that no verifier can manually track

500 issuers, 5 ecosystems — no spreadsheet will save you.

When a university network has 500 member institutions — or an inter-departmental government programme spans education, healthcare and welfare — no verifier can manually maintain a current list of authorised issuers, their DIDs, their credential types and their revocation status. Manual trust is fragile, outdated and vulnerable to error.

03
Revocation must be private and scalable
0leaks to the issuer on each verification — by design

Calling the issuer on every verify is a tracking vector — and a bottleneck.

Checking whether a credential is revoked should not require contacting the issuer for every verification. Privacy-preserving mechanisms — bitstring status lists and referencable status entries — let verifiers confirm validity without revealing who is being verified or which entry was checked. A trust registry orchestrates them across the ecosystem.

Step 01 · Onboard

Issuers, verifiers and wallets register against the ecosystem governance framework

Each participant publishes a DID, metadata and credential-type authorisations. The ecosystem operator signs an entity statement that anchors the participant in the trust chain.

One framework. Many participants. One signed statement each.

03 · Three pillars of Sovio Setu

The governance layer that makes credential ecosystems actually work.

Operated by the ecosystem authority, resolved by every verifier and wallet, interoperable across every issuer in the network.

PILLAR 01
Trust Registry as Source of Truth

Authoritative list of trusted issuers, verifiers, wallets and credential types. The single registry every participant resolves against — no bilateral allow-lists.

PILLAR 02
Standards-Based Resolution

TROP for queries. VCAL for VC-native trust lists. OIDC Federation for OAuth trust chains. W3C and IETF status lists for revocation. One unified architecture, not competing silos.

PILLAR 03
Multi-Ecosystem Governance

Operate many independent trust ecosystems from one deployment — each with isolated participants, governance versions and policies. Built on the open-source CREDSEL project.

04 · End-to-end flow

Holder · Verifier · Registry — trust resolved in sub-second latency.

  1. 00:00
    Holder presents a credential to a verifier
    A graduate shares a verifiable presentation of their degree with a hiring platform. The presentation includes the Issuer DID, the credential type and the credential itself.
  2. 00:01
    Verifier extracts trust parameters
    The verifier pulls the Issuer DID, the credential type identifier and the credential status reference from the presentation — the trust query is composed.
  3. 00:02
    Verifier queries Setu via TROP
    Using the Trust Registry Query Protocol, the verifier sends a trust resolution request to the Setu registry for this issuer and credential type.
  4. 00:03
    Registry resolves issuer trust status
    Setu checks the Issuer DID against the authorised issuer list, validates the OIDC Federation entity statement or VCAL entry, and confirms the issuer is not suspended.
  5. 00:04
    Registry resolves credential type authorisation
    Setu verifies the credential type is authorised for this issuer under the active governance framework — and has not been deprecated.
  6. 00:05
    Registry checks credential status
    Setu resolves the status reference against the active W3C Bitstring or IETF Status List — confirming not revoked, suspended or expired. No issuer call-out.
  7. 00:06
    Registry returns a signed trust decision
    Authorised, revoked, suspended or unknown — with governance framework version, timestamp and signature. Sub-second latency, end to end.
  8. 00:07
    Verifier makes the access decision
    Based on the trust status the verifier accepts or rejects. An audit event is logged with the trust resolution reference for compliance.
05 · Key capabilities

Everything an ecosystem operator needs to govern digital trust.

  1. 01Issuer onboarding — register DIDs, metadata and credential-type authorisations.
  2. 02Verifier onboarding — control scope, permissions and access policies per verifier.
  3. 03Wallet trust registration — certify wallet providers and publish compatibility.
  4. 04Credential type authorisation — govern which issuers can issue which types.
  5. 05Governance policies — versioned rules, ELA criteria and ecosystem compliance.
  6. 06Multi-ecosystem support — many isolated ecosystems from one deployment.
  7. 07TROP query API — programmatic trust resolution, sub-second latency.
  8. 08Status lists — W3C Bitstring & IETF OAuth status, privacy-preserving by design.
06 · Standards & protocols

Composed from W3C, IETF, OpenID — orchestrated by Setu.

Framework
Title
How Setu applies it
TROP
Trust Registry Query Protocol
A full standard for querying trust registries. Defines how verifiers, issuers and wallets programmatically resolve trust against the registry. Supports ecosystem-specific policies.
VCAL
Verifiable Issuers & Credential Authority List
VC-ecosystem-native trust list. Trusted issuers and credential types are listed, signed by the ecosystem authority and distributed for offline verification.
OIDC Federation
OpenID Connect Federation
Signed entity statements and trust chains for OAuth and OpenID Connect participants. Establishes hierarchical trust between operators, issuers and verifiers.
IETF Status List
OAuth Token Status List
Privacy-preserving status mechanism for OAuth and SSI tokens. Referencable status lists enable revocation without revealing individual status.
W3C Bitstring
Bitstring Status List
Compact, privacy-preserving VC status entries — holders prove a credential is not revoked without revealing the specific revocation entry.
CREDSEL
LF Decentralized Trust project
Setu is built on CREDSEL, the open-source registry implementation under the Linux Foundation's Decentralized Trust initiative.

Any organisation that operates or participates in a governed digital credential ecosystem.

07 · Technical depth

For architects, security engineers and compliance teams.

setu · trust-metadata.jsonVCAL · OIDC Fed
{
  "issuer_did":         "did:example:abc123",
  "ecosystem":          "university-network",
  "credential_types":   ["degree", "transcript"],
  "status":             "authorized",
  "governance_version": "v1.2",
  "entity_statement": {
    "sub": "did:example:dept456",
    "iss": "did:example:university",
    "metadata": {
      "credential_types": ["degree"],
      "authority_bits":   ["did:example:ecosystem-operator"]
    }
  }
}
// TROP · GET /registry/resolve
query = { issuer_did, credential_type, ecosystem };
registry.validateEntityStatement(query.issuer_did);
registry.checkTypeAuthorisation(query);
registry.checkStatusList(query.status_ref);
return { trust: "authorized", gov_version: "v1.2", ts, sig }
Resolve
< 1 s
TROP trust query
Protocols
TROP · VCAL
OIDC Fed · status lists
APIs
REST · Events
sync resolve · async streams
Open source
CREDSEL
LF Decentralized Trust
multi-ecosystem by design

Run many independent trust ecosystems from one deployment — each with isolated participants, governance versions and policies. Built on the open-source CREDSEL project.

TROP queries VCAL trust lists OIDC Federation Privacy-preserving status Multi-ecosystem CREDSEL · open source
REGISTER · PUBLISH · RESOLVE · AUDITComing soon

See Sovio Setu
in your ecosystem.

Sovio Setu is launching soon. Join the waitlist to get early access, launch updates and a direct line to our team for design-partner conversations.

Join the waitlist Get launch updates