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.

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 "PossibilityForPreview" to declare the intention of the Evidence Requester to allow the user to preview the Evidence to be received from the Evidence Provider;
• the "ExplicitRequestGiven" to indicate the user consent to request the evidence;
• 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 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" 
	id="urn:uuid:c4369c4d-740e-4b64-80f0-7b209a66d629">
 
    <!-- 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 design documentation, this MUST be set to the value “oots-edm:v1.0”

<!-- SpecificationIdentifier Slot -->
    <rim:Slot name="SpecificationIdentifier">
        <rim:SlotValue xsi:type="rim:StringValueType">
            <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 referred document. 

Α Slot with the name "IssueDateTime" is used with the ValueType of DateTimeValueType which has an ISO timestamp value.

   <!-- IssueDateTime Slot -->
    <rim:Slot name="IssueDateTime">
        <rim:SlotValue xsi:type="rim:DateTimeValueType">
            <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 must be specified using ISO 639-1 two-letter code. 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>
            <rim:LocalizedString
                value="Requesting a birth certificate"
                xml:lang="en"/>
        </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. 

Α Slot with the name of "PreviewLocation" is used with the ValueType of StringValueType which has the value of a URI.

   <!-- PreviewLocation Slot -->
    <rim:Slot name="PreviewLocation">
        <rim:SlotValue xsi:type="rim:StringValueType">
            <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 declare the intention of the Evidence Requester to allow the user to preview the Evidence to be received from the Evidence Provider. When its value is true, then the user will be able to preview, if desired, the provided evidence. When 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. The following example depicts the use of the slot.

   <!-- PossibilityForPreview Slot  -->
    <rim:Slot name="PossibilityForPreview">
        <rim:SlotValue xsi:type="rim:BooleanValueType">
            <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 is set by the ER, when such an exemption is required for the execution of the specific procedure. The following example depicts the use of the slot.

   <!-- ExplicitRequestGiven Slot  -->
    <rim:Slot name="ExplicitRequestGiven">
        <rim:SlotValue xsi:type="rim:BooleanValueType">
            <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 requirement 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.

 <!-- 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>
				<!--  cccev requirement -->
		 		<Identifier>315cfd75-6605-49c4-b0fe-799833b41099</Identifier>
         		<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. 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. 

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 CollectionValueType Slot as a container can hold information about EvidenceRequester and Intermediaries.

<!-- EvidenceRequester Slot  -->      
<rim:Slot name="EvidenceRequester">
        <rim:SlotValue xsi:type="rim:CollectionValueType">
        	<rim:Element xsi:type="rim:AnyValueType">
            	<sdg:Agent>
					<sdg:Identifier schemeID="urn:cef.eu:names:identifier:EAS:0096">DK22233223</sdg:Identifier>
					<sdg:Name lang="en">Denmark University Portal</sdg:Name>
					<sdg:Address>
                    	<sdg:FullAddress>Prince Street 15</sdg:FullAddress>
						<sdg:LocatorDesignator>15</sdg:LocatorDesignator>
						<sdg:PostCode>1050</sdg:PostCode>
                    	<sdg:PostCityName>Copenhagen</sdg:PostCityName>
                    	<sdg:AdminUnitLevel1>Denmark</sdg:AdminUnitLevel1>
						<sdg:AdminUnitLevel2>DK011</sdg:AdminUnitLevel2>
                	</sdg:Address>
				 	<sdg:Classification>IntermediaryPlatform</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.

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 and more specifically the Agent Class.

<!-- EvidenceProvider Slot  -->      
<rim:Slot name="EvidenceProvider">
	<rim:SlotValue xsi:type="rim:AnyValueType">
		<sdg:Agent>
			<sdg:Identifier schemeID="urn:cef.eu:names:identifier:EAS:9930">DE73524311</sdg:Identifier>
			<sdg:Name>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. 

The SupportedValue class is used for the expression of these values inside the AnyValueType slot EvidenceProviderClassification. 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>
					<sdg:Identifier>SecondarySchool</sdg:Identifier>
					<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>
					<sdg:Identifier>YearOfGraduation</sdg:Identifier>
					<sdg:SupportedValue>
						<sdg:StringValue>1988</sdg:StringValue>
					</sdg:SupportedValue>
				</sdg:EvidenceProviderClassification>
			</rim:Element>
		</rim:SlotValue>
	</rim:Slot>

3.5 Evidence Request slot and example

Element to request for a piece of evidence to the Data Service of an Evidence Provider. The elements provide a complete semantic description required to point to the correct evidence type and format. 

The EvidenceRequest Slot has a SlotValue of type AnyValueType. It contains a DataServiceEvidenceType, containing one Distribution class as defined by the SDG AP. This class must specify the Identifier of the Evidence type and Data Service Evidence Type requested together with one distribution containing the format and the conformance profile requested when applicable (e.g. when evidence is structured), as it comes from the Data Services Directory.

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 URI. The transformation itself is defined in the Semantic Repository along a corresponding conformance profile. A transformation could be 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 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>
			<!-- This is the ID that is fetched from the Data Services Directory -->
            <Identifier>2af27699-f131-4411-8fdb-9e8cd4e8bded</Identifier>

		 	<!-- Classification Information - Used for linking with the Semantic Repository and Evidence Broker -->	
            <EvidenceTypeClassification>CertificateOfBirth</EvidenceTypeClassification>
            <Title lang="en">Certificate of Birth</Title>
		    <Title lang="de">Geburtsurkunde</Title>
   			<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.</Description>
			<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.</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--> 
            <DistributedAs>
                <Format>application/pdf</Format>
			 	<ConformsTo>https://semic.org/sa/common/birthcert-1.0.0</ConformsTo>
                <Transformation>https://semic.org/sa/transformations/birthcert-1.0.0/age-of-majority</Transformation>
            </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 and NaturalPerson, 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 and NaturalPerson 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. 

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 NaturalPerson slot 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. 

<!-- NaturalPerson Slot  --> 
<rim:Slot name="NaturalPerson">
    <rim:SlotValue xsi:type="rim:AnyValueType">   
        <sdg:Person>
            <!-- Level of Assurance for the Minimum Data Set (MDS) -->
            <LevelOfAssurance>High</LevelOfAssurance>

            <!-- eIDAS Identifier -->
            <Identifier schemeID="eidas">EL/BE/12313132</Identifier>

            <!-- eIDAS Mandatory Attributes of the Minimum Data Set -->
            <FamilyName>Doe</FamilyName>
            <GivenName>John</GivenName>
            <DateOfBirth>1978-09-09</DateOfBirth>

            <!-- eIDAS Optional Attributes of the Minimum Data Set -->
            <BirthName>Jonathan Doepidis</BirthName>     
            <PlaceOfBirth>Athens</PlaceOfBirth>                
            <CurrentAddress >
                <FullAddress>Panepistimou 5, 85101, Athens</FullAddress>
                <AdminUnitLevel1>GR</AdminUnitLevel1>
            </CurrentAddress>
            <Gender>Male</Gender>

            <!-- Optional Sector Specific Attributes not belonging to the Minimum Data Set -->
            <SectorSpecificAttribute>
                <AttributeName>IBAN</AttributeName>
                <AttributeURI>http://eidas.europa.eu/attributes/naturalperson/banking/IBAN</AttributeURI>
                <AttributeValue>DE02500105170137075032</AttributeValue>
            </SectorSpecificAttribute>
            <SectorSpecificAttribute>
                <AttributeName>BIC</AttributeName>
                <AttributeURI>http://eidas.europa.eu/attributes/naturalperson/banking/BIC</AttributeURI>
                <AttributeValue>INGDDEFFYYY</AttributeValue>
            </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. 

 <!-- LegalPerson Slot  -->    
<rim:Slot name="LegalPerson">
    <rim:SlotValue xsi:type="rim:AnyValueType">   
        <sdg:LegalPerson>
            <!-- Level of Assurance for the Minimum Data Set (MDS) -->
            <LevelOfAssurance>High</LevelOfAssurance>
            
            <!-- eIDAS Mandatory Attributes of the Minimum Data Set -->
            <LegalPersonIdentifier schemeID="eidas">ES/SE/12132123Y</LegalPersonIdentifier>
            <LegalName>AnyCompanyName</LegalName>

 			<!-- Optional Attributes of the Minimum Data Set -->
            <Identifier schemeID="Tax">113123123123123</Identifier>
            <Identifier schemeID="VAT">SE730757727</Identifier>
		   	<RegisteredAddress>
                <FullAddress>Prince Street 15</FullAddress>
                <LocatorDesignator>15</LocatorDesignator>
                <PostCode>11221</PostCode>
                <PostCityName>Malmo</PostCityName>
                <Thoroughfare>PrinceStreet</Thoroughfare>
                <AdminUnitLevel1>SE</AdminUnitLevel1>
            </RegisteredAddress>  

            <!-- Optional Sector Specific Attributes not belonging to the Minimum Data Set -->
            <SectorSpecificAttribute>
                <AttributeName>IBAN</AttributeName>
                <AttributeURI>http://eidas.europa.eu/attributes/legalperson/banking/IBAN</AttributeURI>
                <AttributeValue>SE02500105170137075032</AttributeValue>
            </SectorSpecificAttribute>
            <SectorSpecificAttribute>
                <AttributeName>BIC</AttributeName>
                <AttributeURI>http://eidas.europa.eu/attributes/legalperson/banking/BIC</AttributeURI>
                <AttributeValue>INGDDEFFYYY</AttributeValue>
            </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. The profile is dependent on the SDG OOTS record matching agreements. 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. 

<!--  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>
            
            <!-- Level of Assurance for the Minimum Data Set (MDS) -->
            <LevelOfAssurance>High</LevelOfAssurance>                          

			<!-- eIDAS Mandatory Attributes of the Minimum Data Set -->
            <Identifier>GR/BE/12313132</Identifier>   
            <FamilyName>Doe</FamilyName>
            <GivenName>John</GivenName>
            <DateOfBirth>1978-09-09</DateOfBirth>
            
            <!-- eIDAS Optional Attributes of the Minimum Data Set -->
            <BirthName>Jonathan Doepidis</BirthName>      
            <PlaceOfBirth>Athens</PlaceOfBirth>
            <CurrentAddress >
                <FullAddress>Panepistimou 5, 85101, Athens</FullAddress>
                <AdminUnitLevel1>GR</AdminUnitLevel1>
            </CurrentAddress>
            <Gender>Male</Gender>
            
            <!-- Optional Sector Specific Attributes not belonging to the Minimum Data Set -->
            <SectorSpecificAttribute>
                <AttributeName>IBAN</AttributeName>
                <AttributeURI>http://eidas.europa.eu/attributes/naturalperson/banking/IBAN</AttributeURI>
                <AttributeValue>DE02500105170137075032</AttributeValue>
            </SectorSpecificAttribute>
            <SectorSpecificAttribute>
                <AttributeName>BIC</AttributeName>
                <AttributeURI>http://eidas.europa.eu/attributes/naturalperson/banking/BIC</AttributeURI>
                <AttributeValue>INGDDEFFYYY</AttributeValue>
            </SectorSpecificAttribute> 
        </sdg:Person>
    </rim:SlotValue>
</rim:Slot>