Chapter 3

Adjusted cardinatliy of RegistryObjects in EB Query Responses towards behavior of CS

The cardinality of the RegistryObject in the "4.3. Get Evidence Types for Requirement Query" has been changed from 1..n to 1..1 because exactely one RegistryObject or an Query Error Response will be returned by the CS. 

3.2.4 (4.3) 

SR data model documentation updates in relation to version 1.2.0

Updated the SR data model specifications to account for the extensions made to enable the representation of asset relations and of the transactions an asset may be associated with; in addition, new controlled vocabularies were added to capture relevant code values. 

Asset metadata examples (in XML) were added to illustrate the description of asset relations in practice; updates were also made to improve the asset metadata examples showcasing the description of version history information.

3.3.5 (3.3) Data model

3.3.5.1 (3.3) Controlled vocabularies

3.3.5.2 (3.3) Asset versioning 

3.3.5.3 (3.3) Asset relations 

Clarification of the value of NAPTR records

The value follows the pattern .*!"<URI>"!  so it does not use the full regular expression syntax.

3.4.3

Chapter 4

Evidence Exchange

Incorrect error code in comment

Update Typo in example 4.5.4 - OOTS-EDM XML Examples of the Evidence Exchange, 3.2 Step 2: Error Response. A comment referred to EDM:ERR:0001 instead of EDM:ERR:0002. The example was correct.

4.5.4 (3.2) Step 2: Error Response

Refine description about the use of ConversationId. Queries that are made at later times due to unavailability use a new ConversationId (Late Response). 

4.7 and 4.7.1

Improved the section on the preview service to explain the interplay of PossibilityForPreview, re-authentication, matching, identity swap checking 

4.9

In the diagram in section 4.5.1 for Person, the given name was missing and it was added.

4.5.1

Related Artifacts

Incorrect error code in business rule description

The business rule description refered to EDM:ERR:0001 instead of EDM:ERR:0002. The schematron was correct.

Created version 105 of Business Rules and updated typo in rules R-EDM-ERR-C015 and R-EDM-ERR-C022.

a008d9f9

d3dd0f0d

c87ded2c

6e4e2987

New SR metadata structure 

Inclusion of processing instructions to XML Examples and (cross message validation) Schematrons that carry relevant SR metadata

42aad509

22cf2717

712dc2d1

886c13e9

Creation of additonal XML Examples for EMREX

Created DSD and EB Response Examples for EMREX and usage Scenario NL and RO

Rework of existing EMREX Examples and inclusion of new EMREX Examples for the EB and DSD based on CS query results

fd718ec7

6f06b008

71d87e7a

In LCM some rules were missing that prevented the use of the undefined associations types

153cd236

Updated README file for schematron files

67ad639d

7c956270

Improved handling of conditional ("If present") cross-validation 

Check and update all rules in Cross-validation starting with "If present, ". If both compared elements are absent no error is retrieved.

Fixed some cross-validation rules in EDM-REQ_EDM-RESP.sch

5d811945

5cfdb015

Adding role for cross-message validation rules where it was missing

Updated Cross-Message Validation Business Rules excel file by adding role for rules where it was missing

Check the presence of role=FATAL/WARNING in cross-validation schematrons and XLSX

64d77766

9d4b834a

Adjusted cardinality of RegistryObjects in EB Query Responses towards behavior of CS

Included the following Rules and Schematrons to test the cardinality of RegistryObjects in EB Query Responses: R-EB-REQ-S024, R-EB-EVI-S024

Added regression test samples for R-EB-EVI-S024-01 and R-EB-REQ-S024-01

bf60ecf1

34f2fb52

Validation of values with spaces

Restrict  to exact match Cross-Message Validation of values and improving error messages for all Schematron rules. E.g. empty spaces in one element but not in the other will return an error now

52c195d4

New informative annexes for "Operational Perspectives"

Moved cross-sectional contents into new location "Annexes Operational Perspectives": A.1 Cross-Message Validation Framwork, A.2 Deployment Configuration data for OOTS, A.3 Regression Testing Tool, A.4 TDD Versioning Methodology, A.5 Interconnectivity to Education Domain using EMREX

Operational Perspectives (Annexes of the OOTS Technical Design Documents)

EMREX interconnectivity guidelines

Adding new contents about "A.5 Interconnectivity to Education Domain using EMREX" to Annexes Operational Perspectives section. The section summarizes the concepts, solutions and operational agreements upon the use of EMREX such as the Legal Base, Flows, EMREX bridge, Common Service Registration, Configuration of EMREX Bridge

Annexes Operational Perspectives (A.4 Interconnectivity to Education Domain using EMREX)

Allow ebMS header validation at any level 

The context of the rules is adapted so that they apply to standalone eb:Messaging structures or to ebMS3 SOAP envelopes

7efb8b23

Consistent use of collectionType

Add schematron rules to test the use of collectionType “urn:oasis:names:tc:ebxml-regrep:CollectionType:Set” and updated  examples and regression tests to ensure that all slots of collectionValueType use the collectionType

32000683

e640ac2c

Consolidated and Updated Business Rules EXCEL 

a966ead5

c167c244

Correction of validaton for ER and EP classification

Some rules in schematrons in EDM-REQ_EDM-ERR, EDM-REQ_EDM-RESP, ebMS_EDM-RESP, ebMS_EDM-REQ did not check Classification values ER or EP correctly. Schematrons and Regression Tests were updated

480dd0dd

Minor updates and new version of Cross-Message Validation Business Rules file

3ea32b9a

378b2ef5

Deleted Rule R-EDM-REQ_EDM-RESP-06 because "Gender" is not present in Evidence Response so it cannot be tested.

afc24dfa

Changing rules R-EB-EVI_DSD-RESP-001 and R-EB-EVI_DSD-ERR005-001 to check only for one EvidenceTypeClassification of the EB response that must be present in the DSD response

c070fe84

Cross-validation fix issues with checking all elements in one RegistryObject in EDM-REQ_EDM-RESP. For example RegistryObject 1 has correct NaturalPerson and wrong distribution format and for RegistryObject 2 has correct distribution format and wrong NaturalPerson and message was considered valid by the existing rule.

7a707c04

Moved rules that checked EB and DSD 'AssociationType' type from content schematrons to structure schematron and created a new structure rule for LCM combined EB and DSD

f397e510

58455a42

SR XSD and related examples updated

410531bf

Chapter 3 

Common Services

Added new search method and updated links to new XSD and XML samples.

Updated getAssetMetdata method response format.

3.3.3 SR Functonality

Chapter 3 

Common Services

Added contents to describe the extensions made for version 1.1.0 of the SR data model to cover the versioning of assets.

Added contents that describe the controlled vocabularies used in the SR data model.

Added contents that describe how to use the SR data model to describe the version history of an asset. 

3.5.3 (3.5) Data model

3.5.3.1 (3.5) Controlled vocabularies

3.5.3.2 (3.5) Asset versioning 

Chapter 3

Common Services

Adding contents that describe Combined Regrep LCM Submission of DSD and EB artifacts

A combined RegRep LCM Submission of DSD and EB artifacts has been introduced as another allowed SubmitObjectsRequest message and method how to update the CS. Corresponding specification and business rules have been added

New Business Rule Set for combined LCM Submission: LCM-SUB-S

3.6.3 (3.5) Specification

3.6.3 (3.7) Business Rules

Adding information about Semantic repository Search API Error Response Codes

3.5

Related Artifacts

Update Business Rules for Cross-Message Validation Framework

2baa01c5

Fix issues with Cross-Message Validation Framework DSD-RESP_EDM-REQ rules which return error even when conformsTo, Transformation, Format are missing from both samples

49c4862d

Update EB-EVI_EDM-REQ cross validation xml sample and schematron on Requirement/Requirements

2baa01c5

Add EvidenceTypeList as source object of AssociationType:FulfillsRequirement rule and testing snippets

697f381f

Updated Version information for schematron files

65ae0433, 7e379791, cc6b47ae 

Fixed Cross-Message Validation Framework DSD-ERR_DSD-RESP-02 schematron rule returning error even when value was absent from both samples

779f1693

Reformatted Business Rules Excel Spreadsheet and Inclusion of SR Error Code List to Codelist Excel Spreadsheet

36c6d000

New XML sample for combined LCM Submission: LCM-SUB-S

1dd07b11

Combined EB and DSD LCM Regression testing integration

9afb0d15

Code list for Semantic Repository error messages using RegRep syntax. Name: SRSearchErrorCodes

0ae5679f

Business rules and Schematron rules for XML object submission documents that combine EB and DSD content

New Schematron for combined LCM Submission: LCM-SUB-S

76a80abe

Added snippets for presence of SlotValue

a600b8c2

Corrected Schematron rule for cardinality of Agent of type EP 

Afftecte Business Rule: R-EDM-RESP-C046

a405090d

 Schematron XSD Restriction Rule for IsAbout NP and LP

Previous rule set did not contain any rule to prove that only minimium data set is used for Natural Person and Legal Person in the element IsAbout of the Evidence Respone as defined by the specifications: Affected Business Rules: R-EDM-RESP-S041 and R-EDM-RESP-S042

40537af3

Added rules enforcing presence of a rim:SlotValue under rim:Slot with element content

Affected Business Rule Sets: EB-SUB-S, DSD-ERR-S, DSD-RESP-S, DSD-SUB-S, DSD-SUB_RF-S, EB-EVI-S, EB-REQ-S, EB-SUB-S, EDM-ERR-S

5c1f8b32

38188573

Updated Schematron Rule R-EDM-REQ-C003 which didn't supported the test procedure '00' appropriately

cfda6ffb

Updated Schematron Rule R-EB-EVI_EDM-REQ-01 which had a missing 's' in Slot name=Requirements for Evidence Request

3096ed9a

Related Artifacts

Fixed cross-validation ebMS_EDM-RESP schematron rule 05 and added new snippets for testing

841c559c

Changing severity of role to CAUTION for rule checking attributes on eb:Messaging

932a09b2

Related Artifacts

Update the asset list and version information in Schematron.

6cc6a42d

a67220cf

e1afcfd0

Improve the rules for the cross-validation rules of the two requests for empty elements and elements with attributes.

Improve the for the cross-validation rules of EDM request and EDM response for situations in which the response has an empty registry object list.

In the previous patch the codelists for AgentClassification and Procedures were changed but the version number was not incremented. Now both codelists are published under version 2024-02

a41b3694

Chapter 4

Evidence Exchange

Removal of "DataServiceEvidenceType/note" element from Evidence Request examples. Element is used only in DSD DataServiceEvidenceType

Correction of attribute of SpecificationIdentifier in EDM: QueryResponseError. The graphic contained an attribute named requestID: Identifier which has been changed to rim:SlotValue: StringValueType. 

Added implementation comments to all ebMS header examples based on business rules and ebMS Message Header Implementation Guide

The start and end date of validity period contained the following text. "...must have granularity of seconds, and include time zone information." the text was changed to "...MUST be according to xsd:date." as the data type is defined as xsd:date only and not as xsd:datetime. 

Fix DSD schematron rules related OOTSMediaTypes and the presence of conformsTo if structured and unstructured format is available: "In case a structured sdg:format  shall be used without an apporiate OOTS data model, there MUST be an an alternative sdg:DistributedAs element for the same sdg:DataServiceEvidenceType  which uses an unstructured sdg:format like jpeg, jpg, png, svg or pdf."

Affects rules:

• R-DSD-RESP-C039
  R-DSD-RESP-C041
  R-DSD-SUB-C038
  R-DSD-SUB-C040
  R-DSD-SUB-C007
  R-DSD-SUB_RF-C038
  R-DSD-SUB_RF-C040
  R-DSD-SUB_RF-C007
  R-EDM-REQ-C033
  

Fix Schematron rules R-EDM-ERR-C008 and R-EDM-ERR-C013

• R-EDM-ERR-C013: relax rules with regard to the use prefix for namespace in exception type
• R-EDM-ERR-C008: added space between values IP and EP to be checked

f2a0bc24

6d992dde

f7aba5cb

b1f64b8e

0f287b1a

A.1 Cross-Message Validation Framework

In the procedure codelists, the following text for procedure R1 (English): "Requesting a birth certificate" was changed to the official name "Requesting proof of registration of birth".

Additionally, a correction of a typo was done for T1 in Finnish translation. 

Improved rule R-EDM-ERR-C025 in business rule sheet and Schematron to test for correct use of ExceptionType if requestID is missing

a1bc3926 

ed12df1a

Fixed Schematron rule to check all rim:Elements in the Slot that have an Agent with that Classification.   Not the number of Agents in a single rim:Element.

Regenerated all filtered Schematrons, compiled XSLTs and HTML rendered business rules

Chapter 1

High Level Architecture

No changes in this chapter

Chapter 2

User identification and authentication

Remove the disclaimer

As the PowerOfRepresentationScope attribute is now approved for publication, the disclaimer that this approval was still in progress is removed. 

Chapter 3

Common Services

Corrected severity attribute description

Updated severity attribute description in 4.4.3.2 Implementation Guideline of 3.1.4 Query Interface Specification of the DSD

MUST  be 'urn:sr.oots.tech.ec.europa.eu:codes:ErrorSeverity:DSDErrorResponse:AdditionalInput' if the rs:Exception DSD:ERR:0005 is used and not urn:oasis:names:tc:ebxml-regrep:ErrorSeverityType:Error

Allow ECDSA for DSD content signature

As an alternative to EdDSA, a DSD server is allowed to sign using ECDSA. This is because support for ECDSA is more common among Certification Authorities.

Allow ECDSA for EB content signature

As an alternative to EdDSA, an EB server is allowed to sign using ECDSA. This is because support for ECDSA is more common among Certification Authorities.

Corrected a typo

Some rules in 3.6 were referenced with LBM. Change to LCM

Clean up

Removed the provisional specification text for non-public access in the CS query logging section 

3.7.4

3.8.2

Missing element to log

The client IP address was omitted in the list of items to log in the CS admin logging section. (It was already present in the CS lookup section).

New distribution of OOTS external and internal codelist version 2023-11 (xlsx and gc)

• Adding AlternateFormatLocationURI to reference to SR 
• Changing LocationURI to reference to git source files
• Changing Version and CanonicalVersionURI
• Changing names and removing empty spaces in "Id" and "lang" definitions of LAU codelist
• Metadata of CountryIdentificationCode was changed and the list was published as internal list due to the customizations done in the last snapshot
• Metadata of NUTS was changed and the list was created on the basis of 2024 Eurostat data as internal list due to customizations with regard to non-EEA countries and deprecated values that were present in the current external list
• New list for EEA_country codes to be used for type/schemeID, EvidenceType, eIDAS, Jurisdiction

New distribution of External codelists

• EAS (2023-11-15)
• CountryIdentificationCode and NUTS was removed from External list to OOTS specific list due to the customization done

Changed rules for the use of unregistered schemes in 'schemeID' attribute of the 'Identifier' of 'sdg:AccessService' and 'sdg:Publishers'.

For unregistered addressing schemes it is now mandatory to include a 'EEA_Country' postfix to 'urn:oasis:names:tc:ebcore:partyid-type:unregistered:[Code]' in order to avoid clashes of IDs between MS. MS are then responsible to ensure that within MS there are no duplicate IDs in use. Preference is to use or register specific MS schemes in EAS. The additional value 'oots' was added for testing purposes. Rules affected are: R-DSD-SUB_RF-C022, R-DSD-SUB_RF-C025, R-DSD-SUB-C022, R-DSD-SUB-C025, R-DSD-RESP-C014, R-DSD-RESP-C017

New rule: The value of the 'schemeID' attribute of the 'Identifier' MUST not extend 256 characters and it either, MUST use the prefix 'urn:cef.eu:names:identifier:EAS:[Code]' and a code being part of the code list 'EAS' (Electronic Address Scheme ) OR it MUST use the prefix 'urn:oasis:names:tc:ebcore:partyid-type:unregistered:[Code]' and a code being part of the code list ‘EEA_Country-CodeList’.

Correction that AdminUnitLevel1 is mandatory element for the Address of a Publisher

The Address and its AdminUnitLevel1 are mandatory components of the Publisher according to the XSD but the TDDs did not reflect that for the CS. The element AdminUnitLevel1 has been corrected to be a mandatory element.

eDelivery Configuration for the LCM

Detailing the subsection of the 3.6 eDelivery Configuration for the LifeCycleManagement of the section 3.6 Common Services API Specification. Clarified the use of C1, C2, C3 and C4 including type attributes and basic rules for the ebMS header of LCM. Reintroduced the use of C1/C4 if CS is addressed. 

In all components that relate to Jurisdiction/AdminUnitL1 and EvidenceTypeClassification the use of country codes is restricted to ‘EEA_Country-CodeList’. The additional value 'oots' was added for EvidenceTypeClassification for testing purposes and agreed OOTS data models. 

Clarification on the use of language code elements

Previous version contained references for language elements like "MUST be part of the code list 'LanguageCode' (ISO 639-1 two-letter code).  Default value "en". The codelist 'LanguageCode', however, uses capital letter and combines both, ISO 639-2 Code and ISO 639-1 Code, and both values are allowed.  Thus, description was changed to 'MUST be part of the code list 'LanguageCode'.  Default value "EN"

3.1.1 (3.1.4/3.1.5/3.1.6/3.1.7)

3.2.1 (3.2.4/3.2.5/3.2.6)

Chapter 4

Evidence Exchange

Return URL not appended to URL in PreviewLocation slot

The return URL is only exchanged in the user redirect HTTP request. The Preview URL slot in the second request is an exact copy of the URL exchanged in the exception response,

Typo in reference to slot "Requirements"

The slot name in evidence exchange is "Requirements". In  two places it was incorrectly referred to as the "Requirement" slot (without "s"). 

Clarification on length limit of RIM string datatypes

Clarified that the length of the RIM StringValueType is 256 characters and of the value of InternationalStringValueType is 1024. This needs to be taken into account when generating the preview link URL.

4.5.1.2

4.5.3

Single certificate for signing and encryption

Document that in this version of OOTS, an Access Point uses a single RSA certificate for both signing and encryption. This reflects a limitation of used eDelivery AS4 software implementations.

Sender signature certificate is statically configured

In the list of statically configured parameters of the sending Access Point, the sender signing certificate was missing. (It was specified for the receiver Access Point) 

Removed an out-of-place sentence

Section 4.8.3.1. is about the evidence request, but there was a sentence on the evidence response.

Evidence content information to be logged

In the section on logging of non-repudiation information, we required the content of the evidence to be stored (or to allow reconstruction of the evidence as it was sent). This is too strong and not aligned with the IR.  It is now stated more generally as requiring information (timestamps, identifiers) that allow linking the OOTS logging to the source and destination systems.. 

Removed section 4.8.7. as it was a speculative reference to a potential future interoperable log system interchange format, not a specification to be implemented.

With respect to interchange formats there are no obvious solutions. Several components for OOTS are existing, reused components. The type of events that are logged, the log level at which they are recorded, the data that is logged per event, and the formats in which this logging is done,  are not harmonized. Unstructured or semi-structured log formats are hard or unsuited to transform into formats that can be understood in other contexts. Logging is typically designed for internal use only so there is no clear distinction between what can and what cannot be shared with (even trusted) counterparties, requiring and further complicating filtering. Due to components being provided by third parties (custom, open source or commercial) with their own roadmaps, budget cycles etc. in practice this state of affairs is hard to change. The most realistic approach regarding harmonization seems to be more about metadata (e.g. ways to label log data as being related to particular search parameters) than the actual log format. 

Return URL not appended to URL in PreviewLocation slot

The return URL is only exchanged in the user redirect HTTP request. The Preview URL slot in the second request is an exact copy of the URL exchanged in the exception response,

Corrected specification of the encoding of the preview URL

The wording of 4.9.4. seemed to require preview URLs in evidence errors to be URI encoded. This is only needed in REST API requests. In XML we need encoding of some characters using character references.

No known implementations used the URI encoding,  nor do samples, business rules and Schematrons. So this aligns the specification with the current implementations.

Corrected:

• To be able to safely transmit the query component, both when used as HTTP URI in queries and when transported in an evidence error response XML message, unsafe characters shall be quoted.  For example, the string  https:// is to be quoted as https%3A%2F%2F.    

To:

• To be  able to safely transmit the preview URL in the XML error response, unsafe characters need to be encoded using XML encoding. For example, a preview URL for use with the GET method could include multiple parameters and their values, and therefore include the & character. This character shall be encoded using a &amp;  character reference.
• To be able to safely transmit in REST queries a query component that includes a return URL as value for the returnurl parameter, unsafe characters shall be plus quote-encoded.  For example, the substring https:// is to be quoted as https%3A%2F%2F.  

In R-EDM-ebMS-026, the context eb:PartyInfo/@href was used and it was corrected to eb:PartInfo/@href. 

Changed rules for the use of unregistered schemes in

• 'schemeID' attribute of the 'Identifier' of 'sdg:Agent' in the EDM
• 'type' attribute of 'eb:Party' and 'eb:Property' in ebMS

For unregistered addressing schemes it is now mandatory to include a 'EEA_Country' postfix to 'urn:oasis:names:tc:ebcore:partyid-type:unregistered:[Code]' in order to avoid clashes of IDs between MS. MS are then responsible to ensure that within MS there are no duplicate IDs in use. Preference is to use or register specific MS schemes in EAS. The additional value 'oots' was added for testing purposes. Rules affected are: R-EDM-ebMS-006,R-EDM-ebMS-010, R-EDM-REQ-C012, R-EDM-REQ-C018, R-EDM-RESP-C007, R-EDM-RESP-C013, R-EDM-RESP-C039, R-EDM-ERR-C004, R-EDM-ERR-C010

New rule: The value of the 'schemeID' attribute of the 'Identifier' (or for ebMS  'eb:PartyId/@type' or  'eb:Property/@type') MUST not extend 256 characters and it either, MUST use the prefix 'urn:cef.eu:names:identifier:EAS:[Code]' and a code being part of the code list 'EAS' (Electronic Address Scheme ) OR it MUST use the prefix 'urn:oasis:names:tc:ebcore:partyid-type:unregistered:[Code]' and a code being part of the code list ‘EEA_Country-CodeList’. 

Restricting eIDAS country codes to EEA country codes

In all components that relate to eIDAS Identifiers and EvidenceTypeClassification the use of country codes is restricted to ‘EEA_Country-CodeList’. The additional value 'oots' was added for EvidenceTypeClassification for testing purposes and agreed OOTS data models. 

Clarification on the use of language code elements

Previous version contained references for language elements like "MUST be part of the code list 'LanguageCode' (ISO 639-1 two-letter code).  Default value "en". The codelist 'LanguageCode', however, uses capital letter and combines both, ISO 639-2 Code and ISO 639-1 Code, and both value are allowed.  Thus, description was changed to 'MUST be part of the code list 'LanguageCode'.  Default value "EN"

Removal of timezone information from 'DateOfBirth'

For 'DateOfBirth element the following rule was adopted from SAML attribute profile 'MUST use the following format YYYY + “-“ + MM + “-“ + DD' (as defined for XSD date)'. However, eIDAS and the value do/should not provide/accept timezone information for 'DateOfBirth'. Thus, the description was changed to 'MUST use the following format YYYY + “-“ + MM + “-“ + DD'. The Business Rules were changed accordingly. 

Chapter 5

Data models

Updated the methodology section to reflect the current approach of the data models subgroup

Chapter 6

UX guidance and UX recommendations

No changes in this chapter

Fixes and improvements for Schematron files: 

• OOTS-EDM/sch/EDM-ebMS.sch
• OOTS-EDM/sch/EDM-RESP-S.sch
• OOTS-EDM/sch/DSD-SUB-S.sch
• OOTS-EDM/sch/DSD-ERR-S.sch
• OOTS-EDM/sch/DSD-SUB_RF-S.sch
• OOTS-EDM/sch/EB-SUB-S.sch
• OOTS-EDM/sch/EB-REQ-S.sch
• OOTS-EDM/sch/EB-EVI-S.sch
• OOTS-EDM/sch/LCM-ERR.sch

 The Regression Test Suite was improved to separate errors and warnings.

LCM tests and snippets were added to the Regression Test Suite,

Added "CompressionType">application/gzip to examples where missing

Removed the three letter country codes from eIDAS related artifacts

Corrected rules 030, 033 and 035 in R-EDM-ebMS.sch about the PayloadInfo in the ebMS header and added a few more snippets.

Corrected (and greatly simplified) rule R-EDM-ERR-C-019 EDM-R-C.sch that verified the format for the preview link. Now it just checks that it uses the HTTPS protocol. Updated the related snippets.

Draft XSD for  PowerOfRepresentationScopeType 

• The MS-specific part of an eIDAS identifier can be up to 256 characters. It cannot be whitespace, but otherwise any character.
• Added the PUT method to rules checking the method.

New distribution of OOTS internal codelist version 2023-11 (xlsx and gc)

• Adding AlternateFormatLocationURI to reference to SR 
• Changing LocationURI to reference to git source files
• Changing Version and CanonicalVersionURI
• Changing names and removing empty spaces in "Id" and "lang" definitions of LAU codelist
• Metadata of CountryIdentificationCode was changed and the list was published as internal list due to the customizations done in the last snapshot
• Metadata of NUTS was changed and the list was created on the basis of 2024 Eurostat data as internal list due to customizations with regard to non-EEA countries and deprecated values that were present in the current external list
• EEA_Country-CodeList was developed as a subset of EEA countries from  CountryIdentificationCode-CodeList.gc

New distribution of External codelists

• EAS (2023-11-15)
• CountryIdentificationCode and NUTS was removed from External list to OOTS specific list due to the customization done

Updated codelist metadata

Due to the new distribution of the OOTS internal codelist version 2023-11, the business rule xlsx, listing the rules with associated codelist, has been changed to the new metadata of the codelists

Correction on rule  R-EDM-ebMS-026

This rule is about the href attribute in PartInfo, not PartyInfo.

Corrected rule R-EDM-REQ-S018 EDM-REQ-S.sch

This rule checked rim:Slot name="AuthorizedRepresentative" within query:QueryRequest may be present. Now it does this check within the path query:QueryRequest/query:Query.

Updated rule with unregistered pattern

ebMS: R-EDM-ebMS-006, R-EDM-ebMS-010, R-EDM-ebMS-021,

EDM: R-EDM-REQ-C012, R-EDM-REQ-C018, R-EDM-RESP-C007, R-EDM-RESP-C013, R-EDM-RESP-C039, R-EDM-ERR-C004, R-EDM-ERR-C010

DSD: R-DSD-SUB_RF-C022, R-DSD-SUB_RF-C025, R-DSD-SUB-C022, R-DSD-SUB-C025, R-DSD-RESP-C014, R-DSD-RESP-C017 

Adapted Schematron rules for EEA country code and support for the added  "oots" option under the ebCore unregistered branch

R-EDM-ebMS-006, R-EDM-ebMS-010, R-EDM-ebMS-021, R-EDM-REQ-C012, R-EDM-REQ-C018, R-EDM-REQ-C027, R-EDM-REQ-C040, R-EDM-REQ-C051, R-EDM-REQ-C061, R-EDM-RESP-C007, R-EDM-RESP-C013, R-EDM-RESP-C017, R-EDM-RESP-C028, R-EDM-RESP-C035, R-EDM-RESP-C039, R-EDM-ERR-C004, R-EDM-ERR-C010, R-DSD-RESP-C003, R-DSD-RESP-C014, R-DSD-RESP-C017, R-DSD-RESP-C020, R-DSD-ERR-C011, R-DSD-SUB-C002, R-DSD-SUB-C022, R-DSD-SUB-C025, R-DSD-SUB-C028, R-DSD-SUB_RF-C002, R-DSD-SUB_RF-C022, R-DSD-SUB_RF-C025

In DSD-RESP-C.sch rule R-DSD-RESP-S016 was updated to "A successful QueryResponse MUST include minimum a 'rim:RegistryObject'."

Changing descriptions of language code elements in schematrons

Previous version contained references for language elements like "MUST be part of the code list 'LanguageCode' (ISO 639-1 two-letter code).  Default value "en". The codelist 'LanguageCode', however, uses capital letter and combines both, ISO 639-2 Code and ISO 639-1 Code, and both value types are allowed.  Thus, description was changed to 'MUST be part of the code list 'LanguageCode'.  Default value "EN"

Removal of timezone information from 'DateOfBirth' in schematron 

For 'DateOfBirth element the following rule was adopted from SAML attribute profile 'MUST use the following format YYYY + “-“ + MM + “-“ + DD' (as defined for XSD date)'. However, eIDAS and the value do/should not provide/accept timezone information for 'DateOfBirth'. Thus, the description and schematron was changed to 'MUST use the following format YYYY + “-“ + MM + “-“ + DD'. The Business Rules were changed accordingly. 

Improved and regenerated the HTML versions of the Business Rules

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 snapshot 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 snapshot 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