Latest revision as of 20:22, 5 August 2017

Trust Label Purpose

Trust codes are required to meet stakeholder use case for a discoverable and computable set of metadata to convey asserted trust attributes of an exchange partner.
“When you vote, have you ever wondered whether your ballot is actually counted? If you meet someone online,how do you know they are who they say they are? When you

buy coffee that’s labeled “fair trade,” what makes you so certain of its origin? To be sure, really sure, about any of those questions you’d need a system where records of all kinds could be stored, facts could be verified by anyone, and security is guaranteed. If you were worried someone might cheat this system by editing records, you could even share them with many people and make sure everyone agrees they haven’t changed. These systems are on the horizon, and the underlying software technology powering them is called the blockchain.” Institute for the Future [IFTF Blockchain Lab]

Data Subject Centric Trust

Consumer Oriented TF4FA

Current Trust Frameworks are static; once established, these are very hard to change. Static Trust Frameworks are typically oriented to those who control information and value flows. Consumers seem to have little or no voice in these Trust Framework Trust Policy, or the resulting Trust Recipient or Trust Relying Party Agreements.

Should the HL7 TF4FA be more encompassing of healthcare consumers as parties in the negotiation of Trust Frameworks for Federated Authorization with counterparties with which they can share health information on terms that consumers find more attractive in some way - e.g., for more control of their information's privacy and security, or even for compensation for use of their health information?

Enabling healthcare consumers to negotiate more equitable trust framework will require changing the balance of power where custodians "own" the consumer's health information. Patient Right of Access is disrupting that paradigm. It may be that providers and EHR vendors will see an advantage in supporting PRA as a means to off-load breach liability and consent management, and by simply duplicating patient information in a server accessible to patients for view, download, and transmit, they are able to avoid EHR security issues, although they still have responsibility for the security of a PRA store.

At the same time as custodians are seeing advantages, so are secondary users of patient information. PRA is attractive in that it reduces friction resulting from meeting data sharing requirements of custodians. At this juncture however, these secondary users seem somewhat inclined to negotiate with the consumers that are now supplying them with patient information.

As this new mode of sharing health information scales, healthcare consumers' market place clout to demand more control will increase. With user friendly trust negotiation technologies, we can imagine many healthcare consumers with 0..* trust domains, and 0..* privacy preferences, and security and trust risk tolerances having more and more health information consumers with which to bargain for their best trust contract deal.

HL7 TF4FA could serve as the conceptual model for the healthcare consumer trust negotiation technologies needed to enable this emerging market.

Kantara Initiative Blockchain Smart Contract Discussion Group Report

Report from the Blockchain and Smart Contracts Discussion Group to the Kantara Initiative

Introduction Privacy is broadly recognized as a human right (see Article 12 of the Universal Declaration of Human Rights and A Typology of Privacy). Most OECD countries have put in place some form of overarching data protection regime for the purpose of protecting rights to privacy and embed these rights in a framework that helps guide local jurisdictions when balancing privacy rights between and among individuals as well as privacy rights of the individual against other rights. Examples of other rights include property rights in various information embodiments, rights relating to records and/or data, intellectual property rights, national security, and various other forms of legal, social or economic rights. The nature of the rights and the balance varies from country to country and sometimes within jurisdictions.

Blockchain and smart contract implementations usually depend on the use of data that can be used to identify an individual and other data that is considered to be “personal data”. Such implementations should recognize and be protective of privacy rights. Given the rapidly increasing popularity of these technologies, the first motivation for the DG’s inquiry is to analyze the implications for them in empowering individuals and protecting privacy, and offer observations and recommendations to the Kantara community.

The second motivation is to analyze the use of such technologies to build special-purpose identity and/or personal data solutions in which individuals and organizations can interact more equitably and efficiently, and observe whether these goals are being met.

This report from the group offers recommendations and observations to Kantara Initiative covering the following scope: ● Solving use cases for empowering traditionally disempowered parties (such as individuals)... ● taking part in transactions (such as entering into contracts and information-sharing agreements)... ● with parties that traditionally hold greater power (such as companies and countries)... ● in the context of distributed technologies and techniques (such as blockchain and smart contracts)... ● and their application to identity and identity-related systems (both in the course of conducting business/legal transactions and to solve digital identity use cases). A recurring theme in digital identity communities ("user-centricity") as well as in blockchain communities ("disintermediation") is the question of balancing control between individuals and others – to enable disempowered entities to interact with such others as a "peer" in various contexts. Power imbalances manifest in many forms, and are embodied in many cultural and social artifacts. For example, legal “contracts of adhesion" (a standard-form, take-it-or-leave-it contract) can constrain an individual’s ability to negotiate terms such as in settings where individuals seek services from large third-party outsourcing services networks. The proponents of those systems assert the expediency of scale in support of the rigidity of terms, but individuals are left with a situation where economic compulsion of their dependency on the service can undermine their leverage and hence their ability to protect their individual rights. Key aspects of this imbalance as reflected in large-standard contract settings include: ● Lack of granularity: The less-empowered party must accept a totality of trust and liability, rather than a smaller apportionment. ● Absence of dynamism: The less-empowered party must accept the contract in its entirety at the inception of the relationship and can't change the parameters now or in future. ● No market choice: The less-empowered party is economically compelled to accept an offer due to limits on available alternatives. ● Inadequate transparency: The less-empowered party does not have the means to verify that the other party is acting as promised. There are several interweaving themes in the various public discussions occurring today in the context of blockchain technology and its promise. ● Centralization vs. decentralization: ○ The term “decentralization” is typically used in the context of computing system architectures to mean entities (e.g. nodes) that have equal power or privilege. It usually denotes the degree of control over the outcome of a computing instance. ○ Examples of prior “decentralized” architectures includes the PGP system for public keys based on a “flat” web of trust (in contrast to traditional X.509 certificate hierarchies). ○ For blockchains, the term “decentralization” typically refers to the equal privilege each node (e.g. mining node) possesses in performing transaction processing.

● Distributed vs decentralized: ○ The term “distributed” in the context of computing system architectures is often used to denote the topological design of the system, which are usually multi-component (multi-site) configuration computing systems. A centralized system can be implemented using a distributed topology, where control resides within one or few parties. ○ For blockchains, the term “distributed” is typically applied to refer to the agreement process (consensus-making algorithm) used by nodes in the P2P network to arrive at the same picture of the state of the shared ledger. ○ Discussion of dictatorship vs. democracy as it relates to blockchain

● Trust and distrust: ○ The term “trust” in computing system architectures denotes acceptance of the entity performing computations on behalf of the user, based on clear design and correct implementation of the computation mechanisms (e.g. computing sandbox free from interference), leading to the term technical trust (see the Terminology section). ○ In blockchain conversations, the term “trustless” is often used incorrectly to mean that nodes and users do not have to rely on a centralized authority. However, technologies that make use of technical trust mechanisms are part of the blockchain proposition.

● Power and disempowerment: ○ Not every solution built using blockchain technology is intended to empower or enfranchise individuals, but many are. The mechanisms for empowerment may differ: anonymization, tracking transactions with others, and so on. ○ On the other hand, some solutions built using blockchain technology targeted to be used by parties on the other side of the equation could potentially disempower individuals further if used in service of human identity “provenance and fraud detection” (see the Terminology section), much in the way they are being examined for provenance and fraud detection of luxury goods, diamonds, and similar items.

● Humans and machines for contracts (identities and parties)

Example of sites discussing TF4FA

THEWS presentation at Madrid WGM May 2017

During the Security Madrid WGM Tuesday May 9, 2017 opening session, Dr. Blobel presented on THEWS Trusted eHealth and eWelfare Space - Report on current work: trust calculation and informed trust decisions. His HL7 WGM Madrid 2017_THEWS Project presentation is of particular interest to the Security WG as it is a pilot project in Finland to establish a run time trust contract between data subjects, e.g., patients, and data collectors, e.g., provider EHRs, HIEs, Apps. The Finnish pilot epitomizes the type of implementation that the TF4FA specification seeks to enable using HL7 standards for computable security, privacy, consent, and provenance policies encoded as trust contracts between parties in an interoperable information exchange.
HL7 WGM Madrid 2017_THEWS Project

Trust Library

HL7 Security WG Trust Work

Trust Frameworkby Alex Mense, HL7 Security cochair

Block Chaining

Blockchain in Healthcare Presentation by Mike Davis, VHA Security Architect - Provides an overview of current thinking on using block chaining for healthcare provenance and trust.

Chris Shawn, VA Senior Security Analyst - Potential Pros and Cons, which healthcare should analyze before committing to Healthcare Block Chaining

Pros

Anonymity. Block chaining leverages anonymous users, which may be of workable in the private-sector health care space.
Digital Signature: Block chains are digitally signed and timestamped, providing incontrovertible evidence that the transaction occurred but not necessarily who executed the transaction.

PKI. Doesn’t require robust public key infrastructure to support exchange among different security domains. *Provenance. Provides integrity across multiple users that may be of benefit in health care to preserve provenance, as opposed to digital signatures that are susceptible to data alteration at each waypoint and/or user. According to Chris, this feature is probably block chaining’s greatest strength as opposed to digital signatures.

Integrity. Overall stronger integrity controls than digital signatures alone cryptographically and as noted above.

Cons

Lack of trusted endpoints. User anonymity impedes establishment of trust. While this is a desirable state in a use case such as Bitcoin, and may even be workable in the private-sector health care space, the lack of trusted endpoints would likely prove problematic in the federal space. Though block chaining provides desirable integrity controls (e.g., provenance preservation) some add on functionality would likely be needed to address user trust. According to Chris, this is probably block chaining’s greatest weakness as opposed to digital signatures – specifically for federal agencies.
Non-Repudiation. Block chaining does provide non-repudiation. Transactions are signed and time stamped. But the private key used to sign the transaction is bound to an address. The purpose of signing in this context is to provide non-repudiation that the transaction occurred, not necessarily to the executor of the transaction. This is how block chaining can preserve (to some extent) anonymity. True identity behind an address may not be not verifiable in the absence of some trust framework. And in the case of Bitcoin, Bitcoin.org actually encourages people to use an address only once and to use multiple wallets to preserve anonymity:
- “To protect your privacy, you should use a new Bitcoin address each time you receive a new payment. Additionally, you can use multiple wallets for different purposes. Doing so allows you to isolate each of your transactions in such a way that it is not possible to associate them all together. People who send you money cannot see what other Bitcoin addresses you own and what you do with them. This is probably the most important advice you should keep in mind.” https://bitcoin.org/en/protect-your-privacy
No native confidentiality controls. Block chain does not provide confidentiality as it is an open system. Of course, digital signatures in and of themselves do not provide for confidentiality but encryption across security domains can be implemented with public key certificates. As noted above, some add on functionality would likely be needed to address confidentiality that could be as simple as TLS depending on the use case.

Kantara Blockchain & Smart Contract

MedRec

A Case Study for Blockchain in Healthcare: “MedRec” prototype for electronic health records and medical research data

Blockchain

Is Blockchain the Answer to Healthcare’s Big Data Problems?

bitcoin a peertopeer electonic cast system satoshi nakamoto

Can Trust-Based Private Blockchains Be Trusted?

RSA 2016 Block Chain Presentations

RSA2016 - The Future of Bitcoin and Cryptocurrencies by Bart Preneel
RSA 2016 Dissecting Bitcoin Security

Cassio Goldschmidt

What is Proof of Existence

What is proof of existence? Use our service to anonymously and securely store an online distributed proof of existence for any document. Your documents are NOT stored in our database or in the bitcoin blockchain, so you don't have to worry about your data being accessed by others.
All we store is a cryptographic digest of the file, linked to the time in which you submitted the document. In this way, you can later certify that the data existed at that time. This is the first online service allowing you to publicly prove that you have certain information without revealing the data or yourself, with a decentralized certification based on the bitcoin network.
The key advantages are anonymity, privacy, and getting a decentralized proof which can't be erased or modified by anyone (third parties or governments). Your document's existence is permanently validated by the blockchain even if this site is compromised or down, so you don't depend or need to trust any central authority. All previous data timestamping solutions lack this freedom.

Proof-of-work 'paradigm shift'

Let us digress for a moment to a prior argument in order to elucidate the immense paradigm shift that proof-of-work delivers in the form of a trustless environment. Many would argue that cheating by, or collusion amongst, regulated parties is an illegal act with associated and significant deterrent costs which are sufficient to enforce the rules.
As evidenced above, we know this line of reasoning to be faulty. The reason for this is because when practicably employed, traditional deterrents generate both a non-deterministic and dynamic environment whereby deterrent costs inevitably become cost/benefit estimations – that is, zero cost for successful evasions versus more money due at some future point in time for unsuccessful cheating.
Contrary to the traditional deterrents approach, proof-of-work is entirely deterministic, whereby parties know the cost of cheating and collusion and must decide to pay this cost upfront.
If efficiency is greatest when the countermeasures are most expensive and immediate, then proof-of-work in the context of a distributed ledger and the trustless environment it helps to generate is a massive paradigm shift that is foundationally new and revolutionary.
It should be apparent by now that trust-based systems are merely unsecure and non-empirical software 'workarounds' (if you can even call them that) to the provision of a real security work-product, proof-of- work. In addition, it should be equally apparent that the arguments in support of workarounds to proof-of-work arise, not from a wisdom that it is prudent to build a distributed ledger without proof-of-work, but rather they arise solely from the historical inability to attain proof-of-work in an economical way.
It should also be obvious from the discussion that the proof-of-work protocol is factually the underlying key to unlocking the huge paradigm shift and efficiency of distributed-ledger blockchain technology – no traditional deterrents and countermeasures required – there really is no other viable alternative.

Incorporating the proof-of-work protocol into private blockchain technology taps directly into the immense efficiency of the bitcoin blockchain paradigm shift. Without it, all you've built is an old-fashioned (and inefficient) distributed database.

CommonAccord Provenance Blockchain

Problem: No mechanism to track provenance of digital contracts exchanged between machines No method for verifying non-repudiation beyond digital e-signatures on contracts Weak method to sharing versions of contracts among negotiating parties Solution: Enhance CommonAccord architecture with hash-chains for tracking state of negotiated contracts Publish hash-chains to ledger (public or private) Provide mechanism for parties to access private repositories containing contracts Legal documents are mostly handled as text blobs, in a complex, semi-proprietary format. Authoring, reviewing, sharing, managing are all difficult. Establishing provenance is often impossible The impact is delay, cost, risk, fear, imbalance, and a systemic advantage for large actors Data Model and Version Tracking:

Data model expresses contracts in modular parts
GitHub model for change mgmt & version tracking
Parties check-out contract into private repositories

Access control to contracts and metadata:

UMA model for access control to private repositories
Parties access repo, do changes, send Metadata
Each change generates hash-points in doc hash-tree

Ledger system:

Captures current state of contracts exchange/flow
Hash of Metadata added to ledger
Can use today’s Blockchain or future technology

Is Blockchain the Answer to Healthcare’s Big Data Problems?

bitcoin a peertopeer electonic cast system satoshi nakamoto

Can Trust-Based Private Blockchains Be Trusted?

What is Proof of Existence

What is proof of existence? Use our service to anonymously and securely store an online distributed proof of existence for any document. Your documents are NOT stored in our database or in the bitcoin blockchain, so you don't have to worry about your data being accessed by others.
All we store is a cryptographic digest of the file, linked to the time in which you submitted the document. In this way, you can later certify that the data existed at that time. This is the first online service allowing you to publicly prove that you have certain information without revealing the data or yourself, with a decentralized certification based on the bitcoin network.
The key advantages are anonymity, privacy, and getting a decentralized proof which can't be erased or modified by anyone (third parties or governments). Your document's existence is permanently validated by the blockchain even if this site is compromised or down, so you don't depend or need to trust any central authority. All previous data timestamping solutions lack this freedom.

Proof-of-work 'paradigm shift'

Let us digress for a moment to a prior argument in order to elucidate the immense paradigm shift that proof-of-work delivers in the form of a trustless environment. Many would argue that cheating by, or collusion amongst, regulated parties is an illegal act with associated and significant deterrent costs which are sufficient to enforce the rules.
As evidenced above, we know this line of reasoning to be faulty. The reason for this is because when practicably employed, traditional deterrents generate both a non-deterministic and dynamic environment whereby deterrent costs inevitably become cost/benefit estimations – that is, zero cost for successful evasions versus more money due at some future point in time for unsuccessful cheating.
Contrary to the traditional deterrents approach, proof-of-work is entirely deterministic, whereby parties know the cost of cheating and collusion and must decide to pay this cost upfront.
If efficiency is greatest when the countermeasures are most expensive and immediate, then proof-of-work in the context of a distributed ledger and the trustless environment it helps to generate is a massive paradigm shift that is foundationally new and revolutionary.
It should be apparent by now that trust-based systems are merely unsecure and non-empirical software 'workarounds' (if you can even call them that) to the provision of a real security work-product, proof-of- work. In addition, it should be equally apparent that the arguments in support of workarounds to proof-of-work arise, not from a wisdom that it is prudent to build a distributed ledger without proof-of-work, but rather they arise solely from the historical inability to attain proof-of-work in an economical way.
It should also be obvious from the discussion that the proof-of-work protocol is factually the underlying key to unlocking the huge paradigm shift and efficiency of distributed-ledger blockchain technology – no traditional deterrents and countermeasures required – there really is no other viable alternative.

Incorporating the proof-of-work protocol into private blockchain technology taps directly into the immense efficiency of the bitcoin blockchain paradigm shift. Without it, all you've built is an old-fashioned (and inefficient) distributed database.

CommonAccord Provenance Blockchain

Problem: No mechanism to track provenance of digital contracts exchanged between machines No method for verifying non-repudiation beyond digital e-signatures on contracts Weak method to sharing versions of contracts among negotiating parties Solution: Enhance CommonAccord architecture with hash-chains for tracking state of negotiated contracts Publish hash-chains to ledger (public or private) Provide mechanism for parties to access private repositories containing contracts Legal documents are mostly handled as text blobs, in a complex, semi-proprietary format. Authoring, reviewing, sharing, managing are all difficult. Establishing provenance is often impossible The impact is delay, cost, risk, fear, imbalance, and a systemic advantage for large actors Data Model and Version Tracking:

Data model expresses contracts in modular parts
GitHub model for change mgmt & version tracking
Parties check-out contract into private repositories

Access control to contracts and metadata:

UMA model for access control to private repositories
Parties access repo, do changes, send Metadata
Each change generates hash-points in doc hash-tree

Ledger system:

Captures current state of contracts exchange/flow
Hash of Metadata added to ledger
Can use today’s Blockchain or future technology

DirectTrust

Federal Trust Bundle

GTRI - IDESG

NATE

ONC

ONC Governance Framework Trusted EHIE

State Health Information Exchange Cooperative Agreement Program Guidance on Privacy and Security Frameworks

This guidance addresses the core domains of the Nationwide Privacy and Security Framework for Electronic Exchange of Individually Identifiable Health Information2, built from the fair information practice principles (FIPPs) that have guided privacy and security efforts worldwide for decades: 1. Individual access 2. Correction 3. Openness and transparency 4. Individual choice 5. Collection, use and disclosure limitation 6. Data quality and integrity 7. Safeguards 8. Accountability State HIE Cooperative Agreement Program recipients should use the following guidance to evaluate their current privacy and security policies and practices and determine if alignment gaps exist. State policy makers and other stakeholders can use the guidance to determine, assess and fill gaps in current policies and practices to assure trusted health information exchange. The guidance outlines a core set of privacy and security expectations that should be consistently applied, but it is not exhaustive. Recipients will have additional policies and requirements that are critical to their efforts.

NATIONAL STRATEGY FOR TRUSTED IDENTITIES IN CYBERSPACE Appendix A – Fair Information Practice Principles (FIPPs)

Fair Information Practice Principles To truly enhance privacy in the conduct of online transactions, Fair Information Practice Principles (FIPPs) must be universally and consistently adopted and applied in the Identity Ecosystem. FIPPs are the widely accepted framework of defining principles to be used in the evaluation and consideration of systems, processes, or programs that affect individual privacy.1 In brief, the Fair Information Practice Principles are:  Transparency: Organizations should be transparent and notify individuals regarding collection, use, dissemination, and maintenance of personally identifiable information (PII).  Individual Participation: Organizations should involve the individual in the process of using PII and, to the extent practicable, seek individual consent for the collection, use, dissemination, and maintenance of PII. Organizations should also provide mechanisms for appropriate access, correction, and redress regarding use of PII.  Purpose Specification: Organizations should specifically articulate the authority that permits the collection of PII and specifically articulate the purpose or purposes for which the PII is intended to be used.  Data Minimization: Organizations should only collect PII that is directly relevant and necessary to accomplish the specified purpose(s) and only retain PII for as long as is necessary to fulfill the specified purpose(s).  Use Limitation: Organizations should use PII solely for the purpose(s) specified in the notice. Sharing PII should be for a purpose compatible with the purpose for which the PII was collected.  Data Quality and Integrity: Organizations should, to the extent practicable, ensure that PII is accurate, relevant, timely, and complete.  Security: Organizations should protect PII (in all media) through appropriate security safeguards against risks such as loss, unauthorized access or use, destruction, modification, or unintended or inappropriate disclosure.  Accountability and Auditing: Organizations should be accountable for complying with these principles, providing training to all employees and contractors who use PII, and auditing the actual use of PII to demonstrate compliance with these principles and all applicable privacy protection requirements. Universal application of FIPPs provides the basis for confidence and trust in online transactions. 1 Rooted in the United States Department of Health, Education and Welfare's seminal 1973 report, “Records, Computers and the Rights of Citizens” (1973), these principles are at the core of the Privacy Act of 1974 and are mirrored in the laws of many U.S. states, as well as in those of many foreign nations and international organizations. A number of private and not-for-profit organizations have also incorporated these principles into their privacy policies.

National HIE Governance Forum Trust Framework for Health Information Exchange Trust Framework for HIE

A framework for governing entities and their participants to share trust attributes to support exchange with a group of unaffiliated entities. December 2013. This report was prepared under the auspices of the National eHealth Collaborative through its cooperative agreement with the Office of the National Coordinator for Health Information Technology, U.S. Department of Health and Human Services.

THEWS

Trust Label Harmonization Proposal

Health Blockchain Publications

ONC announces Blockchain challenge winners Note that links to winner's submissions no longer work so search for title in a browser.
Blockchain: Securing a New Health Interoperability Experience Accenture
ONC NIST Blockchain Workshop Accenture presentation
ONC NIST Blockchain Workshop Accenture presentation 2

Back to Security Main Page

Difference between revisions of "Trust Label"

Latest revision as of 20:22, 5 August 2017

Contents

Trust Label Purpose

Data Subject Centric Trust

Consumer Oriented TF4FA

Kantara Initiative Blockchain Smart Contract Discussion Group Report

Example of sites discussing TF4FA

THEWS presentation at Madrid WGM May 2017

Trust Library

HL7 Security WG Trust Work

Block Chaining

Kantara Blockchain & Smart Contract

MedRec

Blockchain

RSA 2016 Block Chain Presentations

DirectTrust

Federal Trust Bundle

GTRI - IDESG

NATE

ONC

THEWS

Trust Label Harmonization Proposal

Health Blockchain Publications

Navigation menu

Personal tools

Namespaces

Variants

Views

More

Search

Navigation

groups

meetings

general

Tools

@@ Line 1: / Line 1: @@
 [[Security|Back to Security Main Page]]
 ==Trust Label Purpose==
-Trust codes are required to meet stakeholder use case for a discoverable and computable set of metadata to convey asserted trust attributes of an exchange partner.
+*Trust codes are required to meet stakeholder use case for a discoverable and computable set of metadata to convey asserted trust attributes of an exchange partner.
+*“When you vote, have you ever wondered whether your ballot is actually counted? If you meet someone online,how do you know they are who they say they are? When you
+buy coffee that’s labeled “fair trade,” what makes you so certain of its origin? To be sure, really sure, about any of those questions you’d need a system where records of all
+kinds could be stored, facts could be verified by anyone, and security is guaranteed. If you were worried someone might cheat this system by editing records, you could even share
+them with many people and make sure everyone agrees they haven’t changed. These systems are on the horizon, and the underlying software technology powering them is called
+the blockchain.”
+[http://www.iftf.org/fileadmin/user_upload/downloads/blockchain/IFTF_BlockchainFuturesLab_2016.pdf Institute for the Future [IFTF] Blockchain Lab]
+==Data Subject Centric Trust==
+==Consumer Oriented TF4FA==
+Current Trust Frameworks are static; once established, these are very hard to change. Static Trust Frameworks are typically oriented to those who control information and value flows. Consumers seem to have little or no voice in these Trust Framework Trust Policy, or the resulting Trust Recipient or Trust Relying Party Agreements.
+Should the HL7 TF4FA be more encompassing of healthcare consumers as parties in the negotiation of Trust Frameworks for Federated Authorization with counterparties with which they can share health information on terms that consumers find more attractive in some way - e.g., for more control of their information's privacy and security, or even for compensation for use of their health information?
+Enabling healthcare consumers to negotiate more equitable trust framework will require changing the balance of power where custodians "own" the consumer's health information. Patient Right of Access is disrupting that paradigm. It may be that providers and EHR vendors will see an advantage in supporting PRA as a means to off-load breach liability and consent management, and by simply duplicating patient information in a server accessible to patients for view, download, and transmit, they are able to avoid EHR security issues, although they still have responsibility for the security of a PRA store.
+At the same time as custodians are seeing advantages, so are secondary users of patient information. PRA is attractive in that it reduces friction resulting from meeting data sharing requirements of custodians. At this juncture however, these secondary users seem somewhat inclined to negotiate with the consumers that are now supplying them with patient information.
+As this new mode of sharing health information scales, healthcare consumers' market place clout to demand more control will increase. With user friendly trust negotiation technologies, we can imagine many healthcare consumers with 0..* trust domains, and 0..* privacy preferences, and security and trust risk tolerances having more and more health information consumers with which to bargain for their best trust contract deal.
+HL7 TF4FA could serve as the conceptual model for the healthcare consumer trust negotiation technologies needed to enable this emerging market.
+==Kantara Initiative Blockchain Smart Contract Discussion Group Report==
+*[http://gforge.hl7.org/gf/project/security/docman/HL7%20Trust/Block%20Chaining/Kantara%20Blockchain%20Smart%20Contract%20Report.docx Report from the Blockchain and Smart Contracts Discussion Group to the Kantara Initiative]
+Introduction
+Privacy is broadly recognized as a human right (see Article 12 of the Universal Declaration of Human Rights and A Typology of Privacy). Most OECD countries have put in place some form of overarching data protection regime for the purpose of protecting rights to privacy and embed these rights in a framework that helps guide local jurisdictions when balancing privacy rights between and among individuals as well as privacy rights of the individual against other rights. Examples of other rights include property rights in various information embodiments, rights relating to records and/or data, intellectual property rights, national security, and various other forms of legal, social or economic rights. The nature of the rights and the balance varies from country to country and sometimes within jurisdictions.
+Blockchain and smart contract implementations usually depend on the use of data that can be used to identify an individual and other data that is considered to be “personal data”. Such implementations should recognize and be protective of privacy rights. Given the rapidly increasing popularity of these technologies, the first motivation for the DG’s inquiry is to analyze the implications for them in empowering individuals and protecting privacy, and offer observations and recommendations to the Kantara community.
+The second motivation is to analyze the use of such technologies to build special-purpose identity and/or personal data solutions in which individuals and organizations can interact more equitably and efficiently, and observe whether these goals are being met.
+This report from the group offers recommendations and observations to Kantara Initiative covering the following scope:
+●	Solving use cases for empowering traditionally disempowered parties (such as individuals)...
+●	taking part in transactions (such as entering into contracts and information-sharing agreements)...
+●	with parties that traditionally hold greater power (such as companies and countries)...
+●	in the context of distributed technologies and techniques (such as blockchain and smart contracts)...
+●	and their application to identity and identity-related systems (both in the course of conducting business/legal transactions and to solve digital identity use cases).
+A recurring theme in digital identity communities ("user-centricity") as well as in blockchain communities ("disintermediation") is the question of balancing control between individuals and others – to enable disempowered entities to interact with such others as  a "peer" in various contexts. Power imbalances manifest in many forms, and are embodied in many cultural and social artifacts.  For example, legal “contracts of adhesion" (a standard-form, take-it-or-leave-it contract) can constrain an individual’s ability to negotiate terms such as in settings where individuals seek services from large third-party outsourcing services networks.  The proponents of those systems assert the expediency of scale in support of the rigidity of terms, but individuals are left with a situation where economic compulsion of their dependency on the service can undermine their leverage and hence their ability to protect their individual rights. Key aspects of this imbalance as reflected in large-standard contract settings include:
+●	Lack of granularity: The less-empowered party must accept a totality of trust and liability, rather than a smaller apportionment.
+●	Absence of dynamism: The less-empowered party must accept the contract in its entirety at the inception of the relationship and can't change the parameters now or in future.
+●	No market choice: The less-empowered party is economically compelled to accept an offer due to limits on available alternatives.
+●	Inadequate transparency: The less-empowered party does not have the means to verify that the other party is acting as promised.
+There are several interweaving themes in the various public discussions occurring today in the context of blockchain technology and its promise.
+●	Centralization vs. decentralization:
+○	The term “decentralization” is typically used in the context of computing system architectures to mean entities (e.g. nodes) that have equal power or privilege. It usually denotes the degree of control over the outcome of a computing instance.
+○	Examples of prior “decentralized” architectures includes the PGP system for public keys based on a “flat” web of trust (in contrast to traditional X.509 certificate hierarchies).
+○	For blockchains, the term “decentralization” typically refers to the equal privilege each node (e.g. mining node) possesses in performing transaction processing.
+●	Distributed vs decentralized:
+○	The term “distributed” in the context of computing system architectures is often used to denote the topological design of the system, which are usually multi-component (multi-site) configuration computing systems. A centralized system can be implemented using a distributed topology, where control resides within one or few parties.
+○	For blockchains, the term “distributed” is typically applied to refer to the agreement process (consensus-making algorithm) used by nodes in the P2P network to arrive at the same picture of the state of the shared ledger.
+○	Discussion of dictatorship vs. democracy as it relates to blockchain
+●	Trust and distrust:
+○	The term “trust” in computing system architectures denotes acceptance of the entity performing computations on behalf of the user, based on clear design and correct implementation of the computation mechanisms (e.g. computing sandbox free from interference), leading to the term technical trust (see the Terminology section).
+○	In blockchain conversations, the term “trustless” is often used incorrectly to mean that nodes and users do not have to rely on a centralized authority. However, technologies that make use of technical trust mechanisms are part of the blockchain proposition.
+●	Power and disempowerment:
+○	Not every solution built using blockchain technology is intended to empower or enfranchise individuals, but many are. The mechanisms for empowerment may differ: anonymization, tracking transactions with others, and so on.
+○	On the other hand, some solutions built using blockchain technology targeted to be used by parties on the other side of the equation could potentially disempower individuals further if used in service of human identity “provenance and fraud detection” (see the Terminology section), much in the way they are being examined for provenance and fraud detection of luxury goods, diamonds, and similar items.
+●	Humans and machines for contracts (identities and parties)
+==Example of sites discussing TF4FA==
+*[https://www.cdt.org/files/healthprivacy/20080514HPframe.pdf Center for Democracy and Technology: Comprehensive Privacy and Security: Critical for Health Information Technology]
+*[https://www.slideshare.net/iirojan/thews-trusted-ehealth-and-ewelfare-space THEWS - Trusted eHealth and eWelfare Space – SlideShare www.slideshare.net/iirojan/thews-trusted-ehealth-and-ewelfare-space]
+*[https://www.jmir.org/2012/2/e52 JMIR-A Conceptual Framework and Principles for Trusted eHealth and eWelfare Space]
+==THEWS presentation at Madrid WGM May 2017==
+*During the Security Madrid WGM Tuesday May 9, 2017 opening session, Dr. Blobel presented on THEWS Trusted eHealth and eWelfare Space - Report on current work: trust calculation and informed trust decisions.  His HL7 WGM Madrid 2017_THEWS Project presentation is of particular interest to the Security WG as it is a pilot project in Finland to establish a run time trust contract between data subjects, e.g., patients, and data collectors, e.g., provider EHRs, HIEs, Apps.  The Finnish pilot epitomizes the type of implementation that the TF4FA specification seeks to enable using HL7 standards for computable security, privacy, consent, and provenance policies encoded as trust contracts between parties in an interoperable information exchange.
+*[http://gforge.hl7.org/gf/project/security/docman/Security%20Work%20Group%20Presentations%20and%20Papers/MAY%202017%20Madrid%20WGM/HL7%20WGM%20Madrid%202017_THEWS%20Project.pdf HL7 WGM Madrid 2017_THEWS Project]
 ='''Trust Library'''=
 ===HL7 Security WG Trust Work===
@@ Line 13: / Line 86: @@
 ''Pros''
 *Anonymity. Block chaining leverages anonymous users, which may be of workable in the private-sector health care space.
-*No PKI. Doesn’t require robust public key infrastructure to support exchange among different security domains.
+*Digital Signature: Block chains are digitally signed and timestamped, providing incontrovertible evidence that the transaction occurred but not necessarily who executed the transaction.
-*Provenance. Provides integrity across multiple users that may be of benefit in health care to preserve provenance, as opposed to digital signatures that are susceptible to data alteration at each waypoint and/or user. According to Chris, this feature is probably block chaining’s greatest strength as opposed to digital signatures.
+PKI. Doesn’t require robust public key infrastructure to support exchange among different security domains. *Provenance. Provides integrity across multiple users that may be of benefit in health care to preserve provenance, as opposed to digital signatures that are susceptible to data alteration at each waypoint and/or user. According to Chris, this feature is probably block chaining’s greatest strength as opposed to digital signatures.
-*Integrity. Overall stronger integrity controls than digital signatures cryptographically and as noted above.
+*Integrity. Overall stronger integrity controls than digital signatures alone cryptographically and as noted above.
 ''Cons''
 *Lack of trusted endpoints. User anonymity impedes establishment of trust. While this is a desirable state in a use case such as Bitcoin, and may even be workable in the private-sector health care space, the lack of trusted endpoints would likely prove problematic in the federal space. Though block chaining provides desirable integrity controls (e.g., provenance preservation) some add on functionality would likely  be needed to address user trust. According to Chris, this is probably block chaining’s greatest weakness as opposed to digital signatures – specifically for federal agencies.
+*Non-Repudiation. Block chaining does provide non-repudiation. Transactions are signed and time stamped. But the private key used to sign the transaction is bound to an address. The purpose of signing in this context is to provide non-repudiation that the transaction occurred, not necessarily to the executor of the transaction. This is how block chaining can preserve (to some extent) anonymity. True identity behind an address may not be not verifiable in the absence of some trust framework. And in the case of Bitcoin, Bitcoin.org actually encourages people to use an address only once and to use multiple wallets to preserve anonymity:
+**“To protect your privacy, you should use a new Bitcoin address each time you receive a new payment. Additionally, you can use multiple wallets for different purposes. Doing so allows you to isolate each of your transactions in such a way that it is not possible to associate them all together. People who send you money cannot see what other Bitcoin addresses you own and what you do with them. This is probably the most important advice you should keep in mind.” https://bitcoin.org/en/protect-your-privacy
+*No native confidentiality controls. Block chain does not provide confidentiality as it is an open system. Of course, digital signatures in and of themselves do not provide for confidentiality but encryption across security domains can be implemented with public key certificates. As noted above, some add on functionality would likely  be needed to address confidentiality that could be as simple as TLS depending on the use case.
+==Kantara Blockchain & Smart Contract==
+*[http://gforge.hl7.org/gf/download/docmanfileversion/9387/14681/On%20Worldwide%20Consensus%20%e2%80%93%20A%20Stellar%20Journey%20%e2%80%93%20Medium.pdf  On Worldwide Consensus – A Stellar Journey]
+*[http://gforge.hl7.org/gf/download/docmanfileversion/9386/14680/stellar-consensus-protocol.pdf  Stellar Consensus Protocol]
-*No non-repudiation service. Digital signatures provide for non-repudiation that is block chaining does not.
+==MedRec==
-*No native confidentiality controls. Block chain does not provide confidentiality as it is an open system. Of course, digital signature in and of themselves do not provide for confidentiality but encryption across security domains is enhanced with the PKI,which would be in place with the use of digital signatures. As noted above, some add on functionality would likely  be needed to address confidentiality that could be as simple as TLS depending on the use case.
+'''[http://gforge.hl7.org/gf/download/docmanfileversion/9383/14677/MIT%20MedRec%20ONC%20Blockchain%20Challenge.pdf A Case Study for Blockchain in Healthcare: “MedRec” prototype for electronic health records and medical research data]'''
+==Blockchain==
 '''[http://healthitanalytics.com/news/is-blockchain-the-answer-to-healthcares-big-data-problems Is Blockchain the Answer to Healthcare’s Big Data Problems?]'''
@@ Line 28: / Line 109: @@
 '''[http://gforge.hl7.org/gf/download/docmanfileversion/9176/14188/Can%20Trust-Based%20Private%20Blockchains%20Be%20Trusted%20-%20CoinDesk.htm Can Trust-Based Private Blockchains Be Trusted?]'''
+=='''RSA 2016 Block Chain Presentations'''==
+*[http://gforge.hl7.org/gf/download/docmanfileversion/9297/14458/cryp-w05_the_future_of_bitcoin_and_cryptocurrencies.pdf RSA2016 - The Future of Bitcoin and Cryptocurrencies] by Bart Preneel
+*'''[http://gforge.hl7.org/gf/download/docmanfileversion/9298/14459/Dissecting_bitcoin_security.pdf RSA 2016] Dissecting Bitcoin Security
+Cassio Goldschmidt'''
 '''[http://proofofexistence.com/about What is Proof of Existence]'''
@@ Line 202: / Line 288: @@
 ==='''THEWS'''===
 *[http://gforge.hl7.org/gf/download/docmanfileversion/9171/14182/Privacy-Related%20Context%20Information%20for%20Ubiquitous%20Health.pdf Privacy-Related Context Information for Ubiquitous Health]
-*[http://gforge.hl7.org/gf/download/docmanfileversion/9172/14183/Trust%20Information-Based%20Privacy%20Architecture%20for%20Ubiquitous%20Health.pdf Trust Information-Based Privacy ARchitecture for Ubiquitous Health]
+*[http://gforge.hl7.org/gf/download/docmanfileversion/9172/14183/Trust%20Information-Based%20Privacy%20Architecture%20for%20Ubiquitous%20Health.pdf Trust Information-Based Privacy Architecture for Ubiquitous Health]
 ===Trust Label Harmonization Proposal===
@@ Line 208: / Line 294: @@
 *[http://gforge.hl7.org/gf/download/docmanfileversion/8271/12099/HL7%20Harmonization%20Proposal%20Trust%20Policy%20Vocabulary%20final.doc July Harmonization initial submission]
 *[http://gforge.hl7.org/gf/download/docmanfileversion/8270/12098/Trust%20Label%20Structure%20and%20Vocabulary.vsd Trust Label Diagrams]
+==='''Health Blockchain Publications'''===
+*[https://wayback.archive-it.org/3926/20170128063822/https://www.hhs.gov/about/news/2016/08/29/onc-announces-blockchain-challenge-winners.html ONC announces Blockchain challenge winners] Note that links to winner's submissions no longer work so search for title in a browser.
+*[https://www.healthit.gov/sites/default/files/2-49-accenture_onc_blockchain_challenge_response_august8_final.pdf Blockchain: Securing a New Health Interoperability Experience] Accenture
+*[https://oncprojectracking.healthit.gov/wiki/download/attachments/14582965/Day1_12_Blockchain_Securing_a_new_HIE_Experience.pdf?version=2&modificationDate=1474664020000&api=v2 ONC NIST Blockchain Workshop Accenture presentation]
+*[https://oncprojectracking.healthit.gov/wiki/download/attachments/14582965/092616%20ONC%20NIST%20Blockchain%20Workshop_Accenture_FINAL.pdf?version=1&modificationDate=1475003566000&api=v2 ONC NIST Blockchain Workshop Accenture presentation 2]
 [[Security|Back to Security Main Page]]