Add task-specific token functionality to v2.0 draft

[andrew-gearhart]

No description provided.

[github-actions]

Branch URL: https://ga4gh.github.io/data-security/2.0-draft-agearh-tst/

[andrew-gearhart]

A few open questions to be discussed:

• Should downstream services be able to exchange the original Client/RP TST for another TST? This is in the draft spec at the moment, but the consent infrastructure isn't (although mentioned in the RAR commentary).
• How does this feature align with the the "Passport-Lite" concept?
• Is it worth even mentioning DPoP and RAR in this draft specification, or just queue them as internal issues for future development?
• As written, the draft mentions that a passport-scoped access token is exchanged for a TST and TSTs can be exchanged for another TST (if permitted). This implies that (1) receivers of a passport can't exchange it for a TST, and (2) holders of a TST can't obtain a full passport (although they can introspect to get a set of in-scope Visas). Is this as intended?
• What scenarios should be prototyped to explore the behavior and implications of this new feature?
• Can we eliminate the "Visas provided by /userinfo" capability? Is this just legacy?

[github-actions]

Branch URL: https://ga4gh.github.io/data-security/2.0-draft-agearh-tst/

[github-actions]

Branch URL: https://ga4gh.github.io/data-security/2.0-draft-agearh-tst/

[andrew-gearhart]

Decided to remove mention of DPoP and RAR from this version of the specification as well as the high-level implementation discussion--this text has been dumped into the TST issue #122 for the time being.

[github-actions]

Branch URL: https://ga4gh.github.io/data-security/2.0-draft-agearh-tst/

[github-actions]

Branch URL: https://ga4gh.github.io/data-security/2.0-draft-agearh-tst/

[andrew-gearhart]

Major issue that needs to be resolved:

• audience/resource is only being validated by the Broker when a service performs an introspection request. In other words, being in audience/resource is really permission to do some type of introspection. Should there be separate permissions for services that can simply validate the TST, and those that can retrieve Visas?
• If a TST is essentially “pass through” to a backend service (like DRS), how to handle situations like API-specific tokens to access a specific WES server? Otherwise, one is assuming either (1) no authorization to access orchestration intermediaries, or (2) the TST is needed to make an access decision, and the service is actually an authorization consumer.
• These API tokens would be in the header as the bearer token, not the TST. Creating a custom TST header would involve changing the downstream API specifications for WES, TES, etc.
  • Is the presence of a TST as the bearer token sufficient to imply that the service is an authorization consumer
  • Tom: AAI spec shouldn’t require any changes to the downstream API
  • What about a proxy or sidecar that is wrapping WES, and another that is wrapping TES?