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.2" for this value of the OOTS technical specifications;
• 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 has given his or her explicit requests for the evidence exchange;
• 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 attribute 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 includes 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 code list.  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.2. The SpecificationIdentifier must match with the ConformsTo statement of the Access Service that has been chosen by the Evidence Requester during the DSD Query Process and to which the Evidence Request will be addressed. 

<!-- SpecificationIdentifier Slot -->
    <rim:Slot name="SpecificationIdentifier">
        <rim:SlotValue xsi:type="rim:StringValueType">
            <!-- MUST be the fixed value "oots-edm:v1.2" for TDD version 1.2 -->
            <rim:Value>oots-edm:v1.2</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  the code list 'LanguageCode'. The default choice is "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', Default choice "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 successful 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 executed 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://'. Note that in RIM, the rim:Value for an element of type rim:StringValueType is of type rim:LongText which has a length limit of 256 characters. 

<!-- 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 there is no requirement to give the user the option to preview the provided evidence. The flag is set by the ER, when such an exemption is required for the execution of the specific procedure. It must be formatted 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 or her explicit request, while when its value is false, then the user has not provided his or her 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 formatted 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. -->
                <sdg:Identifier>https://sr.oots.tech.ec.europa.eu/requirements/315cfd75-6605-49c4-b0fe-799833b41099</sdg:Identifier>
                <!-- MUST be part of the code list 'LanguageCode' Default choice "EN".  -->
                <sdg:Name lang="EN">Proof of Birth</sdg:Name>
                <sdg:Name lang="DE">Geburtsnachweis</sdg:Name>
                <sdg:Description lang="EN">Request for evidence regarding the birth of the person (evidence subject).</sdg:Name>
                <sdg:Description lang="DE">Ersuchen um Nachweise über die Geburt der Person (Nachweissubjekt).</sdg: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 not extend 256 characters and it MUST use either the prefix 'urn:cef.eu:names:identifier:EAS:[Code]' and a code being part of the code list 'EAS' (Electronic Address Scheme ) OR the prefix 'urn:oasis:names:tc:ebcore:partyid-type:unregistered:[Code]' and a code being part of the code list ‘ISO 3166-1 alpha-2 country code (EEA_country subset)’.

The value of lang  attribute of the Name MUST be part of the code list 'LanguageCode'. Default choice "EN". 

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" collectionType="urn:oasis:names:tc:ebxml-regrep:CollectionType:Set">
            <rim:Element xsi:type="rim:AnyValueType">
                <sdg:Agent>
                    <!-- 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 ‘ISO 3166-1 alpha-2 country code (EEA_country subset)’. -->
                    <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'. Default choice "EN".  -->
                    <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 information about the Evidence Provider is retrieved from the Query Response of the Data Service Directory. The Query Response of the Data Service Directory thereby distinguishes between the Access Service, the Corner 3 or Access Point, to which the Evidence Request must be sent and the Publisher who will receive the Evidence Request. The Publisher information shall be adopted in the Evidence Provider slot of the Evidence Request. It is the final recipient or corner 4 to which the Evidence Request in finally sent to retrieve the Evidence. It must be an Evidence Provider associated to the DataServiceEvidenceType  that is referenced by the Evidence Request. The identifier of the Access Service is only used in the ebMS header as an address (eb:To) (see section 4.7).

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 not extend 256 characters and it MUST either use the prefix 'urn:cef.eu:names:identifier:EAS:[Code]' and a code being part of the code list 'EAS' (Electronic Address Scheme ) OR the prefix 'urn:oasis:names:tc:ebcore:partyid-type:unregistered:[Code]' and a code being part of the code list ‘ISO 3166-1 alpha-2 country code (EEA_country subset)’.  

The value of lang  attribute of the Name  MUST be part of the code list 'LanguageCode'. Default choice "EN". 

<!-- EvidenceProvider Slot  -->
<rim:Slot name="EvidenceProvider">
    <rim:SlotValue xsi:type="rim:AnyValueType">
        <sdg:Agent>
            <!-- 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 ‘ISO 3166-1 alpha-2 country code (EEA_country subset)’. -->
            <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'. Default choice "EN".  -->
            <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 document the information provided 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.

  <!-- EvidenceProviderClassification Slot  -->
   <rim:Slot name="EvidenceProviderClassification">
       <rim:SlotValue xsi:type="rim:CollectionValueType" collectionType="urn:oasis:names:tc:ebxml-regrep:CollectionType:Set">
           <!-- Classification Information - User provided input during the DSD query process for discovery of the Evidence Provider -->
           <rim:Element xsi:type="rim:AnyValueType">
            <!-- Determination of the capabilities of the Evidence Provider based on user selection of appropriate values. In this example, the user has selected the city of birth to find the appropriate Evidence Provider -->
            <sdg:EvidenceProviderClassification>
              <!-- The Identifer must be a version 4 UUID. The schemeID points to the appropriate MS-specific classification scheme "Lau2022" from Germany. -->
              <sdg:Identifier schemeID="https://sr.oots.tech.ec.europa.eu/codelists/DE/Lau2022">5ce148b9-5578-4049-aecf-af7bb55714b5</sdg:Identifier>
              <!-- For MS-specific classification schemes the value "codelist" must be provided -->
              <sdg:Type>codelist</sdg:Type>
              <!-- The URI of the ValueExpression returns the applied values that are used across all DSD entries for the requested DataServiceEvidenceType. -->
              <!-- The returned format follows the agreed Genericode format for MS-specific classification schemes (see section 3.5 of the TDDs).-->
              <!-- In this example, the <SimpleCodeList> of Genericode is narrowed down to 2 cities (applied values “11000000” for Berlin and “02000000” for Hamburg) since no other German Evidence Providers are registered for Birth Certificate provision in the DSD yet. -->
              <!-- Note: The URI has been calculated during the DSD query and can change at any time. Thus, the lifespan of the URI is therefore limited to the DSD request and is only stored by the DSD for a short period. -->
              <sdg:ValueExpression>https://query.cs.uat.oots.tech.ec.europa.eu/dsd/rest/codelists/DE/Lau2022/a591a6d40bf420404a011733cfb7b190d62c65bf0bcdaed6d9a38b8a212f2e3d
              </sdg:ValueExpression>
              <!-- The Question that shall be raised to the user -->
              <sdg:Description lang="EN">Select the city in which you were born.
              </sdg:Description>
              <sdg:Description lang="DE">Wählen Sie die Stadt in der Sie geboren wurden.</sdg:Description>
              <!-- This Evidence Provider (Civil Registration Office Berlin I) can provide Birth Certificates for users that were born in Berlin -->
              <sdg:SupportedValue>
                <sdg:StringValue>11000000</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 core information about the DataServiceEvidenceType is adopted from the relevant DSD query response. It must be noted here that not all information of the DataServiceEvidenceType from the DSD query response must be included in the evidence request; the "AuthenticationLevelOfAssurance" and "Note" elements are omitted. This information is only intended for the DSD query response. 

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 during the DSD query process. Thus, the DataServiceEvidenceType is adopted from the QueryResponse of the Data Services Directory but the "AuthenticationLevelOfAssurance" and "Note" elements are omitted . The DataServiceEvidenceType 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/datamodels/[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/datamodels/[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 ‘ISO 3166-1 alpha-2 country code (EEA_country subset)’ using the prefix and scheme ''https://sr.oots.tech.ec.europa.eu/evidencetypeclassifications/[EEA_country]/[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 codelist 'LanguageCode'. Default choice "EN". -->
            <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/datamodels/[DataModelScheme]".-->
               <sdg:ConformsTo>https://sr.oots.tech.ec.europa.eu/datamodels/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/datamodels/[DataModelScheme]/[Subset]"-->
               <sdg:Transformation>https://sr.oots.tech.ec.europa.eu/datamodels/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 examples

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 that can be either a natural person or a legal person. The Authorized Representative is a natural person or legal 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 different types of eIDAS attributes covered by the slots "NaturalPerson", "LegalPerson" and "AuthorizedRepresentative":

Types of attributes exchanged using eIDAS

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.

Common attributes

eIDAS common attributes for both natural and legal persons extend the attributes of the Minimum Data Set on the basis of the corresponding Core Vocabularies.

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).

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 (natural/legal) 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) and rim:Slot "AuthorizedRepresentativeLegalRepresentative" (see chapter 2.3 and descriptions in section 3.6.4 of Authorized Represenative Legal Person slot and example).

Absence of the SectorSpecificAttribute "PowerOfRepresentationScope" means full powers.

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  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 ‘ISO 3166-1 alpha-2 country code (EEA_country subset)’. Example: ES/AT/02635542Y.

The value of DateOfBirth  MUST use the following format YYYY + “-“ + MM + “-“ + DD.

The values for Nationality , CountryOfBirth , CountryOfResidence  and AdminUnitLevel1  MUST be coded using the code list 'CountryIdentificationCode' (ISO 3166-1' alpha-2 codes).

<!-- 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  ‘ISO 3166-1 alpha-2 country code (EEA_country subset)’. 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 nonLatin="Ντόε">Doe</sdg:FamilyName>
            <sdg:GivenName nonLatin="Γιάννης">John</sdg:GivenName>
            <!-- The value of 'DateOfBirth' MUST use the following format YYYY + “-“ + MM + “-“ + DD.  -->
            <sdg:DateOfBirth>1978-09-09</sdg:DateOfBirth>

            <!-- eIDAS Optional Attributes of the Minimum Data Set -->
            <sdg:BirthName nonLatin="Ιωνάθαν Δουπίδης">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>EL</sdg:AdminUnitLevel1>
                <sdg:AdminUnitLevel2>EL3</sdg:AdminUnitLevel2>
            </sdg:CurrentAddress>
            <sdg:Gender>Male</sdg:Gender>

            <!-- eIDAS common attributes -->
            <!-- Nationality MUST be coded using the code list 'CountryIdentificationCode' (ISO 3166-1' alpha-2 codes).  -->
            <sdg:Nationality>EL</sdg:Nationality>
            <!-- CountryOfBirth MUST be coded using the code list 'CountryIdentificationCode' (ISO 3166-1' alpha-2 codes).  -->
            <sdg:CountryOfBirth>EL</sdg:CountryOfBirth>
            <sdg:TownOfBirth>Athens</sdg:TownOfBirth>
            <!-- CountryOfResidence MUST be coded using the code list 'CountryIdentificationCode' (ISO 3166-1' alpha-2 codes).  -->
            <sdg:CountryOfResidence>EL</sdg:CountryOfResidence>
            <sdg:PhoneNumber>+34912739000</sdg:PhoneNumber>
            <sdg:EmailAddress>john.doe@mail.com</sdg:EmailAddress>
        </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  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 ‘ISO 3166-1 alpha-2 country code (EEA_country subset)’. 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).

<!-- 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  ‘ISO 3166-1 alpha-2 country code (EEA_country subset)’. 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>
                <sdg:AdminUnitLevel2>SE11</sdg:AdminUnitLevel2>
            </sdg:RegisteredAddress>

            <!-- eIDAS common attributes -->
            <sdg:LegalPhoneNumber>+34912739000</sdg:LegalPhoneNumber>
            <sdg:LegalEmailAddress>company@mail.com</sdg:LegalEmailAddress>
        </sdg:LegalPerson>
    </rim:SlotValue>
</rim:Slot>

3.6.3 Authorized Representative slot and example

An optional Authorized Representative may also be defined either for natural person or legal person. The slot "AuthorizedRepresentative" is dedicated for a Natural 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. 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  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 ‘ISO 3166-1 alpha-2 country code (EEA_country subset)’. Example: ES/AT/02635542Y.

The value of DateOfBirth  MUST use the following format YYYY + “-“ + MM + “-“ + DD.

The values for Nationality , CountryOfBirth , CountryOfResidence  and AdminUnitLevel1  MUST be coded using the code list 'CountryIdentificationCode' (ISO 3166-1' alpha-2 codes).

To express the power of representation scope of a representative person representing a different represented (legal/natural) 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. Absence of the SectorSpecificAttribute "PowerOfRepresentationScope" means full powers. 

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

The sdg:AttributeValue MUST use a code value from the SDG Procedure code list publicy available at the OOTS repository, meaning the representative person has power of representation for the represented (legal/natural) person in the specified SDG procedure that should match with the procedure context declared in the Evidence Request slot "Procedure". Single value or comma-separated values from SDG Procedure code list are allowed.

The example below illustrates the use of the rim:slot "AuthorizedRepresentative" and an associated sdg:SectorSpecificAttribute for powers of representation scope for that 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 ‘ISO 3166-1 alpha-2 country code (EEA_country subset)’. 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:FamilyName nonLatin="Ντόε">Doe</sdg:FamilyName>
            <sdg:GivenName nonLatin="Γιάννης">John</sdg:GivenName>
            <!-- The value of 'DateOfBirth' MUST use the following format YYYY + “-“ + MM + “-“ + DD.  -->
            <sdg:DateOfBirth>1978-09-09</sdg:DateOfBirth>

            <!-- eIDAS Optional Attributes of the Minimum Data Set -->
            <sdg:BirthName nonLatin="Ιωνάθαν Δουπίδης">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>EL</sdg:AdminUnitLevel1>
                <sdg:AdminUnitLevel2>EL3</sdg:AdminUnitLevel2>
            </sdg:CurrentAddress>
            <sdg:Gender>Male</sdg:Gender>

			<!-- eIDAS common attributes -->
            <!-- Nationality MUST be coded using the code list 'CountryIdentificationCode' (ISO 3166-1' alpha-2 codes).  -->
            <sdg:Nationality>EL</sdg:Nationality>
            <!-- CountryOfBirth MUST be coded using the code list 'CountryIdentificationCode' (ISO 3166-1' alpha-2 codes).  -->
            <sdg:CountryOfBirth>EL</sdg:CountryOfBirth>
            <sdg:TownOfBirth>Athens</sdg:TownOfBirth>
            <!-- CountryOfResidence MUST be coded using the code list 'CountryIdentificationCode' (ISO 3166-1' alpha-2 codes).  -->
            <sdg:CountryOfResidence>EL</sdg:CountryOfResidence>
            <sdg:PhoneNumber>+34912739000</sdg:PhoneNumber>
            <sdg:EmailAddress>john.doe@mail.com</sdg:EmailAddress>

            <!-- Optional Sector Specific Attributes not belonging to the Minimum Data Set. It MUST be included if received from eIDAS -->
            <!-- Sector Specific Attribute Power of Representation Scope retrieved from the eIDAS authentication of the user to the Online Procedure Portal or Intermediary Platform for a specific procedure. In this example Power of Representation is associated to the T1 procedure from the SDG Procedure code list -->
  			<!-- Single value or comma-separated values from SDG Procedure code list are allowed. -->
            <sdg:SectorSpecificAttribute>
                <sdg:AttributeName>PowerOfRepresentationScope</sdg:AttributeName>
                <sdg:AttributeURI>http://data.europa.eu/p4s/attributes/PowerOfRepresentationScope</sdg:AttributeURI>
                <sdg:AttributeValue>T1</sdg:AttributeValue>
            </sdg:SectorSpecificAttribute>

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

3.6.4 Authorized Representative Legal Person slot and example

An optional Authorized Representative may also be defined either for natural person or legal person. The slot "AuthorizedRepresentativeLegalPerson" is dedicated for Legal 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. 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 Legal Person is described along 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  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 ‘ISO 3166-1 alpha-2 country code (EEA_country subset)’. 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).

To express the power of representation scope of a representative person representing a different represented (legal/natural) 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 "AuthorizedRepresentativeLegalPerson"  in the evidence request. The attribute MUST NOT be used in the case of evidence requests not involving representation. Absence of the SectorSpecificAttribute "PowerOfRepresentationScope" means full powers. 

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

The sdg:AttributeValue MUST use 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 (legal/natural) person in the specified SDG procedure that should match with the procedure context declared in the Evidence Request slot "Procedure". Single value or comma-separated values from SDG Procedure code list are allowed.

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

<!-- Authorized Representative Legal Person Slot  -->
<rim:Slot name="AuthorizedRepresentativeLegalPerson">
    <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  ‘ISO 3166-1 alpha-2 country code (EEA_country subset)’. 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>
                <sdg:AdminUnitLevel2>SE11</sdg:AdminUnitLevel2>
            </sdg:RegisteredAddress>

            <!-- eIDAS common attributes -->
            <sdg:LegalPhoneNumber>+34912739000</sdg:LegalPhoneNumber>
            <sdg:LegalEmailAddress>company@mail.com</sdg:LegalEmailAddress>

            <!-- Optional Sector Specific Attributes not belonging to the Minimum Data Set. It MUST be included if received from eIDAS -->
            <!-- Sector Specific Attribute Power of Representation Scope retrieved from the eIDAS authentication of the user to the Online Procedure Portal or Intermediary Platform for a specific procedure. In this example Power of Representation is associated to the T1 procedure from the SDG Procedure code list -->
		    <!-- Single value or comma-separated values from SDG Procedure code list are allowed. -->
            <sdg:SectorSpecificAttribute>
                <sdg:AttributeName>PowerOfRepresentationScope</sdg:AttributeName>
                <sdg:AttributeURI>http://data.europa.eu/p4s/attributes/PowerOfRepresentationScope</sdg:AttributeURI>
                <sdg:AttributeValue>T1</sdg:AttributeValue>
            </sdg:SectorSpecificAttribute>

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