Skip to end of banner
Go to start of banner

Data Passports

Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 2 Next »

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.

In the GA4GH Data Passport parlance a “Broker” is a system that issues information about researchers (data passports) that can be used to grant access to data. This would be a governance system external to Synapse. A Claim Clearinghouse is a system that receives data passports and makes decisions about whether to allow access to data. Synapse would be considered such a clearinghouse. The terminology is defined here.

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.

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.

As mentioned above the id token or user info returned by a broker contains a passport in the form of a claim named “ga4gh_passport_v1”. The format, given here, is:

{
  "ga4gh_passport_v1": [
    "<eyJhbGciOiJI...aaa>",
    "<eyJhbGciOiJI...bbb>"
  ]
}

The passport is an array of visas, each enocded as a signed JWT.

  • No labels