identityClient
Import
import {
createIdentityResolver,
createIdentityCommitment,
createIdentityProofHash,
getIdentityProfile,
getIdentityPolicy
} from 'shyware/sdk/web/identityClient.js'
Overview
The identity client handles commitment construction, proof hash derivation, IDV session initiation, and input normalization across all identity providers. It is used internally by every embodiment client; it can also be used directly when building custom flows.
All commitment and proof hash values are derived client-side from the shyconfig and the caller's input. No network call is required to produce a commitment.
createIdentityResolver(manifest)
Factory that returns an object with all identity methods bound to the manifest's provider configuration.
const resolver = createIdentityResolver(shyconfig)
const { commitment } = await resolver.createIdentityCommitment({ personId: 'didit-journey-id' })
const { proofHash } = await resolver.createIdentityProofHash({ personId: 'didit-journey-id' })
Commitment construction
const { commitment } = await createIdentityCommitment(manifest, input, options?)
Produces a deterministic hash:
H(namespace : provider : source [:scope])
Where:
namespace—"stable_identity"(voting),"account"(custody/governance), or a custom valueprovider— frommanifest.identity.providersource— provider-specific identifier (see below)
Provider sources
provider | source | Input field |
|---|---|---|
didit (or any managed IDV) | Person ID or journey ID from verified session | input.personId or input.journeyId |
wallet | Wallet address (normalized to lowercase) | input.walletAddress |
none | Fallback value for dev/demo | input.value |
For BYOID inputs — where the developer provides credentials directly rather than going through a managed IDV session — tag the input with sourceProvider: "byoid" and pass it through normalizeByoidIdentity:
import { normalizeByoidIdentity } from 'shyware/sdk/web/providers/byoid.js'
const normalized = normalizeByoidIdentity({ personId, journeyId, proofHash })
// → { sourceProvider: "byoid", personId, journeyId, proofHash, walletAddress, ... }
Proof hash construction
const { proofHash } = await createIdentityProofHash(manifest, input, options?)
Produces a binding hash that ties the commitment to a specific verification workflow:
H("proof" : provider : source : workflowId : issuerDid : scope : audience : nonce)
workflowId and issuerDid are read from the manifest's identity block. nonce is a random value generated per session. The proof hash is submitted alongside the ballot or transaction as evidence that a real IDV workflow was completed for this specific commitment.
IDV session management
The SDK does not ship an IDV session client — which IDV provider you use is a deployment choice, not an SDK primitive. Implement session initiation and status polling in your consumer app, then pass the resulting personId or journeyId to the SDK.
Example using the reference Didit helpers (ship these in your app, not the SDK):
// In your app — not imported from the SDK
import { createDiditSession, getDiditSessionStatus, extractDiditIdentity } from './providers/didit.js'
const { sessionId, sessionUrl } = await createDiditSession({
baseUrl: 'https://api.yourdomain.com',
idToken: bearerToken,
verificationType: 'id_verification'
})
// poll until approved...
const raw = await getDiditSessionStatus({ baseUrl, idToken, sessionId })
const { personId, journeyId } = extractDiditIdentity(raw)
// Now pass to the SDK
await client.voteSubmission({ scopingId, payload, personId })
resolver.normalizeManagedIdentity(status) accepts the already-extracted status object and normalizes it for commitment construction. Your app is responsible for calling your IDV provider's extraction function first.
Input normalization
const normalized = await resolver.normalizeIdentityInput(manifest, input, options?)
Normalizes provider-specific identity inputs to a canonical form before commitment derivation. Useful when building custom flows that need to accept multiple input shapes.
Identity profile
const profile = getIdentityProfile(manifest)
// → { provider, mode, kycRequired, byoidPolicy, recommendedIdv, uiHints }
const policy = getIdentityPolicy(manifest)
// → { byoidPolicy, presentationMode }
getIdentityProfile returns provider-specific UI configuration for rendering identity flows in your application. getIdentityPolicy returns the policy constraints governing byoid (bring-your-own-identity) inputs.
KYB — house entity verification
Individual participant IDV and house entity KYB are separate concerns. The SDK handles individual participant identity (commitment construction, proof hashes). House entity onboarding is an operator-level operation outside the SDK:
| Concern | Actor | Notes |
|---|---|---|
| Individual participant IDV | All participants | Any provider that yields personId/journeyId — implement in your app |
| Entity beneficial-ownership attestation | house (warehouse/vault owner) | KYB via Persona or equivalent; emits a pub_key_hex for house_keys |
The house-onboard CLI tool handles the KYB webhook verification and key admission flow. See the Custody Consortium Governance deployment for the complete house onboarding flow.
Oracle resistance
The identity client enforces oracle resistance at the construction layer:
- The
person_secret(ZK tier) is never passed through this module — it is generated and retained byzkpClientexclusively on the device - Commitment inputs (
personId,walletAddress) are hashed before any network contact - The IDV provider receives only
commitment(a hash) — never the raw identity input, never theperson_secret - The
proofHashbinds the commitment to a workflow without revealing the commitment's preimage to on-chain observers
This is the structural non-transmission guarantee: the IDV provider attests the commitment without ever being able to derive the value that produced it (for the ZK tier) or the on-chain identity hash (for all tiers).