Check the claim.
Understand the evidence.

What a credential tells you

• A claim is a statement. A signature protects its contents and identifies the issuer; it does not automatically prove the statement is true.
• Custom claims start as SELF_ASSERTED / UNVERIFIED. Editable profile values are labelled PROFILE_ASSERTED / UNVERIFIED in newly issued credentials.
• Values supplied by an approved verification workflow carry separate provenance. A recorded KYC status is not permission to treat every profile field as independently verified.
• Older credentials may lack field-level provenance. Treat missing information as unknown, not verified.

Manage the lifecycle

• In Hybrid-ID, save private claims and explicitly select which commitments enter the next credential.
• Publishing includes the supported profile fields and selected unexpired claims. Claim identifiers, public identity references, issuer, validity dates and status remain visible. Cleartext claim values and supporting evidence stay private.
• Renewal issues a replacement and revokes the previous active credential. A failed database write rolls back both changes. Earlier signed documents and explorer history remain intact.
• Revocation prevents acceptance when verifiers check current status. It does not erase disclosures already received, terminate application sessions or revoke unrelated credentials.
• Verified facts require the verification workflow. User actions do not rotate the issuer’s signing key or change a third-party issuer’s records.

Public verification references

Replace CREDENTIAL_ID with the 32-character credential ID shown in the Trust Center. These public references do not require your Hybrid-ID password, app client secret or developer credential.

The API returns a success envelope with the record under response. Keep the existing issuer identifier and credential URLs when verifying historical records; moving the management UI does not change their issuer.

Verifier acceptance checklist

1. Obtain the credential from a trusted source and match its ID to the record you intend to verify.
2. Resolve the expected issuer through a trusted, configured issuer reference. Do not trust an arbitrary public key embedded in an untrusted document.
3. Validate the issuer signature over the canonical signed document using the declared suite. Check issuer identity, validity dates and current status. Fail closed for revoked, suspended, expired, unknown or unavailable status.
4. Inspect each claim’s provenance and decide whether that assurance meets your application’s policy. Signature validity alone is not a KYC decision.
5. For an interactive proof, bind acceptance to your own outstanding credential/claim/nonce request, expiration and intended context. Consume that request once; reject unrelated or replayed transcripts.

The public service’s issuer_signature_valid and verified fields are service evaluations. Independent cryptographic verification requires implementing or using the matching Hybrid suite, rather than trusting those booleans as an independent check.

The supported proof: matching known data

The deployed format is HybridZkKnownDataProof2026: randomized Pedersen commitments and a Schnorr opening proof, with an Ed25519-signed credential. It confirms that a value the verifier already possesses matches an issued commitment. It is not a general-purpose range-proof or arbitrary-predicate API.

// Known-data scalar; keep the cleartext on the verifier's side.
hex(SHA256("Hybrid-Chain-ZK-v1|" + claimId + "|" + value.normalize("NFC").trim()))

POST .../challenge
{"domain":"your-verifier.example"}
// Save returned uuid, nonce, expires and expected credential/claim locally.

POST .../presentation
{"challenge_uuid":"...","claim":"custom.example","message_scalar":"<hex>"}

POST .../verify
{"message_scalar":"<hex>","presentation":{...}}
// Also enforce your locally stored challenge/context/expiry and one-use policy.

Challenges expire after five minutes and are consumed during presentation generation. The verify endpoint checks cryptographic validity and current credential status; it does not maintain your application’s acceptance session. The domain label is context metadata, not proof that its sender controls that domain. Do not rely on the outer domain field alone for audience binding.

A scalar is derived from known data and may be guessable for low-entropy values. Keep scalars and transcripts out of analytics and logs. This proof service participates in generation; the flow is not evidence of a fully decentralized authentication server.

Implementation reference: Hybrid proof and signature format. Interoperability with generic W3C credential libraries must be checked for this custom suite.

Authentication and management are separate

OIDC sign-in grants the claims explicitly consented to by the user. It does not grant credential publication or revocation. App-registration agent credentials likewise cannot edit identity claims. Canonical owner mutations require a Hybrid-ID account session, trust permission and fresh authenticator authorization.

Hybrid-Chain’s legacy claim and credential management actions now refer users to Hybrid-ID and return 403 HYBRID_ID_MANAGEMENT_REQUIRED. Existing explorer records, read APIs, issuer-operated verification workflows and application compliance remain available.

SSO and developer integration guide · Identity API reference ↗