document.docx

<same as the Log Summary field below>

epSOS Change ProposalInstructionsThis is a template to propose changes to epSOS Specifications.

Once a Final Text Change Proposal is incorporated into the corresponding epSOS Specification, it is no longer maintained. Relevant CPs must be submitted against the updated epSOS Specification.

The CP publication process is described in detail at www.xxxx.org

In submitting a new Change Proposal, the submitter should assign the MS Word file an initial filename including the submitters initials, and a few words describing the topic, eg: CP-epSOS-eHealth-<author initials>-<3/4 wordSummary>.docx>. The the expert Committee will assign a name (using the convention described below) when it is accepted for processing.

CPs should be submitted to the the epSOS expert Committee by e-mail at: e-mail@xxx.com

Please complete the following fields in the Change Proposal Summary Information: (a) Title, (b) epSOS Specification(s) affected, (c) submitter name and e-mail address and (d) provide detailed Rationale for Change and Proposed Change. Please fill in the Impact of Change and other fields if known.

RED TEXT IS EXPLANATORY. PLEASE DELETE THIS PREAMBLE AND REPLACE THE RED TEXT BELOW WITH APPROPRIATE RESPONSES IN BLACK TEXT.

Tracking information:EpSOS Specifciation (IS-nnnn or UC-pppp and title) D3.A7_epSOS_EED_IHE_XCPD_Binding_v1.0

Change Proposal ID: CP-<EpSOS >-<number>-<version>.doc (assigned by the EpSOS expert Committee)

Change Proposal Status: Submitted

Date of last update: 29/6/2015

Person assigned: (assigned by EpSOS expert Committee)

Change Proposal Summary information:Add the e-SENS Evidence Emitter ABB/SBB

Submitter’s Name(s) and e-mail address(es): Massimiliano.masi@tiani-spirit.com, Soeren.bittins@fokus.fraunhofer.de, Benjamin.kraufmann@fokus.fraunhofer.de

Submission Date: 10/11/2015

Specification numbers (IS-xxxx) affected: D3.A7_epSOS_EED_IHE_XCPD_Binding_v1.0

Use Case Actor(s) and/or Requirement Number affected: epSOS Patient Identification Binding

document.docx

<same as the Log Summary field below>Section(s) affected: 2

Rationale for Change:The patient electronic identification (eID) is a crucial task in the eHealth workflow. Historically has been tackled by epSOS using the findIdentityByTraits transaction, requiring the health professional to enter manually the patient identifier in a member state-specific search mask. This action is time consuming and error prone. In the recent years, many attemps have been made to overcome this problem by enriching the epSOS workflow with electronic identification. Many projects tackled the issue and provided solutions and expertise, namely Stork (all versions) and FutureID. All these efforts are overseen to result in the application of the eIDAS regulation and compliance with its implementation acts.This change proposal defines a set of five assets that will bring eID in the eHealth domain to a level that

Fixes the epSOS SEG relaxation on patient eID Fixes the epSOS SEG on TRC assertion signature Fixes the deployment of the TRC STS Provides a smooth path towards the eIDAS compliance by using a step-by-step level using all the possibile devices,

such as smart cards (EHIC), mobile ID, etc

Formulate the proposed change here, if known at time of submission

Specify what exactly should be changed. When modifying existing text, paste it into this Change Proposal and DO NOT use MS Word change tracking. Manually format all changed text to bold and either underline the new text or cross out the text to be removed.

When pasting from documents use “Paste Special…”, select “Unformatted text”, and apply the appropriate styles to the text inserted. This avoids importing spurious paragraph formats (which are the cause of significant headaches for editors).

Proposed changes should be introduced with “editors instructions” in a “box” such as:

Replace Section X.X by the following:

or

Move Section 3 to Section 4, and replace Section 3 with the following:

1 eIDThis section introduces the various business levels of eID. Each level introduces additional conformity with the eID and additional complexity. At every level an additional eID asset will be introduced, but maintains the ones from the previous levels. The levels are divided by the technology associated and the availability of connection, either to centralised service or a distributed network.

It is worth noticing that this process leverages the pilot experience of EU projects like epSOS and e-SENS, thus it is foreseen that additional Change Proposals will be submitted, further describing the assets' details and the technology, based on the outcome of their respective large scale pilots.

1.1 Level 0 – manual input of IDThis is the most basic level of identification. It only requires the Health Professional to identify the patient by requesting his/her ID, and enter it manually in the system. This is the approach used in the epSOS pilot.

document.docx

<same as the Log Summary field below>The main advantage of this level is in an emergency setting where no other method of identification and authentication is available.

1.2 Level 1 –Passive read of eID tokenThis level requires the existence of an eID token, usually this token is a smart card. The token has identification attributes that can be publicly read.

T asset used provide this level is the Local Attribute Mapping and Retrieval Service (LARMS). This level is safer than the previous, because of the input of the identification is automatic and not manual.

1.3 Level 2 –Localy signed eID with tokenThis level also requires the existence of an eID token, as the previous on, but this token has to be capabl of patient authentication, usually by entering a PIN code.

The asset used to provide this level is the Local Authentication Module (e-SENS LAM) with the Digital Signature Add-On (DSig).

Signing of a patient consent is made possible with the introduction of this level.

This level is safer than the previous, because the introduction of the identification attributes is authenticated by the patient. In this level, as well in the previous ones, a network connection is not needed. The inexistence of a network connection, and thus the connectivity to a PKI (Public Key Infrastructure) to validate this authentication is a liability.

1.4 Level 3 – Localy signed eID with realtime validationThis level has the same functionality of the previous, but with the availability of a network connection and connectivity to the required PKI infrastructures. This level mitigates the liability introduced in the previous level. So the validation of the authentication of identification and patient consents is possible.

1.5 Level 4 – Distributed Cross-Border Authentication (DCA)This level introduces the Authentication Broker, that is leveraged by the STORK 2.0/ eIDAS infrastructure. All authentication and authorization activities are fulfilled outside of the local environment based on an initial authentication information acquired locally from an eID token.

1.6 Level 5 – Virtual eID (mobile eID)This level leverages the previous by giving the possibility of authentication and authorisation without the need of a physical eID token, just using a mobile app a smartphone with a virtual token, specifically developed for this.

document.docx

<same as the Log Summary field below>

1.7 e-SENS Local Attribute Mapping and Retrieval Service (LARMS)The Local Attribute Retrieval and Mapping Service (LARMS) provides a generic interface enabling a consistent exchange from attributes between supported smartcards and remote requesters.

It is designed as an add-on/module to the Open eCard framework registering its own action handler and interface definition in order extends the frameworks capabilities towards local extraction of attributes from accessible eID token carriers (locally typical limited to smart cards) as well as the mapping of the extracted attributes into a consolidated and exchangable form. Consequently, none of the downstream components needs to deal with a particular cards specifics since the output is always a consolidated package that can be immediately consumed (see Figure 1)

Figure 1: LARMS Conceptual Function

How information is natively stored on the smart cards is usually determined by the issue and may differ greatly, for instance subject-DN of X.509 certificate, BCD encoded data or a proprietary XML format. Furthermore, they not only the data encoding but also its location may differ from card to card, like data being outsourced into a proprietary EF. Consequently, not all of the fundamentally accessible information can be assumed to be immediately processable and may require further data conditioning.

LARMS is employing the CardInfo files as a configuration facility to specify what information is to be found where, and whether it has to be pre-or post-conditioned. This configuration is card-specific and available to the eCard framework as well as any add-ons. A last conditioning step also aligns the retrieved data with a common, configurable set of human- and machine-readable attributes (see Figure 2).

document.docx

<same as the Log Summary field below>

Figure 2: Retrieval and mapping methodology

After the retrieval and mapping of the smart card’s data, the information conditioned and packaged into tokens for a coherent after-use. Currently, LARMS is capable of producing the following two routine output formats:

1. SAML Assertion (see Figure 3)

2. JSON Web Token (see Figure 4)

Figure 3: e-SENS LARMS output encoded as SAML

document.docx

<same as the Log Summary field below>

Figure 4: LARMS output encoded as JSON Web Token (JWT)

The in token encoded information can be requested through the LARMS service interface that is implemented and integrated into the eCard framework. The interface is accessible through a regular HTTP GET request on the local machine port 24727:

http://localhost:24727/larms/getAttributes[?format=saml|jwt]

The operation accepts an optional parameter (format) to specify the output format. If no parameter is contained within the request, a JSON Web Token is issued by default.

1.7.1 Summary and Component Brief

Figure 5: LARMS Business Perspective Workflow

1.8 Local Authentication Module (LAM)LARMS as introduced in the last section is specifically limited to the very basic use case of identifying a subject by retrieving only openly available attributes from an eID carrier, in other words: retrieval without any card-bearer or any NI-A systems interaction apart from making the card available to the system. Protected attributes that are only released by the card after the card-

document.docx

<same as the Log Summary field below>bearer has successfully authenticated against the card are inaccessible and therefore out of scope for e LARMS.

The Local Authentication Module (LAM) addresses both of those issues by providing a technical as well as a user interface to:

authenticate a bearer towards a smart card to release card commands and data for after-use

request and provide a set of authenticated attributes directly from the smart card as input for external authentication and/or signature schemes (in collaboration with the DSig Add-On)

Although a direct user interaction with this component is possible, it is primarily designed to provide back-end functionality whenever a particular set of protected and assured attributes needs to be collected, compiled, and provided to an external service. The LAM component is usually triggered by a specific configuration of an Authentication Plan. The LAM returns:

a released smart card signal to the client after successful authentication of the bearer

a signed assertion carrying the configured set of authenticated attributes – OR – a set of authenticated attributes extracted from the card

This translates into the sequence of interaction and events depictured in Figure 6.

document.docx

<same as the Log Summary field below>

Figure 6: LAM sequence

document.docx

<same as the Log Summary field below>

1.8.1 Digital Signature Add-On (DSig)The eID pilot relies on the external digital signature building block “eSign1” as originally provided by the TU Graz. The eSign services are also designed to operate as an add-on to the eCard framework and are integrated locally in order to enable a purely local signature provider. This component registered and interface and handler to process compliant OASIS Digital Signature Services2 (DSS) based signature creation and verification requests for at least Advanced Electronic Signatures (AES). DSS specified two XML-based request/response protocols processing the needs of signature creation and verification.

Currently, the eSign is capable of signing and verifying the following artefacts/signatures:

PDF (PAdES) – such as a patient consent encoded in PDF/A

XML (XAdES) – an assertion or the machine-readable BPPC wrapper of the patient consent

CMS (CAdES) – Cryptographic Message Syntax, currently no corresponding data type in pilot

Since signature requests for immaterial data such as assertions or electronic documents outside of the reach of the subject would put the signer at a disadvantage, the component contains a review facility that enables the signer to review the to-be-signed artefact beforehand.

NOTE: In order to provide a foundation for the integration of external signature services, such as mandated frameworks within a national infrastructure (NI), this component natively support the initiation of a proxy class that is capable of delegating originally locally issued signature requests to external services for fulfilment.

1.9 Obtainin a TRC Assertion using the LAMThe LAM is exploited to obtain TRC assertions signed using the patient's key material available in the EHIC. Since all the key material is available only in the premises of the LAM, the signature will not be performed by the TRC-STS. The flow is as follows.

Event is triggered by the National Infrastructure (ideally the portal)

The LAM performs a RequestSecurityToken towards the TRC-STS3. One way TLS connection. The parameters are evaluated by the LAM

TRC-STS will return an unsigned TRC Assertion

LAM will compute the signature, and will request the PIN

LAM will let the EHIC to encrypt the signature

1 more information and specification available at: http://futureid.eu/data/deliverables/year2/Public/FutureID_D33.03_WP33_v1.02_Implementation%20of%20the%20Framework.pdf

2 specification and interactions available at: https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=dss#technical

3 The TRC-STS is deployed in the national infrastructure. How to obtain the configuration information is left unspecified for the moment. Ideally they will be obtained by e.g., using SMP records.

document.docx

<same as the Log Summary field below>The flow is depicted in Figure 7 Obtaining a TRC-STS.

Figure 7 Obtaining a TRC-STSIt is worth noticing that this binding is not changing the context defined in @@REF@@ maybe put a reference in the assertion binding as well for obtaining a TRC assertion. The same protocol and message layout persist. The following changes are defined to accomodate with the LAM flow. The following namespace is created: trc:http://epsos.eu/trc.

SOAP Element Values

env:Header MUST NOT contain a SAML assertion

wst:TokenType MUST be urn:oasis:names:tc:SAML:2.0:assertion

wst:RequestType MUST be Issue in the WS-Trust namespace

wst:Claims MUST contain the parameters set by the LAM to create the TRC

trc:DoctorId MUST contain the Health Professional identifier

trc:NotBefore MUST be the current datetime

trc:NotOnOrAfter Defined by the national infrastructure regulation, SHOULD be less than 2 hours

document.docx

<same as the Log Summary field below>

trc:AuthnInstant MUST contain the datetime when the user has been electronically identified

trc:SessionNotOnOrAfter MUST contain the time window for which the NI application consider the user session valid

trc:PatientId MUST contain the patient identifier

trc:IdAReference MUST contain the SAML assertion ID attribute of the epSOS Identity Assertion

trc:PurposeOfUse SHOULD be either TREATMENT or EMERGENCY. Additional purposes MAY be defined

A sample message is as follows (LAM to TRC-STS).

<?xml version="1.0" encoding="UTF-8" standalone="no"?><env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope"> <env:Header> <wsa:MessageID xmlns:wsa="http://www.w3.org/2005/08/addressing">uuid:3dfe5344-2b7e-490b-8a51-a93e7824a9c5</wsa:MessageID> </env:Header> <env:Body> <wst:RequestSecurityToken xmlns:wst="http://docs.oasis-open.org/ws-sx/ws-trust/200512"> <wst:TokenType>urn:oasis:names:tc:SAML:2.0:assertion</wst:TokenType> <wst:RequestType>http://docs.oasis-open.org/ws-sx/ws-trust/200512/Issue</wst:RequestType> <wst:Claims> <trc:TRCParameters xmlns:trc="http://epsos.eu/trc"> <trc:DoctorId>Massi</trc:DoctorId> <trc:NotBefore>2015-08-18T09:42:56.716Z</trc:NotBefore> <trc:NotOnOrAfter>2015-08-18T11:42:56.716Z</trc:NotOnOrAfter> <trc:AuthnInstant>2015-08-18T09:40:56.716Z</trc:AuthnInstant> <trc:SessionNotOnOrAfter>2015-08-18T11:42:56.716Z</trc:SessionNotOnOrAfter> <trc:PatientId>massi^^^123</trc:PatientId> <trc:IdAReference>_06459425-f0ec-4ad9-b1aa-26abaeeb5365</trc:IdAReference> <trc:PurposeOfUse>TREATMENT</trc:PurposeOfUse> </trc:TRCParameters> </wst:Claims> </wst:RequestSecurityToken> </env:Body></env:Envelope>

and the response (TRC-STS to LAM)<?xml version="1.0" encoding="UTF-8" standalone="no"?><env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope"> <env:Header> <wsa:RelatesTo xmlns:wsa="http://www.w3.org/2005/08/addressing" >uuid:3dfe5344-2b7e-490b-8a51-a93e7824a9c5</wsa:RelatesTo> </env:Header> <env:Body> <wst:RequestSecurityTokenResponseCollection xmlns:wst="http://docs.oasis-open.org/ws-sx/ws-trust/200512" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://docs.oasis-open.org/ws-sx/ws-trust/200512/ http://docs.oasis-open.org/ws-sx/ws-trust/200512/ws-trust-1.3.xsd">

document.docx

<same as the Log Summary field below> <wst:RequestSecurityTokenResponse> <wst:TokenType> urn:oasis:names:tc:SAML:2.0:assertion</wst:TokenType> <wst:RequestedSecurityToken> <saml2:Assertion xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion" xmlns:xs="http://www.w3.org/2001/XMLSchema" ID="_17690042-96d5-4765-bf3c-9a38a2f5ffe7" IssueInstant="2013-10-18T05:16:07.784Z" Version="2.0"/> </wst:RequestedSecurityToken> </wst:RequestSecurityTokenResponse> </wst:RequestSecurityTokenResponseCollection> </env:Body></env:Envelope>