Technical directive for online gaming in Schleswig Holstein v2.0_2013_english version

684 views

Published on

Published in: Technology, Business
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
684
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
28
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Technical directive for online gaming in Schleswig Holstein v2.0_2013_english version

  1. 1. *This translation of 'Technical Directive for Online Gaming in Schleswig-Holstein' is based on the document released on the 14th of August, 2013 by the German Ministry of the Interior. Th is translation is provi ded to you as a courtesy by Dictao and G LI. Technical Directive for Online Gaming in Schleswig-Holstein Ref. : dictao_Technical Directive for Online Gaming in Schleswig-Holstein_v2.0 Version 2.0 of 14/08/2013 This translation is provided to you as a courtesy by
  2. 2. Technical Directive for Online Gaming in Schleswig-Holstein Ref. : dictao_Technical Directive for Online Gaming in Schleswig-Holstein_v2.0 of 14/08/2013 2/74 Communication, reproduction and use forbidden without prior written permission from Dictao Reference : dictao_Technical Directive for Online Gaming in Schleswig-Holstein_v2.0 Version : 2.0 Date of latest update : 08/14/2013 Confidentiality : RESTRICTED DISTRIBUTION Revision history Revision Description of modification Author Date Version checked 21.06.2013 2.0 Beta Complete revision Project group 09.08 2013 2.0 Incorporation of feedback Project group 12.08.2013 2.0 Final editorial work Project group Approval history The following table provides a summary of all approvals which have resulted in the present document being given the “completed“ status. Date Version checked Comments Controller 21.06.2013 2.0 Beta QA, final Project group 14.08.2013 2.0 QA, final Project group
  3. 3. Technical Directive for Online Gaming in Schleswig-Holstein Ref. : dictao_Technical Directive for Online Gaming in Schleswig-Holstein_v2.0 of 14/08/2013 3/74 Communication, reproduction and use forbidden without prior written permission from Dictao Note: If certain manufacturer’s products are mentioned in this document, they are only named as an example without there being any recommendation of the product in question. References to male persons are used solely for the purpose of making the document easier to read.
  4. 4. Technical Directive for Online Gaming in Schleswig-Holstein Ref. : dictao_Technical Directive for Online Gaming in Schleswig-Holstein_v2.0 of 14/08/2013 4/74 Communication, reproduction and use forbidden without prior written permission from Dictao CONTENTS CONTENTS.....................................................................................................................................................4 1. INTRODUCTION ....................................................................................................................................6 2. ARCHITECTURAL OVERVIEW OF THE CONTROL SYSTEM .........................................................................7 2.1 Data protection with distributed operation of the control system........................................................7 2.2 Data encryption and signature...........................................................................................................7 2.3 IT security ..........................................................................................................................................8 3. DATA CAPTURING ................................................................................................................................9 3.1 Storage ..............................................................................................................................................9 3.2 Data retention period..........................................................................................................................9 3.3 Up-to-dateness ..................................................................................................................................9 3.4 Availability........................................................................................................................................10 3.5 Backup requirements.......................................................................................................................10 3.6 Confidentiality, integrity and authenticity..........................................................................................10 3.6.1 Authentication and encryption .....................................................................................................10 3.6.2 Signature and time stamp............................................................................................................10 4. DATA FORMATS .................................................................................................................................12 4.1 Data log model.................................................................................................................................12 4.1.1 Root element “data logs” .............................................................................................................13 4.1.2 Basic types of data log information..............................................................................................14 4.1.3 Main element “player”..................................................................................................................16 4.1.4 Main element “single player game”..............................................................................................23 4.1.5 Main element “community game” ................................................................................................26 4.1.6 Main element “betting completion”...............................................................................................28 4.1.7 Main element “betting result” .......................................................................................................34 4.1.8 Main element “betting result correction” ......................................................................................37 4.1.9 Main element “game-independent transaction” ...........................................................................40 4.2 Manifest model.................................................................................................................................42 4.2.1 Ensuring integrity and authenticity...............................................................................................42 4.2.2 Compression and encryption.......................................................................................................43 4.2.3 Packing of log data and control structure ....................................................................................44 4.2.4 Schema of control manifest .........................................................................................................45 4.3 Processing instructions....................................................................................................................49 4.4 Validity, updating and adjustment of the data provided....................................................................50 5. DATA FORMATS .................................................................................................................................52
  5. 5. Technical Directive for Online Gaming in Schleswig-Holstein Ref. : dictao_Technical Directive for Online Gaming in Schleswig-Holstein_v2.0 of 14/08/2013 5/74 Communication, reproduction and use forbidden without prior written permission from Dictao 5.1 Access technology...........................................................................................................................52 5.2 Logical data organisation.................................................................................................................52 5.3 Example...........................................................................................................................................53 6. CONTACT OPTIONS ............................................................................................................................56
  6. 6. Technical Directive for Online Gaming in Schleswig-Holstein Ref. : dictao_Technical Directive for Online Gaming in Schleswig-Holstein_v2.0 of 14/08/2013 6/74 Communication, reproduction and use forbidden without prior written permission from Dictao 1. INTRODUCTION Under § 4 clause 8, item 1 in association with § 46, clause 3 of the new Gaming Regulatory Act (Gambling Act) of 20 October 2011, the Ministry of the Interior is authorised by decree to publish regulations on technical requirements for gaming operators. The present document defines the technical requirements for an IT system to monitor online gaming in Schleswig-Holstein. Operators of online gaming services must set up and operate a technical control system which records and digitally stores the data relevant to implementing online gaming monitoring after a period of time (see chapter 3.3) or a trigger event and enables electronic control by the regulatory authority and the respective tax authorities. The terms described in the document must be fulfilled and recorded for the licensing authority before gaming operations can be commenced.
  7. 7. Technical Directive for Online Gaming in Schleswig-Holstein Ref. : dictao_Technical Directive for Online Gaming in Schleswig-Holstein_v2.0 of 14/08/2013 7/74 Communication, reproduction and use forbidden without prior written permission from Dictao 2. ARCHITECTURAL OVERVIEW OF THE CONTROL SYSTEM The control system combines the gaming operator’s applications with those of the regulatory authority and respective tax authorities via the analysis systems. Figure 1 Overview of the architecture The data capturing component within the control system is responsible for the construction of technical XML log data with information on gaming and betting procedures, payment, account statuses and gamblers. The data capturing is triggered by events which are activated by the gaming operations of the gaming operator. The downstream component carries out a digital sealing of data logs combined into data records for the purpose of verifying confidentiality, integrity, undeniability and the option of authentication. The sealing comprises the sub-steps compression, encryption and signing. (see Chapter 4.3). The sealed data records are made directly available to the regulatory authority and respective tax authorities online for control purposes, by the safe system (storing).The XML data records of an individual gaming operator described in this Technical Directive must be stored on a SAFE system and separated from any other data A safe system may only be assigned to one gaming operator. It may also be a virtual server. 2.1 Data protection with distributed operation of the control system It is permissible to deliver the operation of the safe system (storing) for one service operator. In this case, the access to unencrypted customer data of the gaming operator during the sealing of the data by the operator of the safe systems represents a data protection risks. It is therefore necessary to seal data outside the safe system, i.e. wherever data capturing occurs, see figure 1. The sealed data is made available on the safe system for the regulatory authority and the respective tax authority and must be accessed via HTTPS (see Chapter 5.1). 2.2 Data encryption and signature The data in the safe system, which is to be made available to the regulatory authorities and respective tax authority, must be given an advanced signature of the gaming operator. The data
  8. 8. Technical Directive for Online Gaming in Schleswig-Holstein Ref. : dictao_Technical Directive for Online Gaming in Schleswig-Holstein_v2.0 of 14/08/2013 8/74 Communication, reproduction and use forbidden without prior written permission from Dictao must be encrypted with the regulatory authority’s public certificate. More details are contained in Chapter 4.2. 2.3 IT security The safe system and all other necessary components must  fulfil at least the requirements of ISO/IEC 27001:2005 with ISO/IEC 27033 and  prove this by means of certification from an accredited body, ideally by means of an “ISO 27001 certificate based on IT baseline protection1 ” Certification must be implemented within 12 months of the commissioning of the safe system, with the exception of certification based on IT baseline protection. In this case, proof of certification must be presented in compliance with the following framework conditions only after 24 months:  6 months after the commissioning of the safe system, the gaming operator must submit to the regulatory authority a self-declaration of baseline protection2 for the safe system. Together with the self-declaration, the security concept for the safe system based on BSI standard 100-2 and the result of the basic security check must be provided.  An auditor certificate3 can be provided within 12 months of the commissioning of the safe system. A full test report and the auditor's certificate must be submitted to the regulatory authority without being asked to do so, if necessary with a list of the measures still to be carried out.  An ISO 27001 certificate based on IT baseline protection must be submitted for the safe system's IT network with in 24 months. When selecting the IT baseline protection procedure and the implementation of the current baseline protection catalogues of the BSI, the certification of the “safe system” IT network is to be undertaken by a licensed ISO 27001 auditor4, otherwise the certification must be implemented by an accredited body5. In general, recertification is required after the expiry of the validity of a certificate issued. The certificates issued must be submitted in full to the regulatory authority without being asked to do so, together with audit reports, if necessary with a list of the measures still to be carried out based on these reports. 1https://bsi.bund.de/DE/Themen/ITGrundschutz/ITGrundschutzZertifikat/itgrundschutzzertifikat_node.h tml 2A self-declaration of IT baseline security is a statement by the institution that it has implemented all the required measures for entry level and upgrade level. 3https://bsi.bund.de/DE/Themen/ITGrundschutz/ITGrundschutzZertifikat/AuditoenTestate/veroeffentlic hteTestateundSelbsterklaerung/testate.html 4https://www.bsi.bund.de/DE/Themen/ITGrundschutz/ITGrundschutzZertifikat/Veroeffentlichungen/ISO 27001Auditoren/auditoren27001.html 5http://www.iaf.nu//articles/IAF_MEMBERS_SIGNATORIES/4
  9. 9. Technical Directive for Online Gaming in Schleswig-Holstein Ref. : dictao_Technical Directive for Online Gaming in Schleswig-Holstein_v2.0 of 14/08/2013 9/74 Communication, reproduction and use forbidden without prior written permission from Dictao 3. DATA CAPTURING Gaming operators are responsible for setting up and operating the entire control system, Data logs must be stored in a digital safe system. The safe system must be physically separate from the operator’s gaming system and must be installed on a separate server within the Federal State of Schleswig-Holstein. Only the regulatory authority and respective tax authorities are authorised to access the data in the safe system on a read-only basis. Data must be stored in the safe system in accordance with chapter 3.3 after the completion of individual transactions (games, payments). The regulatory authority stipulates which information must be recorded for control purposes as well as its data format in the current valid version of this document. The detailed data model (XSD/XML) for data logs is defined in chapter 4.1. Data logs comprise the following information:  Financial transactions  Personal data of the gaming participants  Gaming and betting procedures  Player protection Details are contained in chapter 4. 3.1 Storage In the event of a control system failure, it must be possible to automatically transfer control data not yet copied into the safe system after operations recommence, so that the data remains chronological and complete. The operator must ensure that only the regulatory authority and the relevant tax authorities may access the data in the safe system via the internet. The operator must enable access to the safe system via the HTPPS protocol for control purposes (see chapter 5) and must provide the aforementioned authorities with the corresponding access information without being requested to do so. 3.2 Data retention period The operator must store the data for 8 consecutive months. The data must be available in the safe system for the fist 36 months. The data can then be archived on externally stored digital media (offline data) for a further 60 months. After 5 calendar days at the latest, it must be possible for the offline data to be made available again for direct access via the internet. After 8 years the data must be irrevocably deleted. 3.3 Up-to-dateness Data logs are combined into a data record and digitally sealed (see chapter 4.2):  after a max. interval of thirty minutes, unless data has accrued  or as soon as the received data volume to be compressed (raw data) has reached 10,000 data records,
  10. 10. Technical Directive for Online Gaming in Schleswig-Holstein Ref. : dictao_Technical Directive for Online Gaming in Schleswig-Holstein_v2.0 of 14/08/2013 10/74 Communication, reproduction and use forbidden without prior written permission from Dictao  or when it is 23:59:59 (UTC) (mandatory, even with empty data records). 3.4 Availability The control system must guarantee a degree of availability to the regulatory authority and respective tax authorities. Access to the safe system must be possible at least during the authorities’ normal working hours6. In the event that availability fails or is impaired, the regulatory authority will tolerate maximum down time of one working day. 3.5 Backup requirements The operator ensures the necessary backup of all data. The safe system and its backup must be geographically separate, at least in different compartments. Data storage on digital media must also be geographically separate from its corresponding backup. The back-up system must be located in the EU and EEA. Online backup and recovery data transfer between both locations must be carried out in a safe manner. 3.6 Confidentiality, integrity and authenticity Using cryptographic procedures, the safe system ensures the goals of confidentiality, integrity and authenticity of the log data. Digital linking and sealing (signature) of the data makes any change to the data (amendment, deletion, supplementation) provable. 3.6.1 Authentication and encryption The provision of confidentiality by the safe system when saved data is accessed by the regulatory authority is protected by several technical measures: Access is safeguarded by means of the authentication TLS-client authentication. The authentication/authorisation to be carried out is described in more detail in chapter 5.1 In addition, the log data is encrypted by means of a hybrid encryption process on the basis of the public certificates from the regulatory authority and tax authorities. The mechanisms to be used for encryption are described in chapter 4.2. 3.6.2 Signature and time stamp Integrity and authenticity is to be protected by an electronic signature and cryptographic time stamp. The signature must be at least an advanced signature. The certificates used must have been published by a trustworthy, public certification authority (CA). 6Workdays from 6:00 until 18:00
  11. 11. Technical Directive for Online Gaming in Schleswig-Holstein Ref. : dictao_Technical Directive for Online Gaming in Schleswig-Holstein_v2.0 of 14/08/2013 11/74 Communication, reproduction and use forbidden without prior written permission from Dictao A cryptographic time stamp is to be added to the signature according to XAdES7 V1.3.2 (ETSI TS 101 903). The XAdES signature time stamp is to be obtained in the form of a RFC3161 timestamp from a trustworthy, independent Time Stamping Authority (TSA)8. In the event of the unavailability of the independent time stamp service, the time stamp must be applied by the end of the next working day at the latest. The mechanisms to be used for the signature and time stamp are described in chapter 4.2. Given algorithms and key lengths comply with the recommendations of the current technical directives from the Federal Network Agency9. Implementation must always comply with the latest version of these recommendations. 7XML Advanced Electronic Signatures (XAdES) 8 http://www.bundesnetzagentur.de/cln 1912/DE/Service- Funktionen/Qualifizierteelektronische/Signatur/WelcheAufgabenhatdieBundesnetzagentur/Aufsichtund AkkreditierungsvonAnbietern/ZertifizierungsDiensteAnbietr node.html 9http://www.bundesnetzagentur.de/cln 1912/DE/Service- Funktionen/Qualifizierteelektronische/Signatur/WelcheAufgabenhatdieBundesnetzagenturGeeigneteAl gorithmrnfestlegen/geeignetealgorithmenfestlegen-node.htmll
  12. 12. Technical Directive for Online Gaming in Schleswig-Holstein Ref. : dictao_Technical Directive for Online Gaming in Schleswig-Holstein_v2.0 of 14/08/2013 12/74 Communication, reproduction and use forbidden without prior written permission from Dictao 4. DATA FORMATS This chapter defines the processing and format regulations for the generation of the data which is to be provided by a gaming operator in a safe system (see chapter 2). These regulations are subdivided as follows:  Data log model (chapter 4.1) o Defines the structures for the recording of data relevant to regulatory measures.  Manifest mode (chapter 4.2) o Defines structures and algorithms which guarantee the integrity, confidentiality and authenticity of the information recorded using cryptographic. The models are defined by XML schemas which can change. UTF 8 format is to be used for coding and UTC is to be used for the time zone instead of CET. The data is provided by the gaming operators within the framework of this technical directive only in accordance with the regulations defined in chapters 0, 4.2 and 5. Chapter 4.3 contains additional explanations regarding the requirements in terms of validity and dealing with updates and corrections in the data provided. The XML schemas corresponding to this technical directive have the following namespace and the following version: Model Namespace Version Data log model http://www.schleswig-holstein.de/IM/Gluecksspiel/safesystem- aufzeichnungsmodell-v2.0.xsd 2.0.0 Manifest model http://www.schleswig-holstein.de/IM/Gluecksspiel/safesystem- manifestmodell-v2.0.xsd 2.0.0 4.1 Data log model The data log model describes the recording regulations for data sets relevant to regulatory matters. The data log model differentiates in particular between root elements and main elements. Main elements are direct “child elements” of a root element, which are written as instances of a main data type into an XML file. The following Table 1 provides an overview of all the main elements for which information must be recorded by the gaming operator for the regulatory authorities. The same table also lists when a specific main element must be generated for transfer into the safe system. Together with the explanations in chapter, 0, chapter 4.2 and chapter 5, the form (e.g. particularly in which file) in which a specific main element is to be saved is defined Main element When generated? /afz:aufzeichnungen/afz:spieler ● as soon as a new player was registered ● as soon as the change to one or more of a player’s values, recorded via this main element, becomes known. ● as soon as a request is carried out by the regulatory authority. /afz:aufzeichnungen/afz:einzelspielerspiel ● as soon as all gaming activities directly following one another in time (several game rounds) with respect to a specific game by a player were concluded and the transaction to be recorded was completed.
  13. 13. Technical Directive for Online Gaming in Schleswig-Holstein Ref. : dictao_Technical Directive for Online Gaming in Schleswig-Holstein_v2.0 of 14/08/2013 13/74 Communication, reproduction and use forbidden without prior written permission from Dictao The player’s activity with regard to a game is regarded as concluded when the player has actively ended the game (e.g. special function or closure of a browser window) or the game was automatically ended by the system (e.g. if the player is inactive for a long time) /afz:aufzeichnungen/afz:gemeinschaftsspiel ● as soon as all the winners of the game are known and all the transactions to be concluded have been completed. /afz:aufzeichnungen/afz:wettabschluss ● as soon as the bets are regarded as completed and the transaction to be recorded has been completed. /afz:aufzeichnungen/afz:wettergebnis ● as soon as a betting result for a betting conclusion is known and the transaction to be recorded has been completed. /afz:aufzeichnungen/afz:wettergebniskorrektur ● as soon as a corrected betting result for a betting conclusion is known, which results in a change to a player account status, and the transaction to be recorded has been completed. /afz:aufzeichnungen/afz:spielunabhaengigeTransaktion ● as soon as a change to a player account status occurs, which is not recorded via a main element from chapters 4.1.4 to 4.1.8 and the associated translation was completed. Table 1: Permissible main elements of the data log model in version 2.0 The XML root element /afz:aufzeichnungen (see chapter 4.1.1) is the “carrier” of the different main elements. 4.1.1 Root element “data logs” Figure 2: Schema of the root element data logs Technical explanations /afz:aufzeichnungen [Mandatory]
  14. 14. Technical Directive for Online Gaming in Schleswig-Holstein Ref. : dictao_Technical Directive for Online Gaming in Schleswig-Holstein_v2.0 of 14/08/2013 14/74 Communication, reproduction and use forbidden without prior written permission from Dictao Highest structural element in the data log model, which contains a sequence of main elements. These main elements can occur in any order and there can be any number of them. There can only be one data log element per XML file. /afz:aufzeichnungen/@afz:lizenzinhaberREF [mandatory] Identifier (key) of the licence holder, which is assigned by the Gaming Regulatory Authority /afz:aufzeichnungen/afz:spieler [optional] Information on a player. See chapter 4.1.3. /afz:aufzeichnungen/afz:aufzeichungen/afz:einzelspielerspiel [optional] Information on an online casino game in which only one player can take part. See chapter 4.1.4. /afz:aufzeichnungen/afz:gemeinschaftspiel [optional] Information on an online casino game in which at least two players can play against one another. See chapter 4.1.5. /afz:aufzeichnungen/afz:aufzeichnungen/afz:wettabschluss [optional] Information on a betting event. See chapter 4.1.6. /afz:aufzeichnungen/afz:aufzeichnungen/afz:wettergebnis [optional] Information on a betting result which follows an event on which bets were placed. See chapter 4.1.7. /afz:aufzeichnungen/afz:aufzeichnungen/afz:wettergebniskorrektur [optional] Information on a betting correction (betting settlement) which follows an event on which bets were placed. See chapter 4.1.8. /afz:aufzeichnungen/afz:spielunabhaengigeTransaktion [optional] Information on a value change of a player account status (or subaccount status) which was caused independently of a gaming activity or betting activity. See chapter 4.1.9. 4.1.2 Basic types of data log information Figure 3: Schema of the basis type of data log information
  15. 15. Technical Directive for Online Gaming in Schleswig-Holstein Ref. : dictao_Technical Directive for Online Gaming in Schleswig-Holstein_v2.0 of 14/08/2013 15/74 Communication, reproduction and use forbidden without prior written permission from Dictao Technical explanation Meta information which is added to each main element in order to record the technical parameters, to provide information about the creation process for a main element and to allow the addressing of individual main elements without reference to the technical content. Each main element inherits the schema of the basic data log information. /afz:aufzeichnungen/<Hauptelementname>/@afz:aufzeichnungsID [mandatory] Identifier (key) of the data log. This identifier is to be assigned clearly to all the listed main elements within a safe system. /afz:aufzeichnungen/<Hauptelementname>/@afz:datenerfassungsDatum [mandatory] Time of the generation of the main element prescribed in accordance with Table 1.
  16. 16. Technical Directive for Online Gaming in Schleswig-Holstein Ref. : dictao_Technical Directive for Online Gaming in Schleswig-Holstein_v2.0 of 14/08/2013 16/74 Communication, reproduction and use forbidden without prior written permission from Dictao 4.1.3 Main element “player” Figure 4: Schema of the main element player Technical explanation
  17. 17. Technical Directive for Online Gaming in Schleswig-Holstein Ref. : dictao_Technical Directive for Online Gaming in Schleswig-Holstein_v2.0 of 14/08/2013 17/74 Communication, reproduction and use forbidden without prior written permission from Dictao The main element player records information which refers to the person of an individual player. The data set is created when a player is registered and is then always created when there is a change to any of the subelements recorded in this main element. Upon registration of a player a unique identifier (key) is to be assigned in the content of the gaming operator. This main element inherits the schema of the basic data log information in chapter 4.1.2. /afz:aufzeichnungen/afz:spieler Contains registration information about players. Such a main element is to be created for transfer into the safe system  as soon as a new play was registered  as soon as the change to one of more values of a player, recorded via this main element, becomes known.  as soon as a request is made by the regulatory authority. /afz:aufzeichnungen/afz:spieler/afz:spielerID [mandatory] Unique one-off identifier (key) to be allocared to the registered player by the gaming operator. The value must not provide any information about the actual identity of the player. Is not reallocated in the event of changes to the database. /afz:aufzeichnungen/afz:spieler/afz:vorname [mandatory] First names of the player. All the first names must be recorded, they must be separated using a space. /afz:aufzeichnungen/afz:spieler/afz:name [mandatory] Surname of the player. /afz:aufzeichnungen/afz:spieler/afz:geburtsname [mandatory] Birth name of the player. If the surname does not correspond to the birth name, the surname is to be re-entered in this element. /afz:aufzeichnungen/afz:spieler/afz:geburtsdataum [mandatory] Date of birth of the player. /afz:aufzeichnungen/afz:spieler/afz:geburtsort [mandatory] Place of birth of the player. /afz:aufzeichnungen/afz:spieler/afz:wohnsitz [mandatory] Information regarding the domicile of the player, which can be derived from his identity papers. If this domicile is not in Schleswig-Holstein, a reported additional domicile or a usual place of residence in Schleswig-Holstein must be recorded in the element /afz:aufzeichnungen/afz:spieler/afz:nebenwohnsitz /afz:aufzeichnungen/afz:spieler/afz:wohnsitz/afz:strasse [mandatory]
  18. 18. Technical Directive for Online Gaming in Schleswig-Holstein Ref. : dictao_Technical Directive for Online Gaming in Schleswig-Holstein_v2.0 of 14/08/2013 18/74 Communication, reproduction and use forbidden without prior written permission from Dictao Street with house number of the place of residence. /afz:aufzeichnungen/afz:spieler/afz:wohnsitz/afz:postcode [mandatory] Postcode of the place of residence. /afz:aufzeichnungen/afz:spieler/afz:wohnsiz/afz:ort [mandatory] Name of the town in the player’s place of residence is located. /afz:aufzeichnungen/afz:spieler/afz:wohnsitz/afz:staat [optional] Country code in accordance with ISO 3166-1 (ALPHA-2) of the country in which the place of residence is located. Must be recorded if the place of residence is not in Germany. /afz:aufzeichnungen/afz:spieler/afz:nebenwohnsitz [optional] Place of residence which must be recorded if the player’s identity papers show no place of residence which is in Schleswig-Holstein. This can be a recorded additional place of residence or a usual place of residence. With a usual place of residence, this is a location at which the player only stays temporarily, although for a specific duration and with a specific regularity. /afz:aufzeichnungen/afz:spieler/afz:nebenwohnsitz/afz:strasse [optional] Street with house number of the additional place of residence or the usual place of residence (see /afz:aufzeichnungen/afz:spieler/afz:nebenwohnsitz) for the player. /afz:aufzeichnungen/afz:spieler/afz:nebenwohnsitz/afz:postcode [mandatory] Postcode of the additional place of residence or the usual place of residence (see /afz:aufzeichnungen/afz:spieler/afz:nebenwohnsitz) for the player. /afz:aufzeichnungen/afz:spieler/afz:nebenwohnsitz/afz:ort [mandatory] Name of the town in which the additional place of residence or the usual place of residence (see /afz:aufzeichnungen/afz:spieler/afz:nebenwohnsitz) for the player is located. /afz:aufzeichnungen/afz:spieler/afz:nebenwohnsitz/afz:grund [optional] Reason for the usual place of residence (see /afz:aufzeichnungen/afz:spieler/afz:nebenwohnsitz). This element does not apply if this is a reported additional place of residence. /afz:aufzeichnungen/afz:spieler/afz:staatsangehoerigkeit [mandatory] Nationality in accordance with DIN EN ISO 3166-1 (ALPHA-2). /afz:aufzeichnungen/afz:spieler/afz:benutzername [mandatory] User name chosen by the player himself. There may only be one unique and one-off user name for a gaming operator. The user name is the name with which the player appears to third
  19. 19. Technical Directive for Online Gaming in Schleswig-Holstein Ref. : dictao_Technical Directive for Online Gaming in Schleswig-Holstein_v2.0 of 14/08/2013 19/74 Communication, reproduction and use forbidden without prior written permission from Dictao parties. If the gaming operator does not allocate a user name, the note "N/A" is to be entered here. /afz:aufzeichnungen/afz:spieler/afz:registrierungsstatus [mandatory] Registration status in connection with the validation of the player’s identity and the usability of a player account. Takes one of three pre-defined values: Provisional Status of the registration before a player’s registration information is authenticated by a trustworthy instance (e.g. Post-Ident). Authenticated Status of the registration after a player is authenticated by a trustworthy instance (e.g. Post-Ident). Deregistered Status of the registration if a gaming account is closed by the operator, if the player quits or if the player applies for a voluntary, definitive self- block. In the latter case the child element /afz:aufzeichnungen/afz:spieler/afz:sperre must be written in the same data log. /afz:aufzeichnungen/afz:spieler/afz:automatischerGewinntransaktion [optional] Amount above which winnings are automatically transferred to the player’s bank account (see /afz:aufzeichnungen/afz:spieler/afz:zahlungsweg)(see § 8(2) of the GGVO). If no limit applies, this element is not to be recorded. /afz:aufzeichnungen/afz:spieler/afz:sperre [optional] Duration of a block in days which a player has applied himself or was imposed for an account by a gaming operator (see Blocks in accordance with § 8(3) of the GGVO). For a block in accordance with § 10(3) of the GGVO), the duration in days must be entered here which the gaming operator reserves the right to impose or order to decide on the consequences resulting from this sort of block. The gaming operator can extend this period at any time. This element does not apply is no block is imposed. /afz:aufzeichnungen/afz:spieler/afz:sperre/@sperrart [mandatory] Type of block. Describes whether the block is determined by the player himself (self-block) or by the gaming operator (third-party block). The following values are to be used. Temporary break from gaming in accordance with § 8 (3) of the GGVO Self Temporary block in accordance with § 8 (3) of the GGVO Self Permanent block in accordance with § 8 (3) of the GGVO or § (2) in connection with §§ 18 (5), 21 (7) of the Gaming Act. Self or third-party Block in accordance with § 10 (3) of the GGVO Third-party
  20. 20. Technical Directive for Online Gaming in Schleswig-Holstein Ref. : dictao_Technical Directive for Online Gaming in Schleswig-Holstein_v2.0 of 14/08/2013 20/74 Communication, reproduction and use forbidden without prior written permission from Dictao /afz:aufzeichnungen/afz:spieler/afz:sperre/@geltungsbereich [mandatory] Scope of a block with respect to gaming operators. Describes whether a block is valid only with recording gaming operators (local) or with all gaming operators (global). The following values are to be used: Temporary break from gaming in accordance with § 8 (3) of the GGVO Local Temporary block in accordance with § 8 (3) of the GGVO Local Permanent block in accordance with § 8 (3) of the GGVO or § (2) in connection with §§ 18 (5), 21 (7) of the Gaming Act. Local or global Block in accordance with § 10 (3) of the GGVO Local /afz:aufzeichnungen/afz:spieler/afz:einzahlungslimitierung [mandatory] Payment limit which a player has set himself. The limit can be increased if the period, for which the limit applies, is shortened, or when a limit which has been is completely cancelled. /afz:aufzeichnungen/afz:spieler/afz:einzahlungslimitierung/afx:antragsdatum [mandatory] Date on which the limit was applied for (set) by the user. With a new registration of a player, no (voluntary) payment limit applies. Instead, the date of the player’s registration is to be entered in this case. If the data record is recorded without their being a change in the payment limit, the same values are to be entered here which were recorded in the last /afz:aufzeichnungen/afz:spieler data record. /afz:aufzeichnungen/afz:spieler/afz:einzahlungslimitierung/afz:wirksamkeitsdatum [mandatory] Date on which the limit or change to the limit comes into force for the first time. With a new registration of a player, no (voluntary) payment limit applies. Instead, the date of the player’s registration is to be entered in this case. If the data record is recorded without their being a change in the payment limit, the same values are to be entered here which were recorded in the last /afz:aufzeichnungen/afz:spieler data record. /afz:aufzeichnungen/afz:spieler/afz:einzahlungslimitierung/afz:limit [optional] Information regarding the maximum amount of all accumulated payments into the gaming account within a relative period, which is recorded under /afz:aufzeichnungen/afz:spieler/afz:einzahlungslimitierung/afz:limit/afz:zeitraum. If no payment limit applies or if a payment limit is inapplicable on a validity date, this element is not written in the data record. If a payment limit is active, however, no change to the payment limit is entered with the data record, so in this case the same values are to be entered which were also recorded in the last /afz:aufzeichnungen/afz:spieler data record for this player. /afz:aufzeichnungen/afz:spieler/afz:einzahlungslimitierung/afz:limit/afz:betrag [mandatory] Maximum amount of all accumulated payments within a relative period which is recorded under /afz:aufzeichnungen/afz:spieler/afz:einzahlungslimitierung/afz:limit/afz:zeitraum.
  21. 21. Technical Directive for Online Gaming in Schleswig-Holstein Ref. : dictao_Technical Directive for Online Gaming in Schleswig-Holstein_v2.0 of 14/08/2013 21/74 Communication, reproduction and use forbidden without prior written permission from Dictao /afz:aufzeichnungen/afz:spieler/afz:einzahlungslimitierung/afz:limit/afz:zeitraum [mandatory] Period in which a maximum amount of accumulated stakes may not be exceeded. The following pre-defined values can be adopted. Day All accumulated payments are reset every 24 hours, from the start of the accumulation of payments. Payments are to be accumulated from the dated recorded in /afz:aufzeichnungen/afz:spieler/afz:einzahlungslimitierung/afz:wirksamkeitsdatum [mandatory] Week All accumulated payments are reset every 168 hours (7 days), from the start of the accumulation of payments. Payments are to be accumulated from the dated recorded in /afz:aufzeichnungen/afz:spieler/afz:einzahlungslimitierung/afz:wirksamkeitsdatum [mandatory] Month All accumulated payments are reset every 720 hours (30 days) from the start of the accumulation of payments. Payments are to be accumulated from the dated recorded in /afz:aufzeichnungen/afz:spieler/afz:einzahlungslimitierung/afz:wirksamkeitsdatum [mandatory] /afz:aufzeichnungen/afz:spieler/afz:zahlungsweg [mandatory] Payment method between the player and its gaming account. The bank account, card payment, other payment services or exclusively cash must be recorded as child elements. /afz:aufzeichnungen/afz:spieler/afz:zahlungs/afz:bakkonto [optional] Bank account used for financial transactions by way of transfer, direct debit or EC card payment to and from the player’s account. /afz:aufzeichnungen/afz:spieler/afz:zahlungsweg/afz:bankkonto/afz:ibanDigest [mandatory] International bank account number in accordance with ISO 13616. The value is not written in plain writing for the purposes of pseudonymisation, but is saved as a hash value (digest). In addition the UTF-8 coded value is to be converted into a byte sequence and added to the hash value. /afz:aufzeichnungen/afz:spieler/afz:zahlungsweg/afz:bankkonto/afz:ibanDigest@digestMethod [mandatory] The algorithm used for generating the hash value. Currently, the algorithm SHA-256 is to be used. For identification purposes, the attribute value of the URI http://www.w3.org/2001/04/xmlenx#sha256 is to be entered. /afz:aufzeichnungen/afz:spieler/afz:zahlungsweg/afz:bankkonto/afz:bicDigest [mandatory] Bank identification code in accordance with ISO 9362. To create the hash value, the details of /afz:aufzeichnungen/afz:spieler/afz:zahlungsweg/afz:bankkonto/afz:ibanDigest apply. /afz:aufzeichnungen/afz:spieler/afz:zahlungsweg/afz:kartenzahlung [mandatory] Information on financial transactions which are settled between the player and player account via a credit card company. /afz:aufzeichnungen/afz:spieler/afz:zahlungsweg/afz:kartenzahlung/afz:kartengesellschaft [mandatory]
  22. 22. Technical Directive for Online Gaming in Schleswig-Holstein Ref. : dictao_Technical Directive for Online Gaming in Schleswig-Holstein_v2.0 of 14/08/2013 22/74 Communication, reproduction and use forbidden without prior written permission from Dictao Name of the credit card company (e.g. Mastercard, Visa, etc.). The issuing organisation (e.g. a bank or a society) is not to be recorded. /afz:aufzeichnungen/afz:spieler/afz:zahlungsweg/afz:kartenzahlung/afz:kartennummerDigest [mandatory] Number on the card. To create the hash value, the details of /afz:aufzeichnungen/afz:spieler/afz:zahlungsweg/afz:bankkonto/afz:ibanDigest apply /afz:aufzeichnungen/afz:spieler/afz:zahlungsweg/afz:kartenzahlung/afz:inhaber/afz:inhabernam eDigest [mandatory] Full name which appears on the card. To create the hash value, the details of /afz:aufzeichnungen/afz:spieler/afz:zahlungsweg/afz:bankkonto/afz:ibanDigest apply /afz:aufzeichnungen/afz:spieler/afz:zahlungsweg/afz:kartenzahlung/afz:referenzBankkonto [mandatory] Bank account of the player which (ultimately) is debited for debit adjustments, repayments and fees for the card recorded. It is used in the event that financial transactions from the gaming account to the player cannot be posted to the registered card. /afz:aufzeichnungen/afz:spieler/afz:zahlungsweg/afz:kartenzahlung/afz:referenceBankkonto/afz: ibanDigest [mandatory] Bank identification code in accordance with ISO 9362. To create the hash value, the details of /afz:aufzeichnungen/afz:spieler/afz:zahlungsweg/afz:bankkonto/afz:ibanDigest apply /afz:aufzeichnungen/afz:spieler/afz:zahlungsweg/afz:sonstigeZahlungsdienste/afz:anbieteridenti fikation [mandatory] Information regarding financial transactions which settled between the player and gaming account using other payment services. /afz:aufzeichnungen/afz:spieler/afz:zahlungsweg/afz:sonstigeZahlungsdienste/afz:kontoidentifik ationDigest [mandatory] Unique identification of the account used at the financial services operator. To create the hash value, the details of /afz:aufzeichnungen/afz:spieler/afz:zahlungsweg/afz:bankkonto/afz:ibanDigest apply /afz:aufzeichnungen/afz:spieler/afz:zahlungsweg/afz:ausschliesslichBar [mandatory] This element is to be recorded if only cash payments are used for this player in stationary betting operations. If as cashless transaction takes place between the player and the gaming operator, a corresponding other element must be recorded in /afz:aufzeichnungen/afz:spieler/afz:zahlungsweg
  23. 23. Technical Directive for Online Gaming in Schleswig-Holstein Ref. : dictao_Technical Directive for Online Gaming in Schleswig-Holstein_v2.0 of 14/08/2013 23/74 Communication, reproduction and use forbidden without prior written permission from Dictao 4.1.4 Main element “single player game” Figure 5: Schema of the main element single player game Technical explanation The main element single player game records the gaming activities of a player in a specific single player game (“human verses random generator”) in a closed, complete time interval. The gaming activity starts with the first stake with the specific game and ends when the player explicitly leaves
  24. 24. Technical Directive for Online Gaming in Schleswig-Holstein Ref. : dictao_Technical Directive for Online Gaming in Schleswig-Holstein_v2.0 of 14/08/2013 24/74 Communication, reproduction and use forbidden without prior written permission from Dictao (e.g. the corresponding browser window is closed) or the game is automatically terminated by the system (e.g. due to a long period of inactivity on the part of the player). This main element inherits the schema of the basic data log information in chapter 4.1.2. /afz:aufzeichnungen/afz:einzelspielerspiel Accumulated information on a single player game over several rounds. Such a main element is to be generated for transfer into the safe system.  as soon as all gaming activities directly following one another in time (several game rounds) with respect to a specific game by a player were concluded and the transaction to be recorded was completed. The player’s activity with regard to a game is regarded as concluded when the player has actively ended the game (e.g. special function or closure of a browser window) or the game was automatically ended by the system (e.g. if the player is inactive for a long time). /afz:aufzeichnungen/afz:einzelspielerspiel/afz:einzelspielerspielID [mandatory] Distinct, one-off identifier (key) of the single player game to be assigned by the gaming operator. /afz:aufzeichnungen/afz:einzelspielerspiel/afz:spielerREF [mandatory] Identifier (key) of the player, in accordance with /afz:aufzeichnungen/afz:spieler/afz:spieler in chapter 4.1.3. /afz:aufzeichnungen/afz:einzelspielerspiel/afz:spielart [mandatory] Type of game. Possible values: slot game, scratchcard, videopoker or other. /afz:aufzeichnungen/afz:einzelspielerspiel/afz:spielname [mandatory] Name of the game in accordance application documentation. /afz:aufzeichnungen/afz:einzelspielerspiel/afz:jackpot [mandatory] Indication as to whether a jackpot was won with the game (true) or not (false). /afz:aufzeichnungen/afz:einzelspielerspiel/afz:gesamteinsatz [mandatory] Total of all stakes which the player has placed over all the completed rounds of this single player game. /afz:aufzeichnungen/afz:einzelspielerspiel/afz:gesamtgewinn [optional Total of all winnings which the player has won over all the completed rounds of this single player game. If no winnings have been won, this element need not be recorded. /afz:aufzeichnungen/afz:einzelspielerspiel/afz:jackpotgewinn [optional] Amount of the jackpot winnings which the player has won. If there is no jackpot, this element need not be recorded.
  25. 25. Technical Directive for Online Gaming in Schleswig-Holstein Ref. : dictao_Technical Directive for Online Gaming in Schleswig-Holstein_v2.0 of 14/08/2013 25/74 Communication, reproduction and use forbidden without prior written permission from Dictao /afz:aufzeichnungen/afz:einzelspielerspiel/afz:sachgewinne [optional] Merchandise which the player has won over all the completed rounds. If no merchandise has been won, this element need not be recorded. /afz:aufzeichnungen/afz:einzelspielerspiel/afz:sachgewinne/afz:sachgewinne [mandatory] Informal description of the merchandise. /afz:aufzeichnungen/afz:einzelspielerspiel/afz:spielanfang [mandatory] Time of the start of the player activities in the game (first stake). /afz:aufzeichnungen/afz:einzelspielerspiel/afz:spielende [mandatory] Time of the end of the player activities in the game (active or passive “logout”) /afz:aufzeichnungen/afz:einzelspielerspiel/afz:anzahlSpielrunden [mandatory] Number of rounds completed between the start and end of the gaming activities of the player in the game. /afz:aufzeichnungen/afz:einzelspielerspiel/afz:realityChecks [mandatory] Times of all implemented “reality checks”. /afz:aufzeichnungen/afz:einzelspielerspiel/afz:realityChecks’afz:realityChecks [optional] Times of all implemented “reality checks”. /afz:aufzeichnungen/afz:einzelspielerspiel/afz:gesamttransaktion [mandatory] Arithmetic overall transactions between gaming account and gaming operator based on the gaming activities recorded in this main element. /afz:aufzeichnungen/afz:einzelspielerspiel/afz:gesamttransaktion/@afz:subkontotyp [optional] Subaccount type of the gaming account to which the transaction refers. If no subaccounts have to be set up by the gaming operator, the attribute can be omitted. Otherwise the following values are to be entered: blocked Logs the value changes to the subaccount from which no payments can be made to the player. remote operation Logs the value changes to the subaccount for payment movements in remote operation, from which payments can be made to the player. /afz:aufzeichnungen/afz:einzelspielerspiel/afz:gesamttransaktion/afz:unbarbetrag [optional] Scope and direction of a cash-less payment movement. A minus sign (-) corresponds to a debit from the gaming account (reduction of the value of the gaming account), while no sign corresponds to a credit to the gaming account (increase in the value of the gaming account). A plus sign (+) is not used.
  26. 26. Technical Directive for Online Gaming in Schleswig-Holstein Ref. : dictao_Technical Directive for Online Gaming in Schleswig-Holstein_v2.0 of 14/08/2013 26/74 Communication, reproduction and use forbidden without prior written permission from Dictao /afz:aufzeichnungen/afz:einzelspielerspiel/afz:gesamttransaktion/afz:spielkontostand [optional] Value of the gaming account (or subaccount) after completion of the transaction. A negative amount is not permitted. The amount corresponds to the balance of the player which can be used to take part in a game or for payment. A plus sign (+) is not used. 4.1.5 Main element “community game” Figure 6: Schema of the main element community game Technical explanation The main element community game logs information regarding a game in which at least two players have played against one another. If participation in the game has been via a network covering all gaming operators, each gaming operator must record this data set using a safe system in accordance with this directive and save it in its safe system. A community game is regarded as started as soon as the first stake has been made, and ends as soon as all winners are certain. No new players can join the game while a community game is running. This main element inherits the schema of the basic data log information in chapter 4.1.2. /afz:aufzeichnungen/afz:gemeinschaftsspiel Protocol of a community game. Such a main element is to be created for transfer to the safe system  as soon as all winners of the game are certain and to transactions to be recorded have been concluded.
  27. 27. Technical Directive for Online Gaming in Schleswig-Holstein Ref. : dictao_Technical Directive for Online Gaming in Schleswig-Holstein_v2.0 of 14/08/2013 27/74 Communication, reproduction and use forbidden without prior written permission from Dictao /afz:aufzeichnungen/afz:gemeinschaftsspiel/afz:gemeinschaftsspielID [mandatory] Distinct, one-off identifier (key) of the community game to be assigned by the gaming operator. /afz:aufzeichnungen/afz:gemeinschaftsspiel/afz:netzwerkspiel [optional] Information if the community game was implemented in a gaming network spanning all faming operators. If the game took place with just one gaming operator, this element is not applicable. /afz:aufzeichnungen/afz:gemeinschaftsspiel/afz:netzwerkspiel/afz:plattformanbieter [mandatory] Name of the platform operator on whose gaming platform the network game was implemented. /afz:aufzeichnungen/afz:gemeinschaftsspiel/afz:netzwerkspiel/afz:netzwerkspielID [mandatory] Identifier (key) of the game assigned by the platform operator. /afz:aufzeichnungen/afz:gemeinschaftsspiel/afz:spielart [mandatory] Name of the type of game. Possible values are Poker and Other. /afz:aufzeichnungen/afz:gemeinschaftsspiel/afz:spielvariante [mandatory] Name of the game variation in accordance with application documents (e.g. Texas Hold ‘Em). /afz:aufzeichnungen/afz:gemeinschaftsspiel/afz:spielanfang [mandatory] Time at which the first stake was made. /afz:aufzeichnungen/afz:gemeinschaftsspiel/afz:spielende [mandatory] Time at which the winners are certain. /afz:aufzeichnungen/afz:gemeinschaftsspiel/afz:rake [mandatory] Fee for participation in a community game. /afz:aufzeichnungen/afz:gemeinschaftsspiel/afz:rake/afz:gesamtrake [mandatory] Total fee deducted from all participants in a community game. Even if the gaming operator retains only a part or nothing of the fees collected (network), the entire fee collected is to be logged. /afz:aufzeichnungen/afz:gemeinschaftsspiel/afz:rake/afz:einbehaltenerAnteil [optional] Proportion of the total rake which remains with the gaming operator keeping the records. If the gaming operator completely retains the entire rake (no network), no entry is required. /afz:aufzeichnungen/afz:gemeinschaftsspiel/afz:spielprotokoll [mandatory] Information regarding all players which have participated in the game.
  28. 28. Technical Directive for Online Gaming in Schleswig-Holstein Ref. : dictao_Technical Directive for Online Gaming in Schleswig-Holstein_v2.0 of 14/08/2013 28/74 Communication, reproduction and use forbidden without prior written permission from Dictao /afz:aufzeichnungen/afz:gemeinschaftsspiel/afz:spielprotokoll/afz:spieler [2..*] Information regarding a player who has participated in a game. /afz:aufzeichnungen/afz:gemeinschaftsspiel/afz:spielprotokoll/afz:spieler/afz:fremderBenutzerna me [optional] User name of a player who is not registered with the gaming operator keeping the records. /afz:aufzeichnungen/afz:gemeinschaftsspiel/afz:spielprotokoll/afz:spieler/afz:registrierterSpieler [optional] User name of a player who is registered with the gaming keeping the records. /afz:aufzeichnungen/afz:gemeinschaftsspiel/afz:spielprotokoll/afz:spieler/afz:registrierterSpieler/ afz:spielerREF [mandatory] Player identification of a player, in accordance with /afz:aufzeichnungen/afz:spieler/spielerID in chapter 4.1.3, who is registered with the gaming operator keeping the records. /afz:aufzeichnungen/afz:gemeinschaftsspiel/afz:spielprotokoll/afz:spieler/afz:registrierterSpieler/ afz:einsatz [mandatory] Total stake of a player up to determination of all final winners. /afz:aufzeichnungen/afz:gemeinschaftsspiel/afz:spielprotokoll/afz:spieler/afz:gewinn [optional] Total winnings of a player after determination of all final winners. This element is not applicable if the player has no winnings. /afz:aufzeichnungen/afz:gemeinschaftsspiel/afz:spielprotokoll/afz:spieler/afz:gesamttransaktion [optional] Arithmetic total transaction in reference to the gaming account of a player based on the relevant gaming activities. Is only logged by the gaming operator with which the player is registered. See /afz:aufzeichnungen/afz:einselspielerspiel.afz:gesamttransaktion. 4.1.6 Main element “betting completion”
  29. 29. Technical Directive for Online Gaming in Schleswig-Holstein Ref. : dictao_Technical Directive for Online Gaming in Schleswig-Holstein_v2.0 of 14/08/2013 29/74 Communication, reproduction and use forbidden without prior written permission from Dictao Figure 7: Schema of the main element betting completion
  30. 30. Technical Directive for Online Gaming in Schleswig-Holstein Ref. : dictao_Technical Directive for Online Gaming in Schleswig-Holstein_v2.0 of 14/08/2013 30/74 Communication, reproduction and use forbidden without prior written permission from Dictao Technical explanation The main element betting completion logs the details of the betting completed between a player and a gaming operator (organiser). This main element inherits the schema of the basic data log information in chapter 4.1.2. /afz:aufzeichnungen/afz:wettabschluss Specific betting of an individual player with a gaming operator. Such a main element is to be created for transfer to the safe system.  as soon as the betting is regarded as completed and the transaction to be recorded has been completed. /afz:aufzeichnungen/afz:wettabschluss/afz:wettabschlussID [mandatory] Unique key to be assigned by the gaming operator for the specific betting. /afz:aufzeichnungen/afz:wettabschluss/afz:wettscheinID [optional] Identifier for associated bets which is to be used in two cases. If several independent bets have been completed at the same time (e.g. preset package of several individual bets, multi-bets), these bets are each to be logged as an independent main element and allocated a common identifier. If bets, due to their conditions, cannot be registered as combination bets or system bets in accordance with the preset schema (e.g. bank tip, system trixie), the different bet rows are each to be logged as an independent main element and allocated a common identifier. /afz:aufzeichnungen/afz:wettabschluss/afz:spielerREF [mandatory] Player identification in accordance with /afz:aufzeichnungen/afz:spieler/afz:spielerID in chapter 4.1.3. /afz:aufzeichnungen/afz:wettabschluss/afz:bewettetesEreignis [mandatory] Details of a bet depending on the type of bet. /afz:aufzeichnungen/afz:wettabschluss/afz:bewettetesEreignis/afz:einzelwette [optional] Details of the result of an individual bet. /afz:aufzeichnungen/afz:wettabschluss/afz:bewettetesEreignis/afz:einzelwette/afz:sportwettbew erb [mandatory] Separate, detailed description of the sports betting application. In the framework of which the betting is completed. Examples (see also child elements) Type of sport Name of event Date held Football Men’s 2014 World Championship, group A, Italy – Mexico 18.08.2014 Handball Men’s Bundesliga 2013/2014, 3rd day, THW Kiel – SC Magdeburg 21.11.2013
  31. 31. Technical Directive for Online Gaming in Schleswig-Holstein Ref. : dictao_Technical Directive for Online Gaming in Schleswig-Holstein_v2.0 of 14/08/2013 31/74 Communication, reproduction and use forbidden without prior written permission from Dictao Basketball Tryout, Germany – Austria 01.04.2014 Athletics 2016 Olympic Games, men’s 100m final 15.08.2016 /afz:aufzeichnungen/afz:wettabschluss/afz:bewettetesEreignis/afz:einzelwette/afz:sportwettbew erb/afz:sportart [mandatory] Official name of the type of sport, in the framework of which the betting is completed. /afz:aufzeichnungen/afz:wettabschluss/afz:bewettetesEreignis/afz:einzelwette/afz:sportwettbew erb/afz:veranstaltungsname [mandatory] Official name of the sporting event, in the framework of which the betting is completed. /afz:aufzeichnungen/afz:wettabschluss/afz:bewettetesEreignis/afz:einzelwette/afz:sportwettbew erb/afz:austragungsdatum [mandatory] Expected date of the event of the sports betting application with betting completion. /afz:aufzeichnungen/afz:wettabschluss/afz:bewettetesEreignis/afz:einzelwette/afz:ereignis [mandatory] Informal, precise description of the event which must be held so that the bet is won by the player. Any applicable handicap is to be incorporated into this description. /afz:aufzeichnungen/afz:wettabschluss/afz:bewettetesEreignis/afz:einzelwette/afz:handicap [optional Indication as to whether this is a handicap bet. With a handicap bet, this element must be logged with the value true. Otherwise, the value false is to be recorded, or this element can be omitted. /afz:aufzeichnungen/afz:wettabschluss/afz:bewettetesEreignis/afz:einzelwette/afz:quote [mandatory] Quote for the individual bet which was valid when the bet was completed. /afz:aufzeichnungen/afz:wettabschluss/afz:bewettetesEreignis/afz:einzelwette/afz:liveWette [optional Indication as to whether betting completed refers to live bets. Must be logged with the value true if the betting completed involves live bets. /afz:aufzeichnungen/afz:wettabschluss/afz:bewettetesEreignis/afz:einzelwette/afz:kombiwette [mandatory] Derails of a combi bet. /afz:aufzeichnungen/afz:wettabschluss/afz:bewettetesEreignis/afz:einzelwette/afz:kombiwette/af z:wette [1..*]
  32. 32. Technical Directive for Online Gaming in Schleswig-Holstein Ref. : dictao_Technical Directive for Online Gaming in Schleswig-Holstein_v2.0 of 14/08/2013 32/74 Communication, reproduction and use forbidden without prior written permission from Dictao Details of an individual bet which is part of the combi bet. See /afz:aufzeichnungen/afz:wettabschluss/afz:bewettetesEreignis/afz:einzelwette /afz:aufzeichnungen/afz:wettabschluss/afz:bewettetesEreignis/afz:kombiwette/afz;wette/@afz:s wquenzID [mandatory] Identifier (numbering) of an individual bet, within the overall betting. /afz:aufzeichnungen/afz:wettabschluss/afz:bewettetesEreignis/afz:systemwette [mandatory] Details of a system bet. /afz:aufzeichnungen/afz:wettabschluss/afz:bewettetesEreignis/afz:systemwette/@afz:tipps [mandatory] Minimum of individual bets won so that the system bet overall applies as won. /afz:aufzeichnungen/afz:wettabschluss/afz:bewettetesEreignis/afz:systemwette/afz:wette [1..*] Details of an individual bet which is part of the system bet. See /afz:aufzeichnungen/afz:wettabschluss/afz:bewettetesEreignis/afz:kombiwette/afz:wette /afz:aufzeichnungen/afz:wettabschluss/afz:stationärerWettabschluss [optional] If the bet is completed in stationary operation not via the internet), the unique identification features of the operating location must be entered here. /afz:aufzeichnungen/afz:wettabschluss/afz:stationärerWettabschluss/afz:vertriebsstättename [mandatory] Name of the operating location in accordance with the application documents. /afz:aufzeichnungen/afz:wettabschluss/afz:stationärerWettabschluss/afz:adresse/afz:strasse [mandatory] Street and building number of the operating location. /afz:aufzeichnungen/afz:wettabschluss/afz:stationärerWettabschluss/afz:adresse/afz:postcode [mandatory] Postcode of the operating location. /afz:aufzeichnungen/afz:wettabschluss/afz:stationärerWettabschluss/afz:adresse/afz:ort [mandatory] Name of the tow in which the operating location is located. /afz:aufzeichnungen/afz:wettabschluss/afz:datum [mandatory] Time the betting was completed.
  33. 33. Technical Directive for Online Gaming in Schleswig-Holstein Ref. : dictao_Technical Directive for Online Gaming in Schleswig-Holstein_v2.0 of 14/08/2013 33/74 Communication, reproduction and use forbidden without prior written permission from Dictao /afz:aufzeichnungen/afz:wettabschluss/afz:einsatztransaktion [mandatory] Transaction from gaming account to the gaming operator, in order to pay the betting stake. /afz:aufzeichnungen/afz:wettabschluss/afz:einsatztransaktion/afz:subkontotyp [optional] Subaccount type of a gaming account to which the transaction refers. If no subaccounts have to be set up by the gaming operator, this attribute can be left out. Otherwise the following values are to be entered. Blocked Logs the value changes on the subaccount, from which no payments can be made to the player. remote operation Logs the value changes on the subaccount for payment movements in remote operation, from which payments can be made to the player. Stationary Logs the value changes on the subaccount for payment movements in stationary operation, from which payments can be made to the player. /afz:aufzeichnungen/afz:wettabschluss/afz:einsatztransaktion/afz:unbarbetrag [mandatory] Scope of a cash-less payment which is carried out to partially or fully pay for a betting stake. If no cash-less payment is carried out, the value ‘0’ is to be logged. See also /afz:aufzeichnungen/afz:einzelspielerspiel/afz:gesamttransaktion/afz:unbarbetrag. A positive amount is nor permissible here. /afz:aufzeichnungen/afz:wettabschluss/afz:einsatztransaktion/afz:spielkontostand [mandatory] See /afz:aufzeichnungen/afz:einzelspielerspiel/afz:gesamttransaktion/afz:spielkontostand /afz:aufzeichnungen/afz:wettabschluss/afz:einsatztransaktion/afz:barbetrag [Optional] Scope of a cash payment made in partial or full settlement of a betting stake. If no cash payment is made, this element can be omitted. It is not permissible to enter a positive amount here.
  34. 34. Technical Directive for Online Gaming in Schleswig-Holstein Ref. : dictao_Technical Directive for Online Gaming in Schleswig-Holstein_v2.0 of 14/08/2013 34/74 Communication, reproduction and use forbidden without prior written permission from Dictao 4.1.7 Main element “betting result” Figure 8: Schema of the main element betting result Technical explanation The main element betting result logs the result (and/or the outcome) of previously completed betting. This main element inherits the schema of the basic data log information in chapter 4.1.2. /afz:aufzeichnungen/afz:wettergebnis Result of a previously completed bet by a single player. Such a main element is created for transfer to the safe system.  as soon as a betting result is determined for a bet completed and the transaction to be recorded has been concluded. /afz:aufzeichnungen/afz:wettergebnis/afz:wettergebnisID [mandatory] Unique key which identifies the betting result of a completed bet. /afz:aufzeichnungen/afz:wettergebnis/afz:wettabschlussREF [mandatory] Unique key which identifies the associated bet completed of a player in accordance with
  35. 35. Technical Directive for Online Gaming in Schleswig-Holstein Ref. : dictao_Technical Directive for Online Gaming in Schleswig-Holstein_v2.0 of 14/08/2013 35/74 Communication, reproduction and use forbidden without prior written permission from Dictao /afz:aufzeichnungen/afz:wettabschluss/afz:wettabschlussID in chapter 4.1.6. /afz:aufzeichnungen/afz:wettergebnis/afz:ergebnisID [mandatory] Overall result of the bet from the player’s perspective. The following values can be logged here; cancelled The gaming operator invalidated or cancelled the bet. The winnings of the player equal a simple refund of the stake or the agreed buy-back value of the completed bet. won The bet was won. The player receives winnings which result from the stipulated quote. lost The bet was lost. The player receives no winnings. /afz:aufzeichnungen/afz:annullierungsdetail [optional] Informal detailed information regarding the cause of the invalidation of the bet. Must be written if the result of the bet is “invalidated”. /afz:aufzeichnungen/afz:wettergebnis/afz:einzelwettenergebnisse [optional] Results of all (individual) bets of which a system or combi bet is comprised. If the completed bet referred to is an individual bet, this element is not applicable. /afz:aufzeichnungen/afz:wettergebnis/afz:einzelwettenergebnisse/afz:ergebnis [mandatory] Result of an individual bet in accordance with the table under /afz:aufzeichnungen/afz:wettergebnis/afz:ergebnis or the value not evaluated To be used if the result of the corresponding individual bet is not known, and due to the known results of other individual bets is insignificant for the end result. /afz:aufzeichnungen/afz:wettergebnis/afz:einzelwettenergebnisse/afz:ergebnis/@afz:sequenzR EF [2..*] Identifier (numbering) of the referenced individual bet in accordance with /afz:aufzeichnungen/afz:wettabschluss/afz:bewettetesEreignis/afz:kombiwette/afz:wette/@af z:sequenzID or /afz:aufzeichnungen/afz:wettabschluss/afz:bewettetesEreignis/afz:systemwette/afz:wette/@a fz:sequenzID. /afz:aufzeichnungen/afz:wettergebnis/afz:annullierungsdetail [0..*] Informal detailed information regarding the cause of the invalidation of an (individual) bet. Must be written if the result of the bet is “invalidated”.
  36. 36. Technical Directive for Online Gaming in Schleswig-Holstein Ref. : dictao_Technical Directive for Online Gaming in Schleswig-Holstein_v2.0 of 14/08/2013 36/74 Communication, reproduction and use forbidden without prior written permission from Dictao /afz:aufzeichnungen/afz:wettergebnis/afz:einzelwettenergebnisse/afz:annullierungsdetail/@afz:s equenzREF [mandatory] Identifier (numbering) of the referenced (individual) bet in accordance with /afz:aufzeichnungen/afz:wettabschluss/afz:bewettetesEreignis/afz:kombiwette/afz:wette/@af z:sequenzID or /afz:aufzeichnungen/afz:wettabschluss/afz:bewettetesEreignis/afz:systemwette/afz:wette/@a fz:sequenzID. /afz:aufzeichnungen/afz:wettergebnis/afz:datum [mandatory] Time from which the betting result is regarded as being valid, /afz:aufzeichnungen/afz:wettergebnis/afz:gewinntransaktion [mandatory] Transaction from the gaming operator to the gaming account in order to pay winnings. If the player lost, this element is not applicable. /afz:aufzeichnungen/afz:wettergebnis/afz:gewinntransaktion/@afz:subkontotyp [optional] See /afz:aufzeichnungen/afz:wettabschluss/afz:einsatztransaktion/afz:subkontotyp in chapter 4.1.6. /afz:aufzeichnungen/afz:wettergebnis/afz:gewinntransaktion/@afz:unbarbetrag [mandatory] See /afz:aufzeichnungen/afz:einzelspielerspiel/afz:gesamttransaktion/afz:unbarbetrag. A negative amount is not permissible. /afz:aufzeichnungen/afz:wettergebnis/afz:gewinntransaktion/@afz:spielkontostand [mandatory] See /afz:aufzeichnungen/afz:einzelspielerspiel/afz:gesamttransaktion/afz:spielkontostand
  37. 37. Technical Directive for Online Gaming in Schleswig-Holstein Ref. : dictao_Technical Directive for Online Gaming in Schleswig-Holstein_v2.0 of 14/08/2013 37/74 Communication, reproduction and use forbidden without prior written permission from Dictao 4.1.8 Main element “betting result correction” Figure 9: Schema of the main element betting result correction Technical explanation The main element betting result adjustment logs the adjustment of an already logged betting result. It is only logged if the previously logged (total) result has changed and this has resulted in a change to the gaming account This main element inherits the schema of the betting result in chapter 4.1.7 /afz:aufzeichnungen/afz:wettergebniskorrektur
  38. 38. Technical Directive for Online Gaming in Schleswig-Holstein Ref. : dictao_Technical Directive for Online Gaming in Schleswig-Holstein_v2.0 of 14/08/2013 38/74 Communication, reproduction and use forbidden without prior written permission from Dictao Adjustment of a result of a previously completed bet by a single player. Such a main element is created for transfer to the safe system.  as soon as an adjusted betting result for a completed is determined for a bet, which resulted in a change to a gaming account, and the transaction to be recorded has been concluded. /afz:aufzeichnungen/afz:wettergebniskorrektur/afz:wettergebnisID [mandatory] Unique identifier (key) which identifies thus betting result adjustment (not the previously logged betting result /afz:aufzeichnungen/afz:wettergebnis). /afz:aufzeichnungen/afz:wettergebniskorrektur/afz:wettabschlussREF [mandatory] Unique identifier key which identifies the associated bet completed of a player in accordance with /:afz:aufzeichnung0en/afz:wettabschluss/afz:wettabschlussID in chapter 4.1.6. /afz:aufzeichnungen/afz:wettergebniskorrektur/afz:ergebnis [mandatory] Adjusted overall result from the perspective of the player. See /afz:aufzeichnungen/afz:wettergebnis/afz:ergbenis in chapter 4.1.7 or the value open If, due to adjustments in the individual betting results, the overall result of an already evaluated bet has been opened again. /afz:aufzeichnungen/afz:wettergebniskorrektur/afz:annullierungsdetail [optional] Informal detailed information regarding the reason for the invalidation of the bet. Must be written if the result of the bet is “invalidated”. /afz:aufzeichnungen/afz:wettergebniskorrektur/afz:einzelwettebergebnisse [optional] Adjusted individual betting results from the perspective of the player. See. /afz:aufzeichnungen/afz:wettergebnis/afz:einzelwettenergebnisse in chapter 4.1.7 with the exception of /afz:aufzeichnungen/afz:wettergebniskorrektur/afz:einzelwettenergebnisse/afz:ergebnis (see below) /afz:aufzeichnungen/afz:wettergebniskorrektur/afz:einzelwettenergebnisse/afz:ergebnis [mandatory] Result of an individual bet in accordance with the table under /afz:aufzeichnungen/afz:wettergebnis/afz:einzelwettenergebnis or the value Open To be used if the result of the corresponding individual bet is open again after the adjustment and it is not yet certain whether this individual result is relevant to the overall result (/afz:aufzeichnungen/afz:wettergebnis/afz:ergebnis or /afz:aufzeichnungen/afz:wettergebniskorrektur/afz:ergebnis) /afz:aufzeichnungen/afz:wettergebniskorrektur/afz:datum [mandatory]
  39. 39. Technical Directive for Online Gaming in Schleswig-Holstein Ref. : dictao_Technical Directive for Online Gaming in Schleswig-Holstein_v2.0 of 14/08/2013 39/74 Communication, reproduction and use forbidden without prior written permission from Dictao Time from which the adjusted betting result is to be regarded as valid. /afz:aufzeichnungen/afz:wettergebniskorrektur/afz:gewinntransaktion [optional Value transaction from the gaming operator to the player in order to adjust winnings. This element is only logged if the winnings are higher than in the previously logged (regular) result (/afz:aufzeichnungen/afz:wettergebnis), if the winnings are less then the element /afz:aufzeichnungen/afz:wettergebniskorrektur/afz:gewinnstornierung is to be used and this element is omitted. /afz:aufzeichnungen/afz:wettergebniskorrektur/afz:gewinntransaktion/afz:subkontotyp [optional] See /afz:aufzeichnungen/afz:wettabschluss/afz:einsatztransaktion/afz:subkontotyp in chapter 4.1.6. /afz:aufzeichnungen/afz:wettergebniskorrektur/afz:gewinntransaktion/afz:unbarbetrag [mandatory] Amount of the cash-less winnings adjustment. See /afz:aufzeichnungen/afz:einzelspielerspiel/afz:gesamttransaktion/afz:unbarbetrag. A negative amount is not permissible here. Only the difference above the previously logged betting result wings is logged. /afz:aufzeichnungen/afz:wettergebniskorrektur/afz:gewinntransaktion/afz:spielerkontostand [mandatory] See /afz:aufzeichnungen/afz:einzelspielerspiel/afz:gesamttransaktion/afz:spielerkontostand /afz:aufzeichnungen/afz:wettergebniskorrektur/afz:details [mandatory] Informal detailed description regarding the cause of the adjustment. /afz:aufzeichnungen/afz:wettergebniskorrektur/afz:gewinnstornierung [optional] Transaction from the player to the gaming operator in order to adjust previously paid out winnings. This element is omitted if no wings have to be cancelled. /afz:aufzeichnungen/afz:wettergebniskorrektur/afz:gewinnstornierung/afz:subkontotyp [optional] See /afz:aufzeichnungen/afz:wettabschluss/afz:einsatztransaktion/afz:subkontotyp in chapter 4.1.6. /afz:aufzeichnungen/afz:wettergebniskorrektur/afz:gewinnstornierung/afz:unbarbetrag [mandatory] Amount of a cash-less cancellation. See /afz:aufzeichnungen/afz:einzelspielerspiel/afz:gesamttransaktion/afz:unbarbetrag. A positive amount is not permissible. /afz:aufzeichnungen/afz:wettergebniskorrektur/afz:gewinnstornierung/afz:spielerkontostand [mandatory]
  40. 40. Technical Directive for Online Gaming in Schleswig-Holstein Ref. : dictao_Technical Directive for Online Gaming in Schleswig-Holstein_v2.0 of 14/08/2013 40/74 Communication, reproduction and use forbidden without prior written permission from Dictao Value of the player’s account (or subaccount) after completion of the transaction. A negative amount equals a debt still to be paid by the player to the gaming operator. A positive amount equals the player’s balance which can be used for participation in a game or for a payment. A plus symbol (+) must not be used. 4.1.9 Main element “game-independent transaction” Figure 10: Schema of the main element game-independent transaction. Technical explanation The main element game-dependent transaction logs transactions which change the value of the gaming account (or subaccount) but the reason for the change is independent of direct gaming activities. A combination of two such main elements is to be logged to record the release of values blocked for payment to the player (bonuses). In such a case, an element game-independent transaction is logged which logs the value reduction (negative value of non-cash amount) of the
  41. 41. Technical Directive for Online Gaming in Schleswig-Holstein Ref. : dictao_Technical Directive for Online Gaming in Schleswig-Holstein_v2.0 of 14/08/2013 41/74 Communication, reproduction and use forbidden without prior written permission from Dictao subaccount with the values blocked for payment to the player (subaccounttype = “blocked”0. In addition, a second element game-independent transaction is logged which records the corresponding value increase (positive value of non-cash amount) of a subaccount for internet operations (subaccount type = “online”) or stationary operations (subaccount type = “stationary”). This main element inherits the schema of the data log information in chapter 4.1.2. /afz:aufzeichnungen/afz:spielunabhaengigeTransaktion Information regarding a transaction which changes the value of the virtual player account (or subaccount), but which was caused independently (outside) of direct gaming activities. Such a main element is created for transfer to the safe system.  as soon as a change to a player account occurs which was not logged using a main element from chapters 4.1.4 to 4.1.8 and the associated transaction was completed. /afz:aufzeichnungen/afz:spielunabhaengigeTransaktion/afz:transaktionID [mandatory] Unique key assigned by the gaming operator which identifies the transaction. /afz:aufzeichnungen/afz:spielunabhaengigeTransaktion/afz:spielerREF [mandatory] Identification of the player, in accordance with /afz:aufzeichnungen/afz:spieler/afz:spielerID in chapter 4.1.3. /afz:aufzeichnungen/afz:spielunabhaengigeTransaktion/afz:details [mandatory] Informal details of the transaction which must provide information about the cause of the transaction (e.g. deposit, payment, adjustment with exact reason). /afz:aufzeichnungen/afz:spielunabhaengigeTransaktion/afz:automatiscjGewinntransaktion [optional] Indicates whether the game-independent transaction was automatically completed in accordance with §8 (2) of the GGVO. Otherwise this element is omitted. /afz:aufzeichnungen/afz:spielunabhaengigeTransaktion/afz:zeitpunkt [mandatory] Time at which the transaction was completed. /afz:aufzeichnungen/afz:spielunabhaengigeTransaktion/afz:stationaererVertrieb [optional] Unique identification features of an operating location. Must be logged if a transaction was caused in stationary operations (not via the internet. See /afz:aufzeichnungen/afz:wettabschluss/afz:stationaererVertrieb /afz:aufzeichnungen/afz:spielunabhaengigeTransaktion/afz:transaktion [mandatory] Transaction information regarding changes to the gaming account (or subaccount), /afz:aufzeichnungen/afz:spielunabhaengigeTransaktion/afz:transaction/@afz:subkontotyp [optional] See /afz:aufzeichnungen/afz:wettabschluss/afz:einsatztransaktion/afz:subkontotyp in chapter 4.1.6.
  42. 42. Technical Directive for Online Gaming in Schleswig-Holstein Ref. : dictao_Technical Directive for Online Gaming in Schleswig-Holstein_v2.0 of 14/08/2013 42/74 Communication, reproduction and use forbidden without prior written permission from Dictao /afz:aufzeichnungen/afz:spielunabhaengigeTransaktion/afz:transaction/afz:unbarbetrag [mandatory] Cash-less paid amount of a transaction. See /afz:aufzeichnungen/afz:inzelspielerspiel/afz:gesamttransaktion/afz:unbarbetrag in chapter 4.1.4. /afz:aufzeichnungen/afz:spielunabhaengigeTransaktion/afz:transaction/afz:spielkontostand [mandatory] Account balance of the player account (or subaccount) at the time the transaction was completed. See /afz:aufzeichnungen/afz:wettabschlusskorrektur/afz:gewinnstornierung/afz:spielkontostand in chapter 4.1.8. /afz:aufzeichnungen/afz:spielunabhaengigeTransaktion/afz:transaction//afz:barbetrag [optional] Amount of a transaction paid in cash. If no cash payment is made, this element is omitted or contains the value ‘0’. If cash payment is made, the cashless amount (/afz:aufzeichnungen/afz:spielunabhaengigeTransaktion/afz:transaction/afz:unbarbetrag) contains the value ‘0’. The use of prefixes in this element is similar to how they are used in /afz:aufzeichnungen/afz:einzelspielerspiel/afz:geamttransaction/afz:unbarbetrag in chapter 4.1.4. 4.2 Manifest model The safe model defines how XML documents with the log data are to be processed in order for them to be stored in the safe system with guaranteed confidentiality, authenticity and integrity. The manifest model also specifies data structures which carry the necessary cryptographic information. 4.2.1 Ensuring integrity and authenticity In order to permit regulatory authorities and the relevant tax authorities to verify the integrity and authenticity of the logged data, cryptographic mechanisms are to be used as described below. In order to ensure the verifiable absence of loopholes in the recorded log data, the documents with the container element <afz:aufzeichnungen> are linked to one another through the generation of hash values. For this purpose, a control data structure <safe:kontrollManifest>is defined in the manifest model, in which the hash value of the logged data is combined with the hash value of the control structure of the previous logs. Each control structure is to have at least an advanced signature. Details on data structures and processing are given in chapters 4.2.4 and 4.3. The principle of cryptographic linking is illustrated in figure 11.
  43. 43. Technical Directive for Online Gaming in Schleswig-Holstein Ref. : dictao_Technical Directive for Online Gaming in Schleswig-Holstein_v2.0 of 14/08/2013 43/74 Communication, reproduction and use forbidden without prior written permission from Dictao Figure 11: Diagram of the principle of cryptographic linking 4.2.2 Compression and encryption After the generation of the hash values (see chapter 4.2.1), the documents with the log data are compressed with the ‘deflate‘ algorithm (RFC1951) in order to reduce the volume of the stored data. The compressed document is then encrypted to ensure confidentiality using the hybrid process. The safe system dynamically generates a symmetric key (256 Bit) for each document for this purpose and uses it to carry out encryption according to the Advanced Encryption Standard (AES256). The generated AES256 key is asymmetrically encrypted with regulatory authorities’ public keys (X.509 certificate) according to the RSA2048 process. The thus encrypted key is stored according to the XML encryption standard within the control structure <safe:kontrollManifest> as an <xenc:EncryptedKey> element. If the different authorities have different public keys (X.509 certificates), the symmetric key is to be encrypted several times and stored in the control structure. Data log Data log Data log … DocumentN Hash value of document N Hash value of previous manifest (N-1) ManifestN Signature N (XAdES) Control manifest N Data log Data log Data log … DocumentN+1 Hash value of document N+1 Hash value of previous manifest(N) ManifestN+1 Signature N+1 (XAdES) Control manifest N+1 Link Link
  44. 44. Technical Directive for Online Gaming in Schleswig-Holstein Ref. : dictao_Technical Directive for Online Gaming in Schleswig-Holstein_v2.0 of 14/08/2013 44/74 Communication, reproduction and use forbidden without prior written permission from Dictao Figure 12: Mechanisms for compression and encryption of log data 4.2.3 Packing of log data and control structure The compressed and encrypted documents with the log data and the signed control manifest are packed in a ZIP file. The ZIP file exclusively contains both file entries without path information (see also Figure 12):  data.bin - compressed and encrypted XML data logs  manifest.xml - signed XML control manifest The resulting ZIP file is archived in the safe system in the folder structure of the respective day (see chapter 5.2.). The name of the ZIP file is formed according to the following example: <lizenzinhaber>_<seqno>_<YYYYMMDD>_<hhmmss>.zip With  <lizenzinhaber> - Owner of gaming licence, no capitals  <seqno> - Day’s sequential counter, with leading zeros, 7 figures  <YYYYMMDD> - Date of creation of file  <hhmmss> - Time of creation with hour, minute and second Data log Data log Data log … Document xenc:EncryptedKey Control manifest RFC1951 deflate RSA2048 encryption symmetr. key AES256 encryption X.509 certificate of regulatory authorities compressed Compressed and encrypted ZIP file
  45. 45. Technical Directive for Online Gaming in Schleswig-Holstein Ref. : dictao_Technical Directive for Online Gaming in Schleswig-Holstein_v2.0 of 14/08/2013 45/74 Communication, reproduction and use forbidden without prior written permission from Dictao 4.2.4 Schema of control manifest The control manifest is an XML document, which is principally a carrier of meta-information and cryptographic data (hash values and key information). It represents the digital sealing and linking of technical log data. Figure 13: Schema of control structure The individual elements of the control structure are described in the following: /safe:kontrollManifest/safe:lizenzinhaberREF Distinct, identifying name of licence holder (gaming operator) /safe:kontrollManifest/safe:erstellungdDatum Date and time of generation of control manifest kontrollManifest tns:lizenzInhaberIdtns: tns:erstellungsDatumtns: tns:manifestSequenceNumbertns: tns:InhaltZfg tns:inhaltZfgtns: tns:anzahlAufzeichnungentns: tns:ersteAufzeichnungtns: tns:letzteAufzeichnungtns: tns:sizeUncompressedtns: tns:sizeCompressedtns: enc:EncryptedKey 1 ¥.. enc:EncryptedData ds:ManifestType dsig:Manifest attributes Id ds:Reference 1 ¥.. dsig:Signature
  46. 46. Technical Directive for Online Gaming in Schleswig-Holstein Ref. : dictao_Technical Directive for Online Gaming in Schleswig-Holstein_v2.0 of 14/08/2013 46/74 Communication, reproduction and use forbidden without prior written permission from Dictao /safe:kontrollManifest/safe:manifestSequenceNumber Sequential counter of control manifests (beginning with “1“) /safe:kontrollManifest/safe:metadaten Element contains summarised meta-information on the XML document with the data logs. /safe:kontrollManifest/safe:metadaten/safe:anzahlAufzeichnungen Total number of log data records within the XML document /safe:kontrollManifest/safe:metadaten/safe:ersteAufzeichnung Date and time of the first log data record (identical to the element value <afz:datum> of the first element <afz:datenerfassung>) /safe:kontrollManifest/safe:metadaten/safe:letzteAufzeichnung Date and time of the last log data record (identical to the element value <afz:datum> of the last element <afz:datenerfassung>) /safe:kontrollManifest/safe:metadaten/safe:sizeUncompressed Size of the non-compressed XML document in bytes /safe:kontrollManifest/safe:metadaten/safe:sizeCompressed Size of RFC1951 compressed XML document in bytes /safe:kontrollManifest/enc:EnryptedKey Element contains the asymmetric, encrypted, dynamically generated AES256 key with which the data file is encrypted, according to the XML encryption standard10 . The encryption algorithm (RSA 1.5) and identification of the X.509 encryption certificate are to be coded. The element for identification of the symmetric key must also contain a name in the element <xenc:CarriedKeyName>. Example: <xenc:EncryptedKey xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"> <xenc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-1_5"/> <ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#"> <ds:X509Data> <ds:X509SubjectName>CN=Behoerde, OU=Aufsicht, C=DE</ds:X509SubjectName> </ds:X509Data> </ds:KeyInfo> <xenc:CipherData> 10see: http:///www.w3.org/TR/xmlenc-core/
  47. 47. Technical Directive for Online Gaming in Schleswig-Holstein Ref. : dictao_Technical Directive for Online Gaming in Schleswig-Holstein_v2.0 of 14/08/2013 47/74 Communication, reproduction and use forbidden without prior written permission from Dictao <xenc:CipherValue>Z3wSdtXI7kpD3GwDlzhvIWRi…eYrO+Mwx76XkA=</xenc:CipherValue> </xenc:CipherData> <xenc:CarriedKeyName>K1456</xenc:CarriedKeyName> </xenc:EncryptedKey> If there are several X.509 encryption certificates for the regulatory authorities and the relevant tax authorities, several elements <xenc:EncryptedKey> are to be generated, which all contain the same symmetric key and name. /safe:kontrollManifest/xenc:EncryptedData ______________________ see: http:///www.w3.org/TR/xmlenc-core/ This element represents the reference to the encrypted data according to the XML encryption standard. It contains the encryption algorithm (AES256) as well as the internal reference to the symmetric key via the identifying name (identical to the value of the element <xenc:CarriedKeyName>). The actual reference to the encrypted data is expressed by a logical URI which is generated by concatenation of both parts as follows:  Absolute path in URL syntax (without scheme and host) to the ZIP file. The path corresponds with the folder structure, which is described in chapter 5.2. Example: /…/… …/<lizenzinhaber>_<seqno>_<YYYYMMDD>_<hhmmss>.zip  Path extension to data.bin file within the ZIP file. Example: /data.bin An Id attribute is to be added to the element to express the link (see next chapter). Example: <xenc:EncryptedData xmlns:xenc="http://www.w3.org/2001/04/xmlenc#" Id="D1456"> <xenc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#aes256-cbc"/> <dsig:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#"> <dsig:KeyName>K1456</ds:KeyName> </dsig:KeyInfo> <xenc:CipherData> <xenc:CipherReference URI="/ACME/Aufzeichnungen/2011/12/31/ACME_1456_20111231_235403.zip/data.bin"/> </xenc:CipherData> </xenc:EncryptedData> /safe:kontrollManifest/dsig:Manifest This element from the XML signature schema represents the cryptographic link of data log units (see chapter Erreur ! Source du renvoi introuvable.). It contains in general two references to data fields including their respective hash values:  External reference to the XML element <dsig:Manifest> from the control manifest within the previously constructed ZIP file (predecessor in the chain). The hash value is generated from the canonised XML element.
  48. 48. Technical Directive for Online Gaming in Schleswig-Holstein Ref. : dictao_Technical Directive for Online Gaming in Schleswig-Holstein_v2.0 of 14/08/2013 48/74 Communication, reproduction and use forbidden without prior written permission from Dictao The reference is to be expressed by a logical URI, which is generated by concatenation of the three parts as follows: o Absolute path in URL syntax (without scheme and host) to the previous ZIP file. The path corresponds with the folder structure, which is described in chapter Erreur ! Source du renvoi introuvable.. Example: /…/… …/<lizenzinhaber>_<seqno>_<YYYYMMDD>_<hhmmss>.zip o Path extension to the manifest.xml file within the ZIP file. Example: /manifest.xml o Reference to XML Id on the manifest element in URI fragment notation. Example: #<Id> Canonisation of the sub-element, which is to be carried out before hash value generation, is expressed by the transform URI for the C14N algorithm (with exclusive name spaces with sub-elements) as defined by the W3C: http://www.w3.org/2001/10/xml-exc-c14n#  Internal reference to the XML element <xenc:EncryptedData> of this control structure. Processing rules are coupled with this reference, which convey that reference is made to the unencrypted and uncompressed data. The hash value is to be generated from the unencrypted and uncompressed XML document. The transformation instructions (Transform-URIs) are to be formulated from the view point of a system which wants to retrace the hash value for the purpose of validation: therefore decryption and then decompression should first be carried out before hash value generation. Two URIs are to be entered accordingly into the processing sequence. The URI http://www.w3.org/2002/07/decrypt#Binary is defined for decryption by the W3C. The URI http:// www.schleswig-holstein.de/IM/transform/rfc1951#inflate is stipulated for RFC1951 decompression. Example: <dsig:Manifest Id="M1456"> <dsig:Reference URI="/ACME/Aufzeichnungen/2011/12/31/ACME_1455_20111231_235304.zip/manifest.xml#M1455"> <dsig:Transforms> <dsig:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/> </dsig:Transforms> <dsig:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/> <dsig:DigestValue>w+7o4caCHF6+N/KFLoC8itsBNhTTIX2BgMOvgI09VUM=</dsig:DigestValue> </dsig:Reference> <dsig:Reference URI="#D1456"> <dsig:Transforms> <dsig:Transform Algorithm="http://www.w3.org/2002/07/decrypt#Binary"/> <dsig:Transform Algorithm="http://www.schleswig-holstein.de/IM/transform/rfc1951#inflate"/> </dsig:Transforms>
  49. 49. Technical Directive for Online Gaming in Schleswig-Holstein Ref. : dictao_Technical Directive for Online Gaming in Schleswig-Holstein_v2.0 of 14/08/2013 49/74 Communication, reproduction and use forbidden without prior written permission from Dictao <dsig:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/> <dsig:DigestValue>agD4HdakRr1d3xR/t5YRyS5RstucSCakrWlbvryiJWM=</dsig:DigestValue> </dsig:Reference> </dsig:Manifest> An Id attribute is also to be added to the manifest element to enable external reference to it for linking. For the exceptional case of the very first control manifest of a safe entity, for which there is no predecessor, the manifest only contains internal reference to the encrypted data. /safe:kontrollManifest/dsig:Signature The complete control manifest is to have a qualified or advanced signature. The signature is to be applied as enveloped Signature (transformURI: http://www.w3.org/2000/09/xmldsig#enveloped-signature) in accordance with XAdES V1.3.2 incl. time stamp (XAdES-T). 4.3 Processing instructions The individual processing steps leading up to creation and storage of a ZIP file to be provided by the gaming operator on the safe system (see 4.2.3) are listed in order below, comprising log data and the control manifest:  Step 0: When one of the conditions for the conclusion of a data record is fulfilled (see chapter 3.3), the XML log document is immediately created.  Step 1: The hash value of the XML log document is calculated with the hash algorithm SHA256.  Step 2: The XML log document is compressed with the RFC-1951-DEFLATE algorithm.  Step 3: A 256Bit long random key is generated for the purpose of symmetric encryption.  Step 4: The compressed XML log document is encrypted with the AES256 algorithm using the key from step 3.  Step 5: The XML control manifest is built and filled with meta data from the log document.  Step 6: The symmetric key from step 3 is encrypted with the public key from the regulatory authority’s X.509 certificate and written in the XML control manifest as <xenc:EncryptedKey> according to XML encryption. An identifying name for the key is to be given in the element <xenc:CarriedKeyName>. If there are several X.509 certificates, step 6 is to be repeated accordingly several times using the same key name.
  50. 50. Technical Directive for Online Gaming in Schleswig-Holstein Ref. : dictao_Technical Directive for Online Gaming in Schleswig-Holstein_v2.0 of 14/08/2013 50/74 Communication, reproduction and use forbidden without prior written permission from Dictao  Step 7: The element <xenc:EncryptedData> with the reference to the encrypted data is to be built, given an Id attribute and written in the XML control manifest. The URI value is to be generated as described in chapter 4.2.4. The key used is to be referenced via the identifying key name generated in step 6 using the element <dsig:KeyInfo>.  Step 8: The hash value of the canonised element <dsig:Manifest> from the control manifest of the previous data record is to be calculated with the hash algorithm SHA256 (alternatively, the temporarily-stored hash value calculated during the construction of the previous data record can be accessed). This step is not applicable for the exceptional case of the very first data record.  Step 9: The element <dsig:Manifest> is to be built and given both references including their respective hash values (from step 1 and step 8). The transform URIs described in chapter 4.2.4 are to be entered. The element is to be given an Id attribute and written in the control manifest.  Step 10: The complete XML control manifest is to be given at least an advanced enveloped signature in accordance with XAdES, and a time stamp is to be added in accordance with chapter 3.6.2.  Step 11: A ZIP file is to be created with both data entries consisting of the encrypted data file data.bin and the signed control manifest manifest.xml. The name of the ZIP file is to be generated according to the rules defined in chapter 4.2.3.  Step 12: The created ZIP file is stored in the safe system in the folder accessible to the regulatory authorities and the relevant tax authorities. 4.4 Validity, updating and adjustment of the data provided Chapters 0. 4.1, 4.2 and 5 describe how and when data must be provided by the gaming operator for the regulatory authority and the relevant tax authorities. It is important that the gaming operators ensure the validity of the data provided, which is affected by the provisions of this directive, by adhering to this directive. Should the data in question not satisfy the provisions of this directive, the gaming operator can be requested to create again all the defective data in accordance with the provisions of this directive. In this case, the exact procedure is to be agreed with the regulatory authority. This chapter indicates several points in the directive in order to support the gaming operator in ensuring the validity of data provided. This directive specified XML schema (see annexes) which are also available as independent xsd schema files from the regulatory authority11. As the regulatory authority will check all XML files in 11The xsd schema files are not published on the internet under the URL of the targetNamespace, but are provided by the regulatory authority by e-mail.

×