HYBRID-CHAINDEVELOPERS
DOCUMENTATIONv2
POST

Identity · transfer credentials

Update subject transfer credentials

/api/v2/identity/transfer-credentials/subject/profile/{profile_uuid}
AUTHENTICATIONBearer token · compliance:writeAUTHORITATIVE OWNERidentity-serviceCONTRACT AUTHORITYCapability registry · plannedSTATUSPlanned · not executable
PLANNING CONTRACT · NOT CALLABLE

This page describes intended capability and integration boundaries so people and agents can prepare safely. Do not send this request or register it as an executable tool. Wait until the capability registry marks it implemented-contract, then re-fetch the deployed OpenAPI document and build the request from that machine contract.

PURPOSE + BUSINESS CONTEXT

Planned capability: apply the requested transition to manage subject transfer credentials through the authoritative trust service boundary.

WHEN THIS CALL IS USEFUL

Do not call or register this operation as an executable agent tool yet. Use this page to plan the future manage subject transfer credentials workflow; enable it only after the status becomes implemented-contract and the exact operation appears in deployed OpenAPI.

OUTCOME · Planned · Create or advance

What changes

None today: this route is not executable. Its intended behavior is: no executable facade behavior exists. The canonical implemented operation retains only public wallet reference, proof commitments, network, validity, and owner evidence without accepting private material.

WHY IT MATTERS

  • Lets people and agents prepare for manage subject transfer credentials without falsely presenting roadmap scope as a live capability.
  • Gives people and agents a contract-backed way to advance manage subject transfer credentials.
  • Separates subject identity, consent, evidence, provider output, review, issuer credentials, and relying-party acceptance instead of collapsing them into a universal trust score.

ISOLATION + AUTHORITY

Bearer subject, tenant, purpose, policy version, role, issuer, reviewer, provider, and relying-party boundaries remain distinct. The response or transition grants no payment, custody, settlement, publisher, matching, or trading authority and must not expose regulated evidence beyond the live schema. This planning record grants no runtime authority, and only deployed OpenAPI can define an executable public contract.

BEFORE YOU CALL

  • First confirm that this operation is marked implemented-contract and exists in the currently deployed OpenAPI document; until then, no production request is valid.
  • Its capability-registry profile is provisional integration guidance, not an executable request schema.
  • Authenticate at the documented boundary: bearer+scope.
  • Treat the proposed profile_uuid (path), wallet_reference (body), challenge_commitment (body), proof_commitment (body) as planning input only; re-generate the request from deployed OpenAPI before making a call.
  • Use one Idempotency-Key only for retries of the same byte-equivalent logical mutation.
  • Resolve the applicable purpose, policy version, consent or role basis, and required assurance before relying on this result.

WHAT TO DO NEXT

  • Keep this operation disabled in clients, agents, SDKs, and workflow automation while it remains planned-contract.
  • Use the stated owner, lifecycle, authority boundary, and provisional manage subject transfer credentials profile to prepare requirements and conformance tests without sending a request.
  • Monitor the capability registry for implemented-contract, then re-fetch deployed OpenAPI and validate its exact security, parameters, schemas, responses, and agent metadata before enabling the integration.

AGENT GUIDANCE

  • Never call this planned contract, include it in an executable tool registry, or infer runtime availability from this readable page.
  • Its capability-registry profile is provisional integration guidance, not an executable request schema.
  • Use manage subject transfer credentials only for the purpose and lifecycle stage described by this operation; do not treat it as authority for an adjacent action.
  • Treat the proposed profile_uuid (path), wallet_reference (body), challenge_commitment (body), proof_commitment (body) as planning input only; re-generate the request from deployed OpenAPI before making a call.
  • Treat policy availability, consent, evidence capture, completed checks, review, decision, credential issuance, validity, and relying-party acceptance as separate facts.
  • After a timeout or conflict, read authoritative state before deciding whether an equivalent retry is safe.
  • When implementation lands, discard generated requests based on this planning record and rebuild them from the deployed OpenAPI operation.
MACHINE CONTRACT

This operation is a non-executable planning contract. Its capability-registry record defines the intended owner, parameters, responses, and integration boundary until an implemented Rust OpenAPI operation replaces it.

EXTENDED INTEGRATION GUIDANCE

Readable request and response reference

Examples describe the reviewed planning contract and remain non-executable until promoted into OpenAPI.

PARAMETERS

Headers, path, query, and body

NAMELOCATIONPRESENCETYPE / RULES / PURPOSE
AuthorizationheaderRequired

Bearer tokenCredential containing the wallets:write scope.EXAMPLEBearer hc_live_…

Idempotency-KeyheaderRequired

ASCII string · 1–128Caller-generated key reused for every retry of the same logical mutation.EXAMPLElaunch-treasury-v1-001

Content-TypeheaderRequired

application/jsonSigned mutations accept canonical JSON only.EXAMPLEapplication/json

Content-DigestheaderRequired

RFC 9530 SHA-256 digestDigest of the exact transmitted body bytes.EXAMPLEsha-256=:47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=:

Signature-InputheaderRequired

RFC 9421 signature parametersCovers @method, @path, content-digest, content-type, and idempotency-key; includes keyid, nonce, created, and expires.EXAMPLEsig1=("@method" "@path" "content-digest" "content-type" "idempotency-key");created=1786582800;expires=1786583100;nonce="01J…";keyid="machine-prod"

SignatureheaderRequired

Ed25519 HTTP Message SignatureSignature made by an active public key registered to the authenticated client.EXAMPLEsig1=:base64-signature:

profile_uuidpathRequired

authenticated subject identifierCompatibility selector only. It cannot address another subject or override bearer ownership.EXAMPLEprofile-uuid-01

vault_uuidbodyOptional

32-character identifierSubject primary vault. Omission selects it; any other vault is rejected.EXAMPLE2ec4cd41a4414292bb33f040605a6231

networkbodyOptional

network code · max 32Wallet network; defaults to HYBRID.EXAMPLEhybrid-testnet

wallet_referencebodyRequired

public wallet reference · max 255Public address or account reference only. Private keys, seeds, recovery material, and credentials are forbidden.EXAMPLEwallet-ref-owner-01

verification_methodbodyOptional

identifier · max 64Externally completed proof method; defaults to SIGNED_CHALLENGE.EXAMPLESIGNED_CHALLENGE

challenge_commitmentbodyRequired

64-character SHA-256 digestCommitment to the possession challenge; challenge cleartext is not accepted.EXAMPLEeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee

proof_commitmentbodyRequired

64-character SHA-256 digestCommitment to the independently verified proof; raw signatures are not accepted.EXAMPLEffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff

validity_daysbodyOptional

integer · 1–365Requested proof lifetime; defaults to 90 days.EXAMPLE90

REQUEST

JSON body example

{
  "network": "hybrid-testnet",
  "wallet_reference": "wallet-ref-owner-01",
  "verification_method": "SIGNED_CHALLENGE",
  "challenge_commitment": "eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee",
  "proof_commitment": "ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff",
  "validity_days": 90
}

RESPONSES

Status and payload examples

501Superseded compatibility-shaped planning path; use the implemented canonical wallet-control-proof operation from live OpenAPI.Not executable · JSON RESPONSE+
{
  "code": "planned_contract",
  "canonical_operation": "POST /api/v2/transfer-compliance/wallet-control-proofs"
}
INTEGRATION DECISIONplanned_contract
CALLER ACTION
Do not send this request or register it as an executable agent tool. Use the implemented alternatives linked by the module guide.
RETRY SAFETY
Do not retry on a timer. Re-fetch production OpenAPI and proceed only after this exact operation appears there.
STATE RECONCILIATION
No runtime state exists to reconcile for this planning contract. Continue from the authenticated profile, tenant brand, referral, funding, and account-lifecycle projections through an implemented operation.
ESCALATE WHEN
Escalate when a fresh session resolves to an unexpected tenant or profile, or when an account lifecycle receipt cannot be found after reconciliation.

OPERATIONAL NOTES

Security and lifecycle guarantees

  • Do not call this path. Use implemented POST /api/v2/transfer-compliance/wallet-control-proofs; this request profile exists only to make legacy business parity and the migration decision explicit.
  • The path profile_uuid never grants cross-subject access. Canonical V2 derives subject and workspace from the bearer and owner-checks the primary vault.
  • Submit only public wallet reference and proof commitments to the canonical route. Never submit private keys, seeds, raw possession signatures, challenge cleartext, identity documents, or credentials.
  • Wallet-control posture is readiness evidence, not formal credential issuance, consent, transfer approval, wallet signing authority, broadcast authority, settlement, or value movement.
DOCUMENTATION STATUS

This planned contract now defines its public parameters, authorization boundary, replay behavior, responses, and authoritative owner. It remains non-executable until its owner adapter and conformance tests are promoted into the Rust gateway.

Return to the V2 directory