You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This sub-problem involves reaching consensus on what information is communicated between client, DRS service, and Passport broker at each API call, and how this information is structured.
Questions include:
What IDs are passed in the API calls?
Will full URLs scale; should identifiers or paths with factored out base URIs be used instead?
Should non-URI IDs be used to identify objects in all places, or should we allow URIs as well?
How about support for plain OAuth2?
Do we require that this process make use of passport brokers, or do we generalize to allow OAuth2 authorization servers as well?
How and where are visa requirements communicated?
Should a DRS server tell a client what visas it should request from a broker? OR...
Should a client tell a broker what DRS objects it wants to authorize for, and let the broker resolve the required visas?
Should the client be sending DRS objects to the broker, or should the client be told which visas to request?
The text was updated successfully, but these errors were encountered:
A sub-problem of the DRS + Passports Design Resolution epic.
This sub-problem involves reaching consensus on what information is communicated between client, DRS service, and Passport broker at each API call, and how this information is structured.
Questions include:
The text was updated successfully, but these errors were encountered: