Skip to content

Identity Grades

Identity grade answers the question: "what do we know, cryptographically, about who this entity is?" It is the first axis in the two-axis model. No amount of substantive evidence can substitute for it when the tier label matters.

The I0–I4 ladder

Identity grades are categorical. Higher grades require progressively stronger cryptographic binding. The grade is computed from the entity's identity bindings.

I0 — Self-asserted only

The entity has a Bukti account but no third-party binding. Any name, any claimed identity. Evidence submitted by an I0 entity may be genuine, but Bukti cannot connect it to a verifiable real-world person or organization.

Examples: a new account that has only filled in a profile form, with no connected accounts.

Effect: regardless of substantive score, the entity's tier is capped at Self-declared.

I1 — Email or domain control proven

The entity has demonstrated control of an email address (via DKIM verification) or a domain (via a did:web document at /.well-known/did.json on a domain they control). This is a weak but non-trivial identity signal: harder to fabricate than I0.

Qualifying methods: verified email (DKIM), did:web on a controlled domain.

Examples: verified email address, did:web:company.com from a company website.

Effect: tier is capped at Self-declared. I1 establishes some identity continuity but not enough for the Attested or Verified tiers.

I2 — Single platform OIDC binding

The entity has authenticated to Bukti via one OIDC provider and that binding has been verified. The OIDC token binds a real account on a real platform to the Bukti identity. Creating a plausible fake account with multi-year history requires non-trivial effort, raising the cost of identity fabrication.

Qualifying methods: OIDC against a major identity provider (GitHub, Google, Microsoft).

Effect: entity is eligible for the Attested tier when substantive evidence clears the mid-substantive thresholds. Not eligible for Verified.

I3 — Two independent OIDC bindings or one institutional VC

The entity satisfies one of two conditions:

  1. Two or more independent OIDC providers are bound. "Independent" means distinct providers — two bindings to the same provider from different accounts count as one provider, not two, to prevent a user from creating multiple accounts on a single provider and claiming independence.
  2. One institutional Verifiable Credential (Open Badges 3.0 format with valid VC 2.0 proof) from an issuer in the trusted registry has been verified and its subject DID is bound to the Bukti entity.

Examples: GitHub + Google Workspace both connected and OIDC-verified; a university-issued Open Badges 3.0 credential for a completed course.

Caveat: institutional VC signature verification is in progress. Today the system accepts Open Badges 3.0 credentials on record integrity (the credential record exists and was imported) and logs a warning. Full cryptographic signature verification against the issuer's DID document, plus Sigstore-based commit-signing verification for behavioral artifacts, are on the near-term roadmap. Until then, I3 via institutional VC is a partial elevation. See limitations.md.

Effect: entity is eligible for Verified when substantive evidence also clears the high-substantive thresholds.

I4 — Government/institutional KYC with cryptographic credential

The entity has undergone a Know Your Customer identity check through a government or regulated institutional process, and holds a cryptographically signed credential attesting to that verification.

Examples: government-issued digital identity credential, notarized DID document.

I4 trumps all lower grades. Any entity with an I4-qualifying method is assigned I4 regardless of other bindings.

Effect: eligible for Verified under the same substantive conditions as I3.

Status: I4 is defined in the system but no issuance pipeline exists today. Reserved for regulated-profession use cases (licensed professionals, enterprise customers).