Feature Matrix
OpenEPCIS capabilities by edition, aligned to the relevant GS1 standards.
9 min read
Legend: ✓ = available · ✓ (basic) = available with limitations; see notes · ✓ (variant) = available in a build variant · partial = building blocks present, not fully wired end-to-end · roadmap = planned, not yet started · — = not in this edition.
Capabilities are grouped by the seven module families the platform is organised around — Resolver, Masterdata, EPCIS Events, Formats & Validation, Integration, Access Control, Testdata, Platform. The deeper stories (multi-tenant isolation at the data layer, live subscriptions, the SAX converter) live on the Architecture and module-group pages.
GS1 Conformant Resolver
The full GS1 Conformant Resolver ships in the business edition. The OSS rows below are the building blocks for working with GS1 identifiers — URN ↔ Digital Link translation, barcode rendering, identifier validation.
| Capability | OSS | Business | Notes |
|---|---|---|---|
| GS1 Conformant Resolver (multi-tenant, REST) | — | ✓ | One deployment serves many brand owners; partners and consumers integrate using standard GS1 link types, no bespoke clients. |
| Self-describing deployment | — | ✓ | Implements the GS1 Conformant Resolver discovery contract — downstream registries (the GS1 Global Office resolver, partner systems) find the deployment and read what it offers automatically, no hand-configuration needed. Served at /.well-known/gs1resolver. |
| A dozen GS1 link types auto-derived from masterdata | — | ✓ | Save a product once and the resolver derives the standard link relations (gs1:pip, gs1:productImage, gs1:certificationInfo, gs1:productSustainabilityInfo, gs1:safetyInfo, gs1:instructions, gs1:nutritionalInfo, gs1:recallStatus, gs1:serviceInfo, gs1:audioFile, gs1:relatedVideo). No manual linkset POST per product. |
| Bulk CSV / JSON-LD linkset import | — | ✓ | First-time onboarding path — tens of thousands of products in a single call. |
| Tenant-scoped masterdata cache | — | ✓ | Keeps resolution fast under multi-tenant load; each customer's hot path stays in cache without crossing tenants. |
| Linkset change audit | — | ✓ | Who changed which linkset, when — what regulated brand owners need to satisfy due-diligence and traceability reviews. |
| EPC URN ↔ Digital Link translation | ✓ | ✓ | For interop with legacy systems still emitting urn:epc:id:…; same library powers URN-on-demand at query time. |
| QR / Data Matrix / GS1-128 barcode generation | ✓ | ✓ | One Digital Link URI rendered into any GS1-conformant barcode — pick by use case (QR for consumer scans, DataMatrix for small parts, GS1-128 for cartons). |
GS1 Web Vocabulary & Masterdata
| Capability | OSS | Business | Notes |
|---|---|---|---|
| GS1 Web Vocabulary data model (libraries) | ✓ | ✓ | Java types for the GS1 Web Vocabulary — useful when building integrations or generating documents outside the platform. |
Masterdata REST API (/organizations, /products, /places) | — | ✓ | Platform discipline: masterdata lives on the resolver, never embedded inside EPCIS events. One source of truth, no duplication, no contradictory copies. |
| Full "Verified by GS1" integration with GS1 Germany services | — | ✓ | Bidirectional. Inbound: verifies a GTIN or GLN against GS1 Germany's registry (Activate Plus / GEPIR) and enriches the local record with authoritative party / product attributes. Outbound: publishes the brand owner's masterdata back into the GS1 network — the deployment acts as source-of-truth and the records propagate up to the GS1 Global Office resolver. A real node in the GS1 trust graph. |
| Event → Resolver masterdata promotion | — | partial | The internal masterdata bus exists; what's missing is the bridge from /capture into it. Once landed, an EPCIS event will register new masterdata implicitly — closing the "events drive masterdata" loop. |
EPCIS Events: Capture · Query · Subscriptions
| Capability | OSS | Business | Notes |
|---|---|---|---|
EPCIS 2.0 REST /capture | — | ✓ | Single endpoint for any volume — documents are validated, hashed, deduplicated and stored in one pipeline. |
EPCIS 2.0 REST /query (Named Queries) | — | ✓ | Filter by EPC, biz-step, location, time window; queries can be stored, named, and re-run by partners without re-sending the criteria each time. |
| EPCIS 2.0 SOAP binding | — | ✓ | For partners still on the EPCIS 1.x message bus — same backend, different envelope. |
| Hash-based event deduplication | ✓ lib | ✓ | Resending the same event produces the same ID. Capture is idempotent — safe to retry after a network hiccup without doubling up the event store. |
| Streaming subscriptions (live, no polling) | — | ✓ | a match fires the moment an event is indexed. No poll interval, no missed window, no "did I get that one yet?" debate. |
| Scheduled subscriptions | — | ✓ | Cron-style delivery for partners that prefer batch-style — nightly digests, periodic compliance pulls. |
| WebSocket delivery | — | ✓ | Push channel for browsers and lightweight clients. |
| Webhook delivery | — | ✓ | Standard HTTP POST to any partner endpoint. |
| Digital Link canonical form at rest, URN on demand | — | ✓ | Stored once in Digital Link form. Clients still on EPC URN form get it rendered on demand — no double storage, no drift between formats. |
| Reliable paginated queries that survive reconnects | — | ✓ | A six-month export can disconnect and resume on the same scroll cursor — important for regulators and big partners pulling long histories. |
| OpenSearch backend | — | ✓ | Primary store — open source, scales horizontally, supports the percolator queries the live subscriptions ride on. |
| Elasticsearch backend (variant) | — | ✓ variant | For deployments where the customer's existing observability or compliance posture already standardises on Elasticsearch. |
| High-volume capture variant | — | ✓ | Headless capture pipeline for environments where events arrive over Kafka rather than HTTP — the REST front-end is replaced by a stream consumer. |
Formats, Validation & Identity
| Capability | OSS | Business | Notes |
|---|---|---|---|
| XML ↔ JSON-LD conversion | ✓ basic | ✓ | OSS: XSLT, load-then-transform — fine for the common cases (single events, small batches, plain shapes). Business: SAX-streaming — multi-gigabyte exports, deep extension trees, complex sensor payloads, mixed-format batches. |
| EPCIS 1.2 ↔ 2.0 XML migration | ✓ basic | ✓ | OSS: the XSLT converter handles straightforward migrations. The Business edition adds the SAX converter — the production-grade path used to migrate live 1.2 corpora to 2.0. |
| EPCIS document validation | ✓ | ✓ | Catches malformed events at the boundary so they never land in the event store. Cheaper than discovering the problem six months later in a query result. |
| Custom-extension validation across the event | — | ✓ | For organisations with proprietary fields that need to coexist with the GS1 vocabulary — extensions are validated at every nesting level of the document. |
| Sensor element validation | — | ✓ | Makes sensor payloads structurally trustworthy — units, value types, device IDs all checked at capture time. |
| Pre-canonical event hash (idempotent event IDs) | ✓ | ✓ | The hash is computed against a normalised representation of the event — whitespace, attribute order, JSON key order don't affect the ID. Re-sends and round-trips through different serialisers produce the same event ID. |
| Web UI for format conversion | — | ✓ | Browser-based for non-technical users — drag in an XML or JSON-LD file, get the other format back. Same engine as the API. |
| Hash generator as a service | — | ✓ | REST endpoint for partners who want canonical event IDs without running the converter locally. |
Integration & Gateways
| Capability | OSS | Business | Notes |
|---|---|---|---|
| S3-compatible storage | ✓ lib | ✓ | Any object store that speaks the S3 API — AWS S3, on-prem implementations, S3-compatible appliances. |
| Azure Blob storage | — | ✓ | First-class option for Azure-native deployments — no S3 gateway in front. |
| File upload / download service | — | ✓ | REST endpoint for bulk inputs and outputs that are too large to fit comfortably inside JSON payloads. |
| AI assistant (Ollama-backed) | — | ✓ | Ask "show me last week's events for GTIN X" in plain English; the assistant classifies the intent (EPCIS query, identifier resolve, vocabulary lookup) and returns a translated EPCIS query plus the answer. Local LLM by default — no third-party API dependency. |
Access Control (cross-cuts every business deployable)
| Capability | OSS | Business | Notes |
|---|---|---|---|
| OIDC, session-cookie, and API-key authentication | — | ✓ | Three credential shapes, one identity. Customers pick whichever fits their stack — OIDC for IdP-integrated systems, cookies for browser UIs, API keys for service-to-service traffic. |
| Per-customer (tenant) isolation in Keycloak | — | ✓ | Each customer gets their own realm — user accounts, groups, roles, and policies don't bleed across customers. Resolved automatically from the request's hostname. |
| Data-layer tenant isolation (OpenSearch DLS) | — | ✓ | the application doesn't rewrite queries to add a tenant filter. The data layer itself enforces isolation, so even if app code is wrong, customer data stays separated. |
Role-based access (capture, query) | — | ✓ | Two roles ship out of the box — capture to write, query to read. Customers can layer their own granular permissions on top. |
| Shareable read-only deep-links (capability tokens) | — | ✓ | Send a regulator a single URL for one specific batch — no full account access granted. Short-lived, scoped to one endpoint and one HTTP method. |
| Wallet-agnostic Verifiable Credentials via OID4VC | — | ✓ | Each Keycloak realm is a Verifiable Credential Issuer through Keycloak's native OID4VCI / OID4VP / SIOPv2 implementation. Credentials in sd-jwt-vc (selective disclosure first), jwt_vc_json, ldp_vc and ISO mDoc — the holder picks the format. Interoperable with every OID4VC-compliant wallet already in production or in pilot (EU Digital Identity Wallet, Catena-X Managed Identity Wallet, enterprise business wallets, sector wallets). No wallet lock-in. |
| Globally-scoped issuer trust list | — | partial | Verifiers need to know which issuers are trustworthy. OpenEPCIS expects to maintain an open, globally-scoped trust list — not EU-only or sector-only. The trust-list surface and population pipeline are the work in flight. |
| EPCIS event → VC issuance pipeline | — | partial | The protocol layer (Keycloak OID4VCI / OID4VP) ships today. The named credential schemas (EPCISCommissioningCredential, DPPBatteryPassportCredential, EUDRDueDiligenceCredential, UNTPDigitalConformityCredential) and the bridge from capture/save into VC issuance are the named roadmap item. |
| UNTP Digital Conformity Credential compatibility | — | partial | UNTP DCC is exactly the kind of VC the OID4VCI layer issues. Schema and field mapping to be published alongside the named credential pipeline. |
| Verifier reference UI / SDK | — | partial | The OID4VP verification endpoint is live; a reference verifier UI for partners (browser-side and integrator SDK) is in flight. |
| Row-level scoping below tenant (GLN / EPC / biz-loc) | — | roadmap | Today access is binary per tenant. Adding GLN-, EPC-range-, or biz-location-bound visibility (so a user sees only "their" sites) builds on the same DLS mechanism. |
Testdata & Developer Tooling
| Capability | OSS | Business | Notes |
|---|---|---|---|
| Test event generation (REST + UI + bulk) | ✓ | ✓ | Synthesise realistic supply chains end-to-end — single events for demos, programmatic feeds for integration tests, or millions of events for performance work. |
| Re-capture / replay tool | — | ✓ | Read events from one deployment, re-capture them into another (or the same one). Useful for environment cloning, regression scenarios, and reproducing production issues in a dev environment. |
| Reference event collection (XML + JSON-LD) | ✓ | ✓ | Curated examples of every EPCIS 2.0 event shape, biz-step, and disposition — in both XML and JSON-LD. Used to test validators and onboard integrators. |
| EPCIS REST conformance test suite | ✓ | ✓ | Point it at any EPCIS 2.0 endpoint — yours or anyone else's — and get a conformance report. The standards-compliance test set, open source; the Business edition extends it with platform-specific checks (multi-tenant DLS, capability tokens, the auto-derived linkset pipeline). |
| Client SDK examples (multi-language) | ✓ | ✓ | Java, Python, Node.js, Go — example calls against /capture and /query to bootstrap an integration. |
Platform & Operations
| Capability | OSS | Business | Notes |
|---|---|---|---|
| Self-host on Kubernetes (Terraform / Helm) | — | ✓ | Reference Terraform modules + Helm charts for production deployment — opinionated but not vendor-locked. |
| Self-host on Docker Compose | — | ✓ | Ansible-driven Docker Compose stack — the fast path for smaller deployments and local development. |
| OpenTelemetry tracing | — | ✓ | End-to-end traces across REST endpoints, capture pipeline, and storage — drop into whatever observability stack the customer already runs (Grafana, Jaeger, Honeycomb, …). |
This matrix lists what's available today. The roadmap lists the strategic next steps — Verifiable Credentials for EPCIS events, the event-to-resolver masterdata bridge, sub-tenant scoping, and a retrieval corpus for the AI assistant.