esMD+AoR+L1+SWG+3+(Digital+Signatures+&+Delegation+of+Rights)+White+Paper

include component="page" wikiName="siframework" page="esMD Header"

=
All of the Use Case materials listed below have been consensus-approved and published to the [|S&I Framework Repository Browser]. For un-published, draft versions of any materials refer to the appropriate S&I Phase and/or workgroup.======

Consensus voting for the esMD AoR L1 Digital Signatures / Delegation of Rights White Paper is now closed. Click here to see the votes.

Click below to download the Use Case in a MS Word document:

=0. Terms= The following are definitions of specific terms used in this document. For a full list of definitions see Appendix A: Glossary.


 * esMD** – electronic submission of Medical Documentation


 * esMD Program** – the program established by CMS for the electronic submission of Medical Documentation


 * esMD Phase 1** – the first phase of the esMD Program focused on the electronic submission of PDF(s) containing medical documentation in a C62 wrapper using the NwHIN Exchange. The primary source of the submission is through certified Health Information Handlers (HIHs). esMD Phase 1 started pilot production submission of documents in September of 2011


 * esMD Phase 1 Transaction** – the transaction specified in the //Implementation Guide for Electronic Submission of Medical Documentation Project (esMD) Version 2.9 (4/17/2012)//


 * esMD Gateway** – the CMS NwHIN Connect instance that receives esMD Phase 1 transactions for CMS


 * esMD Initiative** – the current esMD Program effort in conjunction with the ONC S&I Framework is focused on three specific use cases: 1) Provider registration, 2) secure transmission of the electronic Medical Documentation Requests, and 3) Author of Record, digital identities and digital signatures. With this initiative, the esMD Program is soliciting participation by commercial payers and including specific support for both CMS and commercial payers.


 * esMD Initiative Transactions** – the specific transactions defined by the esMD Initiative use cases and the subsequent implementation guides


 * Individual** –in this document, any reference to an Individual is intended for a natural person only.

=1.0 Summary= The Author of Record Sub Workgroup (SWG) on Digital Signatures and Delegation of Rights (DS/DR) recognizes that healthcare payers using the esMD Initiative Implementation Guides require the ability to create Public Key Infrastructure (PKI) based digital signatures and delegation of rights artifacts to perform the following actions:
 * Organization or Entity** – in this document, any reference to an organization or entity is to a legal entity other than an Individual. In some cases, an Individual may also be the sole individual that is the owner/subject of a professional corporation (PC) or limited liability corporation (LLC); in which case, the Individual is the live person and PC or LLC is an organization or entity. Note: The term Organization will be used in this document.
 * 1) Establish identity of the provider to allow transmission of Protected Health Information (see HIPAA) as part of an electronic Medical Documentation Request (eMDR).
 * 2) Replace the “wet signature” on the document bundle submitted in response to an eMDR.
 * 3) Determine authorship of medical documentation to support claims for payment for services delivered by providers.
 * 4) Prove delegation of rights where the originator of the above action is not the responsible Individual or Organization (e.g., the originator is acting as an authorized agent).

All providers (Individuals and Organizations), as well as their designated agents, that register for the esMD Program will be required to authenticate the above actions with digital signatures created using X.509v3 signing certificates compliant with Federal Bridge Certification Authority (FBCA) Medium Assurance and issued by Credential Service Providers (CSP) that are cross-certified with the FBCA.

The SWG recommends that the esMD Initiative identify and require:
 * 1) A standard for digital signatures in the esMD transaction that clearly supports the transmission of the public certificate and the basic message signature artifact (signed digest of the message) as part of the esMD Initiative Transaction Implementation Guides (see Section 7.0).
 * 2) A standard for digital signatures on document bundles that clearly supports the transmission of the public certificate and the expanded signature artifact (minimum required: digest of message, timestamp, and purpose of signature) for the Author of Record Level 1 Implementation Guide (see Section 7.0).
 * 3) A standard for delegation of rights assertions for both messages and document bundle signatures that include as part of the assertion, at a minimum, the certificate ID of both parties, the purpose of the delegation, the effective date range, and an optional Uniform Resource Identifier (URI) of a revocation list. Any transaction using the delegation of rights assertion must include the public certificate of the delegator (see Section 8.0).
 * 4) Long-term (21+ years) access to CSP/CA root certificates and revocation lists or a transaction that can confirm that a certificate was valid (and not revoked) on a particular date/time.

The immediate need to provide digital signatures and delegation of rights artifacts can be met with existing standards and implemented by providers, payers, agents and contractors. The capability may be provided as a service by third parties or incorporated directly into or provided in conjunction with EHRs and payer systems. Support for long-term access to certificate revocation lists will need to be addressed by the industry. The ability to support validation or revocation of delegation assertions will depend on the nature of the implementation and the specific delegation assertion and specific options may be added as part of the pilots. =2.0 Statement of Problem and Background= Define the required process for issuing and managing digital credentials for the electronic submission of Medical Documentation to the Centers for Medicare and Medicaid Services (CMS) and commercial payers that adopt the esMD Initiative Implementation Guides.

On September 15, 2011, the esMD Program launched a pilot to accept electronic submissions from providers via Health Information Handlers (HIHs). The current esMD initiative will enable Medicare Review Contractors to send electronic Medical Documentation Requests, eliminating the need to send the paper letters via mail. The next release will also implement the replacement of wet signatures with Digital Signatures on the bundle of documents requested by CMS or the appropriate commercial requestor.

There is a need on CMS’s part to: 1) verify the identification of the individual or organization receiving Protected Health Information (PHI) contained in the eMDR and 2) to ensure authenticity of the documents submitted in response to the eMDR. These are requirements for participation in the esMD Program.

Three separate work groups were assembled to address Identity Proofing, Digital Credentials, Digital Signatures, and Delegation of Rights issues associated with Digital Signatures. The Digital Signatures / Delegation of Rights workgroup focused specifically on standards, policies and operational issues related to digital signatures on Document Bundles and delegation of rights assertions for both message and document bundle signatures.

The workgroup recommendations are constrained by two primary factors; (1) the solution must be implemented within the first two quarters of calendar year 2013, and (2) the systems that support the esMD Initiative (including esMD Phase 1) would have to meet standards established by the Federal Information Security Management Act of 2002 (FISMA).

The workgroup identified a number of relevant standards. However, considering the FISMA requirements, special emphasis was placed on NIST SP 800-63-1 and X.509 Certificate Policy for the FBCA version 2.25 in determining the core requirements for their recommendations.

The overall recommendation is that all Individuals, Organizations and their agents must use a digital certificate to sign esMD Initiative transactions and document bundles (as defined in the esMD Initiative Author of Record Level 1 Use Case). The certificate’s root Certificate Authority (CA) must be cross-certified with the FBCA at Medium Assurance or above. Additionally, the provider should authenticate to the signing module or application with at least one additional authentication factor prior to the actual signing event. Adding the additional factor meets NIST Level of Assurance (LOA) 3 and supports the non-repudiation assurances necessary for valid digital signatures. As technology options for both authentication and digital signing continue to evolve, the esMD Initiative should continue to monitor and update policies as appropriate to reflect improved technological capabilities.

The meetings to review the current standards, policies, alternatives and operational issues were conducted on the schedule outlined in the table below:

Table 1: SWG Meeting Schedule
 * ** Date ** ||  ** Topic **  ||  ** Deliverable(s) **  ||
 * September 26, 2012 || Standards || List and review of standards ||
 * October 3, 2012 || Standards and industry examples || List and review of additional standards industry examples ||
 * October 10, 2012 || Transaction and AoR digital signature and delegation process || Document digital signature and delegation of rights process ||
 * October 17, 2012 || Transaction and AoR signature and delegation artifacts || Document digital signature and delegation of rights artifacts ||
 * October 24, 2012 || Validation process for non-repudiation review || Document validation process with assurance of non-repudiation of signer and delegation(s) ||
 * October 31, 2012 || Gaps in policy and standards || Identify gaps in standards, process and policy and make recommendations ||
 * November 7-28, 2012 || Review SWG report || SWG report ||

=3.0 Requirements= The following specific requirements were provided by the esMD Initiative Author of Record workgroup: 1) Solution must 2) Appropriate portions of the following standards must be supported =4.0 Assumptions= The following assumptions were made by the DS/DR SWG as part of their consideration of the esMD AoR Use Case: =5.0 Review of Standards= The following standards, industry implementations, white papers and federal requirements were reviewed by this SWG as part of their review and deliberation.
 * 1) be implementable for pilot in Q1/Q2 of calendar year 2013.
 * 2) scale to all providers (any Individual or Organization that may submit a claim to a healthcare payer), healthcare payers, and agents for either party.
 * 3) minimize the operational impact required to establish, maintain or use a digital identity and digital signature.
 * 4) provide for validation and non-repudiation of the digital signature without resorting to audit logs or validation of system configuration.
 * 1) NIST 800-63-1 Level 3/4 (December 2011)
 * 2) NIST 800-57 Part 1 (Revision 3 July 2012)
 * 3) FederalBridge Certification Authority Medium Assurance Level
 * 4) X.509v3+ Digital Certificates
 * 1) All esMD Initiative transactions must be digitally signed and non-repudiable by their author.
 * 2) Document bundles must be digitally signed and non-repudiable by the responsible provider (the subject of the eMDR) or their designated agent.
 * 3) All delegation of rights to an agent must be cryptographically verifiable and non-repudiable.
 * 4) Multiple architectural solutions may exist for implementation of DS/DR that include:
 * National network – National services for authentication or complete AoR Level 1
 * Federated method – Local (e.g., EHR)
 * 1) Must comply with US government standards and regulations.
 * 2) All certificates must be issued to Individuals or Organizations and include their unique identification number (examples: Provider NPI, Health Plan HPID, Other Entity OEID, or EIN).
 * 3) The esMD Initiative Implementation Guides require digital signatures and delegation of rights artifacts for provider registration (UC 1), secure transmission of eMDRs (UC 2) and Author of Record Level 1.

Table 2: Digital Signatures Standards
 * Digital Signatures**
 * || ** Document Link **  ||  ** Title & Version / Notes **  ||  ** Date **  ||
 * ** Standards ** || [|ITI TF-1] || // IHE IT Infrastructure Technical Framework: Volume 1: Integration Profiles //, Revision 9.0 || Aug 31, 2012 ||
 * ^  || [|ITI TF-2a] || // IHE IT Infrastructure Technical Framework: Volume 2a: Transactions Part A – Sections 3.1-3.28 //, Revision 9.0 || Aug 31 2012 ||
 * ^  || [|ITI TF-2b] || // IHE IT Infrastructure Technical Framework: Volume 2b: Transactions Part B – Sections 3.29-3.51 //, Revision 9.0 || Aug 31 2012 ||
 * ^  || [|ITI TF-3] || // IHE IT Infrastructure Technical Framework: Volume 3: Cross-Transaction Specifications and Content Specifications //, Revision 9.0 || Aug 31 2012 ||
 * ^  || [|IHE DSG] || // IHE IT Infrastructure (ITI) Technical Framework Supplement Document Digital Signature, Trial Implementation Supplement // || Aug 10 2009 ||
 * ^  || [|NIST SP 800-63-1] || // Electronic Authentication Guideline // || Dec 2011 ||
 * ^  || [|OASIS DSS Core Spec] || // Digital Signature Service Core Protocols, Elements, and Bindings, Version 1.0 //

[|//All DSS Standards//] || Apr 11 2007 ||
 * ^  || [|XML DigSig] || // XML Signature Syntax and Processing (Second Edition), W3C Recommendation // || Jun 10 2008 ||
 * ^  || [|FIPS PUB 186-3] || // Digital Signature Standard // || Jun 2009 ||
 * ^  || [|IETF RFC 6277] || // Online Certificate Status Protocol Algorithm Agility // || Jun 2011 ||
 * ^  || [|IETF RFC 6283] || // Extensible Markup Language Evidence Record Syntax // || Jul 2011 ||
 * ^  || [|IETF RFC 5698] || // Data Structure for the Security Suitability of Cryptographic Algorithms // || Nov 2009 ||
 * ^  || [|IETF RFC 5280] || // Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List Profile // || May 2008 ||
 * ^  || [|IETF RFC 5276] || // Using the Server-Based Certificate Validation Protocol to Convey Long-Term Evidence Records // || Aug 2008 ||
 * ^  || [|IETF RFC 4998] || // Evidence Record Syntax // || Aug 2007 ||
 * ^  || [|IETF RFC 3851] || // Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 //// Message Specification // || July 2004 ||
 * ^  || [|FBCA X.509 Certificate Policy] || // X.509 Certificate Policy for the Federal Bridge Certification Authority //, Version 2.25 || Dec 9 2011 ||
 * ** Industry Implementations ** || [|21 CFR Parts 1305 and 1311], (DEA) || // Electronic Orders for Controlled Substances // || Apr 1 2005 ||
 * ^  || [|CertiPath X.509 Certificate Policy] || Version 3.18 || Apr 16 2012 ||
 * ** White Papers / Industry Reports ** || [|ABA IDM Task Force Submission to UNCITRAL] || // Overview of Identity Management. // Additional information found at the ABA’ [|//Federated Identity Management Legal Task Force//] page//.// ||  ||
 * ^  |||| [|//Digital Identity Management – Enabling Innovation and Trust in the Internet Economy//] (OECD). This paper is [|summarized here] and includes the following reports:
 * [|//Guidance on Digital Identity Management for Enabling Innovation and Trust in the Internet Economy//] (Nov 23, 2011)
 * [|//National Strategies and Policies for Digital Identity Management in OECD Countries//] (Mar 31, 2010)
 * [|//Role of Digital Identity Management in the Internet Economy: A Primer for Policy Makers//] (June 11, 2009)
 * [|//OECD Workshop on Digital Identity Management//] (May 8-9, 2007) || Winter 2011 ||
 * ^  || [|//Action Plan//] || EU Qualified Signatures (eSignatures) || Feb 23 2011 ||
 * ** Federal Requirements ** || [|RMH Vol III Standard 3-1 Authentication] || // CMS Risk Management Handbook Volume III, Standard 3.1: CMS Authentication Standards //, Version 1.2 || Jul 31 2012  ||

Table 3: Delegation of Rights Standards // Security Assertion Markup Language // // (SAML), Version 2.0 //
 * Delegation of Rights**
 * || ** Document Link **  ||  ** Title & Version / Notes **  ||  ** Date **  ||
 * ** Standards ** || [|OASIS SAML Assertions] || // Assertions and Protocols for the OASIS //

[|//All SAML v2.0 files//] || Mar 15 2005 || [|Changes Affecting Hospital and] [|Critical Access Hospital Conditions of] [|Participation: Telemedicine] [|Credentialing and Privileging] ||  ||
 * ^  || [|IETF RFC 3820] || // Internet X.509 Public Key Infrastructure Proxy Certificate Profile // || Jun 2004 ||
 * ^  || Federal Register, Vol 76, No 8742 CFR Part 482 and 485 || [|Medicare and Medicaid Programs:]
 * ^  || [|TJC Hospital Record of Care] || TJC standards are proprietary. ||   ||
 * ^  || [|IGTF OID Proxy Delegation Tracing] || International Grid Trust Federation OID Proxy Delegation Tracing || Feb 28 2008 ||
 * ** Industry Implementations ** || HIPAA Business Associate Agreement (BAA) || [|//HHS - Sample Business Associate Contract Provisions//]//, // Aug 14 2002

[|//OCR HIPAA Privacy - Business Associates//]//, // Apr 3, 2003 ||  || // Data Format for the Interchange of Fingerprint, Facial& Other Biometric Information, // Nov 2011 ||  ||
 * ^  || [|AFIS] (Automated Fingerprint Identification System) || [|//NIST SP 500-290//], //American National Standard for Information Systems -//
 * ^  || [|Daon, Inc] (Biometrics) || // Site requires registration. //[|//Knowledgebase//]// contains white papers, data sheets and case studies. // ||   ||
 * ^  || [|42 CFR Part 493 – Laboratory Requirements] || //Current CLIA Regulations // (html)

CLIA requirements for agents or authorized individuals ||  ||
 * ^  || [|FEMA First Responder Program] || (webpage only) ||   ||
 * ^  || No reference || Power of attorney / limited power of attorney ||   ||
 * ** Federal Requirements ** || [|RMH Vol III Standard 3-1 Authentication] || // CMS Risk Management Handbook Volume III, Standard 3.1: CMS Authentication Standards //, Version 1.2 || Jul 31 2012  ||
 * ** Unsorted ** || [|Safe-BioPharma] || Safe-BioPharma – Interoperable Digital Identity Management in the Electronic Exchange of Health Information ||  ||
 * ^  || [|CMS – Pilot] || CMS – Pilot Testing of Initial Electronic Prescribing Standards ||   ||
 * ^  || [|Study Report on Biometrics in E-Authentication] || // Study Report on Biometrics in E-Authentication, // International Committee for Information Technology Standards, Information Technology Industry Council || Mar 30 2007 ||

=6.0 Evaluation of Alternative Solutions for Delegation of Rights= The SWG reviewed a number of potential solutions to address the Delegation of Rights, including:
 * 1) Proxy Certificates,
 * 2) SAML Assertions, and
 * 3) Custom Assertions.

6.1 Proxy Certificates
Based on IETF 3280, a Proxy Certificate is derived from and signed by a normal X.509v3 public key or by another Proxy Certificate to provide restricted proxying and delegation within a PKI based authentication system. The following is excerpted from IETF 3280. A Proxy Certificate is an X.509v3 public key certificate with the following properties: The Proxy Certificate contains a new X.509v3 extension to identify it as a PC and to place policies on the use of the PC. This new extension, along with other X.509v3 fields and extensions, is used to enable proper path validation and use of the PC.
 * It is signed by either an X.509v3 End Entity Certificate (EEC), or by another PC. This EEC or PC is referred to as the Proxy Issuer (PI).
 * It can sign only another PC. It cannot sign an EEC.
 * It has its own public and private key pair, distinct from any other EEC or PC.
 * It has an identity derived from the identity of the EEC that signed the PC. When a PC is used for authentication, in may inherit rights of the EEC that signed the PC, subject to the restrictions that are placed on that PC by the EEC.
 * Although its identity is derived from the EEC's identity, it is also unique. This allows this identity to be used for authorization as an identity independent from the identity of the issuing EEC, for example in conjunction with attribute assertions.

6.2 SAML 2.0 Assertion
The following is a review of SAML 2.0 Security Assertion Markup Language:
 * SAML defines the syntax and processing semantics of assertions made about a subject by a system entity.
 * SAML assertions and protocol messages are encoded in XML [XML] and use XML namespaces [XMLNS].
 * The components primarily permit transfer of identity, authentication, attribute, and authorization information between autonomous organizations.
 * The core SAML specification defines the structure and content of both assertions and protocol messages used to transfer this information.
 * Assertions are usually created by an asserting party based on a request of some sort from a relying party, although under certain circumstances, the assertions can be delivered to a relying party in an unsolicited manner.

6.3 Custom Assertion
Creation of a custom assertion is an effective but non-standard solution for the Delegation of Rights. A custom assertion has the benefit of including only the required information for the delegation and may be considered an acceptable solution for some implementations of the esMD Initiative Transactions where the standard allows for the extension of transaction-associated metadata. The required assertion information consists of at least the following: If the server countersigning approach is utilized to ensure the assertion is valid at the time of a signature event by the recipient of the delegation of rights (see section 8.5), the specific encapsulation of the assertion, in addition to its contents, is also important.
 * 1) A globally unique ID for this assertion
 * 2) Issuer and X.509v3 serial number for both the originator and the recipient of the delegation
 * 3) Effective dates
 * 4) Purpose (from a defined code set)
 * 5) Optional URI of revocation list

6.4 Issues with Assertions
Unlike Proxy Certificates which may potentially utilize CRLs to indicate Proxy Certificates that have been revoked before they have expired, there is no equivalent solution for assertions. This is a potential concern, since the assertion allows the holder to sign on behalf of the grantor of the right until the expiration date. Solutions to this “problem” are discussed in section 8.5 below.

6.5 Summary of Alternatives
The following table summarizes the benefits, limitations and challenges with the above options for conveying Delegation of Rights as required by the esMD initiative.

Table 4: Summary of Alternative Delegation of Rights Options Does not require additional delegation artifacts (i.e., self-contained) Holds information for active date, purpose || Must be generated from End-user Certificate || Generation of Proxy Certificate is not supported by FBCA. No general support for trust chain from Proxy Certificates to antecedent Proxy Certificate or End-user Certificate Requires the delegation activity to be done with the specific Proxy Certificate Revocation process – who and how is it handled? || Easy to use (sign with own certificate and provide assertion as proof of right) Uses certificate verification to ensure identity of grantor and grantee || May not hold all required information without modification of standard || Revocation process – how is it handled? ||
 * || ** Benefits **  ||  ** Limitations **  ||  ** Challenges **  ||
 * **Proxy Certificate** || Understood form and use
 * **SAML Assertion** || Understood form and use
 * **Custom Assertion** || Contains only the information required for the delegation of rights assertion || Requires the inclusion of custom metadata or the extension of existing metadata to support || Not an accepted standard ||

=7.0 Recommended Solution for Digital Signatures= This SWG recommends a Digital Signature signing process compliant with FIPS PUB 186-3 using X.509v3 signing certificates with the non-repudiation bit set and issued according to the current //X.509 Certificate Policy for the Federal Bridge Certification Authority// and compliant with Medium Assurance requirements. The SWG also recommends that the signature artifact include at a minimum the information specified in section 7.2 below and verification of the signature by the recipient is conformant with the process described in section 7.3.

A hash function is used in the signature generation process to obtain a condensed version of the data to be signed; the condensed version of the data is often called a message digest. The message digest is input to the digital signature algorithm to generate the digital signature. The hash functions to be used are specified in the Secure Hash Standard (SHS), FIPS 180-3. FIPS **approved** digital signature algorithms **shall** be used with an appropriate hash function that is specified in the SHS.

The digital signature is provided to the intended verifier along with the signed data. The verifying entity verifies the signature by using the claimed signatory’s public key and the same hash function that was used to generate the signature.

7.1. Recommended Standards
The following standards are recommended as appropriate for esMD Digital Signatures.

Table 5: Recommended Standards for esMD Digital Signatures
 * ** Standard and Link ** || ** Issued by ** || ** Version / Date ** ||
 * [|**FBCA X.509 Certificate Policy**] || //X.509 Certificate Policy for the Federal Bridge Certification Authority//, Version 2.25 || Dec 9 2011 ||
 * [|**FIPS PUB 186-3**] || //Digital Signature Standard// || Jun 2009 ||

7.2. Digital Signature Artifacts for esMD Transactions and AoR Level 1
Digital signatures must conform to the requirements of FIPS 186-3.

When signing an esMD Initiative Transaction, the Implementation Guide shall specify:
 * 1) the portion of the transaction that must be signed
 * 2) the method used to create the digest of the signed portion
 * 3) the use of the X.509v3 private key to encrypt the digest
 * 4) how to include the following elements in the transaction:
 * 5) the encrypted digest, and
 * 6) the public X.509v3 digital certificate corresponding to the X.509v3 private key used to encrypt the digest

When signing an esMD AoR Level 1 Document Bundle, the Implementation Guide shall specify:
 * 1) that all documents included in the Document Bundle shall be included in creating the digest to be signed the method used to create the digest of the complete Document Bundle
 * 2) the creation of a signing artifact that at a minimum must include
 * 3) the digest of the Document Bundle
 * 4) the signature Date/Time (GMT), and
 * 5) the purpose of the signature (from an appropriate standard code set)
 * 6) to include the following elements in the transaction
 * 7) the AoR Level 1 Document Bundle,
 * 8) the signature artifact, and
 * 9) the public X.509v3 digital certificate corresponding to the X.509v3 private key used to encrypt the digest

7.3. Verification of Digital Signature and Data Integrity
The recipient of the esMD Initiative Transaction or the esMD AoR Level 1 Document Bundle shall perform the following validation to authenticate the signer and the signed information:
 * 1) Validate the X.509v3 Digital Certificate(s) by verifying that:
 * 2) the certificate is current
 * 3) it has been issued for a purpose acceptable to esMD
 * 4) the trust anchor is acceptable for esMD by verifying the complete chain to a CA root certificate or Federal common policy CSP
 * 5) the altName field includes the required NPI or Alternative Payer ID identification
 * 6) it has not been revoked by verifying that the certificate is not on the certificate revocation list
 * 7) Decrypt the signed digest or signature artifact with public key
 * 8) Compute the digest of transaction or document bundle
 * 9) Verify that the signed digest matches computed digest
 * 10) For the document bundle, verify that
 * 11) the signature date is appropriate
 * 12) the signature purpose is appropriate

Figure 1: Signature Artifact Example

7.4. Non-Repudiation
All X.509v3 signing certificates issued by CSPs/CAs cross-certified with the FBCA for use with esMD must have the non-repudiation bit set. Management and use of these signing certificates in conformance with the FBCA Medium Assurance requirements and recommendations in NIST 800-57 and the recommendations of the esMD AoR SWG white papers permits the recipient of the appropriately signed transaction and document bundle, once verified as described in section 7.3 of this document, to consider the signatures and content non-repudiable as established by standards cited in Section 7.1. =8.0 Recommended Solution for Delegation of Rights= To convey, to a third party, the delegation of rights between the holder of a right and the Individual or Organization that has been delegated the right by the holder, this SWG recommends the use of an assertion conformant with the SAML Assertion Version 2.0.

8.1. Recommended Standards
The following standard is recommended as appropriate for esMD Delegation of Rights.

Table 6: Recommended Standards for esMD Delegation of Rights
 * ** Standard and Link ** || ** Issued by ** || ** Version / Date ** ||
 * [|**OASIS SAML Assertions**] || **//Assertions and Protocols for the OASIS//**
 * //Security Assertion Markup Language//**
 * //(SAML), Version 2.0//** || **Mar 15 2005** ||

8.2. Delegation of Rights Artifact for Transaction and AoR Level 1
The SAML Assertion should be created at the time the delegation of the right (e.g., the ability to register the provider for a healthcare payer service) is made by the holder of the right and contain at a minimum the following information: A digest of the entire assertion must be signed by the grantor of the right.
 * 1) A globally unique ID for this assertion
 * 2) The issuer and serial number of the current X.509v3 signing certificate of the right grantor (the private key of which must be used to sign the assertion)
 * 3) The issuer and serial number of the current X.509v3 signing certificate of the recipient of the right (the recipient must use the private key of this certificate to sign transactions and documents when acting under the authority of the delegation of rights assertion)
 * 4) The valid dates for the grant
 * 5) The right that is granted (note: SWG recommends that an appropriate, computable list of rights should be created and used for this purpose)
 * 6) A URI to an assertion revocation list (if the assertion will not be countersigned)

When transmitting information to a third party that includes an assertion for the grant of a right, the sending system must include in the transaction:
 * 1) The public X.509v3 signing certificate of the grantor of the right
 * 2) The signed assertion
 * 3) The public X.509v3 signing certificate of the Individual or Organization to whom the right was granted (as defined in the assertion)
 * 4) Optionally but recommended,
 * 5) Public X.509v3 signing certificate of the system that verified that the assertion is currently valid
 * 6) the method used to create the digest of the complete Document Bundle
 * 7) the creation of a signing artifact that at a minimum must include
 * 8) the digest of the signed assertion
 * 9) the signature Date/Time (GMT) and
 * 10) the purpose of signature (validation of the assertion)

Figure 2: Delegation of Rights Example 1

8.3. Verification of Delegation of Rights
The recipient of the esMD Initiative Transaction or the esMD AoR Level 1 Document Bundle that includes a delegation of rights shall perform the following validation:
 * 1) Validate the X.509 Digital Certificate of the assertion signer by verifying that:
 * 2) the certificate is current
 * 3) it has been issued for a purpose acceptable to esMD
 * 4) the trust anchor is acceptable for esMD by verifying the complete chain to a CA root certificate or Federal common policy CSP
 * 5) the altName field includes the required NPI or Alternative Payer ID identification
 * 6) it has not been revoked by verifying that the certificate is not on the certificate revocation list
 * 7) Decrypt the signed digest or signature artifact with public key
 * 8) Compute the digest of assertion
 * 9) Verify that the signed digest matches the computed digest
 * 10) Verify that the assertion was valid when used
 * 11) Verify that the right(s) delegated in the assertion are appropriate
 * 12) Verify that one of the following is true
 * 13) The assertion is for a one time purpose
 * 14) The assertion is valid only for the date/time of the signature
 * 15) The assertion has a valid URI for a revocation list and the assertion is not on the list
 * 16) The assertion and its signature are countersigned by a trusted system (e.g. via a server certificate associated with the grantor of the right that includes in the countersigned signature artifact
 * 17) the digest of signed assertion (verify as above)
 * 18) the signature Date/Time (GMT) (same as the signature date/time by the holder of the right), and
 * 19) the purpose of the signature (validation of the assertion)

Figure 3: Delegation of Rights Example 2

8.4. Non-Repudiation
By using X.509v3 signing certificates issued by CSPs/CAs cross-certified with the FBCA for use with esMD that have the non-repudiation bit set, all assertion message digests signed with the private key allow the recipient to consider the signatures and assertion non-repudiable as established by standards cited in this document. =9.0 Gaps= Gaps exist in current standards, policies and operational processes that must be addressed to implement the recommendations from this SGW. Satisfying these gaps is work that should be undertaken during 2013 to support the digital signature and delegation of rights requirements of esMD Use Case 1 (Provider Registration), Use Case 2 (secure transmission of the eMDR) and the Author of Record implementation guides. These gaps include//:// =10.0 Risks, Issues and Obstacles= The following potential risks, issues and obstacles with regard to the DS/DR recommended were identified by this SWG:
 * 1) Selecting appropriate standards for digital signatures in the esMD transaction that clearly support the transmission of the public certificate and the message signature artifact (signed digest of the message).
 * 2) Selecting appropriate standards for digital signatures on document bundles that, ideally, provide transport-independent support for public certificates and document signature artifacts (signed digest of message, timestamp, and purpose of signature).
 * 3) Selecting appropriate standards for delegation of rights assertions for both messages and document bundle signatures that include, at a minimum, issuer and certificate serial number of both parties, the purpose of the delegation, the effective date range, and the optional location of a revocation list. Any transaction must include the public certificate of the delegator.
 * 4) Validation via pilots for the appropriate verification of the currency of a delegation of rights artifact (e.g. one time use, countersigned by the system on use or a CRL equivalent revocation process).
 * 5) Providing for long-term access to CSP/CA root certificates and revocation lists or a transaction that can confirm that a certificate was valid (and not revoked) on a particular date/time.
 * 6) Support by provider, payers and agents for the recommended signature and delegation of rights standards.


 * # A. Time and cost to support DS/DR for providers, payers, agents and contractors
 * 1) B. Transaction overhead to send the public certificate, signature artifact(s) and delegation of rights artifact(s)
 * 2) C. Processing time to validate digital signatures and delegation of rights
 * 3) D. Long-term storage of public certificate, signature artifact(s) and delegation of rights artifact(s) by all involved parties
 * 4) E. Long-term ability to validate that a certificate was not revoked when it was used in a signing event
 * 5) F. Limited adoption by the current provider and payer community
 * 6) G. Limited use of current standards of digital signatures and delegation of rights in healthcare
 * 7) H. Limited adoption by providers and payers
 * 8) I. Use of the SAML assertion for delegation of rights, while supported by the SAML architecture, is not currently employed in the healthcare industry. ||

=Appendices=

Appendix A: Glossary

 * 1) ** Authentication (NIST) ** - Security measure designed to establish the validity of a transmission, message, or originator, or a means of verifying an individual's authorization to receive specific categories of information. [NS4009]
 * 2) ** Author (of Record) ** - The individual that creates a record.
 * 3) ** Certificate Authority (NIST) ** - An authority trusted by one or more users to issue and manage X.509 Public Key Certificates and CARLs or CRLs.
 * 4) ** Credential ** (NIST) - An object or data structure that authoritatively binds an identity (and, optionally, additional attributes) to a token possessed and controlled by a Subscriber.
 * 5) ** Credentialing ** – the process by which personal or professional information about an Individual or Organization is verified by a third party.
 * 6) ** Data Integrity (NIST) ** - A property whereby data has not been altered in an unauthorized manner since it was created, transmitted or stored. Alteration includes the insertion, deletion and substitution of data.
 * 7) ** Decryption ** - The reverse process of encryption, i.e., to make the encrypted information readable again.
 * 8) ** Delegation of Rights ** - The ability to delegate rights or authority to another to act in a specific capacity on behalf of the grantor of the right.
 * 9) ** Digest ** – The result of applying a hash function to a message. Also known as “hash value.” A hash function is a function that maps a bit string of arbitrary length to a fixed length bit string. Approved hash functions are specified in FIPS 180-3 and are designed to satisfy the following properties: (1) (One-way) it is computationally infeasible to find any input that maps to any new pre-specified output, and (2) (Collision resistant) it is computationally infeasible to find any two distinct inputs that map to the same output.
 * 10) ** Digital Certificate (NIST) ** - A digital representation of information which at least (1) identifies the certification authority issuing it, (2) names or identifies its subscriber, (3) contains the subscriber's public key, (4) identifies its operational period, and (5) is digitally signed by the certification authority issuing it.
 * 11) ** Digital ID Management ** - A trusted authority is responsible for creating the key pair, distributing the private key, publishing the public key and revoking the keys as necessary. The “Passport Office” of the Digital World. The keys and their associated information (e.g. Digital Certificate) are typically stored as software tokens, browser certificate stores, and hardware tokens (Smart Cards, USB Tokens).
 * 12) ** Digital Signatures ** - An artifact appended to a record as a result of a user’s intended action wherein that memorializes a signing event by a process that digitally signs a document or transaction using the private key component of his certificate.(From NIST - The result of a transformation of a message by means of a cryptographic system using keys such that a Relying Party can determine: (1) whether the transformation was created using the private key that corresponds to the public key in the signer’s digital certificate; and (2) whether the message has been altered since the transformation was made.) (From 800-63-1 an asymmetric key operation where the private key is used to digitally sign data and the public key is used to verify the signature. Digital signatures provide authenticity protection, integrity protection, and non-repudiation).
 * 13) ** Encryption ** - In cryptography, encryption is the process of transforming information (referred to as plaintext) using an algorithm (called a cipher) to make it unreadable to anyone except those possessing special knowledge, usually referred to as a key.
 * 14) ** Identity ** - A unique name of an Individual or Organization. Since the legal names of an Individual or Organization are not necessarily unique, the ID must include sufficient additional information (for example an address and NPI number) to make the complete name unique.
 * 15) ** Identity Proofing ** - The process by which the credential issuer validates sufficient information to uniquely identify an Individual or Organization applying for the credential. It proves that the ID exists, proves the applicant is entitled to that ID, and addresses the potential for fraudulent issuance of credentials based on collusion.
 * 16) ** Non-repudiation (NIST) ** - A service that is used to provide assurance of the integrity and origin of data in such a way that the integrity and origin can be verified by a third party. This service prevents an Individual or Organization from successfully denying involvement in a previous action.
 * 17) ** Public Key Infrastructure ** - A set of policies, processes, server platforms, software and workstations used for the purpose of administering certificates and public-private key pairs, including the ability to issue, maintain, and revoke public key certificates.
 * 18) ** Registration Authority (NIST) ** - An entity that is responsible for identification and authentication of certificate subjects, but that does not sign or issue certificates.
 * 19) ** X.509v3+ ** - Includes X.509 version 3 and all subsequent versions [RFC 5280 and its predecessors]

Appendix B: References

 * [|CMS Internet Only Manuals (IOM)]
 * [|ELECTRONIC SIGNATURES IN GLOBAL AND NATIONAL COMMERCE ACT]
 * [|Recommendation for Obtaining Assurances for Digital Signature Applications]
 * OMB 04-04
 * [|Records Management Guidance For PKI Digital Signature Authenticated and Secured Transaction Records]

Appendix C: Copyright Acknowledgement
Excerpts from Internet Society documents included above are allowed based on the following:

Copyright (C) The Internet Society (2002). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING

BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

include component="page" wikiName="siframework" page="space.template.inc_contentleft_end"