This site only contains limited information on DIRECT -- to learn more, dig into the DIRECT Project wiki.

Introduction to the DIRECT project

The Direct Project specifies a simple, secure, scalable, standards-based way for participants to send authenticated, encrypted health information directly to known, trusted recipients over the Internet.

This transaction allows secure communication of health data among health care participants who already know and trust each other.

A Health Information Service Provider (HISP) is an actor in the Direct transaction that is not necessarily a separate business or technical entity; instead, it is a logical concept that encompasses certain services that are required for Direct Project exchange but may be performed or handled by a party other than the sender or receiver, depending on the deployment option chosen by the implementation.

A Direct Project implementation is responsible for packaging message content, securing it, and transporting it from one location to another.

  • Content is packaged using MIME and, optionally, XDM.
  • Confidentiality and integrity of the content is handled through S/MIME encryption and signatures.
  • Authenticity of the Sender and Receiver is established with X.509 digital certificates
  • Routing of messages is handled through SMTP

The Applicability Statement for Secure Health Transport describes how to use SMTP, S/MIME, and X.509 certificates to securely transport health information over the Internet. Participants in exchange are identified using standard e-mail addresses associated with X.509 certificates. The data is packaged using standard MIME content types. Authentication and privacy are obtained by using Cryptographic Message Syntax (S/MIME), and confirmation delivery is accomplished using encrypted and signed Message Disposition Notification.

A Security/Trust Agent (STA) is a Message Transfer Agent, Message Submission Agent or Message User Agent supporting security and trust for a transaction conforming to this specification.

The following functions are specified:

  • Use of Domain Names, Addresses, and Associated Certificates
  • Signed and encrypted Internet Message Format documents
  • Message Disposition Notification
  • Trust Verification

The Direct Project uses S/MIME as an underlying method for message transfer. In short the processes are as follows:

Outgoing

To process outgoing messages, the implementation:

  • Resolves private keys for messageEnvelope.Sender
  • Resolves public certificates for each messageEnvelope.Recipients
  • Enforces the Trust Model
  • Wraps messageEnvelope.Message (see Message Wrapping)
  • Signs and Encrypts the wrapped MIME entity with the sender certificates and private key pair and recipient public certificates
  • Creates a new messageEnvelope.Message with the headers extracted in the message wrapping process and the MIME package created by signing and encrypting

The implementation MUST check recipient certificate trust. If the recipient is un-trusted, the implementation removes the recipient from the recipient list. If a message has no trusted recipients, the implementation MUST reject the message.

Incoming

To verify if a recipient trusts a sender, the implementation MUST check if the sender signed the message with a certificate that the receiver trusts. A sender can sign the message using the private keys associated with multiple public certificates, each of which may represent its membership in different trust circles. The implementation finds at least one valid signature with a certificate whose trust chain contains an anchor that the recipient trusts.

An implementation MUST perform the following steps:

  • Resolve private keys for domain recipients
  • Decrypt messageEnvelope.Message
  • Extract the signed Signed Entity
  • Verify the signature
  • Enforce Trust Model
  • Unwrap message
  • No labels