The wiki page List of TDD assets and their version provide a list of all versioned assets of theTechnical Design Documents (TDD)and their version in the different TDD releases.
Change log for
Note: The patch is fully backwards compatible. It will just allowto declare other EDM versions than 1.0.5 in the DSD response. The change was only adapted in the following git schematron filesDSD-RESP andDSD-SUB_RF and R-DSD-SUB-C023. No other changes implemented in the corresponding specifications and artifacts.
Chapter / Location
Area / kind of change
Comments
Location (Chapter, Section)
Date of change
Related Artifacts
Correction
Relax rules R-DSD-RESP-C015 and R-DSD-SUB_RF-C023
CS 1.0.5 is not aware of EDM 1.2.0 entries in ConformsTo statement of Access Services. This was a development that was not foreseen when the 1.0.5 rules were created.
The patch 1.0.6 will make that rule flexible and to allow oots-edm:v1.2 and other versions in sdg:AccessService/ sdg:ConformsTo
The value of 'ConformsTo' of the Access Service MUST point to the underlying eDelivery Profile 'oots-edm:<MAJOR>: <MINOR>'.
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)
New content
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
Editorial
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
Editorial
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
Editorial
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
New content
Improved the section on the preview service to explain the interplay of PossibilityForPreview, re-authentication, matching, identity swap checking
4.9
Correction
In the diagram in section 4.5.1 for Person, the given name was missing and it was added.
4.5.1
Related Artifacts
Editorial
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.
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
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)
Editorial
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)
Correction
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
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
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
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
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.
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
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
New content
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
New content
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
New content
Adding information about Semantic repository Search API Error Response Codes
3.5
Related Artifacts
Update
Update Business Rules for Cross-Message Validation Framework
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
Schematron XSD Restriction Rule for IsAbout NP and LP
Previous rule set did not contain any rule to prove that onlyminimiumdata set is used forNatural Person and Legal Person in the elementIsAboutof the EvidenceResponeasdefined by the specifications: Affected Business Rules: R-EDM-RESP-S041 and R-EDM-RESP-S042
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
Removal of "DataServiceEvidenceType/note" element from Evidence Request examples. Element is used only in DSD DataServiceEvidenceType
4.5.4
Correction
Correction of attribute of SpecificationIdentifier in EDM: QueryResponseError. The graphic contained an attribute named requestID: Identifier which has been changed to rim:SlotValue: StringValueType.
4.5.3 (sec. 1)
Editorial
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."
SCH missing the '^' to test the beginning of a pattern upfront (urn:uuid) to assert the id format correctly, if some value is put upfront, e.g. id="INVALIDurn:uuid:35c299d8-9383-47ce-ad8c-0ed70ea52827
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.
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.
As the PowerOfRepresentationScope attribute is now approved for publication, the disclaimer that this approval was still in progress is removed.
2.3
Chapter 3
Common Services
Correction
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
3.1.4 (4.4.3.2)
New content
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.
3.1.4.4.6
New content
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.
3.2.4.4.5
New content
Update of the Semantic Repository chapter
Add new requirements and sections, as well as update the SR structure diagram to provide more insights of the SR futures, data structure and asset families that will be hosted in it.
3.3
Editorial
Corrected a typo
Some rules in 3.6 were referenced with LBM. Change to LCM
3.6
Editorial
Clean up
Removed the provisional specification text for non-public access in the CS query logging section
3.7.4
3.8.2
Correction
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).
3.8.4
Breaking Change (Codelists)
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
3.5
Breaking change (Addressing Schemes)
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’.
3.1.1 (3.1.4/3.1.5/3.1.6/3.1.7)
Correction
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.
3.1.1 (3.1.4/3.1.5/3.1.6/3.1.7)
Editorial
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.
3.6 (3.6)
Correction
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.
3.1.1 , 3.2.1
Correction
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
Clarification
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,
4.5.1.2
Editorial
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").
4.5.1.2
Clarification
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
Clarification
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.
4.7.2.3.
Clarification
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)
4.7.2.3.
Correction
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.
4.8.3.1
Correction
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..
4.8.3.2
Editorial
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.
4.8.7
Clarification
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,
4.9.1, 4.9.2, 4.9.5
Correction
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 ashttps%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 & 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 beplusquote-encoded. For example, the substring https:// is to be quoted as https%3A%2F%2F.
4.9.4
Correction
In R-EDM-ebMS-026, the context eb:PartyInfo/@href was used and it was corrected to eb:PartInfo/@href.
4.7.1 and 4.7.2
Breaking change (Addressing Schemes)
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’.
4.5.1, 4.5.2, 4.5.3, 4.6, 4.7., 4.7.1 and 4.7.2
Correction
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.
4.5, 4.6
Correction
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"
4.5.1, 4.5.2, 4.5.3, 4.5.4, 4.6
Correction
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.
4.5.1, 4.5.2, 4.5.4, 4.6
Chapter 5
Data models
New content
Updated the methodology section to reflect the current approach of the data models subgroup
5.1
Chapter 6
UX guidance and UX recommendations
None
No changes in this chapter
Related Artifacts
Corrections
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.
September
New content
LCM tests and snippets were added to the Regression Test Suite,
September
Correction
Added "CompressionType">application/gzip to examples where missing
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.
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
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
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.
Renamed file name of Codelists/OOTS/CountryIdentificationCode-Codelist.gc into CountryIdentificationCode-CodeList.gc and changed links in TDD and API documents
GIT
New content
Adapted Schematron rules for EEA country code and support for the added "oots" option under the ebCore unregistered branch
A new rule R-DSD-ERR-S024 was added in schematron file DSD-ERR-S.sch stating that "A rim:SlotValue of type CollectionValueType MUST have child rim:Element content"
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.
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.
1.8.6
User identification and authentication
Correction
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
Correction
Reference to Intermediary Platforms where Online Procedure Portal is mentioned
2.1.1, 2.1.2.1, 2.1.3.1
Correction
Added the reference to the LoA in the DSD
2.1.1
Clarification
Changed the title of section 2.1.2
2.1.2
Clarification
Changed the title of section 2.3.2
2.3.2
Clarification
Rewording to clarify the procedures in scope
2.3.2,
Clarification
Rewording to explain the meaning of eIDAS authentication in this context.
2.3.2
Functionality
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
Clarification
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
Common Services
Clarification
Added clarification on the understanding how EvidenceTypeList and EvidenceTypes prove requirements
3.2.2, 3.2.4 (4.3), 3.2.5 (5.4)
Clarification
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),
Correction
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
Functionality (Breaking change)
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
Functionality (Breaking change)
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
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
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)
Functionality (Breaking change)
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)
Functionality
Start of migration to a refactored option for DSD LCM
For the DSD Life Cycle Management (LCM) a new refactored specifications is provided (as decided by the TDD subgroup in the meeting on) . It will not immediately replace the currect baseline specification. Both specifications, the baseline and the refactored, will be supported by the Common Services. The refactored version will be phased-in after the Q3 2023 snapshot of the TDD.
For MS that have not yet implemented LCM for the DSD and plan to do so, it is recommended to ignore the baseline version and instead start directly with the refactored version. The baseline version may be phased out at a later stage. The differences between baseline and refactored are summarized as follows:
LCM Interface Specification of the DSD - Baseline (chapter 3, section 3.1.5, abbrev. DSD-SUB): Provides the inital specification of the DSD LCM. The model does not separateAccessService andPublisher as seperate registry objects of an Evidence Provider. This is not a real programmatic Common Services problem but logically incorrect from the underlying DSD LCM data model. In this baseline, eachPublisher must have its own entry forAccess Service. Thus,AccessServicesthat are used by multiplePublisherscannot be associated toPublisher but must be repeated in each Evidence Provider registry object.
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 associations described in bullet 2. are not valid anymore. Instead new associations have been defined as described under bullet 3. : LCM Interface Specification of the DSD - Refactored (chapter 3, section 3.1.6, abbrev. DSD-SUB_RF): Corrects the logical problems of the inital model and lists the AccessService as another RegistryObject that can be associated with evidence types and publishers. Thus, the new classification node AccessService and the new association ProvidesAccess (linking up DataServiceEvidenceType with AccessService) is introduced. Due to the change, the semantics of the classification node EvidenceProvider and the association ServesEvidenceType are also changed. EvidenceProvider now only comprises the Publisher . The association ServesEvidenceType links the EvidenceProvider with AccessService.
LCM Interface Specification of the DSD - Refactored (chapter 3, section 3.1.6, abbrev. DSD-SUB_RF): Corrects the logical problems of the inital model and lists theAccessServiceas separate RegistryObject. Thus, the new classification nodeAccessServiceis introduced and the associations of the LCM for the DSD are redefined. The associationProvidesEvidenceTypenow links upEvidenceProviderwithDataServiceEvidenceType and the associationUsesAccessService reflects the relation betweenEvidenceProvider andAccessService.
The underlying dependencies and business rules that made the change necessary are described in new section 5.5.2.2 (baseline) and 6.5.2.2. (refactored). In the baseline three rules have been added to check the underlying dependencies without chaing the underlying model.
Impact:
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.1.6
Redefinition on
New content
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
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)
Correction
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
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
Correction
In diagram EB LCM "Requirement", cardinality of @lang is M, not [ 1..1 ]
3.2.5
Clarification
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
Clarification
Added the specific DNS name template that will be used for common service discovery.
3.4.3.
Editorial
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
Clarification
Clarify that OOTS proxy caches are allowed to serve stale content if an error occurred in accessing the Common Service origin server
3.4
Functionality
Document the use of HTTP status codes in the common service REST binding.
3.6.2.5
Clarification
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
Functionality
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
Functionality
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
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.*
Functionality
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 therim:Slot "SpecificationIdentifier" is mandatory with value "oots-lcm:v1.0"
For the DSD LCM Baseline the use of therim:Slot "SpecificationIdentifier" is not allowed.
For the EB LCM the use of therim: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)
Functionality (Breaking change)
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)
Editorial
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
Correction
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)
Evidence Exchange
Correction
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
Functionality
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
Clarification
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
Functionality
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.
Clarification
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)
Clarification
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
New content
Adding the ebMS header to each example describing the Evidence Exchange. Correction of existing examples.
4.5.4
Correction
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)
Functionality (Breaking change)
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
Functionality (Breaking change)
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
Clarification
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
Clarification
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
Clarification
Added a link to the "patched" ebMS3 core XSD that includes the type attribute for the property element.
4.7 (2.1)
Clarification
Adding note to the ebMS header specification that in case of exceptionsthe originalSender of the response message should be the Error Provider declared in the Evidence Error Response Message.
4.7 (2.4)
Correction
When referring to "Competent Authority", make sure the "or Intermediary Platform" is present.
4.7
4.8
Clarification
Error reporting for violation of the implementation guide for the ebMS3 header is to use an evidence error response message, not an ebMS3 error signal message.
4.7.1.1
Functionality
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
Correction
The type attribute on party identifier is mandatory, not optional, in our implementation guidelines.
4.7.2.2
Clarification
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
Editorial
Updated the reference to Requirements and recommendations regarding the Digital Certificates used in eDelivery to the latest version.
4.7.6
Correction
Corrected a wrong reference
Reference to Article 18 of IA should be to Article 17
4.8.2
Correction
Corrected a wrong reference
Reference to Article 17 (5) should be to 28 (6)
4.8.5
Functionality
Added a new section on log retention. For now limited to quoting the IA 17 (4).
4.8.6
Clarification
Clarified that preview-related functionality may be provided by Intermediary Platform.
4.9.1
Clarification
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.
Correction
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
Functionality
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
Clarification
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
Editorial
Fixed RFC reference
4.9.4
Clarification
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
Clarification
Also define format and life-cycle of return URL
4.9.4
Clarification
Reminder to recommend use of same eID for the two authentications
4.9.4
Correction
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
Correction of URIs
All URIs in all parts of this chapter that referenced "tech.europa.eu" are updated to "tech.ec.europa.eu"
4.*
Editorial
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
New content
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 assdg:SectorSpecificAttributeof therim: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
Related Artifacts
Correction
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)
Clarification / Correction
Adding the ebMS header to each example describing the Evidence Exchange. Correction of existing examples. Update of README.md
Git (XML): Request-Response Samples (4.5.4 ...) and README.md
Correction
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
Functionality (Breaking change)
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
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
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)
Redefinition on
New Content
New schematrons (EDM-ebMS) for ebMS header validation (Evidence Exchange)
GIT (SCH)
Functionality (Breaking change)
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
Functionality (Breaking change)
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
Correction
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
Correction
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)
Editorial
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.
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.
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
Functionality (Breaking change)
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
Correction
The xlink XSD imports a local copy of the XML xsd.
GIT
Comment
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
Change log for June 2023 snapshot
The following table summarizes the changes compared to the previous snapshot (March 2022).
Chapter / Location
Area / kind of change
Comments
Location (Chapter, Section)
Date of change
Common Services
Correction
Constraint relaxed, also allowing ebCore Party ID type unregistered as values for schemeID
3.1.4, 3.1.5
Correction
Including the class "DistributedAs" to the 4.4.3. Query Error Response of the DSD requesting additional User Provided Attributes (DSD:ERR:005) and API doc. Updating Data Model, Implementation Guideline and XML examples. According to the XSD this element was mandatory and validation of the DSD failed.
3.1.4
Correction
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.
3.2.5
Correction
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)
Evidence Exchange
Clarification
Reworded RESP02 to cover identity ambiguity
4.3
Correction
Relaxed RESP03, indicating date and time of availability is optional
4.3
Editorial
Included the need to indicate the level of assurance as part of requirement REQ16 and REQ17
4.3
Correction
Constraint relaxed, also allowing ebCore Party ID type unregistered as values for schemeID
4.5.1, 4.5.2, 4.5.3
Correction
Aligned the definition of the PossibilityForPreview slot with Art 13 (1) k. of the Implementing Act
4.5.1.
Correction (Breaking change)
Updated cardinalities of Procedure, Requirement slots in Evidence Request
4.5.1.
Correction
The QueryExceptionType is defined in query.xsd instead of rs.xsd
4.5.3.
Editorial
Adding an info box and role model that illustrates the use of the agent class and thereby clarifying the different multiplicities and classification values that are allowed in the different transactions (Evidence Request, Evidence Response, Error Response) and for the actors (Evidence Requester, Evidence Provider, Error Provider.
4.5.1 (3.2, 3.3)
4.5.2 (3.1, 3.2)
4.5.3 (3.1, 3.2)
Editorial
"The Requirement slot" → "The Requirements slot"
4.5.1.3.1
2023-05-18
Correction (Breaking change)
Changing cardinality and description of requestID andrim:slot "EvidenceRequester" from 1..1 to 0..1 in the Error Response. If the Evidence Request is not well-formed and these elements are not provided, the error response cannot provide values for it. Making the elements optional and changing the corresponding business rules R-EDM-ERR-S003 and R-EDM-ERR-S013. Both elements MUST be present in the QueryResponse, unless the rs:exception/@xsi:type 'InvalidRequestExceptionType' is used. The rs:exception/@xsi:type 'InvalidRequestExceptionType' indicates that the QueryRequest was not well-formed.
4.5.3 (1, 2, 3.2)
4.6 (4.1)
Correction (Breaking change)
Changed Business Rules description and Schematrons on Agent/Classification in the Request, Response and Error Response.
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
Correction
Path to identify the C4 in DSD response is incorrect; should be "Publisher" instead of "EvidenceProvider"
4.7.2.2
Correction
Corrected the AS4 action value used when the QueryResponse is an evidence response as described in section 4.5.2.
4.7.5.
Clarification
The conversation identifier is reused for all messages for a user session, it is not needed to use separate ones for different data services.
4.7.5.2
2023-05-23
Editorial
Updated reference from era when Implementing Act was still a draft
4.8.1
New content (informative)
Adding a new sample flow illustrating the "evidence unavailable" status response.
4.10.5.2
OOTS Guidance and UX Recommendations
Data Models
Related Artifacts
Correction
Corrected rules for R-EDM-REQ-C014, R-EDM-REQ-C038, R-EDM-REQ-S040, REC-EDM-C050.
GIT
Correction (Breaking change)
Cardinality of Jurisdiction in reference framework type was changed from 0..1 to0..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
Correction (Breaking change)
Changed Business Rules description and Schematrons on Agent/Classification in the Request, Response and Error Response.
GIT
Correction (Breaking change)
The requestID andrim:slot "EvidenceRequester" MAY be present in the Error Response
GIT
Correction
Updated schematron rules where just a uuid must be present so that no other characters(urn:uuid) are are allowed.
GIT
Correction
Fixed rules containing "no other than"
GIT
Correction (Breaking change)
Updated cardinalities of Procedure, Requirement slots in Evidence Request
GIT
Correction
SCH rule for eIDAS UID format and length update CC/CC/X..Z{9} was updated to CC/CC/X..Z{256}, where CC is a country code from codelist
GIT
Correction (Breaking change)
The xs:element name="ReferenceFramework" type="sdg:ReferenceFrameworkType" SHOULD be present. If the EB query was started with optional parameters such as 'procedure-id', 'country-code', 'jurisdiction-admin-l2' or 'jurisdiction-admin-l2', the EB always returns only those requirements that have a reference framework included. Requirements without a reference framework are not listed by the EB if optional parameters are used. For a query without optional parameters, however, the EB returns all requirements, i.e. also those that do not have a reference framework. These are not valid instances in the sense of the follow-up processes of the OOTS. In the follow-up query of the EB "GetEvidenceType", it must be ensured that only those requirements are queried that contain a reference framework. A query without optional parameters returns requirements without corresponding reference framework to support development teams to find applicable (incomplete) requirements that need to be populated via the Life Cycle Management (LCM).
3.2.4
GIT (R-EB-REQ-S017)
Change log for March 2023 snapshot
The following table summarizes the changes compared to the previous snapshot (December 2022).
Chapter / Location
Area / kind of change
Comments
Location (Chapter, Section)
High Level Architecture
Editorial
Added LCM to acronym list
1.Acronyms
Update
Expanded evidence preview from (just) a service to a process to better describe the various steps, in text and Archimate diagram.
1.3.3
Update
Added language on Intermediary platform.
1.3.3
1.3.4
Editorial
Clarified role of user selection of MS to query.
1.10.1
User identification and authentication
Update
Clarifications on context, reuse of eIDAS
2.1.1.
2.1.3.2.
2.1.4.
Correction
Update on the use of attributes beyond the mandatory attributes of the minimum data set of eIDAS
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
Figure 1 for clarification
2.1.2.1.
Correction
Update reference to relying party requesting authentication to reflect previous restructure of the chapter.
2.1.2.3.
Correction
Update of title to reflect the restructuring.
2.1.2.4.
2.1.2.3.
Correction
Restructuring to reflect the different types of representation. New sections added under this chapter.
2.3.
Update
New example (non-normative) added for user authentication - legal person
2.3.4.
Common Services
Correction
Corrected reference to RFC 7234 which is obsoleted by RFC 9111.
3.4.3.
3.4.4.
Update
Updated the EBjurisdiction-admin-l2 and jurisdiction-admin-l3description.
3.2.4
Correction
Updated cardinality of StringValue, DateValue, BooleanValue in SupportedValue in DSD from 0..1 to 0..n . Removal of currently not XSD supported ValueTypes of SupportedValue.
3.1.4
3.1.5
Correction
Updated the default value of theConformsTo attribute in the DSD Query and LCM descriptions from oots:edm-v1.0 to oots-edm:v1.0 to align with Request-Response specification identifier
3.1.3,3.1.4, 3.1.5
Update
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)
Update
Change all XML examples provided in the EB and DSD query specifications. Alignment of text according to examples given.
3.2.3 (EB), 3.2.4 (EB), 3.1.3 (DSD), 3.1.4 (DSD)
Update
Change all XML examples provided in the EB and DSD LCM interface specifications. Alignment of text according to examples given.
3.2.5 (EB) 3.1.5 (DSD)
Correction
Updated cardinalities in diagrams and text in the EB and DSD LCM interface specifications.
3.2.5 (EB) 3.1.5 (DSD)
Correction
Removed Gender-CodeList.gc from Semantic Repository
3.3 Semantic Repository (SR)
Update
Document that access to the Common Service is public.
3.6.2.5.
Update
Inclusion of "detail" attribute to rs:Exception in DSD and EB queries and LCM
3.2.4 (EB), 3.1.4 (DSD)
3.6
Update
Added section that illustrates an EB Interaction Example Flow
3.2.4 (EB) - 4.7
Evidence Exchange
Update
Adding the default valueurn:cef.eu:names:identifier:EAS to@typein section 2.3 Static Routing Metadata of the 4.7 eDelivery configuration.
4.7
Update
Documented that OOTS will (initially) use the current version 1.15 of eDelivery AS4 common profile and four corner profile enhancement.
4.7
Update
Added reference to eDelivery certficate guidance document
4.7
Update
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.
4.7.5
Updated
Added reference to UX work on previewing multiple evidences.
4.9.6
Update
The sample flows section was expanded. It now covers all the situations of the Projectathon and has many other corrections and extensions.
4.10
Update
Update all XML snippets, comments related to the use of formats and codelists and other corresponding descriptions in Syntax Mapping
4.5.1, 4.5.2, 4.5.3
Update
Update all XML examples, comments and corresponding descriptions in OOTS-EDM Examples of the Evidence Exchange
4.5.4
Update
Adding example upon request of an Extract of a Commercial Register
4.5.4
Correction
Updated Authorized Representative in Data Model Diagram of Evidence Request - Alignment of PlaceOfBirth and Identifier/@schemeID
4.5.1
Correction
Changed name from 1..1 to 1..n and added lang attribute in Agent class (slots: Evidence Provider, Evidence Requester, Error Provider, Issuing Authority
4.5.1, 4.5.2, 4.5.3
Correction
Added PostCityName to tables of Syntax Mapping where missing
4.5.1, 4.5.2, 4.5.3
Update
Changed rim:slots for procedure and requirement from 0..1 to 1..1, making it mandatory due to requirements of the IA
4.3, 4.5.1
Correction
Removal of currently not XSD supported ValueTypes of SupportedValue.
4.5.1
OOTS Guidance and UX Recommendations
Update
OOTS Guidance is updated to reflect latest views from the guidance team.
6.1
Update
Link to UX recommendations updated
6.2
Data Models
Update
Updated the introductory text
5
Removal
Sections on three categories of data models are removed. They will be replaced by new content.
5.2
5.3
5.4
Related Artifacts
Correction
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
SDG-GenericMetadataProfile.xsd
Update
Create new set of examples and snippets in the GIT workspace for DSD, EB, LCM and Request-Response
Directory OOTS-EDM/xml
Update
Create updated set of business rules for DSD, EB, LCM and Request-Response (Folders: "Complete XML examples" and "Snippets" in corresponding directories
Directory OOTS-EDM/xlsx
Update
Create updated set of content related schematron validation files for DSD, EB, LCM and Request-Response (all files ending with -C.sch) and tested them.
Directory OOTS-EDM/sch
Correction
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/sch
Update
Updated all readme files links and text aligned with the new xml samples.
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
Directory OOTS-EDM/OOTS-EDM/xlsx/
Update
Updated Api Documentation for the Common Services
oots.pages.code-europa-eu.gitlab.host/tdd/apidoc/
Change log for December 2023 snapshot
The following table summarizes the changes compared to the Q3 2022 snapshot (October 2022).
Chapter / Location
Area / kind of change
Comments
Location (Chapter, Section)
High Level Architecture
Minor various
Clarified that offering preview links is no hard indication that evidences will be available
1.3.3
Added Preview Area to list of core elements
1.3.4
Clarified that OPP details are implementation dependent.
1.4.2
Clarify that identity information in the first loop may not be sufficient for record matching and that matching is not simple string matching.
5.2
Added XSLT or other presentation information to SR section.
6.4
Added reference to IA articles for DSD and EB LCM
6.5
Identity attributes are not just user, may also be of represented person
7.5
Clarified that eDelivery logs do not include evidence payload content
9.2
Clarified that the sample flow is non-normative
10.1
Fixed an incorrect cross-reference between steps in the procedure
10.1
User identification and authentication
Editorial
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.
2.1
Editorial
Renamed chapter to "Evidence requesters - user authentication and use of eIDAS"
2.2
Clarification
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”
2.2.1
Renamed chapter to "Evidence providers - identity and evidence matching"
2.3
Clarification
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
2.3.1
Editorial
Renamed to "Re-authentication by the evidence provider"
2.3.2
Clarification
Clarification regarding the case when re-authentication is needed
2.3.2
Common Services
Editorial
Split large pages 3.2 and 3.3 into several sub-pages
3.2
3.3
Correction
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
Correction
Cardinality of Procedure Title and ReferebceFramework Title element fixed to 1..n
Editorial
Rule reference forReferenceFramework added forEB
3.2.4.2.2
3.2.4.3.2
Editorial
Improved spelling
3.2.4.4.4
Correction
Changed data type of Name from Code to Text
3.2.5.4.2
Editorial
API section formating of titles
3.6
Semantics
Updated content of the Semantic Repository chapter
3.3
Security
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.7 (new)
Existing DSD TLS section and EB TLS section now refer to the new 3.7
3.1.4.7
3.2.4.6
Added note that trust model for common services response signature and any constraints on certificates are not yet provided.
3.1.4.6
3.2.4.5
Business Rules
Content related business rules updated
3.1.4
3.1.5
3.2.4
3.2.5
3.6
Codelists
Code list section updated
3.5
Evidence Exchange
Correction
Removed a process flow diagram that used a feature from a previous architecture that we dropped.
4.4
Correction
Changed the sample Exception to a timeout exception. Previously, it used ObjectNotFoundException but that is intended for updates, not queries.
4.5.3
Editorial
Put back the heading numbering
4.7
Correction
Introduction states that Preview Areas are on Evidence Requester side. They are instead on Evidence Provider side.
4.8.1
Correction
Corrected a reference to evidence request logging, the article number is 17 instead of 18.
4.8.3.2
Security
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.7
Management
Added a note to eIDAS dashboard or similar secure configuration sharing services (response to a comment of the security sub-group).
4.7
Business Rules
Content related business rules updated
4.5
4.6
Correction
Updated Distribution class: Removing Packaging Format and Compression Format and adding Transformation
4.5.2
Informative
New section 4.10 on evidence flow variations
4.10
Related Artifacts
Documentation
Added README files and rearranged some of the files
The previous (Q2 2022) snapshot of the OOTS Technical Design Documents was published in June 2022. That snapshot was not a public snapshot. For those who had access to that previous snapshot, the following table lists changes made to the technical design documents after the Q2 2022 snapshot. The changes were based on:
Publication of the Implementing Act asC/2022/5628 final.
Feedback on the previous snapshot provided by some Member States.
Feedback and other requests from the teams developing the OOTS test service and implementing the Common Services.
Addition of additional implementation guidelines.
Many other improvements from closer scrutiny of the existing text by the editors.
Chapter / Location
Area / kind of change
Comments
Location (Chapter, Section)
General
Editorial
Changed the bibliographic entry of the Implementing Regulation now that it is published
1
Editorial
Added EUPL license for content of all chapters.
1, 2, 3, 4, 5, 6
Editorial
RegRep identifiers of type URN UUID start with the prefix "urn:uuid"
Documented Member State business requirement to express a desire of the requester to limit responses to a particular language and how the use of the (existing) "xml:lang" attribute of QueryRequest enables this.