...
| Date | Source | Use Case | Description | Champion | Status |
| 2016-07-05 | DG-BSG call | Alice participates in Bob's Research Study | Patient consent for health research on their data, leveraging GA4GH model data sharing consent form. | Jim? John? | under development |
| 2016-07-14 | DG-BSC call | Certificate Transparency | Certificate Transparency (CT) is an experimental IETF open standard and open source framework for monitoring and auditing digital certificates. This document describes an experimental protocol for publicly logging the existence of Transport Layer Security (TLS) certificates as they are issued or observed, in a manner that allows anyone to audit certificate authority (CA) activity and notice the issuance of suspect certificates as well as to audit the certificate logs themselves. The intent is that eventually clients would refuse to honor certificates that do not appear in a log, effectively forcing CAs to add all issued certificates to the logs. Logs are network services that implement the protocol operations for submissions and queries that are defined in this document. | Former user (Deleted) | potential |
| 2016-07-14 | DG-BSC call | Stellar Consensus Protocol | This paper introduces a new model for consensus called federated Byzantine agreement (FBA). FBA achieves robustness through quorum slices—individual trust decisions made by each node that together determine system-level quorums. Slices bind the system together much the way individual networks’ peering and tran- sit decisions now unify the Internet. | ? | potential |
| 2016-07-14 | DG-BSC call | InterLedger | We present a protocol for payments across payment sys- tems. It enables secure transfers between ledgers and allows anyone with accounts on two ledgers to cre- ate a connection between them. Ledger-provided es- crow removes the need to trust these connectors. Con- nections can be composed to enable payments between any ledgers, creating a global graph of liquidity or Interledger. | ? | potential |
| 2016-08-02 | Email to list | Privacy-Preserving Data Sharing on Blockchain P2P Nodes | Instead of a centralized data processing architecture, the P2P nodes (e.g. in a blockchain) offers the opportunity for data (user data and organizational data) to be stored by these nodes and be processed in a privacy-preserving manner. In this new paradigm of privacy-preserving data sharing, we “move the algorithm to the data” where queries and subqueries are computed by the data repositories (nodes on the P2P network). This means that repositories never release raw data and that they perform the algorithm/query computation locally which produce aggregate answers only. This approach of moving the algorithm to the data provides data-owners and other joint rights-holders the opportunity to exercise control over data release, and thus offers a way forward to provide the highest degree of privacy-preservation while allowing data to still be effectively shared. This paradigm requires that queries be decomposed into one or more subqueries, where each subquery is sent to the appropriate data repository (nodes on the P2P network) and be executed at that repository. This allows each data repository to evaluate received subqueries in terms of “safety” from a privacy and data leakage perspective. Furthermore, safe queries and subqueries can be expressed in the form of a query smart contract (QSC) that legally bind the querier (person or organization), the data repository and other related entities. A query smart contract has been vetted to be safe can even be stored on nodes of the P2P network (e.g. blockchain). This allows Queriers to not only search for useful data (as advertised by the metadata in the repositories) but also search for prefabricated safe QSCs that are available throughout the P2P network that match the intended application. Such a query smart contract will require that identities and authorizations requirements be encoded within the contract. A node on the P2P network may act as a Delegate Node in the completion of a subquery smart contract. A delegate node works on a subquery by locating the relevant data repositories, sending the appropriate subquery to each data repository, and receiving individual answers and collating the results received from these data repositories for reporting to the (paying) Querier. A Delegate Node that seeks to fulfil a query smart contract should only do so when all the conditions of the contract has been fulfilled (e.g. QSC has valid signature; identity of Querier is established; authorization to access APIs at data repositories has been obtained; payment terms has been agreed, etc.). A hierarchy of delegate nodes may be involved in the completion of a given query originating from the Querier entity. The remuneration scheme for all Delegate Nodes and the data repositories involved in a query is outside the scope of the current use-case. | Former user (Deleted) | submitted |
| 2016-08-07 | Email to list | General Wellness Product | FDA report: General Wellness: Policy for Low Risk Devices | John W | submitted |
Use Case Template
We are developing a draft template for use cases, see here.