Credentials
Tenzro Network implements W3C Verifiable Credentials to enable cryptographically verifiable claims about identities. Credentials provide a standard mechanism for issuing, presenting, and verifying attestations such as KYC certifications, capability authorizations, and payment approvals while preserving privacy and enabling selective disclosure.
W3C Verifiable Credentials Overview
A Verifiable Credential (VC) is a tamper-evident credential whose authorship can be cryptographically verified. VCs consist of claims made by an issuer about a subject, packaged with metadata and a cryptographic proof. The W3C VC Data Model defines a standard format that works across different blockchain networks and identity systems.
The core participants in the VC ecosystem are:
Issuer: An entity that creates credentials by making claims about subjects. Issuers sign credentials with their private keys to provide cryptographic proof of authorship.
Holder: An entity that possesses one or more credentials and can present them to verifiers. Holders maintain custody of their credentials and control when to disclose them.
Subject: An entity about whom claims are made in the credential. Often the subject and holder are the same entity, but they can be different.
Verifier: An entity that receives credentials from holders and cryptographically verifies their authenticity and validity.
Credential Structure
A Tenzro verifiable credential contains standard W3C properties plus protocol-specific extensions for delegation and inheritance:
{
"@context": [
"https://www.w3.org/2018/credentials/v1",
"https://tenzro.network/ns/credentials/v1"
],
"id": "https://tenzro.network/credentials/550e8400-e29b-41d4-a716-446655440000",
"type": ["VerifiableCredential", "KycCredential"],
"issuer": {
"id": "did:tenzro:issuer:kyc-provider-001",
"name": "Tenzro KYC Provider"
},
"issuanceDate": "2024-01-15T10:30:00Z",
"expirationDate": "2025-01-15T10:30:00Z",
"credentialSubject": {
"id": "did:tenzro:human:550e8400-e29b-41d4-a716-446655440000",
"kycTier": "Enhanced",
"tierLevel": 2,
"verificationDate": "2024-01-15",
"countryOfResidence": "US"
},
"proof": {
"type": "Ed25519Signature2020",
"created": "2024-01-15T10:30:00Z",
"verificationMethod": "did:tenzro:issuer:kyc-provider-001#key-1",
"proofPurpose": "assertionMethod",
"proofValue": "z5bX7jHmP9JKsqW2YxRvNqH8CzAuNDfKjPp7b3vZxM..."
}
}
Core Properties
@context: JSON-LD contexts that define the semantics of the credential. Tenzro includes both the W3C standard context and a protocol-specific context for custom claim types.
id: A unique identifier for this credential, typically a UUID-based URI.
type: An array of types describing the credential. Always includes "VerifiableCredential" plus specific types like "KycCredential", "CapabilityCredential", or "PaymentAuthorizationCredential".
issuer: The DID of the entity that issued the credential, along with optional human-readable metadata.
issuanceDate: The timestamp when the credential was created.
expirationDate: Optional timestamp when the credential expires and should no longer be considered valid.
credentialSubject: Claims about the subject. This is the core payload containing attestations and assertions.
proof: Cryptographic proof that enables verification. Contains the signature type, verification method reference, and the signature value.
Credential Types
KYC Credentials
KYC credentials attest to the identity verification level of a human user. Tenzro defines four KYC tiers, each requiring progressively more verification:
{
"type": ["VerifiableCredential", "KycCredential"],
"credentialSubject": {
"id": "did:tenzro:human:550e8400...",
"kycTier": "Full",
"tierLevel": 3,
"verificationDate": "2024-01-15",
"countryOfResidence": "US",
"verificationMethods": [
"government_id",
"biometric_verification",
"address_verification",
"financial_background_check"
],
"maxTransactionLimit": "1000000000000000000000" // 1000 TNZO
}
}
KYC tiers: Unverified (0), Basic (1), Enhanced (2), Full (3). Higher tiers unlock greater transaction limits and access to regulated financial services.
Capability Credentials
Capability credentials authorize specific actions or access to resources. These are particularly important for machine identities that operate autonomously:
{
"type": ["VerifiableCredential", "CapabilityCredential"],
"credentialSubject": {
"id": "did:tenzro:machine:controller:7c9e6679...",
"capabilities": [
"inference_request",
"model_download",
"settlement_create",
"payment_authorize"
],
"resourceScopes": [
"models:gpt-4:read",
"models:claude-3-opus:read",
"models:*:execute"
],
"maxConcurrentInferences": 100,
"allowedProviders": ["*"]
}
}
Payment Authorization Credentials
Payment authorization credentials enable delegated spending authority with fine-grained controls:
{
"type": ["VerifiableCredential", "PaymentAuthorizationCredential"],
"credentialSubject": {
"id": "did:tenzro:machine:controller:7c9e6679...",
"maxTransactionValue": "1000000000000000000", // 1 TNZO
"maxDailySpend": "5000000000000000000", // 5 TNZO
"allowedPaymentProtocols": ["Mpp", "X402"],
"allowedChains": [1337, 1, 137],
"allowedAssets": ["TNZO", "USDC", "USDT"],
"validFrom": "2024-01-15T00:00:00Z",
"validUntil": "2024-12-31T23:59:59Z"
}
}
Attestation Credentials
Attestation credentials provide cryptographic proof of specific facts, such as TEE hardware capabilities or inference result integrity:
{
"type": ["VerifiableCredential", "TeeAttestationCredential"],
"credentialSubject": {
"id": "did:tenzro:machine:7c9e6679...",
"teeProvider": "IntelTdx",
"hardware": "Intel Xeon Sapphire Rapids",
"attestationReport": "AgAAAMoKAAAOAAwAAAABAA...",
"measurements": {
"mrenclave": "a1b2c3d4e5f6...",
"mrsigner": "f6e5d4c3b2a1..."
},
"verifiedCapabilities": [
"confidential_computing",
"secure_key_storage",
"remote_attestation"
]
}
}
Credential Issuance
Credentials are issued by authorized entities through the Tenzro identity registry. The issuance process involves creating the credential structure, signing it with the issuer's private key, and optionally anchoring it to the blockchain:
// Rust SDK example - Issuing a KYC credential
use tenzro_identity::{IdentityRegistry, Credential, CredentialType};
use tenzro_crypto::{Ed25519Signer, Signer};
let registry = IdentityRegistry::new();
let issuer_did = "did:tenzro:issuer:kyc-provider-001";
let subject_did = "did:tenzro:human:550e8400-e29b-41d4-a716-446655440000";
// Create credential claims
let credential_data = serde_json::json!({
"kycTier": "Enhanced",
"tierLevel": 2,
"verificationDate": "2024-01-15",
"countryOfResidence": "US"
});
// Issue and sign credential
let credential = registry.issue_credential(
issuer_did,
subject_did,
CredentialType::Kyc,
credential_data,
Some(chrono::Utc::now() + chrono::Duration::days(365))
).await?;
// Credential is now cryptographically signed and ready for presentation
println!("Credential ID: {}", credential.id);
Issuer Authorization
Not all identities can issue credentials. Issuers must be explicitly authorized by the network governance or by possessing specific issuer credentials themselves. This creates a web of trust with traceable credential chains.
# Register as an authorized KYC issuer
tenzro-cli identity add-credential \
--did "did:tenzro:issuer:kyc-provider-001" \
--type "IssuerAuthorization" \
--issuer "did:tenzro:governance:root" \
--scope "KycCredential" \
--tier-max 3
Credential Inheritance
One of Tenzro's key innovations is automatic credential inheritance from human identities to their controlled machine identities. When a human receives a credential, all of their machine agents automatically inherit that credential, subject to delegation scope constraints.
Inheritance Mechanism
Credential inheritance follows the controller relationship defined in DIDs:
# Human receives KYC credential
Human DID: did:tenzro:human:550e8400-e29b-41d4-a716-446655440000
Credential: KycCredential (tier 2, Enhanced)
Issuer: did:tenzro:issuer:kyc-provider-001
# Machine automatically inherits
Machine DID: did:tenzro:machine:did:tenzro:human:550e8400...:7c9e6679...
Inherited Credential: KycCredential (tier 2, Enhanced)
Original Issuer: did:tenzro:issuer:kyc-provider-001
Inheritance Chain: issuer → human → machine
Inherited credentials retain their original issuer and issuance date but include additional metadata indicating the inheritance path. This enables verifiers to trace the trust chain and apply appropriate validation logic.
Scope-Limited Inheritance
Delegation scopes can limit which credentials are inherited. For example, a machine with limited payment authority might inherit a human's KYC credential but not their full payment authorization:
# Machine delegation scope restricts inheritance
{
"delegationScope": {
"inheritedCredentialTypes": [
"KycCredential",
"CapabilityCredential"
],
"excludedCredentialTypes": [
"FullPaymentAuthorizationCredential"
],
"maxInheritedTransactionValue": "1000000000000000000"
}
}
Credential Verification
Credential verification ensures that a credential is authentic, has not been tampered with, and remains valid. Tenzro implements multi-layered verification combining cryptographic signature checks, blockchain anchoring verification, and revocation status checks.
Verification Process
// Rust SDK example - Verifying a credential
use tenzro_identity::{IdentityRegistry, Credential};
let registry = IdentityRegistry::new();
// Receive credential from holder
let credential_json = /* credential from presentation */;
let credential: Credential = serde_json::from_str(&credential_json)?;
// Step 1: Verify cryptographic signature
let signature_valid = registry.verify_credential_signature(&credential).await?;
// Step 2: Check expiration
let not_expired = credential.expiration_date
.map(|exp| exp > chrono::Utc::now())
.unwrap_or(true);
// Step 3: Check revocation status
let not_revoked = !registry.is_credential_revoked(&credential.id).await?;
// Step 4: Verify issuer authorization
let issuer_authorized = registry.verify_issuer_authorization(
&credential.issuer,
&credential.credential_type
).await?;
// Step 5: Verify trust chain for inherited credentials
let trust_chain_valid = if credential.is_inherited() {
registry.verify_inheritance_chain(&credential).await?
} else {
true
};
let valid = signature_valid
&& not_expired
&& not_revoked
&& issuer_authorized
&& trust_chain_valid;
if valid {
println!("Credential verified successfully");
} else {
println!("Credential verification failed");
}
Cryptographic Proof Verification
The proof field contains a cryptographic signature over the canonical serialization of the credential. Tenzro supports multiple signature types:
// Ed25519Signature2020
{
"type": "Ed25519Signature2020",
"verificationMethod": "did:tenzro:issuer:kyc-001#key-1",
"proofValue": "z5bX7jHmP9JKsqW2YxRvNqH8CzAuNDfKjPp7b3vZxM..."
}
// EcdsaSecp256k1Signature2019
{
"type": "EcdsaSecp256k1Signature2019",
"verificationMethod": "did:tenzro:issuer:kyc-001#key-2",
"proofValue": "zAn8Y3K2mP9LqW3XyVvQrI9DzBvOEgLkK..."
}
// BbsBlsSignature2020 (for selective disclosure)
{
"type": "BbsBlsSignature2020",
"verificationMethod": "did:tenzro:issuer:kyc-001#key-3",
"proofValue": "kJqW5Z4lN0ObR1SuTwOsPj3EyGxQfMnH..."
}
Selective Disclosure
Selective disclosure enables holders to reveal only specific claims from a credential without exposing all data. This is critical for privacy-preserving credential presentations.
BBS+ Signatures
Tenzro supports BBS+ signatures on BLS12-381 curves for selective disclosure. With BBS+, a holder can create a derived proof showing only selected attributes:
# Original credential has many claims
{
"credentialSubject": {
"id": "did:tenzro:human:550e8400...",
"kycTier": "Enhanced",
"tierLevel": 2,
"dateOfBirth": "1990-05-15",
"countryOfResidence": "US",
"verificationDate": "2024-01-15"
}
}
# Derived proof reveals only kycTier and countryOfResidence
{
"credentialSubject": {
"id": "did:tenzro:human:550e8400...",
"kycTier": "Enhanced",
"countryOfResidence": "US"
},
"proof": {
"type": "BbsBlsSignatureProof2020",
"verificationMethod": "did:tenzro:issuer:kyc-001#key-3",
"proofValue": "kJqW5Z4lN0ObR1SuTwOsPj3...",
"revealedAttributes": ["kycTier", "countryOfResidence"]
}
}
The verifier can cryptographically verify that these revealed attributes came from the original credential without learning any of the hidden attributes.
Credential Revocation
Issuers can revoke credentials before their expiration date. Tenzro implements both on-chain revocation registries and privacy-preserving revocation lists.
Revocation Registry
# Revoke a credential
tenzro-cli identity revoke-credential \
--credential-id "https://tenzro.network/credentials/550e8400..." \
--issuer "did:tenzro:issuer:kyc-provider-001" \
--reason "Information no longer current"
# Check revocation status
tenzro-cli identity check-revocation \
--credential-id "https://tenzro.network/credentials/550e8400..."
# Output
Status: REVOKED
Revocation date: 2024-03-20T14:22:00Z
Reason: Information no longer current
Cascading Revocation
When a human's credential is revoked, all inherited instances in controlled machine identities are automatically revoked as well:
# Revoke human's KYC credential
Revoked: did:tenzro:human:550e8400...
Credential: KycCredential
# Cascaded revocations
Automatically revoked inherited credentials:
- did:tenzro:machine:...:7c9e6679... (KycCredential)
- did:tenzro:machine:...:9f4a2c81... (KycCredential)
- did:tenzro:machine:...:1a5b3c7d... (KycCredential)
Credential Presentation
Credential holders present credentials to verifiers through Verifiable Presentations (VPs). A VP is a container for one or more credentials, signed by the holder to prove possession:
{
"@context": [
"https://www.w3.org/2018/credentials/v1",
"https://tenzro.network/ns/credentials/v1"
],
"type": ["VerifiablePresentation"],
"verifiableCredential": [
{ /* KYC credential */ },
{ /* Payment authorization credential */ }
],
"holder": "did:tenzro:human:550e8400-e29b-41d4-a716-446655440000",
"proof": {
"type": "Ed25519Signature2020",
"created": "2024-03-20T15:00:00Z",
"verificationMethod": "did:tenzro:human:550e8400...#key-1",
"proofPurpose": "authentication",
"challenge": "a1b2c3d4e5f6...",
"proofValue": "z7qY9kR3mN8JsW4VxQoLiH5..."
}
}
The presentation proof includes a challenge provided by the verifier, preventing replay attacks. The holder signs the entire presentation with their private key, proving they possess the credentials and control the associated DID.
Integration with Payments
Credentials integrate tightly with Tenzro's payment protocols (MPP and x402). Payment authorization credentials enable machine identities to execute transactions within defined limits:
// Payment flow with credential verification
// 1. Resource server issues HTTP 402 challenge
HTTP/1.1 402 Payment Required
WWW-Authenticate: MPP realm="inference-api"
// 2. Machine presents payment authorization credential
POST /pay
{
"presentation": {
"verifiableCredential": [
{ /* PaymentAuthorizationCredential */ }
],
"proof": { /* holder signature */ }
},
"amount": "100000000000000000", // 0.1 TNZO
"resource": "/inference/gpt-4"
}
// 3. Server verifies credential and processes payment
// 4. Server grants access to resource
The delegation scope in the credential is enforced during payment verification, ensuring the machine cannot exceed its authorized spending limits.
CLI and SDK Usage
Tenzro provides comprehensive tooling for credential management through the CLI and SDK:
# Issue a credential (requires issuer authorization)
tenzro-cli identity add-credential \
--subject "did:tenzro:human:550e8400..." \
--type "KycCredential" \
--claims '{"kycTier": "Enhanced", "tierLevel": 2}' \
--expiration "2025-01-15T00:00:00Z"
# List credentials for an identity
tenzro-cli identity list-credentials \
--did "did:tenzro:human:550e8400..."
# Verify a credential
tenzro-cli identity verify-credential \
--credential-file credential.json
# Create a verifiable presentation
tenzro-cli identity create-presentation \
--holder "did:tenzro:human:550e8400..." \
--credentials credential1.json,credential2.json \
--challenge "a1b2c3d4e5f6..." \
--output presentation.json