Summary

  • RFC 5134 registered the epc and epcglobal URN namespaces; it did not authenticate any individual tag or product.
  • The epc namespace can name physical objects, while epcglobal names logical constructs such as schemas.
  • In the RFC's SGTIN example, company prefix, product reference and serial number occupy distinct components.
  • Leading zeroes in padded components are significant, so integer-style normalisation can change identity.
  • Verified errata clarify that the namespace-specific string is case-sensitive; the scheme and NID follow general URN comparison rules.
  • Generic URN syntax does not establish validity under a particular EPC sub-namespace or allocation chain.
  • Namespace persistence means a name is not reassigned; it does not prove current possession, location or physical existence.
  • Only certain epc sub-namespaces have an ONS/DDDS resolution path.
  • The epcglobal registration requires no resolution mechanism at all.
  • A tag read proves that identifier bytes were observed, not that the tag is genuine or the named object is present.
  • RFC 5134 treats signatures, secure resolution and trust relationships as fundamental because metadata can be spoofed.
  • Product identity, observation, metadata, event history, custody and physical outcome must remain separate receipts.

The lossless parser was the first control surface

The defect entered before any radio read, resolver query or warehouse movement. A source system supplied an identifier shaped like RFC 5134's non-normative SGTIN example: a company prefix, a padded product reference and a serial component. A middleware team saw digits separated by periods and stored each portion in a numeric field. The next export had the right arithmetic values and the wrong identifier.

That distinction matters because an identifier is not a calculation. RFC 5134 says explicitly that leading zeroes in the padded components are significant. A conversion that maps 0003456 to 3456 is therefore not a harmless presentation change. The operation can redirect every later join: master data, resolver cache, commissioning log, EPCIS event, recall list and proof-of-delivery record.

The evidence chain should begin with an exact byte-preserving capture. Record the original representation, the parser version, the applicable sub-namespace and the output representation. Test round trips, not merely parse success. If a canonical form is produced, retain the rule set and show that the canonicaliser preserves namespace equivalence rather than imposing an application's intuition about numbers.

Case handling has the same shape but a subtler trap. RFC 5134 originally said the entire URN was case-sensitive. Verified errata correct that statement: the namespace-specific part is case-sensitive. The urn scheme and namespace identifier remain governed by the general URN comparison rules. A system that lowercases the entire value may merge distinct names inside the namespace. A system that treats URN:EPC: and urn:epc: as different solely because of their scheme or NID spelling can manufacture duplicates. Both failures arise from replacing the namespace contract with a generic string policy.

Two namespaces, two kinds of thing

RFC 5134 deliberately separates epc from epcglobal. Sub-namespaces beneath epc may name real physical objects or corporeal entities. Sub-namespaces beneath epcglobal name logical or software constructs, including schema namespaces. The distinction prevents one familiar word—identity—from swallowing two different subjects.

A physical-object name can remain persistent while the object moves, changes custody, leaves service or is destroyed. A logical namespace name can remain useful without pointing at a retrievable document. The epcglobal registration says no resolution mechanism is required or provided. Treating every URN as a URL therefore produces false outages: the name can be valid even when there is nothing to dereference.

The inverse mistake is more dangerous. A resolver response can be available even when the physical assertion is wrong. A client may reach a service, receive metadata and render a convincing product page while the observed tag value was copied, the lookup was misdirected, the response was stale or the tagged object was elsewhere. Network success makes the metadata visible. It does not make the metadata true.

Registration protects a narrow invariant

IANA's registry records the namespace identifiers. RFC 5134 describes EPCglobal's role in defining and sub-delegating names. The assignment process is designed to preserve uniqueness and avoid reassignment; the binding is intended to persist through standards or organisational changes. Those are valuable guarantees. They are also narrower than possession.

An allocation record can show that an identifier belongs to a managed name space and that a particular authority was entitled to assign it. It does not show that the party presenting the value now controls the genuine tag, owns the goods, has custody of the shipment or has placed the object at a claimed location. Persistence prevents a later allocator from recycling the name. It cannot stop a copier from replaying the same visible bits.

The leadership error is to turn the strongest property of the ledger into a property of the world. A durable name can outlast a broken sensor. A correct registry can coexist with a false event. A valid serial can be observed on the wrong carrier. The registry describes the identifier's administrative continuity; physical continuity needs a different receipt.

Syntax, validity and assignment are three tests

Generic URN parsing answers whether a string fits the envelope. RFC 5134 adds an EPC namespace shape, then points to EPCglobal-maintained material for the normative details of each sub-namespace. Current GS1 Tag Data Standard material continues to define EPC representations and tag-memory encodings. These layers must not be collapsed.

A string can satisfy generic URI characters yet violate an EPC sub-namespace grammar. It can satisfy the grammar yet contain a company prefix, reference or serial that was not allocated through the authorised chain. It can be validly assigned yet appear on a copied or miscommissioned tag. The corresponding controls are parser validation, namespace validation, allocation evidence and tag/object evidence—not one green badge labelled “valid EPC”.

Version matters too. RFC 5134 calls its SGTIN ABNF example non-normative and delegates normative structure to the Tag Data Standard. GS1's archive shows that TDS has continued to evolve. A validator must therefore identify the rule version it applied. “Valid today” and “valid under the representation used when commissioned” may be different questions, and neither establishes current physical presence.

Observation is not authentication

An RFID reader can supply a strong operational receipt: at a particular time, with particular firmware, antenna geometry and filtering, it observed a response containing an EPC representation. That observation belongs in the evidence chain. It should not be promoted into an authentication result the air interface did not produce.

If the same copied value appears under two reader arches, the namespace remains unique while the observations conflict. The conflict may indicate duplication, a reader-boundary issue, delayed event transmission, an encoding fault or a legitimate movement whose timing was misunderstood. The identifier alone cannot choose among them.

Tag authenticity needs additional evidence: a cryptographic capability, protected manufacture information, controlled commissioning records, tamper evidence, or an accountable process appropriate to the deployment. The exact mechanism varies. The invariant does not: merely reading a persistent name is not proof that the carrier is the authorised physical object.

Resolution selects a service, not reality

RFC 5134 says certain epc sub-namespaces are resolved through the Object Naming Service, described as an implementation of the Dynamic Delegation Discovery System. DDDS and NAPTR provide a rule-driven way to discover a service. They do not turn DNS or the selected endpoint into an oracle about the thing being named.

For every lookup, record the exact input name, equivalence form, requested service, DNSSEC or other transport protections where applicable, delegation chain, selected URI, response signer, freshness interval and application decision. A successful NAPTR path proves that the discovery rules led to a result. It does not prove that the result is current, that its metadata is authorised for this product instance or that the named object is in front of the reader.

The absence of resolution must be interpreted with equal care. epcglobal requires none. Some physical-object subspaces may use services other than the historical ONS model. A resolver miss can mean no service is defined, the service is unavailable, the query form is wrong or the delegation is incomplete. It cannot automatically mean “invalid product”.

Metadata needs its own chain of trust

RFC 5134's security section anticipates the central operational risk. Names can identify valuable physical things, so attackers have an incentive to spoof metadata such as cost or size. The RFC consequently calls digital signatures, secure resolution mechanisms and trust relationships fundamental.

That is a direct warning against the common dashboard shortcut. The resolver returned JSON; the UI therefore labels the product genuine. The missing steps are authority, integrity, freshness and scope. Who signed the record? Which identifier representation was covered? Does the signature bind the product instance or only an object class? Was the response valid at the event time? Can an intermediary substitute a resolver or cache entry? What trust policy did the relying organisation apply?

Metadata integrity still stops short of physical proof. A perfectly signed description can truthfully state what a serial number denotes while the observed carrier is counterfeit. Conversely, a genuine product can be paired with stale business data. The signature binds an accountable statement. Physical inspection and tag authentication bind other facts.

EPCIS supplies events, not omniscience

Current GS1 architecture describes EPCIS as a system for sharing visibility event data: what, where, when, why and how. That separation is useful. The EPC identifier names the subject. An event asserts that some business process observed or acted on it under a particular context.

An EPCIS record should retain capture time, event time, read point, business location, business step, disposition, source system and accountable party. Corrections, late arrivals and duplicates need an audit trail. A location value is not the object itself; it is a claim produced by a device and process. The event becomes stronger when its capture chain, signer, clock, reader boundary and reconciliation rules are visible.

Chain of custody is constructed from such bounded events plus organisational handoffs, not inferred from the persistence of the EPC. Gaps remain gaps. A system should not interpolate physical continuity merely because the same serial appears before and after the missing interval.

The receipt ladder

The operational model is a ladder rather than a single status:

  1. IANA registry receipt: the namespace identifier is registered.
  2. Syntax receipt: the URN fits the generic and namespace-specific grammar.
  3. Lexical receipt: significant zeroes and case rules survived processing.
  4. Assignment receipt: the identifier was allocated through the authorised chain.
  5. Observation receipt: a named reader saw the bytes at a time and boundary.
  6. Authenticity receipt: the tag or carrier passed the deployment's anti-copy control.
  7. Resolution receipt: the requested service was selected and reached securely.
  8. Metadata receipt: an authorised, fresh statement was integrity protected.
  9. Event receipt: a responsible source recorded a bounded business observation.
  10. Physical receipt: inspection or operation established the product and outcome.

Each rung can fail while earlier rungs remain sound. A valid name can have no resolver. A resolver can return false metadata. Signed metadata can describe a copied tag value. A genuine tag can travel without a complete event trail. An event trail can end before delivery. The evidence model must preserve those combinations instead of compressing them into “verified”.

Sources