Additional Proposals for extensions ELMO/EMREX by Hochschule Harz (HSH)

[SebastianKarius]

Additional Proposals for extensions ELMO/EMREX (including Workshops Göttingen 2021 and other Online Workshops)

20.5.2022

Edit 17.12.2022. The issues have been split between this repository and ELMO Schemas with further clarifications available in the comment further down.

• Hermann Strack, HS Harz, hstrack@hs-harz.de
• Sebastian Karius, HS Harz, skarius@hs-harz.de

1. Additional (XML) 3rd signature field in ELMO, concerning ELMO XML diploma data only (without attachements) – for better machine-machine operations on ELMO container
2. Interoperability for multiple ELMO container Attachements (not only one diploma-PDF) and their various attachements types attributes
3. If necessary: check Alignment/Interoperability of ELMO signatures according to EU/ETSI Signature standards (XAdes….)
4. If necessary: additional XML Elements for explicit Signatures Types/Attributes: advanced / qualified … (in ELMO + EMREX)
5. Integrations of eID/digital IDs: Types, LoA, source/sender, EU eIDAS eID minimum data set fields (with/without VC)
6. Integrations of transfer/access restrictions or receiver restrictions attributes (privacy, GDPR)
7. Integration of explicit time-depending validity attributes (expires on ….; because practical crypotography generates only temporary valid crypto data (e.g. for hashes, signatures ), adding links to eIDAS preservation services options
8. (Security) Policy references/links (e.g. including statements for minimal security requirements)
9. Linkage / relations ELMO-EMREX: additional encapsulations/headering levels (see e.g. OSI or SOAP, IPv6-sub-headering/next-header), e.g. for trustworthy NCP features lookups

[mirkostanic]

Questions regarding signatures are protocol related and not XML schema related. Suggest to move to EMREX protocol level.

[mirkostanic]

After a meeting with HS Harry at the issues were further clarified and a decision was made to split this ticket between the ELMO Schemas repository and here. Below are the updated issues.

1. ELMO issue.

2. Interoperability for multiple ELMO container Attachements (not only one diploma-PDF) and their various attachements types attributes. Although ELMO supports multiple attachments and multiple file types as attachments most clients expect only a PDF to be present. We need a list of "approved" file types which the clients can reasonably expect. One such candidate is a detached signature file which can be provided if the digital signature is not embedded. This issue is further clarified in the next points regarding compliance with the eIDAS regulation.

3. If necessary: check Alignment/Interoperability of ELMO signatures according to EU/ETSI Signature standards (XAdes….). This issue affects both ELMO and EMREX and is present here and in the ELMO repository. Make EMREX and ELMO compliant with the eIDAS regulation. This includes support for qualified electronic signatures which include the signer identity and are outlined in PAdES (PDF Advanced Electronic Signature) and XAdES (XML Advanced Electronic Signature) standards as well as support for detached signatures mentioned in the previous issue.

4. If necessary: additional XML Elements for explicit Signatures Types/Attributes: advanced / qualified … (in ELMO + EMREX). This issue affects both ELMO and EMREX and is present here and in the ELMO repository. Closely related to issue 3, concerns compliance with eIDAS regulation.

5. Integrations of eID/digital IDs: Types, LoA, source/sender, EU eIDAS eID minimum data set fields (with/without VC). Some countries do not have personal identification data on the issued documents and with the upcoming EUDI wallet the PID verifiable credential could be attached to the XML data as a proof of ownership. This issue requires no work on EMREX part apart from outlining and clarifying this issue to potential issuers in the EMREX Standard repository.

6. Integrations of transfer/access restrictions or receiver restrictions attributes (privacy, GDPR). This issue affects both ELMO and EMREX and is present here and in the ELMO repository.

7. ELMO issue.

8. (Security) Policy references/links (e.g. including statements for minimal security requirements). EMREX or EWP should implement at the very least a basic penetration testing suite to be performed on potential issuers (EMPs) before adding them to the registry. Seeing as EMREX uses the EWP registry this should be escalated to the EWP level. Also provide a list of best practices for EMCs to follow. If the EMC registry is also established the testing could also be mandated for them as well.

9. ELMO issue.