Accredited Trust Bundle Application Guide

To begin your application, start at the top of this page and work your way down to the bottom.

 How to Use this Guide

There are six basic components to achieving successful inclusion of trust anchor certificates in the DirectTrust Accredited Trust Anchor Bundle.

  1. Membership in DirectTrust (not required, but highly recommended);
  2. Accreditation and audit by DirectTrustrequired), and;
  3. Signing by the HISP of the Federated Services Agreement, and signing by the CA of the Federated Services Agreement Addendum for CAs if the HISP and CA are not the same entity;
  4. Submission and review by DirectTrust of the organization’s anchor certificate and other relevant artifacts (required);
  5. Successful completion of interoperability testing;
  6. Payment in full of Network Services fee.

This Guide covers only the third, fourth, and fifth components in detail, that is, the DirectTrust Network Services that begin with signing of the DirectTrust Federated Services Agreement, FSA, and continue with the submission, review, interoperability testing, management, and distribution of anchor certificates by DirectTrust on behalf of the signatories to the FSA who have successfully completed all steps in the process.  The flow diagram to the right illustrates the high level steps in this process and their recommended sequence.

This Guide is intended for Direct exchange service providers, including HISPs, CAs, and RAs, who wish to become part of the growing DirectTrust network through participation in DirectTrust Anchor Trust Network Services. It provides a step-by-step blueprint for including your organization’s trust anchor certificate(s) in the DirectTrust Accredited Trust Anchor Bundle. DirectTrust members strongly believe that the Trust Network Services described here create a streamlined review, management, and distribution system in a resource and cost effective manner that will be of benefit to all participants in Direct exchange. There is likely to be significant variability in the knowledge of Direct exchange for those who approach this Guide. Some organizations may be entirely new to Direct exchange as a technology and have only a limited understanding of the role and value of DirectTrust.  For these organizations, we recommend the time be taken to read this guide in its entirety, including the introductory and background sections, and that they utilize the many references to additional materials concerning the technical, regulatory, and security/identity aspects that comprise the full domain of Direct as a component of the Nationwide health information network, NwHIN. Others may already have in-depth Direct implementation experience and seek only to better understand how to accelerate the process of including their own trust anchor certificates into one or more trust bundles maintained by DirectTrust. For these organizations, special attention should be paid to particular sections where processes are described in detail and requirements for trust anchor certificate preparation, submission, review, management, and distribution are given. There will be large icons for you to click on to continue on to the next step on each page.  To continue the step-by-step application process now, please continue down this page.
white_triangle

Question 1: Are you a DirectTrust member?

Yes

Continue down this page.

No

Membership in DirectTrust is not a requirement for use of DirectTrust Anchor Certificate Services or for inclusion of your Trust Anchor in the “Accredited” Trust Anchor Bundle. However, active membership in DirectTrust has been a key component in many successful Direct implementations, and may signficantly accelerate the processes and procedures of both accreditation and anchor certificate readiness for review. Trust anchor bundle and network services fees are also discounted to DirectTrust members, and will be significantly higher for non-members.To learn more about DirectTrust, please visit DirectTrust 101. If you would like to continue the application, please continue down this page.

white_triangle

Question 2: Is your HISP fully accredited by DirectTrust HISP Accreditation and your CA/RA accredited by a DirectTrust-EHNAC program yet?

Yes

This link will take you down this page to the next step.

NOTE: HISP, CA and RA all need to be accredited and audited.

No

This link will take you to the DirectTrust HISP Accreditation website and this link to the EHNAC website to begin your accreditation application for CA/RA. Please return here when you have completed that process and have officially been listed as being fully accredited on the EHNAC website.

NOTE: HISP, CA and RA all need to be accredited and audited

white_triangle

3. Download the required materials

Materials to download

You should download these documents, fill them out, and be ready to upload them during the application process. You will be given the chance to upload them after you have completed the Pre-Application Form, paid the Trust Network Services Fee and been given a login to the secure upload pages.

  • DirectTrust HISP-CA ProfileTemplate– Excel spreadsheet to be filled out by submitting HISPs as part of the trust anchor submission process.
  • Federated Services Agreement – Signed by HISPs and DirectTrust CEO, serves to enable HISPs having reached full accreditation status to submit their trust anchors for inclusion in the DirectTrust Accredited Trust Anchor Bundle.
  • Federated Services Agreement CA-RA Addendum  Addendum FSA for RA/CAs. This document is required if a HISP is using a third party for CA and/or RA functions.

In addition to these documents, you will also need to upload:

  • Your trust anchor file(s)
  • Your end-entity certificate(s)
  • Proof of interoperability testing scores are collected separately after the required uploads listed above have been reviewed and approved

A list of all steps required in the process can be found at the bottom of this page or by clicking here.

white_triangle

4. Fill out the Pre-Application Form

This form will initiate your application process. We will then authenticate that you are the point-person for your organization and that you have paid the Services Fees (below). At that point we will create your secure upload page and email you the login information.

All fields are required.

Organization's Name

Name of Contact Person

Email of Contact Person

Phone Number of Contact Person

white_triangle

5. Pay your Trust Network Services Semi-Annual Fees

Click the button above to pay your Network Services fee and then return to this page to read about the next steps in the inclusion process.
white_triangle

What happens next?

After your pre-application form has been completed and your services fee has been processed, you will be emailed a login to gain access to your secure package-upload area that will be set up by DirectTrust.org specifically for your organization to upload your application documents. At that point, the following steps will begin.

Trust Anchor Inclusion Steps

The procedure for including HISP trust anchors into the DirectTrust Accredited Trust Anchor Bundle includes the following high-level steps:

Step 1. Trust anchor and required artifact submission

After a HISP and the utilized CA and RA entities have achieved DTAAP accreditation status, the HISP submits its trust anchor(s) for inclusion into the trust bundle by filling out and submitting all requested materials to the DirectTrust Trust Network Services web site at https://services.directtrust.org/. Submitted materials include:

  1. All trust anchor files
    1. Sample end entity certificate(s) chaining to each trust anchor
      1. An example of each certificate type that will be issued by the trust anchor should be submitted. Certificates types include:
        1. Org level certs
        2. Address level certs
    2. If the sample end entity certificates do not directly chain to the submitted anchors, all intermediate issuing certificates in the certificate chain between the anchors and end entity certificates must be submitted.
  2. HISP/CA/RA profile spreadsheet
  3. Executed copy of the DirectTrust Federated Services Agreement from both the submitting HISP and the relied upon certificate authority. If the HISP and certificate authority represent the same entity, then only the single executed agreement is necessary.

DirectTrust reserves the right to require a method of submission of these documents, e.g. through a dedicated website upload process. All required artifacts must be submitted no later than EOB two business days before the next Trust Anchor Approval Committee meeting in order to be placed on the next meeting’s agenda. For example, if the approval committee meets on a Thursday, all artifacts must be submitted by EOB on the Tuesday prior to the meeting. At the discretion of the Trust Anchor Approval Committee, artifact corrections and/or addendums may be accepted after the submission deadline, but must be received by the Committee prior to the approval Committee meeting. The Trust Bundle Administrator has access to this website and will view the materials here. What is the timetable for review?   All required artifacts must be submitted no later than EOB two business days before the next Trust Anchor Approval Committee meeting in order to be placed on the next meeting’s agenda. For example, if the approval committee meets on a Thursday, all artifacts must be submitted by EOB on the Tuesday prior to the meeting. At the discretion of the Trust Anchor Approval Committee, artifact corrections and/or addendums may be accepted after the submission deadline, but must be received by the Committee prior to the approval Committee meeting.

Step 2. Baseline trust anchor approval

If trust anchors are submitted over a non-secure transport, out of band verification MUST be performed to ensure the integrity and validity of trust anchors. Verification in such cases is performed by the Trust Bundle Administrator via an over the phone verification with an authoritative member of the submitting HISP. The HISP member will verify the following attributes of the trust anchor(s):

  1. Trust anchor thumbprint
    1. Thumbprint is the thumbprint attribute of the trust anchor
  2. Trust anchor subject (distinguished name) attributes
  3. Trust anchor issuer
  4. Trust anchor valid from and valid to dates

Although the trust anchor thumbprint is cryptographically sufficient for verification, the additional attributes are validated for additional assurance. If the verification process is not successful due to inconsistencies in the artifacts submittted, the HISP will resubmit their artifacts. to the designated submission location. Upon receipt, the Trust Bundle Administrator will discard the invalid trust anchor(s) and re-verify the new trust anchor(s). If the subsequent resubmission and verification are not successful, the Trust Bundle Administrator will engage the HISP submitter directly to facilitate alternative means of trust anchor submission.

Step 3. Interoperability testing

After the anchors have been submitted, the Trust Anchor Approval Committee will review the HISP’s documents and the submitted anchors for baseline approval. The committee will evaluate the HISP and the submitted trust anchor(s) for compliance against the trust bundle profile criteria. Approval criteria consists of the following: Requirements For All Entities

  • The HISP, the trust anchor’s Certificate Authority, and Registration Authorities used to validate identities MUST have achieved DTAAP accreditation.
  • The HISP, the trust anchor’s Certificate Authority, and Registration Authorities used to validated identities MUST be listed as accredited DTAAP entities on the EHNAC web site. The previously mentioned website MUST be protected with an EV SSL certificate.

HISP Requirements

  • The HISP and the DirectTrust CEO MUST have signed the DirectTrust Federated Services Agreement.
  • Required Certificate Services fees MUST be paid in full.

Certificate Authority Requirements

  • The Certificate Authority, if a separate third party from the HISP, MUST have signed the DirectTrust Federated Services Agreement CA/RA Addendum.
  • Required Certificate Services fees MUST be paid in full.
  • Trust anchors submitted by the HISPs must adhere to the DirectTrust X.509 Certificate Policy (CP) 1.2 or a more recent version. Depending on the CP version compliance, trust anchors are considered for compliance under one of the three following provisions:
    • Trust anchor(s) in compliance with any CP allowed by this profile and the HISP is its own CA. This case implies a 1-1 relationship between the CA and the HISP meaning that certificates are only issued to entities within the single HISP (i.e. the CA does not issue certificates to other HISPs).
    • Trust anchor(s) in compliance with 1.2.x where the CA may issue to multiple HISPs. In this case, the trust anchor under consideration may only issue to HISPs that are DTAAP accredited.
    • Trust anchor(s) in compliance with CP 1.3 or greater where the CA may issue to multiple HISPs. In this case, the trust anchor under consideration may only issue to HISPs that are DTAAP accredited.
  • All subjects or organizational representatives of organizations using end entity certificates issued by the CA issuing the trust anchor (also any ISSOs where a HISP is used) MUST be identity proofed using at minimum DirectTrust LoA 3 or an equivalent identity proofing process.
  • All end entity certificates issued by the trust anchor (or sub anchors) must express in the certificate policies extension an entity category policy OID defined under the 1.3.6.1.4.1.41179.2 OID arc. For all anchors existing in the bundle before this requirement becomes effective, all newly issued end entity certificates MUST contain the entity category policy OID starting October 1st, 2015 and all existing end entity certificates MUST contain the entity category policy OID by January 1st, 2016.
  • All HISPs holding end entity certificates issued by the CA issuing the trust anchor must have fulfilled the requirement to sign the DirectTrust Federated Services Agreement, i.e. the CA issuing the trust anchor may only issue certificates to subjects or organizational representatives that are served by a HISP that has signed the DirectTrust Federated Services Agreement.

The baseline approval process includes a checklist of items that MUST be reviewed by the approval committee. Each item in the checklist MUST be reviewed and signed off by two members of the approval committee or the appropriate member of DirectTrust staff. NOTE: CP 1.3 specifies additional policy OIDs to assert additional attributes such as accreditation status and issuing LoA. However, this requires relying parties to be able to process the policy OIDs. At the time of writing, this functionality is not available in the majority of HISPs. Future versions of this SOP may allow for CP 1.3 compliant CAs to issue to HISPs at non-accreditation statuses and LoAs lower than DirectTrust LoA 3. Upon baseline approval or denial by the Committee, the original submitter will be sent an email indicating the results of the Committee’s decision. For trust anchors that are denied, detailed information will be included indicating the reasons for denial. If multiple trust anchors were submitted, it is possible that some trust anchors may be approved while others are not. For trust anchors that are baseline approved, the anchors will move forward in the process to interoperability testing. HISPs will be notified of their baseline approval status by the Approval Committee within 10 business days of trust anchor submission.

Step 4. Final anchor and operational approval

Upon baseline trust anchor approval, HISPs must complete interoperability testing to prove a reasonable level of operational competency and compliance.  The Security and Trust Compliance workgroup continuously operates a matrix of interoperability testing among members of the DirectTrust community, and an interoperability HISP pool of DTAAP accredited members that have successfully connected with 80% of the other members of the matrix will be created for the interoperability-testing phase herein described. The HISP will provide a Direct address per submitted anchor whose end entity certificate chains to the anchor(s) under review to the trust bundle administrator.  This address should be a testing address within a production environment that will be utilized for sending and receiving test Direct messages with other members of the DirectTrust network.  The HISP’s trust anchor will be placed in a temporary interoperability testing trust bundle that can be consumed by the HISPs in the interoperability HISP pool during the testing phase.  The HISP’s anchor may be removed from the interoperability testing trust bundle after the testing phase has been completed. Interoperability testing will consist of bidirectional exchange of messages between the HISP under review and 10 other DTAAP accredited HISPs.  The 10 HISPs will consist of:

  • 5 HISPs selected from the interoperability HISP pool chosen by the HISP under review.
  • 5 HISPs randomly selected from the interoperability HISP pool.  The trust bundle administrator will execute this selection process.

Bidirectional exchange consists of the following criteria:

  • Successful sending of a message from the HISP under review to the DTAAP accredited HISP.
    • The message must be received and security and trust validated by the receiving HISP.
    • The receiving HISP must send back an MDN process message to the HISP under review.
    • The MDN processed message must be successfully received and security and trust validated by the HISP under review.
  • Successful receipt of a message from the DTAAP accredited HISP to the HISP under review.
    • The message must be received and security and trust validated by the HISP under review.
    • The HISP under review must send back an MDN process message to the DTAAP accredited HISP.

The HISP under review must successfully complete bidirectional exchange with a minimum of 8 of the 10 DTAAP accredited HISPs, for an interoperability score of 80 per cent or higher. The HISP under review must compile artifacts from tests against each DTAAP accredited HISP as proof of successful bi-directional exchange.  Because retrieving artifacts from remote systems may be difficult, time consuming, and in some cases impractical, this required list is comprised of only artifacts that are in direct control of the HISP under review.  These include: Sending Messages:

  • Proof of a message successfully sent from the HISP under review.  This includes proof of security and trust validation.
  • Proof of a receipt of the MDN processed message.  This includes proof of security and trust validation and MUST show a correlation to the message ID of the originally sent message.

Receiving Messages:

  • Proof of a message successfully received from the DTAAP accredited HISP.  This includes proof of security and trust validation.
  • Proof an MDN processed message successfully sent from the HISP under review.  This includes proof of security and trust validation and MUST show a correlation to the message ID of the received message.

The medium, format, and contents of the artifacts are not specified, however they must deterministically demonstrate that the above stated criteria have been met. In the event of an unsuccessful bidirectional exchange between the HISP under review and a DTAAP accredited HISP, the two parties should attempt to resolved interoperability issues and attempt a subsequent exchange.  If interoperability issues cannot be resolved, the HISP under review may submit a request to the trust bundle administrator to replace the DTAAP accredited HISP with a different DTAAP accredited HISP.  The request will be reviewed by the Trust Anchor Approval Committee and be either approved or denied at their discretion.  If the committee approves the request, then a new DTAAP accredited HISP will be selected to replace the previous HISP.  The HISP under review may only request at most 2 replacements during the duration of the approval process. After interoperability testing is successfully completed, the HISP under review will submit their artifacts to the Trust Anchor Approval Committee for final approval.  Artifacts will be emailed to the DirectTrust Administrator.

Step 5. Final anchor approval
Upon completion of interoperability testing, the Trust Anchor Approval Committee will review the submitted anchor(s) again for final approval.  The committee will review the results of interoperability testing and determine if all criteria have been successfully met as defined by the interoperability testing measures.  If it is determined that the criteria has not been met, then the HISP must continue interoperability testing until all issues are resolved. The Committee also reserves the right to revaluate the criteria of baseline approval if additional issues are discovered during in the interoperability-testing phase.  If baseline issues are found at this stage that result in a denial, then the HISP must go back through baseline approval and interoperability testing.
Step 6. Trust bundle generation and publication

Upon successful final anchor approval, the Trust Bundle Administrator will move the trust anchor(s) into the trust bundle anchor repository location.  This repository location contains a collection of all approved trust anchors in the DirectTrust Accredited Trust Anchor Bundle, and is regularly renewed and updated. The Trust Bundle Administrator will then generate a new trust bundle file that includes all existing and the newly approved trust anchors using the necessary tooling.  The new trust bundle will use the identical file name of the existing bundle. Before the new trust bundle is published to the publicly accessible URL, the existing trust bundle will be backed up into a trust bundle archive location.  After the existing trust bundle has been archived, the new trust bundle will be moved to the trust bundle publication URL. Lastly, the trust bundle details page will be updated with all required information including but not limited to:

  • HISP name
  • HISP ID
  • Trust anchor(s) common name
  • CA operator name
  • RA operator name
  • Trust anchor(s) compliance information
    • DirectTrust CP version compliance
    • CP URL and CPS URL
  • Issued certificate types

Contact Us

7 + 10 =