Contents

1. Exchange Data Model: QueryRequest (Evidence Request)

This guideline explains how to use the ebRS QueryRequest syntax to implement the Business Requirements (Req ID) described for the Evidence Request. The guideline provides specific details for each class and information element including the underlying standards, data types and cardinalities to produce conformant XML documents. In the following sections, we describe the XML serialization of the Evidence Request in the same hierarchical order of the corresponding Exchange Data Model.

The Exchange Data Model in the figure below provides an overview of the information elements and their associations contained in the Evidence Request. An Evidence Request is a message created by the Evidence Requester (ER) containing all the necessary parameters for requesting evidences.

Note that rim:Slot elements are to be processed based on the value of the name attribute, not on XML document order. However, it is good practice to following the order as presented in the diagram below. 

To form a valid QueryRequest (Evidence Request), at least the following elements are required:

• the "id" of the QueryRequest;
• the "SpecificationIdentifier" to identify the version of this specification. Please use the value "oots-edm:v1.0";
• the "IssueDateTime" to describe the time of the request;
• the "Procedure" in which the request for evidence was made;
• the "PossibilityForPreview" to express whether the possibility of previewing the evidence is required in accordance with Article 14(5) of Regulation (EU) 2018/1724;
• the "ExplicitRequestGiven" to indicate the user consent to request the evidence;
• the "Requirements" describing the needs of the procedure with regard to the evidence request or a particular piece of information;
• the "EvidenceRequester" to identify the one or more entities that are technically executing the request on behalf of the User;
• the "EvidenceProvider" to identify the entity that the Evidence Request is sent to;
• the "ResponseOption" "LeafClassWithRepositoryItem" to indicate the request of a document.
• the "QueryDefinition" expressed through the information entity "DataServiceEvidenceType" in the "EvidenceRequest" slot, which is used to form the "DocumentQuery".
• the highlighted information entities "LegalPerson" and "NaturalPerson" to identify the Evidence Subject (or User) for which the query is done. The business rules do not permit the use of both information entities at the same time;

2. ebRIM Definitions of the QueryRequest (Evidence Request)

This section defines the core ebRIM elements that are used to compose a Query Request (Evidence Request). It thereby distinguishes between attributes and slots in the column ebRIM type to define the Evidence Request:

Attribute Definition: The table provides an overview of the mandatory attributes and the information they contain for each QueryRequest according to ebRIM. 

Slot definition: The elements provide an overview about the defined ebRIM SlotType instances, which have a name and a value. The value is of type ValueType. Most rim:Slots do not contain sub-properties other than the SlotValue itself, except if they are collections. Collections refer to other sources of information such as Core Vocabularies and a corresponding syntax binding to a class defined in the SDG Generic Metadata Profile (see section 3). 

2.1. ebRIM QueryRequest example

The Evidence Request is syntactically expressed using the ebRS QueryRequest, as shown in the example below.

The element id  is used to assign a unique identifier to the Evidence Request.

The element ResponseOption  is used to control the type and structure of results within the corresponding QueryResponse. It specifies whether the RegistryObjects returned should include composed objects. Must be fixed value LeafClassWithRepositoryItem to ensure that the response include the RepositoryItems, if any, for every rim:RegistryObject  in the rim:RegistryObjectList  element of the QueryResponse.

In order to specify a Query , the ebXML Element Query is used. The attribute queryDefinition  can be used to specify the type of Query to be done. The value of this attribute must come from the appropriate codelist.  The value of the queryDefinition  attribute in the Query element must always be DocumentQuery when requesting Document Evidence. 

<?xml version="1.0" encoding="UTF-8"?>
<query:QueryRequest xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmlns:rs="urn:oasis:names:tc:ebxml-regrep:xsd:rs:4.0"
    xmlns:sdg="http://data.europa.eu/p4s"
    xmlns:xmime="http://www.w3.org/2005/05/xmlmime"
    xmlns:rim="urn:oasis:names:tc:ebxml-regrep:xsd:rim:4.0"
    xmlns:query="urn:oasis:names:tc:ebxml-regrep:xsd:query:4.0"
    xmlns:xlink="http://www.w3.org/1999/xlink"
    xmlns:xml="http://www.w3.org/XML/1998/namespace"
    xml:lang="DE"
    id="urn:uuid:c4369c4d-740e-4b64-80f0-7b209a66d629">
    <!-- The 'id' attribute of a 'QueryRequest' MUST be unique UUID (RFC 4122) for each request starting with prefix "urn:uuid:" -->
    <!-- The optional 'lang' attribute can be used to indicate a preferred language of the requested Evidence  -->

    <!-- Slots are omitted for clarity -->

    <!-- Default Response Option -->
    <query:ResponseOption returnType="LeafClassWithRepositoryItem"/>

    <!-- Query Definition -->
    <query:Query queryDefinition="DocumentQuery">

    <!-- Further slots are omitted for clarity. -->

    </query:Query>
</query:QueryRequest>

2.2. Specification Identifier example

The SpecificationIdentifier  slot is used for expressing the version of the specification used for creating the referred message. A Slot with the name SpecificationIdentifier  is used with the ValueType of StringValueType. In this version of the TDD specification, this MUST be set to the value oots-edm:v1.0

<!-- SpecificationIdentifier Slot -->
    <rim:Slot name="SpecificationIdentifier">
        <rim:SlotValue xsi:type="rim:StringValueType">
            <!-- MUST be the fixed value "oots-edm:v1.0". -->
            <rim:Value>oots-edm:v1.0</rim:Value>
        </rim:SlotValue>
    </rim:Slot>

2.3. Issue Date and Time example

The IssueDateTime  slot is used for expressing the creation date and time of the evidence request. If the value of the ExplicitRequestGiven slot is true, the value of the IssueDateTime  slot shall not be materially different from the date and time at which the explicit request was made by the user.  

Α Slot with the name IssueDateTime  is used with the ValueType of DateTimeValueType which has an ISO timestamp value according to xsd:dateTime.

<!-- IssueDateTime Slot -->
 <rim:Slot name="IssueDateTime">
     <rim:SlotValue xsi:type="rim:DateTimeValueType">
         <!-- MUST be according to xsd:dateTime.  -->
         <rim:Value>2021-02-14T19:20:30+01:00</rim:Value>
     </rim:SlotValue>
 </rim:Slot>

2.4. Procedure example

A slot with the name Procedure  and ValueType of InternationalStringValueType is used to represent the information contained in one or more local languages and has a sequence of LocalizedString instances. Each LocalizedString instance is specific to a particular locale. The language attribute must be specified using ISO 639-1 two-letter code using the codelist 'LanguageCode', default value EN. The value represents the procedure under which the Evidence Requester requests the specific evidence.

<!-- Procedure SLOT -->
<rim:Slot name="Procedure">
    <rim:SlotValue xsi:type="rim:InternationalStringValueType">
        <rim:Value>
            <!-- Code for "Requesting a birth certificate". MUST be part of the code list 'Procedures' -->
            <!-- MUST be part of the code list 'LanguageCode' (ISO 639-1 two-letter code), default value 'EN' -->
            <rim:LocalizedString xml:lang="EN"
                value="R1"/>
        </rim:Value>
    </rim:SlotValue>
</rim:Slot> 

2.5 Preview Location example

The PreviewLocation  element is used for expressing the location of the Preview Space for the Evidence Request. The element is only used in cases where a preview is required on the Evidence Provider side. The Evidence Requester in such case has received an Evidence Error Response with a defined preview location defined as URI. The preview location is then added to the second evidence request after successfull execution of the the preview to give an indication to the Evidence Provider that the preview was executed under the defined URI.  The Evidence Provider than can validate if the Preview has been excecuted successfully under the given URI. 

Α Slot with the name of PreviewLocation  is used with the ValueType of StringValueType which has the value of a URI. The URI MUST be starting with 'https://'.

<!-- PreviewLocation Slot -->
 <rim:Slot name="PreviewLocation">
     <rim:SlotValue xsi:type="rim:StringValueType">
         <!-- MUST be a URI starting with 'https://' -->
         <rim:Value>https://preview.space.example.com/requests/d36af8bc-fea6-4ee5-a32d-5bef82cdb071</rim:Value>
     </rim:SlotValue>
 </rim:Slot>

2.6. PossibilityForPreview example

The PossibilityForPreview is the slot used to express whether the possibility of previewing the evidence is required in accordance with Article 14(5) of Regulation (EU) 2018/1724. If its value is true, then the user should be given the option to preview, if desired, the provided evidence. If its value is false, then the user will not be able to preview the evidence to be received. The flag is set by the ER, when such an exemption is required for the execution of the specific procedure. It must be formated according to xs:boolean. For information about legal preview requirements see Article 14 (3) f  and 14 (5) of Regulation (EU) 2018/1724. The following example depicts the use of the slot.

<!-- PossibilityForPreview Slot  -->
 <rim:Slot name="PossibilityForPreview">
     <rim:SlotValue xsi:type="rim:BooleanValueType">
         <!-- MUST be according to xs:boolean -->
         <rim:Value>true</rim:Value>
     </rim:SlotValue>
 </rim:Slot>

2.7. Explicit Request Given example

The ExplicitRequestGiven is the slot used to declare that the Evidence Requester has received the user's explicit confirmation to request the evidence from the specific Evidence Provider. When its value is true, then the user has provided his explicit request, while when its value is false, then the user has not provided his explicit confirmation to request the evidence. The flag false is set by the ER, when such an exemption is required for the execution of the specific procedure. It must be formated according to xs:boolean. The following example depicts the use of the slot.

If the value of this slot is true, the value of the IssueDateTime slot shall not be materially different from the date and time at which the explicit request was made by the user.   

 <!-- ExplicitRequestGiven Slot  -->
 <rim:Slot name="ExplicitRequestGiven">
     <rim:SlotValue xsi:type="rim:BooleanValueType">
         <!-- MUST be according to xs:boolean -->
         <rim:Value>true</rim:Value>
     </rim:SlotValue>
 </rim:Slot>

3. SDGR Application Profile for the ebRIM QueryRequest (Evidence Request)

The SDGR application profile for the Evidence Request defines the semantics of the previously introduced rim:Slots  defined as a collection (green components) of the Evidence Request Message. The SDGR application profile for the Evidence Request describes how the SDG Generic Metadata Profile (SDG-Syntax) is profiled in ebRIM in order to compose a valid QueryRequest. It therefore contains a mapping to the underlying SDG-syntax elements and the necessary parameters for requesting evidences based on information retrieved from eIDAS, the Evidence Broker and the Data Service Directory. Thus, the values for several parameters are obtained from the queries made to eIDAS, the Evidence Broker and the Data Service Directory in order to initiate the Query Request. The namespace of the SDG-syntax is http://data.europa.eu/p4s. In the following samples, the prefix "sdg" is assumed to be linked to the namespace http://data.europa.eu/p4s.

3.1 Requirements slot and example

The Requirements slot in the Evidence Request is contextual information that can be used to perform logging in compliance with the regulatory framework of the SDGR. It is not (yet) expected to be required to determine the evidence for the evidence subject. The value is obtained by the Evidence Requester from the Evidence Broker while executing an SDG procedure.

A slot with the name Requirement and ValueType of CollectionValueType is used by the Evidence Requester to provide the Requirements that will be proven using the requested evidence. It is represented as a list of Requirement elements, expressed using the CCCEV 2.0 Vocabulary and typically extracted from the Evidence Broker. The value of Identifier  of a Requirement  must be a unique UUID (RFC 4122) listed in the EvidenceBroker and use the prefix ''https://sr.oots.tech.ec.europa.eu/requirements/[UUID]'' pointing to the Semantic Repository.

<!-- Requirements Slot  -->
<rim:Slot name="Requirements">
    <rim:SlotValue xsi:type="rim:CollectionValueType" collectionType="urn:oasis:names:tc:ebxml-regrep:CollectionType:Set">
        <rim:Element xsi:type="rim:AnyValueType">
            <sdg:Requirement>
                <!--  The value of 'Identifier' of a 'Requirement' MUST be a unique UUID (RFC 4122) listed in the EvidenceBroker and use the prefix ''https://sr.oots.tech.ec.europa.eu/requirements/[UUID]'' pointing to the Semantic Repository. -->
                <Identifier>https://sr.oots.tech.ec.europa.eu/requirements/315cfd75-6605-49c4-b0fe-799833b41099</Identifier>
                <!-- MUST be part of the code list 'LanguageCode' (ISO 639-1 two-letter code).  -->
                <Name lang="EN">Proof of Birth</Name>
            </sdg:Requirement>
        </rim:Element>

            <!--  another cccev requirement may be added as rim:Element-->

    </rim:SlotValue>
</rim:Slot>

3.2 Evidence Requester slot and example

The Evidence Requester element is used to describe an organisation that requests data or documents from Evidence Providers. The agent requests the evidence, by sending an Evidence Request to the Evidence Provider, on behalf of the evidence subject.  In several cases it might be a portal/organisation or intermediary that initiates the evidence request. If there are multiple agents involved, they can be classified. In case of multiple national routings on the side of the Evidence Requester an Evidence Request e shall name and identify the intermediary platforms involved in the communication.   No central registry of Evidence Requesters is required, only the minimal details required to enable legal logging of requests or facilitate the processing of the evidence request. 

The following info box and role model illustrates the principles and agent roles that can be applied for the Evidence Requester.

A Slot with the name of EvidenceRequester  is used with the ValueType of CollectionValueType which is a container for a collection of values. It may be used to represent a SlotValue that is a collection of values where each value is represented by a AnyValueType instance which accepts any xml representation. In this particular case, the Agent class is used for the expression of the Evidence Requester information inside the AnyValueType Slot.

The value of the schemeID  attribute of the Identifier  MUST be part of the code list 'EAS' (Electronic Address Scheme ) and use the prefix 'urn:cef.eu:names:identifier:EAS:[Code]' or MUST use the prefix 'urn:oasis:names:tc:ebcore:partyid-type:unregistered'.

The value of lang  attribute of the Name MUST be part of the code list 'LanguageCode' (ISO 639-1 two-letter code). 

The value of the AdminUnitLevel1  MUST be coded using the code list 'CountryIdentificationCode' (ISO 3166-1' alpha-2 codes). The value must be provided if the Classification  of the Agent is 'ER' (EvidenceRequester).

The value of the AdminUnitLevel2  MUST be coded using the code list 'NUTS' (Nomenclature of Territorial Units for Statistics).

The CollectionValueType Slot as a container can hold information about the Evidence Requester and Intermediaries. The roles are classified through the element Classification . The value of Classification  MUST be part of the code list 'AgentClassification'. Default value: ER (Evidence Requester). If the code 'IP' (Intermediary Platform) is present there must be another 'sdg:Agent' Element containing the code 'ER'. The codes 'EP' and 'ERRP' shall not be used by this transaction.

<!-- EvidenceRequester Slot  -->
<rim:Slot name="EvidenceRequester">
        <rim:SlotValue xsi:type="rim:CollectionValueType">
            <rim:Element xsi:type="rim:AnyValueType">
                <sdg:Agent>
                    <!-- The value of the schemeID  attribute of the Identifier  MUST be part of the code list 'EAS' (Electronic Address Scheme ) and use the prefix 'urn:cef.eu:names:identifier:EAS:[Code] or MUST use the prefix 'urn:oasis:names:tc:ebcore:partyid-type:unregistered'. -->
                    <sdg:Identifier schemeID="urn:cef.eu:names:identifier:EAS:0096">DK22233223</sdg:Identifier>
                    <!-- The value of 'lang' attribute MUST be part of the code list 'LanguageCode' (ISO 639-1 two-letter code).  -->
                    <sdg:Name lang="EN">Denmark University Portal</sdg:Name>
                    <sdg:Address>
                        <sdg:FullAddress>Prince Street 15, 1050 Copenhagen, Denmark</sdg:FullAddress>
                        <sdg:LocatorDesignator>15</sdg:LocatorDesignator>
                        <sdg:PostCode>1050</sdg:PostCode>
                        <sdg:PostCityName>Copenhagen</sdg:PostCityName>
                        <sdg:Thoroughfare>Prince Street</sdg:Thoroughfare>
                        <!-- The value of the 'AdminUnitLevel1' MUST be coded using the code list 'CountryIdentificationCode' (ISO 3166-1' alpha-2 codes).  -->
                        <sdg:AdminUnitLevel1>DK</sdg:AdminUnitLevel1>
                        <!-- The value of the 'AdminUnitLevel2' MUST be coded using the code list 'NUTS' (Nomenclature of Territorial Units for Statistics).  -->
                        <sdg:AdminUnitLevel2>DK011</sdg:AdminUnitLevel2>
                    </sdg:Address>
                    <!-- The value MUST be part of the code list 'AgentClassification'. Default value: ER (Evidence Requester). If the code 'IP' (Intermediary Platform) is present there must be another 'sdg:Agent' Element containing the code 'ER'. The codes 'EP' and 'ERRP' shall not be used by this transaction.   -->
                    <sdg:Classification>ER</sdg:Classification>
                </sdg:Agent>
            </rim:Element>
        </rim:SlotValue>
</rim:Slot>

3.3 Evidence Provider slot and example

The Evidence Provider element is used to describe an organisation that receives the Evidence Request from the Evidence Requester.  In most cases, the agent is a public organisation, however in some MSs, for some evidence types, businesses have been accredited to supply them.

An evidence provider must be registered in the Data Service Directory in order to be activated in the SDG OOTS.

The following info box and role model illustrates the principles and agent roles that can be applied for the Evidence Provider.

A Slot with the name of EvidenceProvider  is used with the ValueType of AnyValueType which accepts any xml representation. In this particular case, the Agent class is used for the expression of the Evidence Provider information inside the AnyValueType Slot.

The value of the schemeID  attribute of the Identifier  MUST be part of the code list 'EAS' (Electronic Address Scheme ) and use the prefix 'urn:cef.eu:names:identifier:EAS:[Code] or MUST use the prefix 'urn:oasis:names:tc:ebcore:partyid-type:unregistered'.

The value of lang  attribute of the Name  MUST be part of the code list 'LanguageCode' (ISO 639-1 two-letter code). 

<!-- EvidenceProvider Slot  -->
<rim:Slot name="EvidenceProvider">
    <rim:SlotValue xsi:type="rim:AnyValueType">
        <sdg:Agent>
            <!-- The value of the schemeID  attribute of the Identifier  MUST be part of the code list 'EAS' (Electronic Address Scheme ) and use the prefix 'urn:cef.eu:names:identifier:EAS:[Code] or MUST use the prefix 'urn:oasis:names:tc:ebcore:partyid-type:unregistered'. -->
            <sdg:Identifier schemeID="urn:cef.eu:names:identifier:EAS:9930">DE73524311</sdg:Identifier>
            <!-- The value of 'lang' attribute MUST be part of the code list 'LanguageCode' (ISO 639-1 two-letter code).  -->
            <sdg:Name lang="EN">Civil Registration Office Berlin I</sdg:Name>
        </sdg:Agent>
    </rim:SlotValue>
</rim:Slot>

3.4 Evidence Provider Classification slot and example

The EvidenceProviderClassification slot is used to collect the required information selected by the user during the Data Services Directory queries for the proper discovery of the Evidence Provider. 

A Slot with the name of EvidenceProviderClassification  is used with the ValueType of CollectionValueType with included rim:Elements  of the ValueType of AnyValueType which accepts any xml representation. In this particular case, the EvidenceProviderClassification class is used for the expression of the value selected by the user during a DSD dialog process requesting additional User Provided Attributes (Error: DSD:ERR:005). The SupportedValue  class is used for the expression of the user provided value inside the AnyValueType slot EvidenceProviderClassification. The remaining structure e.g. Identifier, Type, Value Expression, Description  must be adopted from the corresponding DSD QueryResponse.  The following example illustrates the XML mapping.

  <!-- EvidenceProviderClassificationValues Slot  -->
   <rim:Slot name="EvidenceProviderClassification">
       <rim:SlotValue xsi:type="rim:CollectionValueType">

           <!-- Classification Information - Used for finding the evidence -->
           <rim:Element xsi:type="rim:AnyValueType">
               <sdg:EvidenceProviderClassification>
                   <!-- The value of 'Identifier' of MUST be unique UUID (RFC 4122) pointing to a concept for Evidence Provider Classification in the DSD, e.g. SecondarySchool coded as type -->
                   <sdg:Identifier>0c7c9948-0a9f-4407-aedd-a956d1479fbd</sdg:Identifier>
                   <sdg:Type>Codelist</sdg:Type>
                   <!-- Definition of the value expression. Must be published in the Semantic Repository. The codelist contains the values of secondary schools -->
                   <!-- During the DSD query process the user has to select one of these values as additional input parameter for the query in order to identify the correct publisher / evidence provider -->
                   <!-- The selected value will be mapped against the ClassificationValue of Publishers -->
                   <sdg:ValueExpression>https://sr.oots.tech.ec.europa.eu/ep-classification/de/secondaryschool</sdg:ValueExpression>
				   <!-- The value of 'lang' attribute MUST be part of the code list 'LanguageCode' (ISO 639-1 two-letter code).  -->
                   <sdg:Description lang="EN">The Secondary School is the school where a person received a secondary school graduation</sdg:Description>
                   <!-- The selected value of the user MUST be provided in the Evidence Request-->
                   <sdg:SupportedValue>
                       <sdg:StringValue>Wilhelm Gymnasium</sdg:StringValue>
                   </sdg:SupportedValue>
               </sdg:EvidenceProviderClassification>
           </rim:Element>

           <!-- Classification Information - Used for finding the evidence -->
           <rim:Element xsi:type="rim:AnyValueType">
               <sdg:EvidenceProviderClassification>
                   <!-- The value of 'Identifier' of MUST be unique UUID (RFC 4122) pointing to a concept for Evidence Provider Classification in the DSD, e.g. YearOfGraduation coded as type -->
                   <sdg:Identifier>ed8a7f93-3276-452d-9e8c-c9b117572625</sdg:Identifier>
                   <sdg:Type>Codelist</sdg:Type>
                   <!-- Definition of the value expression. Must be published in the Semantic Repository. The codelist contains the values of years to indicate the year of graduation -->
                   <!-- During the DSD query process the user has to select one of these values as additional input parameter for the query in order to identify the correct publisher / evidence provider -->
                   <!-- The selected value will be mapped against the ClassificationValue of Publishers -->
                   <sdg:ValueExpression>https://sr.oots.tech.ec.europa.eu/ep-classification/de/yearofgraduation</sdg:ValueExpression>
				 <!-- The value of 'lang' attribute MUST be part of the code list 'LanguageCode' (ISO 639-1 two-letter code).  -->
                   <sdg:Description lang="EN">The year of graduation is the year when a person received a degree</sdg:Description>
                   <!-- The selected value of the user MUST be provided in the Evidence Request-->
                   <sdg:SupportedValue>
                       <sdg:StringValue>1988</sdg:StringValue>
                   </sdg:SupportedValue>
               </sdg:EvidenceProviderClassification>
           </rim:Element>
       </rim:SlotValue>
   </rim:Slot>

3.5 Evidence Request slot and example

The Evidence Request element is used to request for a piece of evidence to the Data Service of an Evidence Provider. The element provides a complete semantic description required to point to the correct evidence type and format. 

The Slot with the name EvidenceRequest  has a SlotValue of type AnyValueType. It contains a DataServiceEvidenceType  with one Distribution class selected by the Evidence Requester as defined by the SDG AP. This class must specify the  EvidenceTypeClassification (Identifier of the Evidence type) and the Identifier  of the DataServiceEvidenceType  requested together with one distribution containing at least the Format.The element ConformsTo is only used if the Format for the DataServiceEvidenceType  is marked as structured in the code list 'OOTSMediaTypes'. The element ConformsTo links to a conformance profile that relates to an OOTS data model to describe structured pieces of evidence, as it was received from the QueryResponse of the Data Services Directory. The format MUST be part of the code list 'OOTSMediaTypes'. The ConformsTo MUST be a persistent URL with a link to a "DataModelScheme" of the DataServiceEvidenceType retrieved by the DSD and described in the Semantic Repository which uses the prefix "https://sr.oots.tech.ec.europa.eu/distributions/[DataModelScheme]".

Optionally, the requester may indicate that a specific identified Transformation  is to be applied to the evidence by the Data Service. The format of a Transformation description MUST be a als persistent URL with link to a "DataModelScheme" and "Subset" of the DataServiceEvidenceType  retrieved from the Data Service Directory, described in the Semantic Repository which uses the prefix "https://sr.oots.tech.ec.europa.eu/distributions/[DataModelScheme]/[Subset]". The Transformation  itself is defined in the Semantic Repository along the conformance profile expressed by ConformsTo . Thus, a Transformation can be only used if ConformsTo exists. A Transformation is used to minimize the information in the evidence to a specific information requirement. For example, to prove that a particular person has become an adult and acquired full legal capacity, the person identification and age-related information in a birth certificate is sufficient. Information on place of birth or about parents is not relevant and could therefore be omitted.

The diagram below illustrates the use of the component sdg:DistributedAs  to markup structured and unstructured sdg:DataServiceEvidenceType.  The associated business rules of the component sdg:DistributedAs prove the adherence of instances with the rules of the mark up.

Note: In case a structured sdg:format is used without an apporiate OOTS data model the user shall be warned through an appropriate business rules. In this case the receiver of the evidence might not be able to read the evidence as there is no appropriate visualization for the evidence type described as part of an OOTS data model. This special aspect is not reflected in the illustration below. 

The DCAT Application profile is used for representing each XML element. The Evidence Request uses the ValueType of AnyValueType which accepts any xml representation as the slot's value. 

<!-- EvidenceRequest Slot  -->
<rim:Slot name="EvidenceRequest">
    <rim:SlotValue xsi:type="rim:AnyValueType">
        <sdg:DataServiceEvidenceType>
            <!-- MUST be unique UUID (RFC 4122) fetched from the Data Services Directory -->
            <sdg:Identifier>2af27699-f131-4411-8fdb-9e8cd4e8bded</sdg:Identifier>

            <!-- MUST be a UUID retrieved from the Evidence Broker/DSD and include a code of the code list 'CountryIdentificationCode' (ISO 3166-1' alpha-2 codes) using the prefix and scheme ''https://sr.oots.tech.ec.europa.eu/evidencetypeclassifications/[CountryIdentificationCode]/[UUID]'' pointing to the Semantic Repository -->
            <sdg:EvidenceTypeClassification>https://sr.oots.tech.ec.europa.eu/evidencetypeclassifications/DE/620c08b0-eca2-4dd9-9d1e-45fdb0baac8e</sdg:EvidenceTypeClassification>
            <!-- The value of 'lang' attribute of Title and Description MUST be part of the code list 'LanguageCode' (ISO 639-1 two-letter code).    -->
            <sdg:Title lang="EN">Certificate of Birth</sdg:Title>
            <sdg:Title lang="DE">Geburtsurkunde</sdg:Title>
            <sdg:Description lang="EN">An official certificate of birth of a person - with first name, surname, sex, date and place of birth, which is obtained from the birth register of the place of birth.</sdg:Description>
            <sdg:Description lang="DE">Eine amtliche Bescheinigung über die Geburt einer Person – mit Vorname, Familienname, Geschlecht, Datum und Ort der Geburt, welche aus dem Geburtsregister des Geburtsortes erstellt wird.</sdg:Description>

            <!-- This is the selected distribution requested.
            It must be one of the distributions provided by the DSD for this specific Data Service Evidence Type-->
            <sdg:DistributedAs>
                <!-- The value of 'Format' of the requested distribution MUST be part of the code list 'OOTSMediaTypes'.-->
               <sdg:Format>application/xml</sdg:Format>
                <!-- MUST be a persistent URL with a link to a "DataModelScheme" of the DataServiceEvidenceType retrieved by the DSD and described in the Semantic Repository which uses the prefix "https://sr.oots.tech.ec.europa.eu/distributions/[DataModelScheme]".-->
               <sdg:ConformsTo>https://sr.oots.tech.ec.europa.eu/distributions/birthcert-1.0.0</sdg:ConformsTo>
                <!-- MUST be a persistent URL with link to a "DataModelScheme" and "Subset" of the DataServiceEvidenceType retrieved from the Data Service Directory, described in the Semantic Repository which uses the prefix "https://sr.oots.tech.ec.europa.eu/distributions/[DataModelScheme]/[Subset]"-->
               <sdg:Transformation>https://sr.oots.tech.ec.europa.eu/distributions/birthcert-1.0.0/age-of-majority</sdg:Transformation>
           </sdg:DistributedAs>
       </sdg:DataServiceEvidenceType>
   </rim:SlotValue>
</rim:Slot>

3.6 Evidence Subject and Authorized Representative slots and example

The Evidence Subject is the entity whose evidence is requested from the Data Service. The Evidence Subject can be a natural person or a legal person. This can be expressed either by a NaturalPerson OR a LegalPerson slot. A request may contain one of the two but NOT both. The Evidence Subject has a complexity dependent on the nature of the subject and the agreements made in the context of identity record matching. An optional Authorized Representative may also be defined. The Authorized Representative is a Person acting on behalf of the Evidence Subject being either a legally registered business or a natural person to trigger the Evidence Requester's request for evidence. The provided values for Evidence Subjects and Authorized Representatives are primarily bound to the eIDAS agreements.  The figure below illustrates the eIDAS attributes covered by the slots "NaturalPerson", "LegalPerson" and "AuthorizedRepresentative":

eIDAS Minimum Data Set and Level of Assurance

Once-Only Evidence Requests relate to Evidence Subject, the identified users, acting either directly or through a representative. The syntax and semantics of Evidence Subject specifies how person identity attribute information is expressed. The NaturalPerson Slot and Legal Person Slot are obtained using eIDAS Minimum Data Set (MDS). Both slots contain the level of assurance of the eIDAS identification scheme. It is the responsibility of the Evidence Requester to make sure that the Level of Assurance of the identity data that is included to the request matches the previous authentication via eID means issued by an eID scheme notified under eIDAS.

Based on the the identity data received from eIDAS and included to the Evidence Request, the Data Service  may decide if the user, once re-directed, needs to re-authenticate. Data Services could use identity matching based on the attributes received in the Evidence Request with an authentication verification service. The re-authentication on the side of the Data Service will allow the Data Service to verify that an eIDAS authentication took place for a user-session before which resulted in an Evidence Request with the included identity data and the indicated Level of Assurance . Thus, the Data Service could assume that the authentication was made by the user for the execution of an electronic procedure in the scope of the SDG.

Sector specific attributes

Within the Evidence Subject slots LegalPerson, NaturalPerson and AuthorizedRepresentative, it is possible to add further attributes that relate to sector-specific application contexts. These SectorSpecificAttributes can be also retrieved via eIDAS. They are embedded in the slots LegalPerson, NaturalPerson and AuthorizedRepresentative of the Evidence Request message via key-value pairs. Sector specific attributes are developed by Member States and domain experts to create additional attribute schema describing the type and usage of these attributes for inclusion in Member State eIDAS Node metadata. However, SectorSpecificAttributes are not part of the eIDAS Minimum Data Set (MDS) and identification scheme.

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 section 3.6.3 of Authorized Represenative slot and example).

3.6.1 Natural Person slot and example

A natural person that is alive, dead or real acting as Evidence Subject described along the Core Person Vocabulary (https://semiceu.github.io/Core-Person-Vocabulary/releases/2.00/#Person). 

The slot with the name NaturalPerson contains data that describes a Natural Person. When using an ISA Core Person Vocabulary for representing the value of a slot, AnyValueType is used as its type since it allows data in XML format to be used as the slot's value. The slot follows the structure of eIDAS attributes containing mandatory and optional attributes of the Minimum Data Set and Sector Specific Attributes, where applicable. 

The value for LevelOfAssurance  for the Minimum Data Set (MDS) must be part of the code list 'LoA' (eIDAS Levels Of Assurance).

The value of Identifier  MUST have the format XX/YY/ZZZZZZZ where XX is the Nationality Code of the identifier and YY is the Nationality Code of the destination country and ZZZZZZZ is an undefined combination of characters which uniquely identifies the identity asserted in the country of origin. The values of XX and YY MUST be part of the code list 'CountryIdentificationCode' (ISO 3166-1' alpha-2 codes). Example: ES/AT/02635542Y.

The value of DateOfBirth  MUST use the following format YYYY + “-“ + MM + “-“ + DD (as defined for xsd:date).

The value of the AdminUnitLevel1  MUST be coded using the code list 'CountryIdentificationCode' (ISO 3166-1' alpha-2 codes).

The value of the AdminUnitLevel2  MUST be coded using the code list 'NUTS' (Nomenclature of Territorial Units for Statistics).

<!-- NaturalPerson Slot  -->
<rim:Slot name="NaturalPerson">
    <rim:SlotValue xsi:type="rim:AnyValueType">
        <sdg:Person>
            <!-- Level of Assurance for the Minimum Data Set (MDS). The value of 'LevelOfAssurance' must be part of the code list 'LoA' (eIDAS Levels Of Assurance). -->
            <sdg:LevelOfAssurance>High</sdg:LevelOfAssurance>

            <!-- eIDAS Identifier: MUST have the format XX/YY/ZZZZZZZ where XX is the Nationality Code of the identifier and YY is the Nationality Code of the destination country and ZZZZZZZ is an undefined combination of characters which uniquely identifies the identity asserted in the country of origin. The values of XX and YY MUST be part of the code list 'CountryIdentificationCode' (ISO 3166-1' alpha-2 codes). Example: ES/AT/02635542Y.  -->
            <!-- The 'schemeID' attribute of the 'Identifier' MUST have the fixed value 'eidas'.  -->
            <sdg:Identifier schemeID="eidas">EL/BE/12313132</sdg:Identifier>

            <!-- eIDAS Mandatory Attributes of the Minimum Data Set -->
            <sdg:FamilyName>Doe</sdg:FamilyName>
            <sdg:GivenName>John</sdg:GivenName>
            <!-- The value of 'DateOfBirth' MUST use the following format YYYY + “-“ + MM + “-“ + DD (as defined for xsd:date)  -->
            <sdg:DateOfBirth>1978-09-09</sdg:DateOfBirth>

            <!-- eIDAS Optional Attributes of the Minimum Data Set -->
            <sdg:BirthName>Jonathan Doepidis</sdg:BirthName>
            <sdg:PlaceOfBirth>Athens</sdg:PlaceOfBirth>
            <sdg:CurrentAddress >
                <sdg:FullAddress>Panepistimou 5, 85101 Athens, Greece</sdg:FullAddress>
                <sdg:LocatorDesignator>5</sdg:LocatorDesignator>
                <sdg:PostCode>85101</sdg:PostCode>
                <sdg:PostCityName>Athens</sdg:PostCityName>
                <sdg:Thoroughfare>Panepistimou</sdg:Thoroughfare>
                <!-- The value of the 'AdminUnitLevel1' MUST be coded using the code list 'CountryIdentificationCode' (ISO 3166-1' alpha-2 codes).  -->
                <sdg:AdminUnitLevel1>GR</sdg:AdminUnitLevel1>
                <!-- The value of the 'AdminUnitLevel2' MUST be coded using the code list 'NUTS' (Nomenclature of Territorial Units for Statistics).  -->
                <sdg:AdminUnitLevel2>EL3</sdg:AdminUnitLevel2>
            </sdg:CurrentAddress>
            <sdg:Gender>Male</sdg:Gender>

            <!-- Optional Sector Specific Attributes not belonging to the Minimum Data Set -->             
			<sdg:SectorSpecificAttribute>
                <sdg:AttributeName>Residency-ID</sdg:AttributeName>
                <sdg:AttributeURI>http://eidas.europa.eu/attributes/naturalperson/location/Residency-ID</sdg:AttributeURI>
                <sdg:AttributeValue>INGTTTFYYY</sdg:AttributeValue>
            </sdg:SectorSpecificAttribute> 
        
		</sdg:Person>
    </rim:SlotValue>
</rim:Slot>  

3.6.2 Legal Person slot and example

A business that is legally registered acting as Data Subject described along the Core Business Vocabulary (https://semiceu.github.io/Core-Business-Vocabulary/releases/2.00/)

The LegalPerson slot contains data that describes the Legal Person (a.k.a. a Company) that submits this request. When using an ISA Core Busines Vocabulary for representing the value of a slot, AnyValueType is used as its type since it allows data in XML form to be used as the slot's value.  The slot follows the structure of eIDAS attributes containing mandatory and optional attributes of the Minimum Data Set and Sector Specific Attributes, where applicable. 

The value of  schemeID  attribute of the Identifier  MUST have be part of the code list 'IdentifierSchemes' (eIDAS Legal Person Identifier Schemes like VAT, TAX, Business Codes). It is part of the optional attributes of the Minimum Data Set.

The value for LevelOfAssurance  for the Minimum Data Set (MDS) must be part of the code list 'LoA' (eIDAS Levels Of Assurance). 

The value of Identifier  MUST have the format XX/YY/ZZZZZZZ where XX is the Nationality Code of the identifier and YY is the Nationality Code of the destination country and ZZZZZZZ is an undefined combination of characters which uniquely identifies the identity asserted in the country of origin. The values of XX and YY MUST be part of the code list 'CountryIdentificationCode' (ISO 3166-1' alpha-2 codes). Example: ES/AT/02635542Y. It is part of the mandatory attributes of the Minimum Data Set.

The value of the AdminUnitLevel1  MUST be coded using the code list 'CountryIdentificationCode' (ISO 3166-1' alpha-2 codes).

The value of the AdminUnitLevel2  MUST be coded using the code list 'NUTS' (Nomenclature of Territorial Units for Statistics).

 <!-- LegalPerson Slot  -->
<rim:Slot name="LegalPerson">
    <rim:SlotValue xsi:type="rim:AnyValueType">
        <sdg:LegalPerson>
            <!-- Level of Assurance for the Minimum Data Set (MDS). The value of 'LevelOfAssurance' must be part of the code list 'LoA' (eIDAS Levels Of Assurance). --> -->
            <sdg:LevelOfAssurance>High</sdg:LevelOfAssurance>
            <!-- Optional Attribute of the Minimum Data Set -->
            <!-- The 'schemeID' attribute of the 'Identifier' MUST have be part of the code list 'IdentifierSchemes' (eIDAS Legal Person Identifier Schemes like VAT, TAX, Business Codes). -->
            <sdg:Identifier schemeID="Tax">113123123123123</sdg:Identifier>
            <sdg:Identifier schemeID="VAT">SE730757727</sdg:Identifier>
            <!-- eIDAS Mandatory Attributes of the Minimum Data Set -->
            <!-- eIDAS Identifier: MUST have the format XX/YY/ZZZZZZZ where XX is the Nationality Code of the identifier and YY is the Nationality Code of the destination country and ZZZZZZZ is an undefined combination of characters which uniquely identifies the identity asserted in the country of origin. The values of XX and YY MUST be part of the code list 'CountryIdentificationCode' (ISO 3166-1' alpha-2 codes). Example: ES/AT/02635542Y.  -->
            <!-- The 'schemeID' attribute of the 'Identifier' MUST have the fixed value 'eidas'.  -->
            <sdg:LegalPersonIdentifier schemeID="eidas">ES/SE/12132123Y</sdg:LegalPersonIdentifier>
            <sdg:LegalName>AnyCompanyName</sdg:LegalName>

            <!-- Optional Attributes of the Minimum Data Set. -->
            <sdg:RegisteredAddress>
                <sdg:FullAddress>Prince Street 15, 11121 Stockholm, Sweden</sdg:FullAddress>
                <sdg:LocatorDesignator>15</sdg:LocatorDesignator>
                <sdg:PostCode>11121</sdg:PostCode>
                <sdg:PostCityName>Stockholm</sdg:PostCityName>
                <sdg:Thoroughfare>PrinceStreet</sdg:Thoroughfare>
			    <!-- The value of the 'AdminUnitLevel1' MUST be coded using the code list 'CountryIdentificationCode' (ISO 3166-1' alpha-2 codes).  -->
                <sdg:AdminUnitLevel1>SE</sdg:AdminUnitLevel1>
			    <!-- The value of the AdminUnitLevel2  MUST be coded using the code list 'NUTS' (Nomenclature of Territorial Units for Statistics). -->
                <sdg:AdminUnitLevel2>SE11</sdg:AdminUnitLevel2>
            </sdg:RegisteredAddress>

            <!-- Optional Sector Specific Attributes not belonging to the Minimum Data Set -->
            <sdg:SectorSpecificAttribute>
                <sdg:AttributeName>IBAN</sdg:AttributeName>
                <sdg:AttributeURI>http://eidas.europa.eu/attributes/legalperson/banking/IBAN</sdg:AttributeURI>
                <sdg:AttributeValue>SE02500105170137075032</sdg:AttributeValue>
            </sdg:SectorSpecificAttribute>
            <sdg:SectorSpecificAttribute>
                <sdg:AttributeName>BIC</sdg:AttributeName>
                <sdg:AttributeURI>http://eidas.europa.eu/attributes/legalperson/banking/BIC</sdg:AttributeURI>
                <sdg:AttributeValue>INGDDEFFYYY</sdg:AttributeValue>
            </sdg:SectorSpecificAttribute>
        </sdg:LegalPerson>
    </rim:SlotValue>
</rim:Slot>

3.6.3 Authorized Representative slot and example

An optional Authorized Representative may also be defined. The Authorized Representative is a Person acting on behalf of the Evidence Subject being either a legaly registered business or a natural person to trigger the evidence requester's request for evidence. It may contain the power of representation scope of a representative person representing a different represented person  retrieved during eIDAS authentication of the user to the Online Procedure Portal or Intermediary Platform (see chapter 2.3 and descriptions below). The Authorized Representative is described along the Core Person Vocabulary (https://semiceu.github.io/Core-Person-Vocabulary/releases/2.00/#Person). 

The AuthorizedRepresentative slot contains data that describes the Legal Representative of a company or a person. This slot is optional and may be used for expressing the representative of  either a LegalPerson or a NaturalPerson slot. When using an ISA Core Vocabulary for representing the value of a slot, AnyValueType is used as its type since it allows data in XML format to be used as the slot's value. The slot follows the structure of eIDAS attributes containing mandatory and optional attributes of the Minimum Data Set and Sector Specific Attributes, where applicable. 

The value for LevelOfAssurance  for the Minimum Data Set (MDS) must be part of the code list 'LoA' (eIDAS Levels Of Assurance).

The value of Identifier  MUST have the format XX/YY/ZZZZZZZ where XX is the Nationality Code of the identifier and YY is the Nationality Code of the destination country and ZZZZZZZ is an undefined combination of characters which uniquely identifies the identity asserted in the country of origin. The values of XX and YY MUST be part of the code list 'CountryIdentificationCode' (ISO 3166-1' alpha-2 codes). Example: ES/AT/02635542Y.

The value of DateOfBirth  MUST use the following format YYYY + “-“ + MM + “-“ + DD (as defined for xsd:date).

The value of the AdminUnitLevel1  MUST be coded using the code list 'CountryIdentificationCode' (ISO 3166-1' alpha-2 codes).

The value of the AdminUnitLevel2  MUST be coded using the code list 'NUTS' (Nomenclature of Territorial Units for Statistics).

To express the power of representation scope of a representative person representing a different represented person, the sector specific "PowerOfRepresentationScope" attribute may be available from the eIDAS authentication of the user to the Online Procedure Portal or Intermediary Platform. If available from eIDAS, the attribute MUST be included to the sdg:SectorSpecificAttribute of the rim:slot "AuthorizedRepresentative  in the evidence request. The attribute MUST NOT be used in the case of evidence requests not involving representation. 

The sdg:AttributeName MUST be PowerOfRepresentationScope and use the sdg:AttributeURI   http://data.europa.eu/p4s/attributes/PowerOfRepresentationScope

The semantics of the sdg:AttributeValue MUST be one of the following:

1. The fixed value "ALL",  meaning the representative person has power of representation for the represented person in the context of all SDG procedures in the request context.
2. A code value from the SDG Procedure code list publicly available at the OOTS repository, meaning the representative person has power of representation for the represented person in the specified SDG procedure in the request context.
3. A comma-separated list of code values from the SDG Procedure code list, meaning the representative has power of representation in all the specified SDG procedures  in the request contex.

The example below illustrates the use of the rim:slot "AuthorizedRepresentative and an associated sdg:SectorSpecificAttribute for powers of representation scope of an authorized representative.

<!--  AuthorizedRepresentative Slot. Both LegalPerson and NaturalPerson can have an AuthorizedRepresentative (optional 0..1)-->
<rim:Slot name="AuthorizedRepresentative">
    <rim:SlotValue xsi:type="rim:AnyValueType">
        <!--     Core Person Vocabulary (CPV) Expression of the LegalRepresentative -->
        <sdg:Person>

            <!-- eIDAS Identifier: MUST have the format XX/YY/ZZZZZZZ where XX is the Nationality Code of the identifier and YY is the Nationality Code of the destination country and ZZZZZZZ is an undefined combination of characters which uniquely identifies the identity asserted in the country of origin. The values of XX and YY MUST be part of the code list 'CountryIdentificationCode' (ISO 3166-1' alpha-2 codes). Example: ES/AT/02635542Y.  -->
            <!-- The 'schemeID' attribute of the 'Identifier' MUST have the fixed value 'eidas'.  -->
            <sdg:LevelOfAssurance>High</sdg:LevelOfAssurance>

            <!-- eIDAS Mandatory Attributes of the Minimum Data Set -->
            <sdg:Identifier schemeID="eidas">GR/BE/12313132</sdg:Identifier>
            <sdg:FamilyName>Doe</sdg:FamilyName>
            <sdg:GivenName>John</sdg:GivenName>
            <!-- The value of 'DateOfBirth' MUST use the following format YYYY + “-“ + MM + “-“ + DD (as defined for xsd:date)  -->
            <sdg:DateOfBirth>1978-09-09</sdg:DateOfBirth>

            <!-- eIDAS Optional Attributes of the Minimum Data Set -->
            <sdg:BirthName>Jonathan Doepidis</sdg:BirthName>
            <sdg:PlaceOfBirth>Athens</sdg:PlaceOfBirth>
            <sdg:CurrentAddress >
                <sdg:FullAddress>Panepistimou 5, 85101 Athens, Greece</sdg:FullAddress>
                <sdg:LocatorDesignator>5</sdg:LocatorDesignator>
                <sdg:PostCode>85101</sdg:PostCode>
                <sdg:PostCityName>Athens</sdg:PostCityName>
                <sdg:Thoroughfare>Panepistimou</sdg:Thoroughfare>
                <!-- The value of the 'AdminUnitLevel1' MUST be coded using the code list 'CountryIdentificationCode' (ISO 3166-1' alpha-2 codes).  -->
                <sdg:AdminUnitLevel1>GR</sdg:AdminUnitLevel1>
                <!-- The value of the 'AdminUnitLevel2' MUST be coded using the code list 'NUTS' (Nomenclature of Territorial Units for Statistics).  -->
                <sdg:AdminUnitLevel2>EL3</sdg:AdminUnitLevel2>
            </sdg:CurrentAddress>
            <sdg:Gender>Male</sdg:Gender>

            <!-- Optional Sector Specific Attributes not belonging to the Minimum Data Set -->
            <!-- Sector Specific Attribute Power of Representation Scope retrieved from the eIDAS authentication of the user to the Online Procedure Portal or Intermediary Platform. In this example Power of Representation is associated to "ALL" SDG procedures. Attribute Value may also contain only one procedure e.g. T1 or comma-separated list of code values "T1, T2, S1" from the SDG Procedure code list -->
            <sdg:SectorSpecificAttribute>
                <sdg:AttributeName>PowerOfRepresentationScope</sdg:AttributeName>
                <sdg:AttributeURI>http://data.europa.eu/p4s/attributes/PowerOfRepresentationScope</sdg:AttributeURI>
                <sdg:AttributeValue>All</sdg:AttributeValue>
            </sdg:SectorSpecificAttribute>

        </sdg:Person>
    </rim:SlotValue>
</rim:Slot>