GA4GH Passports

Minutes and Actions 2021-2022

These are the minutes for the Passports meetings, a subgroup of the GA4GH Genomic Knowledge Standards 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 https://ga4gh.org.

Links to relevant documents:

• GA4GH Passport specification
• GA4GH AAI Profile specification
• DURI 2020 Roadmap: DUO milestones, Passports milestones
• Passport Manuscript: latest draft vs. original draft

2017-2018 Minutes

2019-2020 Minutes

Table of Contents

2017-2018 Minutes

2019-2020 Minutes

Meeting Protocols

List of Meetings

2022-05-04

2022-03-23

2022-02-09

2021-11-17

2021-10-06

2021-08-25

Paper: comments back to Orli. Waiting for her comments back.

2021-06-02

2021-04-21

2021-01-27

2021-##-##: TEMPLATE

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.

List of Meetings

2022-05-04

Chairs: Sarion Bowers (WSI)

Attendees “Name (Affiliation): Kurt Rodarmer (NIH), Martin Kuba (ELIXIR-CZ), Susan Fairley (GA4GH), Mikael Linden (ELIXIR-FI), Jonathan Lawson (Broad), Fabio Liberante (GA4GH), Tom Conner (Broad), Michele Mattioni (Seven Bridges)

Meeting recording (to be linked):

Minutes

SF: Product Approval Process Document

https://docs.google.com/document/d/1UUJSnsPw32W5r1jaJ0vI11X0LLLygpAC9TNosjSge_w/edit

SB: External review as in external to GA4GH or to the Work Stream?

SF: External to people involved in development work

MK: Should implementations be required for minor versions, as they are for major versions?

SF: Goal to demonstrate interoperability

SB: Any concerns with going through a reduced Product Approval Process?

KR: No known implementations of v1.2 beyond personal desks. Is it mechanical or policy interoperability?

SB: Would agree that policy is more important.

KR: NIH don’t work with Bona Fide, only pre-authorisation, so Passports compliance doesn’t equal interoperability

SF: Short summary of changes - not brand new documentation

Updates from Working Group

2022-03-23

Chairs: Sarion Bowers, Martin Kuba, David Bernick

Attendees “Name (Affiliation): Giselle Kerry, Michele Mattioni, Tom Conner, Brandon Wright, Francis Jeanson, Tommi Nyronen, Jaime Guidry Auvil

Meeting recording (to be linked):

Minutes

Latest resources for v1.2

• https://github.com/ga4gh/data-security/pull/56

• https://ga4gh.github.io/data-security/1.2-draft-token-exchange/aai-openid-connect-profile

AM: A smaller working group has been looking at resolving some issues towards a newer version of Passports. These meetings occur weekly for an hour. Let me know if you’d like to be added (alice.mann@ga4gh.org)

Updates from Working Group

MK: Changes were communicated during the last meeting. Now we are preparing the text. https://github.com/ga4gh/data-security/pulls

TC: There are a number of PR that start with 1.2-draft. There are two that have some stuff that will find their way into.. Updates on token exchange to allow proper token exchange separate from user info. There’s another branch and OR that concerns sequence diagrams and high-level descriptions of how it works. Those two things will separately be resolved then merged into 1.2-main. Once that’s settled, it will be ready to merge back to the main branch. We’ve been talking about simplifying certain things in the spec.

MK: Intention is to keep the spec backward compatible and accumulate changes that were done by NIH in a version that was never released (1.1). 1.2 is supposed to accommodate changes done by NIH but instead of releasing token used by user info, we introduce token exchange mechanism for releasing the same token.

AM: Anyone interested in implementing/already implemented passports?

FJ: Working with a group in OBI and testing Passports technology through DNAStack. What are any central services for the management of these federated identities? Who hosts the digital identities. Any recommendations? With ELIXIR for example there’s compatibility with ORCID. Often research institutions will have their own identity service, e.g. active service, their own bespoke version.

MK: There are two approaches. In North America, the data is managed by NIH and they have their own identity provider. In ELIXIR there is something called ELIXIR AAI which is a proxy IDP (a service provider connected to all ID providers in SAML federation and also connected to Google, ORCID, GitHub, on the other end it looks like an identity provider)

• Security assertion markup language
• GA4GH passports only defined for OIDC (OpenID Connect) then gets a passport
• Identifier as provided by the original identity provider
• FJ: that identity provider, what technologies are preferred?
• Created central identity management service. As long as compatible with OpenID Connect
• Original identity provider? Which technology preferred, easiest is probably an implementation of like Shibboleth IdP or SimpleSamlPHP
• Also possible to connect oAuth OpenID identity providers e.g. google providing openID connect, github is providing oauth2.

April Connect

• April 20-22
• Hybrid
• Two passports session

• FASP Passports Integration
• General updates on Passports 1.2

Passports Release Timeline

TN: Is there a plan for the release of v1.2?

DB: as soon as it’s ratified I’m ready for the release.

AM: Still working through the details so any ideas in terms of that time frame.

TC: Won’t be ready by Connect, but it’s getting there. At Connect it will be at a point where we can dig into final details.

DB: Can we have one of those documents that suggest how it should be used?

TC: A high-level doc to go along with detailed spec? Maybe?

DB: That would be helpful - to say this isn’t quite done, but this is what could happen.

TC: Definitely some non-normative high level descriptions. Good to use the time at Connect to tell people what we’re doing.

DB: Whenever we have ambitions at Connect to get people involved at Security it’s always the same people.

AM: Hope to do outreach beyond GA4GH. Going through a sequence diagram would be a good proposal for Connect.

TN: Can you remind us of the process of what happens once it’s ready for release.

AM: It’s a minor release so it does not need to go through the product approval process. Will need to check if anything is needed for minor release.

TN: When we do release it we should make some noise about it. Announcing it sounds like a good idea. Let us know if it’s enough for DURI WS to self declare.

2022-02-09

Chairs: Sarion Bowers, Tommi Nyronen

Attendees “Name (Affiliation): Janne Lauros, Jim Basney, Kurd Rodarmer, Martin Kuba, Joe Flores-Toro, Mikael Linden, Tom Conner, Melanie Courtot, Jonathan Lawson, Michele Mattioni, Heidi Sofia,  Vivian Ota Wang, Stephanie Dyke

Apologies: Alice Mann (GA4GH)

Link to meeting recording: https://us02web.zoom.us/rec/share/967S28ZFVLk7DIlEeRhA_sYzSlq7jKiBvMRZ4tP6FybboR0s-ejNub38A7t1uIKa.daRfH2itBBXC35W

Minutes

SSI Proof of Concept (slides here)

• Current approach: there are passport brokers that pull visas and present them to passport clearinghouse
• challenge : how many passport brokers will we need to have? Researchers need to log in to the passport broker that can deliver their permissions. To access two datasets from different data providers, the researcher needs to log in against two brokers and two different sets of credentials - it can be difficult to understand why they need to log in twice.
• Distributed (self-sovereign) identity: emerging paradigm. There is no identity provider (passport broker). Issuer writes attributes to the user's wallet which is in the user’s smartphone. VCs or related proofs are released directly to verifiers.

• European commission is proposing eIDAS update which follows these principles

• SSI approach to visa delivery

• User goes to DAC which will give them permission which is added to their wallet. The user goes to several DACs if they need to access multiple datasets. The wallet is then used with all permissions to access the computing environment.

• Proof of concept: Built on ELIXIR AAI and REMS.

• Used commercial components: Evernym’s Connect.me wallet and Evernym’s SDK.
• Try here with ELIXIR ID: https://docs.google.com/document/d/189e857cshrbCowoFtl-bsxCj09yFpi2N_u60FZtW_ek/edit

• Live demo by Janne
• SSI Pros: decoupling authentication and visa delivery, visas from DACs behind multiple brokers, no fragmented user identifiers, no broker as a single point of failure (trust)
• SSI Cons: limited smartphone UI and cannot control how the UI looks
• Questions:

• Martin: If a researcher has access somewhere but leaves their employer, access should be revoked but can’t delete from their wallet. How is this handled?

• Issuers can revoke them. Can’t remove the app but can ask the verifier to revoke access. The service checks all credentials against issuers in real time but haven’t tried it ourselves yet.

• Tommi: How does it work if a person has two jobs with different access rights. How would that work? Solved by Passports 1.0, the issuer can couple visas with affiliation. Affiliation doesn’t need to be expressed using a role but with verifiable credentials by the organization. One person can have several credentials in their wallet if they’re employed by two organizations with written verifiers. You need affiliation credentials from both organizations.
• Michele: Is this based on a standard or can someone use this application on a browser or website?

• SSI think wallets = smartphone apps but possible to do over web browser.

Passports v1.2 and v2.0

• Minor upgrade from 1.0 to 1.2. Which will include a token exchange endpoint for releasing all passport visas in a signed token separated from other personal information. Non-breaking small change. Reason is concern over when visas are released from the user reference endpoint there may be information of the user that shouldn’t be passed to other services. This will separate visas from person’s information.
• V2.0 will define work-order tokens with limited permissions for computational workflows. Work-order token should be assigned to entities, even if it leaks it can’t be abused by another party. Should also have a longer lifetime.
• Now deciding where to host these proposals on repos and once decided will share these links and invite comments from wider groups.
• There is a new implementation from CINECA
• There was a FASP hackathon focused on testbed for interoperability among all involved parts (idP, visa issuers, brokers, WES, TES, DRS)
• Questions:

• Michele: DRS wants to explicitly say which passport holds information. See pull request: https://github.com/ga4gh/data-repository-service-schemas/pull/381

2021-11-17

Chairs: Alice Mann (GA4GH), Sarion Bowers (Sanger), Martin Kuba (ELIXIR-CZ)

Attendees “Name (Affiliation): Vivian OTA WANG (ODSS/NIH); Heidi Sofia (NIH/NHGRI)

Tom Conner (Broad Institute), Joe Flores-Toro (NIH/NCI), Michele Mattioni (Seven Bridges), Francis Jeanson (Datadex), Suresh Maslamoney (H3ABioNet), Jaime Guidry Auvil (NIH/NCI), Kurt Rodarmer (NIH)

Minutes

Passports paper has been published along with many others last week. Passports paper well received. Thank you to everybody who worked on it. Milestone for this group.

Update slides here

H3Africa keen to set up H3Africa. Some of the groundwork.

Jaime: Where would you like to see Passports going in the future?

• We have standards out right now
• Highly driven in a particular way that feels possibly different now
• All the work streams are coming into their own, they have standards out, there are more discussions about the specific needs for implementers.
• Appears to me that there are different combinations of implementations
• If giant matrix on a lifecycle and put DP and implementations underneath each, is that the way H3Africa or ELIXIR etc, the path along that life cycle would be different among each group.
• Having these cross WS discussions by implementation, or overlap of implementations at specific points could be useful
• Hear a lot of discussions that maybe need to be brought out into collaboration.
• DB: loosely coupled systems that we see in the US, bunch on Institutions working on one project that need to share as if one system but managed by different Institutions. That is the use case I was thinking about. Hoping to remove some of the ambiguity and reduce the number of ways of doing things.
• Passports work but how does it tie in in other places, DUO still
• Can passports also express what you can do with the data, hook in DUO and WES, you can have access to this data only to do these types of algorithms and if you exceed it then WES system allows you to only use this and access this
• KR: hts and crypt4GH folks should be getting involved soon
• FJ: second David’s idea, part of newly formed computable cohorts group, definite interest here to leverage that as part of process of finding cohorts from federated databases. Adding the ability to support that kind of activity with existing databases will be part of that.
• Integration with DRS makes a lot of sense.
• FJ: We are at implementation stage, for those interested in exploring that, Suresh and interested with groups i work with in Ontario
• DB: Tom can post the document here, we have a working document of what v1.2 looks like before we turn it into spec. Then we will flip it into a PR.
• Summary document here: https://docs.google.com/document/d/11D6t6t6lgvpU9sEWg3f7ZKNqNlQdszJ5P2DFDnC8wXE/edit 
• Jaime: another quick question, some of my team has joined a computable cohort team. Do we want to put formerly onto our roadmap?
• FJ: FASP is positioned as an overarching working group that might be the avenue to come together and discuss which groups are integrating with other groups.
• FJ: two groups within the computatable cohorts.

2021-10-06

Chairs: Alice Mann (GA4GH), Sarion Bowers (Sanger)

Attendees “Name (Affiliation)”:  Kurt Rodarmer (NIH), Mikael Linden (ELIXIR-FI), Martin Kuba (ELIXIR-CZ), Tom Conner, Karen Plevock-Haase, Jonathan Lawson, Katie Vance, Suresh Maslamoney (H3ABioNet), Francis Jeanson, Stephanie Dyke, Pinar Alper (ELIXIR-LU), Andrew Paredes

Minutes

• Passports paper: should be submitted this afternoon or tomorrow morning. Hopefully last submission. It has been a lot of work up to this point. Thank you to everybody for their contributions so far!
• New Passports leads: Craig Voisin recently stepped down, thank you to Craig for all his hard work and contributions. We have new leads and welcome Martin Kuba and David Bernick along with Sarion who remains in the co-lead position.
• David is current co-lead for Security WS and has been involved in Passports/AAi discussions since the beginning.
• Martin has been involved in passport implementation at ELIXIR AAI and brings a lot of experience in this to the workstream.
• Thank you to both for stepping up.

Passports workshop

• For October Connect next week
• We need to plan the workshop for Passports Implementation
• Mikael suggests using the use case document to focus implementers discussions
• Good idea so have incorporated this suggestion
• Use cases:
• https://docs.google.com/document/d/1x9jEmSQqaFRDMrFAvCHtma0N0QrNfTKLG3xqpJRw8pE/edit#heading=h.vo7w4rw4ya22 
• Alice to start making slides that can be populated by presenters

Martin has some questions on the size of the new proposed 4k compact passport

• This has been proposed for v1.2 (will be discussed at the October Connect meeting for anyone who wants more detail)
• See the minutes below for a discussion on this
• Martin asking more details about the necessity for smaller passports
• Kurt giving some context

2021-08-25

Chairs: Craig Voisin (Google), Sarion Bowers (Sanger)

Attendees “Name (Affiliation)”: VIvian OTA WANG (ODSS-NIH), Kurt Rodarmer (NIH),

Katie Vance (ODS-NCI), Binam Bajracharya (UChicago), Jaime Guidry Auvil (NIH), Stephanie Dyke, Heidi Sofia (NIH), Mikael Linden (ELIXIR-FI), Suresh Maslamoney (H3ABioNet), Michele Mattioni (Seven Bridges)

Minutes:

Paper: comments back to Orli. Waiting for her comments back.

Craig:

• Passports/AAI group - WG on DRS/Passports working together. There is a WG running a hackathon on what kind of changes are required for Passports to get it working together. Made minor tweaks to AAI and Passports spec (patch) - clarifies what is a passport etc with more solid definitions, and a new version 1.2  (v1.1 will be NIH work) will introduce a new format for passport (working title 4k passport) which contains the visas. V1.2 will be a more self-contained version but will limit the number of visas, which are in a more compact form but retains the “special sauce” of passports - retaining the original authorisation of the visa.  In order to retain the authorisations the passport will have limitations on the number of visas - “downscoped” passport. There may be encoding to allow you to get your visa into the “compact” passport.

Kurt Rodarmer:

• v1.1 is NIH, looking for GA4GH feedback, a number of groups implementing to that spec, DRS implementers , take a passport in a POST method to DRS, seeing this through
• NIH ecosystem will have everyone using this v1.1
• v1.2 has been described as supporting a number of features

• downscope
• switch back/forth from full version and compact version
• Kurt fully supports compact form going forward
• will be some time before implementing v1.2 (the NIH ecosystem investing in v1.1 right now)
• v1.2 will help support FHIR and will be a push for NIH to move towards v1.2
• Kurt looking at FHIR support for passports as part of design, gathering requirements and looking at possible solutions

Passport workshop:

• implementing passports
• driver projects that have implemented passports or want to in future
• Suresh Maslamoney (H3Abionet?)

• looking to implement
• still setting up
• Alice^[a] will follow up

• Mikael Linden (ELIXIR)

• Cineca project - could provide examples of use cases where passports are made use of

• Binam Bajracharya (UChicago)

• Would like to be in the workshop

• Suggestions of GEM Japan, H3Africa and Genomics Australia and Autism Sharing Initiative (ASI)
• Michele Mattioni (Seven Bridges)

• sd/l;.looking at implementation no=

Jaime:

• Susan is looking to work across the spectrum in GA4GH
• Possible connections with DUO and clinpheno ?
• See more of this in connect meeting and some in the plenary as well
• please register
• have some starting agendas, but will be tweaked
• please check in on the GA4GH website

2021-06-02

Chairs: Craig Voisin (Google), Sarion Bowers (Sanger)

Attendees “Name (Affiliation)”: Stephanie Dyke, Kurt Rodarmer (NIH), Mikael Linden (ELIXIR-FI), Jaime Guidry Auvil (NIH/US), Alice Mann (GA4GH), Suresh Maslamoney (H3ABioNet), Heidi Sofia (NIH, NHGRI), Dylan Spalding (ELIXIR-FI), Pinar Alper (ELlXlR-LU), Vivian OTA WANG (ODSS/NIH-US)

Minutes:

Updating the definition of Passport

• Difficult to follow what we mean and when, terms are used interchangeably and not clear because so many tokens are involved. Project kicked off by David Bernick (Data Security WSL) responsible for AAI spec. Working with a few members to clean up the definition of what Passport is.
• Goal is we can clearly define what token and non-token components make up a passport and cleaning up token types
• Reach out if you’d like to be part of the review process

Starter Kit & DURI interactions

• Start Kit: project by Ewan, to get research institutes and organizations onboarded to GA4GH and to start using our standards. Breaking down barriers to get them onboarded. Previously named the On-Ramp campaign.
• What are the minimal things we can put together for institutions that they can use to layer on top of their existing infrastructure so that their researchers can start using our tools. When ready for more complete implementation, can easily swap out pieces.
• DURI plays a role with these services, involved with this package. Jeremy Adams leading this.
• Members interested in being involved and provide input on the DURI interactions? When should DURI be involved and when we shouldn’t?
• There will at least be a passport broker involved, or something that allows you to interact, there are plans for such a system developed, a minimal one.
• Will DUO get involved with the starter kit
• When will DURI get involved
• Heidi Sofia: Is the Starter Kit meant to be general across GA4GH?
• CV: yes, a generalised concept. Focused around DRS and passports. It may be a layer that wraps around what your lab is already doing. Using GA4GH wrappers etc such examples are starter points for the GA4GH MVP
• Get in contact with Craig Voisin for any feedback/interaction/get involved

Passports paper

• Reviewers comment came back, reviewers liked our work. Minor revision, one reviewer had the recommendation that was published as is. But with the high level journal, 12 points suggested for how the article can be improved
• 3 weeks to respond to 12 points
• Kathy and Alice have started a google doc to work on this, proposing a smaller group of people (lead authors and other experts) contributing to 12 points and then bring back to more general DURI and then send back to Editor.
• Goal today is not to assign all the tasks, first we need to understand the general direction to know our response
• Technical article is longer than what we have, so we could expand but it means much more work
• Going through the reviewers comments document made by Kathy and Alice
• Themes and topics from reviewers
• Current scope of paper: introduction to community, giving examples of Passports and indication of how you could start yourself and how it could solve your problems.

• Originally stayed away from being too technical; can consider now making it more technical but may lose original audience.
• Tommi: we should stick to targeting scientific audience.

• Tommi to respond to the editor letting them know our decision not to convert it to a technology article and why
• Jaime and Craig: expand on trust, add a few more words here. Would strengthen the value proposition.

• Craig: if more implementations direction, ELIXIR current implementation example is fairly short. If reach out to AutismSpeaks re google implementation, could we add more nuance here to what passports can achieve?
• Kathy: dbGAP could be an interesting example to explore. Also the GAP analysis proposed in the reviewers seemed interesting. High level benefits as part of GAP analysis.

Main article considerations

1. Shorten to technical paper? There is enough information here that we can make into a longer article. Base decision off what the main objective and who the audience is for the article.

1. See article types: https://www.cell.com/cell-genomics/article-types

2. Which direction do we take the paper?

2021-04-21

Chairs: Craig Voisin (Google), Sarion Bowers (Sanger)

Attendees “Name (Affiliation)”: Stephanie Dyke, Mikael Linden (ELIXIR-FI), Dylan Spalding (ELIXIR-FI), Jaime Guidry Auvil (NCI/NIH), Kurt Rodarmer (NIH), Pinar Alper (ELIXIR-LU), Michele Mattioni (Seven Bridges), Heidi Sofia (NIH, NHGRI), Tommi Nyrönen (ELIXIR-FI), Jonathan Lawson (Broad Institute), Heidi Sofia (NIH), Emily Boja, Andre Paredes,

Minutes:

Meeting recording (Passcode: 0^rSjYF0)

Passport paper - Tommi

• Cell Genomics Passport paper is still “under review”
• GA4GH marker paper has been revised (Heidi Rehm, Angela Page)
• Action: chase in a few weeks if we don’t hear back

Mikael Linden: CINECA presentation

• Slide link
• CINECA: Europe, Africa, Canada
• Currently, in Passport spec, permission is an atomic string value
• EGA approach where the data object is atomic dataset

• Dataset identified by EGA accessions
• Grants permissions to access the dataset as a whole

• Works for EGA, but within CINECA there are other modalities

• Child cohorts in Canada: granted to certain variables

• properties of patients then only those are available for research
• access some columns not all

• Even more fine-grained approach used by several biobanks

• Not just columns, but filter by rows
• E.g. grant access only to samples that have positive diagnosis for diabetes
• Gives access control needs down to cell level in the table

• Current passport spec doesn't cover this

• out of scope
• proprietary extension
• NIH may also need finer grained controls
• wondering if we could see how that compares (?) to other cohorts and if there is a common ground for a common specification

• Sarion: metadata vs other data?

• Variables can be phenotype data like gender, BMI

• Tommi:

• case a: EGA whole dataset with phenotype and genotype data
• case b, c
• doesn't exist in many of the serving infrastructures

• Jaime: Attributes and variables coincide with allowable data use; phenotype may coincide with disease specific variables but wondering to what extent this could actually match with DUO codes?

• Heidi: two different data cells that have same DUO code but you may want to differentiate between them, implementation of ability to create fine grained access control and independent of DUO codes. Could be useful. If not hard to build, this would be interesting capability.
• Stephanie Dyke: +1

• Kurt: Protecting individual columns but not general case scenario

• Craig: There are technologies that can subselect rows and columns or permissions for different views, other databases have policy tags and enforce base on users and what policies they can see. There are a couple of approaches. For the most part, most visas have the what of the permission encoded inside value field of visa (not very specific). Common interpretation of value is a unique identifier.
• Tommi: How many service providers are actually at that level? Readiness of data service providers should be predicted based on this. Not sure how timely this might be. Other service providers we’re not aware of?
• Kurt: The ability to bridge between authorizations carried in the PAssport and access to big query would be fruitful avenue to explore

• Pinar: Such granular access control meets the “data minimisation” requirement of the GDPR. Appears to come with the cost of partitioning datasets to allow it.
• Craig: What’s mapping level of dbgap?

• Jaime: From approval standpoint, you approve by consent group. DAC is given permission by consent group even within a dataset. Caveats within that are specific to multiple consent groups in one study.

• Craig: is there a need for a language that would allow data access to vary dynamically? Are these things fixed or are they quite dynamic and data keeps changing?

• Jaime: There shouldn’t be change by consent (not often seen); how it’s put in the system is how it is.

• Craig: Number of consent groups?

• Jaime: as many as 6 or 7; becoming less to have multiple consent groups.
• Sarion: agree with that; there can be quite a few depending on how you slice it.
• Craig: If permutations are large, it would be a maintenance nightmare to use views. In the case of Mikael, create 6-7 views or permutations of those. Seeing if there is halfpoint without having dynamic language.

• Craig: If there are 7 different consent groups, and as a researcher I should have access to 2. If I had access to 2 different tables, would that be too much of a pain for the researcher? Better to have 1 table with 2 groups?

• Dylan: restricting regions of the genome, questions about data minimization,

• Craig If we just look at file level, based on different attributes and policies people would typically have, would any one file would only appear in one access scenario or could you have different access scenarios where some set of data would be duplicated?
• Kurt: Describe access in the IDs, something that designates data

• Mikael: how would you deal with that in a visa?
• Kurt: not sure, difficult problem, in NIH visas use a language that is considered more private and not general purpose

• Craig: How dynamic are these needs in CINECA?
• Mikael: Is there a need for defined sets or are we happy with proprietary approaches? Does it bring added value if there is a GA4GH standard for fine grain permissions?

• Dylan: EGA data supplier prospective, EGA data supplied to conform, if two different codes then only return the one that is relevant, not part of the passport itself, discovery or search API
• Mikael: granted as dataset as a whole?
• Dylan: as of a month ago, yes, but there are discussions on how to make it more granular (based on data use conditions)

• Craig & Tommi: Figure out implementation when there’s need; we need a use case.

• CINECA use case: without DURI, when researcher applies access to biobank, enter variables they need to the DAC and based on list someone in biobank creates manually the tailored dataset which contains only those variables and that dataset is provided to the researcher. Each data access request generates new instance of dataset and data objects. Not ideal.
• Dylan: Is it purely functional purpose of researcher using those attributes?

• Mikael: They only select the requested attributes
• Conforms to data minimization

• Jaime: In the model where you have single user who wants to obtain data from EGA and NIH, getting down to differences in how each visa would interpret attributes, assumption that it’s possible and not problematic if user came outside of the home institutions would be obtain data from each but using 2 different visas. Or asking single visa and need to agree on attributes up front?

• Mikael: Several visas needed, could there be common ground so that implementation and interpretation of visa isn’t dependent on the issuer.

• Mikael: is it useful to have a common provision in the passport spec?

• Kurt: If we try to achieve common language, it wouldn’t work.
• Craig: in spec, provide a place where custom extra provisions can be provided; whoever is implementing need to understand provision and if they don’t need to generate error. Need a place where this exists. Is this a reasonable approach?

• Tommi: Pinar had use case with GDPR data minimization, interesting overlap between NIH internal data minimization and GDPR requirement for data minimization. This may be driver/use case.
• Solution for data minimization first? Looking at what’s already part of passport process; extend to have more granular data access. Do they meet somewhere in the technical system?
• ACTION: Contact Giselle from EGA, may be able to give real world use case.

Wrap-up

• New DURI WS Manager: We will be welcoming Alice Mann in May! Alice Mann is a current Sanger employee, working with Open Targets since 2019. Before that she was a postdoc and PhD student in functional genomics, also at Sanger.

2021-01-27

Chairs: Craig Voisin (Google), Sarion Bowers (Sanger)

Attendees “Name (Affiliation)”: Tommi Nyrönen ELIXIR, Mikael Linden (ELIXIR-FI), Kurt Rodarmer (NIH), Max Barkley (DNAstack), Stephanie Dyke, Pinar Alper (Elixir LU), Michele Mattioni (Seven Bridges), Dylan Spalding (EBI), Heidi Sofia (NIH, NHGRI), Vivian Ota Wang (NH, NCI), Jaime Guidry Auvil (NIH, NCI), Justina Chung (GA4GH)

Minutes:

• Passports manuscript shortened and refined and sent to the editor at Cell Genomics for comments; have not heard back from her yet. Next steps: could be shortened more and literature review.
• Ideas for Connect meeting

• What are the dependencies? Would like to have ideas across the community about the different use cases we want to enable. What are blocking issues that can be resolved to help other standards move forward. Example use cases:

1. Cloud WS DRS, how do we use passports to access data through DRS API
2. Search API, they’re asking for guidance
3. Use passport in conjunction with FIHR on clin/pheno data. Michele will find someone to be the champion for this.
4. The Service Info/Registry group in the Discovery Workstream is also interested in how they can advertise what auth is needed for a service
5. What other use cases can we consider?

• Time slot would be shared with DUO

• Passport Roadmap

• Milestone 1- clinical care professionals and industry researchers; what do we want to do with this item?

1. Movement of data science, this should be kept as priority.
2. Clin/pheno WS is thinking of how to integrate with ehrs, FIHR, etc. may be valuable to bring someone from this group to share their thinking.
3. Add suggestions who can help drive this forward.
4. Will need to update the expected completion date.

• Milestone 2 & 4 can be merged? Recommendations from DACrES
• An item in the roadmap about security - i.e. to model cybersecurity threats, see what kind of attack vectors can happen, and evaluate how the passport’s built-in security controls address those risks?

1. Add to Milestone 2 - security assessment collaboration to analyze threats and mitigations

• Summary of hackathon

• Specific use case with DRS: Client trying to get access files, already know list of files by ID.For simplicity, we’ll say the whole set is from one DRS server controlled by NIH.

1. Client goes to DRS server, asks for who they need to talk to get authorization for DRS ID. Assumption that DRES Server has an endpoint that exposes one or more brokers that they can talk to that will hand the passport they’re looking for.
2. DRS will give you access to bytes only if you have passport from the broker (eg. you need to talk to RAS)
3. Client talks to broker and asks for access to DRS ID and asks for passport
4. You get specialized minted visa specific for your use case
5. Go back to DRS server to give passport and access bytes

• Requires 2 extensions at least, ability to indicate resources it’s interested in when talking to broker (arrow 3) and an API for the broker to interrogate DRS server to ask what visas would be necessary for these resources. Broker doesn’t need to have this info.
• This is a model, doesn't have to be DRS. Could follow a similar model for Search, etc. As long as the broker can call back and ask what visas you need. Can we follow same model and how different does it have to be?
• Htsget? They were asking to work with FASP to solve this. This could probably be adapted for htsget as well.
• More information here. The team is invited to send feedback and to add comments to the doc.

2021-##-##: TEMPLATE

Chairs: Craig Voisin (Google), Sarion Bowers (Sanger)

Attendees “Name (Affiliation)”:

Minutes: