DRS + Passports client role and capabilities

[jb-adams]

A sub-problem of the DRS + Passports Design Resolution epic.

This sub-problem involves reaching consensus on what a DRS/Passport-aware client should be able to do to facilitate this flow. It also involves what information needs to be communicated to the client from the service.

Questions include:

• Where do we need to support handling passports that are too large for headers?
  • For some requests, an Authorization header may suffice, BUT we know some passport access tokens may be too large for headers
  • Should large passport tokens be passed in the request body and sent via POST request?
• How can we make the supported flows/capabilities self-describing in DRS?
  • If the DRS service supports OAuth2 bearer tokens, embedded passport access tokens, root passport access tokens, or some combination thereof, where is this communicated to client? Can/should this go in service-info?
• Can we support OAuth and passports?
  • Should we leverage an existing OAuth flow to do the token downscoping?
  • Can we self-describe so a client can discover which kind of flow a DRS server supports?

[briandoconnor]

The Broad team reached out to me to ask about adding key/values to a DRS response to make it clear what auth mechanism to use for that resources.

[mattions]

@briandoconnor this exactly the same problem I wanted to discuss in the Cloud Workstream meeting.

I think we need to add an authorization key to DRS, which points maybe to the iss, and provides type: ga4gh_passport maybe, so we can differentiate in case we have several DRS object, from the same server, with multiple authorization mechanism