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

1. Electronic Submission of Medical Documentation (esMD)Identity Proofing Sub-Workgroup October 3, 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. DEA Example • Physicians have the option of e-prescribing controlled substances as of June 1, 2010, if they comply with specific requirements, as described below. • Physicians must first undergo a verification process (either in person or remotely) in order to receive authorization to e-prescribe controlled substances. • Access controls must be established prior to e-prescribing controlled substances. • Physicians must use a two-factor credential to e-prescribe controlled substances. • Physicians must comply with notification requirements if they lose their hard token or if they discover that their security controls have been compromised. • Physicians must use a compliant e-prescribing application in order to e-prescribe controlled substances. • Source: http://www.ama-assn.org/ama1/pub/upload/mm/399/dea-eprescriptions-final-rule-summary.pdf

14. DEA Example • Identity Proofing • Authentication must occur by an authorized third party (federally approved credential service provide (CSP) or CAs) • CSPs and CAs are required to conduct identity proofing at NIST SP 800-63-1 Assurance Level 3 (requiring either in-person or remote identity proofing) • Logical access controls are set after authentication credentials are issued, which verifies that the authenticated user has the authority to perform the requested operation (may be role-based). • Someone other than the prescriber needs to authenticate the prescriber • Credentialing can also be completed in-house within a hospital credential office, but two people must be responsible for this • Verification of identity is required via two-factor authentication • If a hard token is used, it must be a cryptographic device or meet the Federal Information Processing Standard 140-2 Security Level 1 • Physicians can use their own digital certificate to sign eRxs for controlled substances, and can be used as part of the two-factor authentication as long as the certificate is from a CA cross-certified with the FBCA at the basic assurance level (this is being confirmed)

16. DEA Example • Under the IFR, e-prescribers must prove their identities using two of the three following factors: • Something you know, such as a password or response to a challenge question; • Something you have, such as a hard token or device separate from the computer; or • Something you are, such as biometric data.

17. DIRECT • Key Concepts of the DIRECT project (from presentation by John Hall) • Direct enables push-based transport – a sender pushes information to one or more recipients • Direct Messages act as containers of health information • Direct Addresses are used to route Direct Messages • Digital certificates are used to protect Direct Messages in transit and to express trust relationships • SMTP is used to transport Direct Messages • Security/Trust Agents (STAs) such as Health Information Service Providers (HISPs) are responsible for providing the services necessary for exchange using Direct

18. DIRECT • Each Direct Address must have at least one X.509v3 digital certificate associated with it • Address-bound certificate – certificate tied to a specific Direct Address • Domain-bound certificate – certificate tied to the Domain that is part of a Direct Address (also known as organizationally-bound certificate) • Digital certificates are used within Direct to secure Direct Messages in transit and to express trust relationships • Certificates in Direct are not intended to be used to protect data at rest or to provide legal non-repudiation through signing of content. • Certificates in Direct are used for both encryption and signing • Encryption protects data from access by attackers and restricts access to data to receiving STA • Signing provides integrity protection and “good enough” non-repudiation for transport (signature ties sending STA to transaction)

19. DIRECT • Trust relationships are expressed using digital certificates. A party may choose to trust a specific certificate, as well as any certificate that cryptographically chains to a trust anchor. • Certificates are issued only to parties that agree to abide by specified trust policies. These policies often cover: • Certificate applicability (i.e., purposes for which certificates are issued) • Identity verification of parties • Security requirements of parties • Setting trust policy is outside the domain of the Direct Project. • For health information exchange, policy originates with the HITPC and ONC • Communities may further build upon those policies

20. DIRECT • Direct Project does not require particular policies or processes for identity proofing • Matter of policy that is outside scope of Direct Project • All states, implementing communities, and national HISPs do require entities seeking to enroll to provide identifying information. Information required is based on: • What is needed to obtain a certificate • What is needed to establish a foundation of trust between exchange participants

21. Electronic Submission of Medical Documentation (esMD)Digital Signature and Delegation of Rights Sub-Workgroup October 3, 2012

22. Schedule for Identity Proofing SWG

23. 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.

24. 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/4 (December 2011) • NIST 800-57 Part 1 (Revision 3 July 2012) • Federal Bridge Certification Authority Medium Level • X.509v3+ Digital Certificates

25. 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

26. 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

27. Standards for Digital Signature and Delegation of Rights

28. 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

29. 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.

30. 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

31. Review of W3C XMLdigsig • XML Signatures are applied to arbitrary digital content (data objects) via an indirection. • Data objects are digested, the resulting value is placed in an element (with other information) and that element is then digested and cryptographically signed. • XML digital signatures are represented by the Signature element which has the following structure (where "?" denotes zero or one occurrence; "+" denotes one or more occurrences; and "*" denotes zero or more occurrences): <Signature ID?> <SignedInfo> <CanonicalizationMethod/> <SignatureMethod/> (<Reference URI? > (<Transforms>)? <DigestMethod> <DigestValue> </Reference>)+ </SignedInfo> <SignatureValue> (<KeyInfo>)? ( <Object ID?>)* </Signature>

32. Review of W3C XML DigSig • Signatures are related to data objects via Uniform Resource Identifiers (URIs) • Within an XML document, signatures are related to local data objects via fragment identifiers • Local data can either be within an enveloping signature (parent) or be an enclosed enveloped signature (child) • Detached signatures can be utilized over external network resources or local data objects residing within the same XML document as sibling elements • Care should be taken to avoid collisions violating the ID uniqueness validity constraint by choosing different names for the signature element and other elements such as the ID

33. W3C XML DigSig Required element consists of two processes: Validation of Signature and Validation of Each Reference Indicates the key to be used to validate the signature

34. W3C XML DigSig • [s02-12] The required SignedInfo element is the information that is actually signed. Core validation of SignedInfo consists of two mandatory processes: validation of the signature over SignedInfo and validation of each Reference digest within SignedInfo. Note that the algorithms used in calculating the SignatureValue are also included in the signed information while the SignatureValue element is outside SignedInfo. • [s03] The CanonicalizationMethod is the algorithm that is used to canonicalize the SignedInfo element before it is digested as part of the signature operation. Note that this example, and all examples in this specification, are not in canonical form. • [s04] The SignatureMethod is the algorithm that is used to convert the canonicalizedSignedInfo into the SignatureValue. It is a combination of a digest algorithm and a key dependent algorithm and possibly other algorithms such as padding, for example RSA-SHA1. The algorithm names are signed to resist attacks based on substituting a weaker algorithm. To promote application interoperability we specify a set of signature algorithms that MUST be implemented, though their use is at the discretion of the signature creator. We specify additional algorithms as RECOMMENDED or OPTIONAL for implementation; the design also permits arbitrary user specified algorithms. • [s05-11] Each Reference element includes the digest method and resulting digest value calculated over the identified data object. It also may include transformations that produced the input to the digest operation. A data object is signed by computing its digest value and a signature over that value. The signature is later checked via reference and signature validation. • [s14-16] KeyInfo indicates the key to be used to validate the signature. Possible forms for identification include certificates, key names, and key agreement algorithms and information -- we define only a few. KeyInfo is optional for two reasons. First, the signer may not wish to reveal key information to all document processing parties. Second, the information may be known within the application's context and need not be represented explicitly. Since KeyInfo is outside of SignedInfo, if the signer wishes to bind the keying information to the signature, a Reference can easily identify and include the KeyInfo as part of the signature.

35. Review of Proxy Certificate Standards • IETF 3280 • Proxy Certificate: A certificate that is derived from, and signed by, a normal X.509 Public Key End Entity Certificate or by another Proxy Certificate to provide restricted proxying and delegation within a PKI based authentication system

36. Proxy Certificate (PC) Standards • A Proxy Certificate is an X.509 public key certificate with the following properties: • It is signed by either an X.509 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 independent identity from the identity of the issuing EEC, for example in conjunction with attribute assertions as defined in [i3]. • It contains a new X.509 extension to identify it as a PC and to place policies on the use of the PC. This new extension, along with other X.509 fields and extensions, are used to enable proper path validation and use of the PC.

37. Proxy Certificate • The process of creating a PC is as follows: • A new public and private key pair is generated. • That key pair is used to create a request for a Proxy Certificate that conforms to the profile described in this document. • A Proxy Certificate, signed by the private key of the EEC or by another PC, is created in response to the request. During this process, the PC request is verified to ensure that the requested PC is valid (e.g., it is not an EEC, the PC fields are appropriately set, etc). • When a PC is created as part of a delegation from entity A to entity B, this process is modified by performing steps #1 and #2 within entity B, then passing the PC request from entity B to entity A over an authenticated, integrity checked channel, then entity A performs step #3 and passes the PC back to entity B. • Path validation of a PC is very similar to normal path validation, with a few additional checks to ensure, for example, proper PC signing constraints.

38. 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]. • They are typically embedded in other structures for transport, such as HTTP POST requests or XML-encoded SOAP messages. • The SAML bindings specification [SAMLBind] provides frameworks for the embedding and transport of SAML protocol messages. • The SAML profiles specification [SAMLProf] provides a baseline set of profiles for the use of SAML assertions and protocols to accomplish specific use cases or achieve interoperability when using SAML features.

39. SAML 2.0 • The components primarily permit transfer of identity, authentication, attribute, and authorization information between autonomous organizations that have an established trust relationship. • 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. • The means by which lower-level communication or messaging protocols (such as HTTP or SOAP) are used to transport SAML protocol messages between participants is defined by the SAML bindings.

40. SAML 2.0 • SAML profiles are used to satisfy issues such as Web Browser SSO profiles • Profiles typically define constraints on the contents of SAML assertions, protocols, and bindings in order to solve the business use case in an interoperable fashion. • There are also Attribute Profiles, which do not refer to any protocol messages and bindings, that define how to exchange attribute information using assertions in ways that align with a number of common usage environments (e.g. X.500/ LDAP directories, DCE). • Metadata defines a way to express and share configuration information between SAML parties. For instance, an entity's supported SAML bindings, operational roles (IDP, SP, etc), identifier information, supporting identity attributes, and key information for encryption and signing can be expressed using SAML metadata XML documents. SAML Metadata is defined by its own XML schema. • In a number of situations, a service provider may need to have detailed information regarding the type and strength of authentication that a user employed when they authenticated at an identity provider. • A SAML authentication context is used in (or referred to from) an assertion's authentication statement to carry this information. An SP can also include an authentication context in a request to an IdP to request that the user be authenticated using a specific set of authentication requirements, such as a multi-factor authentication. There is a general XML schema that defines the mechanisms for creating authentication context declarations and a set of SAML-defined Authentication Context Classes, each with their own XML schema, that describe commonly used methods of authentication.

41. SAML 2.0

42. Additional Material – esMDAoR • Reference from prior AoR call materials

43. 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

44. 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

45. Topics for Digital Identities and AoR Workgroup Effort • Identity proofing • Digital identity management • Encryption • Digital signatures and artifacts • Delegation of Rights • Author of Record

46. Initiative Requirement Summary

47. esMD Requirements * Required if the action of the responsible party is being represented by a third party

48. 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

49. 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)

50. Sub-Workgroups