Presentation Transcript

1. Electronic Submission of Medical Documentation (esMD)Identity Proofing Sub-Workgroup

   September 26, 2012
2. Sub Workgroup: Identity Proofing Deliverable: “Summary White Paper” Assumptions Statement of Problem Recommended Solution(s) Review of Standards (e.g. NIST, FICAM, FBCA) Certification requirements for RAs Proof of identity requirements for Entities Individuals Allowed proofing processes (e.g. as part of credentialing?) Frequency of Identity review Appeals process for denial Variation based on specific credentials/use? Revocation (triggers and process) Identify gaps in current policy impacting Identity Proofing References Goal Define required process for identity proofing of healthcare individuals and organizations for esMD Requirements NIST SP 800-63-1 Level 3 authentication (December 2011) Federal Bridge Certification Authority Medium Level In-Scope RA qualifications and certification Combining RA process with other healthcare identity proofing (e.g. credentialing) Policy issues regarding identity proofing Out-of-Scope Digital Credential Management Digital Signatures Delegation of Rights
3. Schedule for Identity Proofing SWG
4. Definitions Identity (NIST) A set of attributes that uniquely describe a person within a given context. Identity (Proposed) A set of attributes that uniquely describe a person or legal entity within a given context. Identity Proofing (NIST) The process by which a Credential Service Provider (CSP) and a Registration Authority (RA) collect and verify information about a person for the purpose of issuing credentials to that person. Identity Proofing (Proposed) The process by which a Credential Service Provider (CSP) and a Registration Authority (RA) collect and verify information about a person or legal entity for the purpose of issuing credentials to that person or legal entity.
5. General Requirements Solution must be implementable for pilot in Q1/Q2 2013 scale to all providers and payers minimize the operational impact required to establish , maintain or use a digital identity provide for non-repudiation without resorting to audit logs or validation of system configuration Standards -- required NIST 800-63-1 Level 3 (December 2011) NIST 800-57 Part 1 (Revision 3 July 2012) Federal Bridge Certification Authority Medium Level X.509v3+ Digital Certificates
6. Standards for Identity Proofing
7. NIST 800-63-1 Separation of RA and CSP functions A common reason for breaking up the registration process as described above is to allow the subscriber to register or obtain tokens for use in two or more environments. This is permissible as long as the tokens individually meet the appropriate assurance level. However, if the exact number of tokens to be issued is not agreed upon early in the registration process, then the tokens should be distinguishable so that Verifiers will be able to detect whether any suspicious activity occurs during the first few uses of a newly issued token. If a valid credential has already been issued, the CSP may issue another credential of equivalent or lower assurance. In this case, proof of possession and control of the original token may be substituted for repeating the identity proofing steps. (This is a special case of a derived credential. See Section 5.3.5 for procedures when the derived credential is issued by a different CSP.) Any requirements for credential delivery at the appropriate Level shall still be satisfied.
8. NIST 800-63-1 Level 2 Identity Proofing Requirements
9. NIST 800-63-1 Level 3 Identity Proofing Requirements
10. NIST 800-63-1 Level 4 Identity Proofing Requirements
11. FBCA Identification Requirements by Assurance Level
12. PIV For compliance with the PIV-I control objectives, departments and agencies shall follow an identity proofing and registration process that meets the requirements defined below when issuing identity credentials. 5 PERSONAL IDENTITY VERIFICATION (PIV) OF FEDERAL EMPLOYEES AND CONTRACTORS + The organization shall adopt and use an approved identity proofing and registration process. + The process shall begin with initiation of a National Agency Check with Written Inquiries (NACI) or other Office of Personnel Management (OPM) or National Security community investigation required for Federal employment. This requirement may also be satisfied by locating and referencing a completed and successfully adjudicated NACI. At a minimum, the FBI National Criminal History Check (fingerprint check) shall be completed before credential issuance. Beginning with Part 2, Identity credentials issued to individuals without a completed NACI or equivalent must be electronically distinguishable from identity credentials issued to individuals who have a completed investigation. Appendix C, Background Check Descriptions, provides further details on NAC and NACI. + The applicant must appear in-person at least once before the issuance of a PIV credential. + During identity proofing, the applicant shall be required to provide two forms of identity source documents in original form. The identity source documents must come from the list of acceptable documents included in Form I-9, OMB No. 1115-0136, Employment Eligibility Verification. At least one document shall be a valid State or Federal government-issued picture identification (ID). + The PIV identity proofing, registration and issuance process shall adhere to the principle of separation of duties to ensure that no single individual has the capability to issue a PIV credential without the cooperation of another authorized person. The identity proofing and registration process used when verifying the identity of the applicant shall be accredited by the department or agency as satisfying the requirements above and approved in writing by the head of the Federal department or agency. Two examples of processes that meet these requirements are provided in Appendix A, PIV Processes.

13. Electronic Submission of Medical Documentation (esMD)Digital Signature and Delegation of Rights Sub-Workgroup

    September 26, 2012
14. Schedule for Identity Proofing SWG
15. Definitions Digital Signature (NIST) The result of a cryptographic transformation of data that, when properly implemented, provides a mechanism for verifying origin authentication, data integrity and signatory non-repudiation. Data Integrity (NIST) Data integrity is 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. Non-repudiation (NIST) Non-repudiation is 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 entity from successfully denying involvement in a previous action. 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. Must include the digital identity of the grantor, the digital identity of the grantee, the rights granted, duration of grant in a format that is usable in transaction and AoR signature events and is verifiable by a third party for non-repudiation purposes.
16. General Requirements Solution must be implementable for pilot in Q1/Q2 2013 scale to all providers and payers minimize the operational impact required to establish , maintain or use a digital identity provide for non-repudiation without resorting to audit logs or validation of system configuration Standards -- required NIST 800-63-1 Level 3 (December 2011) NIST 800-57 Part 1 (Revision 3 July 2012) Federal Bridge Certification Authority Medium Level X.509v3+ Digital Certificates
17. Sub Workgroup: Digital Signatures Deliverable: “Summary White Paper” Assumptions Statement of Problem Recommended Solution(s) Review of Standards (e.g. OASIS, IHE, HL7, …) Transaction signature process Transaction artifacts to meet Use Case 1 and 2 requirements Document Bundle signature process Artifacts to meet AoR L1 requirements Data Integrity requirements Non-repudiation assurance Identify gaps in current policy impacting Digital Signatures References Goal Define process, artifacts and standards for transaction and document bundle digital signatures for esMD Requirements Must provide for non-repudiation as part of the credentials and artifacts Must ensure data integrity In-Scope Use Case 1 and 2 transactions AoR L1 (Signature binding to aggregated document bundle) Signature workflow Signature artifacts Identification of relevant standards Out-of-Scope AoR L2 AoR L3
18. Sub Workgroup: Delegation and Proxy Deliverable: “Summary White Paper” Assumptions Statement of Problem Recommended Solution(s) Review of Standards (e.g. OASIS, IHE, HL7, …) Proxy/Delegation Credential/Artifact(s) Operational consideration for Proxy/Delegation Creation Scope/Content of Proxy/Delegation Revocation of Proxy Credential Transaction proxy requirements Transaction artifacts to meet Use Case 1 requirements Document Bundle proxy signature process Artifacts to meet AoR L1 signature proxy requirements Data Integrity requirements Non-repudiation assurance Identify gaps in current policy impacting Delegation & Proxy References Goal Define credentials, artifacts and process for Delegation of Rights for esMD Requirements Must provide for non-repudiation (NIST definition) as part of the credentials and artifacts Revocable In-Scope Use Case 1 and AoR L1 Delegation of Rights requirements Delegation/Proxy workflow Delegation/Proxy artifacts Identification of relevant standards Out-of-Scope AoR L2 AoR L3
19. Standards for Digital Signatures and Delegation of Rights
20. Assumptions AoR Level 1 Source record for episode of care exists and has been finalized Need to address externally provided records (e.g. from another provider) that are the basis for a decision Need to address transition to digital signature (probably applies to AoR Level 2 and 3
21. W3C XMLdigsig This document specifies XML digital signature processing rules and syntax. XML Signatures provide integrity, message authentication, and/or signer authentication services for data of any type, whether located within the XML that includes the signature or elsewhere. Integrity "The property that data has not been changed, destroyed, or lost in an unauthorized or accidental manner." [SEC] A simple checksum can provide integrity from incidental changes in the data; message authentication is similar but also protects against an active attack to alter the data whereby a change in the checksum is introduced so as to match the change in the data.  Object Authentication, Message The property, given an authentication code/protected checksum, that tampering with both the data and checksum, so as to introduce changes while seemingly preserving integrity, are still detected. "A signature should identify what is signed, making it impracticable to falsify or alter either the signed matter or the signature without detection." [Digital Signature Guidelines, ABA]. Authentication, Signer The property that the identity of the signer is as claimed. "A signature should indicate who signed a document, message or record, and should be difficult for another person to produce without authorization." [Digital Signature Guidelines, ABA] Note, signer authentication is an application decision (e.g., does the signing key actually correspond to a specific identity) that is supported by, but out of scope, of this specification.
22. FIPS – 186 (Digital Signature Standards) INTRODUCTION .................................................................................................................................. 1 2. GLOSSARY OF TERMS, ACRONYMS AND MATHEMATICAL SYMBOLS ....................................... 2 2.1 TERMS AND DEFINITIONS ................................................................................................................ 2 2.2 ACRONYMS ................................................................................................................................... 5 2.3 MATHEMATICAL SYMBOLS................................................................................................................6 3. GENERAL DISCUSSION....................................................................................................................... 9 3.1 INITIAL SETUP ............................................................................................................................... 11 3.2 DIGITAL SIGNATURE GENERATION.................................................................................................. 12 3.3 DIGITAL SIGNATURE VERIFICATION AND VALIDATION ....................................................................... 13 THE DIGITAL SIGNATURE ALGORITHM (DSA) ............................................................................... 15 4.1 DSA PARAMETERS........................................................................................................................ 15 4.2 SELECTION OF PARAMETER SIZES AND HASH FUNCTIONS FOR DSA ................................................ 15 4.3 DSA DOMAIN PARAMETERS........................................................................................................... 16 4.3.1 Domain Parameter Generation......................................................................................17 4.3.2 Domain Parameter Management...................................................................................17 4.4 KEY PAIRS .................................................................................................................................. 17 4.4.1 DSA Key Pair Generation..............................................................................................17 4.4.2 Key Pair Management ...................................................................................................18 4.5 DSA PER-MESSAGE SECRET NUMBER........................................................................................... 18 4.6 DSA SIGNATURE GENERATION ...................................................................................................... 19 4.7 DSA SIGNATURE VERIFICATION AND VALIDATION............................................................................ 19 5. THE RSA DIGITAL SIGNATURE ALGORITHM.................................................................................. 22 5.1 RSA KEY PAIR GENERATION ......................................................................................................... 22 5.2 KEY PAIR MANAGEMENT ................................................................................................................ 23 5.3 ASSURANCES...............................................................................................................................23 5.4 ANS X9.31 ................................................................................................................................ 23 5.5 PKCS #1 ................................................................................................................................... 24 6. THE ELLIPTIC CURVE DIGITAL SIGNATURE ALGORITHM (ECDSA).............................................26 6.1 ECDSA DOMAIN PARAMETERS...................................................................................................... 26 6.1.1 Domain Parameter Generation......................................................................................26 6.1.2 Domain Parameter Management...................................................................................28 6.2 PRIVATE/PUBLIC KEYS .................................................................................................................. 28 6.2.1 Key Pair Generation.......................................................................................................28 6.2.2 Key Pair Management ...................................................................................................29 6.3 SECRET NUMBER GENERATION...................................................................................................... 29 6.4 ECDSA DIGITAL SIGNATURE GENERATION AND VERIFICATION ........................................................ 29 6.5 ASSURANCES...............................................................................................................................30 APPENDIX A: GENERATION AND VALIDATION OF FFC DOMAIN PARAMETERS ........................... 31
23. Additional Material – esMDAoR Reference from prior AoR call materials
24. esMD Initiative Overview Registration Authority Certificate Authority Provider Directories Gateway Provider Entity Payer Entity esMD UC 1: Provider Registration Contractors / Intermediaries Agent esMD UC 2: Secure eMDR Transmission Provider (Individual or Organization) Payer Payer Internal System esMD AoR Level 1 Digital Identities Bundle Signatures
25. AoR -- Phased Scope of Work Level 1 – Current Focus Focus is on signing a bundle of documents prior to transmission to satisfy an eMDR Define requirements for esMD UC 1 and UC 2 Signature Artifacts May assist with EHR Certification criteria in the future Digital signature on aggregated documents (bundle) Level 2 - TBD Digital signature on an individual document Focus is on signing an individual document prior to sending or at the point of creation by providers Will inform EHR Certification criteria for signatures on patient documentation Level 3 - TBD Digital signature to allow traceability of individual contributions to a document Focus is on signing documents and individual contributions at the point of creation by providers Will inform EHR Certification criteria for one or multiple signatures on patient documentation
26. Topics for Digital Identities and AoR Workgroup Effort Identity proofing Digital identity management Encryption Digital signatures and artifacts Delegation of Rights Author of Record
27. Initiative Requirement Summary
28. esMD Requirements * Required if the action of the responsible party is being represented by a third party
29. Scope for AoR (L1) Out of Scope Interactions between: Payer and Payer Contractors Provider and Agent Payer or Payer Contractor and Gateway Transaction level encryption Document level signatures and individual contribution signatures Defining delegation of rights within and between Providers and other authors In Scope Identify Proofing as part of Non-Repudiation of Actor Identity Digital Credential Management required for Non-Repudiation Actions (Signingand Delegation), Data Integrity and Encryption Digital Signatures and Signature Artifacts for Identity and Non-Repudiation Digital Credentials and Artifacts for Non-Repudiation of Delegation as required by UC1 and AoR L1 Data Integrity requirement actions and artifacts Encryption of PHI requirements Interactions with External Provider Directories
30. User Story / Workflow Overall User Story Components All Actors obtain and maintain a non-repudiation digital identity Provider registers for esMD (see UC1)* Payer requests documentation (see UC2)* Provider submits digitally signed document (bundle) to address request by payer Payer validates the digital credentials, signature artifacts and, where appropriate, delegation of rights *User Stories for UC 1 and 2 have already been defined. Workgroup will help define bullets 1) and 4)
31. Sub-Workgroups