data-security
data-security copied to clipboard
ga4gh
verifiable consent of visa usage
When considering implementation of the AAI spec, we have a concern that there is no way for a clearinghouse to verify that the user has consented to allow a visa to be used by a broker. As the spec currently stands users who trust a Broker A effectively must trust all other brokers that Broker A trusts and so on down the trust chain. The user has no visibility into or mechanism to limit this.
This addition to the spec hopes to achieve this by adding audiences to Embedded Access Tokens or Embedded Document Tokens. Users can consent to a list of brokers when the tokens are generated. If the audience field does not exist then there is no restriction. How the token issuer knows what list to present to the user is unspecified.
Example embedded access token payload:
{
"iss": "https://<embedded-token-issuer-website>/",
"sub": "<subject-identifier>",
"aud": [
"https://<consented-broker1-website>/",
"https://<consented-broker2-website>/" ...
],
"iat": <seconds-since-epoch>,
"exp": <seconds-since-epoch>,
"jti": <token-identifier>,
"scope": "openid <ga4gh-spec-scopes>",
}
Example access token issued by broker to clearinghouse:
{
"iss": "https://<consented-broker1-website>/",
"sub": "<subject-identifier>",
"iat": <seconds-since-epoch>,
"exp": <seconds-since-epoch>,
"jti": <token-identifier>,
"scope": "openid <ga4gh-spec-scopes>",
}
In this example, the clearinghouse MUST verify that the aud field in the embedded access token payload contains the iss field of the broker access token.
I'd like @cdvoisin to take first pass. Might also be worth having @mikael-linden look and chat...
Looks reasonable. Aud is a common OIDC practice to restrict access token consumers.
Great if Mikael is a thumb, then once Craig says yes we're good to go.
@cdvoisin I think I addressed your comments. Please take another look. Thanks.
@dvoet almost there, just a couple more nits for you to look at. Ping me when ready.
I think adding aud as a claim would be beneficial for a variety of use cases so certainly no objections from me on this PR.
However, this doesn't address consent or verifiable consent at all.
As I understand it, consent is an agreement between the user and an organization or company (a legal entity).
In the proposed flow, the organization needs to obtain the user’s data (their Visa) and parse it in order to verify if the user has consented or not. That’s already too late. The organization should not even have access to the user’s data without knowing that the user has consented. Verification of user consent needs to happen prior to the user’s data being shared.
A key philosophy that we ask across the AAI and Passport, without asking, is "Should a JWT, signed from a trusted source, full of visas from sources that can be checked, sufficient for Authentication?"
It might help us to include things about JWT-only auth, such as that it is assumed that JWT-only auth works in a fairly closed network of sources where it is ensured that the User understands that their JWT might be used be these related downstream systems. These systems are NOT 3rd parties in the traditional sense. Maybe I'll write something and add it to the spec, at least as an explanation.
It is NOT a replacement for OIDC/Oauth but rather an expression of them upstream. It is NOT the intention of AAI/Passports ONLY to "just be OIDC", but rather an alternative. JWT-only auth IS allowed by AAI/Passport provided that risk is appropriately assessed.
Hi @jiaqi216, I've started this PR https://github.com/ga4gh/data-security/pull/41 to make sure that the GA4GH spec explicitly mentions JWT_only auth as a possible, and not recommended, method of auth. I feel, with your feedback, that it was lacking to have an explicit callout.