eidas Technical Specifications

Transcription

1 eidas Technical Specifications v0.90 [Written by eidas Technical Subgroup] [July 2015]

2 EUROPEAN COMMISSION European Commission B-1049 Brussels

3 Europe Direct is a service to help you find answers to your questions about the European Union. Freephone number (*): (*) The information given is free, as are most calls (though some operators, phone boxes or hotels may charge you). Disclaimer This document is for informational purposes only and the Commission cannot be held responsible for any use which may be made of the information contained therein. References to legal acts or documentation of the European Union (EU) cannot be perceived as amending legislation in force or other EU documentation. The document contains a brief overview of technical nature and is not supplementing or amending terms and conditions of any procurement procedure; therefore, no compensation claim can be based on the contents of the present document. Page 3 of 71

4 NOTE In line with Regulation (EU) No 910/2014 of the European Parliament and of the Council on electronic identification and trust services for electronic transactions in the internal market, and with COMMISSION IMPLEMENTING REGULATION (EU) 2015/1501 of 8 September 2015 on the interoperability framework, in particular with regard to Article 12 thereof, in order to implement the interoperability framework, technical specifications could be developed. The present technical specifications may serve as the basis of further details of the technical requirements contained by COMMISSION IMPLEMENTING REGULATION (EU) 2015/1501. The specifications for the eidas node accompanying this note have been developed through member state collaboration in a technical sub-committee of the eidas Expert Group. The role of the Commission has been to facilitate and support this process with a view to DG DIGIT providing a sample implementation of the technical specifications which member states are free to adopt as an "off the shelf" implementation should they wish to do so. The specifications posted here as versions 0.9 represent a stabilisation of specifications in order that member states can work towards their implementation. In most areas of the technical specifications imminent change is not expected as member states have reached a consensus. However in the area of distribution and trust of metadata, there are some outstanding matters to be resolved and agreed by member states. These are not critical to a build of the technical specifications commencing and work on a version 1.0 which will focus on these areas will immediately get underway in order to have a stable version across all areas. Page 4 of 71

5 Table of contents TABLE OF CONTENTS... 5 TABLE OF FIGURES... 8 TABLE OF TABLES INTRODUCTION EIDAS INTEROPERABILITY ARCHITECTURE Introduction to interoperability architecture Definitions Key Words Robustness Principle eidas-nodes Sending MS Receiving MS Communication between eidas-nodes Identification of eidas-nodes Proxy based Schemes Middleware based Schemes Interfaces Interface between eidas-connector and Relying Party Interface between eidas-connector and eidas-service Request Messages Response Messages Interface between eidas-service and eid Scheme MS selection Process flow Metadata exchange Trust Anchor SAML Metadata Metadata Location Caching of Metadata Pre-fetching of Metadata Metadata Verification Operational and Security Requirements Nodes Node Operators Middleware Provisioning TLS SAML Key Storage Implementations (informative) CEF MOA Middleware-Service for eidas-token MESSAGE FORMAT Introduction to message format...25 Page 5 of 71

6 Page 6 of Definitions Key Words eidas Message Format Metadata Metadata Format Name Identifiers Attributes Attribute Support Requesting Attributes Responding Attributes SAML protocol message content SAML AuthnRequest SAML Response Attribute Definitions Name Identifier Levels of Assurance eidas Attributes Additional Attributes Private/Public Sector SP Message Format Examples eidas Connector SAML-Metadata eidas Service SAML Metadata ATTRIBUTE PROFILE Introduction Definitions Key Words Attributes SAML Attribute Naming Attributes for Natural Persons Mapping eidas minimum data set for Natural Persons to ISA Core Vocabulary Attribute Schema Uniqueness Identifier (mandatory) Current Family Name(s) (mandatory) Current First Name(s) (mandatory) Date of Birth (mandatory) First name(s) and family name(s) at birth Place of Birth Current Address Gender Attributes for Legal Persons Mapping eidas minimum data set for Legal Persons to Core ISA Vocabulary Attribute Schema Uniqueness Identifier (mandatory) Legal Name (mandatory) Legal Address...56

7 VAT Registration Number Tax Reference Number Directive 2012/17/EU Identifier Legal Entity Identifier Economic Operator Registration and Identification System for Exchange of Excise Data Identifier Standard Industrial Classification Transliteration CRYPTOGRAPHIC REQUIREMENTS Introduction Key words Requirements for TLS TLS version Cipher Suites Elliptic curves Certificates Domain parameters, keys and random numbers Additional requirements and recommendations Requirements for SAML General requirements Hash functions XML Encryption with SAML Content Encryption Key Encryption Signatures for SAML and SAML Metadata Signature Algorithms Elliptic curves X.509 Certificates Certificates for SAML Metadata Certificates for SAML communication REFERENCES...69 Page 7 of 71

8 Table of figures Figure 1 Centralized and decentralized deployment...14 Figure 2 Components...14 Figure 3 Interfaces...15 Figure 4 Metadata trust management...19 Figure 5 Schema for natural persons...45 Figure 6 example PersonIdentifier attribute value...46 Figure 7 example CurrentFamilyName attribute value...48 Figure 8 Example CurrentGivenName attribute value...48 Figure 9 Example DateOfBirth attribute value...49 Figure 10 Example BirthName attribute value...49 Figure 11 Example PlaceOfBirth attribute value...50 Figure 12 Example CurrentAddress attribute value (address data base64 encoded)...50 Figure 13 Address data before encoding to base Figure 14 Example Gender attribute value...51 Figure 15 Schema for legal persons...55 Figure 16 Example LegalPersonIdentifier attribute value...55 Figure 17 Example LegalName attribute value...56 Figure 18 Example LegalPersonAddress attribute value (address data base64 encoded)...56 Figure 19 Address data before encoding to base Figure 20 example VATRegistrationNumber attribute value Figure 21 Example TaxReference attribute value...57 Figure 22 example D EUIdentifier attribute value Figure 23 Example LEI attribute value...58 Figure 24 Example EORI attribute value...59 Figure 25 Example SEED attribute value...59 Figure 26 Example attribute element based on SIC...60 Figure 27 Example attribute element based on FamilyName including Latin and non- Latin attribute value Page 8 of 71

9 Table of tables Table 1 Mandatory attributes are required by the Regulation...42 Table 2 Optional attributes...42 Table 3 Mandatory attributes are required by the Regulation...51 Table 4 Optional attributes...51 Table 5 Recommended Cipher Suites...64 Table 6 Key lengths for TLS...64 Table 7 Hash function for SAML...66 Table 8 Algorithms for key transport...67 Table 9 Signature Algorithms for SAML...67 Table 10 Signature Algorithms for SAML...68 Table 11 Signature of Certificates...68 Page 9 of 71

10 1. Introduction The current document contains the four main documents developed by the eidas Technical subgroup and it is structured as follows: Chapter 2 - eidas - Interoperability architecture Chapter 3 - Message format Chapter 4 - Attribute profile Chapter 5 - Cryptographic requirements Page 10 of 71

11 2. eidas Interoperability Architecture Page 11 of 71

12 2.1. Introduction to interoperability architecture This document specifies the interoperability components of the eidas-network, i.e. the components necessary to achieve interoperability of notified eid schemes according to the eidas Regulation [eidas]. These specifications are based on the requirements laid down in the Implementing Act [IA IF]. Stakeholder of the eidas-network are: the relying party requires authenticity/integrity of the received person identification data in order to fulfil his data protection obligations, requires also confidentiality of the received personal identification data the citizen expects confidentiality of his person identification data expects that the eidas-network respects his privacy the operators of components of the eidas-network requirements derived from the requirements of the relying party and the citizens To fulfil these requirements, and to provide accountability / liability mandated by the regulation, a chain of responsibility / trust is needed throughout the complete authentication process. Therefore the framework for cross-border interoperability must provide confidentiality of the person identification data; authenticity/integrity of the person identification data; secure identification/authentication of communication end-points. The framework must not put requirements on the eid scheme or the systems of the MS where the relying party is established. It is assumed that the national systems provide adequate measures to provide confidentiality, authenticity/integrity and communication end-point identification for their systems. Note: Relying party and citizen may also require availability of the eidas-network. Requirements on operators concerning availability are out of scope of the Interoperability Framework and therefore not part of these technical specifications Definitions The following terms are used throughout this document: MS: State covered by the eidas regulation, i.e. a Member State of the European Union and/or the European Economic Area. Sending MS: the MS whose eid scheme is used in the authentication process, and sending authenticated ID data to the receiving MS. Receiving MS: the MS where the relying party requesting an authentication of a citizen is established. Page 12 of 71

13 eidas-node: an operational entity involved in cross-border authentication of citizens. A Node can have different roles, which are distinguished in this specification (eidas-connector/eidas-service, see below). eidas-connector: an eidas-node requesting a cross-border authentication. eidas-service: an eidas-node providing cross-border authentication. eidas-proxy-service: an eidas-service operated by the Sending MS and providing personal identification data. eidas-middleware-service: an eidas-service operated by the Receiving MS and providing personal identification data. Proxy based scheme: a (notified) eid scheme which provides cross-border authentication via an eidas-proxy-service. Middleware based scheme: a (notified) eid scheme which provides crossborder authentication via eidas-middleware-services. Middleware: Software provided by a MS notifying a Middleware based scheme which is used by Receiving MSs to operate eidas-middleware-services Key Words The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL in this document are to be interpreted as described in [RFC2119]. The key word "CONDITIONAL" is to be interpreted as follows: CONDITIONAL: The usage of an item is dependent on the usage of other items. It is therefore further qualified under which conditions the item is REQUIRED or RECOMMENDED Robustness Principle Implementations according to this specification SHALL following the robustness principle, also known as Postel's Law: Implementations should follow a general principle of robustness: be conservative in what you do, be liberal in what you accept from others eidas-nodes Interoperability between different eid-schemes is achieved via defining the technical interfaces between eidas-connectors and eidas-services, collectively eidas-nodes. The interfaces between the eidas-connector and relying parties and between the eidas-services and the eid-scheme are part of the national system of the Receiving MS and the Sending MS, respectively, and therefore out of scope of this specification Sending MS Sending MS can choose between two integration scenarios for their eid-scheme. 1. Proxy-based: The Sending MS operates an eidas-proxy-service, relaying authentication requests and authentication assertions between an eidas- Connector operated by the Receiving MS and the eid scheme of the Sending MS. 2. Middleware-based: In this scenario the Sending MS does not operate a Proxy for the purpose of authentication of citizens to relying parties of other Page 13 of 71

14 MS. The Sending MS provides a Middleware to other MS, which is operated by the operator(s) of the eid-connector(s) of the Receiving MS. A MS notifying their eid scheme as a Middleware-based scheme MUST provide the necessary Middleware to Receiving MSs (see section Middleware Provisioning) Receiving MS Each Receiving MS SHALL operate one or more eidas-connectors. It is up to the Receiving MS to decide the national deployment of Connectors. Connectors need not to be operated by the MS itself, but can also be operated by public and/or private relying parties established in that MS. In the following, MSs operating exactly one Connector are called Centralized MSs, while MSs operating several Connectors are called Decentralized MSs. An eidas-connector is operated together with eidas-middleware-services for communication with middleware-based eid schemes. Figure 1 Centralized and decentralized deployment The internal structure of the eidas-connector is out of scope of this document. An eidas-connector MAY provide additional services, (e.g. signature services), which are also out of scope of this specification. Note: Centralized MS notifying their own eid-scheme as a Proxy-based scheme MAY operate their eidas-connector and their eidas-proxy-service as an integrated deployment. Figure 2 Components Receiving MSs MUST ensure that personal identification data received via an eidas- Connector is processed according to applicable data protection legislation. This includes that data MUST NOT be forwarded to unidentified peers Communication between eidas-nodes The eidas-nodes SHALL use SAML (see section 2.9 Interface between eidas- Connector and eidas-service) for communication. Page 14 of 71

15 2.6. Identification of eidas-nodes To provide an uninterrupted chain of trust for authentications, as well as an uninterrupted chain of responsibility for integrity/authenticity and confidentiality for personal identification data, eidas-nodes MUST be securely identified before transmitting data to them/accepting data from them Proxy based Schemes Certificates for SAML signing and encryption of messages between eidas-connector and eidas-proxy-services are exchanged via signed SAML Metadata, see section 2.13 Metadata exchange Middleware based Schemes Certificates for SAML signing and encryption of messages between eidas-connector and eidas-middleware-services are exchanged directly between the entities, since there is a one-to-one correspondence between Connector and Middleware-Service. To facilitate exchange, Middleware-Services SHALL provide (unsigned) SAML Metadata containing the certificate of the Service, see section 2.13 Metadata exchange Interfaces An operator of an eidas-connector operates one instance of the eidas-connector, and one eidas-middleware-service for each type of notified middleware based eid schemes. Note: MSs notifying middleware based eid schemes based on the same technology MAY share a middleware, i.e. only one instance of the middleware is necessary for those eid schemes. Figure 3 Interfaces The eidas-connector provides the following interfaces: 2.8. Interface between eidas-connector and Relying Party This interface is up to the Receiving MS and out of scope of this specification Interface between eidas-connector and eidas-service The eidas-nodes SHALL use SAML, including error handling, for communication, as specified in [SAML-Core], as profiled in [eidas SAML]. Messages MUST NOT be sent to eidas-nodes not identified and MUST NOT be accepted from eidas-nodes not identified (see section 2.6 Identification of eidas- Nodes). The necessary information for communication, e.g. URLs, certificates for encryption/signature and information about the capabilities of nodes are contained in Page 15 of 71

16 SAML Metadata objects of the Nodes (see section 2.15 SAML Metadata). Metadata objects of peers can be retrieved during the authentication process or ahead of time (see section 2.16Metadata Location). Metadata objects MUST NOT be used if not successfully (explicitly or implicitly) verified (see section 2.17Metadata Verification). For all SAML communication, Transport Layer Security (see section TLS) SHALL be enforced by all Nodes Request Messages SAML Request Messages MUST be signed (see [SAML-Core]). The requirements from [eidas Crypto] apply. The Request Message Format is defined in [eidas SAML] Binding HTTP Redirect binding or HTTP POST binding (see [SAML-Binding]) SHALL be used for transmitting SAML Request messages. Nodes SHALL support both bindings for Request messages. It is RECOMMENDED for the requesting Node to use HTTP Redirect binding if the (signed) request is short enough to be processed via a redirect Verification Each eidas-service MUST verify the integrity/authenticity of a SAML Request message before processing the request. This comprises the following steps: 1. Extract the signature certificate of the Connector from the verified SAML Metadata object of the Connector (see sections 2.16 Metadata Location/2.17 Metadata Verification) 2. Verify the signature of the SAML Request message. Note: Steps 1 MAY be performed ahead of time, if the SAML Metadata object is imported decoupled from the receiving of the SAML message. Request messages which cannot be verified via this procedure MUST be rejected Response Messages Response Messages MUST be signed (see [SAML-Core]). Additionally, an Assertion contained in the Response Message MAY be signed. SAML Assertions MUST be encrypted; the encryption certificate SHALL be retrieved from the verified SAML Metadata object of the requesting Connector. 1 This recommendation is aimed at reducing latency (redirect processing is usually faster than POST-processing) and enhancing usability in environments where java-script is not available, e.g. corporate networks. Page 16 of 71

17 Assuming a successful response, the Response message MUST contain exactly one EncryptedAssertion-element. The encrypted Assertion MUST contain exactly one AuthnStatement-element and one AttributeStatement-element. The requirements from [eidas Crypto] apply. The Response Message Format is defined in [eidas SAML] Binding HTTP POST binding (see [SAML-Binding]) SHALL be used for transmitting SAML Response messages. The Response MUST NOT be transmitted to a URL not contained as AssertionConsumerService in the metadata of the Connector Verification Each eidas-connector MUST verify the authenticity a SAML Response message before processing the included assertion. This comprises the following steps: 1. Extract the signature certificate of the Service from the verified SAML Metadata of the Service (see sections 2.16 Metadata Location/2.17 Metadata Verification). 2. Verify the signature of the SAML Response message. 3. If the SAML Assertion is signed, its signature MAY be verified. Assertion messages which cannot be verified via this procedure MUST be rejected. Unsolicited Response Messages MUST NOT be accepted Interface between eidas-service and eid Scheme This interface is up to the Sending MS and out of scope of this specification MS selection The eidas-connector SHALL offer the user the possibility to select the MS, whose notified eid scheme is to be used for authentication, if the MS was not already preselected by the requesting relying party. The eidas-connector SHOULD only offer those MSs which are capable of fulfilling the request of the relying party (minimum Level of Assurance, type of Data Set to be authenticated), if these information are available to the Connector Process flow This section describes the process flow to authenticate a citizen, enrolled in the eidscheme of the Sending MS, to a relying party established in the Receiving MS. 1. The process is started by the relying party, which sends an authentication request to the eidas-connector responsible for it. The eidas-connector can be directly attached to the relying party (Decentralized MS) or operated by a separate entity (Centralized MS). The request MAY contain an identifier identifying the MS, whose eid scheme is to be used for the authentication, if this is already known to the relying party. Page 17 of 71

18 Page 18 of The eidas-connector SHALL request the MS, whose eid scheme is to be used for the authentication from the user, if this information was not already contained in the request of the relying party (see section 2.11 MS selection). 3. The eidas-connector SHALL send a SAML-Request to the eidas-service corresponding to the selected MS (see section Request Messages). The request MUST include the type and name of the relying party. 4. The eidas-service MUST verify the authenticity of the Request (see section Verification). o o o If the eidas-service serves several eid schemes, the Service SHOULD provide a scheme selection interface for the user. If the requesting relying party is a private entity, the Service MAY reject the Request if the terms and conditions of the eid scheme are not fulfilled. If the requested (or higher) Level of Assurance cannot be fulfilled by the eidas-service, the Request MUST be rejected. 5. The eidas-service SHALL perform the authentication of the citizen according to the selected eid scheme at least on the requested Level of Assurance, and SHALL send a SAML Response to the requesting eidas- Connector containing an encrypted SAML Assertion (see section Response Messages). 6. The eidas-connector SHALL verify the authenticity (see section Verification) of the received SAML Response message and decrypt the Assertion. The Connector MUST verify that the Level of Assurance indicated in the Assertion matches or exceeds the requested Level of Assurance, and send the received authenticated person identification data to the requesting relying party. If any of the checks (e.g. signature verification, Level of Assurance matching) fails, the procedure MUST be aborted. Error handling SHALL follow the SAML specification (see [SAML- Core]) Metadata exchange To provide an uninterrupted chain of trust for authentications, as well as an uninterrupted chain of responsibility for integrity/authenticity and confidentiality for personal identification data, Nodes must be securely identified. The Architecture defines two communication relationships: 1. Communication between eidas Connectors and Proxy-Services 2. Communication between eidas Connectors and Middleware-Services. Metadata exchange is based on the following principles: The trust anchors for all Nodes are the MSs. No central trust anchor is provided. Trust Anchors are exchanged bilaterally between MSs (see section 2.14 Trust Anchor). Metadata are distributed in the form of SAML Metadata [SAML-Meta]. Metadata objects of Connectors and Proxy-Services are signed by the Trust Anchor or by another entity (e.g. the operator of the Node) authorized via a certificate chain starting from the trust anchor. (see section 2.15 SAML Metadata). Metadata objects of Middleware-Services are unsigned. SAML Metadata SHALL be instantiated per Node.

19 This model allows different national deployment scenarios (arrows denote signatures): Figure 4 Metadata trust management Note: This allows to separate the trust anchor from the actual SAML end points (Nodes). This implies that the entity providing the trust (and holding the root key ) is not necessarily the same providing the SAML metadata, i.e. the Node operator. Since the Trust Anchors are exchanged bilaterally, and all trust (including Node certificates) is derived from these anchors, it is not necessary to use certificates from public CAs for these certificates Trust Anchor All MS MUST bilaterally exchange trust anchors in the form of certificates, certifying a signing key held by the MS (the Root ). This signing key can either be used to directly sign SAML metadata objects, or as root certificate of a PKI used to sign SAML metadata objects. Certificates of the root and subordinate certificates SHALL follow [RFC5280]. MSs MUST ensure that all SAML Metadata objects signed directly or indirectly under this Root describe valid eidas-nodes established in that MS SAML Metadata Each eidas-connector and each eidas-service MUST provide metadata about the Connector / Service in the form of SAML Metadata (see [SAML-Meta]). The SAML Metadata objects of Connectors and Proxy-Services MUST be signed and include a certificate chain starting at a trust anchor (see section 2.14 Trust Anchor) and terminating with a certificate certifying the key used to sign the Metadata object. Requirements for SAML from [eidas Crypto] apply. Metadata objects of Middleware- Services are exchanged directly with the corresponding Connector and therefore do not need to be signed. The SAML Metadata Interoperability Profile Version MUST be followed (see [SAML- MetaIOP]). Certificates MUST be encapsulated in X509Certificate-elements. The Metadata Format for Connectors and Services is defined in [eidas SAML] Metadata Location The SAML Metadata of Connectors and Proxy-Services MUST be publicly available under a HTTPS URL. The SAML Metadata of Middleware-Services SHALL be exported as a file. SAML Requests and Responses originating at a Connector or a Proxy-Service MUST contain a HTTPS URL in the <Issuer> element pointing to the SAML Metadata object of the Issuer of the request/assertion (see 'Well-Known Location' method in section 3.6 Metadata Format). Page 19 of 71

20 Requirements for TLS from [eidas Crypto] apply Caching of Metadata Retrieving and validating metadata objects during the authentication process can have an impact on reliability and performance of the authentication process, e.g. if the metadata URL is not reachable due to network problems or verification is not possible due to unavailability of revocation information for certificates. To avoid this, eidas Nodes MAY cache metadata objects (see section of [SAML- Meta]). Note: If the node regularly retrieves, verifies and caches new metadata objects after having learned the corresponding URL from a SAML message, retrieving metadata during the authentication process is only necessary for the first contact to a new node or if the metadata URL has changed Pre-fetching of Metadata To avoid the need to learn metadata URLs from SAML messages, metadata objects can be pre-fetched. [Mechanism under discussion. Scenarios discussed include the aggregation of metadata by the MS itself, or providing a list of metadata-urls to facilitate aggregation by third parties, e.g. other MSs or (optionally) COM.] Metadata Verification For verification of signed SAML metadata, verifiers MUST build and verify a Certification Path according to [RFC5280] starting from a trusted Trust Anchor (see section 2.14 Trust Anchor) and ending at the signer of the metadata object. Revocation check MUST be performed for all certificates containing revocation information. SAML metadata files directly exchanged between Connectors and Middleware-Services do not need to be explicitly verified, trust is conveyed implicitly via the direct exchange. All restrictions contained in the Metadata object (e.g. validity period) MUST be honoured by the verifier. Page 20 of 71

21 2.18. Operational and Security Requirements Nodes Nodes MUST NOT store any transaction data containing personal data beyond as required by Article 9(3) of the [IA IF]: The node operator shall store data which, in the event of an incident, enable reconstruction of the sequence of the message exchange for establishing the place and the nature of the incident. The data shall be stored for a period of time in accordance with national requirements and, as a minimum, consist of the following elements: a)node's identification; Node Operators b)message identification. c)message date and time. Information assurance requirements for eidas-services are laid down in Article 10 of [IA IF]: (1) Node operators of nodes providing authentication shall prove that, in respect of the nodes participating in the interoperability framework, the node fulfils the requirements of standard ISO/IEC by certification, or by equivalent methods of assessment, or by complying with national legislation. (2) Node operators shall deploy security critical updates without undue delay. The vendors SHALL provide necessary security updates in a timely manner. This includes the eidas-connector as well as eidas-services Middleware Provisioning The MS notifying a middleware-based eid scheme is responsible to provide the necessary Middleware. The Middleware SHALL meet the following requirements: Middleware SHALL be provisioned as pre-configured virtual machine in Open Virtualization Format. Configuration of the virtual machine by the operator SHOULD be supported by scripts or similar provided by the notifying MS. The virtual machine SHALL be provided for or SHALL be configurable for test and production environments. The virtual machine SHALL expose logging information via a syslog-interface and health information via an SNMP-interface. Generation of keys SHALL be performed under control of the hoster of the Middleware. The Middleware SHALL be provided to DG DIGIT for bundling with the CEFimplementation (see section CEF) and to the other Member States (if requested). The Middleware SHALL be accompanied by documentation, providing at least: Instructions for how to access an administrative or service account on the operating system needed for configuration and troubleshooting. Page 21 of 71

22 Instructions on how to install keys and certificates and other security-relevant topics. Requirements for the operational environment, including network configuration, DNS configuration, firewalls ports to open and expected storage capacity needed. Instructions on how to monitor the MW e.g. for heartbeat, crashes, resource utilization, response times and security events. Instructions on how to install new versions and patches in a way that does not erase log-data, configuration etc. Instructions on how to backup the machines (what files), and when logs files can be erased. Instructions on how to scale in case additional processing power is needed and how to implement and handle fail-over. Instructions how to restart the machines and troubleshoot common problems. Notifying MSs SHALL provide service and support for the Middleware TLS Communication between eidas-connectors and eidas-services via the browser of the user SHALL be protected by TLS (see [RFC5246]). The requirements for TLS and TLS certificates from [eidas Crypto] apply SAML Communication via SAML MUST be cryptographically protected according to [eidas Crypto]. This includes encryption of SAML Assertions and signing all SAML protocol messages. Before verifying a signature, the verifier MUST perform a XML schema validation of the signed object. It is RECOMMENDED to carefully consider the well known security aspects of SAMLbased systems (see [SAML-Sec]) and the Best Practices for XML Signatures (see [XMLSig BP]) Key Storage Private cryptographic keys MUST be securely stored. Public keys used to authenticate SAML assertions MUST be stored protected against manipulation Implementations (informative) This section provides information on the currently known implementations CEF An implementation of the eidas-connector and the eidas-proxy-service as a single package licensed under the EUPL is provided by DG DIGIT under the CEF (Connecting Europe Facility) program. Requirements on the implementation, including provisioning and service/support are managed by the CEF Management Board. Page 22 of 71

23 This implementation is provided bundled with the Middlewares provided by the Member States having notified a middleware based scheme MOA TBD Middleware-Service for eidas-token The Middleware-Service for an eidas-token based eid scheme is defined in [TR ]. Page 23 of 71

24 3. Message Format Page 24 of 71

25 3.1. Introduction to message format The eidas interoperability framework including its national entities (eidas-connector and eidas-service) need to exchange messages including personal and technical attributes to support cross-border identification and authentication processes. For the exchange of messages, the use of the SAML 2.0 specifications has been agreed in the eidas technical subgroup and is laid down in the eidas Interoperability Architecture. Since the eidas interoperability architecture should use widely used standards, the following SAML-based profiles are taken into utmost account in this paper: Kantara Initiative egovernment Implementation Profile of SAML V2.0 [SAMLeGov2.0] STORK 2.0 D4.4 First version of Technical Specifications for the cross border Interface [STORK] 3.2. Definitions Terms used throughout this document are defined in [eidas Interoperability Architecture]. In addition, when referring to SAML technology, an eidas-service can be seen as SAML identity provider and an eidas-connector as a SAML service provider. The following references are used in this document: Elements and attributes of the SAML 2.0 Protocol namespace of [SAML2Core] will be prefixed by saml2p:, e.g. <saml2p:respone> Elements and attributes of the SAML 2.0 Core namespace of [SAML2Core] will be prefixed by saml2:, e.g. <saml2:nameid> Elements and attributes of the SAML 2.0 Metadata namespace of [SAML2Meta] will be prefixed by md:, e.g. <md:entitydescriptor> Elements and attributes of the STORK Protocol namespace of [STORK] will be prefixed by storkp:, e.g. <storkp:requestedattributes> Elements and attributes of the STORK Core namespace of [STORK] will be prefixed by stork:, e.g. <stork:requestedattribute> Elements and attributes of the XML Digital Signature Syntax namespace of [XML-DSig] will be prefixed by ds:, e.g. <ds:x509certificate> Elements and attributes of the eidas SAML Attribute Profile [eidas-attr- Profile] will be prefixed by eidas:, e.g. <eidas:sptype> 3.3. Key Words The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL in this document are to be interpreted as described in [RFC2119]. The key word "CONDITIONAL" is to be interpreted as follows: CONDITIONAL: The usage of an item is dependent on the usage of other items. It is therefore further qualified under which conditions the item is REQUIRED or RECOMMENDED. Page 25 of 71

26 3.4. eidas Message Format The following sub-sections specify the message format of exchanged metadata or SAML AuthnRequest and Response messages to be exchanged between eidas-nodes. This document considers sign-on use cases only and thus neglects logout use cases. For SAML elements and attributes not explicitly discussed in this specification the SAML WebSSO-Profile [SAML2Prof] MUST be referred to. Metadata trust management is specified in [eidas-interop-architecture] and thus not explicitly discussed here. However, in most use cases defined in [eidas-interop-architecture] the metadata document MUST be properly signed according to [eidas-interop-architecture] Metadata This section defines basic requirements for the support and use of SAML metadata between different SAML entities and eidas-nodes, respectively Metadata Format The root element of SAML metadata MUST be <md:entitiesdescriptor> or <md:entitydescriptor> (depending on the chosen metadata retrieval method, i.e. for the Well-Known Location method as defined in [SAML2Meta] and [eidas-interop- Architecture], respectively, the root element MUST be <md:entitydescriptor>). The root element MUST contain the attribute validuntil. The cacheduration attribute MAY be included. The attribute EntityID MUST be a HTTPS URL pointing to the publication of metadata using the Well-Known-Location method defined in section 4.1 of [SAML2Meta]. SAML metadata of eidas-services MUST contain a <md:idpssodescriptor> element whereas SAML metadata of eidas-connectors MUST contain a <md:spssodescriptor> element. The <md:idpssodescriptor> element MUST contain the attribute WantAuthnRequestsSigned set to "true" to indicate the requirement of a signed <saml2p:authnrequest>. The <md:spssodescriptor> element MUST contain the attribute AuthnRequestsSigned set to "true" to indicate that transmitted <saml2p:authnrequest> messages are signed. Implementations MUST support and use the <md:keydescriptor> element and the <ds:x509certificate> element for the inclusion of X.509 Certificates used for SAML communication. Support for other key representations, and for other mechanisms for credential distribution, is OPTIONAL. The usage attribute of the <md:keydescriptor> element MUST be present. The supported name identifier formats SHOULD be indicated in the <saml2:nameidformat> element in the respective SAML metadata. The default AssertionConsumerServiceIndex and the default AttributeConsumingServiceIndex SHOULD be indicated by the attribute isdefault set to "true" within SAML Metadata. Human readable information of the organization operating the eidas-node SHOULD be indicated by the <md:organization> element. At least the elements <md:organizationname>, <md:organizationdisplayname>, and <md:organizationurl> SHOULD be provided. In addition, SAML metadata SHOULD contain contact information for support and for a technical contact. SAML metadata SHOULD contain both a <md:contactperson> element with a contacttype value of "support" and a <md:contactperson> element with a contacttype value of "technical". The <md:contactperson> elements SHOULD contain at least one <md: address>. Page 26 of 71

27 eidas-nodes MUST publish their cryptographic capabilities with regards to XML Signature and XML Encryption in their SAML metadata according to [eidas-crypto] and [SAML2AlgSup]. Entities MAY use this information for automatic negotiation of algorithms. eidas-services MUST publish all their supported attributes as <saml:attributevalue> elements in the <md:idpssodescriptor> element according to [SAML2Meta]. eidas-services MUST publish its highest supported Level of Assurance as entity attribute according to [MetaAttr] in the <md:extension> element. The NameFormat of the including <saml:attributevalue> MUST be set to "urn:oasis:names:tc:saml:2.0:attrname-format:uri" and the Name value MUST be set to Name Identifiers This section defines the treatment of identifiers to be used in a cross-border context. eidas-node implementations MUST support the following SAML 2.0 name identifier formats [SAML2Core]: urn:oasis:names:tc:saml:2.0:nameid-format:persistent urn:oasis:names:tc:saml:2.0:nameid-format:transient urn:oasis:names:tc:saml:1.1:nameid-format:unspecified Support for other formats is OPTIONAL Attributes This section discusses the handling and inclusion of attributes into exchanged messages Attribute Support eidas-services MUST support at least all mandatory attributes as specified in [Attr- Profile]. Optional attributes of [Attr-Profile] SHOULD be supported. Other optional attributes beyond the ones defined in [Attr-Profile] MAY be supported. Attributes not defined in [Attr-Profile] MAY require bilateral agreement on acceptance between eidas-connector and eidas-service Requesting Attributes Requesting attributes by an eidas-connector from an eidas-service MUST be carried out dynamically by including them in a <saml2p:authnrequest>. Only attributes that are published in the SAML metadata of the eidas-service can be requested by an eidas-connector (see Section Metadata Format). Attributes requested that are not supported by an eidas-service MUST be ignored by the eidas-service. Attributes MUST be requested as <storkp:requestedattributes> according to [STORK]. <storkp:requestedattributes> MUST be included in the <saml2p:extensions> element of the SAML AuthnRequest. For every requested attribute the eidas-connector includes a <stork:requestedattribute> element within the <storkp:requestedattributes> element. For attributes requested and being mandatory according to the eidas minimum data sets and [Attr-Profile] the attribute isrequired of <stork:requestedattribute> MUST be set to true. When requesting a minimum data set, at least all attributes defined as mandatory within this minimum data set MUST be requested. At least one minimum data set MUST be requested in each <saml2p:authnrequest>. Page 27 of 71

28 Responding Attributes Attributes are delivered in <saml2:attribute> elements within one <saml2:attributestatement> included in one SAML assertion. <saml2:attributevalue> elements within the eidas context are defined in [Attr-Profile]. <saml2:attributevalue> elements SHOULD be strings. XML content should be base64- encoded. Attributes MUST NOT contain empty values. Single encrypted attributes using <saml2:encryptedattribute> MUST NOT be used SAML protocol message content This section gives details on the exchanged SAML protocol messages between eidas- Nodes and the underlying transport mechanisms. SAML bindings for transporting SAML protocol messages are defined in [eidas-interop-architecture] SAML AuthnRequest eidas-connectors SHOULD NOT provide AssertionConsumerServiceURL. If included, the eidas-service MUST compare the value with the SAML metadata element <md:assertionconsumerservice> using case-sensitive string comparison and issue an error if the value does not match. eidas-connectors SHOULD NOT use ProtocolBinding. eidas-connectors MUST support ForceAuthn. ForceAuthn MUST be set to true. eidas-connectors MUST support ispassive. ispassive SHOULD be set to false. AttributeConsumingServiceIndex MAY be included. eidas-connectors SHOULD use ProviderName to indicate the actual service provider filing the authentication request.<saml2p:nameidpolicy> SHOULD be used to indicate the requested name identifier format. <saml2p:requestedauthncontext> SHALL be used to indicate the requested eidas Levels of Assurance. Implementations MUST support the eidas Levels of Assurance (LoA) as defined in Section eidas-connectors SHOULD request a specific LoA that is defined as a URI. Implementations requesting a LoA MUST limit the value of the Comparison attribute of <saml2p:requestedauthncontext> to "minimum" or exact. eidas-service implementations MUST support all <saml2p:authnrequest> child elements and attributes defined by [SAML2Core], but MAY provide that support in the form of returning appropriate errors when confronted by particular request options. However, implementations MUST fully support the options enumerated above. SAML AuthnRequest messages MUST be signed according to [eidas-interop- Architecture] SAML Response The status of the SAML response MUST be indicated using the <saml2p:status> element providing at least one <saml2p:statuscode>. Page 28 of 71

29 The <saml2:subject> element of the assertions issued by an eidas-service MUST contain a <saml2:nameid> element. Details of the <saml2:nameid> are defined in Section The elements <saml2:authncontext> and <saml2:authncontextclassref> MUST contain a URI describing an eidas LoA according to Section A SAML assertion MUST include at least the attributes requested as mandatory (indicated in the SAML authentication request by the attribute isrequired= true ), otherwise the SAML response MUST include an appropriate error message.the NameFormat value of a <saml2:attribute> MUST be urn:oasis:names:tc:saml:2.0:attrname-format:uri. The attributes and names are defined in Section 4.3.of [SAML-Meta] MUST be signed and SAML assertions MAY be signed according to [eidas-interop-architecture]. SAML assertions MUST be encrypted according to [eidas-interop-architecture]. Page 29 of 71

30 3.9. Attribute Definitions In this section, a basic set of attributes is defined Name Identifier It is RECOMMENDED to use a person identifier of [Attr-Profile] as name identifier Levels of Assurance The following URIs are valid: eidas Attributes The complete list of attributes supported by the eidas minimum data sets are defined in [Attr-Profile] Additional Attributes Exchange of further additional attributes between eidas-connector and eidas- Service MAY be supported. Attribute definitions are out-of-scope of this specification and of [Attr-Profile]. Page 30 of 71

31 3.13. Private/Public Sector SP For indicating whether an authentication request is made by a private sector or public sector SP, the following defined element <eidas:sptype> MUST be present either in the <md:extensions> element of SAML metadata or in the <saml2p:extensions> element of a <saml2p:authnrequest>. The <eidas:sptype> element can contain the values public or private only. <?xml version="1.0" encoding="utf-8"?> <xsd:schema xmlns=" xmlns:xsd=" targetnamespace=" elementformdefault="qualified" attributeformdefault="unqualified" version="1"> <xs:element name="sptype" type="sptypetype"/> <xs:simpletype name="sptypetype"> <xs:restriction base="xs:string"> <xs:enumeration value="public"/> <xs:enumeration value="private"/> </xs:restriction> </xs:simpletype> Page 31 of 71

32 3.14. Message Format Examples In the following, samples for SAML Metadata and exchanged SAML messages are provided eidas Connector SAML-Metadata <?xml version="1.0" encoding="utf-8"?> <md:entitydescriptor xmlns:md="urn:oasis:names:tc:saml:2.0:metadata" xmlns:eidas=" xmlns:alg="urn:oasis:names:tc:saml:metadata:algsupport" ID="_9ebc8854ec7f701da9749e87a801e5f2" entityid=" validuntil=" t19:30:26.624z"> <ds:signature xmlns:ds=" <ds:signedinfo> <ds:canonicalizationmethod Algorithm=" <ds:signaturemethod Algorithm=" <ds:reference URI="#_9ebc8854ec7f701da9749e87a801e5f2"> <ds:transforms> <ds:transform Algorithm=" <ds:transform Algorithm=" </ds:transforms> <ds:digestmethod Algorithm=" <ds:digestvalue>t2dvnbfynxqslof4bfjpivaubrsevdjbcpbhulkyh4g=</ds:digestvalue> </ds:reference> </ds:signedinfo> <ds:signaturevalue>g34==</ds:signaturevalue> <ds:keyinfo> <ds:x509data> <ds:x509certificate>miid==</ds:x509certificate> </ds:x509data> </ds:keyinfo> </ds:signature> <md:extensions> <eidas:sptype>public</eidas:sptype> <alg:digestmethod Algorithm=" <alg:signingmethod MinKeySize="256" Algorithm=" <alg:signingmethod MinKeySize="3072" MaxKeySize="4096" Algorithm=" </md:extensions> <md:spssodescriptor AuthnRequestsSigned="true" WantAssertionsSigned="false" protocolsupportenumeration="urn:oasis:names:tc:saml:2.0:protocol"> <md:keydescriptor use="signing"> <ds:keyinfo xmlns:ds=" <ds:x509data> <ds:x509certificate>miid==</ds:x509certificate> </ds:x509data> </ds:keyinfo> </md:keydescriptor> <md:keydescriptor use="encryption"> <ds:keyinfo xmlns:ds=" <ds:x509data> <ds:x509certificate>miid==</ds:x509certificate> </ds:x509data> </ds:keyinfo> <EncryptionMethod Algorithm=" 256-gcm"/> </md:keydescriptor> Page 32 of 71

33 <md:nameidformat>urn:oasis:names:tc:saml:2.0:nameidformat:persistent</md:nameidformat> <md:nameidformat>urn:oasis:names:tc:saml:2.0:nameidformat:transient</md:nameidformat> <md:nameidformat>urn:oasis:names:tc:saml:1.1:nameidformat:unspecified</md:nameidformat> <md:assertionconsumerservice Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location=" isdefault="true"/> </md:spssodescriptor> <md:organization> <md:organizationname xml:lang="en">eidas Connector</md:OrganizationName> <md:organizationdisplayname xml:lang="en">eidas Connector</md:OrganizationDisplayName> <md:organizationurl xml:lang="en"> </md:organization> <md:contactperson contacttype="technical"> <md:company>eidas Connector Operator</md:Company> <md:givenname>john</md:givenname> <md:surname>doe</md:surname> <md:telephonenumber> </md:TelephoneNumber> </md:contactperson> </md:entitydescriptor> eidas Service SAML Metadata <?xml version= 1.0 encoding= UTF-8?> <md:entitydescriptor xmlns:md= urn:oasis:names:tc:saml:2.0:metadata xmlns:alg= urn:oasis:names:tc:saml:metadata:algsupport xmlns:saml2= urn:oasis:names:tc:saml:2.0:assertion xmlns:mdattr= urn:oasis:names:tc:saml:metadata:attribute ID= _9ebc8854ec7f701da9749e87a801e5f2 entityid= validuntil= T19:30:26.624Z > <ds:signature xmlns:ds= > <ds:signedinfo> <ds:canonicalizationmethod Algorithm= /> <ds:signaturemethod Algorithm= /> <ds:reference URI= #_9ebc8854ec7f701da9749e87a801e5f2 > <ds:transforms> <ds:transform Algorithm= /> <ds:transform Algorithm= /> </ds:transforms> <ds:digestmethod Algorithm= /> <ds:digestvalue>t2dvnbfynxqslof4bfjpivaubrsevdjbcpbhulkyh4g=</ds:digestvalue> </ds:reference> </ds:signedinfo> <ds:signaturevalue>g34==</ds:signaturevalue> <ds:keyinfo> <ds:x509data> <ds:x509certificate>miidpwa==</ds:x509certificate> </ds:x509data> </ds:keyinfo> </ds:signature> <md:extensions> <mdattr:entityattributes"> <saml2:attribute Name=" Page 33 of 71