Digital Corporate Record

info

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

Proposed credential — scope under review

The Digital Corporate Record was accepted as a v1.0 requirement and its scope is settled. The schema is a working draft pending working group review of this page. Design discussion and the decisions behind it are in issue #688.

Artifacts

V0.8.0 Schema and Samples

• JSON Schema:

Schema	Description
DigitalCorporateRecord.json	Full credential schema including the W3C VC envelope and the legal entity subject
CorporateRecord.json	Standalone schema for the credential subject

• Sample Instances:

Sample	Description
DigitalCorporateRecord_instance.json	The Japanese copper refiner from the sample supply chain

• Diagram:

Diagram	Description
CorporateRecord.puml	PlantUML source for the logical model diagram

Vocabulary and Context

The DCR reuses the UNTP Party structure and borrows the rest of its model from the W3C Organization Ontology, with dates from schema.org. It defines almost nothing of its own — see Borrowed, not invented.

Overview

Supply chains are operated by legal entities: companies, holding companies and operating subsidiaries. UNTP could already describe a facility and a product, but the company behind them appeared only as a Party reference — a name and a registered identifier attached to some other record. There was no way to look up the entity itself, to see which facilities it operates, or to follow a corporate structure upwards to the group that controls it.

The digital corporate record (DCR) fills that gap. It is a verifiable description of a legal entity: who it is, where it is registered, which facilities it operates, which entities it owns or is owned by, and what it claims about its own performance. It is issued by the organisation itself — the only party that holds this content — and it gives a corporate identity something the rest of the UNTP graph can point at. The register's role is to anchor the identity the record is published under, not to publish the record.

A DCR is not an assessment of a company. Where an independent party has assessed an entity, that assessment is a Digital Conformity Credential, issued by the assessor and linked from the claim it supports.

Conceptual Model

A Digital Corporate Record answers five questions about a legal entity:

• WHO is the entity — its identifier, registered name, registered identifier and the scheme that issued it.
• WHERE is it registered and addressed — registration country and registered address.
• WHAT does it do — industry classification.
• WHICH assets and entities does it control — the facilities it operates and the entities above and below it in the ownership chain.
• WHAT does it claim — performance claims made at group or corporate level, with evidence.

Requirements

The digital corporate record is designed to meet the following requirements, as well as the general UNTP Requirements.

ID	Name	Requirement Statement
DCR-01	Resolvable identity	The DCR MUST identify the entity with a resolvable identifier, together with the registered identifier and the scheme under which it was issued.
DCR-02	Source and currency	The DCR MUST carry the scheme that issued the registered identifier, and MUST state its own validity period, so that a verifier can reach the authoritative register and judge how current the record is without fields that restate register data. The linked Digital Identity Anchor carries the register's own assertion.
DCR-03	Corporate structure	The DCR MUST provide a means to reference the entity that directly controls it, the entity at the top of its ownership chain, and the entities it controls. An issuer MAY omit any of them.
DCR-04	Facility linkage	The DCR MUST provide a means to reference the facilities an entity owns or operates, identified as they are in their Digital Facility Records.
DCR-05	Corporate claims	The DCR MUST provide a means to make performance claims at corporate level, using the same claim structure as product passports and facility records.
DCR-06	Alternative identity	The DCR MUST provide a means to carry additional registered identifiers for the same entity — tax, VAT or trading identifiers — each with the scheme that issued it.
DCR-07	Identity anchoring	The entity SHOULD be anchored by a Digital Identity Anchor issued by its register, and register-asserted facts SHOULD be carried by that anchor rather than restated here.
DCR-08	Disclosure control	Corporate structure and identifiers can be commercially sensitive. Every property other than those required by DCR-01 MUST be optional, and an entity SHOULD be able to publish a public record and a fuller restricted one under the same identifier using Decentralised Access Control.

Logical Model

The Digital Corporate Record is an assembly of re-usable components. The diagram below shows the corporate record — the credential subject carried inside the credential envelope — and the components it composes. The surrounding W3C Verifiable Credential envelope (issuer, validity, status, rendering) is omitted for clarity; it is shown in full under Credential Schema.

Read it outwards from CorporateRecord at the top. The entity's own attributes sit in that box. To the left, the relationships that place it in a group: immediateParent, ultimateParent and subsidiaryRecords all point at a Party, because a related entity is identified here rather than described — it may or may not publish a record of its own. relatedFacility points at a Facility in the same way, identified as it is in its Digital Facility Record.

To the right, performanceClaim reaches the same Claim structure used by product passports and facility records, with its criteria, evidence and measured performance. Each box is an object; each labelled arrow is a property, with its cardinality (1, 0..1, *) shown at the target end.

Note what is not in the diagram: nothing about whether the entity is validly registered, in good standing, or what legal form it takes. Those are the register's assertions and live on the identity anchor.

Credential Schema

The full JSON Schema for the credential — the W3C Verifiable Credential envelope wrapping the corporate record subject.

Loading schema viewer...

Borrowed, not invented

The corporate model is deliberately thin. Almost every property is either an existing UNTP term or a term from a published W3C vocabulary:

Property	Comes from
id, name, registeredId, idScheme, partyAddress, industryCategory, partyAlsoKnownAs, registrationCountry, organisationWebsite	the existing UNTP Party
immediateParent, ultimateParent, subsidiaryRecords	org:subOrganizationOf, org:transitiveSubOrganizationOf, org:hasSubOrganization
relatedFacility	org:hasSite
foundingDate	schema:foundingDate
registrationScope (legal form)	UNTP's own, shared with the Digital Identity Anchor
performanceClaim	the existing UNTP Claim structure, as used by the DPP and DFR

Two consequences follow. A verifier that already understands org: can traverse a UNTP corporate structure without learning anything UNTP-specific. And the model gains no aggregated code lists, which would otherwise have to be maintained and would decay.

Implementation Guidance

Who issues a DCR

A DCR is issued by the organisation it describes, exactly as a Digital Facility Record is issued by the facility operator. The entity is the only party that holds the content: which facilities it operates, how its group is structured, what it claims about its own performance.

A register should not publish a corporate record about an entity. Not because it would be forbidden, but because it would be asserting things it is not in a position to know, and it would compete with the entity's own record for the same identifier. This is the same principle as claimed and unclaimed identifiers on the facility side: a register maintains identifiers, it does not speak for the parties behind them.

A DCR is therefore self-declared by design. Its weight comes from what it links to — the identity anchor, conformity credentials issued by assessors, facility records that corroborate the sites it claims — not from the issuer's own say-so. That is the ordinary UNTP pattern, not a weakness peculiar to this credential.

Relationship to the identity anchor

The two credentials divide by what each party can actually assert:

	Digital Identity Anchor	Digital Corporate Record
Issued by	the register	the entity itself
Asserts	this identifier belongs to this registered entity, with its registration status	the entity's facilities, corporate structure, activities and claims
Trust comes from	the registrar's listing in the UN GRID	the anchor, plus the credentials the record links to

Register-asserted facts are not restated here, so that "is this company real and in good standing" stays answerable from the anchor alone — which is what a verifier checks before reading anything the entity says about itself. Legal form is the one deliberate exception, carried in both so that a corporate record remains readable where no anchor has been issued yet.

The entity's identifier is the join: the identifier the anchor binds is the id of the corporate record's subject. Between them they also answer how current the record is, without a field restating register data — the idScheme names and resolves to the register, the anchor carries its own validity, and the record's validFrom and validUntil bound the entity's self-declared content.

Traversing a corporate structure

Parent and subsidiary references carry an identifier, not an embedded record. A verifier follows the identifier the same way it follows any UNTP identifier — through an Identity Resolver — to find that entity's own corporate record, if one is published. This keeps each record small, keeps each entity's data under its own control, and avoids a group-wide record that goes stale the moment any part of the group changes.

Traversal is therefore best-effort by design. An entity MAY name a parent that publishes nothing. That is a normal state rather than an error, and a verifier MUST NOT treat an unresolvable reference as evidence that the relationship is false.

Handling commercially sensitive data

Corporate structure and identifiers are commercially sensitive in many markets. The DCR handles that in three layers, and it is worth being explicit about them because the instinct is usually to reach for the last one first.

Everything beyond the identity fields is optional. An entity that does not wish to publish its ownership chain simply omits immediateParent, ultimateParent and subsidiaryRecords. The record stays conformant. Optionality is the primary protection, and it needs no machinery at all.

The record carries no personal data. The DCR describes corporate structure — which companies own which — not the people behind them. Directors, officers and shareholders are deliberately absent. That keeps the credential outside the scope of most data protection regimes and makes it materially less sensitive than a beneficial ownership disclosure, which is a different instrument with a different legal basis.

Two records, two audiences. Where an entity wants to publish some corporate data openly and share more with selected counterparties, the clean pattern is to issue two credentials: a public record carrying identity, activity and facilities, and a fuller record adding the ownership chain and additional identifiers, released to trusted parties through Decentralised Access Control. Both are valid DCRs about the same entity, and both resolve from the same identifier through the Identity Resolver, which returns the links a given requester is entitled to see.

Two records is usually simpler than one encrypted record with selectively disclosed fields, and it fails safe: a verifier that cannot see the restricted record sees a complete, conformant public one rather than a record with holes in it.

The components of a DCR

Credential envelope

All DCRs are issued as W3C Verifiable Credentials (VCDM 2.0). The credential type includes both VerifiableCredential and DigitalCorporateRecord.

"issuer": {
  "type": ["CredentialIssuer"],
  "id": "did:web:sample-refinery.example.com",
  "name": "Sample Copper Refinery Co. Ltd"
},
"validFrom": "2026-03-01T00:00:00Z",
"validUntil": "2027-03-01T00:00:00Z",
"name": "Digital Corporate Record — Sample Copper Refinery Co. Ltd"

A validUntil is worth setting on a corporate record. Registered facts change without notice, and an expiry tells a verifier when to go back to the source rather than trusting a cached copy indefinitely.

Entity identification

"credentialSubject": {
  "type": ["Party"],
  "id": "did:web:sample-refinery.example.com",
  "name": "Sample Copper Refinery Co. Ltd",
  "registeredId": "REF-001",
  "idScheme": {
    "type": ["IdentifierScheme"],
    "id": "https://www.sample-register.example.com",
    "name": "Sample National Business Register"
  },
  "registrationCountry": { "countryCode": "JP", "countryName": "Japan" },
  "foundingDate": "1973-04-02"
}

Additional identifiers for the same entity — a tax number, a VAT number, a trading identifier — go in partyAlsoKnownAs, each with the scheme that issued it. There is no separate field per identifier type; the scheme says what the number is.

Legal form

"registrationScope": ["https://www.houjin-register.example.com/EntityType?Id=kabushiki-kaisha"]

registrationScope carries the entity's legal form as the register's own URI for it — a Kabushiki Kaisha, a GmbH, an Australian private company — together with any other registered roles or scopes. It is the same property, with the same meaning, as registrationScope on the Digital Identity Anchor, so a verifier reads legal form the same way whether or not an anchor is available.

Two consequences are worth stating.

No aggregated code list. UNTP does not maintain a list of the world's legal forms, and does not adopt one. Each national register already publishes its own entity types authoritatively; a roll-up of them is an incomplete copy that decays, and usually cannot be dereferenced. Pointing at the register's own definition keeps the authority where it belongs.

Legal form answers ownership type. Whether an entity is publicly listed, privately held, state-owned or a co-operative is implied by its legal form in its own jurisdiction — that is what legal forms encode. So there is no separate ownershipType field, and no controlled vocabulary to maintain for one.

Where a Digital Identity Anchor exists, it is the authoritative statement of the same fact, because the register asserts it there. The copy here keeps a corporate record readable on its own, which matters while anchors are not yet universal.

Corporate structure

"immediateParent": {
  "type": ["Party"],
  "id": "did:web:sample-holdings.example.com",
  "name": "Sample Copper Holdings Pty Ltd",
  "registeredId": "90664869327",
  "idScheme": { "type": ["IdentifierScheme"], "id": "https://abr.business.gov.au", "name": "Australian Business Register" }
},
"subsidiaryRecords": [
  {
    "type": ["Party"],
    "id": "did:web:sample-refinery-logistics.example.com",
    "name": "Sample Refinery Logistics KK",
    "registeredId": "REF-014"
  }
]

immediateParent and ultimateParent are the same entity in a two-level group, and differ where a group has intermediate holding companies.

These are identifiers, not credentials. A parent or subsidiary is named by its id and, where it has one, its registered identifier and scheme — nothing more. The referenced entity MAY publish its own Digital Corporate Record, in which case a verifier reaches it by resolving that identifier through an Identity Resolver, exactly as it would for any other UNTP identifier. Equally, it may publish nothing at all: plenty of entities in a group never issue a credential of any kind, and a holding company in another jurisdiction may have no UNTP presence.

So a DCR MUST NOT be read as asserting that the entities it names have records of their own. It asserts a relationship to an identified entity. Whether anything is published about that entity is discovered by resolution, not by the reference.

These relationships describe control or ownership, in the ordinary sense. They are deliberately not defined as accounting consolidation: a controlled entity can sit outside a consolidation perimeter, so a model built on consolidation answers a financial reporting question rather than a supply chain one.

Facilities operated

"relatedFacility": [
  {
    "type": ["Facility"],
    "id": "https://facility-register.example.com/fac-002",
    "name": "Sample Copper Refinery",
    "registeredId": "JP-44-SM-0021"
  }
]

The facility identifier is the one used in that facility's Digital Facility Record, so a verifier can move from the company to the site and on to the products shipped from it.

Corporate claims

Claims at corporate level use the same Claim structure as product and facility claims: a criterion the claim is made against, the standard that criterion comes from, a measured value with a metric and unit, the period it covers, and links to evidence.

Corporate emissions are the clearest worked example. Under the GHG Protocol and IFRS S2 an entity reports Scope 1, Scope 2 and Scope 3 as separate figures with different boundaries and methods, so they are separate claims rather than one aggregate. Each carries its own metric, value and evidence:

"performanceClaim": [
  {
    "type": ["Claim"],
    "id": "https://sample-refinery.example.com/claims/ghg-scope-1-2025",
    "name": "Scope 1 GHG emissions — 2025",
    "description": "Direct greenhouse gas emissions from sources owned or controlled by the group, consolidated on an operational control basis across all operated facilities.",
    "referenceCriteria": [
      {
        "type": ["Criterion"],
        "id": "https://ghgprotocol.org/corporate-standard#scope-1",
        "name": "GHG Protocol Corporate Standard — Scope 1 GHG emissions"
      }
    ],
    "referenceStandard": [
      {
        "type": ["Standard"],
        "id": "https://ghgprotocol.org/corporate-standard",
        "name": "GHG Protocol Corporate Accounting and Reporting Standard"
      },
      {
        "type": ["Standard"],
        "id": "https://www.ifrs.org/issued-standards/ifrs-sustainability-standards-navigator/ifrs-s2-climate-related-disclosures/",
        "name": "IFRS S2 Climate-related Disclosures"
      }
    ],
    "claimDate": "2026-03-01",
    "applicablePeriod": {
      "startDate": "2025-01-01",
      "endDate": "2025-12-31",
      "periodInformation": "Calendar year 2025, consolidated on an operational control basis."
    },
    "claimedPerformance": [
      {
        "metric": {
          "type": ["PerformanceMetric"],
          "id": "https://vocabulary.uncefact.org/performance-metrics/scope-1-ghg-emissions",
          "name": "Scope 1 GHG Emissions"
        },
        "measure": { "value": 118000, "unit": "TNE" }
      }
    ],
    "conformityTopic": [
      {
        "type": ["ConformityTopic"],
        "id": "https://vocabulary.uncefact.org/conformity-topics/greenhouse-gas-emissions",
        "name": "Greenhouse Gas Emissions"
      }
    ],
    "evidence": [
      {
        "linkURL": "https://sample-refinery.example.com/reports/ghg-inventory-2025.pdf",
        "linkName": "2025 group GHG inventory report",
        "linkType": "untp:evidence",
        "mediaType": "application/pdf",
        "digestMultibase": "zQmSampleDigestOfTheInventoryReport2025"
      },
      {
        "linkURL": "https://credentials.sample-assurance.example.com/dcc/ghg-2025",
        "linkName": "Limited assurance statement — Sample Assurance Services (Digital Conformity Credential)",
        "linkType": "untp:evidence",
        "mediaType": "application/vc+jwt"
      }
    ]
  }
]

The full sample carries all three. Scope 2 is reported market-based, with the location-based figure noted in the description because only one value can carry the metric. Scope 3 states which categories are included and which are not material — without that boundary, a Scope 3 number cannot be compared with anyone else's.

Note what the two evidence links do. The first is a PDF: a verifier can confirm the bytes have not changed via digestMultibase, but nothing more. The second resolves to a Digital Conformity Credential — an assurance statement issued by a third party, which a verifier can actually verify. That difference is the whole point of evidence links, and it is derived by following them rather than asserted by the issuer.

Use a corporate claim where the assertion is genuinely about the entity — a group emissions total, a labour standards commitment across all sites. Where a claim is really about one site or one product, it belongs on that facility record or product passport, where it can be checked against the thing it describes. A group Scope 1 total and a facility's own Scope 1 figure are different claims by different issuers; both can exist, and a verifier can compare them.