Regarding the representative data set, amended the SAML attribute name by adding “representative” for completeness 

1.4.4 , 1.8.3

1.8.6

1.8.4

Specification for use of the PowerOfRepresentationScope sector specific OOTS eIDAS attribute and the controlled values vocabulary. 

NB: follow-up to short-term action agreed in EUDI Wallet & Synergies Contact Group. Provisional content to allow MS to prepare implementation. The attribute has not been formally approved and published yet.  

Regarding the representative data set, added the amendment of the SAML attribute name by “representative” for completeness 

2.1.2.6, 2.3.3,  2.3.2

2.1.1, 2.1.2.1, 2.1.3.1

2.1.1

Changed the title of section 2.1.2

2.1.2

Changed the title of section 2.3.2

2.3.2

2.3.2,

2.3.2

Specification of the use of the PowerOfRepresentationScope sector specific OOTS eIDAS attribute. 

NB: follow-up to short-term action agreed in EUDI Wallet & Synergies Contact Group. Provisional content to allow MS to prepare implementation. The attribute has not been formally approved and published yet.

2.3.4

Clarified that the attribute may (in the future) be exchanged during eIDAS authentication of the user. If it is available from eIDAS, it must be included in the OOTS  evidence request.

2.3.4

Clarifying the use of component sdg:DistributedAs  to markup structured and unstructured sdg:DataServiceEvidenceTypes.

Including Diagram, description and improvement of element definitions. The corresponding rules where changed to allow the use of structured evidence types without an appropriate OOTS data model only in such cases where another sdg:DistributedAs  element exists for the same sdg:DataServiceEvidenceType  that provides a visual representation. (Rules: R-DSD-RESP-C039, R-DSD-RESP-C041, R-DSD-SUB-C038, R-DSD-SUB-C040)

3.1.4 (4.2.2/4.3.2.1),

3.1.5 (5.5.2/5.5.2.1), 

New Version of Codelist OOTSMediaTypes 2023-08 (Correction of Errors)

New Version of Codelist CountryIdentificationCode (Creation of Alpha-2 code  refactored subset for ISO 3166 which uses country code EL for Greece instead of GR)

Impact: this change is considered a correction rather than a breaking functional change as there are no known implementations or other parts of the specification that assume or depend on use of the Alpha-3 code. 

3.5

New Version of Codelist due to new URIs 

All URIs and URNs used in the metadata of the codelists have been  changed from "tech.europa.eu" to "tech.ec.europa.eu". New version 2023-08 of all OOTS codelists 

Impact:

• Implementations of the previous and current specifications that validate the URI are not compatible.

3.5

New multilingual element "sdg:Note" (0..n) in sdg:DataServiceEvidenceType

Adding new xsd element sdg:Note to sdg:DataServiceEvidenceType in SDG-GenericMetadataProfile-v1.0.0.xsd and adjusting the corresponding implementation guidelines and XML examples for the DSD a including associated rules (R-DSD-RESP-C042, R-DSD-RESP-C043, R-DSD-ERR-C026, R-DSD-ERR-C027, R-DSD-SUB-C041, R-DSD-SUB-C042) and schematron files to support the new xsd element. The multilingual note, page or document about a DataServiceEvidenceType may contain any additional information helpful for the user to execute the process (e.g. payment information, date since which evidences are available)

Impact:

• XML instances based on the previous XSD version remain valid against the updated version and can be processed by systems designed to support the new XSD.
• XML instanced based on the updated XSD that use the new element are not valid against the previous XSD and are not compatible with systems that perform XSD validation.  
• Some implementations based on the previous XSD version may simply ignore new element content.

3.1.4 (4.3. 4.4)

3.1.5 (5.3.1, 5.5)

Correction of some data models in the EB Query and EB LCM

Some data models in the EB Query and EB LCM did not contain the lang attribute and correct cardinalities for Requirement Name. However, the tables, XML Examples and XSD were correct. All requirement structures now comprise name: text (1..n) and name/@lang (M)

3.2.4 (4.2.1, 4.3.1 )

3.2.5 (5.2.3, 5.4.1)

Correction of some tables and data models in DSD Query and DSD LCM 

All tables and data models in the DSD Query and DSD LCM did not contain the lang attribute and correct cardinalities for Publisher Name. All Publisher structures now comprise name: text (1..n) and name/@lang (M). Corresponding Business Rules have been added (R-DSD-RESP-C046, R-DSD-RESP-C047, R-DSD-SUB-C045, R-DSD-SUB-C046)

3.1.4 (4.3 )

3.1.5 (5.3.2 5.5)

New multilingual element Name (0..n) in Access Service

The DSD Query and DSD LCM did not contain a name of the access service. Both transactions now contain a name of an access service to offer the possibility to label the access service. All access services now comprise name: text (0..n) and name/@lang (M). Corresponding XML examples have been amended and  Business Rules have been added (R-DSD-RESP-C044, R-DSD-RESP-C045, R-DSD-SUB-C043, R-DSD-SUB-C044)

Impact:

• XML instances based on the previous XSD version remain valid against the updated version and can be processed by systems designed to support the new XSD.
• XML instanced based on the updated XSD that use the new element are not valid against the previous XSD and are not compatible with unmodified systems that perform XSD validation.
• Some implementations based on the previous XSD version may simply ignore new element content.

3.1.4 (4.3 )

3.1.5 (5.3.2 5.5)

3.1.6

New rules created to reflect the cardinality change of Publisher in AccessService

XSD cardinality changes of sdg:Publisher (from mandatory to optional) affected the existing DSD Query and DSD LCM baseline where the Publisher is a mandatory element. Corresponding Business Rules have been added to ensure the use of publisher in these transactions (R-DSD-SUB-S038, R-DSD-RESP-S017).

3.1.4 (4.3 )

3.1.5 (5.3.2 5.5)

Correction of rules for EB LCM and DSD LCM

The following rules have been changed (R-EB-SUB-S036, R-EB-SUB-S038, R-EB-SUB-S040, R-DSD-SUB-S028) and split by adding (R-EB-SUB-S057, R-EB-SUB-S058, R-EB-SUB-S059, R-EB-SUB-S060, R-DSD-SUB-S036, R-DSD-SUB-S037) in order to ensure the correct functioning of the validation of the EB LCM and DSD LCM process with regard to the use of source and target  objects in the associations expressed by registry objects.

3.1.4 (5.5)

3.2.5 (5.4)

Refinement in the handling of the severity attribute 

The rule R-EB-ERR-011 was split into the rules R-EB-ERR-011 and R-EB-ERR-018 to better validate the severity attribute of the EB Error Response.

3.2.4 (4.4)

Clarification of the use of country code parameter in EB queries

An Information Box has been added upfront to the EB queries to clarify to which country a query should be addressed.

• The first query of the Evidence Broker (Get List of Requirements) is intended to establish the context of the Evidence Requester in order to identify the requirements of the procedure to be carried out.
• The second query of the Evidence Broker (Get Evidence Types for Requirement) determines the context of the Evidence Provider in order to identify the Evidence Types in the Evidence Providing Member State. 

3.2.4.2

3.2.4.3

In diagram EB LCM "Requirement", cardinality of @lang  is M, not [ 1..1 ]

3.2.5

Clarification of the use of country codes in Common Services discovery

The clarification on country codes to be used for the three CS API queries also applies to the Common Services discovery feature. 

3.4.3

Added the specific DNS name template that will be used for common service discovery.

3.4.3.

Fixed wrong subsection numbering

There were two sections number "3":  discovery of common services and proxy caching. The latter is now "4", and the references are "5" 

3.4

Clarify that OOTS proxy caches are allowed to serve stale content if an error occurred in accessing the Common Service origin server

3.4

Document the use of HTTP status codes in the common service REST binding.

3.6.2.5

Added specific values for AS4 headers for use with LCM. (They were in the referenced OASIS specification, but including them here directly is more convenient).

3.6.3.4

Specification of three alternative common service "read" access control mechanisms. 

• A:  no access control (public access)
• B:  access limited based on network address (whitelisting)
• C: access granted based on TLS client certificate 

Provision specification pending decision (expected end of September). After a decision is made, to be edited to reflect the choice.

3.7.4

New section on Common Services logging.

Partially relates to the three option for "read" access.

After a decision is made, to be edited to reflect the choice.

3.8

Correction in URI names

All URIs in all parts of this chapter that referenced "tech.europa.eu" are updated to "tech.ec.europa.eu" 

3.*

New optional slot SpecificationIdentifier in LCM

An optional element rim:Slot "SpecificationIdentifier"  was introduced to indicate the version of the LCM specifications and to distinghish between DSD baseline and DSD refactored LCM. Note:

• For the DSD LCM Refactored the use of the rim:Slot "SpecificationIdentifier"  is mandatory with value "oots-lcm:v1.0"
• For the DSD LCM Baseline the use of the rim:Slot "SpecificationIdentifier"  is not allowed.
• For the EB LCM the use of the rim:Slot "SpecificationIdentifier" is only mandatory in cases where a SubmitObjectsRequest is combined with DSD LCM Refactored.

A generic model has been integrated to section 3.6 to illustrate the common element for LCM better for the EB and DSD.

Impact:

• This slot is restricted to, and serves to indicate the use of, the new refactored DSD LCM. As the EC Common Services implementation is currently the only consumer of LCM submissions and will support both the baseline and refactored LCM submission feature, there is no immediate practical impact on any existing MS implementations.

3.6

3.1.1 (3.1.5./3.1.6)

3.2.1 (3.2.5)

New multilingual element "sdg:Description" (0..n) in sdg:Publisher

Adding new XSD element sdg:Description to sdg:Publisher in SDG-GenericMetadataProfile-v1.0.0.xsd and adjusting the corresponding implementation guidelines and XML examples for the DSD including associated rules (R-DSD-RESP-C048, R-DSD-RESP-C049, R-DSD-SUB-C047, R-DSD-SUB-C048) and schematron files to support the new xsd element. The description about a publisher may contain any additional information helpful for the user to understand the entity and execute the process

Impact:

• XML instances based on the previous XSD version remain valid against the updated version and can be processed by systems designed to support the new XSD.
• XML instanced based on the updated XSD that use the new element are not valid against the previous XSD and are not compatible with unmodified systems that perform XSD validation.
• Some implementations based on the previous XSD version may simply ignore new element content.

3.1.4 (4.3 )

3.1.5 (5.3.2 5.5)

New section for business rules of the EB and DSD

All business rules have been moved into a new separate section and have been deleted from the previous subsections. The business tables are now generated as html files from business rules xlsx in git to ensure better maintanance and minimize inconsistencies between different sources. 

3.1.7. Business Rules (DSD)

3.2.6 Business Rules (EB) 

3.7. Business Rules of the Regrep LCM

Consistent use of attribute checkReference in LCM

According to CS API specifications the use of the RegRep attribute checkReferences is mandatory and MUST be "true". However, the LCM specifications of the EB and DSD did not consider the attribute in the Data Models, Examples and Tables. The element was included to all DSD and EB LCM descriptions. In section 3.6 it was noted that if the references are not resolveable an UnresolvedReferenceException will be returned. The list of Error codes for the LCM did not include this exception type. The description was changed so that unresolved reference will be responded by the server with  rs:InvalidRequestExceptionType (LCM:ERR:0003)

3.6 

3.1.5 (5.5)

3.1.6 (6.5)

3.2.5 (5.4)

Corrected a diagram that used a removed feature

The BPMN diagram diagram referenced a feature from an earlier draft that has been removed.  Corrected the diagram,

4.4

This section only covered the single request-response flow.

Added a second diagram and a new section on flow choreograph  that covers the two flows.

4.4.4.1

Detection and elimination of duplicate requests 

Document that requests have unique identifiers and are to be processed at most once. Duplicate requests (duplicate in the sense of reusing an identifier) are to be rejected. Similarly, responses reference uniquely identified requests. For a request there is at most one response. Duplicate responses (duplicate in the sense of reusing an identifier) are to be rejected.

4.4.4.1

Added a subsection on timeouts for OPP and DS.

OPP and DS implement a configurable timeout feature. Timeouts on DS should take into account automated and manual processing and should allow sufficient time for user review. They are reported to the OPP as timeout exception.

4.4.4.4.

Clarified handling of structured and unstructured evidences

Clarifying the use of component sdg:DistributedAs  to markup structured and unstructured sdg:DataServiceEvidenceTypes. Including Diagram, description and improvement of element definitions. The corresponding rules were changed to Warnings in order to allow the use of structured evidence types without an appropriate OOTS data model and  visual representation in exceptional cases and if explicitly wished by the user. (Rules: R-EDM-REQ-C070, R-EDM-RESP-C044, R-EDM-RESP-C045)

4.5.1 (3.5)

Clarified the interpretation of the date and time of explicit request 

If the request is issued upon explicit request by a user, the issue date time of the request must not be materially different from the date and time at which the user provided his/her explicit request.

4.5.1.2.3

4.5.1.2.7

4.5.4

Corrected wrong value "urn:oasis:names:tc:ebxml-regrep:ErrorSeverityType:PreviewRequired" with correct value 'urn:sr.oots.tech.ec.europa.eu:codes:ErrorSeverity:EDMErrorResponse:PreviewRequired" in rs:Exception/severity

4.5.3 (2)

Change in cardinality of the Requirement and Procedure slots.

The elements query:QueryRequest/rim:Slot[@name='Requirement'] and query:QueryRequest/rim:Slot[@name='Procedure'] are now made mandatory (from 0..1 to 1..1) in the EvidenceRequest. Business Rules (R-EDM-REQ-S007, R-EDM-REQ-S011) and Schematrons have been changed accordingly.

Impact:

• Evidence requests based on the previous version of the specification that do not include one or both Slots are not valid against the current specification version.
• Evidence requests based on the current version of the specification are valid against and compatible with the previous specification version.

4.5.1 

4.6

Allow the receiver of the evidence request to understand which country sends an Evidence Request / Evidence Response and Evidence Error Response

New rules to make the use of the country mandatory for the main sender of a document (currently optional). Change also highlighted in the EDM data models. Reasoning is to understand which country sends an Evidence Request / Evidence Response and Evidence Error Response. 

• Evidence Request: A value for 'AdminUnitLevel1' MUST be provided if the sdg:Agent/sdg:Classification value is "ER" (R-EDM-REQ-C072, R-EDM-REQ-C073)
• Evidence Response: A value for 'AdminUnitLevel1' MUST be provided if the sdg:Agent/sdg:Classification value is "EP" (R-EDM-RESP-C046, R-EDM-RESP-C047)
• Error Response: A value for 'AdminUnitLevel1' MUST be provided (R-EDM-ERR-C023)

Impact:

• XML content based on the previous version of the specification that does not include AdminUnitLevel1 is not valid against the current specification version.
• XML content based on the current version of the specification is valid against and compatible with the previous specification version.

4.5.1

4.5.2

4.5.3

4.6

Explain the semantics of an empty RegistryObjectList

Document that a RegistryObjectList in a response may be empty for two reasons:

• there are no pieces of evidence matching the query
• there are pieces of evidence matching the query but the user (during preview) decides not to use any of them. 

4.5.2.2.1

4.10.5.1

Explain the semantics of the order of Slots

Document that the order of Slots is not significant, they are to be processed based on the value of their name attribute. Still good practice to follow the diagrams.

4.5.1.1

4.5.2.1

4.5.3.1

Added a link to the "patched" ebMS3 core XSD that includes the type attribute for the property element. 

4.7 (2.1)

4.7 (2.4)

4.7

4.8

4.7.1.1

New implementation guideline to detail the rules and principles to implement the ebMS header for the different Evidence Exchange messages.

The new guideline illustrates the ebMS Header Model, provides examples and detailed descriptions for each concept along the ebMS specification and its relation to the OOTS and introduces a set of Business Rules for relevant information entities to prove the correct format of instances.

4.7.1, 4.7.2

The type attribute on party identifier is mandatory, not optional, in our implementation guidelines.

4.7.2.2

Specify constraints on certificates to be used in eDelivery

Added a requirement that certificates used in access points shall follow the requirements and recommendations regarding the Digital Certificates used in eDelivery.

4.7.3

Updated the reference to Requirements and recommendations regarding the Digital Certificates used in eDelivery to the latest version.

4.7.6

Corrected a wrong reference

Reference to Article 18 of IA should be to Article 17

4.8.2

Corrected a wrong reference

Reference to Article 17 (5) should be to 28 (6)

4.8.5

Added a new section on log retention. For now limited to quoting the IA 17 (4).

4.8.6

Clarified that preview-related functionality may be provided by Intermediary Platform.

4.9.1

Clarified that the evidence response contains an empty registry object list if there are no pieces of evidence matching the request for the user or if the user decides not to use any pieces of evidence.  

4.9.1.

Corrected and elaborated on the specification of preview for different HTTP methods

Section 4.9 was internally inconsistent about the allowed HTTP methods for accessing the preview space and the return address.  4.9.4 said "PUT" or "POST",  4.9.5 said PUT or GET.   The example in 4.10 used GET.  To  not break any existing implementation, we now allow all three variants.  

4.9.4

4.9.5

Specification of encoding of parameters in preview and return URLs

The specification was also incomplete on how the URL and method parameters are to be provided (to preview and to return).   

4.9.4

4.9.5

Clarified the life-cycle of the preview URL. 

A URL can be used at most once and only during a defined interval. 

4.9.4

Functionality

Add randomness to preview URL and return URL

Preview URL and return URL should include a random component (i.e. not just be unique but also unpredictable); .

Impact limited to implementations that do not already use e.g. UUID-4:

• Change in DS/PS for preview URL 
• Change in OPP/IP for return URL 

4.9.4

Fixed RFC reference

4.9.4

Explicitly state that portal is to (re)confirm identity of returning user (i.e. knowledge of the return URL is not enough).

4.9.4

Also define format and life-cycle of return URL

4.9.4

Reminder to recommend use of same eID for the two authentications

4.9.4

The subsection on previewing multiple evidences was too suggestive/speculative. It is now limited to documenting the benefits of user sessions to obviate the need for re-authentication. Renamed the section to better match the content.

4.9.6

Correction of URIs

All URIs in all parts of this chapter that referenced "tech.europa.eu" are updated to "tech.ec.europa.eu" 

4.*

New tables for business rules of the Evidence Exchange

The business tables are now generated as html files from business rules xlsx available in GIT to ensure better maintanance and minimize inconsistencies between different sources. 

4.6

Description for the use of the sector specific attribute "PowerOfRepresentationScope"

In the context of the SDG, the sector specific "PowerOfRepresentationScope" attribute may be available from the eIDAS authentication of the user to the Online Procedure Portal or Intermediary Platform.  It may contain the power of representation scope of a representative person representing a different represented person. If retrieved from eIDAS, it MUST be included as sdg:SectorSpecificAttribute of the rim:Slot "AuthorizedRepresentative" (see chapter 2.3 and descriptions in chapter 4.5.4, section 3.6.3 of Authorized Represenative slot and example). Also Examples in section 4.5.4 and Git were updated.

4.5.1 (3.6.3)

4.5.4

Corrected/updated several XML examples

Updated EB/Complete XML examples "4.3 Get Evidence Types for Requirement Query" and LCM\Complete XML Example "5.4 LCM Submit Objects to the Evidence Broker - Bulk submission" with the correct use of evidence type lists and evidence types, specifically the example about Secondary Education

GIT (XML)

Git (XML): Request-Response Samples (4.5.4 ...) and README.md

Correction of OOTS Media Type code list

New Version of Codelist OOTSMediaTypes 2023-08 - Correction of typo "unstructred" and normalization of codelist value for "svg". Update of associated gc, xlsx and xml files and CS description

GIT (codelist): OOTS/OOTSMediaTypes-Codelist.gc and associated files in xlsx directory 

New Version of Codelist due to new URIs 

All URIs and URNs used in the metadata of the codelists have been  changed from "tech.europa.eu" to "tech.ec.europa.eu". New version 2023-08 of all OOTS codelists. Update of associated gc, xlsx and xml files and CS description. 

Impact:

• Implementations of the previous and current specifications that validate the URI are not compatible.

GIT (codelist)

Correction of country code list

New refactored subset version of codelist CountryIdentificationCode - Creation of Alpha-2 code subset for ISO 3166, Removal of Alpha-3 code values, reflecting usage of country code EL for Greece instead of GR

GIT (codelist): External/CountryIdentificationCode-2.3.gc

Several new examples and schematrons for Refactored LCM

Introduce new sections for XML Examples and Snippets for Refactored DSD LCM (3.1.6). Rename existing DSD LCM into - DSD LCM Baseline (3.1.5)

Adding schematrons for Refactored DSD LCM (DSD-LCM_RF)

Note: Due to some impossible but necessary validations of dependencies between DataServiceEvidenceTypes and EvidenceProviders, the associations had to be redefined after the subgroup approval of the Q3 release on 01.09.2023. The examples and schematrons of the Refactored DSD LCM have been updated accordingly.

Schematrons have been added for the Baseline DSD LCM to prove these dependencies without changing the actual underlying model. 

GIT (XML/LCM)

GIT (SCH)

New schematrons (EDM-ebMS) for ebMS header validation (Evidence Exchange)

GIT (SCH)

Addition of optional element Name  for use with AccessService

The XSD was updated with a Name element to allow a name of the Access Service to be presented in the Common Services user interface. An element sdg:Name was added to the <xs:element name="AccessService" type="sdg:DataServiceType"/>. 

Impact:

• XML content based on the previous version of the XSD is valid against the current XSD version.
• XML content based on the current version of the XSD that uses the element is not valid against the previous XSD version.
• Some implementations based on the previous XSD version may simply ignore new element content. 

GIT 

XSD (SDG-GenericMetadataProfile-v1.0.0.xsd)

sch/DSD-SUB-S

sch/DSD-RESP-S

Refactoring the XSD to support new refactored LCM feature

The XSD was updated to implement the required changes for refactored DSD LCM process which holds Access Service and Publishers as separate registry objects:

• The cardinality of name="Publisher" of the <xs:complexType name="DataServiceType"> was changed from from minOccurs="1"  to minOccurs="0" 
• A new declaration was added for <xs:element name="Publisher" type="sdg:EvidenceProviderType"/>

The XSD cardinality changes affected the existing DSD Query and DSD LCM baseline where the Publisher is a mandatory element. Corresponding Business Rules have been added to ensure the use of publisher in these transactions (R-DSD-SUB-S038, R-DSD-RESP-S017). 

Impact:

• XML content based on the previous version of the XSD is valid against the current XSD version. 
• XML content based on the current version of the XSD that uses the element is not valid against the previous XSD version. 

See above on explanation that, as the EC Common Services implementation is currently the only consumer of LCM submissions and will support both the baseline and refactored LCM submission feature, there is no practical impact on MS implementations.

GIT 

XSD (SDG-GenericMetadataProfile-v1.0.0.xsd)

sch/DSD-SUB-S

sch/DSD-RESP-S

Updating the EB LCM and DSD LCM Schematrons to reflect associations 

The following rules have been changed (R-EB-SUB-S036, R-EB-SUB-S038, R-EB-SUB-S040, R-DSD-SUB-S028) and split by adding (R-EB-SUB-S057, R-EB-SUB-S058, R-EB-SUB-S059, R-EB-SUB-S060, R-DSD-SUB-S036, R-DSD-SUB-S037) in order to ensure the correct functioning of the validation of the EB LCM and DSD LCM process with regard to the use of registry objects and source and target  objects in the associations expressed by registry objects.

GIT

sch/DSD-SUB-S

sch/DSD-RESP-S

Updating DSD related XML artifacts to reflect XSD update

All DSD related XML artifacts have been changed. The element sdg:AccessService/sdg:Name and sdg:DataServiceEvidenceType/sdg:Note has been added. 

GIT

xml/LCM (3.1.5, 3.1.6)

xml/DSD (3.1.3, 3.1.4)

Adding tooling to generate HTML documentation from the current Excel format (via XML).

Different files can be generated for combinations of worksheets. This makes it easier to include the content in the Wiki.

GIT  

xlsx/html

Fixed an issue with the code list Excel sheet. 

Due to presence of a column for NO in the procedures sheet,  but no actual values,  the values for some other languages (alphabetically after NO) had the wrong language reference. 

GIT

Procedure Codelist.gc

Ease offline validation 

Some (100% non-functional) XSD changes to allow fully offline validation:

• OOTS driver import XML XSD
• Separate version of OOTS driver that imports local copies of the RegRep4 XSDs.
• Created local copies of the XML XSD and XSD XSD. 
• Edited the local copies of the RegRep4 XSDs to reference local copies of the XML XSD and the XSD XSD.  

GIT

... sdg/oots_driver_v1.0.0.xsd

... driver_v1.0.0_local_imports.xsd

Updated the local copy of the ebMS3 XSD to not import the SOAP XSDs.

GIT ... /xsd/ebms3

New optional Description element for Evidence Provider

Adding an optional Description (0..n) to EvidenceProviderType.  This was a feature request from UX testing. 

Impact:

• XML content based on the previous version of the XSD is valid against the current XSD version. 
• XML content based on the current version of the XSD that uses the element is not valid against the XSD version. 
• Some implementations based on the previous XSD version may simply ignore new element content

GIT

Update the GIT content for the change to the URI on europa.eu.

All URIs in XML, SCH and GC file that referenced "tech.europa.eu" are updated to "tech.ec.europa.eu" 

Impact:  the curent and previous specification versions are incompatible.

GIT

The xlink XSD imports a local copy of the XML xsd.

GIT

Summary of cumulative changes to the XSD since previous Projectathon (not a new change, only a summary. See detailed entries above):​

• Data Service Type has a new multilingual Name (0..n)​
• Data Service Type updated cardinality for Publisher (0..1) for use in refactored LCM​
• Data Service Evidence Type has new multilingual Note (0..n)​
• Evidence Provider Type has new multilingual Description (0..n)​
• Publisher element can be used outside AccessService for use in refactored LCM

GIT

3.1.4, 3.1.5

Updating cardinality of the classes Requirement/Related to from 0..n to 1..n

Updating cardinality of the classes Requirement/Jurisdiction to from 0..1 to 0..n

Updating cardinality of the classes EvidenceType/Jurisdiction to from 0..n to 1..n

This XSD was changed in Q1 2023 release in the query but the change wasn't adopted in the LCM. Both need to be harmonized. 

Updating cardinality of the classes ReferenceFramework to 1..n in the EB evidence type query.

Updating cardinality of the classes ReferenceFramework to 0..n in the EB requirements query.

Some models and tables were inconsistent. Both need to be harmonized so model updated.

Additionally, it was necessary to enable requirements queries without reference frameworks to support MS Development Teams to access the requirements in the EB. Thus, a note on the use of optional parameters in the EB requirements query and business rule (R-EB-REQ-S017)  was changed.  

3.2.4 

3.2.5

3.2.4 (section 4.2)

Constraint relaxed, also allowing ebCore Party ID type unregistered as values for schemeID 

4.5.1.

4.5.1 (3.2, 3.3)

4.5.2 (3.1, 3.2)

4.5.3 (3.1, 3.2)

4.5.1.3.1

2023-05-18

4.5.3 (1, 2, 3.2)

4.6 (4.1)

• In the EvidenceRequest it is be possible to specify multiple agents.  There MUST be one Agent with the classification value ER. One or more optional Agents can be defined with the classification value IP. The classification value EP and ERRP cannot be used. 
• In the EvidenceResponse with status for EvidenceProvider it is possible to specify multiple agents.  There MUST be one Agent with the classification value EP. One or more optional Agents can be defined with the classification value IP. The classification value ER and ERRP cannot be used. 
• In the ErrorResponse" for EvidenceProvider it is only possible to specify single agents.  Accepted classification values are EP, ERRP and IP

4.6

Path to identify the C4 in DSD response is incorrect; should be "Publisher" instead of "EvidenceProvider"

2023-05-23

4.8.1

4.10.5.2

Cardinality of Jurisdiction in reference framework type was changed from  0..1 to 0..n in the XSD. It was not possible to indicate multiple Jurisdictions for a single reference Framework in the EB query responses on the level of the XSD even though it was defined by the TDDs. The element had a wrong cardinality in the XSD. 

GIT (SDG-GenericMetadataProfile-v1.0.0.xsd)

API Doc updated

Changed Business Rules description and Schematrons on Agent/Classification in the Request, Response and Error Response. 

The requestID and rim:slot "EvidenceRequester" MAY be present in the Error Response

Updated schematron rules where just a uuid must be present so that no other characters(urn:uuid) are are allowed. 

Fixed rules containing "no other than" 

Updated cardinalities of Procedure, Requirement slots in Evidence Request

Correction

Correction (Breaking change)

3.2.4

GIT (R-EB-REQ-S017) 

Expanded evidence preview from (just) a service to a process to better describe the various steps, in text and Archimate diagram.

1.3.3

1.3.3

1.3.4

Clarifications on context, reuse of eIDAS

2.1.1.

2.1.3.2.

2.1.4.

2.

2.1.1.

2.1.2.1.

2.1.2.4.

2.1.2.5.

2.1.3.1.

2.1.4.

2.1.3.2.

Update reference to relying party requesting authentication to reflect previous restructure of the chapter.

2.1.2.4.

2.1.2.3.

3.4.3.

3.4.4.

3.1.4

3.1.5

3.1.3, 3.1.4, 3.1.5

Update query definition and specifications. Inclusion of codelists links, inclusion of sample flows, correction of examples.

Put a note on encoding to query parameter evidencetypeclassification of the DSD (4.2.2. Parameter Details) and requirement-id of the EB and Update of corresponding API DOC

Adding query parameter description for EvidenceProviderClassification

3.1.4 - 4.1 (DSD)

3.2.4 - 4.3 (EB)

3.2.4 - 4.2 (EB)

3.2.3 (EB), 3.2.4 (EB), 3.1.3 (DSD), 3.1.4 (DSD)

3.2.4 (EB), 3.1.4 (DSD)

3.6 

Adding the default value urn:cef.eu:names:identifier:EAS  to @type in section 2.3 Static Routing Metadata of the 4.7 eDelivery configuration.

Documented that OOTS will (initially) use the current version 1.15 of eDelivery AS4 common profile and four corner profile enhancement.

Added a Payload Profile section that

• describes the structure of an OOTS evidence exchange message.
• adds the size restrictions agreed in the TDD sub-group meeting of 2023-03-09. 
• recommends limitation to OOTS media types. 

5.2

5.3

5.4

Updated cardinality of StringValue, DateValue, BooleanValue in SupportedValue in SDG-GenericMetadataProfile.xsd from 0..1 to 0..n . 

Updated cardinality of Jurisdiction relation to Evidence Type from 0..1 to 0..n in in SDG-GenericMetadataProfile-.xsd.

Updated cardinality of RelatedTo relation to ReferenceFramework from 0..1 to 0..n in in SDG-GenericMetadataProfile.xsd.

Change of OOTS XSD and OOTS Driver from version 0.99 (snapshot) to version 1.0.0

Bugfix DSD-SUB-S.sch and EB-SUB-S.sch.

Changed the use of default value of ConformsTo from oots:edm-v1.0 to oots-edm:v1.0 oots-edm:v1.0. 

Directory OOTS-EDM/xml

Directory OOTS-EDM/sch

Correction

Updated language "en" to "EN"

Replaced "rim:slot" with "rim:Slot"

Replaced code "EDM:ERR:0001" with "EDM:ERR:0002"  in R-EDM-ERR-C015

Removed rules already covered by XSD validation

Removed rules related to Gender

Changed the use of default value of ConformsTo from oots:edm-v1.0 to oots-edm:v1.0 oots-edm:v1.0

• Clarification on the eID notified requirement on Evidence Requester side and the cases in which re-authentication is needed on the side of the Data Service.
• Explanation to reflect the restructuring of the entire chapter.

• Clarification on the cross-border eIDAS flow
• Changed the picture with the attributes to clarify the additional attributes
• Clarification regarding the “available sector specific attributes”

• Clarification on when the use of notified eIDAS eID scheme is a mandatory requirement
• Clarification for the case when the eIDAS notified eID scheme is issued by the Member State of the Online Procedure Portal

3.2

3.3

Use of rim:RegistryObject for associations instead of rim:Classification in LCM examples of the EB and DSD

Also fixed definition of sourceObject and targetObject

3.2.5.3

3.2.5.4.2

3.2.4.2.2

3.2.4.3.2

Following review by the Security sub-group, a new separate section is added on network and transport layer security. 

• Introduces DNSSEC
• Further elaboration on TLS, content derived from draft future eDelivery AS4 specification. 

3.1.4.7

3.2.4.6

3.1.4.6

3.2.4.5

3.1.4

3.1.5

3.2.4

3.2.5

3.6

In eDelivery configuration, added a reference to the new 3.7

Also added a note on Certification Authorities for eDelivery (response to a comment of the security sub-group)

4.5

4.6

Changed the bibliographic entry of the Implementing Regulation now that it is published

Fix heading numbering in section on identity and record matching

4.5.2

4.5.3

4.3

4.5.1