...
The passport is an array of visas, each enocded as a signed JWTencoded as a signed JWT. There are multiple types of visas. The variety of types is open ended but the GA4GH spec' defines some particular types here. It’s important to note that while some visas are assertions about the researcher (like AffiliationAndRole, ResearcherStatus) others refer to specific data sets, like ControlledAccessGrants. The reason to have these different types is illuminated by this overview article on GA4GH Data Passports, which differentiates between “registered access” and “controlled access” models. Regarding registered access:
Registered access models are a type of role-based access to datasets.
while for controlled data
In the DAC review phase, the DAC must verify the identity of the data user and determine if the proposed research is within the bounds of the permitted use(s) of the dataset. If approved, the data user and their institution must agree to the terms of use of the repository’s data through a data use or processing agreement. In the data use phase, the data user gains access to the dataset(s).
We then then conceive of different sorts of passport-linked access requirements in Synapse. One type would grant access to data if a researcher is indicated to have a certain status by a trusted Broker. Another type would grant access only if a visa provided by a trusted Broker indicates that the user has access to a certain (controlled) data set. We would expect that in the visa the data set would be referred to by its ID in the namespace known to the Broker, as opposed to its Synapse ID. Therefore the Synapse access requirement would have to include the former ID in order to be able to evaluate the user’s visas.
An example of a ResearcherStatus visa taken from here is:
| Code Block |
|---|
"ga4gh_visa_v1": {
"type": "ResearcherStatus",
"asserted": 1549680000,
"value": "https://doi.org/10.1038/s41431-018-0219-y",
"source": "https://grid.ac/institutes/grid.240952.8",
"by": "so"
} |
The Synapse access requirement would, at a minimum, be configured with the URI seen in the ‘value’ field. An example of a ControlledAccessGrants visa (from the same source) is:
| Code Block |
|---|
...
"ga4gh_visa_v1": {
"type": "ControlledAccessGrants",
"asserted": 1549632872,
"value": "https://example-institute.org/datasets/710",
"source": "https://grid.ac/institutes/grid.0000.0a",
"by": "dac"
} |
Again, the Synapse access requirement would, at a minimum, be configured with the data set ID seen in the ‘value’ field.
Implementation Considerations
In many places, Synapse needs to rapidly answer the question of which of one or more entities a user is authorized to download. The determination reflects access requirements placed on the entities and uses corresponding access approvals, stored in the Synapse database, to answer the question. Moreover, there are use cases in which a headless user agent (e.g., a batch data processing job) seeks to download data on behalf of a user. In such cases the user agent can’t be redirected to a data passport broker to retrieve user info via the OAuth flow. We should therefore adopt a model in which, when a user first authenticates to a broker, their user info, access token and refresh token are captured in Synapse so that Synapse can maintain up-to-date visa information, which can be used to answer authorization questions without a user’s involvement.