Basic Trust Model - Keys for Consensus

From Direct Project
Jump to navigation Jump to search
v3 draft here: S&T Consensus Proposal v3


Please:

  1. Use the discussion threads to discuss disagreement or confusion
  2. Edit the wiki text when the intent is clear (based on verbal or wiki discussion) but the wording is not
  3. Use the discussion threads to explain wiki updates



Consensus Items


Intent original version:

The plain English of what we are trying to get to are the preconditions for the following level of confidence: When I send data to you, I have confidence it will get to you; when I receive data from you, I have confidence that it came from you, and I have confidence in the exchange between us (that it won't lose the data, or do something with it that I don't like or agree to).

The goal of these items is to express a mechanism that satisfies the following goals:

  1. Provides for confidence in the basic preconditions of exchange: that information is reliably transmitted from the sender to the receiver and that nothing unexpected happens to the data during the transmission (examples of unexpected: transfer to a third party, secondary reuse without explicit authorization)
  2. Recognizes the need to verify that the counterparty to exchange adheres to at least my minimum floor set of preconditions (and may go above and beyond)
  3. Recognizes that the definition of basic preconditions for exchange will vary among participants
  4. Recognizes that there are many other aspects of confidence and trust in exchange that are not satisfied purely by the preconditions and need to be satisfied before someone decides to use the exchange (in the same way that policy will dictate if I should mail a letter before I send it in the mail, not after).
  5. Scales down to individual n^2 decisions on confidence and up to a single rooted level of confidence (and, more likely, to a finite set of rooted levels of confidence).


discuss

intent (FT version):

The Direct Project network will be a secure channel that its users can use to exchange messages that contain PHI.

In the same way that clinicians currently do not assume that it is safe to fax PHI to anyone with a fax number, or mail PHI to anyone with a post office address, Direct Project users will not assume that it is safe to send messages to any Direct Project address. Direct Project users will need to establish real-world trust relationships with other Direct Project users on their own terms, but once they have established this real-world trust, they can be sure that an Direct Project network will securely deliver Direct Project messages to the trusted Direct Project user.

Any Direct Project user will need to establish policies and standards for deciding which other Direct Project addresses to trust, in much the same way that clinicians currently decide which numbers or addresses they are willing to fax or mail PHI to. As much as possible, the design of the Direct Project secure network will not force Direct Project users to adopt or reject trust policies they might otherwise have used. However, in order to build a secure network for the transmission of PHI, Direct Project must select which protocols and technologies that Direct Project Implementers will use to build a secure network for Direct Project users. In some cases, those protocols and technologies will come with specific configuration options that will have policy implications. These security protocol and technology configuration options will present constraints that Direct Project will force on the trust policies of its users.

These security protocols and technologies will determine what "language" that given policies must speak. Most notably the decision to use the IETF X.509 standards for a PKI-based infrastructure will force Direct Project users to create trust policies that speak in terms of certificates, public key infrastructure and certificate authorities. Other protocol and technology decisions will have similar policy language implications.

All of this is to enable the Direct Project implementations to provide a simple security feature:
if two Direct Project users trust each other in the real world, and can mutually agree on standards and policies for handling PHI, they will be able to configure an Direct Project implementation to securely send messages containing PHI between them.


Second Level Items for discussion:

  1. In this document "Trust Assertion" is defined as: defines and executes policy and operations sufficient for participates to be assured that: discuss
    1. Messages are delivered only to the addressed endpoints(s) (specific individuals, groups or processes at the destination authorized to view messages sent to that endpoint).
    2. An endpoint can unambiguously identify the source address of a message.
    3. Data is governed and transmitted between Source and Destination according to the expectations of Source and Destination
  2. Other aspects of trust are out of scope for this document Note that data stewardship, governance and policy at the Source and Destination (behind the addressed endpoints) are out of scope for the definition of a trust assertion. In particular, the definition of a trust assertion in this document defines only the level of trust necessary to establish confidence that the transmitted message will faithfully be delivered to the recipient, not that the two parties (Source and Destination) trust or should trust each other; this definition of trust is to be defined by Source and Endpoint out of band, and may be facilitated by entities external to the Direct Project specifications (e.g., secure directories of credentialed providers). discuss
  3. Trust assertions are to be expressed by x.509 certificates The trust assertion is expressed through signatures or verification of approved x.509 certificates that map to the specific trust assertion made. The details of what that trust assertion means are described in policy documents which the parties agree to be represented by the certificate(s) in question. These policy decisions include but are not limited to identity assurance and authorization requirements, data governance (for the scope of transactions defined by the Direct Project Abstract Model, system security and privacy practices, QA and operational management, disclosure policies, and endpoint roles (e.g., provider vs. group vs. patient). discuss
  4. Direct Project Implementation interfaces should allow individual Direct Project users to think in terms of trust, rather than in PKI technical language. Real world evidence suggests that forcing key management on individuals will stifle adoption. Direct Project Implementations should allow individuals to work with the concepts of addresses/endpoints, organizations, and meta-organizations (e.g., a regional HIE). discuss
  5. Direct Project Implementations must support communication with patients/individuals using pseudonymous Direct Project addresses and certificates. For many Direct Project addresses, there will be a clear well-proven connection between a particular individual and a certificate address pair. Patient Direct Projectaddresses, however, will not typically have any such strong assurance performed at the Certificate Authority level. Trust between clinical Direct Project users and patient/individual Direct Project users will be established in a "business card" fashion. Clinicians will trust that a given patient/individual address is associated with a given patient because the patient will personally present that address to the provider. discuss
  6. Direct Project Users must be allowed to make all Trust Decisions. Direct Project Implementations will not automatically include any root certificate from a particular CA. The decision to import or not to import a given Certificate Authorities public key will be made by only by end users or administrators. This means that there will be no "default" Trust Network for the Direct Project outside of those explicitly configured by Direct Project users. discuss
  7. Direct Project Implementations allow simultaneous membership in networks defined by different trust assertions. Real world evidence suggests that achieving global trust is not practical. Therefore, an individual or organization participating in Direct Project must be able to specify the other individuals and/or organizations they are willing to exchange messages with, even when those organizations are following slightly different security and trust procedures. This configuration must be flexible enough to describe trust relationships at the address/endpoint, organization and meta-organization levels. These different Direct Project networks, with different trust and security rules, will be called "Trust Networks". Trust Networks are enabled by Certificate Authorities that have a single published security policy. discuss


Items defined by policy


  1. Direct Project implementations must allow separation of routing metadata and content data and metadata such that HISPs need not examine data to perform routing functions The decision to allow access to content, with the associated PHI, must be separably assignable to HISPs, not required to perform basic routing functions. In particular, routing functions must be allowed when all content, including content metadata, is encrypted. discuss
Retrieved from "https://directproject.mywikis.wiki/w139/index.php?title=Basic_Trust_Model_-_Keys_for_Consensus&oldid=53"