Versions Compared

Key

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

...

Attending: Colin, Adrian, Marc, Thomas, Jim Hazard, Kathleen,

Went through the bulleted list from Adrian.  Thomas: this list of also what is needed for Smart Contracts (e.g. subject, user, resources, etc). A smart contract has identities of originator, destination (counter-party), dates/durations, conditions (which may depend on external data sources - resources), agreed set of data-feeds (resources), source-authenticity of the data-feeds/sources, even perhaps agreed nodes/platforms to execute the contract, etc.

Adrian: Using a blockchain tech, you can create a UMA without federation. So it becomes a "federation-free" to perform transactions involving personal data.User is running the UMA-AS and signing contracts with hospitals.  The contract control how hospital A shared my data with hospital B. Adrian's assumption is that the AS is a user-owner resource. Two types of contracts: first contract is the registers a resource that has my data with my AS (delegation of authZ).  The second contract is the Hospital A and B.

Adrian's maps the world in 2 phases capturing the 2 constructions of contracts. The first contract is telling the institution "here is my AS and resources under the control of my AS" (bilateral or trilateral).

Kathleen: text sent to Eve/Scott for pre-review.  HL7 has based its work on foundation standards (e.g. access control; privacy; policies, etc). Examples: ISO/IEC 10181. How to use attributes to make access control decisions (e.g. RBAC). Agreements on security and privacy policies. Not a full trust framework, but more on federated authentication: how 2 or more domains establish trust. How to expand from narrow to wide ecosystem: how to move away from centralized model to a direct trust model (e.g. using Stellar consensus model). How to express this trust in smart-contracts. So that if data "falls-off" or "escapes" that you can no longer use that data. How does the RP check claims etc in a direct (non-centralized) model.

Adrian: important to express difference between the federated model vs the blockchain model.  The Federated model is able to get hospital A and B to share data about User without immediate consent from the User.  Adrian thinks we need 2 contracts. Here is the UMA-AS is acting as the agent of the RO (resource owner). The RO does not need to be present 24x7.  The issues:  are the policies visible to external entities. In Adrian's case, the policies are never visible.

Kathleen: in this case, the AS will honor whoever is able to prove trust. So the 2 models are compatible. The access policies are not necessarily visible.

 

Thursday, October 6

Agenda:

...