Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

It seems some in the GA4GH community view passports as being provided to the Clearinghouse by the client, rather than the Clearinghouse retrieving them from Brokers as proposed above. See:

https://docs.google.com/document/d/1T3uYGS2yZflDbLRbG4uxhi8ICqk9C9xWPmJ0DQpFvDU1amOGLwAbKkMSU6up_dHGhsuUF9SVFlllO0qjQSJYuVI/edit#heading=h.5atd0vqkj5vqhttps://docs.google.com/document/d/1amOGLwAbKkMSU6up_dHGhsuUF9SVFlllO0qjQSJYuVI/edit#heading=h.4uzh9l6x5chihh644d5mw17b

In the diagram shown in “Approach 2”, the client (the blue column in the sequence diagram) will receive a userInfo object from the RAS server with a subject ID “paired” to that client by RAS. The Auth server, upon receiving a passport containing that subject ID will not be able to resolve it against the subject IDs it received from RAS. It will not “know” which of its own users the passport represents. The question then is what is required by security compliances standards (HIPAA, FISMA) and Sage Governance with respect to tracking the identity of users who download controlled data.