Skip to end of banner
Go to start of banner

API Extensions for GA4GH Passport Integration

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 5 Next »

Passports provide interoperable infrastructure to authenticate and authorize users across biomedical services at various stages of a research project or study.

--GA4GH Passport standard for digital identity and access permissions

Use Cases

  1. A set of files that can only be accessed by an NIH approved researcher. This use case assumes the use of the NIH Research Auth Service (RAS).

  2. A set of files that can only be accessed by a user with IRB approval. The IRB approval can be verified either by the Sage ACT or by the user’s own institution.

  3. A set of files that can only be access within a FISMA approved boundary. For example, the files can be accessed by a Cavatica workflow but not be download to an unsecured laptop (PLFM-8264).

  4. A set of files with controlled access that will be downloaded using a command line client. For this case the client will need something like a Personal Access Token (PAT) instead of a web UI login.

Visas

The GA4GH Passport standard provides a standardized mechanism for data users to present their digital identity, including authenticated credentials and permissions, in the form of visas and to share this across distributed data systems and organizational boundaries.

--GA4GH Passport standard for digital identity and access permissions

In practice, a passport would be presented within an access token to a file download API call, such as the DRS. The passport would be used by the service to determine if the caller is authorized to download the requested data file/files. While the access token would only contain one passport, the passport can contain one or more visas. Each visa make a single assertion about the caller. Each visa is a signed JSON Web Token (JWT) Claim. For example, we could create a visa that states that the caller has passed the Synapse Certification Quiz (see: Figure 1).

{
  "typ": "vnd.ga4gh.visa+jwt",]
  "alg": "RS256",
  "jku": "https://repo-prod.prod.sagebase.org/auth/v1/oauth2/jwks",
  "kid": "W7NN:WLJT:J5RK:L7TL:T7L7:3VX6:JEOU:644R:U3IX:5KZ2:7ZCK:FPTH"
}.
{
  "iss": "https://repo-prod.prod.sagebase.org/auth/v1",
  "sub": "456",
  "scope": "download",
  "jti": "some-uuid",
  "iat": 1708651144,
  "exp": 1708665544,
  "ga4gh_visa_v1": {
    "type": "AcceptedTermsAndPolicies",
    "asserted": 1645593544,
    "value": "https://repo-prod.prod.sagebase.org/repo/v1/certified/user/456",
    "source": "https://repo-prod.prod.sagebase.org/auth/v1"
  }
}.<signature>

Figure 1. An example decoded visa claim that asserts userId 456 has passed the Synapse Certification Quiz.

Note: Each individual visa is signed. The signature can be validated using the public key provided by the“jku” value.

In the example visa in Figure 1., most of the fields are part of the general JWT Claim standard and help the receiver to validate both the signature and the claim's expiration. However, the “ga4gh_visa_v1” object defines the core of the visa’s assertion. The four sub-fields (type, asserted, value, & source) tell us exactly what the visa means.

Let us assume that we wish to create a new Access Requirement (AR) that would require the caller to provide a visa that asserts the user has passed the Synapse Certification Quiz such as the example in Figure 1. Notice that the visa does not have a single identifier, and instead has four fields that define it. Also the “value” contains the user’s ID, so each user will have a slightly different “value”. So, how would we encode such a visa in an AR? In the next section we will explore how we can use GA4GH Conditions to solve this problem.

Conditions

Part of the GA4GH visa claim specification includes a section called: conditions for cases where a visa is only valid if another visa is present. The conditions specification provides a syntax for defining visa matching rules. The following is an example of how we might define a condition to match the visa from Figure 1:

{
	"type":"AcceptedTermsAndPolicies",
	"value":{
		"match-type":"pattern",
		"match-value":"https://repo-prod.prod.sagebase.org/repo/v1/certified/user/*"
	},
	"source":{
		"match-type":"const",
		"match-value":"https://repo-prod.prod.sagebase.org/auth/v1"
	}
}

Figure 2. Example condition for matching the visa from Figure 1.

We propose to reuse the condition syntax for all cases where we need to match visas. Specifically, we will provide a new API to create Conditions. Each Condition will be: reusable, immutable, and publicly readable, similar to the Synapse ColumnModel system. See Table 1.

response

signature

request

description

StoredCondition

POST /condition

StoredCondition

Create a new StoredCondition immutable Condition. If an exact copy of the provided condition already exists, then the existing StoredCondition will be returned.

VisaCondition

GET /condition/{id}

Get an existing StoredCondition via its ID.

Table 1. Conditions API.

Note: By making conditions immutable, user can be assured that it is safe to reuse them in multiple passport AR. If conditions were to be mutable, it would be difficult for users to predict the impact any changes would have across the system.

In the subsequent sections we will cover how these conditions will be used for:

  • Defining the visas that make up a passport access requirements

  • Informing the caller as to which visas will be needed for a successful call

  • Requesting a new access token containing the desired visas issued by both Synapse and trusted 3rd party visa brokers/issuer.

Passport Access Requirement

The new passport access requirement needs to be able to define which visas are required to be present in order for a user to be able to download its associated subjects (typically files). This means a passport access requirement can be define exclusively with visa conditions IDs. A passport AR with a single condition will require the user provide a single visa matching that condition to be considered “met”. A passport AR can also include multiple conditions with simple logical relationships between each. For example, given conditions with the IDs 1 through 5, we can have an passport AR with a logical combination of visa conditions. In this example, the passport AR would require the following logical combination of conditions:

(1 and 2) or (3 and 4) or 5

The above passport AR conditions would resulting in the following passport AR:

{
	"concreteType":"org.sagebionetworks.repo.model.ar.PassportAccessRequirement",
	"conditions":[
		{"conditionIds":["1","2"]},
		{"conditionIds":["3","4"]},
		{"conditionIds":["5"]}
	]
}

Note: There is an “and” relationship between elements within a single conditionIds array. There is an “or“ relationship between each conditionID array. This aligns with the GA4GH conditions definition.

The GA4GH Visa conditions specification does not support nested logic such as: 

1 and (2 or (3 and 4))

In order to remain compatible with the specification our passport ARs inherit this limitation.

It is important to note that the new PassportAccessRequirement does not inherit any functionality directly from existing ARs (ManagedACTAccessRequirement, SelfSignAccessRequirement, LockAccessRequirement, TermsOfUseAccessRequirement). The new PassportAccessRequirement is intended supplement, but not replace any of the existing ARS. To achieve this goal, Synapse will issue a visa, to a user, for each traditional AR that they have been grated an approval. In the next section we will cover all of the types of visas that Synapse will issue.

Visa Issuer

By setting up Synapse to issue visas, we can enable 3rd party services to make their own authorization decisions based on a user’s Synapse accolades. For example, a 3rd party might limit access to a resource to users with a Synapse validated profile. Synapse would provide this information to the 3rd party service by issuing a signed visa claim if the user’s profile is validated:

  {
	"ga4gh_visa_v1": {
		"type": "ResearcherStatus",
		"asserted": 1645593544,
		"value": "https://www.synapse.org/#!Profile:273991/validated-profile",
		"source": "https://repo-prod.prod.sagebase.org/auth/v1"
	}
}

Note: According to the GA4GH specification, ResearcherStatus value URL must point to a human readable web page that asserts the researcher’s status. This is an odd requirement for the GA4GH passport specification which is designed for the automatic machine validation of visas.

The above validated profile visa is just one example of a predefined visa that Synapse will be able to provide for users. Other such predefined visas will include:

Condition Name

Condition ID

Synapse Validated Profile

1

Synapse Certified User

2

Accepted the Synapse Terms of Use

3

Enabled two factor authentication

4

Using these predefined visa conditions, we can create a new passport AR that requires the user to have both a Validated Synapse Profile and two factor authentication enabled using the following definition:

 {
	"concreteType":"org.sagebionetworks.repo.model.ar.PassportAccessRequirement",
	"conditions":[
		{"conditionIds":["1","4"]}
	]
}

In the next section we will cover how visas will be available from Synapse that assert a user has “met” (been approved), for any tradition access requirement.

Traditional Access Requirements

Currently the main tool used by ACT for data access management is the ManagedACTAccessRequirement. For example, consider the case where ACT determines that Institutional Review Board (IRB) approval is required to access a dataset. To set this up, a member of the ACT would create a ManagedACTAccessRequirement with isIRBApprovalRequired=true and then bind it to the dataset. Once bound, anyone that wishes to download the dataset must first demonstrate they have “met” the bound access requirement. For this case a data consumer would need to submit proof of IRB approval to ACT. A member of ACT would then grant an approval for valid submissions. Such an approval means the data consumer has “met” the IRB approval access requirement.

Passport Access Requirements

It is important to note, that in the previous example of IRB approval, ACT is not acting as an IRB. Instead, ACT is manually confirming that an external IRB has granted approval to access the data to the researcher. If the external IRB’s system issued GA4GH visas that assert a researchers has their approval, then ACT would no longer need to manually confirm the assertion. Instead, ACT would create a condition to match IRB’s visas. ACT would then use the resulting condition ID to define a new PassportAccessRequirement and bind the AR to the data. Once the Passport AR is setup, a member of the ACT would no longer need to manually “confirm” each IRB approval. Instead, Synapse would automatically acquire and validate the researcher’s visa directly from the IRB’s system to confirm approvals.

Actions Required

Currently when a user has an “unmet” ManagedACTAccessRequirement that is bound to a file, the UI informs the user using the ActionsRequired set of APIs. Specifically, the API will provide a MeetAccessRequirement that includes the ID of the AR that is “unmet”. With the new Passport AR we plan to utilize the same mechanisms.

For example, a user wants to download files syn123 that is the subject of the following Passport AR:

 {
    "id":"222"
	"concreteType":"org.sagebionetworks.repo.model.ar.PassportAccessRequirement",
	"conditions":[
		{"conditionIds":["1","4"]}
	]
}

When the UI calls GET /entity/syn123/actions/download with an access token, the service will check if the provided token includes the required visa to meet conditions 1 and 4. For this example, the user’s token includes a visa matching condition 4 but does not have a visa for condition 1. Therefore, the service will return the following:

{
	"actions": [
		{
			"concreteType": "org.sagebionetworks.repo.model.download.MeetAccessRequirement",
			"accessRequirementId": 222
		}
	]
}

This response informs the caller that the user needs to meet the Passport AR with an id=222. In a later section we will cover how client will use this information to request the missing visa.

Combining Passport and Traditional Access Requirements

In order to demonstrate how a new passport ARs will be integrated with ManagedACTAccessRequirement let us consider a new example around a dataset that requires IRB approval to access. For this case we have two groups of researchers that need access the data:

  • Group One - Researchers that have already demonstrated IRB approval to an affiliated institution.

  • Group Two - Individual researchers that have IRB approval but do not belong to an an affiliated institution.

For this use case we would like to setup an access requirement such that the affiliated institution can automatically confirm IRB approval (for group one) or Sage ACT can manually confirm IRB approval (for group two).

Group One

We will assume that the affiliated institution is a trusted GA4GH Visa Issuer. In other words, the affiliated institution’s web services are capable of issuing visas that assert the holder has successful demonstrated IRB approval to access the controlled dataset. Such a visa might look something like this:

{
	"ga4gh_visa_v1": {
		"type": "ControlledAccessGrants",
		"asserted": 1645593544,
		"value": "https://some.institution.org/irb/approval/123/dataset/456",
		"source": "https://some.institution.org",
		"by": "dac"
	}
}

In this example the institution’s ID for the user would be 123, while the ID of the dataset would be 456. We will cover how such a visa would be acquired and and linked to a Synapse User in a later section. For now, assume that researchers from group one, will be able to provide such visa when accessing the dataset in Synapse.

Group Two

For group two we will assume the researchers will need to demonstrate IRB approval to by submitting a traditional request to the Sage ACT. For this case, ACT would need to create a ManagedACTAccessRequirement with isIRBApprovalRequired=true exactly as they do today. Let us assume the ID of this new managed AR is 789. Once a researcher from group two has been approved for AR 789 via the traditional methods, Synapse will be able to issue a new visa for the researcher that asserts this approval. Such a visa might look like this:

{
	"ga4gh_visa_v1": {
		"type": "ControlledAccessGrants",
		"asserted": 1645593544,
		"value": "https://repo-prod.prod.sagebase.org/auth/v1/access/requirment/met/789/user/111",
		"source": "https://repo-prod.prod.sagebase.org/auth/v1",
		"by": "dac"
	}
}

In this example, the Synapse user ID is 111.

Visa Conditions

At this point we have two possible GA4GH visa that both demonstrate the bearer has IRB approval to access a specific dataset. Therefore, we will need to create two visa conditions, one for each, the define we expect to match:

{
	"id": "12",
	"name":"Affiliate IRB approval",
	"type":"ControlledAccessGrants",
	"value":{
		"match-type":"pattern",
		"match-value":"https://some.institution.org/irb/approval/*/dataset/456"
	},
	"source":{
		"match-type":"const",
		"match-value":"https://some.institution.org"
	},
	"by":"dac"
}

and

{
	"id": "13",
	"name":"AR 789 Approval",
	"type":"ControlledAccessGrants",
	"value":{
		"match-type":"pattern",
		"match-value":"https://repo-prod.prod.sagebase.org/auth/v1/access/requirment/met/789/user/*"
	},
	"source":{
		"match-type":"const",
		"match-value":"https://repo-prod.prod.sagebase.org/auth/v1"
	},
	"by":"dac"
}

At this point we are ready to create a new passport access requirement for this use case by combining our two conditions with an “or” as follows:

{
	"concreteType":"org.sagebionetworks.repo.model.ar.PassportAccessRequirement",
	"conditions":[
		{"conditionIds":["12"]},
		{"conditionIds":["13"]}
	]
}

The final step would be to bind this new passport AR to the IRB controlled dataset. This passport visa states that the caller must provide a visa from either the affiliate institution (condition Id=12) or Synapse ACT (condition ID 13).

Note: The Managed AR 789, is not bound directly to the dataset, as doing so, would require that all users meet it. By binding the passport AR to the dataset, users have a choice as to how they demonstrate IRB approval.

Visa Broker

In the previous sections we covered several cases where a user will need to acquire additional visas in order to “meet” Passport ARs bound to data they wish to download. A user might need the following kinds of visas:

  • Visas that are provided by a 3rd party visa broker/issuer.

  • Visas that link 3rd party user identifiers to a Synapse userId.

  • Predefined Synapse visas such as proof of user certification.

  • Visas that demonstrate a user has been approved for a Synapse ManagedACTAccessRequirement.

In order for Synapse to function as a GA4GH passport broker, it will need to be extended such that users can request Passport-Scoped Access Token. These passport scoped access tokens would be an extension of the access tokens issued and consumed by Synapse today. Basically, the resulting passport-scoped access tokens will contain visa that matches each requested visa condition ID.

For example, a client has determined that a user will need a visa for both a Synapse-Verified-User and Synapse-Certified-User. The two predefined visa conditions for these have the IDs 1 and 2 respectively. Assuming the current access token held by the client does not include either of these visas, the client will need to request a new passport-scoped access token that includes them from Synapse.

The following is an example request that the client would make to consent the release of the two necessary visas for POST /oauth2/consent

{
     "clientId": "100002",
     "scope": "openid ga4gh_passport_v1",
     "claims": {
          "userinfo": {
               "is_certified": null,
               "visa_condition_ids": {"values": ["1","2"]},
               "userid": null,
               "email": null
          },
          "id_token": {
               "is_certified": null,
               "visa_condition_ids": {"values": ["1","2"]},
               "userid": null,
               "email": null
          }
     },
     "responseType": "code",
     "redirectUri": "https://foo.bar.com",
     "nonce": "a6cc21bd-163a-4c63-86ac-c1c541fc240f"
}

Notice that the request includes a scope of ga4gh_passport_v1 and also includes the visa condition ID that define the match to the desired visas. If the above request is success full, the resulting access code can then be used to get a new passport-scoped access token that contains the necessary visa by calling: POST /oauth2/token.

For the case where a 3rd party visa broker/issuer will provide the visas, Synapse will need to redirect the caller to the 3rd party services. The following document outlines the details of this redirect: Data Passports. Once, Synapse acquires the 3rd party visas, a new access token will be issued that contains all of the internal and external visas into a single passport.

When a 3rd party issues a visa, the visa should identify the user according to the 3rd party’s identification system. Recall our earlier example where a 3rd party IRB system was providing a visa with the following value:

"value": "https://some.institution.org/irb/approval/123/dataset/456",

In this example, the user’s ID within some.institution.org was 123. However, the same user’s ID within Synapse might be 88. Therefore, we need a mechanism that maps the userId in the visa claim, 123, to the Synapse user 88. The GA4GH specification defines a special visa type LinkedIdentities for such mapping.

Linked Identities

At the time where Synapse acquires a visa from a 3rd party, Synapse will need to issue an additional LinkedIdentities visa that maps 3rd party userId to the user’s Synapse ID. For the example above, the resulting link visa would look like:

 {
	"ga4gh_visa_v1": {
		"type": "LinkedIdentities",
		"asserted": 1645593544,
		"value": "123,https://some.institution.org/irb/approval/;88,https://www.synapse.org/#!Profile:",
		"source": "https://repo-prod.prod.sagebase.org/auth/v1",
		"by": "dac"
	}
}

The above linked visa maps some.institution’s user ID 123 to Synapse user ID 88.

To receive a LinkedIdentities visa, the user needs to demonstrate that they are the holder of both identities.

--GA4GH Passport standard for digital identity and access permissions

Limit Download Context

We have a use cases where a set of files must only be downloaded within a limited context (PLFM-8264). Specifically, a set of files must only be access from a FISMA approved system. In this example, Cavatica has received FISMA approval for their workflow system, while an individual researcher’s laptop has not been approved. In other words, a researcher can access the data via a Cavatica workflow, but the same researcher cannot donwload the same data to their laptop.

Synapse implements the OAuth 2.0 specification which allows users to “login” to Synapse via trusted 3rd party clients. Each time a user logs into Synapse from one of the trusted clients, the resulting access token will include the registered client ID. For our example, let us assume that the registered Cavatica client ID is 33. Note: If the user logs into Synapse using any other client (even the web client), the client ID in the resulting access token will not be 33. We can use this information to solve the limited download context problem.

Let us assume that Synapse can provide a visa that states which client ID was used for authentication. If a user were to authenticate to vial Cavatica client, then such a visa might look like:

{
	"ga4gh_visa_v1": {
		"type": "ControlledAccessGrants",
		"asserted": 1645593544,
		"value": "https://repo-prod.prod.sagebase.org/auth/v1/oauth/client/id/33/user/111",
		"source": "https://repo-prod.prod.sagebase.org/auth/v1",
		"by": "system"
	}
}

If the same user were to login via the Synapse web client, with a client ID of 22, then the same visa might be:

{
	"ga4gh_visa_v1": {
		"type": "ControlledAccessGrants",
		"asserted": 1645593544,
		"value": "https://repo-prod.prod.sagebase.org/auth/v1/oauth/client/id/22/user/111",
		"source": "https://repo-prod.prod.sagebase.org/auth/v1",
		"by": "system"
	}
}

We now have enough information to define a new visa condition for this use case:

{
	"id": "101",
	"name":"OAuth 2.0 Client ID",
	"type":"ControlledAccessGrants",
	"value":{
		"match-type":"pattern",
		"match-value":"https://repo-prod.prod.sagebase.org/auth/v1/oauth/client/id/33/user/*"
	},
	"source":{
		"match-type":"const",
		"match-value":"https://repo-prod.prod.sagebase.org/auth/v1"
	},
	"by":"system"
}

The resulting visa condition ( id=101) states that the client ID must be 33. We are ready to create the new passport AR that will enforce the requirements for this use case when bound to the restricted dataset:

{
	"concreteType":"org.sagebionetworks.repo.model.ar.PassportAccessRequirement",
	"conditions":[
		{"conditionIds":["101"]}
	]
}

Personal Access Tokens

Most Synapse users will use utilize one of the many Synapse web UIs at some point. However, there is a class of Synapse that depend on one of the programmatic clients for their Synapse interactions. This is especially true for Synapse users that write/depend on scripts for automation. However, the GA4GH visa specification is an extension of the OIDC Connect specification with a typical “log in” flow that involves redirecting a browser between various web pages. Since the programmatic clients do not have web pages, an alternate means of authentication is needed.

The recommenced solution to the programmatic client authentication problem is to acquire a Personal Access Token (PAT) using POST /personalAccessToken. A PAT is a special access token that can be created using a web client (that supports redirects), and then saved to a programmatic client’s local credential store. The programmatic client is then free to use the resulting PAT for all calls to Synapse that require authentication.

Since the new passport AR feature will requires clients to present GA4GH visas to access the certain datasets, we will need to extend the current PAT service to allow users to request which visas to include within the generated PAT. Specifically, we will need to extend the AccessTokenGenerationRequest’s OAuthScope to include ga4gh_passport_v1. When included, Synapse will include the GA4GA visas found in the access token provided to create the PAT. Note: Each visa within the resulting PAT will have its own expiration that will almost certainly be shorter than the expiration date of the PAT. A PAT that includes expired visas will still be valid for any call that does not require the visas. Given the short lived nature of GA4GH visas we might want to consider adding a mechanism where a client can “refresh” a PAT and its visas.

New API Objects

org.sagebionetworks.repo.model.ar.Visa

{
	"properties": {
		"type": {
			"description": "Required.  The visa type to be matched.  Note: Custom types are not supported.",
			"$ref": "org.sagebionetworks.repo.model.ar.VisaType"
		},
		"asserted": {
			"description": "Seconds since unix epoch that represents when the Visa Assertion Source made the claim.",
			"type": "integer"
		},
		"value": {
			"description": "A string that represents any of the scope, process, identifier and version of the assertion. The format of the string can vary by the Visa Type.",
			"type": "string"
		},
		"source": {
			"description": "A URL Claim that provides at a minimum the organization that made the assertion. ",
			"type": "string"
		},
		"conditions": {
			"type": "array",
			"description": "A group of one or more ConditionGroup.  There is an 'OR' relationship between each ConditionGroup.",
			"items": {
				"$ref": "org.sagebionetworks.repo.model.ar.ConditionGroup"
			}
		},
		"by": {
			"description": "The level or type of authority within the 'source' organization of the assertion.",
			"$ref": "org.sagebionetworks.repo.model.ar.ByType"
		}
	}
}

org.sagebionetworks.repo.model.ar.VisaCondition

{
	"description": "Defines a match to a single GA4GH passport visa.  See: <a href=\"https://github.com/ga4gh-duri/ga4gh-duri.github.io/blob/master/researcher_ids/ga4gh_passport_v1.md#conditions\">GA4GH passport conditions</a>",
	"properties": {
		"type": {
			"description": "Required.  The visa type to be matched.  Note: Custom types are not supported.",
			"$ref": "org.sagebionetworks.repo.model.ar.VisaType"
		},
		"value": {
			"description": "Optional.  When provided defines an expected 'value' claim.",
			"$ref": "org.sagebionetworks.repo.model.ar.MatchTypeValue"
		},
		"source": {
			"description": "Optional.  When provided defines an expected 'source' claim.",
			"$ref": "org.sagebionetworks.repo.model.ar.MatchTypeValue"
		},
		"by": {
			"description": "Optional.  When provided defines an expected 'by' claim.",
			"$ref": "org.sagebionetworks.repo.model.ar.ByType"
		}
	}
}

org.sagebionetworks.repo.model.ar.VisaType

{
	"description": "Required.  The visa type to be matched.  Note: Custom types are not supported.",
	"type": "string",
	"enum": [
		{
			"name": "AffiliationAndRole"
		},
		{
			"name": "AcceptedTermsAndPolicies"
		},
		{
			"name": "ResearcherStatus"
		},
		{
			"name": "ControlledAccessGrants"
		},
		{
			"name": "LinkedIdentities"
		}
	]
}

org.sagebionetworks.repo.model.ar.ByType

{
	"description": "Required.  The visa type to be matched.  Note: Custom types are not supported.",
	"type": "string",
	"enum": [
		{
			"name": "self"
		},
		{
			"name": "peer"
		},
		{
			"name": "system"
		},
		{
			"name": "so"
		},
		{
			"name": "dac"
		}
	]
}

org.sagebionetworks.repo.model.ar.MatchTypeValue

{
	"description": "Defines both the operation and value for matching a single visa claim.",
	"properties": {
		"type": {
			"description": "Required.  The type defines how value should be matched to a claim.",
			"name": "MatchType",
			"type": "string",
			"enum": [
				{
					"name": "const",
					"description": "A case sensitive full string match."
				},
				{
					"name": "pattern",
					"description": "Supports special meaning characters for matching values.  Use '?' to match any single character, and '*' to match multiple characters"
				},
				{
					"name": "split_pattern",
					"description": "A pattern match on part of a ';' delimited value."
				}
			]
		},
		"value": {
			"description": "The value depends on match type.  For 'const' a match requires a case sensitive full string match of this value.  For 'patterns', use a '?' to match any single character, and '*' to match multiple characters including the empty string and null string.",
			"type": "string"
		}
	}
}

org.sagebionetworks.repo.model.ar.ConditionGroup

{
	"description": "A group of one or more GA4GH visa conditions.",
	"properties": {
		"visaConditions": {
			"description": "A group of one or more VisaCondition.  There is an 'AND' relationship between each VisaCondition.",
			"type": "array",
			"items": {
				"$ref": "org.sagebionetworks.repo.model.ar.VisaCondition"
			}
		}
	}
}

org.sagebionetworks.repo.model.ar.StoredCondition

{
	"extends": {
		"$ref": "org.sagebionetworks.repo.model.ar.VisaCondition"
	},
	"properties": {
		"id": {
			"description": "The unique ID issued to this condition when it was created.",
			"type": "string"
		},
		"name": {
			"description": "A display name for this condition.",
			"type": "string"
		}
	}
}

org.sagebionetworks.repo.model.ar.PassportAccessRequirement

{
	"description": "An Access Requirement type defined by GA4GH passport visa conditions.",
	"implements": [
		{
			"$ref": "org.sagebionetworks.repo.model.AccessRequirement"
		}
	],
	"properties": {
		"conditions": {
			"description": "A group of one or more ConditionIdGroups.  There is an 'OR' relationship between each ConditionIdGroup.",
			"type": "array",
			"items": {
				"$ref": "org.sagebionetworks.repo.model.ar.ConditionIdGroup"
			}
		}
	}
}

org.sagebionetworks.repo.model.ar.ConditionIdGroup

{
	"description": "A group of one or more GA4GH visa condition IDs.",
	"properties": {
		"conditionIds": {
			"description": "A group of one or more condition IDs.  There is an 'AND' relationship between each condition IDs.",
			"type": "array",
			"items": {
				"type": "string"
			}
		}
	}
}

The Passport broker collects the visas from the Visa Issuers, assembles the Passport, and gives it to the data user. When the data user accesses a Passport Clearinghouse, the Passport is included with requests such that the computing environment is made aware that access policies are met and access to the dataset can be permitted.

--GA4GH Passport standard for digital identity and access permissions

A Passport Visa Assertion Repository stores assertions and provides an interface to record and query them. … A Passport Visa Issuer queries the Passport Visa Assertion Repository, formats, and digitally signs assertions in a verifiable GA4GH Passport visa format and makes them available to Passport Brokers.

--GA4GH Passport standard for digital identity and access permissions

To facilitate interoperability of technologies with these processes, NIH has introduced a Passport Broker called Researcher Auth Service (RAS).

--GA4GH Passport standard for digital identity and access permissions

  • No labels