FAQ

You are on: International (jiaozi.io)

Is a credential from the China site (jiaozi.tech) different from one from the international site (jiaozi.io)?

No difference. Credentials from both portals are identical and equally valid: all are issued by the Singapore node into one global ledger with globally unique credential IDs, verifiable by anyone at either portal or the public API.

The portals differ in only two aspects, neither of which affects the credential itself:

• Intake path: the China site (operated by Q Jupiter Technology) handles intake and the Singapore issuing node performs technical issuance; the international site connects to Singapore directly.
• Jurisdiction: the China site operates under PRC laws; the international site operates under international rules.

Which portal to use depends on your compliance environment, not on which credential you want — it is the same credential.

Why does my credential DID point to jiaozi.io?

JIAOZI is built on an "onshore intake, neutral issuance" architecture: Q Jupiter Technology (jiaozi.tech) handles identity intake and verification inside China, while technical issuance and anchoring are performed by the JIAOZI Singapore issuing node (jiaozi.io). That is why every credential DID points to jiaozi.io — the single global issuing anchor, guaranteeing that one agent identity resolves to the same trusted source in every region and under every standard.

Do I have to use your website to verify a credential?

No. Verification public keys are published with the credential, so signatures can be verified in your own environment with any standards-compliant third-party open-source tool. We also ship open-source SDKs (npm / PyPI) and a credential inspector that verifies locally in your browser. The website checker is a convenience, and verification never depends on our systems being online.

What are trust levels T0–T3?

A trust level answers one question: how far we verified the party behind the credential. There are four levels, they only go up, every credential states its level, and anyone can look it up for free:

• T0 Named holder — key possession (credential bound to the agent key) + self-asserted account name + at least one contact channel confirmed by one-time code (China site: phone and email; international site: email, phone optional). The credential is not anonymous: we record who it was issued to and how to reach them. This is the baseline for every tier, including the free Personal tier.
• T1 Verified individual — on top of T0, a three-factor consistency check of name, ID number and phone number through a licensed channel; we record only match/no-match, never the raw ID number or any image. Liveness face match is an optional upgrade. An identity-verified person stands behind the credential. Pro tier; by request on the China site, not yet offered on the international site.
• T2 organization tier — the product is the credential. Claiming this tier requires organization verification as the second step (important; often called KYB): company-registry match, corporate-domain email and operator authorization. Once approved, the organization name appears on the credential and DID document and every agent under the entity inherits it. Included in Business, a Pro add-on; online application is open. We do not sell verification as a separate product.
• T3 Enhanced organization verification — on top of T2, supplementary documents, video verification, call-back, ultimate-beneficial-owner (UBO) check and human review with a full audit trail. For counterparties with stricter risk requirements; Platinum, by arrangement — contact us.

Why does even the free Personal tier require a named holder?

Because verifying and claiming are different acts. Verification is always anonymous, free and account-less — nobody has to tell us who they are to check a credential. Claiming means we issue a credential, and even a free one must be traceable to a holder, or it means nothing to the party verifying it. The free tier asks for the minimum: name and email, plus a phone number on the China site (optional internationally). Contact channels are confirmed by one-time code — an unreachable email is no registration at all.

Is T3 a regulatory-compliance grade or an official recognition?

No. T3 is the most rigorous technical verification within our capability: more documents, a longer process, human review and a full audit trail. It claims no legal effect of an electronic signature, is not compliance in any financial, anti-money-laundering or sector-regulatory sense, and implies no endorsement by any government or regulator. Where legal effect or licensed compliance is required, that part is provided by licensed institutions; we provide the technical verification and issuance layer.

Does a higher level make the credential technically stronger?

They are different things. The trust level says who stands behind the credential and how far we verified them. The credential also states the attestation form of the runtime — software-measured (owner-key binding + code-metric hash, available now), cloud-attested (roadmap), hardware TEE/TPM (roadmap) — which says whether it is running the code it claims right now. The three forms suit different deployments; they are not a ranking and are not limited by tier: a T0 personal agent may run inside a TEE, and a T3 enterprise agent may rely on software measurement alone.

What trust level does a sub-agent have?

Sub-agents inherit the main agent’s trust level through the delegation chain — no separate verification, no slot, no charge; up to 100 concurrently valid sub-agents per main agent. At the cap, new registrations pause and expansion can be requested; nothing is hard-rejected. That number is a quota, not an abuse control: delegation-chain depth is a policy set by each verifier (our first implementation defaults to 3 hops), and the sub-agent registration endpoint is rate-limited separately. Every agent under a T2 entity shows the same verified organization name; the chain itself is published with the credential, so a verifier can trace each link back to the main agent and its holder.

As a verifier, how should I use trust levels?

Treat it as a risk input, not a pass. Low-risk interactions (reading public data, trials) can accept T0; anything involving funds, data authorization or long-term cooperation should require T2 or above and check the organization name; where your counterparty risk bar is higher, require T3. Combine level, attestation form and the declared behavior boundary into your own policy. The level is exposed as the trustTier field of the public API; the SDK’s requireTrust currently gates on attestation form and behavior boundary — gating by trust level is on the roadmap.

What is a Level of Assurance (LoA)?

A Level of Assurance is the identity industry’s standard way of grading how confident one can be that a party is who it claims to be. ISO/IEC 29115 defines LoA 1–4: LoA 1 is self-asserted with no verification; LoA 2 requires identity information with some (possibly remote) verification; LoA 3 requires stronger verification and cross-checks; LoA 4 usually requires in-person verification. The EU eIDAS levels Low / Substantial / High correspond to LoA 2 / 3 / 4.

A single 29115 level bundles two steps: how identity was verified at enrollment, and how each operation is confirmed to come from that party. NIST SP 800-63 later split them — identity proofing (IAL), authenticator strength (AAL) and federation (FAL) are graded separately — because combinations such as “rigorously verified but weakly protected keys” cannot be expressed by one number.

How do trust levels map to LoA, NIST and eIDAS?

We follow NIST’s split: T levels correspond only to the identity-proofing step (≈ IAL); attestation forms correspond to key custody and runtime (≈ AAL); delegation chains correspond to federation (≈ FAL). The table below maps T levels to the identity-proofing step of each standard. It is an approximation for professionals and not a conformance claim against any standard or regulation:

• LoA 4 / IAL3 strictly require in-person or supervised remote proofing; only T3’s video verification comes close, so LoA 4 is not claimed.
• T1 collects no face data by default: the three-factor check already matches the name and ID number against authoritative sources, which is sufficient for holding an agent credential accountable, while biometric data carries an order of magnitude more compliance burden and breach consequence. Liveness face match is an optional upgrade only where genuinely needed.
• Attestation forms (software-measured / cloud-attested / hardware TEE·TPM) correspond to the key-custody side of AAL; they are stated separately and are not part of this table.

Is this an electronic certification service under the PRC Electronic Signature Law?

No. Q Jupiter Technology performs identity verification onshore; technical issuance of credentials is performed by the JIAOZI Singapore issuing node. This service provides technical identity verification — proving that an agent holds a key, runs certain code, and what its status is right now. It does not constitute electronic certification services under the PRC Electronic Signature Law, and implies no government or regulatory endorsement. For legally binding signatures, use a licensed onshore e-signature provider.

I am in China but do not read Chinese — what should I do?

The China site offers multiple interface languages, and switching language never leaves the site. Language (interface text) and region (service jurisdiction) are two independent switches: use the language toggle to change text; use the region switch only when you actually need a different jurisdiction — it will clearly state the change of operating entity.

Will submitting the same agent twice create two credentials?

No. The deduplication key is applicant key + code digest: repeat submissions with the same key and the same code idempotently return the existing credential. The same code under a different key may get its own credential, but the transparency ledger shows both point to the same digest.

Verifier

High-value Q&As on using the verifier and presenting credentials to third parties. Full wording lives in VERIFIER_FAQ.

What is the verifier? Is verification free?

The verifier is a free identity check desk: enter an AI agent's credential ID or DID and learn in seconds who it is, whether the credential is backed by a verifiable mechanism, and whether it is still valid. No signup, no install. Main page: /verifier; the home page also has a short showcase.

Verification is free forever (resolve / status / badges / embed / public VC export). Charges apply to issuance (subscription seats, T2). Claiming T2 requires organization verification as the second step (important); we do not sell verification as a separate product.

Is “verify” the same as “claim / apply”?

No. Using the verifier checks whether someone else’s credential is valid (free). Cryptographic verification proves a VC / status was not tampered with. Claiming / issuance is applying for a credential for your own agent. The verifier will not issue you a credential in one click — issuance needs a local Validator check plus keys.

What should I enter to verify?

A credential ID (e.g. demo JIAOZI-2026-000027, or legacy JP-2026-000016) or a DID. Case-insensitive; JJ- normalizes to JP-.

The other party’s verifier wants a URL / JSON / file / QR — what do I give?

There is one authoritative payload: the W3C VC. Everything else is another way to hand over the same thing. If unsure what they need → give the public verification link first.

Example verification link: https://www.jiaozi.io/api/certs/{id}/vc. You can also copy JSON, download a .json file, or show a verification QR (whose content is that same link).

Verification QR vs display QR — what’s the difference?

A verification QR opens the machine-readable VC URL for third-party verifiers. A display QR opens the credential card page for humans. Do not treat the display QR as a third-party verification QR.

Do all third-party verifiers accept a URL?

No. Some want pasted JSON or a file upload; some only speak API / wallet protocols. Keep the share pack complete: link + JSON + file + verification QR; machines use the same URL.

Does a VerifierPlus Warning “isn't in a known issuer registry” mean failure?

It is not a signature failure. It means their known-issuer registry does not list our issuer DID (their trust policy). Format, signature, non-revoked, and non-suspended checks can still pass. Until listed in their registries, that Warning is basically normal on VerifierPlus.

Why doesn’t a third-party result show “permissions”?

Generic third-party verifiers check format, signature, expiry, and revocation — the cryptographic interoperability floor (P0). Trust tier, behavior boundary, and API gatekeeping are JIAOZI higher-layer semantics (status / requireTrust), visible in the JIAOZI verifier or SDK gates.

Will China-standard / SM2 alignment show up on VerifierPlus?

Do not expect that. VerifierPlus checks the international W3C / Ed25519 layer. GB/Z 185 semantics and the CN-side SM2 parallel endorsement are a separate rail; international tools may ignore SM2. For SM2, self-verify the public status with SM2-with-SM3–capable tools.

How do I embed the verifier on my site?

Use the script badge (data-jiaozi-verify) or an iframe: /embed/{id}. Status comes from the API — the host page cannot fake a green result. See the developer docs.

When will wallet presentation be available?

On the roadmap. We open a pilot once there is a clear customer requiring wallet flows (OID4VP / CHAPI); we will not hard-build it without demand. For agent scenarios, prefer fetching the same VC via API.

Verification troubleshooting cheatsheet

• Not found → wrong ID or not issued: check prefix/digits, or apply.
• Third party rejects → you pasted a credential ID or status, not the VC: paste the public /vc verification link.
• VerifierPlus Warning → not in their registry: policy, not crypto; check whether signature items are green.
• Embed stays grey → network or wrong ID: check the API in devtools; verify data-jiaozi-verify.
• Need a permissions conclusion → use JIAOZI status / requireTrust, not a generic VC tool alone.