Trust & Schema Governance

Prerequisites

This is typically the first step in your TCS integration. You need:

• An organization name and contact email
• A secure password (min 8 characters, uppercase + lowercase + number)
• A unique tenant identifier for your organization

What is the Trust Registry?

The Trust Registry is the root of trust within a TCS deployment. Before an organization can issue or verify credentials in that deployment, it must register and receive an approved identity. This ensures every credential traces back to a known, vetted entity within the deployment — eliminating anonymous issuance.

TCS operates a scoped issuer allowlist: each tenant (e.g. Turing Certs) is added to the allowlist after registration and approval, and verifiers configured against the same Trust Registry will accept their credentials. This is intentionally a centralized governance model — it is not OpenID Federation, EBSI TIR, or an ETSI/eIDAS Trusted List. Cross-ecosystem trust (e.g. presenting a TCS-issued credential to a verifier in another ecosystem) bridges through the X.509 / x5c path with an externally-anchored CA — see Architecture & Security and the Standards Compliance roadmap.

When a verifier receives a credential, it checks the iss claim against the Trust Registry’s approved issuer list — ensuring every credential traces to a registered, vetted entity.

Registration Flow

Step 1: Apply to join (out of band)

Trust Registry onboarding is handled by the TCS team, not via a public API — the Trust Registry is a root of trust and approval requires identity review. To register your organization:

1. Contact us with your organization name, your intended tenant slug (lowercase letters / digits / hyphens, 3–32 chars — e.g. acme-corp), and the email of the engineering owner who will integrate.
2. We review and provision your account on the Trust Registry.
3. You receive two distinct credentials, delivered once via an encrypted channel:
   • A UUID + initial password — identify your tenant on the Trust Registry login (POST /v1/auth/login below) and on DID lifecycle endpoints (/v1/did/*).
   • A separate Issuer API key — used in the X-API-Key header on POST /v1/offers and POST /v1/verifier/authorization-request.
4. The two credentials are not interchangeable; storing them in a secret manager keyed by tenant is the simplest pattern.

Store the credentials

The UUID, password, and Issuer API key are delivered once. Store them in your secret manager / KMS keyed by tenant. Do not commit any of them to source.

Step 2: Log In

Exchange your UUID and password for a JWT access token. The Trust Registry rate-limits this endpoint to 5 attempts per 60 seconds.

curl -X POST https://trust-registry.turingspace.co/v1/auth/login \
  -H "Content-Type: application/json" \
  -d '{
    "uuid": "f47ac10b-58cc-4372-a567-0e02b2c3d479",
    "password": "SecurePass123"
  }'

Success (200 OK):

{
  "access_token": "eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiJmNDdhYzEwYi01OGNjLTQzNzItYTU2Ny0wZTAyYjJjM2Q0NzkiLCJpYXQiOjE3MTk0MDAwMDAsImV4cCI6MTcxOTQ4NjQwMH0.signature",
  "expires_in": 86400
}

Error (401 Unauthorized):

{
  "statusCode": 401,
  "message": "Invalid credentials"
}

Error (403 Forbidden):

{
  "statusCode": 403,
  "message": "Account not approved"
}

Parameter	Type	Required	Description
uuid	string	Yes	UUID returned from the apply step
password	string	Yes	Password set during registration

Step 3: Create a DID

Create a new DID (Decentralized Identifier) anchored on the IOTA network. Send an empty body with your JWT in the Authorization header.

curl -X POST https://trust-registry.turingspace.co/v1/did \
  -H "Authorization: Bearer eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiJmNDdhYzEwYi01OGNjLTQzNzItYTU2Ny0wZTAyYjJjM2Q0NzkiLCJpYXQiOjE3MTk0MDAwMDAsImV4cCI6MTcxOTQ4NjQwMH0.signature" \
  -H "Content-Type: application/json"

Success (201 Created):

{
  "did": "did:iota:0xabcdef1234567890abcdef1234567890abcdef1234567890abcdef1234567890",
  "private_key": "OKP.Ed25519.eyJrdHkiOiJPS1AiLCJjcnYiOiJFZDI1NTE5IiwiZCI6Ijk4..."
}

Store Your Private Key

The private_key is shown only once. Store it in a secrets manager or encrypted vault. You need this key to sign credentials.

Error (401 Unauthorized):

{
  "statusCode": 401,
  "message": "Unauthorized"
}

Error (500 Internal Server Error):

{
  "statusCode": 500,
  "message": "IOTA network error"
}

Step 4: Import an Existing DID (Alternative)

If your organization already owns a DID anchored on the IOTA network, import it instead of creating a new one. This registers the DID in the Trust Registry without generating new key material.

curl -X POST https://trust-registry.turingspace.co/v1/did/import \
  -H "Authorization: Bearer eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiJmNDdhYzEwYi01OGNjLTQzNzItYTU2Ny0wZTAyYjJjM2Q0NzkiLCJpYXQiOjE3MTk0MDAwMDAsImV4cCI6MTcxOTQ4NjQwMH0.signature" \
  -H "Content-Type: application/json" \
  -d '{
    "did": "did:iota:0x9876543210fedcba9876543210fedcba9876543210fedcba9876543210fedcba",
    "private_key": "OKP.Ed25519.eyJrdHkiOiJPS1AiLCJjcnYiOiJFZDI1NTE5IiwiZCI6ImFi..."
  }'

Success (201 Created):

{
  "did": "did:iota:0x9876543210fedcba9876543210fedcba9876543210fedcba9876543210fedcba",
  "status": "imported"
}

Error (400 Bad Request):

{
  "statusCode": 400,
  "message": "Invalid format or verification failed"
}

Error (404 Not Found):

{
  "statusCode": 404,
  "message": "DID not found on IOTA network"
}

Error (409 Conflict):

{
  "statusCode": 409,
  "message": "DID already imported"
}

Error (503 Service Unavailable):

{
  "statusCode": 503,
  "message": "IOTA network unavailable"
}

Parameter	Type	Required	Description
did	string	Yes	Fully qualified IOTA DID
private_key	string	Yes	Base64url-encoded Ed25519 private key for the DID

DID Management

You have two options for establishing your DID identity:

	Create (POST /v1/did)	Import (POST /v1/did/import)
Use when	Starting fresh with no existing DID	You already own a DID on IOTA
Key generation	TCS generates the Ed25519 keypair	You supply the existing private key
Network interaction	TCS anchors a new DID document on IOTA	TCS verifies the DID exists on IOTA
Key custody	You receive and store the private key	You already hold the private key

In both cases, the DID is registered in the Trust Registry and linked to your organization’s account. You use this DID as the issuer identity when creating credential offers.

DID Configuration

The Trust Registry exposes a Well-Known DID Configuration endpoint for each tenant. This follows the DIF Well Known DID Configuration specification, allowing external parties to verify the link between your domain and your DID.

curl https://trust-registry.turingspace.co/.well-known/did-configuration.json/acme-university

Success (200 OK):

{
  "@context": "https://identity.foundation/.well-known/did-configuration/v1",
  "linked_dids": [
    {
      "@context": [
        "https://www.w3.org/2018/credentials/v1",
        "https://identity.foundation/.well-known/did-configuration/v1"
      ],
      "type": ["VerifiableCredential", "DomainLinkageCredential"],
      "issuer": "did:iota:0xabcdef1234567890abcdef1234567890abcdef1234567890abcdef1234567890",
      "issuanceDate": "2025-01-15T09:00:00Z",
      "credentialSubject": {
        "id": "did:iota:0xabcdef1234567890abcdef1234567890abcdef1234567890abcdef1234567890",
        "origin": "https://trust-registry.turingspace.co"
      }
    }
  ]
}

This endpoint is public and requires no authentication. Wallets and verifiers use it to confirm that a DID is controlled by the entity operating the domain.

Schema Registry

The Schema Registry serves VCT (Verifiable Credential Type) metadata for all credential types supported by TCS. It is a read-only discovery service — you query it to understand the structure of credential types before issuing or verifying them.

Both issuers and verifiers reference VCT metadata from the Schema Registry: issuers validate credential offers before issuance; verifiers understand credential structure during presentation verification. All credential types must be registered before issuance.

Discover a Credential Type

curl https://schema-registry.turingspace.co/schemas/TuringCerts_Standard_Credential/v2

Success (200 OK):

{
  "vct": "https://schema-registry.turingspace.co/schemas/TuringCerts_Standard_Credential/v2",
  "name": "Turing Certs Standard Credential",
  "description": "A general-purpose verifiable credential issued through the Turing Credential Service.",
  "claims": [
    {
      "path": ["given_name"],
      "display": [{ "lang": "en-US", "label": "Given Name" }],
      "sd": "allowed"
    },
    {
      "path": ["family_name"],
      "display": [{ "lang": "en-US", "label": "Family Name" }],
      "sd": "allowed"
    }
  ],
  "schema_uri": "https://schema-registry.turingspace.co/schemas/TuringCerts_Standard_Credential/v2"
}

Error (404 Not Found):

{
  "statusCode": 404,
  "message": "VCT not found"
}

Path Parameter	Description
type	The credential type identifier (matches the vct field in issued SD-JWT VCs)
version	The schema version number (e.g., 1.0)

Schema Registry is Read-Only

The Schema Registry is the single source of truth for available credential types — see the full catalog for the current list. To propose a new credential type for your organization, contact the TCS team.

What’s Next

• Issuing Credentials — Issue SD-JWT credentials using your API key and DID
• Verifying Credentials — Verify credential presentations
• Authentication Reference — Understand all authentication patterns