Skip to main content

Overview

The Grantex-hosted service enabled opt-in portable WebAuthn assertion evidence on September 27, 2026. Self-hosted deployments must enable it explicitly. The current TypeScript, Python, and Go SDKs listed in Release Status expose typed grant-evidence references and VC attestations. Grantex can issue W3C Verifiable Credentials (VCs) alongside standard RS256 JWTs. While grant tokens are optimized for real-time authorization (short-lived, revocation-checked, scope-enforced), Verifiable Credentials provide a portable, standards-compliant proof of authorization that any party can verify independently using the Grantex DID document.
Verifiable Credentials are opt-in. Existing token exchange flows continue to work unchanged. Pass credentialFormat: "vc-jwt" during token exchange to receive a VC alongside the standard grant token.Portable WebAuthn evidence additionally requires PORTABLE_WEBAUTHN_EVIDENCE_ENABLED=true, IRREGULARITY_CASCADE_REVOCATION_ENABLED=true, and PORTABLE_WEBAUTHN_EVIDENCE_STATUS_CHECK_ENABLED=true on the auth service (all source defaults are off). Keep the latter two safety flags on if issuance is rolled back. The current primary SDKs expose the typed reference; independent verification still requires checking the VC, assertion, trusted origin, and current status.

Why Verifiable Credentials?

Grant tokens work well within systems that integrate with Grantex. But in agentic commerce, agents interact with third-party services that may have no relationship with Grantex:
  • A payment processor needs proof that the agent is authorized to spend on the user’s behalf
  • A contract-signing service needs proof of human consent
  • An insurance API needs proof of delegated authority from a specific principal
Verifiable Credentials provide a signed document that a verifier can check using published keys without a Grantex account. The verifier must trust the issuer’s enrollment and authorization process, and revocation checks require current status-list data.

W3C Compliance

Grantex VCs conform to:

Issuing a Verifiable Credential

Request a VC during token exchange by setting the credentialFormat parameter:

Credential Types

AgentGrantCredential

Issued for direct grants (user authorizes an agent directly). The credential subject attests that a specific principal authorized a specific agent with specific scopes.

DelegatedGrantCredential

Issued for delegated grants (agent delegates to a sub-agent). Includes the full delegation chain for traceability.

Portable WebAuthn Evidence

With portable evidence enabled, for a new passkey-approved grant, Grantex stores the verified assertion and includes a signed webauthnEvidence reference in the grant token. When credentialFormat is vc-jwt or both, the VC’s evidence array contains a GrantexWebAuthnAssertion with version: 1, authRequestId, credentialId, base64url credentialPublicKey, previousCounter, rpId, origin, challenge, base64url clientDataJSON, authenticatorData, signature, userVerified, assertedAt, and a SHA-256 hex digest. With the rollout flag enabled (or for already-evidenced grants), the VC and grant commit together and failed requested VC issuance fails the exchange. Existing grants cannot acquire past assertion evidence retroactively. When an agent delegates a grant, the child token and opt-in VC inherit the original assertion reference/evidence only after Grantex checks it against the signed parent reference. This proves the original principal ceremony in the chain, not a new human approval of the delegation. Requested delegated VCs also commit atomically with their child grant. The digest is SHA-256 of the UTF-8 bytes of compact JavaScript JSON.stringify output (no added whitespace) for this ordered array: [authRequestId, credentialId, credentialPublicKey, previousCounter, rpId, origin, challenge, clientDataJSON, authenticatorData, signature, userVerified, assertedAt]. It binds the compact grant reference to the exact exported assertion. Verify the issuer signature and status, pin the expected RP ID and origin, recalculate the digest, then verify the WebAuthn signature and challenge using the included public key and prior counter. The webauthnVerified field from /v1/credentials/verify reports successful assertion verification, not independent customer-identity verification. The authenticator signs the challenge, not the grant/scopes; the Grantex issuer signature binds them and attests enrollment. Trust in the issuer’s enrollment and identity checks remains essential. Raw public keys are correlatable, so request and distribute these VCs only when needed.

Verifying a VC

Using the Grantex SDK

Independent Verification

Any party can verify a Grantex VC without the SDK by:
  1. Decoding the VC-JWT (standard JWT decode)
  2. Resolving the issuer DID (did:web:grantex.dev resolves to https://grantex.dev/.well-known/did.json)
  3. Extracting the public key from the DID document
  4. Verifying the JWT signature against the public key
  5. Checking the credentialStatus endpoint for revocation
  6. If WebAuthn evidence is required, checking the trusted RP ID/origin, assertion signature/challenge/counter, and grant-reference digest
No Grantex account or API key is required for verification. The DID document and status list endpoints are public, but the verifier still needs a trusted issuer policy and fresh status data.

Revocation via StatusList2021

Grantex uses the W3C StatusList2021 standard for credential revocation. Each VC references a position in a bitstring-based status list. When a grant is revoked, the corresponding bit is flipped.

How It Works

  1. Each credential is assigned a statusListIndex (a position in the bitstring)
  2. The status list credential is published at a public URL (/v1/credentials/status/:id)
  3. When a grant is revoked, Grantex sets the bit at that index
  4. Verifiers fetch the status list and check the bit to determine revocation

Checking Status

Revocation Timing

When you revoke a grant via DELETE /v1/grants/:id or an enabled irregularity cascade, the following database changes happen atomically:
  1. The grant record is marked as revoked
  2. The StatusList2021 bit is flipped (VC shows as revoked)
  3. All delegated sub-grants are cascade-revoked (and their VCs)
The Redis revocation cache is updated after commit; the database remains authoritative. An issuer-side check for evidence-bearing VCs also consults their stored grant status. Independent verifiers must check a fresh status list; a signature and WebAuthn assertion alone do not establish current authorization. Operators should run the historical VC reconciliation when upgrading a deployment that previously used grant-only irregularity revocation.

Listing Credentials

Mastercard Verifiable Intent

Grantex VCs have some building blocks relevant to agentic commerce, but no Mastercard certification or full Verifiable Intent interoperability is claimed:

API Reference

Next Steps

Ownership

Grantex is owned by Orchestrum Technologies LLP. Inventor and owner: Sanjeev Kumar. Ownership contact: sanjeev@orchestrum.in or mishra.sanjeev@gmail.com.
Last modified on September 28, 2026