GA4GH Data Passports Study Group

Minutes and Actions

These are the minutes for the Data Passports study group.  

Table of Contents

Meeting Protocols

Meeting Details

Data Passports

Meetings

2025-11-04

Meeting Protocols

• Please note that by participating in meetings, attendees agree to adhere to the GA4GH Standards of Professional Conduct.

Meeting Details

• Meeting link: https://us02web.zoom.us/j/89339522201 
• Passcode: GA4GH

Data Passports

Data Passports offers computable governance for data access policy. It aims to represent data use constraints and information, that includes regulatory and policy expectations, and extends the GA4GH Passports specification by defining a set of data visas encoding data-level policy attributes.

Objectives of Data Passports:

1. Define a structure to standardize data access policy information (“metadata”)
2. Provide policy makers with more direct control and better ability to communicate regulations within technical systems
3. Put policy “metadata” with data in a machine readable format
4. Support policy compliance by checking Researcher Passports’ alignment with Data Passports

Resources:

Slide deck - DSWS presentation on Data Passports

2025-11-04

Chairs: Tom Conner, Jonathan Lawson

Meeting attendees:  Tom Conner (TC), Angela Page (AP), Dylan Spalding (DS), Jaime Delgado, Martin Kuba, Laura Paglione, Gregory Rushton (Broad) (GR), Ann Novakowski (Sage), Jinny Park, Jessica Seegobin (JS), Jonathan Lawson (JL), Timothy Slade, Binam Bajracharya, Simon Jobson,, C.D. Tiwari (C.D.T), Wendi Bacon, Debbie Sebatta, Roberto Lleras (RL), Michael Baumann, Daniel Uribe (DU), Andrew Gearhart (AG), Laura Paglione (LP), Amy Brower, Lishaung Shen,Mamana Mbiyavanga, Tobias Stefan Richter, Navid (Verily)

Meeting Minutes

Welcome

JL discussed the Data Passports as an expansion of the current Passport spec, noting that we should understand important truths about data governance and access. From a product perspective, we’re trying to solve the problem of what should be done to be on the list of approved data users, what is the data and and what can be done with it.  

Scope of product

TC suggested we should discuss whether this encompasses a ‘new’ product, or an update to an existing product.

AP added that as per the PDAP, the main deliverables are a problem statement which outlines the problem that needs to be solved and reiterates that GA4GH can address that; a landscape analysis to evaluate what’s happening in this domain. She noted these outputs need to be presented to PSC and if approved, the group can proceed into the development stage.

AP (chat):

“Materials to be shared with PSC at least two weeks before voting deadline

10.1.1 Landscape Analysis

10.1.2 Use cases (and users)

10.1.3 Potential adopters

10.1.4 Problem statement

10.1.5 Where applicable, summary of adopter view of previous version

Criteria for guiding decision to advance to development phase

10.3.1 Is there engagement from a varied cross-section of the community?

10.3.2 Is the problem, as stated, of broad interest and utility?

10.3.3 Is there a need for new work? Could existing products be used effectively?

10.3.4 Have any pre-development interoperation concerns been identified and clearly scoped?

10.3.5 Does the problem fit within GA4GH’s remit?

10.3.6 Is the Problem Statement in line with GA4GH’s decentralised and federated philosophy, where we avoid centralised infrastructure?

10.3.7 Is the Problem Statement clearly defined?

10.3.8 Does the content of the Problem Statement make sense?

10.3.9 Is it likely that the product will be adopted? Is it addressing a sufficiently important issue that stakeholders are likely to dedicate resources to development and adoption?”

TC suggested that Data Passports could manifest as updates to AAI and Passports as products that currently exist. The PDAP process for a rev is likely different from a new product.

TC clarified that initially, it was thought to be a new product, but this may actually be another type of a Passports as Data Passports is a Passports; compared to the existing ‘Researcher Passports,’ the Data Passports subject is the dataset.

JL noted conceptually, Data Passports are the same with a similar structure. Even if it’s a change to Passports, it’s doubling the size of the Passports. AP noted this could be a ‘scope change’ which means it needs to go through the study group phase.

TC noted that in addition to Passports itself, there’s a need to get standardization of a policy engine and enforcement point that looks at the data and policy authorizations. This may be a reference implementation of Passport and AAI, rather than a product.

AP mentioned that the PDAP doesn’t require reference implementations. TC noted the DSWS meeting discussion highlighted the need for building implementations, whether it be a third-party or done with the tech team owned by GA4GH as a starter kit, where the product would be a spec. TC suggested the importance of building the spec at the same time to identify issues proactively.

AP added this involves verified implementations, which are implementations that are developed  by a third party organization without requiring us to create a new one.

Technical discussions

The team reviewed a previous presentation, looking at Data Passports. TC noted the link to a pre-print article which was developed (attached  in the presentation). He added there’s a need for consistency and clarity and discoverability of the policy on data.

TC described the proposed Visa types, mentioning the distinction with Data Passports compared to the current Passports that are researcher based. JL added there may be a possibility to expand these five Visa types in terms of scope of the terms.

RL asked about the having ApprovedUsers list as part of defining Data Passports and the issues in terms of data, user privacy, sovereignty. JL replied that the Data Passports would be held next to data in a core data infrastructure operating the policy engine, though there needs to be more work to address these questions.

DS (chat): “The approved users could be used to define the roles that a user has that can access data, e.g. a clinical for primary use”

GR suggested thinking about scale, given that the Approved Users and RequiredAgreements could be very large.

TC mentioned this could become a JSON LD schema that lays out the attributes for each of these Visa types, defining the behavior of the access evaluation, links to users, oversight bodies, and an accompanying definition of policy enforcement with respect to the actual data in the Passports.

LP noted her work with NIH from MFA and identity assurance, noting its evolving  importance. TC echoed this idea, adding there’s a policy that requires folks to be authenticated to identity assurance level two for gaining access to controlled access data.

DS (chat): “LoA is an issue for GDI so support that”

LP (chat): “We may also want to look at agentic uses of data (AI)”. TC noted the GA4GH group on federated ML/AI, which looks at federation of these workloads and issues of access to data.

JL (chat): “if you're interested, out yesterday: https://papers.ssrn.com/sol3/papers.cfm?abstract_id=5683067”. JL suggested that liability will be ascribed back to an entity, either human, software, LLM, etc, which means there will need to be representation of an entity as a user.

TC suggested one of next steps might be to write a draft either an update to the Passports spec, or draft of the data visa types, as a standalone document. He noted that this would help advance discussions on the concrete elements in the schema.

JL encouraged participants to provide feedback on the five categories of Visa types, especially if there are bullet points that are missing, and to share their use cases. He noted the need to garner perspectives outside the US, noting the relevance of GDPR, sub-saharan Africa, East Asia, etc.

TC noted the complementary relationship with the existing Researchers Passports, which enables dynamic access control, behavior of the orchestration, and auditable, reproducible access decisions. He acknowledged that these may not fit into a JSON LD schema, which may warrant a document for starters as either an ontology or some other representation with a policy engine. This may require further consideration.

TC mentioned that this is a different time from when the Researcher Passport was created, noting Data Passports presents an opportunity to be created through onboarding and ingesting the data into the data repository. The second opportunity to generate a Passport would be any kind of approval process.

TC added the ConsentedDataUseTerms looks at a data use statement or data use agreements that have been signed, where this data visa would indicate whether that particular document has been accepted. JL shared data use agreements are institutional, whereas ConsentedDataUseTerms descend directly out of consent forms that are represented unilaterally with single signed institutions. He clarified that ConsentedDataUseTerms  involves the consensus of data sharing, and RequiredAgreements are the constraints on data use, access and sharing that institutions put up, where consent comes from participants, required agreements comes from institutions.

C.D.T (chat): “My apologies if I miss the boat to check about federated data and federated identity alignment with researcher identity is in the scope for data passport/visa with the trend moving to federated TREs ?”  JL’s response (chat): “I think this may be solved by the 'ApprovedUsers' visa types; which likely deserves the most refinement in the next few weeks”

DU (chat): “https://genobank.io/whitepapers/ga4gh-bionft-sequentia/  to propose decentralized GA4GH passports and Agentic Data Passports using Blockchain based GA4GH NFTs”

DU added that his team developed an internal protocol that could be extended to discuss how to make these credentials decentralized, especially if there’s interest in discussing why blockchain could be a good ally. He suggested this could give agenda easy access to a data wallet and credentials as NFTs.  JL suggested the first steps for Data Passports may involve starting with the schema and the components, and then talk about interchanging that in different ways.

JL also mentioned the need to ensure we’re talking about the datasets itself to allow for appropriate representation. He added that in addition to putting these five different Visa categories in a document, we should also explore some schema architecture. These schematics will also help us understand what we expect to be on the data in a Data Passport, versus what shouldn't be there.

Next steps

MB (chat):

“ Given data passports are a new product (lower case, at least), it seems we need the following to move forward, correct? Materials to be shared with PSC at least two weeks before the voting deadline.

10.1.1 Landscape Analysis

10.1.2 Use cases (and users)

10.1.3 Potential adopters

10.1.4 Problem statement

10.1.5 Where applicable, summary of adopter view of previous version

Criteria for guiding decision to advance to development phase”

The group reviewed the next steps.  TC noted that we have beginnings of drafts on some of these supporting documents, but noted that this will require some more work and can’t be finished shortly. He suggested a year from now, at the Fall September 2026 Plenary, would be a good opportunity to see this become an actual approved spec.

AP noted that to get this approved for development at the next product steering committee (PSC) meeting, which would be in January, all of these deliberables would need to be completed. Then, from January until September, the team would have to work towards final approval if it’s to be released at the Fall PSC meeting. She added that the January PSC meeting dates haven’t been decided yet.

TC suggested having a draft of a schema ready for January 2026 PSC meeting.

TC also added that developing policy enforcement spec should also be explored. JL suggested it may be too ambitious to build both the enforcement and schema by January 2026.

AP noted that it may be help to have a rough outline of the product that will be delivered in response to the problem statement

Meeting Frequency

TC suggested a bi-weekly meeting rhythm for more technical meetings about the contents of these deliverables, potentially with pauses in light of upcoming holidays.

AP also recommended encouraging folks to offer two options (e.g. one month ET mornings, another month AEST/BST mornings, etc).

JL suggested that given everyone’s schedules and various time zones, it may be more efficient to participate in a Google Doc actively, rather than relying on a lot of meetings with TC and JL soliciting different items. TC added GitHub PRs may also be useful.

Actions/Next Steps:

1. In order to join the Data Passports study group mailing list, please reach out to Jessica Seegobin.

2. Prepare a draft of a schema with the initial spec focusing on the five Visa types, including technical and policy considerations - Tom Conner

• Prepare a Visa Type schema & Policy Enforcement spec Draft, possibly for January 2026. (Possibly aim to go for approval for product development at the  September 2026 PSC)

3. Complete these PSC deliverables:  Explore whether we can aim for January 2026 PSC Meeting (dates to be determined)

10.1.1 Landscape Analysis

10.1.2 Use cases (and users)

10.1.3 Potential adopters

10.1.4 Problem statement defining the topic and stating clearly what will be in and out of scope

10.1.5 Where applicable, summary of adopter view of previous version

4. Complete PRC, Regulatory & Ethics and Data Security Meetings (More details in points 6.1.5.3 and 6.2 in the PDAP)

Meeting Frequency:

• Explore biweekly technical meetings (potentially with pauses in light of holidays) at two different, alternating times
• Conduct work asynchronously via Google Docs