GA4GH Data Use & Researcher IDs Work Stream

Minutes and Actions 2021-2022

Welcome reference docs :

• What is the Access Product Line?
• Our DURI google drive
• DUO repository
• 2021 DURI Roadmap

These are the minutes for the GA4GH Data Use & Researcher IDs Work Stream. For further information, please visit the GA4GH Work Stream page (will link to the page on the website when it is ready) at ga4gh.org.

2017-2018 Minutes

2019-2020 Minutes

Meeting Protocols

• Please note that by participating in meetings, attendees agree to adhere to the GA4GH Standards of Professional Conduct.
• Meetings may be recorded for note-taking purposes. Recordings will be deleted within three months of the meeting taking place.

Sub-Group Minutes and Actions Documents

This Work Stream has meetings for the following sub groups:

• Data Use (2021 minutes)
• Researcher Identification (2021 minutes)

List of Meetings

Chairs: Tommi Nyrönen (ELIXIR), Jaime Guidry-Auvil

• 2022-12-14
• 2022-11-02
• 2022-08-10
• 2022-06-29
• 2022-05-18
• 2022-05-03
• 2022-04-06
• 2022-02-23
• 2022-01-12
• 2021-12-01
• 2021-09-08
• 2021-05-05
• 2021-03-24
• 2021-02-10

Minutes:2021-##-##: TEMPLATE

2022-12-14

Attendees “Name (Affiliation)”: Jaime, Tommi, Martin Kuba, Freddie, Pinar Alper, Soichi, Asiyah Lin

Actions

Agenda

Notes & Links

Martin - Passport v1.2. Nearly complete, going to a regular (6 week) meeting schedule. Timeline for Passport v.2? Est. 2 years.

Jaime - use case around v.2 is needed to drive spec development (motivation).

Both NIH and ELIXIR have implementations of present Passport and other GA4GH standards.

Martin - standard of co-operation is different in the US  and Europe. Europe genome data is distributed/federated across countries. In the US NIH institutes (27, common policy, individual implementations) coordinate the genomic data. US model is good for a single country, but sharing data in the global environment is a different case.

Tommi - GDI http://gdi.onemilliongenomes.eu/ implementation project that will use GA4GH framework of standards. 20 EU countries are partners, backed up by their governments. By 2026 ambition is that 15 countries will have an operational data hub that form a data federation to implement policy set by 1+MG initiative (political). Project is coordinated by ELIXIR and will use GA4GH framework of standards to increase interoperability -> GA4GH implementation forum input.

Jaime - researcher viewpoint.

Tommi - In Europe https://ec.europa.eu/digital-building-blocks/wikis/display/DIGITAL/eID 

Tommi - for future technological note, perhaps “global data traveler Passport” information of a researcher data access permissions could be encoded in a self-sovereign identity “blockchain” application on your personal mobile phone. https://en.wikipedia.org/wiki/Self-sovereign_identity 

Jaime - country of origin -> country of destination. Now : need to match for each case individually. Future - could be automated.

Jaime - NIH cloud platform interoperability project - NCPI  – linking with European GDI?

Minutes

2022-11-02

Attendees “Name (Affiliation)”:

Actions

Agenda

Notes & Links

Minutes

FJ: Happy to have a look first and volunteer. ACTION - Send to Francis!

FL: Do we need a demo implementation?

AP: +1 spec is better with one.

FL: Tom?

TN: Tom Barton Internet2 - interested in Passport Spec. Related to NIH via Chicago. Probably not for implementation.

RB (in chat): I am a BioData Catalyst PI with Alastair.  We are implementing passport with NIH RAS.  If helpful I or someone on my team can review. - ACTION - Send to Rebecca.

TN: Unsure if v1.2 is a high priority for ELIXIR implementation.

KR (in chat): +1 Rebecca. We are missing an NIH reviewer. I had hoped Alastair would review, but you could as well!

Data Access Requests -

TN: ICGC ARGO & REMS. Data Access Tools comparing technical solutions. Connect with REWS. Everyone has the challenge that we need to ask questions from applicants. Vary by country. Identity vetting. Comparing big data access forms between countries/institutions. Can support interoperability of these forms. And ultimately Passports. Beyond DURI mandate. Select a few forms as examples to discuss at Connect? Australian Genomics etc.

JL: DACReS group. Ted & Vaso as REWS leads. Right time for what’s next. Common issues across DACs. 40 DAC members. Identify toolkit for DACs to get up to speed. Standardisation of DAR forms we haven’t looked at. Standardising data access agreements - legal experts. Where should DUO be involved? How to represent that in a Passport. DAR form great idea. Common elements. Sum of components different, but common elements.

TN: Same page. Prove 80% DACs are similar. Implement that into a tool that speaks with DUO. Ask questions with DUO terms. Data access applicants are not familiar.

RB (in chat): That is very true!

JL: Already have a lot of DAC members. 40-70 represented in a mailing list already. Caveat: DAR form could be sent but not using it as is, feedback is important. Even in DUOS - certain things we have to put in by government policy.

AP: +1. Same work here in REMS. 4 different med institute DACs. No agreement in that case. Good to get a feel. Have some forms and the people using those forms. Output - let’s imagine Beacon discovery to find data sets - 15 different REMS instances & forms?? Maybe 80%

JL: NHGRI dbGaP - piloting multitenant DAC system. N DACs for N datasets. Long road.

TN: This will be the same in Europe soon. Unclear whether DACs can delegate.

JL: Legislation around DAC is not something that I am aware of. Different to IRBs. Inertia in how DACs operate. Not unwilling, just uncertain.

JL: Find DACReS list. ACTION - Maili to invite to DURI DAR Connect.

FL: Any forms?

JL: We didn’t collect any.

AP: I have some.

TN: ARGO & Australian? We can provide a Finnish one. Map form questions to DUO terms. Translate DAC requirements to DUO, e.g Hungarian terms. Jaime’s point about applicant questions should not be structured.

FJ: Survey before? Share the responses? DACReS?

JL: PowerBI software license waiting.

FJ: Static version?

JL: No click and filter, but good idea.

FL: Condensed?

JL: Worried about compliance, not technology. Will discuss it at DACReS.

FL: Is your platform

AP: Ours is fed off REMS. Aus Genomics have questions that are framed towards DUO. Others not.

TN: Template access questions could be a useful thing. REMS is a platform with Visa Issuer function.

TN: Attempt on consent clauses. Consitent translations between consent and access

FJ: Visas could include DUO statements - autocomplete request form.

AP: Visa could do that. Different way of approving requests. Approve codes rather than applications.

JL: Researchers will be represented as HMB codes - NCI tests?. Correct?

FJ: Could be piecemeal. Match subset. For profit organizations wouldn’t match.

JL: EGA - 1-4 data sets per submitter. If DACs trust each other. Distributed - Tommi’s DAC approved them for HMB - we trust Tommi, so we can share HMB with them too.

FL: Shared applications between DACs via REMS.

TN: We enabled modular DAR forms. Federated data access is still exotic.

AP: All our DACs think they are the most unique the world.

AP: Do you want the forms ahead of time?

JL: Can get an associate to look through forms. ACTION - share with JL.

2022-08-10

Attendees “Name (Affiliation)”: Sarion Bowers (Sanger), Kurt Rodarmer (NIH), Andrew Patterson (UMCCR/BioCommons), Jaime Guidry Auvil (NIH), Francis Jeanson (Datadex), Fabio Liberante (GA4GH), Angela Page (GA4GH), Juliane Schneider (Sage Bionetworks), Martin Kuba (ELIXIR-CZ)

Actions

Agenda

Notes & Links

Passports/AAI

Product Review Committee

• David Glazer - Engineering Director and Terra CTO, at Verily Life Sciences, USA
• Allison Heath - Director of Data Technology at Children's Hospital of Philadelphia, USA
• Dylan Spalding - Senior Coordinator, CSC - IT Center for Science, Finland

Minutes

[Recording/transcript to be reviewed]

2022-06-29

Chairs:

Attendees “Name (Affiliation)”: Martin Kuba (ELIXIR-CZ), Fabio Liberante (GA4GH), Tom Conner (Broad), Francis Jeanson (Datadex), Suresh Maslamoney (H3ABioNet), Yu Lin (?)

Actions

Agenda

Notes & Links

Passport/AAI

Summary of changes - https://ga4gh.github.io/data-security/1.2-draft-changes/changes-1_2 

Passport Specification on DURI Github https://ga4gh-duri.github.io/researcher_ids/ga4gh_passport_v1.html

Namespace and media types - https://github.com/ga4gh/TASC/issues/36

Potential PRC Third Member? Other suggestions welcome!

• Researcher Auth Service @ NIH

• Alistair Thompson
• Chris Siwy
• Larry Holt

• German Human Genome-Phenome Archive

• Christoph Zwerschke

• European Joint Programme on Rare Diseases

• Sergi Beltran

• Spherical Cow Group

• Scott Koranda

• Health Data Research UK

• Susheel Varma

• GEM Japan? H3Africa?

Minutes

2022-05-18

Chairs: Jaime Guidry Auvil (NCI/NIH)

Attendees “Name (Affiliation)”: Susan Fairley (GA4GH), Martin Kuba (ELIXIR-CZ), Kurt Rodarmer (NIH), Giselle Kerry (ELIXIR-Hub), Tom Conner (Broad), Fabio Liberante (GA4GH), Juliane Schneider (Sage Bionetworks) VIvian OTA WANG (ODSS/NIH), Mikael Linden (ELIXIR-FI)

Minutes:

• Ian Fore unable to present a demo today, but happy to in the future. See GA4GH Computable Cohort Hackathon 2022 - MASTER DOC

• Welcome to Fabio as the new DURI workstream manager!
• TN: Approval of Beacon v2 specification at Connect. Expands search vs v1. More granular searches. What this spec means for DUO/Passports XWS work? Future agenda point. Access data through a Beacon using a Passport. What is the DURI role in the Starter Kit? Beacon v2 must change this interaction somehow. @JA - Regulatory & Ethics changes? JA: @SF? REWS have been working on codable consent in the future. Machine-readable, but also DAC-readable. These were passed at the last meeting
• SF: Beacon v2 was passed at Connect as was “Consent clauses for large-scale initiatives”. Leads to a one-step resource for national initiatives. 14 countries represented - H3Africa, Malaria genome, Genomics England etc. Part of broader aims. Not exhaustive, but serves as a starting point to match language of GA4GH global standards. Many people involved.
• TN: REWS document on clauses links with DURI work on MRCG & DUO codes. We should be thinking about how these can be integrated?
•  JL: Similar starting point - MRCG sounds similar to consent clauses.
• TN: MRCG v1
• JL: No v2 of DUO. There are terms in DUO not in Consent Clauses. Changed language of the meaning but not the definition.
• JL: Has been used a template, but designed not to be vulnerable to breaking changes
• VOW: To add US perspective. Informed consent language is locally driven - institution drives the language. At NIH they have templated language that they are required to use, driven by lawyers. There are contextual constraints. If not adopted widely, could be a legal issue, not demand.
• JL: Use cases - IRB conference source. There is a demand from institutions to standardize at a higher level, but not sure how. There is some adoption already
• TN: If we have some MRCG implementations that exist, we could link GA4GH tools to this and automate it.
• JGA: Has Australian Genomics picked this up yet?
• JL: A year or two from MRCG in use now ends up as “data” that can be accessed.
• VOW: No consent forms, there is a process in between that it may not directly connect with the data.
• JL: If genomic process administration receives MRCG in submission, it makes it easier .
• VOW: We never receive the actual Informed Consent, they receive a certification/verification that something was in the original consent. GPA filters things.
• JL: Perhaps we ask on the investigator side?
• VOW: +1

• MK: Passports update. Going through PP v1.2 - TC has merged branches
• TC: Getting close - adding diagrams. Finished up soon.
• Approval process - see recording!
• JGA: What was the difference from the process for version 1?
• TN: How many things does v1.2 breaks compared to existing implementations? My understanding is that it isn’t breaking that much.
• MK: Access token visa we would like to remove, but we have avoided doing so to minimise breaking.
• TC: +1
• TN: We need a process description document.
• JGA: Yes, thank you. I was thinking of differences in terms of documentation and if we can just use any that are part of the initial process for consistency? Otherwise, I'm hearing that we need to formulate our own process for subsequent versions and create a SOP???
• SF: +1. Make changes as clear and simple as possible.
• JGA: Perfect, that's was my second question was what would a "threshold" of review entail (maybe use other WS examples)
• TC: Github diff view can help, but not as clear with Markdown.
• SF:

• Equality Discrimination Inclusion EDI working group update from secretariat
• SF: How do we make meetings less antisocial for people in different timezones? This moved over to the EDI group. Working on Best Practices for all WS. An expectation for WS to work towards this. Some WS have noticed issues already. Some approaches work better than others. Mechanism to support ideas. One strand is that we need to broaden out the participant base. We need uptake and they need to work in different parts of the world. One of the reasons for the EDI group to be set up.
• TN: What is the responsibility of the secretariat and what is the WS?
• SF: Stephanie can produce graphics, but needs the ideas. Starter Kits could help along with test suites. At least some input is needed from the expert contributors. Need a feedback loop from standards and implementations. To listen to why it doesn’t work for some, how do we develop the standards? Documentation, Implementation milestones. Staff team can help, but not specialist knowledge.
• TN: Voluntary - discussion forum and expert knowledge. Support for standards uptake is out of scope for unless a WS contributors employer agrees. How do we support/resource uptake? What happens next? GA4GH WS focus on creating specifications.
• SF: Like a publication. This documentation/implementation is ancillary - needs to be part of the specification release itself. A person may be permitted by their manager to work on a local implementation but not stds dev work - what people can work on depends on their circumstances. Test suites add to the definition of the specification
• TN: If we recruit new members to DURI WS, what do we expect from them? Encourage local implementations, but if they become the support persons for their institute then they could be challenged.
• SF: If it possible to do advocacy as part of their natural role, great. Secretariat can be more proactive but need WS to prepare materials to simplify implementation. Like Driver Project Champions.
• TN: Should be inviting people to DURI discussion?
• TN: Should we pause the 6-weekly Passports meeting?
• JGA: Thank you all so much for this important check in. I believe that our actions include making sure we have a clear review process that is well documented for minor spec modifications/releases and then also thinking about how we want to be more inclusive as we move forward for DURI. Are there others?

2022-05-03

Chairs:

Tommi Nyrönen, Jaime Guidry-Auvil, Sarion Bowers, Melanie Courtot

Attendees “Name (Affiliation)”:

Mikael Linden (ELIXIR-FI) , Fabio Liberante (GA4GH)

Minutes:

TN: Does Work Stream need to approve v1.2 updated spec? Which documents are needed to approve an updated spec?

SB: Do we need to document the update, or full approval?

Agenda for tomorrow?

Martin feedback?

2022-04-06

Chairs: Angela Page (GA4GH)

Attendees “Name (Affiliation)”: Vivian OTA WANG (ODSS-OD/NIH)

Tommi Nyrönen (ELIXIR/CSC),Juliane Schneider (Sage Bionetworks), Kurt Rodarmer (NIH), Mikael Linden (ELIXIR-FI) , Martin Kuba (ELIXIR-CZ), Tom Conner (Broad)

Apologies:

Minutes

2.0 Connect Planning

• Expecting release of passport spec before plenary, have reached an equilibrium in terms of development, now need to focus on uptake and feedback
• Hybrid Connect meeting april 20-22, three sessions with DURI representation:

• ELIXIR gap analysis,
• Kurt virtually,
• Vivian virtually
• Simon,
• Geoff Coles, Genomics England virtually
• Francis virtually computable cohort, cloud API
• Tommi virtually
• Suresh, virtually

• DURI attendance at FASP sessions:

• Thursday 12:30 PM - 2:00 PM (EST): FASP Use Case Session

• Tom Conner
• Tommi
• Geoff Coles
• Jaime

• Friday 10:00 AM - 11:30 AM (EST): FASP Collaboration on Passports, DRS, and Discovery

• Francis Jeanson can speak to it when people have questions, but hasn’t done it personally so can’t respond to in depth technical questions

• Point people to Martin Kuba and Ian Fore for those questions?

• Tom Conner
• Geoff Coles
• Jaime

• Are Passport and DUO technical capabilities acknowledged appropriately in FASP? Is it well represented in the meetings?

• NIH is quite active in FASP
• Prime Passports & DUO demonstration stakeholders

• ELIXIR/1+MG https://www.youtube.com/watch?v=6MtIJA4xXdU 
• NIH - manage security around release of passports tech in RAS, many integrators don’t have access to final signed versions of tokens yet

• NCBI (Ian Fore) has been demonstrating overall integration, co-lead on FASP

• ELIXIR compute platform is aligned and is active but maybe not yet completely. ELIXIR-DE

• If you go to meetings across Connect, please come prepared to report back at next DURI main meeting
• We shouldn’t make changes to standards too frequently, makes easier for implementers if they are most stable

• Eg., resolving issues tracked down for passports 1.2

• Kurt would like to present token work in terms of prototyping

3.0 Passport Spec 1.2 Status

• DSWS AAI OIDC profile 1.2 spec (eg., passport spec)
• Goals of 1.2 rev: describes obtaining ppts and visas from userinfo, oauth from openIDC
• Intends to ease implementation by adding ability to do token exchange, go to token endpoint and say “userinfo” separates id’able info that’s normally in /userinfo ppt and visa tokens - will be removed (?) from 1.2
• DURI ppt spec still to be referenced ,describes ppts and visas whereas oidc concerns “plumbing” - obtaining tokens, passing around and using them
• Intention is to not make breaking changes so those using /userinfo won’t be invalid with 1.2, encouraging newer token exchange approach
• More ambitious changes (e.g., work order token) but won’t be in 1.2, possibly 2.0 (not numbered per se)
• Mechanics of spec and draft

• Branch and pull request open in DSWS - 1.2 draft-main and asstd pull request
• Several specific features in separate pull requests will all converge into 1.2-draft-main, which will ultimately be merged with main branch, official release

• Current state of draft-main branch, available on internet at {{add url}}
• Looking to get more people using passport or close-to-passprot implementations to participate and validate edits to the spec
• Would like to be close to ready before connect, if not completed
• Have decent participation on Thursday meetings, working on several important details, no huge issues remain at this point
• DURI spec will continue for near future, for 1.2 there may need to be some edits to the spec but we don’t expect radical changes

Discussion / Questions

• Francis: when you say DURI spec, how does that differe from passports spec?

• Tom: DURI is more about user identity and passports is the content of the passports, claims and visas inside the passports
• Kurt: AAI is about shape of token and token tech, DURI is about content and claims, when we say “passport” we mean both at the same time
• https://docs.google.com/spreadsheets/d/11pPTKVW3j3_WHigWw4UOvlkQbPkM_z-ICgksE5L1vEY/edit#gid=1401368198 

• Tommi: Is a new naming needed?

• Repo: https://github.com/ga4gh-duri/ga4gh-duri.github.io/tree/master/researcher_ids

• Contains passports markdown file and visas markdown file

• Important to keep language consistent

• Francis: who has implemented this so far?

• 1.0 and 1.1 implementations Gen3, DNAstack, Ontario Bioinstitute
• 1.2: Ontario Bioinstitute interested in exploring this as well

• ELIXIR: 1.0 is supported now. When 1.2 spec is finalised we will  implement, shouldn’t be a “big deal” diff is just implementation of token exchange so should not be difficult, media type for token etc must be specified
• NIH RAS: don’t have anything to start with until spec is firm, we’ll prototype it soon as it becomes available for NIH it will have to then go through committee process internally for evaluation and to see how it’s scheduled

• First step is to prototype, describe, and present

• Francis: when folks with registered access, an entity that recognized them as bona fide researcher can use those creds to access more than one database, is that happening within NIH ecosystem already? Around the corner across multiple jurisdictions
• Is anyone working with Gen3 platform with this?

• Gen3 is implementing NIH-compatible token standard
• Follow up with those folks to see where there’s potential opportunities on collaboration and how they implemented

• Plan to implement passports: Australian Genomics, CanDIG, All of Us Research Program, Genomics England, Broad Institute, EJP RD, ELIXIR - EGA, DNAstack, ELIXIR - Beacon, ELIXIR - Cloud & AAI, Seven Bridges, Verily

• Connect with these groups at Connect [or set up an implementers call after the meeting)

• Prepare meetings in way to support implmenters
• From DURI standpoint, to have them together makes sense when the standards are being implemented together, but by and large they are separated out a bit, tend to have same folks on ppt and duo meetings

• How can we structure it to do differently and possibly in conjunction with other implemnters
• FASP is the probably the right place for this

• DUO / Passports is only a partial solution, need to consider in context of the whole suite of standards (or a “subsuite”)

• NEed to  ensure TASC  and FASP take into account what DUO and Passports can and cannot do

• Focus on desired functionality, could slightly differ

• in talking about FASP exercise, eg. Ian’s anecdotes at NIH about what’s of focus for a particular system trying to make data available vs. coming at it from standpoint of data access process
• You’d think they’d line up better than they sometimes do, quirks that allow for potential for interpretation that would lead to different pathway to implement, depending which one you’re getting info from
• Interesting to have those conversations, not just how tech standard works, but all ways it could/coudln’t be applied, does it meet a particular process need down the line
• If you have implemntation at one point, need an overall process to accomplish something, bu tin your system have to do diff implementation differently to meet what you did with first spec, may not have been intended

• How to line up streams start to end for each implementer
• Like the idea of getting toward that piece, figure out where they will be similar yet different to meet the different processes and regulations across the board
• Not as simple as plugging and playing each piece because you may do differently depending on what you choose

• Bottle neck - even if you support information that comes in at passport form, dac process has to be able to use that information, that’s part of the rEWS remit more than DURI, DACReS, recommended processes for DACs for them to work with standards
• Keep in mind we are not the service organization, to give support to DPs, they have the engineers and should be the ones to get to that point
•  

2022-02-23

Chairs: Alice Mann (GA4GH)

Attendees “Name (Affiliation)”: Jaime Guidry-Auvil (NIH/NCI), Tom Conner (Broad), Kurt Rodarmer (NIH), Francis Jeanson, Mikael Linden (ELIXIR-CSC), Vivian OTA WANG (ODSS-OD/NIH)

Apologies: Tommi Nyronen (CSC/ELIXIR), Suresh Maslamoney

Minutes

v1.2 update

https://github.com/ga4gh/data-security/pull/55

• Sequence diagram also here
• Merged back into master eventually
• These PRS, one PR pasted into chat and above here is a map of the different plans and what it looks like in terms of PRs in github
• We are looking for comment and participation
• Francis Jeason: should we comment in this draft #55
• TC: yes or also linked a token exchange branch and a sequence diagram branch, in github will work well but also good to send email to appropriate mailing list: aai@ga4gh.org 
• TC: it seems likely that there will be an update to the DURI repo needed as well, the passport within the DURI side, we don’t see a ton of changes there as v1.2 about token exchange and doesn’t change too much the content of passport or visa. We don’t have a PR for that yet.

DUO update

• First initiative is DUO validation with NIH datasets, made some good headway, supplement supporting that, master grant is in midst of renewal and ready to make good progress, results some time next quarter
• DaCRES DAC standard work collaborating with REWS - near final on survey that will go out to DAC members asking how they operate, go out sometime in March. Will share with DURI distribution list as well.
• Still in planning for some of the DUO/REWS collaborations for this year, we will input on ethical provenance group contributing thoughts around data access agreements and standardisation of that.
• Lastly continued thoughts on other REWS and DURI collabors: meeting with people from NIF in US government, looking to use DUO as part of their metadata management framework.
• MC: at the stage they are at maybe they are more interested in understanding ontologies and how they could plug those into their system, data access but not biomedical domains so that was foreign to them. Looking at standards and tools they could use so learning more about ontologies in general.

DURI workshops at April Connect (20th-22nd April)

• MC: DaCRES, session with REWS consolidating those DAC specific terms?
• JL: yes probably right, but maybe a little early for that group not sure they are even approved as a REWS initiative, i can check in
• Vivian OTA WANG: I think an early discussion would be useful, existing definitions they are based on are in existence. Part of it is early goal and encourages data to be less broad for data sharing. Early residuals of NIH dbGAP system.

2022-01-12

Chairs: Tommi Nyronen (CSC/ELIXIR), Jaime Guidry-Auvil (NIH/NCI)

Attendees “Name (Affiliation)”: Alice Mann (GA4GH), Sarion Bowers (WSI), Gregory Rushton (Broad), Joe Flores-Toro (NIH/NCI), Kurt Rodarmer (NIH), Vanessa Vogel-Farley,  Yu Lin, Mikael Linden (ELIXIR-FI), Jonathan Lawson, Juha Tornroos, Tom Conner (Broad), David Bernick (Broad), Subhashini, Vivian OTA wang, Brandon

Apologies:

Minutes

Tommi

• Last year reached a big milestone with the papers
• Plan to update the roadmap this year
• We need more feedback from the users, good and bad sides of the Passports and DUO
• Juha Tornroos here from Cloud WS to give us an update on the Beacon implementation
• And plan to talk about SSI, a way to store the information carried by Passports (Mikael), brief introduction today
• Action between the cloud and DURI workstream - hackathon coming up
• Jonathan to give an update on DUO

Juha Törnroos- Beacon case in Finland and how DURI standards used in that

• Working in GA4GH Discovery Work Stream and moving to Cloud work stream as new position in ELIXIR, new lead of ELIXIR compute platform
• Implemented Passport and supporting 3 access tiers to query these Beacons on public, and two different access tiers that require more (registered and controlled access)
• Frequencies of variants visible when you log in to ELIXIR AAI
• ELIXIR AAI is able to tell if the user is identified as a researcher or not
• Bringing in more data from FINNGEN, 356k samples at the moment and we are working on supporting more complex queries and phenotype data available. Next step is users can apply access to this data and compute on it in different computing environments
• Link to try: https://thl.fi/en/web/thl-biobank/-/thl-biobank-s-new-beacon-discovery-service-includes-20-million-genomic-variants?redirect=%2Fen%2Fweb%2Fthl-biobank 
• Tommi: THL data access committee in this case, they are terms of use for the data on the samples, have been mapped to DUO codes.
• Juha: at the moment we support open and registered access levels, coming next is we expect that these users who discover data in ELIXIR beacon network they want to apply controlled access data and DUO codes will support that use case. This whole thing provides quite nice use case for the different things that have been developed, it utilises beacon specification and standard and DURI work streams.

Tommi

• Great use case for DURI work stream we could include in the upcoming Connect workshop.
• If anyone else knows of use cases and examples of how these standards are being used, please let me know.

Mikael - SSI

• Self sovereign identity proof of concept (PoC)
• Will go into this in the next passports call here a short introduction
• In the current architecture there could be several passports brokers needed.
• The PoC studied the need for having a broker at all? Imposes every limitations to the interactions, for instance if you want to project visas from several brokers you need to authenticate against each broker in sequence
• SSI has no brokers or identity providers at all. The user has a wallet, an app maybe in their smart phone, the researcher applies for access rights from the DAC as usual, the DAC issues and writes the permission in the wallet. If researcher wants several datasets access, ask several DACs to write controlled access visa to their wallet. Then when they want to make sure of data access rights in cloud and to access the files from their analysis, they use their wallets to expose the permissions from their wallet to the computing environment.
• Verification of the visas (In SSI dubbed as verifiable credentials, VC) are displayed in the computing environment. There is no broker in the game at all. Instead it is the user themselves that release the visas directly from their wallet
• Slides are linked in agenda, see links for more information
• Deliverable D2.2 in the slides is a detailed description for how the ELIXIR AAI works
• Screencast video linked in the above slides
• Also links to try it at home – need to download a wallet app to your smartphone.
• Slides: SSI introduction (slides)
• Invite next passports subworkstream call 9 Feb if you want to see a demo and discuss more
• Jonathan lawson: on the wallet, how is that going to handle expiring permissions, does the loss of the broker means someone could use DA rights that have expired? Would they be able to demonstrate they still have access that they don't
• ML: in SSI “visas” are verifiable credentials with JWT syntax, they have the same JWT structure (including expiry fields) as the visas we have currently in the passport spec. SSI Implements also mechanisms to revoke credentials even before the expiration time stamp.
• TN: how is the wallet app better than the passport brokers that would be run by trusted infrastructures?
• ML: separates the authentication of the researcher and delivery of the visas from the visa issuer to the computing environment. You don't need to authenticate against a particular broker which originally delivered visas. If you need visas from several brokers from your analysis you don’t need to authenticate against several brokers in a sequence.
• TN: does the mechanism guarantee the security is not worse than the trusted broker mechanism?
• ML: security already difficult but VCs and SSI are subject of intensive research and it is something that is an emerging technology that is a topic of interest
• KR: can you describe how the permissions are shared and delegated. How does it accommodate CL tools and batch processing?
• ML: I need to give the demo to answer the question. So scheduled for 9th February.

FASP hackathon

• Looking for participants in the context of ELIXIR who have interest in passport and DRS integration session.
• Contact Alice Mann alice.mann@ga4gh.org or Jeremy Adams jeremy.adams@ga4gh.org if you are interested in joining the FASP hackathon - there is a DRS-Passports proposal for the hackathon.
• NIH is active here
• Juha: there are ongoing discussions in how ELIXIR can participate here

DUO news - Jonathan Lawson

• Ready to participate and support the Roadmap and the development of it
• Using DUO for physical human samples
• Work to be done on a number of the terms that we currently have, not so much descriptors or researchers but common terms on data access agreements
• Two things i see rising people who are asking us about using DUO for samples and questions around DAs and that we in DUO already have some terms that work for that
• And additionally grow our efforts in documentation and offering guidance to implementers as well.
• Don’t have a number for users yet, but some US biobanks using it.
• Vivian: DUO based on dbGAP model so can be more difficult to tease apart what is uniquely DUO.
• JL: there may be biobanks that are using NIH data use limitations as descriptors of data use,
• V: yes established a while ago, dbGAP created for the community, first time centralized controlled access data in a much more uniform way.
• JL: if there are groups you are aware of that have done that, we would like to talk to them, hoping to reconcile DUO and NIH data use conditions
• V: should be a 1:1 correlation based on history of data use development.
• JL: Cross work stream initiative with REWS, DaCRES, data access committee review standards, kick off a survey for that we have a research associate supporting us. Hoping to start designing that survey tool now and plan on ruling it out in Q2 or Q3 of this year. Follow up with that in general and reaching out to folks on this call on that sub project.
• YL: mapping DUO to dbGAP, we can also map to the others consent code NCBI platforms, EMBO and Kids first (CRDC) and BDC data catalyst. Consent codes on dbGAP not mapped to DUO yet, we are thinking of that but if you guys do it with dbGAP why not do it with whole NCBI and other platforms. dbGAP part of NCBI
• Jaime: in this case using dbGAP as whole controlled access process, codes same regardless of repository they are in, but for repositories there are data in some of those that are not registered in dbGAP. Moonshot biobank does employ a process that moves straight from the biobank itself into the registered dbGAP controlled access process. There are genomic sequences being created on data being banked. See how they are using it in their biobank system and we can get you in touch with people working on the actual biobank system
• JL: absolutely
• V: useful exercise but just to attend to confounding variable, most of these are based on controlled access process in dbGAP. What we do for DUO based on dbGAP model
• JL: shouldn't have a lot of surprises here if used for samples then?
• V: yes
• JL: more of a reference implementation in that case.

Matrix/Roadmap

• DURI 2022 roadmap proposals and achievements from 2020 roadmap summarised: https://docs.google.com/document/d/1V6EtPAJ2KVOcbZ4wMHbnME2TLiLnJ7GSpeRcExTwZZs/edit 
• Identify the gaps that we have in the standards and the process we have
• Implementation matrix where we identify the real life use cases and needs and things that GA4GH standards as a whole deliver and adding resolution to that from the DURI angle. What passports and DUO are addressing and what they are not.
• Would like to do more cross work stream work
• Consent clause guidance as well - continue this work
• We would need to lead this type of work from the Work Stream side of things
• How we quantify the number of possibilities for implementation, maybe we can start to put that into some sort of form. Something like an excel spreadsheet. Possible goal for having something by the next Connect meeting. General pathways that DPs are going down.

2021-12-01

Chairs: Sarion Bowers (WSI), Jaime Guidry-Auvil (NIH/NCI)

Attendees “Name (Affiliation)”: Alice Mann (GA4GH), Martin Kuba (ELIXIR-CZ), Mikael Linden (ELIXIR-FI), Kylie Davies, Jonathan Lawson, Gregory Rushton, Joe Flores-Toro (NIH/NCI)

Apologies: Tommi Nyronen

Minutes

• Sarion: we are interested on hearing how people want to use the papers, publicise them and use them to support more implementations. They are a great reference
• Alice: survey sent to
• Jaime: when the disease definition changes, new markers in the disease itself and this has shifted, accepted clinically, however we are stuck with old traditional consents as they are historial
• Jonathan: yes melanie can be more precise but rely on mondo ontology we use in DUO for diseases but complicated as whenever a consent includes terms like diabetes and related diseases for example, as science progresses we understand new associations and relatedness with diseases. Always hard to track in DUO, is that ever a wise term? Maybe you should have made it disease-specific. Looking for people to help advise us on that scenario too

Roadmap planning

• Introducing Kylie Davies to the DURI team
• Jaime: please add your requirements as a new member to documents
• We could hold a collaborative roadmap meeting like REWS are doing in the new year to brainstorm
• Everyone needs a rest after papers so let’s mull over ideas for the future of DURI and come back in January to focus on this, DURI has achieved an amazing feat in the last roadmap and work is still actively going on on the new passports v1.2

Cross work stream efforts

• Jaime: focus on cross work stream, how do the pieces fit together more than separately
• As we go down each path with each implementer, what are the touch points? No two implementers are implementing the same way across work streams, pairings or groupings of implementers that are working with a specific standard a certain way as we move down that pathway
• Help create that fluidity across the workstreams and standards
• Let’s see what that evolution is, shifts over time for DP? Converging shifts?
• In the new year we will look to focusing on these efforts

2021-10-20

Chairs: Sarion Bowers, Jaime Guidry-Auvil, Alice Mann

Attendees “Name (Affiliation)”: Martin Kuba (ELIXIR-CZ), Vivian OTA WANG (ODSS-NIH), Kurt Rodarmer (NIH), Joe Flores-Toro (ODS-NCI), Tom Conner (Broad), David Bernick (Broad), Mikael Linden, Jonathan Lawson, Pinar Alper (ELIXIR LU), Kathy Reinold, Gregory Rushton, Dylan Spalding, Michele Mattioni, Vanessa Vogel, Surya Saha, Suresh Maslamoney (H3ABioNet)

Apologies: Tommi Nyronen

Passports

• We think we are done!! DUO and Passports papers submitted to Cell Genomics and accepted, now in production stage
• Angela: accepted and copy editing. Anyone who wants to do a Q&A, anyone interested in that let Angela Page know. Front of the book sort of Q&A. not sure if online or in the print version.

• They are looking for short news / commentaries to allow voices from others in GA4GH to share their perspectives, aiming for a good representation of Work Streams, topics,  perspectives, and geography. Some ideas for discussion points (although they are also open to other suggestions)  - behind the scenes: how are standards / frameworks made? - how collaborations work (internal WGs or external) - technical or practical challenges in developing standards - same for implementation - motivations for involvement with GA4GH

• Written Q&A
• More details on the additional CG ask I mentioned earlier: they are looking for short news / commentaries to allow voices from others in GA4GH to share their perspectives, aiming for a good representation of Work Streams, topics,  perspectives, and geography. Some ideas for discussion points (although they are also open to other suggestions)  - behind the scenes: how are standards / frameworks made? - how collaborations work (internal WGs or external) - technical or practical challenges in developing standards - same for implementation - motivations for involvement with GA4GH

New Passports leads

• Craig Voisin has stepped down after an amazing stint, thank you so much Craig!
• Triumervant going forward, joining Sarion we have Martin Kuba and David Bernick helping to take on different aspects of the technical stream for the Passports. Hopefully help to bring richness to the ever evolving and expanding standard. Welcome to Martin and David.
• Martin: represent ELIXIR, implementing the ELIXIR AAI infrastructures, hopefully will bring some insight into GA4GH.
• David has been a long fixture at GA4GH, AAI, Passports etc.

Plenary and Connect Summary

Plenary

• We had great talks from DUO and Tommi spoke on the 1million Genomes Projects (EU)

Connect Passports Workshop

• Minutes and Agenda from the workshop are here.
• Recordings from all workshops are available to watch here.

Alice has provided a summary of the workshop here:

• We had great attendance with just over 50 people dialing into the workshop.
• Driver Projects/Other interest implementers that attended:

1. EGA
2. Genomics England
3. H3ABioNet
4. GEMJapan
5. Seven Bridges
6. ELIXIR
7. Australian Access Federation

• The team delivered-

1. a brief introduction to the concept of a Passport
2. explained the motivating factors from moving to v1.2 from v1.0 and what v1.1 was.
3. Tommi spoke on the motivation for Driver Projects in Implementing Passports
4. Mikael introduced our use case document and explained various use cases. Please submit your use case here.

The team provided the following background:

• Passport and visa mechanism design is represented for digital tokens (JWT) and contain claims or data statements/assertions backed up and validated by the authority of their signatures.
• In v1.0 timeframe, tokens obtained from /userinfo and delivered as a collection to tokens.
• Initial tests with v1.0 spec identified a cause of some level of confusion with different organisations going in different directions and no common direction. It didn’t define exactly what a passport was.
• Thus v1.1 came from NIH (NIH RAS), as is separate to a GA4GH adopted version. Essentially v1.1 spec takes all visas from v1.0 and encapsulates them inside a single token, pretty much identical to v1.0 otherwise.
• There were also issues where the size of a Passport caused some errors, if you have a lot of visas this can become large.
• With Passports v1.2 we limit the token size to 4k and allow it to be passed as a header. It is semantically different from the OAuth access token. Key goal is for loosely coupled federations to talk to each other and remove ambiguity in the spec.

Interesting points from the discussion 

• Passports are not about authorising the user identity but about authorising systems. You need to add extra controls to ensure the user is who they say they are behind the passport.
• Currently mostly used within the scope of a single system- what about the situation where there are multiple brokers across boundaries for example?
• So far systems existing have an element of trust, we all trust the RAS passport for example.
• We need to look into a system that trust multiple brokers and essentially we all agreed that Institutes need to agree trust and policy between them to achieve this. That is a possible next step here, explore with Institutes the requirements for trust and policy and make sure there is an alignment on policy and trust.

Next steps:

• V1.2 written into a spec
• Explore a discussion between Institute policy representatives
• After v1.2 defined into a spec then explore other technical issues (downscoping, audience etc)

DaCRES Updates

• REWS workstream approved the DaCRES standard moving forward. Determined next week at Steering Committee.
• DaCRES policy - standard, guidance for DACS
• Funding for user interviews about that and look at further thoughts on what would be next.
• DUO: going forward with a number of initiatives soon, look out for the next Data Use Agenda. Updates to definitions of the DUO terms. Feedback from Craig Voisin on how we can make DUO definitions computer UI friendly.
• Questions have come up around use of imaging data (not just genomic) and human samples. Aware of a few real world scenarios in which Institutions and Biobanks that already apply GA4GH DUO for sample and image management.
• Looking to a DUO implementers paper but probably the new year before we dial into that.

Future of DURI

• Where do we want to get to on the Roadmap.
• Cross work stream efforts
• What we want to do next on our roadmap, specifically in DURI and Passport and the blending of those two things for data access.
• Opening it up to get the ball rolling.
• Community feedback to Data Access and sharing.
• Improvements in data use agreements and data access agreements.
• REWS work stream has researched this a bit.
• Data access can be challenging
• There may be potential for standardisation, uniformity at least.
• When are Passports and DUO be together? When will we see a DUO term in a passport? DACs approving researcher for data use profile not just specific datasets. Visa has a DUO term and access datasets with that corresponding DUO profile. Will require DACs to endorse that with policy.
• Vanessa: agree, use cases coming up. That would be the pie in the sky idea. Automation of that DAC using Passport and DUO. agree with that.
• Vivian: data use agreements and certifications. Great task to look towards. Separate from data access request, conditions put forth by the Institute for data uses. Sometimes get conflated.
• Jaime: i admit I don’t see why you couldn’t use DUO terms by project on a Passport. If you had a project code to go along with it.
• David: I don’t see why it’s not possible, passports are there to have strings. Tell you to have whatever you need. Denial of that. Just a matter of doing that. Each of the brokers has to decide that. We should make it a bit recommendation that they should the DUO information. There are some size concerns that may happen but we can address those as we approach them
• Vivian: having on our radar people implementing, we need visibility they are doing it. Passports - not on use authentication, more on project based. May be useful to think that all the way through. dbGAP process here is very project based.
• Kathy: what do you mean by project based? Only people working on that project are allowed?
• Vivian: you can only have access to datasets that you have requested for a project. Only people associated as collaborators will have access to that particular set. Transparency expectations. Data use reporting back to research participants so they know how their data is being used.
• Kathy: this sounds like a more detailed use case that we should walk through.
• Sarion: we have implemented DUO, but it has no bearing how data is processed in the Institute, only has benefits for the users. Users can see DUO, tells them there is a usage restriction. Move to a place where we can tag DUO as they come in and follows it through. Ultimately I would like that all datasets under a code in a pool and sign data access agreement and give you access to all datasets under that code. But at the moment you have to reapply if you want another dataset.
• Some datasets where you are required to report back to the participants. Born in Bradford for example, sensitivities around the data and requires to report back how many datasets were downloaded. So this dataset would never be in a pool with other datasets because of sensitivities around the data. More the less sensitive datasets. Overwhelming datasets have one standard agreement but you have to sign that everytime you want to get access. And a few consortia where you have their own. Some have usage restrictions on them so useful to know before they apply.
• Jaime: Because single investigators have many different types of projects with a range of allowable use
• Kathy: so, context of the request is also a consideration

Agenda: 2021-09-08

Chairs: Tommi Nyronen, Jaime Guidry-Auvil, Sarion Bowers, Alice Mann

Attendees “Name (Affiliation)”: Kurt Rodarmer (NIH) Vivian OTA WANG (ODSS-NH), Emily Boja (NCI-ODS), Michele Mattioni        (Seven Bridges), Angela Page (GA4GH), Mikael Linden (ELIXIR-FI), Mamana Mbyiavanga (H3Africa), Karen Plevock Haase, Joseph Flores-Toro, Asiyah Yu Lin (NIH), Vivian Ota Wang (NIH), Pinar Alper (ELIXIR Luxembourg), Soichi Ogishima (ToMMo, Tohoku University), Francis Jeanson (Datadex)

Apologies: Melanie Courtot, Jonathan Lawson, Suresh Maslamoney

Minutes 

• Two standards in stable state for DURI, interacting with REWS linking to regulatory framework and supporting that with technology standards
• Two papers in process
• Many actions DURI actions can do and people involved can engage in various ways in interest areas
• We are also looking what should we focus our voluntary forces next
• Next year a lot of energy writing these two papers, this has taken a lot of effort
• Heading towards the next virtual plenary and then october connect meeting we are hoping we can reach out with these standards for adoption by Driver Projects
• GA4GH have official DP with various technical experiences- Tommi will talk about European (EU 1+Million genomes) angle with Rare Disease DP this in the session

Passports Update (Sarion)

• Extensive edits back from Orli
• Some of the edits are around accessible language
• More difficult edits from methods- Cell is a biological journal where methods and being able to reproduce the results is important but Passports is a computer science technical standard.
• We may follow the DUO template for how to address the methods updates.
• Hopefully done in the next few weeks
• An awful lot of work to this point, we may need to think in future for how we approach papers
• The editor wants to make a lot of improvements after the reviewers gave the green light for publication
• Is the cell genomics strategy different?
• Angela: willing to bring this up the chain of command, not sure for what value this is a lot of work. Will this add anything as nobody is going to use this to reproduce the standard, they will go to the standard. Will loop in Heidi and some others.
• Jaime: started on both papers last November and written by January, a lot of what is going on since then is an extensive amount of time are technical details found elsewhere.
• Is there a collective that can be done for GA4GH processes? Otherwise will have a lot of difficulty with the different standards
• Sarion: further guidance notes for the authors each round we get a new lot of issues.
• Angela: we have had the same experience with the marker paper. What is driving this? This is the first issue and that still is the plan, so may just be making them perfect for their first issue.
• Especially for volunteers.

Kurt

• Passports v1.2
• A number of goals for v1.2 and we did not come close to as we got derailed on details I thought had been settled since post v1.0
• Some features that we need to hammer home. Downscoping passports is a significant one, a lot of work put into that and again got derailed by additional discussions, i think it’s time to refocus it to just get it nailed down
• We have the smaller more compact version, strawman description of, have to be put together for v1.2. I don’t know where it’s been left.

October Connect workshop proposed agenda (work in progress so far)

https://docs.google.com/document/d/1o8o9jBpAok9MJYx53KjsYry7dJb2p4SVxTTa6hzGnXI/edit#heading=h.somgoowwkvaj 

• We need someone technically minded to talk to the technical process on development up to this point.

Tommi

• We don’t want to make it too complex to reduce uptake (in general terms)

Kurt

• I don’t think we proposed anything particularly complex
• People have disagreement on how to pursue
• One of the main items that it has to adhere to is security principles.
• We can’t push for people to adopt a standard that is not secure
• To do it in the simplest way as item number 2 makes perfect sense.

Francis

• Discovery group interested in passports and other working groups taking passports into consideration, especially in xWS efforts. DRS for example, to index data and passports to facilitate access to it. Very present in the community’s mind.
• Update diagrams or ecosystem or use cases using passports? This may help?

Alice

• We are producing an updated use case document as we go through the technical discussions. Plan to have that in time for the workshop and shared beforehand. And disseminate through other workstreams.

Jaime

• Policy as part of the technical meeting
• Can we put together part of the workshop or advance of it a list of questions that could be asked by a technical team of the governance team about their process that would be helpful
• Hard for me to follow some of the technical conversations, where are the pieces that are really important in our process that are compliant with the policy, is this translated by the technical piece.
• Pull out the right questions, do you have identifiers for a dataset, do you have identifiers for the signing official? What do they need encoded in a passport? What is critical for you to know for your use?
• Not sure taking a technical process to the governance folks will get your answers?
• Tommi: I agree this is the dialogue we want to have all the time in this workstream.
• What kind of data governance things that DURI enables that may not have been possible before the DURI standards

Michele

• Cloud work stream at the same time as the DURI workstream
• Need to tie better passport with DRS, will need an update for both standards
• Can we discuss this at connect? https://github.com/ga4gh/data-repository-service-schemas/issues/352
• Yes, I think this is part of a planned session at Plenary (DRS + Passports)

Agenda: 2021-06-16

Chairs: Tommi Nyronen, Jaime Guidry-Auvil, Craig Voisin, Sarion Bowers, Jonathan Lawson, Melanie Courtot

Attendees “Name (Affiliation)”: Soichi Ogishima (Tohoku Univ, GEM Japan), Michele Mattioni (Seven Bridges), Kurt Rodarmer (NIH), Susan Fairley (GA4GH), Alice Mann (GA4GH), Mikael Linden, Pinar Alper, Michele Mattioni, David Bernick, Yu Lin, Justina  Chung (GA4GH), Sarion Bowers (WSI), Rebecca Boyles (RTI International/ NIH BioData Catalyst), Jaime Guidry Auvil (NIH), Chisato Yamasaki (Osaka Univ., GEM Japan)

Apologies: Esther van Enckevort, Suresh Maslamoney, Jonathan Lawson

Minutes:

Papers

• Reformatting the papers at request of editor
• Great feedback
• Kathy Reginald assisting for Passports, Melanie organising DUO side of things
• CV: looking at how trust is established in Passports and different implementers and what are they hoping to achieve. Looking to expand this story on the passports side.
• TN: Cell Genomics is a scientific journal, thought that this would not be technical as technical side in github. Review came back to revise as a technical report but change in structure is not that big. Committed to open review and keep everyone online for resubmission of the paper
• Even if technical paper we will still target the scientific community with the paper, explaining the implementers intention with the use of these standards.
• CV: Passports, add technical detail but not bogging down the main detail in the paper, Mikael has added technical notes and appendix that leads to more of the technical aspects as how things are coded. Still maintaining the flow of the main body to capture the wider audience.
• JGV: have we spoken to Jonathan or Melanie about this approach.
• DUO authors feedback: only four reviewer requests plus technical formatting. Request for additional content was not as broad as it was for the DUO

Looking forward

• In a year’s time, how would DURI and the DURI products look like?
• Two standards are maturing, DUO more than Passports.
• Are these two standards enough? New or something more integrative?
• SF:
• CV: how to bring genotype and phenotype together, make compliant with other standards, is there interest in the community to get DUO to grant access to data with HL7, not only within the GA4GH roadmap. When do we cross over?
• KR: main struggle technical detail having passports work as main access to FHIR. making genotype and phenotype information available in that format and what that means. That will be based on passports. Is there an existing healthcare interoperability standard, how do we plug in the GA4GH standard.
• CV: access to the entire store?
• KR: the system consists of the issuing of the passport, the passport is the token that is used to access FHIR, FHIR calls the clearing house and the clearing house vets the token and is able to access the visa content.
• TN: what kind of requirements would this be on the data services in terms of hosting and sharing when the researcher has a passport? Do you not need a new interface on the data site?
• J: all of this happening on the back end? In our instance we have genomic and phenotypic data together. Does Craig mean taking EHR data and trying to combine with other sources that have the genomic data?
• CV: what level of FHIR integration is the community looking at?
• RB: BioData Catalyst is closely watching the bdGaP approach to see if it is something we can mimic.
• KR: The existing dbGAP model is already covered by our model of visas and permissions and dbGAP careful to separate sensitive information from information that could be made public. Combination of those two. Initial challenge of getting plumbing to work so the tokens are there, semantics of how tokens will be modified over time it’s getting the thing to work at all.
• AL: NCBI platform, different platforms have all those cases, they use the HL7 PR and R resource to try to model/grab a portion of the data so that you can search but not all the data. If the user needs to access those controlled data then need to use DRS, but DRS is one of the strategies to access one of the original datasets.
• KR:  GA4GH are introducing new protocols, FHIR is an existing and established protocol that don’t have much hope of influencing of steering in any way and there are some engineering challenges that it presents to make it that we have to bend to it. FHIR is a big and important project to accomplish here, so we will need to modify the passports protocols to fit within the old model.
• TN: authentication and authorization in FHIR part of security framework, with passports we could supply that to a FHIR compatible data resource. Trying to get a view of what this requires from dbGAP, that would be interesting to discuss.
• KR: not designing that part of it but am joining the work on dbGAP FHIR team around now, so a little early to answer what is being done. More involved in making use the GA4GH authorisation methods.
• RB: eagerly watching in this space, know we are going to do something with FHIR, don’t any have active development going on here
• CV: Is DUO needed as part of a FHIR consent encoding system: https://www.hl7.org/fhir/codesystem-consent-policy.html
• DB: AAI group, actively trying to make the passport a thing not just a concept. We think it will land as going to be a thing as a collection of embedded visas that are passed around. In the RAS team at NIH have already been involved in how they integrate that.
• RB: whilst that is going on we are looking at exactly the use case KR described and using it as part of FHIR
• AL: I think there is discussion about consent in the HL7 BR&R WG. I did suggest DUO to the group
• TN: DURI direction key point to observe, many healthcare FHIR being looked at, research side still merging. If we can form passports with FHIR compatible data resources. This is happening independently; we are just providing a way to express the authentication and authorization information. How does the DUP relate? Probably to the data request and discoverability. HL7 and FHIR compatibility to look at across workstreams that could create impact on the driver projects. Agree or disagree?
• RB: And from our perspective the growing interest in FHIR is being driven by COVID data.
• SF: looking at any interoperability things is good. One of the WS has a lot of interaction with FHIR is clinpheno, having a philosophical discussion and their interaction with FHIR. run on cloud or local compute and verify themselves so people being granted appropriate permissions to the data files. Their reading and writing from shares in the file system. This would be really useful.
• TN: this is aim of DURI, not focused on semantics like Clinpheno, we are looking more to identify researchers, its requirements from underlying infrastructure uptake, EGA and dbGAP but we are agnostic of the data semantics.
• SF: potential for role in accessing big data resources but also pipelines to data.
• Jaime: getting into discussion we wanted to have today, this idea of exactly who are we needing to work with now? DUO and passports a little different but we happen to be working with a standard at least with DUO don’t want a lot of changes here, stable to be implemented well. As would cause people to go back and change a lot of things. So now identifying all the different places where this standard could apply.
• AL: I think there is discussion about consent in the HL7 BR&R WG. I did suggest DUO to the group
• RB: And from our perspective the growing interest in FHIR is being driven by COVID data.
• SF: where are these areas of common concern and interest, please follow up with Susan if you want to explore this further.
• MM: Passports and DRS working together: https://github.com/ga4gh/data-repository-service-schemas/issues/351

MRCG

• TN: REWS discussion, ended up with MRCG, standard clauses that would map into DUO codes. Make consent more machine readable. Could this lead to a new direction?
• JGA: where do we want to head to the plenary, looking at points of crossover, working with regulatory arena. How to incorporate the DUO codes, machine readable consenting. Another area where we want to cross over. Question had come up as to what does this implementation look like? Input information up front to spit out universal consent document backed by GA4GH or versus more to stick within these clauses where you could have a section of consent to describe these. Are there groups that don’t have an idea of the type of consent they want to use?
• JL: DUO implementation retro or prospectively. Retrospectively the biggest challenge, is there a way to have experts on hand to receive consent forms and offer what they would believe is the appropriate translation for clauses in terms of DUO, rather than having every person come up to speed on DUO.
• TN: working on an implementation, plenary end of september is this something that we should be looking at. How do we take a step forward with this?
• JL: we have folks interested in doing this, anyone interested in how this would look and advising, we have the tech team. We could definitely have something by plenary.
• TN: anything similar from the passports side? What would be the DURI inputs for the plenary. Increasing collaboration with the regulatory and ethics experts.
• CV: Hopefully by plenary, how to get a bit further on with integrations.
• SF: need a conversation with people who have a handle on the development. FASP good example of coordinating work across WS

Summary of DURI looking forward

• Integration with HL7 and FHIR, get further implementations
• MRCG development and implementation

Plenary

• JGA: what do we want to get set up for Plenary? September is not far away. Get together a list of the crossover points.
• Plenary a good time to introduce some ideas and give some touch points and get very wide feedback
• Could we set up a series of joint meetings across some of these workstreams. Do we invite certain workstreams to DUO and Passports focused?
• Streamlining and efficiencies wherever possible
• FHIR clinpheno and the DURI both, seeing our different roles.
• Is there anyone else working with FHIR?

Agenda: 2021-05-05

Chairs: Tommi Nyronen, Jaime Guidry-Auvil, Craig Voisin

Attendees “Name (Affiliation)”: Kurt Rodarmer, Vivian Ota Wang, Francis Jeanson, Mikael Linden, Pinar Alper, Angela Page, Joe Flores-Toro, Michele Mattioni, Emily Boja, Adrian Thorogood, Justina Chung, Michele Mattioni (Seven Bridges), Sylvia Gayle, Suresh Maslamoney (H3ABioNet), Soichi Ogishima (Tohoku Univ, GEM Japan), Freddie, John, Nancy Mah, Yu Lin, Subhashini

Minutes:

• Passport paper submitted at the beginning of March; still under review. Angela and Melanie have been following up with Orli Bahcall for status updates.

• The slow down is finding reviewers that are not GA4GH conflicted.
• Overall positive feedback
• Original timeline was for the first Cell Genomics paper in April (not yet published)
• Would be good to have this by ELIXIR all-hands meeting in June.

• Angela to raise this with Orli

• Steering Committee updates

• Data Connect API, formerly Search API, passed the Steering Committee vote.
• How does the Data Connect API leverage data access standards that DURI has been working on. Need to have interoperability between Passport and Data Connect.

• Feedback I received from SC that they agreed, Data Connect API listed Passport testing as next step; DURI supported the approval of Data Connect

• DUO Workshop

• Anyone interested in joining can contact Lindsay Smith (lindsay.smith@ga4gh.org)
• Learn more about DUO and DUO implementations

• Integrating DURI with FASP

• Initiative by Ewan for on-ramp of uptake of GA4GH standards and by having labs using them can facilitate broader adoption.
• Federated Analysis Systems Project (FASP) highly related looking how standards developed can work for researchers and integrated to work together to make sense.
• Focused at the moment on how Passport can be integrated into DRS; right now DRS doesn’t go beyond OAuth 2 token. Trying to refine the standard to know how to redirect to a Passport broker in order to get information, and on the Passport broker side we want enhancement so you don’t have to hand over the entire passport.
• Figure out how to enhance the spec to integrate everything together.
• At the March Connect meeting, DURI concluded one way we can participate as DURI is if things came out of FASP in 3 categories we can look at those things.

• What are institution outcomes and input that is needed? Eg. what is needed for DAC to work
• What is the technology?
• User experience

• Data Connect and Passport integration, how do we involve ourselves with that.
• TN - what is in DURI scope in FASP/On-Ramp context? Do we try to see the big picture, or focus on data access/use authorisation

• The On-Ramp/Starter kit is a particular implementation of standards that may not use every use case; it’s an easy way for a lab to stand up GA4GH standards as part of getting closer to integrating. Not a one-size fits all.
• FASP is a layer above that looking at what are the interfaces; how do the actual products integrate together. On-Ramp is one implementation of that (on a particular site/organisation. Organisations could make alternative solutions how to provide required interfaces to FASP.
• DURI role: use of Passport and eventually DUO in the interfaces of the services (using GA4GH standard implementation).
• User experience
• DUO : GS - geographic restriction  
• European supercomputer & ELIXIR data on Genomeweb https://www.genomeweb.com/informatics/new-european-supercomputers-support-data-sharing-efforts-drive-dx-innovation?_ga=2.86169884.541510902.1620134122-370060752.1620134122&adobe_mc=MCMID%3D74347787596239632013073126242640410736%7CMCORGID%3D138FFF2554E6E7220A4C98C6%2540AdobeOrg%7CTS%3D1620216913&CSAuthResp=1%3A%3A2473074%3A1911%3A24%3Asuccess%3AFCFFC45173773C5AC8C8F507D9E0E011#.YJKMVbUzb-g 
• How do we ensure Passports work within existing ecosystems (eg. NIH), even in this space we are getting feedback on what technology and policy looks like. We can take this and look at if ELIXIR has the same requirements.

• Jaime: Agree, this is necessary approach

• Visualization of end-to-end and seeing how individual pieces fit together very useful; who is putting together the big picture?

• Part of the vision is up to us, the DURI WS, to best take products we have and make sure they’re used across the ecosystem. What is feedback of what the vision should be? What are you working in your groups where you have to work across different aspects?

• Adrian: GA4GH put together a paper submitted to Cell Genomics to present a vision of what federation means and given a more nuance position of when federation is desirable or not.

• Feedback from reviewers is to tie it together with the standards we are developing; what is needed for the minimal viable level of federation.
• The kind of federation we hope to achieve is informal, clunky, international.  More opportunities for seamless end-to-end connection of institutions. There is trade off and challenge. When looking internationally, what is the minimal onboarding

• Vivian: new role, setting up COVID databases, great example of a unit because it is merging everything we’ve talked about. Trying to make all types of data available in a very quick way including systems that are already up and running. Very fast-paced and could feed this back to FASP.
• Angela: This is related to the GA4GH Planet API that Jeremy is developing, which should track implementations. For now I am tracking in a Google spreadsheet here: https://docs.google.com/spreadsheets/d/11pPTKVW3j3_WHigWw4UOvlkQbPkM_z-ICgksE5L1vEY/edit#gid=730055376
• Michele: Have examples of sites that do run and how they’ve implemented GA4GH standards and platform integrations to show how people have it done. Eg. ELIXIR and AAI.

• Need to give bite-sized chunks for people.
• Finding the bridge to connect the standards

• John: struggled to identify minimal skill sets needed; just stood up a passport server and wouldn’t be able to tell researcher how you submit, can’t easily be explained for it to be useful for them.

2021-03-24

Chairs: Tommi Nyronen, Jaime Guidry-Auvil, Craig Voisin, Sarion Bowers, Jonathan Lawson, Melanie Courtot

Attendees “Name (Affiliation)”: Tommi Nyrönen (ELIXIR), Jaime-Guidry-Auvil, Craig Voisin, Asiyah Lin, Francis Jeanson, John Wright, Kathy Reinold, Kurt Rodarmer, Sarion Bowers, Vanessa Vogel-Farley, Aina Jene, Soichi Ogishima, Pinar Alper, Sylvia Gayle, Suresh Maslamoney (H3ABioNet)

Minutes:

FASP: DRS+Passport Connect meeting (agenda, recording, minutes)

FASP updates since then:

• Changing FASP main meeting cadence and make room for more hackathon sessions
• Resolving issues with resolving researcher access to a specific set of files across multiple organizational boundaries
• Then wish to look at an end-to-end researcher flow including discovery of such files
• Collect other use cases and pressure test design at the technical level
• Communicate with groups along the "three lenses" listed above
• Action is to organise hackathons (ELIXIR developers requested)
• Collecting more use cases (Researcher flows)

• Execution of a query on distributed (access controlled) files
• Meeting host institute policy

• Use case(s):

• Tommi: EJP-RD EU 1M genomes initiative to execute clinical relevant queries to diagnose rare disease across 4-5 European sites. Thinking of adopting GA4GH standards and DUO and Passports both play a role.

• Pinar: Have contacts with local people on 1MG Federated Access use case: Adrian Thorogood

• Example collection of user stories; this is a good level to start at and then map the technical requirements.

• Do we need a template for how people describe use cases? How to best describe things succinctly and make it easy to collect community feedback.

• Get right people into DURI meetings; we want to understand at what level we need to achieve requirements for use cases. Standards won’t do everything but meet the core needs.

• Kathy: Does a lot of use case collection; Gabby at EMBL-EBI spends time interviewing users, would be a good person to reach out to. Have number of projects around search use cases (how do we find this data, etc) and challenge is scope of search; so broad that trying to answer so many questions is hard. Scope is important.
• Asiyah: NIH cloud interoperability, there should be different layers of search. Support effort to define what kind of search, have hierarchy, and then look at use cases to target. NCBI is using GA4GH standards, and can look at how we can align.
• Asiyah: Want to find specific population, define cohort.
• Kathy: Show me all high quality CTCF targeted ChIPseq data from samples with gene expression data.
• Kathy: Find all RNA-Seq datasets that have compared a certain species of microbe (say, E coli or Staph aureus or Candida albicans) treated with a certain antimicrobial drug (say, ceftriaxone or oxacillin or fluconazole)
• Has anyone done landscape analysis of systems involved? What’s possible to start with?

• The Beacon v2 model where datasets are identified and bonafide access to deepers search functionality could be allowed; will increase metadata that can be returned.

• Francis: Create a list of what questions may be and classify those that are more obtainable.

• Jaime and Kathy: Agreed; we need to start with what can be done for more immediate needs and then work up to more ideal.

• If it starts at search, we can look into the research the Discovery WS have done on use cases, what they support and plan to support.

Roadmap Review

• Add comments indicating the status of each deliverable.
• Terminology needs some fixing as names have changed
• DUO milestones

• Along with increasing and expanding documentation,
• DUO governance process evolved - important to keep “change management process” on the agenda
• How to recognise development made on top of DUO standard that could be leveraged by another adopter. What to capture?

• Idea: Invite documentation how DUO has been implemented and share it in GA4GH website etc.
• Kathy: Could allow those who extend DUO to post about their extensions.

• FHIR Consent Language & DUO is a good idea to emphasize https://www.hl7.org/fhir/consent.html 

• Clin/pheno WS and dbGaP are exploring this

• Machine readable guidance document is important for success of DUO, gives value when it is available at the start depending how you’re using DUO.

• Too difficult to translate every instance, nuance scenarios

• Passports milestones

• Looking for feedback from DACReS in June which will help drive milestone 1
• We need a drivers for milestone 1 and 2
• Milestone 3 most active

• DRS and Passport spec change proposal updated to Q2

• Papers

• DUO paper has gone to reviewers but haven’t heard back
• Passport paper submitted

2021-02-10

Chairs: Tommi Nyronen, Jaime Guidry-Auvil, Craig Voisin, Sarion Bowers, Jonathan Lawson, Melanie Courtot

Attendees “Name (Affiliation)”: Vivian OTA WANG (NCI-NIH), Kurt Rodarmer (NIH), Mikael Linden (ELIXIR-Finland), Suresh Maslamoney (H3ABioNet), Dylan Spalding (EBI), Stephanie Dyke, Lynette Lilly (UChicago), Nancy Mah (FH-IBMT), Georg Philip Krog (Signatu), Pinar Alper (ELIXIR LU/LCSB)

Minutes:

• Passports paper - thank you for everyone’s comments

• Dylan’s comment: not sure passports are designed for storage. Sounds like a schema that stores information.

• Not that Passport is storing, it stores access rights; Passports includes information but not necessarily a store. Remove “and store”

• Jaime’s comment: sentence that is very specific to an implementation process and not really relevant for passports.

• The external collaborators need to independently apply for access, their home institution takes legal responsibility. Important point that passport is not necessarily going to address.
• Remove sentence to avoid confusion

• Mikael’s comment: paragraph that doesn’t have reference to support statement.

• Remove paragraph.

• “DACs are moving towards a model in which they approve a researcher for any datasets...”

• Too strong a sentence?
• Keep in to indicate other ways people are thinking of doing this. Okay to be speculative.

• Kathy’s comment: Add one more statement giving access to users and smoothing access request to conclusion.

• Start with as tech becomes more readily available.
• Can add more concepts
• Kathy volunteered to help clean up.
• Can link paper from A.Thorogood and B.Knoppers that can be tied into this. Tommi will share this paper.

• Authors: need to understand the role of each person. Need to make sure everyone did actually contribute.

• Add emails and send a call to action to everyone already listed to include contribution detail; if enough detail we can include them.
• Sarion will draft what that contribution should look like.

• DUO paper

• Melanie and Jonathan will send out, looking for additional comments by Feb 19 to be discussed at DUO call.

• Connect Meeting

• DURI meeting topics:

• How to best integrate Passport with cloud offerings. How IDs are looked up. Cross-WS piece, not so much around policy, better suited for FASP?
• Talk about other collaborative work and figuring out what that means in terms of policies and possible implementations. How DUO and Passports play with other groups?
• What DUO can and can’t be applied to. Creating a vision of how different pieces will work together.

• Add an OnRamp session?
• DURI representation at FASP, DACReS, OnRamp session (?)

Minutes:2021-##-##: TEMPLATE

Chairs: Tommi Nyronen, Jaime Guidry-Auvil, Craig Voisin, Sarion Bowers, Jonathan Lawson, Melanie Courtot

Attendees “Name (Affiliation)”:

Minutes: