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
W3C Compliance
Grantex VCs conform to:Issuing a Verifiable Credential
Request a VC during token exchange by setting thecredentialFormat 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 signedwebauthnEvidence 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:- Decoding the VC-JWT (standard JWT decode)
- Resolving the issuer DID (
did:web:grantex.devresolves tohttps://grantex.dev/.well-known/did.json) - Extracting the public key from the DID document
- Verifying the JWT signature against the public key
- Checking the
credentialStatusendpoint for revocation - If WebAuthn evidence is required, checking the trusted RP ID/origin, assertion signature/challenge/counter, and grant-reference digest
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
- Each credential is assigned a
statusListIndex(a position in the bitstring) - The status list credential is published at a public URL (
/v1/credentials/status/:id) - When a grant is revoked, Grantex sets the bit at that index
- Verifiers fetch the status list and check the bit to determine revocation
Checking Status
Revocation Timing
When you revoke a grant viaDELETE /v1/grants/:id or an enabled irregularity cascade, the following database changes happen atomically:
- The grant record is marked as revoked
- The StatusList2021 bit is flipped (VC shows as revoked)
- All delegated sub-grants are cascade-revoked (and their VCs)
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
- FIDO2 / WebAuthn — passkey-based human presence verification
- DID Infrastructure — how the issuer DID works
- Grant Token — the standard JWT-based grant token
- Multi-Agent Delegation — delegation chains in VCs