Skip to main content

2026-02-19 1854 AEDT

Feb 19, 2026

UN CEFACT GTR Project - AUS / EU​

Attendees:

  • Alina Nica Gales
  • Hans Huber
  • Harmen van der Kooij
  • Jesus San Fernandez
  • Jo Spencer
  • John Phillips
  • Sankarshan Mukhopadhyay
  • Steve Capell

Summary​

Review Process and Timeline Clarified
The project confirmed that due to UN constraints, the forum/plenary is now scheduled for November, but the Business Requirement Specification only requires UN/CEFACT Bureau approval for its 60-day review, meaning delivery can happen outside the plenary window. This clarified the project's non-policy documents can be finalized on a more flexible schedule.

Prioritizing Specification and Pilots
The primary focus is generating a high-quality technical specification first, supported by evidence from pilot implementations like those in Spain and India, which will inform any subsequent policy recommendations. Participants agreed that the live GitLab site, not static documents, must be the authoritative source for the specification, with versioned releases frozen only for the required public review period.

Refining DIA Scope and Definitions
The team refined document structure by immediately merging updates to the glossary and eligibility requirements to focus the scope on authoritative 'trade relevant' registrars. Discussions emphasized keeping the Digital Identity Anchor (DIA) simple and atomic, linking to only one type of identifier to avoid architectural complexity related to multiple lifecycles or liabilities

Details​

NEEDS FURTHER DISCUSSION​

  • Schedule Visualization Structure Schedule visualization splits into two separate charts: one reflecting project specification document release process, separate chart detailing possible recommendation process for November plenary.

  • Machine Readable Data Domain Investigate setting up CI/CD pipeline to deploy JSON structure data to permanent domain name, utilizing HTTP accept headers allowing browser to view human readable page, machine to see machine readable data.

  • Digital Identity Anchor Scope Future discussion about DIA implementation focuses narrowly on providing specific use case and descriptions for DIA use in relation to Grid and authoritative registers context.

DISAGREEMENTS​

  • Digital Identity Anchor Architecture DIA architecture should link multiple DAS (Digital Identity Anchors) to a single DID document rather than attempting to lock all into one DIA, accommodating different life cycles, expiry, and renewal dates.

ALIGNED​

  • GitLab Site Authoritative Specification Authoritative specification will be GitLab site, not PDF document. Specification documentation uses point-in-time versioned release (e.g., 0.x) for public review, allowing continuous maintenance of the latest bleeding edge version.

  • Project Schedule Relaxation Project schedule will relax by a couple of weeks, aiming publication of project documents in a time frame allowing bureau look-over, agreement, crystallization of recommendation before June/July timeframe.

  • Development Sequence Technical Specification Development sequence must prioritize writing high quality technical specification first, informed by pilot implementations, then writing policy recommendation based on successful pilots and technical specification.

  • Merge Glossary Eligibility Requirements Merge changes to document content moving glossary earlier in document set and strengthening eligibility requirements wording for authoritative register, despite need for future refinement.

  • UNIC GitLab Account Issue Resolution John Phillips will forward Hans's registration email and response details to relevant contacts. Contacts asked to help resolve UNIC GitLab account registration request.

More details:

  • Meeting Logistics and Conduct: John Phillips proposed the agenda, which included a review of meeting minutes, a discussion of the project schedule, and a focus on proposed issues, discussions, and merge requests. They confirmed the meeting is operating under the UNECE/UN/CEFACT open development process, which includes intellectual property rules and codes of conduct. Participants were reminded to note their presence if they are not actively speaking, and the recording, transcript, and minutes will be made available shortly after the meeting [00:00:00].

  • Screen Sharing Issue: Sankarshan briefly interrupted the discussion to inform John Phillips that the screen share was not active, which John Phillips quickly acknowledged and corrected [00:00:51]. John Phillips used this moment to humorously compare the assumption of visibility to a child's perspective [00:01:42].

  • Locating Meeting Minutes: John Phillips showed participants where to find the minutes from previous meetings, noting they are available in the GitLab repository under the "docs and meetings" folder and are also presented on the project website as rendered pages [00:01:42].

  • Initial Discussion on Schedule and UN/CEFACT Forum: John Phillips proposed using the UN/CEFACT Forum, which they initially believed was scheduled for May 2021, as the target date for the project's output, a Business Requirement Specification (BRS). They noted that a BRS requires a 60-day public review period, even though the documents are continuously available on GitLab [00:02:45].

  • Correction of Forum Dates and Review Process: Steve Capell corrected the meeting date, stating there is no May forum, but rather a combined forum and plenary scheduled for November due to UN budgetary constraints. Steve Capell clarified that the project's deliverables, excluding policy recommendations, only require UN/CEFACT Bureau approval for the 60-day review process and subsequent finalization, which can happen out of session at any time [00:03:59].

  • Project Activity Threads and Timeline Proposal: John Phillips identified two main threads of activity: the Digital Identity Anchor (DIA) specification and the body of work describing the grid, which they refer to collectively as the BRS. They proposed a revised schedule where documents would reach a declaration of a "release version" (e.g., version 0.something) after about a week of work, followed by three weeks of working on traceable changes before declaring the documents final and releasing PDF/Word versions [00:05:50].

  • Authoritative Document Format: Steve Capell emphasized that the authoritative specification should be the GitLab site, not a static PDF or Word document, particularly for technical specifications and live registries. Steve Capell offered to support this stance within the bureau, citing similar challenges with the UN Trade Portal (UNTP) [00:06:53].

  • Versioning for Public Review: Steve Capell suggested adopting a versioning approach similar to UNTP, where a point-in-time versioned release (e.g., 0.6 or 0.7) is frozen for the 60-day public review, allowing continuous maintenance and updates on the latest, bleeding-edge version [00:07:56]. John Phillips agreed that this approach makes sense, especially given the project's use of Docsaurus, which supports version freezing [00:09:37].

  • Policy Recommendation vs. Specification Timeline: Alina Nica Gales inquired about the deadline for public review given the November plenary. Steve Capell explained that only policy recommendations (which would be Recommendation 52, if written) require plenary approval, necessitating working backward from November to have a public review draft ready by June or July [00:11:28]. Other project documents only require Bureau approval and can be delivered at any time [00:12:59].

  • Strategy for Document Production and Testing: The participants agreed that the project should focus on writing a high-quality technical specification first, followed by a decision with the Bureau's agreement on whether to write a policy recommendation based on the finalized specification [00:14:43]. Steve Capell strongly advocated for informing the technical specification through pilot implementations, citing that evidence of successful pilots in India and Spain would increase confidence in the specification's quality and strengthen any resulting policy recommendation [00:15:50].

  • Inclusion of Pilot Projects in Planning: Harmen van der Kooij asked how pilot projects, such as those in India and Spain, fit into the immediate upcoming months [00:18:06]. Alina Nica Gales noted that Spain’s pilot is active, but they are focused on harmonizing the initiative with the European Commission’s We.build project. Harmen van der Kooij confirmed that their work with the Dutch Chamber of Commerce is facing the same harmonization topics [00:19:02].

  • Pilot Implementation Independence: Steve Capell clarified that pilot projects can run independently of policy recommendations or the 60-day public review period, emphasizing that the primary goal is to publish a quality specification supported by evidence that it works [00:19:51]. Harmen van der Kooij confirmed that their existing work, partially funded by the Dutch Chamber of Commerce and Tax Office, could be included as a UN Grid pilot, as it already aligns with the Digital Identity Anchor (DIA) concept [00:21:31].

  • Refining the Project Schedule: John Phillips committed to revising the schedule to create two separate charts: one focusing on the first draft of the project specifications and another on the possible recommendation process for the November plenary, to separate the specification work from the policy decision [00:24:33]. Harmen van der Kooij further clarified that their facilitating role for the pilot involves running projects for the Dutch Tax Office and Chamber of Commerce, who are the authoritative public registries involved [00:25:28].

  • Addressing Registry Scope and DIA Use: Steve Capell noted that while the Grid has a formal governance scope limited to authoritative national registers, the DIA concept is used more broadly by UNTP for identity linking that may not fall under the Grid governance, such as a beekeepers association issuing a DIA [00:27:13]. All tests of the architecture, even outside the formal Grid context, are considered valuable [00:28:35].

  • Review of Merge Request for Document Structure (Issue #31): John Phillips introduced a merge request aimed at fixing issues in the documentation, specifically by elevating the glossary to an earlier section of the document set [00:29:44]. This change ensures that essential terms like "authoritative registrar" are seen before the legal governance and target operating model document that rely on them [00:30:34].

  • Refinement of Eligibility Requirements and Terminology: The merge request also included a revision of the eligibility requirements in the Target Operating Model document to be more precise, for example, restricting membership to UN member states who choose to participate and have an authoritative registrar [00:31:35]. Alina Nica Gales and John Phillips discussed the definition of "authoritative registrar," specifically John Phillips's addition of "trade relevant" to the term "official identifiers" to narrow the scope and prevent expansion into non-trade related social or personal digital identity matters [00:33:31] [00:36:27].

  • Merging and Continuing Document Improvements: John Phillips proposed merging the changes to the glossary and eligibility requirements immediately to make the content live, while acknowledging that the document is still a work in progress and will require further iteration and improvements [00:37:27]. The merge triggered an automatic pipeline to rebuild the website and run checks in a dummy pilot environment [00:38:18].

  • JSON Data Representation for Registrar Data: John Phillips introduced a second waiting merge request to improve the representation of registrar data, which is currently a simple Markdown table, by converting it to a more robust, machine-readable JSON format [00:39:22]. Steve Capell suggested adopting a process similar to UNTP, where a JSON structure stored outside the Docsaurus structure could be deployed via a CI/CD pipeline to a permanent domain, utilizing HTTP Accept headers to serve either a human-readable web page or the machine-readable JSON [00:40:37].

  • Discussion on Digital Identity Anchor (DIA) Complexity: The group discussed an ongoing issue regarding the scope and complexity of the DIA, focusing on whether to allow it to link to multiple types of identifiers [00:44:03]. The discussion trended towards keeping the DIA simple and "atomic," meaning one DIA should link to only one type of identifier issued by the registrar, even if the registrar offers multiple services (e.g., Spanish business identifier, LEI, and EU ID) [00:45:06].

  • Architectural Principles of the DIA: Steve Capell agreed with the "atomic" approach, suggesting that linking multiple identifiers should be managed through multiple DIAs aggregated in a DID document. Steve Capell emphasized that the DIA's purpose is to link an authoritative identifier to a self-controlled digital asset, and creating one DIA for multiple identifiers with different lifecycles or expiration dates would create unnecessary messiness [00:48:14].

  • Liability and Identity Control Concerns: The conversation shifted toward the liability and control required when a person who controls a DID requests a registrar to link it to a business's authoritative identifier [00:50:25]. Hans raised a concern about linking a natural person's DID to a legal entity, which Steve Capell clarified is an issue of proving the DID controller is an authorized officer of the business, not an issue of identifying the person [00:55:34].

  • Conclusion on DIA and Next Steps: John Phillips suggested concluding the conversation and proposed two actions regarding the DIA issue: that interested parties should read and contribute to the existing discussion thread, and that the project needs to narrow its focus to specifically explain the DIA's use within the context of the Grid and authoritative registrars. Hans also raised a problem with their blocked GitLab account, which participants identified as a UN/CEFACT internal administration issue outside of their control [00:57:15].

  • GitLab Account and Contributor Status: The process for engaging with the project requires two steps, starting with the creation of a general UNICC GitLab account, which is approved by New York and can take one or two days. Having this account allows for ticket creation, but to push content, one needs the project maintainer, identified as John Phillips, to make them a contributor. Obtaining a UNICC account is sufficient for creating tickets [00:59:16].

  • Troubleshooting Account Access: Hans indicated that they have credentials for the UNICC account but that it does not seem to work [00:59:16]. John Phillips suggested that there is likely a help desk email address at uniccc.org or similar, though Steve Capell was not aware of a specific contact as they did not experience issues creating their account. John Phillips committed to assisting Hans by asking them to send an email detailing the registration response or email address used so they could forward it to relevant contacts for help with the registration hold [01:00:07].

  • Meeting Conclusion: John Phillips ended the discussion, thanking the participants for the conversation. John Phillips wished everyone a good day or evening and mentioned that they would stop the recording [01:00:07].

Suggested next steps​

  • Hans will send John Phillips an email with the registration response or the email address used to register.

  • John Phillips will forward Hans's registration information to the people he has been in touch with before to ask for help.

Chat Discussion​

00:42:05.879,00:42:08.879

Harmen van der Kooij: we are doing the exact same thing with all the catalogs on (human readable pages backed by json files in a public github) https://fides.community/

00:51:58.196,00:52:01.196

sankarshan: For this particular conversation I'd like to know if the participants feel that we have arrived at a definitive agreement and can update the ongoing issue and resolve the comment with a final stance/decision.

00:54:51.480,00:54:54.480

Jo Spencer: Two issues on the DID to DIA design - 1. Retained validity of a DIA if changes are made to the linked DID docs and 2. commercial effort of making changes to a DIA and the implied effort and cost of changing the DIA due to linked DID changes. We mustn't create a commercial imbalance

00:56:18.070,00:56:21.070

Jo Spencer: ...and we also don't want to make a complicated process of xhange

00:58:08.027,00:58:11.027

sankarshan: Link to the issue: https://opensource.unicc.org/un/unece/uncefact/gtr/-/issues/3

00:58:38.431,00:58:41.431

steve capell: I think we are confusing what is the INTENT and what is possible.

00:59:15.663,00:59:18.663

Harmen van der Kooij: I have to go now. Good discussion. Talk soon