Synapse can host controlled data and has governance features allowing the Sage Governance team (or their delegates) to approve access to said data. GA4GH Data Passports allow approval to be given by an authority which is external to Synapse.
GA4GH Data Passports builds on top of OpenID Connect (OIDC, which is itself an extension of OAuth 2.0). It’s worth reviewing how a user logs in to Synapse using an OIDC identity provider (IdP) like Google:
The flow starts when the user indicates to Synapse that they want to login with an external IdP. Synapse redirects the browser (the “user agent”) to the IdP, which, after authenticating them, returns an authorization code. This is forwarded to Synapse which uses its so called client credentials to exchange the authorization code for an access token, id token and (optionally) a refresh token. The inclusion of the id token is the fundamental extension to OAuth 2.0 by OpenID Connect: In addition to authorizing access (via the access token) the IdP returns information it has about the user. The id token is a Json Web Token (JWT) so it has a JSON payload, i.e. a key-value map. The keys are “claims” about the user, like “family_name” or “email”, and the values are the user data. If the IdP is a so-called “Broker” then it can return a GA4GH data passport. The claim name is “ga4gh_passport_v1” and the value is an array of GA4GH “visas”, described further below.
The OIDC specification provides for defining an expiration for user information. That is, the IdP can indicate that the recipient of an id token should only consider the user information valid for a limited time. One the information has expired then a new id token should be obtained. An OIDC IdP has a “/userInfo” endpoint to which an access token can be passed. The result is a new collection of user info, returned either as a JWT or as a JSON object.
.png?version=1&modificationDate=1651081440464&cacheVersion=1&api=v2)
Note that the refresh of the user info' can be done without the user’s involvement, so long as a valid access token is available.
Access tokens can expire, and OAuth 2.0 provides for a ‘refresh token’ which can be exchanged (along with client credentials) for a new access token. The IdP may rotate the refresh token and also return a new, fresh id token. Again, this can be done without the user’s involvement, so long as a valid refresh token is available.