Altera o Anexo I do Regulamento 903-B/2015 que define os Requisitos Técnicos do Sistema Técnico do Jogo Online, publicado no Diário da República, 2ª série, n.º 250, de 23 de dezembro de 2015. Através do Regulamento 903-B/2015, publicado no Diário da Repú-blica, 2.ª série, n.º 250, de 23 de dezembro de 2015, a Comissão de Jogos aprovou os requisitos técnicos do sistema técnico do jogo online.
Constatou-se, porém, que, por um lado, o anexo ao regulamento foi publicado com algumas inexatidões e, por outro, que se afigura necessário proceder a algumas retificações e alterações de mero pormenor. Assim, é retificado em todo o anexo as inexatidões do formato dia hora de “YYYYMMDD HH24MISS” para “YYYYMMDDHH24MISS”. Por outro lado, procede-se a alterações nos SERVIÇOS DE JOGADORES, II. SERVIÇOS DE VERIFICAÇÃO DE IDENTIDADE DO JOGADOR onde são modificados no processo de validação de identidade do SRIJ a estrutura dos diagramas de PedidoVerificaçãoTP e de RespostaVerificaçãoTP e os principais elementos da estrutura de pedido e resposta do serviço PedidoVerificaçãoTP e RespostaVerificacaoTP.
Na CRIAÇÃO SISTEMÁTICA DE REPORTES, II. ESPECIFICAÇÃO DOS TIPOS DE RECOLHA DE DADOS é modificada a categorias de dados V.1 Schema RESF_ e nesta bem como nas categorias de dados V.2 Schema JGDR_, V.3 Schema SESS_, V.4 Schema AJOG_ e V.5 Schema TRAN_ no XSD Schema são alterados os comandos da estrutura XML de element name=”id_ficheiro” type=”xs: short” /> para element name=”id_ficheiro” type=”xs: int” e ainda na tabela SCHEMA: AJOG dos diversos jogos e apostas as regras de mapeamento para o modelo de dados da entidade exploradora é aumentado o tamanho dos atributos cod_aptr_jog e cod_opejog de varchar2(6) para varchar2(22) e no Schema: AJOG_ Finalmente, procede-se à alteração da estrutura do XSD Schema do V.1 Schema RESF_ para ajustar o formato definido para a organização dos dados ao tipo de estrutura pretendida para os requisitos do reporte de informação. Considerando que o Regulamento 903-B/2015 foi disponibilizado no sítio da Internet do Serviço de Regulamentação e Inspeção de Jogos para consulta pública e que as alterações agora introduzidas não modificam substancial ou materialmente os requisitos técnicos definidos naquele Regulamento, não se submeteu a presente alteração a audiência ou consulta pública. Assim, ao abrigo das disposições conjugadas do n.º 3 do artigo 35.º e do artigo 48.º do Regime Jurídico dos Jogos e Apostas Online (RJO), aprovado em anexo ao Decreto Lei 66/2015, de 29 de abril, com a alínea b) e m) do n.º 3 do artigo 7.º do Decreto Lei 129/2012, de 22 de junho, na redação dada pelo Decreto Lei 66/2015, de 29 de abril, a Comissão de Jogos, na reunião de 10 de março de 2016, deliberou: 1 - É alterado o Anexo I do Regulamento 903-B/2015, que define os requisitos técnicos do sistema técnico do jogo online, publicado no Diário da República, 2.ª série, n.º 250, de 23 de dezembro de 2015, de acordo com o Anexo ao presente regulamento, que dele faz parte integrante. 2 - O presente regulamento entra em vigor no dia seguinte ao da sua publicação. 12 de abril de 2016. - A VicePresidente do Conselho Diretivo, Maria Teresa Rodrigues Monteiro. Informação Técnica para entidades exploradoras de jogo online SERVIÇOS DE JOGADORES A funcionalidade Serviços de Jogadores é considerada parte do Sistema técnico de jogo, aceitando-se por isso que esta funcionalidade possa ser implementada na infraestrutura da entidade exploradora. No âmbito dos serviços de jogadores, as entidades exploradoras devem interagir com a infraestrutura de controlo Serviço de Regulação e Inspeção de Jogos (SRIJ) através de dois tipos de serviços de dados I - SERVIÇO DE AUTOEXCLUSÃO DE JOGADORES As funcionalidades garantidas pelo presente serviço são ● Notificações de autoexclusão de jogadores ○ As entidades exploradoras devem enviar ao SRIJ, num prazo máximo de 24 horas desde a receção do pedido, os dados dos jogadores que solicitam a sua autoexclusão ou que alterem ou revoguem um pedido anterior de autoexclusão. ○ Notificações de alterações à base de jogadores autoexcluídos do SRIJ (onde é mantido o registo dos jogadores que solicitaram autoexclusão na página do SRIJ) serão enviadas a todas as entidades exploradoras em tempo real. ○ As entidades exploradoras devem garantir a reação adequada às notificações mencionadas no ponto anterior e proceder à recolha da última versão da lista de jogadores autoexcluídos. ● Recolha da última versão da lista de jogadores autoexcluídos ○ A entidade exploradora deve proceder ao download da última versão da lista de jogadores autoexcluídos transmitida pelo SRIJ. A caracterização técnica e funcional deste serviço podem ser aferidas nos seguintes pontos: /u01/app/oracle/mftxfer/[GameVault Code]/in/excl Um processo dedicado de gestão de transferência de ficheiros iniciará a operação de transferência do ficheiro XML para a infraestrutura de controlo do SRIJ logo que detete a existência de novos dados dentro do filesystem em questão. A estrutura deste ficheiro encontra-se descrita no anexo sub capítulo V.6 Schema EXCL_. O processo de encriptação do ficheiro encontra-se descrito no sub capítulo “processo de encriptação de ficheiros de dados”. definitions name=”ListaExcluidos” targetNamespace=”http: //www.turismo-deportugal.pt/ListaExcluidos/ListaExcluidos” xmlns: tns=”http: //www.turismodeportugal.pt/ListaExcluidos/Lis-taExcluidos” taExcluidos” xmlns: inp1=”http: //www.turismodeportugal.pt/SRJSchema/Lis-xmlns: xsd=”http: //www.w3.org/2001/XMLSchema” xmlns: soap=”http: //schemas.xmlsoap.org/wsdl/soap/” xmlns: wsdl=”http: //schemas.xmlsoap.org/wsdl/” > types> schema xmlns: xsd=”http: //www.w3.org/2001/XMLS- import namespace=”http: //www.turismodeportugal. pt/SRJSchema/ListaExcluidos” schemaLocation=”../xsd/SRJJogoOn-lineListaExcluidos.xsd”/> schema> types> message name=”requestMessage”> part name=”part” element=”inp1: PedidoListaExclui- message> message name=”replyMessage”> part name=”part” element=”inp1: RespostaListaExclui-chema”> dos”/> dos”/> message> portType name=”listaexcluidos_ptt”> operation name=”getlistaexcluidos”> input message=”tns: requestMessage”/> output message=”tns: replyMessage”/> operation> portType> binding name=”listaexcluidos_bind” type=”tns: listaexclui- binding transport=”http: //schemas.xmlsoap.org/soap/ operation name=”getlistaexcluidos”> operation style=”document” soapAction=”getlistaex dos_ptt”> http”/> cluidos”/> input> body use=”literal” namespace=”http: //www.turis-modeportugal.pt/ListaExcluidos/ListaExcluidos”/> input> output> body use=”literal” namespace=”http: //www.turis-modeportugal.pt/ListaExcluidos/ListaExcluidos”/> output> operation> binding> definitions> Excluidos” Os dados devem ser enviados na forma de uma estrutura de XML. Em seguida detalhar-se-á o XSD correspondente: schema xmlns: xsd=”http: //www.w3.org/2001/XMLSchema” xmlns: srjlex=”http: //www.turismodeportugal.pt/SRJSchema/Lista-targetNamespace=”http: //www.turismodeportugal.pt/SRJSchema/ ListaExcluidos” elementFormDefault=”qualified”> element name=”PedidoListaExcluidos” type=”srjlex: Pedido- element name=”RespostaListaExcluidos” type=”srjlex: Lista-ListaExcluidosType”/> CidadaoExcluidoType”> annotation> documentation>A sample element documentation> annotation> element> complexType name=”ListaCidadaoExcluidoType”> sequence> element name=”Sucesso” type=”xsd: boolean”/> element name=”ListaCidadaoExcludo” minOccurs=”0”> complexType> sequence> element name=”CidadaoExcluido” type=”srjlex: Cida-daoExcluidoType” minOccurs=”1”/> sequence> complexType> element> element name=”MensagemErro” minOccurs=”0” maxOc-curs=”1” type=”xsd: string”/> sequence> complexType> complexType name=”CidadaoExcluidoType”> sequence> element name=”IdTipoCid” type=”srjlex: int1”/> element name=”IdCidadao” type=”srjlex: string20”/> element name=”IdNacao” type=”srjlex: string2”/> element name=”DataInicio” type=”xsd: date”/> element name=”DataFim” type=”xsd: date”/> element name=”Confirmado”> simpleType> restriction> simpleType> list itemType=”xsd: string”/> simpleType> enumeration value=”S”/> enumeration value=”N”/> restriction> simpleType> element> sequence> complexType> complexType name=”PedidoListaExcluidosType”> sequence> element name=”CodEntidadeExploradora” type=”srjlex: string3”/> sequence> complexType> simpleType name=”string20”> restriction base=”xsd: string”> maxLength value=”20”/> restriction> simpleType> simpleType name=”string3”> restriction base=”xsd: string”> length value=”3”/> restriction> simpleType> simpleType name=”string2”> restriction base=”xsd: string”> maxLength value=”2”/> restriction> simpleType> simpleType name=”int1”> restriction base=”xsd: int”> totalDigits value=”1”/> restriction> simpleType> schema> schema xmlns: xsd=”http: //www.w3.org/2001/XMLSchema” xmlns: srjnpe=”http: //www.turismodeportugal.pt/SRJSchema/Noti-ficacaoPedidoExclusao” NotificacaoPedidoExclusao” targetNamespace=”http: //www.turismodeportugal.pt/SRJSchema/ elementFormDefault=”qualified”> element name=”NotificacaoPedidoExclusao” type=”srjnpe: NotificacaoPedidoExclusaoType”> annotation> documentation>A sample element documentation> annotation> element> element name=”RespostaNotificacaoPedidoExclusao” type=”srjnpe: RespostaNotificacaoPedidoExclusaoType”/> complexType name=”NotificacaoPedidoExclusaoType”> sequence> element name=”IdCidadao” type=”srjnpe: string20”/> element name=”IdTipoCid” type=”srjnpe: int1”/> element name=”IdNacao” type=”srjnpe: string2”/> element name=”DataInicio” type=”xsd: date”/> element name=”DataFim” type=”xsd: date”/> element name=”Confirmado”> simpleType> restriction> simpleType> list itemType=”xsd: string”/> simpleType> enumeration value=”S”/> enumeration value=”N”/> restriction> simpleType> element> sequence> complexType> complexType name=”RespostaNotificacaoPedidoExclusao Type”> sequence> element name=”Sucesso” type=”xsd: boolean”/> element name=”MensagemErro” type=”xsd: string”/> sequence> complexType> simpleType name=”string20”> restriction base=”xsd: string”> maxLength value=”20”/> restriction> simpleType> simpleType name=”string2”> restriction base=”xsd: string”> maxLength value=”2”/> restriction> simpleType> simpleType name=”int1”> restriction base=”xsd: int”> totalDigits value=”1”/> restriction> simpleType> schema> JOGADOR O sistema técnico de jogo das entidades exploradoras deve ser configurado de forma a cumprir todos os requisitos para garantir a comunicação com o WebService “NotificacaoPedidoExclusao”. II - SERVIÇO DE VERIFICAÇÃO DE IDENTIDADE DO O sistema técnico de jogo das entidades exploradoras de jogo online deve, no âmbito do processo de registo dos jogadores, garantir a execução de uma validação da identidade dos jogadores. A entidade exploradora validar deve verificar a identidade dos jogadores através dos seguintes métodos: a) Diretamente no seu sistema técnico de jogo, através do cartão do cidadão ou da chave móvel digital. b) Através da consulta em tempo real de uma base de dados de uma entidade pública, feita através de uma comunicação com o SRIJ. No seguimento da emissão de cada licença de exploração de jogo online, o SRIJ irá enviar à AMA, I.P. a identificação da entidade exploradora licenciada, que deve por sua vez contactar esta agência e seguir os procedimentos necessários para integrar no processo de registo do seu sistema técnico de jogo um processo de validação baseado no serviço autenticação.gov.pt. Este processo de verificação deve retornar ao sistema técnico de jogo da entidade exploradora informação relativamente ao nome, data de nascimento e número de identificação civil ligados ao cartão do cidadão ou da chave móvel digital utilizados no processo de registo de jogador. Validação através do processo de validação de identidade do SRIJ Com o objetivo de validar a informação ligada ao registo dos jogadores, o SRIJ irá mediar o acesso à base de dados de entidades públicas. No âmbito do processo de validação da identidade do jogador, a entidade exploradora deve aceder, na infraestrutura de controlo do SRIJ, ao serviço PedidoVerificacaoIdentidadeTP. Em seguida proceder-se-á à descrição detalhada do WSDL do serviço: definitions name=”PedidoVerificacaoIdentidade” targetNames-pace=” http: //www.turismodeportugal.pt/MediacaoRegisto/PedidoVe-rificacaoIdentidadeTP” xmlns: tns=”http: //www.turismodeportugal.pt/ MediacaoRegisto/PedidoVerificacaoIdentidadeTP” xmlns: inp1=”http: // www.turismodeportugal.pt/SRJSchema/VerificacaoIdentidade” xmlns: xsd=”http: //www.w3.org/2001/XMLSchema” xmlns: soap12=”http: // schemas.xmlsoap.org/wsdl/soap12/” xmlns: wsdl=”http: //schemas.xml-soap.org/wsdl/”> types> schema> import namespace=”http: //www.turismodeportugal. pt/SRJSchema/VerificacaoIdentidade” schemaLocation=”../xsd/SRJJo-goOnlineVerificacaoIdentidade.xsd”/> schema> types> message name=”requestMessage”> part name=”part” element=”inp1: PedidoVerificaca- message> message name=”replyMessage”> part name=”part” element=”inp1: RespostaVerificaca-oTP”/> oTP”/> message> portType name=”verificacaoidentidade_ptt”> operation name=”verificacaoidentidade”> input message=”tns: requestMessage”/> output message=”tns: replyMessage”/> operation> portType> binding name=”verificacaoidentidade_bind” type=”tns: verificacaoidentidade_ptt”> bindings/HTTP/”/> binding transport=”http: //www.w3.org/2003/05/soap/ operation name=”verificacaoidentidade”> operation style=”document” soapAction=”verificac aoidentidade” soapActionRequired=”false”/> input> body use=”literal” namespace=”http: //www.turismo-deportugal.pt/MediacaoRegisto/PedidoVerificacaoIdentidadeTP”/> body use=”literal” namespace=”http: //www.turis-modeportugal.pt/MediacaoRegisto/PedidoVerificacaoIdentidadeTP”/> input> output> output> operation> binding> definitions> O diagrama subjacente ao pedido é apresentado de seguida: A estrutura de XML é composta por quatro elementos: Nome do jogador a) A data de nascimento que corresponde ao nº de identificação civil é válida? cação civil é válido? já faleceu? enviado? b) O nome completo do cidadão que corresponde ao nº de identifi-c) O cidadão que corresponde ao nº de identificação civil enviado d) Existe um cidadão registado com que o nº de identificação civil A informação enviada pelo serviço da base de dados de entidade pú-blica é depois reportada ao sistema técnico da entidade exploradora. A resposta do serviço incluirá os seguintes elementos: Os principais elementos da estrutura de resposta do serviço RespostaVerificacaoTP são: A estrutura total de informação que é redirecionada pelo SRIJ para o sistema técnico de jogo da entidade exploradora encontra-se incluída no esquema de XSD que detalhamos de seguida e corresponde ao elemento “RespostaVerificacaoTP” : schema xmlns: xsd=”http: //www.w3.org/2001/XMLSchema” xmlns: srjvid=”http: //www.turismodeportugal.pt/SRJSchema/Veri-ficacaoIdentidade” VerificacaoIdentidade” targetNamespace=”http: //www.turismodeportugal.pt/SRJSchema/ elementFormDefault=”qualified”> element name=”PedidoVerificacaoJogadorOnlineRegistado” type=”srjvid: PedidoVerificacaoJogadorRegistadoType”/> element name=”RespostaVerificacaoJogadorOnlineRegistado” type=”srjvid: RespostaVerificacaoJogadorRegistadoType”/> element name=”PedidoVerificacaoTP” type=”srjvid: Pedido-VerificacaoTPType”> annotation> documentation>A sample element documentation> annotation> element> element name=”RespostaVerificacaoTP” type=”srjvid: Res-postaVerificacaoTPType”/> element name=”PedidoVerificacao” type=”srjvid: PedidoVe-rificacaoType”/> taVerificacaoType”/> Type”> element name=”RespostaVerificacao” type=”srjvid: Respos- complexType name=”PedidoVerificacaoJogadorRegistado sequence> element maxOccurs=”1” minOccurs=”0” name=”Numero IdentificacaoJogador” type=”xsd: string”/> element maxOccurs=”1” minOccurs=”0” name=”TipoIden tificacaoJogador” type=”xsd: string”/> element maxOccurs=”1” minOccurs=”0” name=”NifJogador” type=”xsd: int”/> sequence> oType”> complexType> complexType name=”RespostaVerificacaoJogadorRegistad sequence> element name=”Sucesso” type=”xsd: boolean”/> element name=”JogadorValido” type=”srjvid: stringSN” minOccurs=”1” maxOccurs=”1”/> element name=”MensagemErro” type=”xsd: string” maxOc-curs=”1” minOccurs=”0”/> curs=”1” minOccurs=”0”/> element name=”DetalheErro” type=”xsd: string” maxOc- sequence> complexType> complexType name=”PedidoVerificacaoTPType”> sequence> group ref=”srjvid: group1” maxOccurs=”1” minOccurs=”0”/> group ref=”srjvid: group2” maxOccurs=”1” minOccurs=”0”/> sequence> complexType> complexType name=”PedidoVerificacaoType”> sequence> element name=”Nif” type=”xsd: int”/> sequence> complexType> complexType name=”RespostaVerificacaoTPType”> sequence> element name=”Sucesso” type=”xsd: boolean”/> element name=”Valido” type=”srjvid: stringSN” minOc- element name=”CodigoErro” type=”srjvid: string10” mi-curs=”0” maxOccurs=”1”/> nOccurs=”0” maxOccurs=”1”/> nOccurs=”0” maxOccurs=”1”/> curs=”0” maxOccurs=”1”/> element name=”MensagemErro” type=”xsd: string” mi- element name=”DetalheErro” type=”xsd: string” minOc- sequence> complexType> complexType name=”RespostaVerificacaoType”> sequence> choice maxOccurs=”1”> element name=”NomeValido” type=”srjvid: stringSN”/> element name=”NomeCompleto” type=”xsd: string”/> choice> element name=”NifValido” type=”srjvid: stringSN” ma-xOccurs=”1”/> choice maxOccurs=”1”> element name=”DataNascimentoValida” type=”srjvid: stringSN” minOccurs=”1”/> element name=”MaiorDeIdade” type=”srjvid: strin- choice> element name=”Falecido” type=”srjvid: stringSN” minOc-curs=”0” maxOccurs=”1”/> sequence> complexType> group name=”group1”> sequence> element name=”CodEntidadeExploradora” type=”srjvid: gSN”/> string3”/> element name=”Nome” type=”xsd: string”/> element name=”NumeroIdentificacao” type=”xsd: string”/> element name=”TipoIdentificacao” type=”xsd: int”/> element name=”DataNascimento” type=”xsd: date”/> sequence> group> group name=”group2”> sequence> element name=”Nif” type=”xsd: int” maxOccurs=”1” mi-nOccurs=”0”/> element name=”NumeroIdentificacao” type=”xsd: string” maxOccurs=”1” minOccurs=”0”/> element name=”TipoIdentificacao” type=”xsd: int” maxOc-curs=”1” minOccurs=”0”/> sequence> group> simpleType name=”string10”> restriction base=”xsd: string”> maxLength value=”10”/> minLength value=”10”/> restriction> simpleType> simpleType name=”string3”> restriction base=”xsd: string”> maxLength value=”3”/> minLength value=”3”/> restriction> simpleType> simpleType name=”stringSN”> restriction base=”xsd: string”> enumeration value=”S”/> enumeration value=”N”/> restriction> simpleType> schema> REQUISITOS DE ARMAZENAMENTO DE DADOS PARA AS ENTIDADES EXPLORADORAS I - CRIAÇÃO DE FICHEIROS DE DADOS DE JOGO O SRIJ, de acordo com o enquadramento legal garantido pelo RJO, requer que as entidades exploradoras de jogo online façam o envio sistemático de informação ligada à atividade de jogo. Estes dados devem ser recolhidos no sistema técnico de jogo da entidade exploradora e enviados sobre a forma de um reporte de informação consolidado. Os dados devem ser organizados em estruturas de XML com base em categorias prédefinidas e armazenadas numa estrutura de sistema de pastas do SAFE da entidade exploradora, como um ficheiro diário único, comprimido (ZIP) e encriptado. Os ficheiros XML vão conter a atividade considerada relevante do sistema técnico de jogo da entidade exploradora durante o período de uma hora. Desta forma, deve ser produzido um ficheiro por cada hora do dia e por cada categoria de dados. Apenas o ficheiro de resumo financeiro da atividade de jogo da entidade exploradora e a lista diária de jogadores autoexcluídos devem ser produzidas numa base diária. A entidade exploradora é responsável pela recolha e produção dos ficheiros XML para as seguintes categorias de dados: A entidade exploradora é responsável pela geração e colocação diária no SAFE, até às 01: 00 AM (hora legal de Portugal Continental,determinada nos termos da legislação nacional e divulgada pelo Observatório Astronómico de Lisboa através dos servidores de NTP), de um ficheiro ZIP contendo, pelo menos, quatro conjuntos de ficheiros XML horários, um ficheiro XML diário de resumo financeiro correspondentes à atividade do dia anterior, bem como um ficheiro diário com a lista de jogadores autoexcluídos do dia anterior. A infraestrutura de controlo do SRIJ procede em seguida ao período de processamento, consubstanciado na recolha dos ficheiros encriptados colocados no SAFE, que decorrerá previsivelmente durante o intervalo da 01: 00 AM às 12: 00 PM (hora legal de Portugal Continental,determinada nos termos da legislação nacional e divulgada pelo Observatório Astronómico de Lisboa através dos servidores de NTP). Se os dados que constam de um determinado ficheiro que tenha sido depositado no SAFE forem considerados inválidos pelo processo de recolha do SRIJ, a criação de um novo ficheiro para uma data hora específica será solicitada à entidade exploradora. Este novo ficheiro de dados reprocessado deverá em seguida ser comprimido, encriptado, e depositado no SAFE tal como detalhado no ponto “III - processo de encriptação de ficheiros de dados”. Os ficheiros devem ser nomeados com a extensão “rp.xml”, para garantir o seu reconhecimento como “dados reprocessados” por parte do servidor de identificação do mecanismo de transferência de ficheiros do SRIJ e copiado para a estrutura de filesystem. As operações de reprocessamento não deverão ocorrer durante o periodo normal de processamento. Nota importante: cada processo de reprocessamento e reenvio de dados deve obrigatoriamente incluir o ficheiro de resumo financeiro (ver o ponto V.1 Schema RESF_ para os detalhes da estrutura do ficheiro) junto com os restantes tipos de ficheiro que devem ser reprocessados. II - REQUISITOS E ESPECIFICAÇÕES MINIMAS PARA O SAFE As entidades exploradoras são responsáveis pela configuração de uma infraestrutura que deve garantir as funcionalidades associadas à atividade do SAFE, com os seguintes requisitos mínimos: ● Sistema operativo: Linux (Orientação: a versão Oracle Linux e Red hat já foi testatada com a infraestrutura de controlo do SRIJ, tendo sido comprovada a sua compatibilidade); ● Rede de comunicação: uma conexão wide broadband (de pelo menos 20 Mbps) dedicada à infraestrutura de controlo do SRIJ; ● Um serviço de FTPS configurado no sistema operativo; ● Uma estrutura de pastas de ficheiros: /u01/app/oracle/mftxfer/in; /u01/app/oracle/mftxfer/in/excl; /u01/app/oracle/mftxfer/in/out III - PROCESSO DE ENCRIPTAÇÃO DE FICHEIROS DE DADOS O registo de dados no SAFE é agrupado em categorias prédefinidas. Cada uma dessas categorias deve ser assinada, comprimida e encriptada pela entidade exploradora utilizando para tal o formato e os procedimentos descritos no modelo de dados do SRIJ. O SRIJ disponibiliza às entidades exploradoras certificados PKI Multicert 128 bits SSL/HTTPS para assinar, comprimir e encriptar os ficheiros comprimidos gravados e subsquentemente retidos no SAFE. Os certificados Multicert 128 bits SSL/HTTPS são gerados de acordo com os seguintes requisitos: ● Recommendation ITU.T. X.509; ● RFC 5280; ● Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates, CA / Browser Forum. E possuem as seguintes características técnicas: ● Identificação eletrónica segura e inequívoca de um servidor; ● Membership Server a uma entidade/organização; ● Identificação e autenticação segura contra servidores Web; ● Garantia de autenticidade, confidencialidade, não repúdio e inte-● 2048-bit RSA keys; ● Hash Algorithm - SHA256; ● Shelf Life de 3 anos; ● Integração e reconhecimento automático pelos principais browsers gridade; e aplicações de e-mail. Como orientação, um processo de compressão e encriptação de ficheiros de jogo XML (obriga à criação do subfolder../mftxfer/bin) é descrito de seguida: ● Passo 1: Copia os ficheiros horários XML, o ficheiro diário XML de jogadores autoexcluídos e o ficheiro diário XML de resumo financeiro para o subfolder../mftxfer/in ● Passo 2: Posiciona-se no subfolder../mftxfer/bin ● Passo 3: Executa o seguinte script (que serádisponibilizado pelo SRIJ) > encripta.sh > encripta.sh cert.pem 20150427 1AA O shell script comprime os ficheiros XML dos subfolder ‘in’ para um ficheiro ZIP na pasta ‘bin’, encripta em seguida o ficheiro, gera o ficheiro de password rpasswd.pass.crypt, e cria um ficheiro ZIP final contendo os ficheiros referenciados. ● Passo 4: Move o ficheiro ZIP criado no Passo 3 para a pasta ‘out’. Logo que o processo de Managed File Transfer da infraestrutura de controlo do SRIJ deteta novos ficheiros colocados no SAFE, inicia a sua transferência. CRIAÇÃO SISTEMÁTICA DE REPORTES I - CONCEITOS DA ESTRUTURA DO MODELO DE DADOS DE JOGO ONLINE Atividade de jogo online Cada evento de jogo gravado deve ter um código específico único a cada entidade exploradora. O código de evento de jogo representa um evento aposta específico. Detalham-se em seguida alguns exemplos: Uma aposta desportiva, um torneio de Poker, uma aposta num jogo de roleta, uma aposta hípica, uma aposta num jogo de baccara, uma aposta num jogo de blackjack, etc.. A cada jogador associado a um evento de jogo é atribuido um código de evento de jogador por entidade exploradora e por evento de jogo. Este código vai encontra-se sempre associado a todas as operações efetuadas pelo jogador, enquanto participante desse evento de jogo. II - ESPECIFICAÇÃO DOS TIPOS DE RECOLHA DE DADOS As entidades exploradoras devem recolhar e produzir os ficheiros XML com os seguintes tipos de dados: Cada uma das categorias de dados vai ser em seguida detalhada. V.1 Schema RESF_ Esta categoria deve incluir o reporte financeiro completo da atividade de jogo online da entidade exploradora (i.e., total apostas, total comis-sões) ao longo das 24 horas que correspondem ao dia em causa. Deve ser gerado um ficheiro por cada dia e como orientação à sua produção, os valores apresentados neste resumo global devem corresponder aos valores reportados nos XML schema para as mesmas variáveis nas restantes categorias de dados do modelo de dados. RESF_YYYYMMDD_[GameVault _code].xml element ref=”tipo_liq”/> element ref=”total_comissoes” minOccurs=”0” /> element ref=”total_ganhos” minOccurs=”0” /> element ref=”total_apostas”/> element ref=”total_reembolsos” minOccurs=”0” /> sequence> complexType> element> element name=”tipo_liq” type=”xs: byte”/> element name=”total_comissoes” type=”xs: decimal”/> element name=”total_ganhos” type=”xs: decimal”/> element name=”total_apostas” type=”xs: decimal”/> element name=”total_reembolsos” type=”xs: decimal”/> element name=”descricao” type=”xs: string”/> element name=”licenca_exp” type=”xs: string”/> element name=”liq_int”> complexType> sequence> element name=”data_fin” type=”xs: int”/> element name=”tipo_jogo”> complexType mixed=”true”> sequence> element ref=”descricao”/> element ref=”licenca_exp”/> element ref=”liq_int” maxOccurs=”2” minOccurs=”1”/> sequence> complexType> element> element name=”cod_entexpl” type=”xs: byte”/> element name=”datahr” type=”xs: int”/> element name=”datahr” type=”xs: int” /> element name=”cod_cofre” type=”xs: string”/> element name=”resumo_activ”> complexType> sequence> element ref=”data_fin”/> element ref=”tipo_jogo”/> sequence> complexType> element> element name=”ficheiro”> element> complexType> complexType> sequence> element ref=”cod_entexpl”/> sequence> element ref=”datahr”/> element ref=”id_ficheiro”/> element ref=”cod_cofre”/> element ref=”resumo_activ”/> schema> de jogo online. NOT NULL’ cod_cofjog = ‘Codigo externo de cofre de dados do jogo online. NOT NULL’ id_ficheiro = ‘Identificador do ficheiro XML proveniente da entidade exploradora de jogo online. NOT NULL’ data_hr = ‘Datahora de producao do ficheiro de dados XML. YYYYMMDDHH24MISS. NOT NULL’ data_fin = ‘Data de resumo de actividade financeira. NOT NULL’ tipo_jogo = ‘Descricao do tipo de jogo, aposta online. NOT NULL’ licenca_exp = ‘Codigo da licenca de jogo online. NOT NULL’ tipo_liq=’Tipo de liquidez. Internacional Sim 1, Nao 0.’ total_comissoes = ‘Total de comissoes gerado pela entidade exploradora, operador de jogo online no periodo reportado, em euros.’ total_ganhos = ‘Total de ganhos gerado pela entidade exploradora, operador de jogo online no periodo reportado, em euros.’ total_apostas = ‘Total de apostas gerado pela entidade exploradora, operador de jogo online no periodo reportado, em euros. NOT NULL’ total_reembolsos = ‘Total de reembolsos gerado pela entidade exploradora, operador de jogo online no periodo reportado, em euros.’ V.2 Schema JGDR_ Esta categoria de dados deve incluir todos os novos registos de jogadores ou atualizações subsequentes de registos relativos a informação pessoal realizadas dentro do sistema técnico da entidade exploradora. A entidade exploradora deve produzir um ficheiro por cada hora do dia a que respeita o reporte. xml Example: JGDR_2015040221_2AA.xml buteFormDefault=”unqualified” elementFormDefault=”qualified”> element name=”codjogador” type=”xs: string” /> element name=”conta_jog” type=”xs: string” /> element name=”tip_pag” type=”xs: string” /> element name=”logon” type=”xs: string” /> element name=”id_cidadao” type=”xs: string” /> element name=”id_tipocid” type=”xs: string” /> element name=”timestp_reg” type=”xs: string” /> element name=”alias_jog” type=”xs: string” /> element name=”nome” type=”xs: string” /> element name=”data_nascimento” type=”xs: string” /> element name=”nif” type=”xs: string” /> element name=”morada” type=”xs: string” /> element name=”cod_postal” type=”xs: string” /> element name=”id_nacao” type=”xs: string” /> sequence> element ref=”codjogador” /> element ref=”conta_jog” /> ANEXO