Hello, These are the answers to the questions you've sent. In order to clarify how STORK works and make easy to answer these and future questions, I've also attached a short document to describe the necessary steps to work as a Service provider in STORK platform. 1) Since STORK is authenticating users with multiple country's eID cards, and every country has different national laws applying to the forwarding of user's attributes extracted out of the eID cards, does our IDM system need to own one accepted certificate per country? Example: STORK allows users from 10 different countries to authenticate, does NSN need to own the national certificates of these 10 countries too? NO: Take into account that a server provider must only "talk" with its national PEPS/MW. Any further redirection (to End-User's Member State PEPS/MW) will be perform by its national server. So Server providers are only authenticate by its nationals institutions. 2) STORK must have legal contracts with the governments of the countries whose eID cards it is handling. Do these legal contracts allow STORK to forward the attributes of the users to a third party (i.e. NSNs IDM Demo System / i.e. to the FiWare Demo system). I think not. Perhaps the legal department of STORK needs to clarify this. The other issue is cross-border data transfer. Can all attributes be transferred to e.g. a German server? - "Legal contract with governments" NO: Governments are part of the STORK consortium. - "Forward attributes": No contract is necessary, the End-User sends its acknowledgement to send the attribute list to the Server provider. - "Can all attributes be transferred?" : Some attributes could be not available in some countries according with each country regulations or technology current state of implementation. Anyway the current set of attributes has already analyzed by STORK. 3) Need for an unencrypted SAML request and response in order to check if it is complaint with the NSN SAML implementation (trace needed). Application layer trace is necessary since at communication layer the SAML message is encrypted To correctly integrate a Service provider with STORK you must use the STORKSAMLEngine provided because it includes some extensions to the standard You can get the interface specifications from STORK web site (https://www.eid-stork.eu/) 4) What are the requirements for such a service provider which enables it to forward her users to the STORK system for identification? The basic requirement is to send the registration form to its national authority. Check the attached document where we've tried to explain the information that should be provided. 5) Which keys (for encryption, for signing and for TLS protection) are required for the service provider e.g. LIMOSA? A server provider must have a valid certificate from the country where it attempts to be registered. If you need any additional question, please send us. Best Regards. ************************************ * Antonio García-Vázquez * * (+34) 91 214 9384 * * antonio.garcia at atosresearch.eu <mailto:antonio.garcia at atosresearch.eu> * ************************************ From: Goetze, Norbert (NSN - DE/Munich) [mailto:norbert.goetze at nsn.com] Sent: martes, 22 de noviembre de 2011 13:07 To: Seidl, Robert (NSN - DE/Munich); Antonio Garcia Vazquez Cc: Bauer-Hermann, Markus (EXT-Tieto - DE/Munich) Subject: STORK -> list of requirements for e.g. LIMOSA Hi Antonio, I checked the STORK homepage an found the following statement: The role of the STORK platform is to identify a user who is in a session with a service provider, and to send his data to this service. Whilst the service provider may request various data items, the user always controls the data to be sent. The explicit consent of the owner of the data, the user, is always required before his data can be sent to the service provider. Looking deeper into the STORK descriptions, it looks like LIMOSA would be a service provider mentioned in the statement above. So my questions are: 1. What are the requirements for such a service provider which enables it to forward her users to the STORK system for identification? 2. Which keys (for encryption, for signing and for TLS protection) are required for the service provider e.g. LIMOSA? Can you forward us such a requirement list from which is made clear which public keys, private keys and certificates must be installed on e.g. the LIMOSA site? BR, Norbert _____________________________________________ From: Seidl, Robert (NSN - DE/Munich) Sent: Thursday, November 17, 2011 4:04 PM To: Antonio Garcia Vazquez Cc: Goetze, Norbert (NSN - DE/Munich); Bauer-Hermann, Markus (EXT-Tieto - DE/Munich) Subject: FI-WARE IDM Certificate for STORK Hi Antonio, Please find attached a summary of our questions as we discussed today. Questions 1&2 relates to the certificate whereas question 3 relates to your SAML library. Question 1: -------------- Since STORK is authenticating users with multiple country's eID cards, and every country has different national laws applying to the forwarding of user's attributes extracted out of the eID cards, does our IDM system need to own one accepted certificate per country? Example: STORK allows users from 10 different countries to authenticate, does NSN need to own the national certificates of these 10 countries too? Question 2: -------------- STORK must have legal contracts with the governments of the countries whose eID cards it is handling. Do these legal contracts allow STORK to forward the attributes of the users to a third party (i.e. NSNs IDM Demo System / i.e. to the FiWare Demo system). I think not. Perhaps the legal department of STORK needs to clarify this. The other issue is cross-border data transfer. Can all attributes be transferred to e.g. a German server? Question 1: -------------- Need for an unencrypted SAML request and response in order to check if it is complaint with the NSN SAML implementation (trace needed). Application layer trace is necessary since at communication layer the SAML message is encrypted. Many thanks in advance Robert ------------------------------------------------------------------ This e-mail and the documents attached are confidential and intended solely for the addressee; it may also be privileged. If you receive this e-mail in error, please notify the sender immediately and destroy it. As its integrity cannot be secured on the Internet, the Atos group liability cannot be triggered for the message content. Although the sender endeavours to maintain a computer virus-free network, the sender does not warrant that this transmission is virus-free and will not be liable for any damages resulting from any virus transmitted. Este mensaje y los ficheros adjuntos pueden contener informacion confidencial destinada solamente a la(s) persona(s) mencionadas anteriormente pueden estar protegidos por secreto profesional. Si usted recibe este correo electronico por error, gracias por informar inmediatamente al remitente y destruir el mensaje. Al no estar asegurada la integridad de este mensaje sobre la red, Atos no se hace responsable por su contenido. Su contenido no constituye ningun compromiso para el grupo Atos, salvo ratificacion escrita por ambas partes. Aunque se esfuerza al maximo por mantener su red libre de virus, el emisor no puede garantizar nada al respecto y no sera responsable de cualesquiera danos que puedan resultar de una transmision de virus. ------------------------------------------------------------------ -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://lists.fiware.org/private/old-fiware-security/attachments/20111125/02164ab1/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: FI-WARE STORK Step by Step.v1.0.docx Type: application/octet-stream Size: 224096 bytes Desc: FI-WARE STORK Step by Step.v1.0.docx URL: <https://lists.fiware.org/private/old-fiware-security/attachments/20111125/02164ab1/attachment.obj>
You can get more information about our cookies and privacy policies clicking on the following links: Privacy policy Cookies policy