Go-Trust

Overview

Go-Trust is a multi-framework AuthZEN Trust Decision Point (PDP) server. It evaluates trust decisions across multiple trust registries including ETSI TS 119 612 Trust Status Lists (TSLs), ETSI TS 119 602 Lists of Trusted Entities (LoTEs), OpenID Federation, and DID Web.

Go-Trust is designed to run inside the same trust domain as the entity that relies on trust evaluation (for instance a wallet unit or an issuer). It promotes interoperability across implementations that rely on ETSI trust status lists such as the EUDI wallet.

Note: For TSL and LoTE processing (load, transform, convert, sign, publish), use tsl-tool from g119612. Go-trust consumes pre-processed TSL/LoTE data.

Features

AuthZEN Compliant: Implements the OASIS AuthZEN Trust Registry Profile for policy decisions
Multi-Registry Architecture: Parallel evaluation across ETSI TSL, ETSI LoTE, OpenID Federation, and DID Web
Flexible Resolution Strategies: First-match, all-registries, best-match, or sequential
Circuit Breaking: Graceful handling of registry failures
Rate Limiting: Per-IP rate limiting for API protection
Prometheus Metrics: Comprehensive observability support
Kubernetes Native: Liveness and readiness probes, ConfigMap support
Test Server: Embedded test server for integration testing
X5C Enrichment: Certificate policy OID validation and RP identity extraction
Swagger UI: Built-in API documentation at /swagger/
High Quality: >80% test coverage, comprehensive linting, security scanning

Quick Start

Installation

# Clone and build
git clone https://github.com/sirosfoundation/go-trust.git
cd go-trust
make build

# Or install directly
go install github.com/sirosfoundation/go-trust/cmd/gt@latest

Running the Server

# With a PEM certificate bundle (recommended for production)
gt --etsi-cert-bundle /path/to/trusted-certs.pem

# With TSL XML files directly
gt --etsi-tsl-files eu-lotl.xml,se-tsl.xml

# With whitelist registry (for simple deployments)
gt --registry whitelist --whitelist /etc/go-trust/whitelist.yaml

# With always-trusted registry (development/testing only!)
gt --registry always-trusted

# With configuration file
gt --config /etc/go-trust/config.yaml

# With external URL for discovery (behind reverse proxy)
gt --external-url https://pdp.example.com --etsi-cert-bundle certs.pem

# Full configuration
gt \
  --host 0.0.0.0 \
  --port 6001 \
  --etsi-cert-bundle /etc/go-trust/trusted-certs.pem \
  --external-url https://pdp.example.com \
  --log-level info \
  --log-format json

Command-Line Options

Option	Description	Default
`--host`	Listen address	`127.0.0.1`
`--port`	Listen port	`6001`
`--external-url`	External URL for discovery	auto-detect
`--etsi-cert-bundle`	PEM file with trusted CA certs	-
`--etsi-tsl-files`	Comma-separated TSL XML files	-
`--registry`	Registry type: whitelist, always-trusted, never-trusted	-
`--whitelist`	Path to whitelist YAML/JSON config file	-
`--whitelist-watch`	Watch whitelist file for changes	`true`
`--log-level`	Log level: debug, info, warn, error	`info`
`--log-format`	Log format: text, json	`text`
`--config`	Configuration file (YAML)	-

Environment variable: GT_EXTERNAL_URL for external URL.

API Endpoints

Endpoint	Description
`POST /evaluation`	AuthZEN trust evaluation
`GET /.well-known/authzen-configuration`	PDP discovery document
`GET /healthz`	Kubernetes liveness probe
`GET /readyz`	Kubernetes readiness probe (503 until TSLs loaded)
`GET /readyz?verbose=true`	Readiness with detailed TSL info
`GET /metrics`	Prometheus metrics
`GET /registries`	List configured trust registries
`GET /swagger/*`	Swagger UI API documentation

AuthZEN Evaluation Request

{
  "subject": {
    "type": "key",
    "id": "https://issuer.example.com"
  },
  "resource": {
    "type": "x5c",
    "id": "https://issuer.example.com",
    "key": ["MIIDQjCCAiqgAwIBAgIUJlq+zz4..."]
  },
  "action": {
    "name": "credential-issuer"
  }
}

Action Parameters

The action.parameters field allows clients to include role-specific constraints in the request. A common use case is specifying which credential types are being evaluated:

{
  "subject": {"type": "key", "id": "https://issuer.example.com"},
  "resource": {"type": "x5c", "key": ["MIIC..."]},
  "action": {
    "name": "credential-issuer",
    "parameters": {
      "credential_types": ["eu.europa.ec.eudi.pid.1", "eu.europa.ec.eudi.mdl.1"]
    }
  }
}

When credential_types is provided, it enables:

Audit logging: The requested credential types are included in the requested_credential_types field of the response reason for all supporting registries (ETSI TSL, LoTE, OpenID Federation, whitelist)
Policy-based validation: For OpenID Federation, credential types can be mapped to required trust marks via credential_type_trust_marks (see Credential Type to Trust Mark Mapping)
Server-side filtering: For ETSI TSL, credential_types can be set in the policy constraints for server-configured audit (see Credential Types in ETSI TSL)

AuthZEN Evaluation Response

{
  "decision": true,
  "context": {
    "reason": {
      "registry": "etsi-tsl",
      "resolution_ms": 12,
      "service_type": "http://uri.etsi.org/TrstSvc/Svctype/CA/QC"
    }
  }
}

Architecture

Multi-Registry Design

Go-Trust implements a flexible multi-registry architecture that allows multiple trust frameworks to be queried simultaneously.

┌─────────────────┐     ┌─────────────────┐
│  AuthZEN Client │────▶│   Go-Trust PDP  │
└─────────────────┘     └────────┬────────┘
                                 │
    ┌────────┬──────┬────────────┼────────────┬──────────┬────────────┐
    ▼        ▼      ▼            ▼            ▼          ▼            ▼
┌──────┐┌──────┐┌─────────┐┌─────────┐┌───────────┐┌────────┐┌────────┐
│ ETSI ││ ETSI ││ OpenID  ││DID Web/ ││ DID JWKS/ ││ mDOC  ││  RP   │
│ TSL  ││ LoTE ││  Fed    ││ WebVH   ││  Key      ││ IACA  ││ Cert  │
└──────┘└──────┘└─────────┘└─────────┘└───────────┘└────────┘└────────┘

TrustRegistry Interface

All trust registries implement the same interface:

type TrustRegistry interface {
    Evaluate(ctx context.Context, req *authzen.EvaluationRequest) (*authzen.EvaluationResponse, error)
    SupportedResourceTypes() []string
    SupportsResolutionOnly() bool
    Info() RegistryInfo
    Healthy() bool
    Refresh(ctx context.Context) error
}

SupportsResolutionOnly() indicates whether the registry only performs DID/key resolution without trust evaluation (e.g. did:key).

Resolution Strategies

Strategy	Description
`FirstMatch`	Returns as soon as any registry returns `decision=true`
`AllRegistries`	Queries all registries and aggregates results
`BestMatch`	Returns the result with highest confidence
`Sequential`	Tries registries in order until one succeeds

Supported Registry Types

ETSI TSL Registry

Evaluates X.509 certificates against ETSI TS 119 612 Trust Status Lists.

Input sources:

--etsi-cert-bundle: PEM file with trusted CA certificates (processed by tsl-tool)
--etsi-tsl-files: Raw TSL XML files

Supported resource types: x5c, jwk, x509_san_dns

Configuration options (in YAML config file):

lotl_signer_bundle: PEM file containing trusted LOTL signer certificates for signature validation
require_signature: When true, TSLs must have valid signatures (requires lotl_signer_bundle)

OpenID Federation Registry

Evaluates trust chains in OpenID Federation ecosystems.

Supported resource types: entity, openid_federation

DID Web Registry

Resolves and validates DID Web identifiers per W3C DID specification.

DID Web URL Mapping:

did:web:example.com → https://example.com/.well-known/did.json
did:web:example.com:users:alice → https://example.com/users/alice/did.json
did:web:example.com%3A3000 → https://example.com:3000/.well-known/did.json

Supported resource types: key, jwk

DID Web VH Registry

Resolves and validates DID Web VH (Verifiable History) identifiers with cryptographic integrity verification.

Features:

Full DID:web:vh resolution per spec
Cryptographic chain verification
Version history traversal
Pre-rotation key support

Supported resource types: did_document, jwk, verification_method

DID JWKS Registry

Resolves did:jwks identifiers that encode JWKS endpoints directly in the DID. Supports discovery via OAuth2/OIDC metadata endpoints.

Supported resource types: jwk, key

DID Key Registry

Resolves did:key identifiers that encode public keys directly in the DID (no network resolution required). Part of the generic DID resolver framework in pkg/registry/did/.

Supported resource types: jwk, key

mDOC IACA Registry

Dynamically validates mDOC/mDL X.509 certificate chains against IACA (Issuing Authority Certificate Authority) certificates fetched from OpenID4VCI issuers.

Architecture:

Receives trust evaluation with issuer URL (subject.id) and X5C chain (resource.key)
Fetches issuer's OpenID4VCI metadata (discovers mdoc_iacas_uri endpoint)
Fetches IACA certificates from mdoc_iacas_uri
Validates X5C chain against fetched IACAs
Optionally enforces issuer allowlist

Supported resource types: x5c

import "github.com/sirosfoundation/go-trust/pkg/registry/mdociaca"

reg, err := mdociaca.New(&mdociaca.Config{
    Name:            "mdoc-iaca",
    IssuerAllowlist: []string{"https://issuer.example.com"},  // Optional
    CacheTTL:        time.Hour,
})

// Evaluate trust for an mDOC issuer
req := &authzen.EvaluationRequest{
    Subject:  authzen.Subject{Type: "key", ID: "https://issuer.example.com"},
    Resource: authzen.Resource{Type: "x5c", Key: []interface{}{dsB64, iacaB64}},
}
resp, err := reg.Evaluate(ctx, req)

Use cases:

Mobile driving license (mDL) issuer validation
EUDI wallet mDOC credential issuance
Any OpenID4VCI issuer publishing IACA certificates

FIDO MDS3 Registry

Validates a FIDO2/CTAP2 attestation's X.509 certificate chain against the FIDO Alliance Metadata Service v3 (MDS3) — the official, periodically-updated, cryptographically-signed registry of certified authenticator models (e.g. security keys, platform authenticators) and their certification/revocation status.

Architecture:

Fetches the MDS3 blob (JWT-signed), verifies its signature, and indexes entries by AAGUID
Periodically re-fetches on a configurable interval; a transient fetch failure degrades to stale data rather than blanking the index
Optional disk cache (CachePath) lets a process restart serve the last-known-good, re-verified blob immediately instead of blocking on a live fetch
Evaluate() looks up the AAGUID from subject.id, verifies the resource.key X5C chain against that entry's attestation root certificates, and rejects entries whose StatusReports include an undesired status (e.g. revoked, user-verification-bypass)
Optionally enforces a profile-scoped AAGUID allow/blocklist on top of MDS3 status — see Policy Configuration

Supported resource types: x5c

import "github.com/sirosfoundation/go-trust/pkg/registry/fidomds3"

reg, err := fidomds3.New(fidomds3.Config{
    Name:            "fido-mds3",
    RefreshInterval: 24 * time.Hour, // Optional; 0 disables periodic refresh
    CachePath:       "/var/lib/go-trust/fido-mds3.jwt", // Optional disk cache
})
reg.StartRefreshLoop(ctx) // Optional; only needed if RefreshInterval is set

// Evaluate trust for a FIDO2 authenticator's attestation
req := &authzen.EvaluationRequest{
    Subject:  authzen.Subject{Type: "key", ID: aaguid.String()},
    Resource: authzen.Resource{Type: "x5c", Key: []interface{}{attestationCertB64}},
}
resp, err := reg.Evaluate(ctx, req)

Use cases:

WebAuthn/passkey hardware-key attestation verification
WSCD (Wallet Secure Cryptographic Device) provisioning, where only AAGUIDs with a confirmed-working feature (e.g. previewSign) should be trusted, tighter than "not revoked"
Denying a specific AAGUID with a known issue even though FIDO Alliance hasn't revoked its certification

LoTE Registry (ETSI TS 119 602)

Evaluates trust from ETSI TS 119 602 Lists of Trusted Entities (LoTE) — the JSON-based successor to XML Trust Status Lists. LoTE documents list trusted entities with their digital identities (X.509 certificates, JWK keys, or DIDs) and service descriptions.

Features:

Loads LoTE JSON from URLs or local files
Indexes entities by ID and digital identity fingerprint
X.509 PKIX path validation against entity certificates
JWK key matching via SHA-256 fingerprints
Optional JWS signature verification on LoTE documents
Periodic refresh with configurable interval

Supported resource types: x5c, jwk

Configuration (YAML config file):

registries:
  lote:
    enabled: true
    name: "LoTE"
    description: "ETSI TS 119 602 List of Trusted Entities"
    sources:
      - "https://example.com/lote-se.json"
      - "https://example.com/lote-de.json"
      - "/etc/go-trust/local-lote.json"
    verify_jws: false
    fetch_timeout: "30s"
    refresh_interval: "1h"

Programmatic usage:

import "github.com/sirosfoundation/go-trust/pkg/registry/lote"

reg, err := lote.New(lote.Config{
    Name:            "lote-eu",
    Sources:         []string{"https://example.com/lote.json"},
    RefreshInterval: time.Hour,
})

// Evaluate trust for an entity
req := &authzen.EvaluationRequest{
    Subject:  authzen.Subject{Type: "key", ID: "https://issuer.example.com"},
    Resource: authzen.Resource{Type: "x5c", Key: []interface{}{certB64}},
}
resp, err := reg.Evaluate(ctx, req)

Use cases:

JSON-native trust evaluation for modern credential ecosystems
LoTE-based trust where entities are identified by JWK, X.509, or DID
Transition from XML TSL to JSON LoTE format

RP Certificate Registry (ETSI TS 119 475)

Validates Relying Party registration certificates per ETSI TS 119 475 and TS 119 411-8. Verifies that a relying party presents a valid registration certificate issued by a recognized authority.

Features:

X.509 certificate chain validation for RP certificates
Certificate policy OID validation
RP identity extraction from certificate Subject DN and SANs

Supported resource types: x5c

Static Trust Registries

The pkg/registry/static package provides simple TrustRegistry implementations for testing, development, and basic use cases:

Registry	Description	Use Case
`AlwaysTrustedRegistry`	Always returns `decision=true`	Testing, development, trust-all scenarios
`NeverTrustedRegistry`	Always returns `decision=false`	Testing trust rejection, deny-all scenarios
`SystemCertPoolRegistry`	Validates X509 against OS CA bundle	Simple TLS trust without ETSI TSL
`WhitelistRegistry`	URL-based whitelist with file watching	Simple issuer/verifier allowlisting

import "github.com/sirosfoundation/go-trust/pkg/registry/static"

// Accept all trust requests (testing only!)
registry := static.NewAlwaysTrustedRegistry("test-always-trusted")

// Reject all trust requests (testing only!)
registry := static.NewNeverTrustedRegistry("test-never-trusted")

// Validate against system CA bundle
registry, _ := static.NewSystemCertPoolRegistry(static.SystemCertPoolConfig{
    Name:        "system-ca",
    Description: "System root CA certificates",
})

// URL whitelist from config file (with auto-reload)
registry, _ := static.NewWhitelistRegistryFromFile("/etc/go-trust/whitelist.yaml", true)
defer registry.Close()

// URL whitelist configured programmatically
registry := static.NewWhitelistRegistry()
registry.AddIssuer("https://pid-issuer.example.com")
registry.AddVerifier("https://verifier.example.com")

WhitelistRegistry Configuration

The whitelist registry supports YAML or JSON configuration files:

# whitelist.yaml
issuers:
  - https://pid-issuer.example.com
  - https://issuer.example.org
  - https://trusted-domain.com/*  # Wildcard prefix match

verifiers:
  - https://verifier.example.com
  - https://rp.example.org

trusted_subjects:
  - https://any-role.example.com  # Matches any role

Features:

Role-based matching: issuers for credential issuers, verifiers for relying parties
Wildcard support: https://example.com/* matches any path under that domain
Global wildcard: * matches all subjects (use with caution)
File watching: Automatically reloads config when file changes (when watch=true)
Runtime updates: AddIssuer(), RemoveIssuer(), AddVerifier(), RemoveVerifier()

Security Note: WhitelistRegistry provides URL-based trust only. Signature verification must be performed at the application layer. For cryptographic trust verification, use ETSI TSL, OpenID Federation, or other advanced registries.

Policy Configuration

Policies map action names (from AuthZEN requests) to registry-specific constraints. This enables role-based trust evaluation where different credential types or participant roles have different requirements.

Configuration Structure

policies:
  # Default policy when action.name doesn't match any specific policy
  default_policy: credential-verifier

  policies:
    # Policy for credential issuers
    credential-issuer:
      description: "Trust requirements for credential issuers"
      
      # ETSI TSL constraints
      etsi:
        service_types:
          - "http://uri.etsi.org/TrstSvc/Svctype/QCert"
          - "http://uri.etsi.org/TrstSvc/Svctype/QCertForESeal"
        service_statuses:
          - "http://uri.etsi.org/TrstSvc/TrustedList/Svcstatus/granted"
      
      # OpenID Federation constraints
      oidfed:
        entity_types:
          - "openid_credential_issuer"
        required_trust_marks:
          - "https://dc4eu.eu/tm/issuer"
      
      # DID constraints (did:web and did:webvh)
      did:
        allowed_domains:
          - "*.eudiw.dev"
          - "*.example.com"
        require_verifiable_history: true

    # Policy for wallet providers
    wallet-provider:
      description: "Trust requirements for wallet providers"
      oidfed:
        entity_types:
          - "wallet_provider"
        required_trust_marks:
          - "https://dc4eu.eu/tm/wallet"
      # Override which registries to query
      registries:
        - "oidfed-registry"

    # Policy for mDL issuers
    mdl-issuer:
      description: "Trust requirements for mDL/mDOC issuers"
      mdociaca:
        issuer_allowlist:
          - "https://pid-issuer.eudiw.dev"
        require_iaca_endpoint: true
      registries:
        - "mdoc-iaca"

    # Policy for WSCD previewSign provisioning: only AAGUIDs confirmed to
    # have a working previewSign implementation are trusted, tighter than
    # "not revoked by FIDO Alliance"
    wscd-previewsign-provision:
      description: "Trust requirements for WSCD previewSign provisioning"
      fidomds3:
        allowed_aaguids:
          - "0132d110-bf4e-4208-a403-ab4f5f12efe5"
      registries:
        - "fido-mds3"

Constraint Types

Constraint Type	Description	Applicable Registries
`etsi`	Service types, statuses, countries, credential types (audit)	ETSI TSL
`lote`	Entity types, statuses, territories, credential types (audit)	ETSI LoTE
`oidfed`	Entity types, trust marks, credential type mapping	OpenID Federation
`did`	Allowed domains, verifiable history	DID Web, DID Web VH
`mdociaca`	Issuer allowlist, IACA endpoint	mDOC IACA
`fidomds3`	AAGUID allowlist/blocklist	FIDO MDS3

AAGUID Policy in FIDO MDS3

For the FIDO MDS3 registry, allowed_aaguids/blocked_aaguids are enforced on top of, never instead of, the registry's own MDS3 status-report and X5C chain verification — a request must still pass MDS3 certification checks regardless of policy. If allowed_aaguids is non-empty, only those AAGUIDs are trusted (allowlist_only semantics), even if MDS3 still certifies others. Otherwise, if blocked_aaguids is non-empty, all MDS3-certified AAGUIDs are trusted except those listed (allow_except_blocklist semantics). If both are set, allowed_aaguids takes precedence. If neither is set — including when no policy matches the request's action.name at all — behavior is unchanged: MDS3 status/chain verification only.

Credential Types in ETSI TSL

For ETSI TSL, credential_types can be supplied by the client via action.parameters or set server-side in the etsi policy constraints. When present, they are included in the requested_credential_types field of every evaluation response (both allowed and denied) for audit purposes. Future versions may use them for filtering against TSL service extensions or metadata.

Client-supplied via action.parameters:

{
  "action": {
    "name": "credential-issuer",
    "parameters": {
      "credential_types": ["eu.europa.ec.eudi.pid.1"]
    }
  }
}

Server-side via policy configuration:

policies:
  policies:
    credential-issuer:
      etsi:
        service_types:
          - "http://uri.etsi.org/TrstSvc/Svctype/QCert"
        credential_types:
          - "eu.europa.ec.eudi.pid.1"

Credential Types in LoTE

For ETSI LoTE (List of Trusted Entities), credential_types supplied via action.parameters are included in the requested_credential_types field of all evaluation responses (both allowed and denied) for audit purposes.

{
  "action": {
    "name": "credential-issuer",
    "parameters": {
      "credential_types": ["eu.europa.ec.eudi.pid.1"]
    }
  }
}

The response will include:

{
  "decision": true,
  "context": {
    "reason": {
      "admin": "Found ...",
      "requested_credential_types": ["eu.europa.ec.eudi.pid.1"]
    }
  }
}

Credential Type to Trust Mark Mapping (OpenID Federation)

For OpenID Federation, you can configure a mapping from SD-JWT VCT values (credential types) to required trust marks. When a client includes credential_types in action.parameters, the policy will derive the required trust marks from the mapping:

policies:
  policies:
    credential-issuer:
      description: "Validate PID and mDL issuers"
      oidfed:
        entity_types:
          - "openid_credential_issuer"
        # Map credential types to required trust marks
        credential_type_trust_marks:
          "eu.europa.ec.eudi.pid.1":
            - "https://trust.eu/tm/pid-issuer"
          "eu.europa.ec.eudi.mdl.1":
            - "https://trust.eu/tm/mdl-issuer"

When a client requests evaluation with:

{
  "action": {
    "name": "credential-issuer",
    "parameters": {
      "credential_types": ["eu.europa.ec.eudi.pid.1"]
    }
  }
}

The OIDF registry will require the entity to have the https://trust.eu/tm/pid-issuer trust mark, in addition to any statically configured required_trust_marks.

Example Request

# Request with action.name to select policy
curl -X POST http://localhost:6001/evaluation \
  -H "Content-Type: application/json" \
  -d '{
    "subject": {"type": "key", "id": "https://issuer.example.com"},
    "resource": {"type": "x5c", "key": ["MIIC..."]},
    "action": {"name": "credential-issuer"}
  }'

X5C Enrichment

When evaluating x5c resources, Go-Trust can enrich evaluation responses with additional information extracted from the leaf certificate:

Certificate Policy OID Validation: Require that the leaf certificate contains specific policy OIDs. Configure via policy constraints or request parameters:

policies:
  policies:
    credential-issuer:
      etsi:
        required_cert_policy_oids:
          - "2.16.840.1.101.2.1.11.36"
          - "1.3.6.1.4.1.311.94.1.1"
        extract_rp_identity: true

Or per-request via action.parameters:

{
  "action": {
    "name": "credential-issuer",
    "parameters": {
      "required_cert_policy_oids": ["2.16.840.1.101.2.1.11.36"],
      "extract_rp_identity": true
    }
  }
}

RP Identity Extraction: When enabled, the response includes the relying party's identity extracted from the leaf certificate:

{
  "decision": true,
  "context": {
    "reason": {
      "matched_policy_oids": ["2.16.840.1.101.2.1.11.36"]
    },
    "trust_metadata": {
      "rp_identity": {
        "organization": ["Example Corp"],
        "common_name": "Example RP",
        "country": ["SE"],
        "serial_number": "1234567890",
        "dns_sans": ["rp.example.com"]
      },
      "matched_policy_oids": ["2.16.840.1.101.2.1.11.36"]
    }
  }
}

X5C enrichment is supported by both ETSI TSL and LoTE registries.

Deployment

Docker

docker build -t go-trust:latest .

docker run -d \
  --name go-trust-server \
  -p 6001:6001 \
  -v /path/to/trusted-certs.pem:/app/certs.pem:ro \
  go-trust:latest --etsi-cert-bundle /app/certs.pem

Kubernetes

apiVersion: apps/v1
kind: Deployment
metadata:
  name: go-trust
spec:
  replicas: 3
  selector:
    matchLabels:
      app: go-trust
  template:
    metadata:
      labels:
        app: go-trust
      annotations:
        prometheus.io/scrape: "true"
        prometheus.io/port: "6001"
    spec:
      containers:
      - name: go-trust
        image: go-trust:latest
        args:
        - --host=0.0.0.0
        - --port=6001
        - --etsi-cert-bundle=/config/trusted-certs.pem
        - --log-format=json
        ports:
        - containerPort: 6001
        livenessProbe:
          httpGet:
            path: /healthz
            port: 6001
          initialDelaySeconds: 10
          periodSeconds: 30
        readinessProbe:
          httpGet:
            path: /readyz
            port: 6001
          initialDelaySeconds: 5
          periodSeconds: 10
        volumeMounts:
        - name: config
          mountPath: /config
      volumes:
      - name: config
        configMap:
          name: go-trust-config

Workflow: TSL Processing + PDP Server

For production deployment, use tsl-tool (from g119612) to process TSLs and generate certificate bundles:

# 1. Process TSLs with tsl-tool
tsl-tool --output trusted-certs.pem pipeline.yaml

# 2. Run gt with the generated certificate bundle
gt --etsi-cert-bundle trusted-certs.pem

Run tsl-tool via cron to update TSL data periodically:

# Crontab entry: Update TSLs daily at 2 AM
0 2 * * * /usr/local/bin/tsl-tool --output /etc/go-trust/trusted-certs.pem /etc/tsl-tool/pipeline.yaml

Prometheus Metrics

The /metrics endpoint exposes:

Metric	Description
`api_requests_total`	HTTP requests by method, endpoint, status
`api_request_duration_seconds`	Request latency histogram
`api_requests_in_flight`	Current active requests
`cert_validation_total`	Certificate validations by result
`cert_validation_duration_seconds`	Validation latency

Example Prometheus queries:

# Request rate by endpoint
rate(api_requests_total[5m])

# 95th percentile latency
histogram_quantile(0.95, rate(api_request_duration_seconds_bucket[5m]))

# Certificate validation error rate
rate(cert_validation_total{result="error"}[5m])

Embedded Test Server

The testserver package provides an embedded test server for integration testing:

import (
    "testing"
    "github.com/sirosfoundation/go-trust/pkg/testserver"
    "github.com/sirosfoundation/go-trust/pkg/registry/static"
)

func TestMyApplication(t *testing.T) {
    // Create a test server that accepts all trust requests
    srv := testserver.New(testserver.WithAcceptAll())
    defer srv.Close()

    // Or use static registries for more control
    srv := testserver.New(testserver.WithRegistry(static.NewAlwaysTrustedRegistry()))
    defer srv.Close()

    // Use srv.URL() to get the server address
    // Make AuthZEN requests to the server
}

Test Server Options

Option	Description
`WithAcceptAll()`	Accept all trust requests
`WithRejectAll()`	Reject all trust requests
`WithRegistry(r)`	Use a specific TrustRegistry implementation
`WithMockRegistry(name, decision, types)`	Add a mock registry
`WithDecisionFunc(fn)`	Dynamic trust decisions

Using Static Registries in Tests

// Test with always-trusted registry
srv := testserver.New(testserver.WithRegistry(static.NewAlwaysTrustedRegistry()))

// Test with never-trusted registry  
srv := testserver.New(testserver.WithRegistry(static.NewNeverTrustedRegistry()))

// Test with system CA validation
srv := testserver.New(testserver.WithRegistry(static.NewSystemCertPoolRegistry()))

// Test with specific whitelist
reg := static.NewWhitelistRegistry()
reg.AddIssuer("https://test-issuer.example.com")
srv := testserver.New(testserver.WithRegistry(reg))

Development

Requirements

Go 1.26+ (check go.mod for exact version)
CGO enabled (CGO_ENABLED=1)
Make for build automation

Building

make build          # Build the binary (./go-trust)
make test           # Run tests with race detection
make coverage       # Generate coverage report
make lint           # Run linters
make quick          # Quick pre-commit checks

Project Structure

go-trust/
├── cmd/gt/            # Main application
├── pkg/
│   ├── api/           # HTTP API implementation (Swagger UI)
│   ├── authzen/       # AuthZEN protocol types
│   ├── authzenclient/ # AuthZEN client library
│   ├── config/        # YAML configuration loading
│   ├── registry/      # Trust registry interface and manager
│   │   ├── etsi/        # ETSI TSL registry (XML, TS 119 612)
│   │   ├── lote/        # ETSI LoTE registry (JSON, TS 119 602)
│   │   ├── oidfed/      # OpenID Federation registry
│   │   ├── didweb/      # DID Web registry
│   │   ├── didwebvh/    # DID Web VH registry
│   │   ├── didjwks/     # DID JWKS registry
│   │   ├── did/         # Generic DID resolver + did:key
│   │   ├── didutil/     # DID utility functions
│   │   ├── mdociaca/    # mDOC IACA registry
│   │   ├── fidomds3/    # FIDO Alliance MDS3 registry
│   │   ├── rpcert/      # RP Certificate registry (TS 119 475)
│   │   └── static/      # Static registries (always/never/system/whitelist)
│   ├── resilience/    # Resilient HTTP fetcher
│   ├── trustapi/      # Trust API evaluator types
│   └── testserver/    # Embedded test server
├── example/           # Example configurations
└── docs/              # Architecture documentation

Contributing

Contributions are welcome! Please read CONTRIBUTING.md for guidelines.

# Development workflow
git checkout -b feature/amazing-feature
make quick && make test
git commit -m 'feat: Add amazing feature'
git push origin feature/amazing-feature
# Open a Pull Request

Related Projects

g119612 - ETSI TSL and LoTE processing library and tsl-tool CLI
go-oidfed/lib - OpenID Federation library
AuthZEN Specification
ETSI TS 119612 - Trust Status Lists (XML)
ETSI TS 119602 - Lists of Trusted Entities (JSON)

License

This project is licensed under the BSD 2-Clause License - see LICENSE.txt for details.

Acknowledgments

ETSI TS 119612 - Trust-service status list format
AuthZEN - Authorization framework
AuthZEN for Trust
SUNET - Swedish University Network
SIROS Foundation

Name		Name	Last commit message	Last commit date
.github		.github
.vscode		.vscode
cmd/gt		cmd/gt
developer_tools/scripts/gen_config_docs		developer_tools/scripts/gen_config_docs
docs		docs
example		example
pkg		pkg
scripts		scripts
tests/contract		tests/contract
.editorconfig		.editorconfig
.gitattributes		.gitattributes
.gitignore		.gitignore
.golangci.yml		.golangci.yml
.testcoverage.yml		.testcoverage.yml
CHANGELOG.md		CHANGELOG.md
CONTRIBUTING.md		CONTRIBUTING.md
DEVELOPER.md		DEVELOPER.md
Dockerfile		Dockerfile
LICENSE.txt		LICENSE.txt
Makefile		Makefile
README.md		README.md
RELEASE_NOTES.md		RELEASE_NOTES.md
go.mod		go.mod
go.sum		go.sum
sonar-project.properties		sonar-project.properties

Uh oh!

Latest commit

History

Folders and files

Repository files navigation

Go-Trust

Overview

Features

Quick Start

Installation

Running the Server

Command-Line Options

API Endpoints

AuthZEN Evaluation Request

Action Parameters

AuthZEN Evaluation Response

Architecture

Multi-Registry Design

TrustRegistry Interface

Resolution Strategies

Supported Registry Types

ETSI TSL Registry

OpenID Federation Registry

DID Web Registry

DID Web VH Registry

DID JWKS Registry

DID Key Registry

mDOC IACA Registry

FIDO MDS3 Registry

LoTE Registry (ETSI TS 119 602)

RP Certificate Registry (ETSI TS 119 475)

Static Trust Registries

WhitelistRegistry Configuration

Policy Configuration

Configuration Structure

Constraint Types

AAGUID Policy in FIDO MDS3

Credential Types in ETSI TSL

Credential Types in LoTE

Credential Type to Trust Mark Mapping (OpenID Federation)

Example Request

X5C Enrichment

Deployment

Docker

Kubernetes

Workflow: TSL Processing + PDP Server

Prometheus Metrics

Embedded Test Server

Test Server Options

Using Static Registries in Tests

Development

Requirements

Building

Project Structure

Contributing

Related Projects

License

Acknowledgments

About

Topics

Resources

Contributing

Security policy

Stars

Watchers

Forks

Releases

Packages

Used by

Contributors

Languages