OpenNCP integration with SMP

...

PARTICIPANTS

Today's Meeting Participants:

...

1. 1. e-SENS extended
      1. We can try to have a full stack SMP to be tested in April's Connectathon
   2. e-SENS not extended
      1. We go for EXPAND (EXPANDATHON)
      2. We should implement using the current SMP implementation and inform what requirements should implemented later
      3. We won't have DNSSEC in DIGIT's DNS for EXPANDATHON
         1. If we define DNSSEC as a MUST we need to have our own SMP/SML/DNS with DNSSEC in EXPANDATHON. Otherwise we can use the current infrastructure (we need an agreement with Jerry from UNIPI)
         2. Joao Cunha and Uwe Roth to discuss if we can relax the DNSSEC requirement (at least for the pilot, but state it as mandatory for the future)
         3. Adrien suggests to forget about DNSSEC. PEPPOL doesn't have it.
      4. SMP: has lack of documentation
         1. It's almost done for SML but for SMP still has to be done
         2. Ask IHE for support for SMP/SML
      5. Regarding the developments to be made in OpenNCP:
         1. Change TSL-Editor to add a TSL-to-SMP transformator (e.g. XSLT)
         2. We can use the current SMP/SML if we decide to discard DNSSEC. Otherwise we'll need to have a local development environment with SMP/SML and a DNS server with DNSSEC
         3. Without DNSSEC, we can be provided a specific SMP user with sufficient rights to PUT the SMP files
         4. DIGIT has a SMP client JAR file to do the GET that they can provide
         5. PUT takes an unsigned SMP file
         6. SMP signs the SMP file
         7. Validation of SMP signature is made by the client JAR file in NCP-B. In case we have multiple signatures (scenario #2), we can use Apache Santuario (Massimiliano Masi)
         8. Then we can consume the data
         9. We will need to have the SMP certificate in the NCP truststore
         10. As for the caching:
             1. Which component should host it? Study this with Kostas Karkaletsis
             2. We need to move some properties from the epsos properties DB to the cache
             3. Cache should be in TZ2 (NCP-B), not in the NI
             4. Study which properties are fetched from the DB and which components are responsible for that
         11. For now, the developments should focus on using SMP for endpoints, certificates and search masks
         12. How do we expect to access the information of TRC-STS in LAM?
             1. If we just need the URL: we can do a nslookup directly in the DNS for the specific NAPTR record that will save the address of each country TRC-STS
             2. If we need more than just the URL (more metadata): we'll need to use the normal SMP/SML workflow
         13. When TSL/SMP file is signed by a scheme operator, the signature should be a XaDES. But its adoption depends on the Actions agreed:
             1. In #1: we don't need
             2. In #2 or #3: e-SENS e-Signature BB says that we should use a XaDES since we have a qualified signature. In scenario #2 SMP can have a XMLDSIG, while NCP will have a XaDES.
             3. XaDES = XMLDSIG that as a MANIFEST with some properties

Photos of the whiteboard:

• https://openncp.atlassian.net/wiki/download/attachments/65634340/20151015_174508.jpg?api=v2
• https://openncp.atlassian.net/wiki/download/attachments/65634340/20151015_174512.jpg?api=v2