1. e-SENS Electronic Simple European Networked Services e-SENS CC5.2 F2F, Porto, 2015 Architecture and use of e-SENS Building Blocks: e-ID SAT Pilot eID Stakeholder integration STORK (2.0) Junction Soeren Bittins, Ben Kraufmann // FhGFOKUS

2. Agenda current state of the eID Nation in e-SENS brief summary/status of ready technical artifacts short demo of integrated/prototyped components brief summary/status of in-progress technical artifacts open issues and challenges (technical, strategically) synthesis / discussion 2

3. CardInfo eID configuration CardInfo artifacts specify and configure specific eID carrier for use with e-SENS eID building blocks support auto-detection of plugged eID carrier constrain the attribute realm to be available (SMP?) configuration currently available for: PT – extended profile IT – basic profile LX – basic profile, limited functionality (cert.-based) DE – extended profile, no piloting planned AT – extended profile, no piloting planned as of yet ES – missing  3

4. e-SENS LARMS Local Attribute Mapping and Retrieval: extract, transform, and process attributes from an eID processing local to the PoC in country-B independent of locally available middleware/country-A NI also referred to as passive AuthN provides two baseline profiles: 1.BASIC – identity traits can be freely extracted (Identification) 2.EXTENDED – identity traits can be extracted after controlled AuthN access to further information depending on eID carrier Status: ready for integration (DEMO) 4

5. DEMO (slightly) extended e-SENS LARMS demo based on a Portugese card (Ben using Rui’s/Licinio’s card) e-SENS CC6.3 f2f, Brussels – Security and Trust 5

6. advanced e-SENS eID SAT distributed attribute retrieval and cross eID mapping: usefulness limited but interesting for STORK enrichment pre-authorization by PIN-controlled attribute release: required for advanced functions, prerequisite for many MW providence of authenticated attributes from eID: very useful for mobile eID and STORK-based integrations digital signature for cross-border documents: patient consent as manifest of patient authorization no other document/AuthZ currently envisioned PAC out of scope due to missing x-border properties 6

7. STORK 2.0 Junction selecting most appropriate eID means available 1.STORK 2.0 (discussion: STORKv1 DSI component?) 2.advanced e-SENS eID profile (AuthN/AuthZ), FutureID 3.e-SENS LARMS, 4.„typing“ (epSOS), local extraction, proprietary tool chain required is available and dry tested early demonstrator components available one crucial BB missing (external dependency FID) need access to STORK 2.0 infrastructure for real tests priority component for regulatory robustness 7

8. eID Integration integration development artifacts and progress: e-SENS LARMS: jnlp.fokus.fraunhofer.de e-SENS ready OpenNCP demonstrator e-SENS eID Attribute Mapping Policy documents: not included in current work assignments / budget consideration e-SENS Digital Signature code base re-integrated (harmonizing LARMS and DSig code for joint use) prototype integration into OpenNCP (not RC2 yet) auto-detection of plugged/available eID token carrier auto-filling of search masks with extracted attributes 8

9. eID physical Integration all integration is unofficial using an internal OpenNCP staged, complimentary deployment concept not implemented: missing architectural cornerstones: security context handler (XACML-style on NCP level) NCP-level services but facades for pan-European selective providence to unburden local HIT (AIS, STORK) metadata / middleware locator and retrieval services re-issuing, compilation, enrichment of attributes from different sources, final LoA/AAL assignments local HIT integration by PAM/JS LARMS component 9

10. Open Issues critical e-SENS tasks have ceased/postponed activity: trust establishment, digital signature, etc. moving x-domain aspects from 6.x to 5.x with no oversight collection of sample token carrier took long: cards available now, middleware / spec’s not so much LX very little data available, GR nothing so far wet-testing with STORK and advanced middleware: Massi will provide test assertions in compliance with 6.4 STORK testing infrastructure appreciated local middleware for advanced profile testing required “new” CEF/CIPA/DSI requirements and expectations 10

11. Open Issues (cont.) integration who/how in OpenNCP needs discussion: divergent financing issues between e-SENS/OpenNCP strategic direction unclear to (parts of) the e-SENS team advanced components will have significant impact on current architecture and deployment approach EXPAND as guideline & tie-breaker currently unavailable options: 1.e-SENS development, EXPAND oversight, OpenNCP integration 2.e-SENS development + integration, EXPAND + OpenNCP drop-off 3.EXPAND strategic decision, e-SENS + OpenNCP devel. + integration 11

12. Discussion? 12