LDAP+Direct+Project+Recommendation+Review

=Certificate Discovery for Direct Project - LDAP Recommendation For Review:= toc Previous discussion regarding harmonization of considered DNS as an option in support of the Direct Project.It was generally agreed that the DNS pilots occurring within the Direct Project should continue their work and provide information in the future to the S&I Framework on their progress to date.

This page will be used to document recommendations and analysis surrounding an X.500 LDAP option for the Direct Project. Since the Direct pilots are currently concentrated in using DNS, most of the implementation guidance needed to support DNS guidance is already available. However, a key consideration of using a DNS approach is that many commercial off-the-shelf email programs will not support the current approach outlined in the Direct Rules of the Road statement for DNS, and it also is not clear that these email programs will change any time soon to support the Direct Project. This is one of the key reasons for exploring an alternative X.500 LDAP option for those Direct participants who wish to use existing LDAP infrastructure, such as Microsoft Exchange Server 2007, to support the Direct Project. This includes support for those implementers who may choose to use X.500 LDAP support within secure email, or who may already have an existing LDAP infrastructure in their organization.

The outlines of this proposed X.500 LDAP approach are as follows:
 * X.500 LDAP would be an alternative option to be considered for potential Direct participants. While adoption of X.500 LDAP has been limited so far for Direct Project participants, the reference implementation that has currently been developed for the Direct Project supports X.500 LDAP so guidance can be drawn from there.
 * Support from almost all off-the-shelf email programs is already built in for LDAP, so focus would be on building a simple X.500 LDAP solution to support the Direct Project. The specific issue where off-the-shelf email cannot support DNS inhibit its overall adoption.
 * Those publishing certificates may have to publish through multiple means (DNS for global search and X.500 LDAP for "trusted provider" search). This would be known in this proposal as the "hybrid approach". This approach allows for the best characteristics of both DNS and X.500 LDAP to be used in support of the Direct Project.

X.500 LDAP Issues to Review
The S&I Framework Provider Directory Initiative will look at the following questions in considering X.500 LDAP as appropriate for the Query for Digital Certificate for Direct Project Use Case business and technical requirements:
 * * What are the specific weaknesses of the **X.500 LDAP** **approach for Direct and can they be documented and described in more detail?**
 * What is the general set of implementation guidance surrounding use of **X.500 LDAP** that is needed to support emerging **X.500 LDAP pilots?**
 * What is the maturity of implementations of the **X.500 LDAP** **standards vs. DNS standard?** ||

X.500 LDAP **Weaknesses and Mitigation**
X.500 LDAP issues to be considered as part of developing S&I Framework consensus around the Query for Digital Certificate for Direct Project Use Case include:
 * Need for global automated query federation - it appears the Direct pilot participants are focused on this specific issue as a reason not to use X.500 LDAP. Explore and document this issue.
 * High level authoritative root may be needed to support global federation. (Peter & Les).


 * Volunteers to develop this guidance further?**

Questions

 * What happens if we want to use one standard more than another in the Hybrid Approach?

=X.500 LDAP Implementation Guidance=

Using an approach referred to as simple LDAP, an alternative approach can be offered to query digital certificates using X.500 LDAP. The inetOrgPerson object Class would allow for the storage of all the information needed to support the Query for Digital Certificate for Direct Project Use Case**.** Specifically, the userSMIMECertificate attribute would allow for the storage of the X.500 digital certificate required from the use case.

The following figure outlines this possible approach:

Please click here to provide volunteer feedback.

For query for certificate by the recipient's email address, as in the case for Direct Project, use the Mail attribute on the inetOrgPerson object as the search filter: (mail=//recipient Email Address)//.

For organizational recipient with a Direct address, a contact user can be created for the organization, in which case the query for certificate will be the same as described above.

Note that IHE's Healthcare Provider Directory profile (HPD) also defined the HcSigningCertificate attribute on the HCProfessional and HCRegulatedOrganization classes to store provider and organization's certificate. This attribute potentially can be used to query for certificates beyond the Direct Project use case.

HISPs trusting each other can share LDAP information to allow a sending system to query the receiving system's for recipient certificate. Virtual Directory technology may be used to present a unified view of information from multiple systems for ease of implementation.


 * Volunteers to develop this guidance further? ( Bob, Peter, Lin, Les - Ken Reviewer) - COB Friday**

A UML Classifier Diagram explores Namespaces, the following diagram show a trusted root and a provider directory. Access to the provider directory is via DNS SRV record which returns an LDAP access point. The LDAP access point in this diagram also includes a PEP, or policy enforcement point. The LDAP X.500 root object is instantiated with an AAMD or autonomous administrative management domain which represents the entire United States provider directory. Under that Health Informatics Provider Directory are located national organizations, and states. States hold all providers in that state in a state X.500 LDAP directory. States may query the root for data of other states, which will then create a connection between them, based on the privacy, governance, and business rules of the national object. Nothing prevents a bi-lateral DURSA agreement between states but the root object will have a negotiated minimum set of privacy and security requirements and data elements to support meaningful use for messaging and other applications.

Please click here to provide volunteer feedback.

=X.500 LDAP - DNS Hybrid Implementation Guidance=

Additionally, the implementation guidance should provide some guidance on how to possibly provide some level of federation if the pilot participant requires it. The Query for Digital Certificate for Direct Project does not specifically point out any requirements for federation, so this is only optional, but would appear supportive for pilots.

X.500 LDAP SRV records for a domain name can be discovered on a global basis, The SRV record is commonly available with DNS; and would allow a Direct participant to retrieve a certificate from an X.500 LDAP server via LDAP. A query to the Directory via LDAP allows for three types of native access or "binding".

1. Anonymous 2. Password 3. Strong Authentication with Digital Certificate

Fine grained access controls based on business rules are available using XACML.

In addition, there are internal, and external (border) LDAP accesses. Participants will determine at a minimum what needs to be exposed to different access levels. X.500 LDAP can also process clearance levels to prevent data leakage between systems which have different clearance ratings. Implementers should determine determine which data should be provided to other members of the Directory, who will maintain it as current information, and business owners of the data.

The following figure outlines this possible approach:

This hybrid approach would also like for some protection of provider attributes/certificates should an organization or provider desire to achieve this level of security. This is done through the storage of information in X.500 LDAP but the usage of DNS to locate other sources of digital certificates. This also would meet the needs for global federation by allowing discovery of the LDAP entrypoint through DNS-SRV records deals with the 'federation' problem.

The following figure provides an example deployment diagram showing how Microsoft Exchange and a DNS Server can be used to meet the requirements for global federation:




 * Volunteers to develop this guidance further?**

=Maturity of LDAP and DNS=

One of the main reasons for evaluating maturity of both X.500 LDAP and DNS is to ensure that multiple factors are used in evaluating standards. This means it is necessary to consider not only the maturity of the standard but also if there is a ‘market issue’ where the technology itself is problematic with dominant players. Because this Direct Project-focused use case has a very minimal schema, we should try to use an out-of-the-box schema with no healthcare specifics. This would imply that X.500 LDAP should be evaluated with this context, as it supports this minimal schema and allows for the addition of other needed attributes (for example, those specified in the Electronic Service Information Use Case) and healthcare-specific attributes (through the use of a standard like IHE HPD.)


 * Volunteers to develop this guidance further?**


 * A lack of truly unique identifiers that scale nationally and globally**.

We all know how important names are to individuals and corporations. They represent identity and brand reputation which is critical for trust formation. The uniqueness of names is very low. Therefore digital certificates use distinguished names in the subject field of a certificate. This aligns perfectly with a provider directory entry. Any element of that name can be used to narrow a search on the set of all providers in the U.S. One could query on a state, a locality, a common name, and so on. To prevent "trawling" which frequently happens with data (for example a clinic has 59,000 entries in a search engine, access controls are introduced.

A simple parallel category data mining example shows that there are only a few paths which allow for unique naming. Many elements are unique if combined with other elements, or non-unique in a national or global sense. By combining the right required data elements along with the digital certificate based on traceable requirements, a provider is guaranteed uniqueness.



=Recommendations=

We feel this hybrid approach works better than a distinct DNS or X.500 LDAP only approach in the Direct Project for the following reasons
 * Provides broader reuse capabilities for existing infrastructures
 * Allows for commercial, off-the-shelf email to be supported for the Direct Project,a major consideration in promoting further Direct Project adoption.
 * Allows for non-anonymous query (in support of privacy and security considerations), a feature that DNS does not support.
 * Takes the best of both standards (DNS and X.500 LDAP) and merges them into one approach -
 * Works better as a way forward for other types of Provider Directories - one solution vs. multiple solutions depending on your environment.
 * The Direct Reference Implementation already supports X.500 LDAPnatively.

The major tension in this approach is that it will need to move quickly from documentation to actual implementation. As such, pilots on this approach will need to be quickly identified and commissioned, and work on a reference implementation will need to be completed.

**To review the proposed Harmonization Statement for Query for Digital Certificate Use Case for Direct Project Use Case** **(lead by Bob Dieterle), please visit the Volunteer Recommendation Review page.**

Direct Project Implementation Recommendations
The S&I Framework recommends the consideration of the following implementation options for the Query for Direct Project for Digital Certificate Use Case:
 * DNS-only approach - to support current Direct Project DNS pilot projects and those who have a DNS-only infrastructure and require global query and federation.
 * X.500 LDAP-only approach - to support a Direct trust model where the trusted Direct Project participants exist in a local or regional area and who also use LDAP.
 * DNS/X.500 LDAP hybrid approach - to support an infrastructure where X.500 LDAPis already in use (commercial, off the shelf email) but DNS is available to support global query and federation of digital certificates

X.500 LDAP Pilots
The S&I Framework will sponsor activities associated with pilots of the X.500 LDAP -only approach. Specifically, a reference implementation of the Direct Project will be stood up to test the approach of using X.500 LDAP-only to query for digital certificates.

X.500 LDAP/DNS Pilot Approach
The S&I Framework will sponsor activities associated with testing and piloting a hybrid DNS-X.500 LDAP approach. Specifically, a reference implementation of the Direct Project will be stood up to test an X.500 LDAP/DNS hybrid approach that allows for global query of digital certificates.


 * Volunteers to develop this guidance further?**