Decentralised Access Control

info

Please note that this specification is suitable for pre-production pilot implementations.

Scope and Terminology

This specification defines access-control patterns and points at existing protocols. It does not prescribe a single solution. An implementer applies the six patterns independently or in combination. Encryption is optional: publishing only public credentials is conformant. Encryption is the encrypt tool in Disclosing the Data.

What this specification covers

• Six access-control patterns, and the rules for combining them. See Decentralised Access Control.
• How an Identity Resolver linkset advertises an encrypted target (encryptionMethod, accessRole) and an update endpoint (method). See Confidential data discovery.
• Minimum encryption rules: a symmetric algorithm, a minimum key length, and a separate key per identified entity. See Encrypted Content.
• The shape of a shared-secret carrier: a resolver URL carrying a decryptionKey parameter, and an optional short redirect for a small data carrier. See Shared Secrets.
• Which existing authentication protocols to use. This specification recommends protocols; it does not define one. See Decentralised authentication protocol options.

What remains implementation-specific

• Which patterns to deploy, including the choice to encrypt nothing.
• How a data holder stores keys, runs update endpoints, or decides that presented evidence meets its own policy, including which Digital Identity Anchor issuers it trusts.
• Federated sign-in for parties the data holder already knows. Federated Authentication permits any OAuth 2.0 or OpenID Connect deployment and adds no further rules.
• The set of accessRole values. Role URIs are chosen by the publisher. A controlled list of transparency levels is post-v1 work. accessRole filters what a resolver returns; it does not authenticate the requestor. See Disclosing the Data.
• Public discovery of unencrypted credentials, specified in the Identity Resolver.
• A different signed credential for each audience, specified in variant-based disclosure, and a third-party attestation that stands in for private records, specified in Chain of Custody and Mass Balance.
• Cryptographic selective disclosure, such as redacting claims inside one signed credential. That is outside v1 conformance. See Disclosing the Data.
• Custody, escrow, and release of decryption keys after the data holder stops operating. See Durable Storage.

Relationship to the Verifiable Credentials Profile

The Verifiable Credentials Profile specifies how a UNTP credential is issued and checked: the W3C VC data model, the enveloping proof, credential status, and issuer DID methods. DAC specifies who may obtain those bytes, and who may post an update.

An encrypted target is a signed VC profile credential with encryption applied to the signed bytes. Decrypting it produces that same signed artefact. The VC profile requires the artefact to be kept byte-for-byte: parsing it and writing it out again invalidates the proof. See VCDM profile.

This specification does not add properties to the credential, change its proof, or replace the Bitstring Status List. Survival of the signed credential and of the verification material it depends on is normative in the VC profile. DAC-7 records the durability requirement; the storage patterns that keep ciphertext and keys available after the data holder has gone are informative and are described in Durable storage and Durable Storage.

Terms

Term	Meaning
authorised party	A data requestor that has met the evidence the data holder requires for a given read or write. The evidence may be a secret, a verified role, a verified identity, or a combination of those. The data holder makes that decision against its own policy. This specification does not keep a register of authorised parties.
access grant	The data holder's release, for one identified entity and where roles are used for one access role, of the means to read or write non-public data. A read grant is a decryption key, or the decrypted bytes. A write grant is acceptance of an authenticated update. An access grant is not a credential type, and this specification defines no schema for it.
key holder	A party in possession of the symmetric key for an encrypted target. The data holder is the first key holder and may pass the key on, for example inside product packaging. Possession of the key is the read grant for that target. The key holder does not have to be identified.
encrypted target	A link target whose content is ciphertext. A resolver advertises it with encryptionMethod and accessRole. Every requestor who is shown the link receives the same ciphertext. The party who can read it is the key holder.
data holder	The party that creates and maintains information about a product or facility, typically the manufacturer or the brand. The data holder keeps both public and non-public data and is the party that issues access grants.
data requestor	The party seeking access to data that the data holder maintains.

Overview

There is a balance between the demands of transparency (more supply chain visibility means it's harder to hide green-washing) and confidentiality (share too much data and you risk exposing commercial secrets). A key UNTP principle is that every supply chain actor should be able to choose their own balance between transparency and confidentiality.

This page is the encrypt tool in Disclosing the Data: the same credential bytes, with the key given only to those who may see them. Public discovery, role variants, and trusted-auditor attestations are specified elsewhere. Encryption is optional for UNTP conformance — public credentials and variants can be enough.

The ability to enforce access control to read and write non-public data is a critical capability for any traceability and transparency framework. But when the non-public data is distributed across thousands of different systems and needs to be accessed by authorised parties previously unknown to the holder of the data, traditional access control systems will not work. A decentralised data architecture also needs a decentralised access control mechanism.

Conceptual Model

The conceptual model for decentralised access control is relatively simple. All non-public credentials are encrypted with a unique key for each credential. Read access to encrypted data then boils down to the mechanism by which authorised parties acquire decryption keys from a data holder that may not know the requestor. Write access (e.g., adding links to an Identity Resolver, or submitting lifecycle/update events) is performed via authenticated update endpoints, typically advertised as link targets. There are only two broad ways to prove rights to non-public data.

1. You already have the key: The key is passed by the data holder to the data requestor by a separate channel. For example, to empower access to non-public data by the legitimate purchaser of the goods, the key could be located inside the packaging of the product.
2. You have a right to the key: The key is made available to any data requestor that can prove their authorised role to the data holder via an authentication mechanism such as DID Authentication.

Each uniquely identified item will have a unique encryption key. Therefore the keys provided by either of the above methods is usable only to decrypt the data about a single item. Similarly, for confidential data about products or facilities each will have its own unique encryption key.

Shared secrets and DID Authentication can be used in conjunction - for example a data holder may allow anonymous users to read non-public data with just a secret but may require both the secret (to prove item ownership) and DID Authentication (to confirm identity or role of the data requestor) to update item data.

For read access, the decryption of previously issued and encrypted verifiable credentials is preferred over any dynamic service because

• The same encrypted UNTP credential is used for both the shared secret and DID authentication access models.
• The access control is easily delegated to Identity Provider services and can continue to work even after the original issuer is no longer in business.

Requirements

The terms data holder, data requestor, authorised party, access grant, key holder, and encrypted target are defined in Terms.

ID	Name	Requirement	Solution Mapping
DAC-1	Anonymous access	As a data requestor that requires access to public product information, I should be able to access the information without any registration or identification - so that my privacy remains protected.	Anonymous public access
DAC-2	Access by legitimate owner	As the legitimate owner or user of a specific serialised item, I should be able to access non-public information such as usage and maintenance history about my item and also be able to update post-sale life-cycle events without any need to register or identify myself to the data holder.	Anonymous access with secret
DAC-3	Access with verifiable role	As an authorised actor such as an accredited recycling plant or a government authority, I should be able to access and update non-public product information according to my authorised role even if I am otherwise unknown to the data holder.	Decentralised authentication - role registrationScopeList property
DAC-4	Access with verifiable identity	As a known and trusted data requestor party I should be able to prove my identity to the data holder and be granted access according to my permissions.	Decentralised authentication - ID registeredId property or any federated identity protocol
DAC-5	Confidential supply	As a buyer who received credentials from my suppliers that provide confidence in the sustainability or quality of my upstream supply chain, I would like to pass on the sustainability or quality confidence to my customers without revealing the identity of my suppliers.	N-tier supplier visibility — using the four tools in Disclosing the Data, not a fifth mechanism
DAC-6	Discoverability	As any data requestor that queries available data about a product or facility from an identity resolver service, I would like to understand not only what public data is available but also what confidential data is available and what evidence I need to provide to access the confidential data.	Discoverability of encrypted content
DAC-7	Durability	As a data requestor seeking information about a product or facility, I want to access the necessary data according to my role even if the original manufacturer is no longer in business and whether or not the data is open or confidential.	Durable storage options — informative in v1.0; the normative part is in the VC profile
DAC-8	Limit impact	The confidential data access scope associated with a specific secret key should be limited to one product or item so that the consequence of un-authorised access to confidential data is minimised	Encryption granularity
DAC-9	Small footprint	Where space is tight (eg under a wine bottle cap) then a small format secret key option is available.	Secret key carrier

Decentralised Access Control

UNTP defines six access control patterns that can be combined to balance transparency and confidentiality for both read and write access:

1. Anonymous Public Access - No encryption, publicly discoverable via Identity Resolver
2. Unguessable Identifiers - Security through high-entropy random IDs (128-bit minimum)
3. Encrypted Content - Encryption with unique keys per entity
4. Shared Secrets - Decryption keys embedded in data carriers with products
5. Federated Authentication - OAuth/OIDC for known parties with pre-established trust
6. Decentralised Authentication - DID Auth for verifiable roles/identities without prior registration

These patterns can be used independently or in combination depending on requirements. For example, Pattern 4 (shared secrets) can be combined with Pattern 6 (decentralised authentication) to require both proof of item ownership and verified role credentials for access.

The following paragraphs provide guidance on how to secure data and grant access for various scenarios. The same patterns can also be used to control write access (e.g., accepting lifecycle updates or allowing authorised parties to add links) via authenticated endpoints.

Anonymous Public Access

Anonymous access to public data is the default UNTP access pattern. It is already described in the identity resolver specification. From a security and resilience perspective, the only requirements are

• That data providers MUST NOT require personal identifying information from the data requestor as a condition of providing public information.
• That data SHOULD remain available for the lifetime of the product, irrespective of whether the original manufacturer still exists.

The first requirement is met using the identity resolver specification. The second is only partly met by it: the resolver is a discovery service, not an archive, and it can itself become unreachable. Availability beyond the publisher's own lifetime depends on where the credential bytes are stored — see Durable storage.

Unguessable Identifiers

Most item identifiers are relatively short numbers and are issued sequentially. So, for example, if https://example.com/product/11223/serial/44556 is a known product and serial identifier then it is likely that the next serialised item ID could be https://example.com/product/11223/serial/44557 or that the next product and serial in the range could be https://example.com/product/11224/serial/00001. When identifiers are easily guessed then information about the products is easily discovered even when the data requestor is not in possession of an actual product or serialised item.

However, if the product and serial numbers are issued as genuinely random large numbers then they become un-guessable and so any public (ie non-encrypted) data linked to the ID can be considered to be accessible only to the party in possession of the item. For example https://example.com/product/11223/serial/44FDB2AFC91B898893CF36CB18863D26 is a product with a 32 character hexadecimal (128 bit) serial number and, provided the serial number is genuinely random, is computationally impractical to guess (1 billion guesses per second would still take many universe lifetimes).

Large random serial numbers are not common practice in industry and so are more likely to be considered for new rather than existing identifier schemes. However, depending on the sensitivity of the data, shorter serial numbers (eg https://example.com/01/0952400005919/21/419A2845FD8050A0DD56) may provide adequate confidentiality provided they are issued randomly and not sequentially. For example, if serial number 419A2845FD8050A0DD56 were one of a million serialised items of product ID 0952400005919 then it would still take a few years to guess one matching serial number at 1 billion guesses per second.

When non-guessable large identifiers are used as a security mechanism to access non-encrypted sensitive data, then;

• the access mechanism is no different to anonymous public access.
• the identifiers MUST be genuinely random strings
• the data MUST NOT be index-able by search engines.
• the web repository that holds the data MUST NOT be searchable or expose lists of stored files.

Unguessable identifiers are one optional hardening measure. UNTP does not require guessability-resistance as the access-control mechanism — encryption, variants, and role-based key release remain available, and the choice is the implementer's.

Legacy sequential identifiers

Many existing identifier schemes issue sequential values: GS1 GTINs, customs batch numbers, national livestock tags. Those schemes are already embedded in operations, and UNTP requires existing schemes to remain usable (IDR-03). Replacing a sequential base with a random identifier is often impractical.

Where an implementer wants an unguessable lookup key without abandoning the sequential base:

• Keep the sequential identifier for internal systems, barcodes already in the field, and trading-partner documents.
• Append a random suffix (128-bit entropy is the same threshold as above) to form the Identity Resolver path or query key, for example https://resolver.example/01/0952400005919/21/419A2845FD8050A0DD56 where 0952400005919 is the existing sequential GTIN and the serial is random.
• Publish the sequential identifier as an alsoKnownAs (or scheme-specific synonym) so internal systems still match, while public discovery uses the unguessable key.

This is migration guidance, not a mandate. An implementer who encrypts the payload, or who publishes only non-sensitive public data, has no need to randomise identifiers.

Encrypted Content

In many cases, relying on an un-guessable identifier is not possible or not sufficiently secure. In such cases, confidential data SHOULD be encrypted.

• Encryption MUST be done with a symmetric encryption algorithm such as AES with a minimum of 128 bit key length.
• Each distinct identified entity (i.e. facility, product, product batch, or serialised item with a unique IDR path) MUST use a separate and unique encryption key.
• Where there are multiple different authorised roles that require access to different non-public data then a unique encryption key SHOULD be used for each role.
• Where there are multiple non-public documents or credentials for a given unique entity and authorised role then they SHOULD be encrypted with the same key.

These encryption requirements will result in an optimal granularity of encryption where one or more encrypted objects about a specific item and for access by a specific authorised role are all encrypted with the same key. But data for other roles or other items are not accessible with the given key.

Shared Secrets

Terminology Note

This specification uses the term "secret" for consistency with established cryptographic standards (e.g., "shared secret" in key exchange protocols). In business contexts, implementers may find terms like "access code" or "decryption key" more user-friendly when communicating with non-technical stakeholders. The technical meaning remains the same regardless of terminology choice.

When confidential data about serialised items is encrypted then decryption keys SHOULD be included with the product and be optimised for easy use.

• The key SHOULD be presented as a QR code (either included with the product or, for bulk/raw materials, sent separately)
• The code MUST resolve to an Identity Resolver query URL for the given item and with the symmetric key secret as a decryptionKey parameter.
• For cases with limited space such as a QR under a wine bottle cap, implementers MAY use a shorter URL that redirects to the same full identity resolver URL. The short URL SHOULD include 128 bit entropy so that it is sufficiently un-guessable.

For example, for a 128 bit AES key in a query to a resolver about product ID 90664869327 that returns only encrypted link targets for anonymous access the resolver URL would be https://resolver.product-register.com/01/90664869327?decryptionKey=2b7e151628aed2a6abf7158809cf4f3c&accessRole=untp%3AaccessRole%23Anonymous

Small footprint codes

A 128 bit short redirect URL (in capitals because that creates smaller QR codes) can be used for cases where there is limited space for QR codes. For example HTTPS://REDIRECT.IO/E05778C659733E222758AC5179AE4611 could redirect to the same full URL https://resolver.product-register.com/01/90664869327?decryptionKey=2b7e151628aed2a6abf7158809cf4f3c&accessRole=untp%3AaccessRole%23Anonymous

The full and short URLs would produce the following QR codes

Full resolver URL	Short redirect URL

Federated Authentication

In some cases access to (and update of) confidential data requires more than a shared secret that proves ownership of a serialised item but also requires evidence that the data requestor has an authorised role such as a competent authority, a recycling plant, or accredited auditor. When the data requestor is already known and registered with the data provider then a conventional "sign-in-with" federated authentication and authorisation mechanism such as OAuth 2.0 or OIDC can be used. UNTP does not impose any restrictions on how a data provider authenticates and authorises access to protected data for users that are already known to the provider.

However, these kind of protocols require a relying-party relationship between the data provider that requires evidence of identity (eg a product passport issuer) and an identity provider that is the manager of the identity (eg a regulatory authority). Although this "sign-in-with" protocol is easy to implement with social network identity providers who deliberately place low barriers to relying parties, more authoritative registers such as national business registers, land registers, trademark registers, and so on are much more conservative. They mostly either don't offer federated identity or even if they do, they are very restrictive about allowed relying parties.

Decentralised Authentication

Decentralised protocols provide a much simpler and more scalable authentication and authorisation approach for decentralised architectures that avoids any need for direct collaboration or dependencies between data providers and identity providers. For example, consider an access rule defined by a China based battery manufacturer that says "to update battery status to recycled the requestor must be an accredited recycling establishment operating in a recognized jurisdiction (eg Australia). The workflow would be

• Australian recycling plant "Sample Recyclers" is accredited under the Australian Government Department of Environment stewardship scheme and has obtained a Digital Identity Anchor credential that links their DID to their government accreditation status.
• Sample Recyclers receives a battery for recycling after 7 years of use that was originally made by "China Batteries Sample Co". It has a serialised item specific QR secret printed on the battery.
• Sample Recyclers scans the QR (which includes presentation of the secret), receives an IDR link-set response that includes a UNTP standard link that defines an authenticated method and URL to add a recycled event to the battery history that requires evidence of accredited recycler status.
• Sample Recyclers authenticates to the specified endpoint using DID-Authentication and presents their Australian Government issued DIA credential as a verifiable presentation.
• China Sample Batteries Co verifies the presentation (which confirms DID control) and checks that the issuer (AU government) is on their trusted white-list, and then adds the recycled event to the item history.

Decentralised authentication protocol options.

UNTP does not define any new protocols for decentralised authentication but rather supports the use of any of the existing standards listed below.

• DID Auth specification
• DID SIOP specification
• OID4VP specification

Aspect	DID Authentication	DID-SIOP	OpenID4VP
Primary Purpose	DID-based authentication with credential integration	Decentralized login using OIDC	Credential presentation in OIDC
Workflow Complexity	Moderate	Moderate	Complex
OIDC Integration	No	Yes	Yes
Use Case Focus	Proving DID control with credential attachment	Decentralized login	Claim verification and presentation

The best choice will eventually be the specification(s) that demonstrate the widest market implementation. At this time, the UNTP recommendation is that implementers SHOULD use DID-Authentication but MAY also use either DID-SIOP or OpenID4VP.

DIA issuance capacity

The DID/DIA pattern assumes an accreditation body, business register, or similar authority that can issue Digital Identity Anchors. Many developing-country registries do not yet have that capability. UNTP does not relax the DIA data model for v1.0, and it does not invent a second identity mechanism. It does acknowledge the gap: until a register can issue DIAs, parties in that jurisdiction will rely on public credentials, shared secrets, and federated sign-in with parties they already know — and will not be able to use role-based key release that depends on a presented DIA.

Capacity-building programmes such as the UNIDO Global Quality and Standards Programme (GQSP) are the transition path: they strengthen the quality infrastructure (metrology, standardisation, accreditation, conformity assessment) that a future DIA issuer needs. Implementers and donors SHOULD treat DIA issuance as a register-maturity goal, not as a prerequisite that blocks public UNTP credentials in the meantime.

Confidential data discovery

Identity resolvers MUST include information to indicate when a link target is encrypted. Resolvers MUST also provide information about how to POST update events, where appropriate.

• When a link target is encrypted, the encryptionMethod custom property MUST be included with a value drawn from the UNTP encryption method code list.
• When a link target is encrypted, the accessRole custom property MUST be included. The allowed values are an array of URIs that will be used to match against registrationScopeList in digital identity anchor credentials. accessRole on a link (and as a resolver query parameter) is disclosure filtering: it describes who the publisher intends to give the key to. It is not authentication. Anyone can put any role on a query string; protection is the encryption of the target, not the query parameter. See Disclosing the Data.
• To indicate that access is allowed by any party that holds a secret key, the accessRole untp:accessRole#Anonymous MUST be included.
• To indicate that the link target is an update service, the "method": "POST" property is required, together with the accessRole needed for the update to be accepted.

For example

{
  "linkset": [
    {
      "anchor": "https://resolver.product-register.com/01/90664869327",
      "dte": [
        {
          "href": "https://sample-credential-store.com/credentials/dte-90664869327.json",
          "title": "Battery maintenance event",
          "type": "application/ld+json",
          "hreflang": ["en"],
          "encryptionMethod": "AES-128",
          "accessRole": ["untp:accessRole#Anonymous"]
        },
        {
          "href": "https://api.sample-credential-store.com/credentials",
          "title": "Battery recycling event",
          "type": "application/ld+json",
          "hreflang": ["en"],
          "method": ["POST"],
          "accessRole": ["untp:accessRole#Recycler"]
        }
      ]
    }
  ]
}

Implementation Considerations

The following paragraphs are guidance for common concerns. They do not add conformance requirements.

Access role granularity

accessRole on a link or query is a disclosure filter, not authentication — see Disclosing the Data. Anyone can put any role on a URL. Protection of non-public data is encryption or a different signed variant.

That still leaves a commercial risk: a dominant buyer can contractually demand an overly broad role (for example untp:accessRole#Customer mapped to the entire confidential graph) and defeat the confidentiality architecture through market power rather than technical necessity.

Access-role scopes should be defined at the narrowest granularity consistent with the verifier's legitimate need. Worked example: a buyer who only needs to know whether a batch met a conformity threshold can be given a conformance-indicator-only role that decrypts (or is issued a variant containing) the pass/fail indicator and the criterion URI — not the supplier identity, not the full assessment report, not the transformation event. A role that discloses the full upstream graph should be reserved for cases where that breadth is actually required (a competent authority, an appointed auditor).

This is non-binding. UNTP does not add a new accessRole code list in v1.0; formalising named transparency levels as selectable roles is post-v1 work. Implementers may mint their own narrow role URIs and advertise them on the linkset today.

Linked confidential data

Data about a value chain comprises multiple credentials about products and facilities in a linked-data graph. Any of the credentials in the graph may be considered confidential and therefore be protected by an appropriate access control method. This will present challenges for verifiers such as supply chain traceability systems that need to traverse long graphs for their customers. A typical scenario might work as follows:

• A verifier encounters a serialised product ID and performs an IDR lookup which returns a link-set which contains:
  • link to an un-encrypted Digital Product Passport (DPP) which also contains an ID of the facility that manufactured the item
  • links to an encrypted Digital Traceability Event (DTE) with "encryptionMethod": "AES-128" and "accessRole":["untp:accessRole#Anonymous"] properties.
• The verifier has the secret key for the given item and so decrypts the DTE to find that it is a transformation event that lists the identifiers and quantities of input products.
  • For some of the input product ID, the verifier is able to resolve link-sets from relevant IDRs and access public data (eg DPPs) about the input products.
  • The input product IDR process also returns encrypted links but they cannot be decrypted because the verifier has no access to the secret key for supplier input products.
• The verifier resolves the facility ID found in the DPP to a new link-set that contains links to both public and private data about the facility.
  • A link to a public digital facility record (DFR) includes precise geo-location information as well as some public sustainability claims.
  • A set of links to facility level conformity credentials (DCC) that are encrypted and have "accessRole":["untp:accessRole#Customer"] property. The verifier uses DID-Authentication to connect to the DCC end points and presents a Digital Identity Anchor (DIA) that proves the verifier ID which matches a facility customer list. Decryption keys are provided with a new link-set of the authorised customer.

In general, when a verifier hits a graph node that is encrypted and does not have access keys, then graph traversal cannot proceed beyond that node. Perhaps the most common scenario will be transformation events that reveal the input products (and suppliers) in a manufacturing process.

N-tier supplier visibility

DAC-5 is not a fifth disclosure mechanism. Upstream supplier identity is another payload that an issuer may disclose using the four v1 tools in Disclosing the Data. Formalising those four levels as a selectable accessRole code list is post-v1 work; v1.0 shows how to compose the tools that already exist.

This is often the most commercially sensitive data point for aggregators and exporters. A typical pattern: a West African aggregator buys from many smallholders, sells a blended batch to an overseas manufacturer, and must pass on deforestation or labour confidence without handing the buyer a list of farms they could contract around. The aggregator chooses how far upstream identity travels.

Typical choices:

• Public — publish the upstream credentials, or the supplier identifiers in the transformation event, for anyone who resolves the product.
• Variant — issue a customer (or regulator) variant that includes supplier identifiers, and a public variant that does not. See Variant-based disclosure.
• Encrypt — encrypt the transformation event (or the supplier-identifying credentials) and give the key to direct customers, for example when the requestor's Digital Identity Anchor matches the destination party in a transaction event.
• Trusted auditor — a third party assesses the supply chain and issues a more public Digital Conformity Credential that attests to qualities without naming suppliers. See Chain of Custody and Mass Balance.

An issuer may also keep upstream data entirely private. Graph traversal stops at any encrypted node for which the verifier has no key; see Linked confidential data.

Worked examples

Illustrative only. Identifiers, farms, and quantities are fictional. Each example is a fragment — envelope fields omitted — showing how the same EPCIS TransformationEvent is disclosed differently. The Identity Resolver linkset is what a verifier sees first. Examples use EPCIS event types (TransformationEvent here) rather than UNTP-native MakeEvent / MoveEvent / ModifyEvent.

0. Shared scene. Aggregator did:web:savanna-aggregators.example issues a batch DPP for cocoa https://id.savanna-aggregators.example/cocoa/batch/2025-Q1-088 and a transformation event that consumed two farm lots. The public linkset always advertises the DPP; what else it advertises depends on the tool.

{
  "linkset": [
    {
      "anchor": "https://id.savanna-aggregators.example/cocoa/batch/2025-Q1-088",
      "dpp": [
        {
          "href": "https://creds.savanna-aggregators.example/dpp/2025-Q1-088.json",
          "title": "Digital Product Passport",
          "type": "application/vc+jwt"
        }
      ]
    }
  ]
}

1. Public. The transformation event is a public dte link. Input epcClass values are the farm lots, so anyone who resolves the batch can traverse to those farms.

"dte": [
  {
    "href": "https://creds.savanna-aggregators.example/dte/transformation-2025-Q1-088.json",
    "title": "Aggregation transformation event",
    "type": "application/vc+jwt"
  }
]

{
  "type": "TransformationEvent",
  "eventTime": "2025-03-20T12:00:00Z",
  "eventTimeZoneOffset": "+00:00",
  "bizStep": "https://ref.gs1.org/cbv/BizStep-commissioning",
  "disposition": "https://ref.gs1.org/cbv/Disp-active",
  "bizLocation": {
    "id": "https://id.savanna-aggregators.example/facility/warehouse-1"
  },
  "inputQuantityList": [
    {
      "epcClass": "https://id.farm-kojo.example/cocoa/lot/2025-014",
      "quantity": 800,
      "uom": "KGM"
    },
    {
      "epcClass": "https://id.farm-ama.example/cocoa/lot/2025-009",
      "quantity": 650,
      "uom": "KGM"
    }
  ],
  "outputQuantityList": [
    {
      "epcClass": "https://id.savanna-aggregators.example/cocoa/batch/2025-Q1-088",
      "quantity": 1450,
      "uom": "KGM"
    }
  ]
}

2. Variant. Two signed transformation-event credentials. The public variant replaces farm epcClass values with a type-level class (or omits inputQuantityList). The customer variant is the full event from example 1. The resolver returns one or the other based on accessRole — a filter, not a lock. See Variant-based disclosure.

"dte": [
  {
    "href": "https://creds.savanna-aggregators.example/dte/transformation-2025-Q1-088-public.json",
    "title": "Aggregation transformation event (public)",
    "type": "application/vc+jwt",
    "accessRole": ["untp:accessRole#Anonymous"]
  },
  {
    "href": "https://creds.savanna-aggregators.example/dte/transformation-2025-Q1-088-customer.json",
    "title": "Aggregation transformation event (customer)",
    "type": "application/vc+jwt",
    "accessRole": ["untp:accessRole#Customer"]
  }
]

{
  "type": "TransformationEvent",
  "eventID": "https://creds.savanna-aggregators.example/dte/transformation-2025-Q1-088-public",
  "eventTime": "2025-03-20T12:00:00Z",
  "eventTimeZoneOffset": "+00:00",
  "bizStep": "https://ref.gs1.org/cbv/BizStep-commissioning",
  "disposition": "https://ref.gs1.org/cbv/Disp-active",
  "bizLocation": {
    "id": "https://id.savanna-aggregators.example/facility/warehouse-1"
  },
  "inputQuantityList": [
    {
      "epcClass": "https://id.savanna-aggregators.example/cocoa/farm-lots-anonymised",
      "quantity": 1450,
      "uom": "KGM"
    }
  ],
  "outputQuantityList": [
    {
      "epcClass": "https://id.savanna-aggregators.example/cocoa/batch/2025-Q1-088",
      "quantity": 1450,
      "uom": "KGM"
    }
  ]
}

3. Encrypt. One transformation-event credential, encrypted, advertised with encryptionMethod and accessRole. The aggregator gives the AES key to the contracting manufacturer (shared secret, or DID-Auth against a customer list). A stranger who fetches the href gets ciphertext. Graph traversal past this node requires the key.

"dte": [
  {
    "href": "https://creds.savanna-aggregators.example/dte/transformation-2025-Q1-088.enc",
    "title": "Aggregation transformation event",
    "type": "application/vc+jwt",
    "encryptionMethod": "AES-128",
    "accessRole": ["untp:accessRole#Customer"]
  }
]

4. Trusted auditor. The transformation event stays private (or encrypted for the auditor only). A CAB issues a public DCC that the batch DPP cites as evidence. The DCC says the batch meets the deforestation criterion; it does not list farm identifiers. Downstream buyers verify the claim without traversing to the farms.

"dcc": [
  {
    "href": "https://creds.sample-cab.example/dcc/cocoa-2025-Q1-088.json",
    "title": "EUDR plot-of-origin conformity",
    "type": "application/vc+jwt"
  }
]

{
  "type": ["ConformityAssessment"],
  "assessmentCriteria": {
    "id": "https://example-scheme.example/eudr/plot-of-origin",
    "name": "Plot-of-origin and legality",
    "conformityTopic": "environment.deforestation"
  },
  "conformity": true,
  "assessedProduct": {
    "id": "https://id.savanna-aggregators.example/cocoa/batch/2025-Q1-088"
  }
}

The four tools compose. An aggregator might encrypt the transformation event for the contracted buyer (encrypt), issue a public DPP with a trusted-auditor DCC (trusted auditor), and keep a regulator variant of the farm list (variant) without ever publishing farm identities to the open web.

Durable storage

Managing protected data durability is important to ensure that product and facility information remains accessible even after the original supplier or publisher is no longer in business. For storage patterns, verification dependency closure, downstream custodian copies, and an example preservation package, see the Durable Storage design pattern.