Archivo de la categoría: Prestadores de Servicios Electrónicos de Confianza

Nuevas opciones de identificación a distancia para prestadores de servicios de certificación.

1 respuesta

El artículo 24 del Reglamento eIDAS (Reglamento UE nº 910/2014) define varias formas en las que los prestadores de servicios de certificación pueden identificar a sus clientes solicitantes de certificado.  En su apartado 1 se indica:

1. Al expedir un certificado cualificado para un servicio de confianza, un prestador cualificado de servicios de confianza verificará, por los medios apropiados y de acuerdo con el Derecho nacional, la identidad y, si procede, cualquier atributo específico de la persona física o jurídica a la que se expide un certificado cualificado.

La información a que se refiere el párrafo primero será verificada por el prestador de servicios de confianza bien directamente o bien por medio de un tercero de conformidad con el Derecho nacional.

a) en presencia de la persona física o de un representante autorizado de la persona jurídica, o

b) a distancia, utilizando medios de identificación electrónica, para los cuales se haya garantizado la presencia de la persona física o de un representante autorizado de la persona jurídica previamente a la expedición del certificado cualificado, y que cumplan los requisitos establecidos con el artículo 8 con respecto a los niveles de seguridad «sustancial» o «alto», o

c) por medio de un certificado de una firma electrónica cualificada o de un sello electrónico cualificado expedido de conformidad con la letra a) o b), o

d) utilizando otros métodos de identificación reconocidos a escala nacional que aporten una seguridad equivalente en términos de fiabilidad a la presencia física. La seguridad equivalente será confirmada por un organismo de evaluación de la conformidad.

Hoy se ha conocido que la Agencia Tributaria equipara un video selfie a otras modalidades de identificación (entre las que se incluyen la identificación por certificado) para permitir el cambio del número de teléfono móvil asociado a la identificación con sistema Cl@ve gestionada por la propia Agencia Tributaria y que es posible usar en todas las administraciones públicas:

Registro Cl@ve

En el epígrafe «Modificación del teléfono aportando vídeo y documentación relacionada» se indica:

Avisos

  • Mediante este trámite puede modificar el teléfono móvil asociado a su registro en Cl@ve aportando la información relacionada, que incluye un vídeo utilizado para contrastar su identidad.
  • Puede obtener más información sobre este trámite pinchando aquí
  • En la documentación deberá presentar:
  • Copia del DNI/NIE por las dos caras.
  • En el caso de los NIE, copia de la primera hoja del pasaporte.
  • Copia de la última factura del nuevo teléfono móvil que quiere dar de alta en Cl@ve, en la que se visualice dicho número. No es necesario que se vean otros datos personales (números de IBAN) ni de consumo.
  • Video autorretrato grabado por el solicitante (tipo video selfie) de máximo un minuto de duración en el que se muestre el DNI/NIE por las dos caras y donde el solicitante debe dar esta información:
    • Nombre y apellidos.
    • DNI/NIE.
    • Trámite que quiere realizar.
    • Número de teléfono que quiere registrar.
    • Puede usar esta frase a modo de guion:
      «Me llamo XXXX YYYY ZZZ, mi DNI es el 00000000 y quiero modificar el número de teléfono de mi registro en Cl@ve. El nuevo número es el 66666666» al tiempo que muestra el DNI/NIE por las dos caras.
      El video debe realizarse en una sola toma y sin cortes, en condiciones de luz que permitan identificar claramente al solicitante.

Esto es una gran noticia para los prestadores de servicios de certificación que, además de los procedimientos autorizados por el SEPBLAC podrán adoptar la posibilidad de admitir «Video autorretratos grabados por los solicitantes» tal como lo describe la Agencia Tributaria.

Tenemos, pues, un nuevo método de identificación reconocido a escala nacional de los que recoge el Reglamento Europeo EIDAS.

¿Cuantos Prestadores de Servicios Electrónicos de Confianza Cualificados hay en Europa?

Deja un comentario

El dato va cambiando con el tiempo.

El 2018 había 182, en 2019 había 194. Mi estimación (porque no he hecho la cuenta) es que en 2020 se superan los 200.

En la cumbre europea «CA-Day» de 2019 se resumió el número de Prestadores de Servicios Electrónicos de Confianza Cualificado por paises en este mapa:

Una de las sorpresas en aquella reunión fue ver que España cuenta con el mayor número de Prestadores de Servicios Electrónicos de Confianza de Europa.

Políticas europeas, qué se cuece

Deja un comentario

La Comisión Europea ha publicado su estrategia digital, su estrategia de datos y un Informe (White paper) sobre inteligencia artificial.

Tiene previsto iniciar una consulta pública sobre las prioridades en materia de certificación de ciberseguridad.

Agenda digital

La Comisión Europea ha publicado su estrategia digital: «Dando forma al futuro digital de Europa» («Shaping Europe’s digital future»).

El 19 de febrero de 2020, la Comisión Europea publicó su  estrategia digital y su visión para la formulación de políticas digitales en los próximos cinco años. La agenda digital esboza varias iniciativas legislativas y no legislativas previstas por la Comisión en los próximos meses. Algunos de los aspectos más destacados para los entidades dedicadas a las infraestructuras digitales son los siguientes:

  • Ley de Servicios Digitales (Q4 2020). Normas nuevas y revisadas para profundizar en el mercado interior de los servicios digitales, aumentando y armonizando las responsabilidades de las plataformas en línea y los proveedores de servicios de información y reforzando la supervisión de las políticas de contenido de las plataformas en la UE. Según la Comisión, la venta de productos ilícitos, peligrosos o falsificados y la difusión de contenidos ilegales deben abordarse con la mayor eficacia posible.
  • Cumplir una nueva Agenda del Consumidor (Q4 2020).
  • Revisión del Reglamento eIDAS (Q4 2020): para mejorar su eficacia, extender sus beneficios al sector privado y promover identidades digitales de confianza para todos los europeos. Según la Comisión, es necesario contar con una nueva Identidad Digital (eId) pública, universalmente aceptada para que los consumidores tengan acceso a sus datos y utilicen de forma segura los productos y servicios que desean sin tener que utilizar plataformas no relacionadas y compartir innecesariamente datos personales con estas plataformas.
  • Estrategia europea de ciberseguridad, que incluya el establecimiento de una unidad conjunta de ciberseguridad, una revisión de la Directiva sobre la seguridad de las redes y los sistemas de información (NIS) y un impulso al mercado único de ciberseguridad.

Protección de datos

La Comisión Europea reveló «Una estrategia europea para los datos» («A European strategy for data»)

El 19 de febrero de 2020, la Comisión Europea publicó su  estrategia de datos. . Según la Comisión, «los datos son el elemento vital del desarrollo económico», como «la base de muchos productos y servicios nuevos, que impulsan el aumento de la productividad y la eficiencia de los recursos en todos los sectores de la economía». Los datos no sólo permiten «productos y servicios más personalizados», sino que también permiten «una mejor elaboración de políticas» y mejoran los servicios gubernamentales. La estrategia de datos reconoce conceptos diferentes al acceso a los datos ejercido en los Estados Unidos y China, al tiempo que subraya la necesidad de que Europa encuentre su propio camino, «equilibrando el flujo y el amplio uso de los datos, al tiempo que se preservan unas elevadas normas de privacidad, seguridad y ética».

A fin de utilizar el potencial de la economía de datos en beneficio de las personas y la sociedad en general, la Comisión Europea se propone «crear un espacio único europeo de datos -un verdadero mercado único de datos, abierto a los datos de todo el mundo- en el que los datos personales y no personales, incluidos los datos comerciales sensibles, estén seguros y las empresas también tengan fácil acceso a una cantidad casi infinita de datos industriales de alta calidad».

Según la Comisión Europea, «actualmente no se dispone de suficientes datos para una reutilización innovadora, incluso para el desarrollo de la inteligencia artificial». Entre los obstáculos a la reutilización de datos en Europa figuran (entre otros) la fragmentación de los marcos jurídicos de los Estados miembros, la falta de incentivos económicos para el intercambio de datos entre empresas, los desequilibrios en el poder de mercado, la falta de formatos normalizados interoperables para la reunión y el procesamiento de datos de diferentes fuentes y los problemas que plantea la nube tanto del lado de la oferta como del de la demanda.

Como parte de su visión hacia una economía de datos reforzada, la Comisión Europea tiene la intención de poner en marcha:

  • Un marco legislativo para la gobernanza de los espacios comunes de datos europeos (en el cuarto trimestre de 2020) para «fomentar la interoperabilidad de los datos entre sectores y, cuando sea pertinente, dentro de los sectores» (centrándose en las actividades de normalización).
  • Ley de datos (2021), que, entre otras cosas, tiene por objeto incluir la revisión de la Directiva sobre bases de datos y una posible aclaración de la aplicación de la Directiva sobre la protección de los secretos comerciales (evaluación del marco jurídico de los derechos de propiedad intelectual de la UE).

El Comité Europeo de Protección de Datos (EDPB por sus siglas en inglés) proporcionó orientación sobre la aplicabilidad del RGPD (Reglamento Generaql de Protección de Datos) a los algoritmos injustos.

En su  respuesta a la solicitud de la diputada Sophie in ‘t Veld sobre la idoneidad del RGPD como marco legal para proteger a los ciudadanos de algoritmos injustos, el Comité Europeo de Protección de Datos (EDPB) puso en duda la validez general de una suposición común «de que cuantos más datos se utilicen para entrenar algoritmos, más precisos serán para predecir aquello para lo que fueron entrenados».

Según la EDPB, el enfoque de «maximización de datos» crea un incentivo para la recopilación y posterior procesamiento de datos potencialmente ilegales.

Los algoritmos son cada vez más complejos, lo que los hace menos transparentes, según el EDPB. En lo que respecta a la adopción de decisiones por los algoritmos, los principios generales consagrados en el artículo 5 del RGPD , «específicamente la legalidad, la equidad y la transparencia, la exactitud, la minimización de los datos y la limitación de la finalidad rigen el tratamiento de los datos personales, tanto al crear como al utilizar los algoritmos». El RGPD también exige que «toda persona que utilice un algoritmo para la adopción automática de decisiones, informe a los interesados de la existencia de este proceso y proporcione información significativa sobre su lógica, así como sobre el significado y las consecuencias previstas», según la EDPB. Por último, la EDPB considera que ya existe un amplio marco jurídico en torno a la protección de datos, y que es prematuro en este momento promulgar una legislación adicional en la esfera de la protección de datos dirigida a una tecnología específica. La atención debería centrarse más bien en el desarrollo de las normas existentes, especialmente los requisitos de transparencia y rendición de cuentas.

Ciberseguridad

La Comisión Europea anunció su Libro Blanco sobre Inteligencia Artificial

El 19 de febrero de 2020, la Comisión Europea publicó su «Libro Blanco sobre Inteligencia Artificial – Un enfoque europeo de la excelencia y la confianza»  («White Paper on Artificial Intelligence – A European approach to excellence and trust»).

Según el Libro Blanco, Europa debe esforzarse por crear un «ecosistema de excelencia» y un «ecosistema de confianza» al elaborar el marco normativo y reglamentario de la inteligencia artificial (IA).

Según la Comisión, las tecnologías de la IA tienen muchos beneficios públicos, por ejemplo, al «dotar de instrumentos adecuados para garantizar la seguridad de los ciudadanos a las autoridades encargadas de hacer cumplir la ley». En particular, ayudan a identificar la propaganda terrorista en línea y a «identificar objetos ocultos peligrosos o sustancias o productos ilícitos».

Sin embargo, la IA también plantea un cierto riesgo elevado para nuestra sociedad, según el Libro Blanco. De ahí que las tecnologías de la IA cambien el concepto de seguridad establecido actualmente en la UE por el marco jurídico pertinente.

Según el Libro Blanco, esos riesgos pueden estar vinculados a las ciberamenazas, a los riesgos de seguridad personal o a los riesgos derivados de la pérdida de conectividad.

A fin de apoyar la confianza de los consumidores en las tecnologías de la inteligencia artificial, sería conveniente que el próximo marco normativo de la UE sobre la inteligencia artificial abarque explícitamente determinados «requisitos clave». En la actualidad, los requisitos relativos a la transparencia, la trazabilidad y la supervisión humana de la adopción de decisiones en materia de algoritmos no están contemplados específicamente en ninguna legislación en vigor.

Además de proponer enmiendas a la legislación vigente (por ejemplo, la Directiva sobre la responsabilidad por la seguridad de los productos), «podría ser necesaria una nueva legislación específica sobre la IA».

Además, la Agencia  ENISA tiene previsto realizar un estudio del panorama de amenazas sobre la IA, a fin de alimentar la labor de la Comisión Europea sobre la IA. Tras la publicación del Libro Blanco, la Comisión Europea está  recopilando propuestas  de forma abierta. Existe una consulta pública que se prevé finalice el 31 de mayo de 2020.

La Comisión Europea tiene previsto abrir una consulta pública sobre las prioridades en la certificación de la ciberseguridad

En un acto sobre ciberseguridad celebrado en Bruselas, un representante de la Comisión Europea proporcionó cierta información sobre los actuales planes de certificación de la ciberseguridad que se están preparando, tras la aplicación de la Ley de ciberseguridad de la Unión Europea. La Ley sobre ciberseguridad establece el primer marco de certificación en toda la Unión Europea que prevé la introducción de planes de certificación de la ciberseguridad  para «productos, servicios y procesos de TIC».

En virtud de la Ley de ciberseguridad, se ha abierto una «vía para la certificación obligatoria», pero actualmente la prioridad es asegurarse de que se introduzcan los planes. Es necesario determinar las prioridades de los futuros planes en el Programa de Trabajo Permanente de la Unión, aprobado por la Comisión Europea.

La Comisión tiene previsto abrir una consulta pública sobre las prioridades del Programa de trabajo renovable de la Unión para finales del primer trimestre de 2020. Todo plan obligatorio que se introduzca en el futuro debe ir acompañado de la legislación pertinente, según la Comisión Europea. Todo plan obligatorio también debe estar justificado por la correspondiente evolución del mercado.

Comunicación de Mozilla a las Autoridades de Certificación

Deja un comentario

La Fundación Mozilla ha enviado una comunicación a  las Autoridades de Certificación para informar a las CAs que tienen certificados raíz incluidos en el programa de Mozilla en relación con acciones planificadas y las fechas prevista.

La comunicación a las CAs se ha enviado por correo electrónico al Punto de contacto principal  y a un alias de correo electrónico para cada CA del programa de Mozilla, y se les ha pedido que respondan a las siguientes 7 acciones planificadas:

  1. Leer y cumplir plenamente con la versión 2.7 de la Política de la Repositorio  Raíz de Confianza de Mozilla.
  2. Asegurarse de que sus CP y CPS cumplen con la sección 3.3 de la política actualizada que requiere indicar de forma adecuada cuando no aplica un apartado y el mapeo de los documentos de la política a los certificados de las CA.
  3. Confirmar su intención de cumplir con la sección 5.2 de la política de repositorio raíz de Confianza de Mozilla que requiere que los nuevos certificados de entidad final incluyan una extensión EKU que exprese su uso previsto.
  4. Verificar que sus declaraciones de auditoría cumplen los requisitos de formato de Mozilla que facilitan el procesamiento automatizado.
  5. Resolver los problemas con las auditorías de los certificados de CA intermedios que han sido identificados por el sistema automatizado de validación de informes de auditoría.
  6. Confirmar el conocimiento de los requisitos de informes de incidentes de Mozilla y la intención de proporcionar buenos informes de incidentes.
  7. Confirmar el cumplimiento de la versión actual de los requisitos básicos del foro de navegadores y CAs.

Los elementos de acción completos pueden leerse aquí. Las respuestas a la encuesta serán publicadas automática e inmediatamente por la CCADB.

Aunque la participación en el Programa de certificados de CA de Mozilla se somete al criterio de la Fundación Mozilla que puede excluir una CA discrecionalmente, parece que el mejor enfoque para salvaguardar la seguridad de los usuarios es trabajar con las CA como colaboradores, en vez de como adversarios, fomentando una comunicación abierta y franca, y que busque el encuentro al identificar formas de mejorar.

 

Material de estudio para la certificación profesional de Auditor EIdAS

2 respuestas

Próximamente TCAB publicará más detalles sobre las jornadas de formación previstas en 2020 para la certificación profesional de Auditor EIdAS.

Ya se ha publicado el contenido previsto de la formación pero todavía no se han publicado las fechas para los exámenes de certificación y aspectos como los requisitos para ser Auditor EIdAS en el esquema de TCAB.

Quienes deseen prepararse para esta cualificación profesional pueden descargarse y utilizar como material de estudio las guías publicadas por ENISA.

Aunque el material está en inglés, a continuación se relacionan algunos de los documentos disponibles indicando también la traducción del título al español:

Certificados cualificados en el Reino Unido tras el Brexit, cambios al #eIdAS

1 respuesta

Una vez que el Reino Unido abandone la Unión Europea, pasa a ser un tercer país, de modo que los prestadores de servicios electrónicos de confianza cualificados radicados en UK, dejarían de ser válidos como tales en Europa.

De todas formas, eso en realidad no va a suceder, porque, según indica la lista de confianza expedida en agosto de 2019 y válida hasta febrero de 2020, no existen prestadores cualificados en UK compatibles con eIdAS.

Los prestadores que figuran en la lista TSL únicamente proporcionan servicios de confianza ajustados la legislación nacional del Reino Unido que ni siquiera tienen vocación de interoperabilidad con los europeos.

En el momento actual operan los siguientes prestadores:

La normativa británica Electronic Identification and Trust Services for Electronic Transactions Regulations 2016 se aprobó el 1 de julio de 2016, justo cuando entraba en vigor el Reglamento EIDAS y se aplicó a partir del 22 de julio. Su publicación se realizó con posterioridad al referendum del Brexit.

El texto está claramente inspirado en el EIDAS y revoca la normativa «The Electronic Signatures Regulations 2002», al tiempo que modifica diversas normas:

  • «Electronic Communications Act 2000»,
  • «Medicines for Human Use (Clinical Trials) Regulations 2004»,
  • «National Health Service (General Medical Services Contracts) (Scotland) Regulations 2004»,
  • «National Health Service (Primary Medical Services Section 17C Agreements) (Scotland) Regulations 2004»,
  • «Hazardous Waste (Wales) Regulations 2005»,
  • «Defence and Security Public Contracts Regulations 2011»,
  • «Human Medicines Regulations 2012»,
  • «National Health Service (Pharmaceutical and Local Pharmaceutical Services) Regulations 2013»,
  • «National Health Service (Pharmaceutical Services) (Wales) Regulations 2013», l
  • «Reservoirs Act 1975 (Capacity, Registration, Prescribed Forms, etc.) (England) Regulations 2013»,
  • «Electronic Documents (Scotland) Regulations 2014»,
  • «European Union (Recognition of Professional Qualifications) Regulations 2015»,
  • «National Health Service (Charges for Drugs and Appliances) Regulations 2015»,
  • «National Health Service (General Medical Services Contracts) Regulations 2015»,
  • «National Health Service (Personal Medical Services Agreements) Regulations 2015»,
  • «Public Contracts Regulations 2015»,
  • «Public Contracts (Scotland) Regulations 2015»,
  • «Concession Contracts (Scotland) Regulations 2016»,
  • «Utilities Contracts Regulations 2016»,
  • «Utilities Contracts (Scotland) Regulations 2016»,

Posteriormente en 2018 se aprobó la normativa «The Electronic Identification and Trust Services for Electronic Transactions (Amendment etc.) (EU Exit) Regulations 2018». Esta norma retiene el Reglamento UE 910/2014 (EIDAS) como propio, pero cambiando ciertos textos para que sea una normativa nacional.

En la modificación del artículo 24 establece que los servicios y prestadores cualificados en el marco de la normativa de la Unión Europea se reconocen como cualifcados en la normativa británica tras el Brexit.

Además se indica la derogación de diversa normativa europea que ya no será aplicable en el Reino Unido:

  • Commission Decision 2009/767/EC
  • Commission Decision 2010/425/EU
  • Commission Decision 2011/130/EU
  • Commission Implementing Decision 2013/662/EU
  • Commission Implementing Decision 2014/148/EU
  • Commission Implementing Decision (EU) 2015/296
  • Commission Implementing Regulation (EU) 2015/806
  • Commission Implementing Regulation (EU) 2015/1501
  • Commission Implementing Regulation (EU) 2015/1502
  • Commission Implementing Decision (EU) 2015/1505
  • Commission Implementing Decision (EU) 2015/1984

Se aplican, de forma modificada:

  • Commission Implementing Decision (EU) 2015/1506
  • Commission Implementing Decision (EU) 2016/650

Por resumir, el reconocimiento mutuo a nivel de medios de identificación y autenticación no proseguirá tras el Brexit, pero los servicios electrónicos de confianza cualificados de la Unión Europea seguirán siendo válidos en el Reino Unido. Lo contrario no es cierto mientras el Reino Unido no inicie un procedimiento específico según lo previsto en el artículo 14 del Reglamento eIdAS.

En 2019 se ha publicado la normativa «The Electronic Communications (Amendment etc.) (EU Exit) Regulations 2019» que tiene que ver con los procedimiento de notificación de incidentes de seguridad, especialmente en relación con la normativa de protección de datos, pero que no incide directamente en los servicios de confianza.

INDOTEL aprueba el nuevo marco regulatorio para servicios de certificación digital y confianza en República Dominicana, alineado con el #eIdAS

Deja un comentario

Mediante la Resolución No. 071-19 del Consejo Directivo INDOTEL aprobó la Norma Complementaria por la que se establece la equivalencia regulatoria del sistema dominicano de Infraestructura de Claves Públicas y de Confianza con los marcos regulatorios internacionales de servicios de confianza, así como la Norma Complementaria sobre Procedimientos de Autorización y Acreditación.

Indotel-ogoEsta actualización del marco normativo de la Ley 126-02 sobre Comercio Electrónico Documentos y Firmas Digitales se ha desarrollado para modernizar el mercado de servicios electrónicos de confianza de la República Dominicana y para adaptarlo al surgimiento de nuevas tecnologías, de forma tal que sean instrumentos realmente eficientes para la aplicación de los distintos agentes involucrados en la prestación de estos servicios electrónicos.

Por decisión del regulador, la citada normativa está específicamente alineada con las mejores prácticas internacionales en la materia, tomando como referencia el modelo europeo para la prestación de servicios electrónicos de confianza, definido en el Reglamento (UE) N.º910/2014 del Parlamento Europeo y del Consejo, de fecha 23 de julio de 2014, relativo a la identificación electrónica y los servicios de confianza en las transacciones electrónicas en el mercado interior y por el que se deroga la Directiva 1999/93/CE (habitualmente denominado eIDAS) y en los estándares técnicos establecidos en los organismos de normalización como el Instituto Europeo de Normas de Telecomunicación (ETSI) y el Comité Europeo de Normalización (CEN).

Junto con el interés por aprovechar el desarrollo de estándares de la Unión Europea, el nuevo modelo regulatorio enfatiza también su compatibilidad  con otros estándares regionales impulsados por organizaciones como el Foro de Autoridades de Certificación y Programas de Exploración de Internet (CA/B Forum en inglés), que coordina la evolución de los certificados para sitio web de confianza pública, según los tipos acuñados de validación de dominio, validación de organización y validación extendida.

Se espera que la adopción de este nuevo modelo regulatorio,  favorezca  la interoperabilidad internacional, para lo que crea una implementación normativa de referencia que podría estudiarse por otros países, latinoamericanos o no, para facilitar la aplicación del artículo 14 del Reglamento EIDAS y por tanto el establecimiento de listas TSL no solo europeas sino globales.

En resumen, la norma publicada permite a la República Dominicana:

  • Ampliar el espectro de servicios de certificación digital que hasta a fecha contemplaba la normativa vigente, para incluir los que se detallan en el Reglamento europeo eIDAS, por ejemplo, servicios de confianza cualificados de: creación de firmas y sellos electrónicos a partir de certificados cualificados y dispositivos de creación de firmas cualificados, o servicios electrónicos de entrega cualificados;
  • La ubicación e instrumentación de listas de confianza TSL de prestadores nacionales que, una vez serán cursado el procedimiento previsto en el artículo 14 del Reglamento europeo eIDAS podrán ser incluidos en la lista de confianza europea, con un mecanismo de reciprocidad;
  • El reconocimiento mutuo de prestadores cualificados de confianza europeos y prestadores de servicios de confianza dominicanos, consecuencia del procedimiento del artículo 14 citado.;
  • Ampliar los servicios de confianza a otros como: servicio cualificados de validación y conservación de firmas cualificadas; servicios cualificados de sellos electrónicos,  y los servicios de certificados para la autenticación de sitios web, etc.; y
  • Aumentar la competitividad de las entidades dominicanas de confianza digital favoreciendo su posicionamiento en mercados como los europeos y abriendo los servicios de confianza a un mercado mayor.

Algunos de los aspectos contemplados en la norma son:

  • La posibilidad de desarrollar sistemas de identificación remota, por ejemplo los basados en videoconferencia o videograbación.
  • La posibilidad de prestar servicios de firma y sello electrónicos a distancia, bajo control del firmante o del titular del sello electrónico
  • La posibilidad de que la evaluación de conformidad la pueda realizar un organismo de evaluación de conformidad acreditado por el ODAC (Organismo Dominicano de Acreditación) admitiendo entidades acreditadas por otros organismos de acreditación como los europeos, sin perjuicio de la capacidad inspectora y de auditoría del propio INDOTEL.

En consecuencia, la aprobación de la Resolución No. 071-19 se suma a los desarrollos normativos previos del INDOTEL que siempre han buscado el desarrollo e impulso del comercio electrónico a nivel de la República Dominicana, y que además auspicia un régimen de reconocimiento mutuo entre estados y una mayor interoperabilidad entre prestadores de servicios de confianza a nivel internacional, colaborando en la  armonización de las normas jurídicas y técnicas de los servicios de confianza.

Desde Europa se ve este desarrollo normativo como un gran paso para la interoperabilidad global, y como ejemplo para otros países.

Referencia:

Artículo de D. Cesar Moliné publicado en LinkedIn.

 

Se traslada la LLC «Lista de listas» de servicios de confianza de eIdAS

Deja un comentario

En relación con el Reglamento UE 910/2014 (eIdAS) la Comisión Europea ha publicado el cambio de ubicación de la «lista de las listas de confianza» (LLC, en inglés: LOTL – List of Trusted Lists’), así como su último conjunto de certificados que respaldan la firma o el sello electrónicos de la LLC en el Diario Oficial de la Unión Europea: Información relativa a los datos sobre las listas de confianza de los Estados miembros notificada en virtud de la Decisión de Ejecución (UE) 2015/1505 de la Comisión (2019/C 276/01).

La publicación en el Diario Oficial de la ubicación de la LOTL y el conjunto de certificados de firma de la LOTL (denominados en español «certificados de firma de la LLC») no será necesaria si se producen futuros cambios de ubicación en base a otra decisión de la Comisión de modificar la ubicación de LOTL o el conjunto de certificados, ya que los futuros cambios podrán quedar refejados en la propia LOTL. De esta forma,  los sistemas que usan la LOTL en su verión XML para tratamiento automatizado de datos podrán ir actualizando las veriones sucesivas también de forma automatizada.

La nueva LLC supone un hito de procesamiento que conecta una LLC con las sucesivas a lo largo del tiempo (en inglés se denomina Pivot Point) de forma que queda la traza y se conserva cada una de las ubicaciones anteriores, incluyendo los juegos de certificados electrónicos de firma o sello, con los que se securiza la lista. La cadena de hitos de LLC refleja la cadena de cambios.

La primera publicación electrónica a partir de la publicación en el Diario Oficial supone el primer hito (el primer pivote) y su versión inicial refleja la misma información respecto a las listas de confianza de los países de la Unión Europea que se incluía en el modelo de infomación anterior.

La primera emisión de un LOTL anclada a la nueva publicación del Diario Oficial, con una cadena vacía de LOTL pivote, está programada para el 4 de septiembre de 2019.

La LOTL continuará publicándose en paralelo en las ubicaciones definidas en el modelo anterior de publicidad de listas junto con las nuevas. Se prevé que la publicación en paralelo se extienda,  al menos, hasta finales de 2019.

Estos cambios hacen necesario que los sistemas de validación y comprobación de firmas electrónicas y de sellos electrónicos se actualicen para poder gestionar en el futuro el «origen de confianza» de los certificados raiz de los prestadores de servicos electrónicos de confianza cualifiados que se reflejan en las listas de los paises, a las que se llega a partir de la LOTL.

Los certificados utilizados en este primer hito, en formato PEM, son.

1.
—–BEGIN CERTIFICATE—–

MIIGZzCCBE+gAwIBAgIQEAAAAAAAH6yPXvnVxqcEcDANBgkqhkiG9w0BAQUFADAzMQswCQYDVQQGEwJCRTETMBEGA1UEAxMKQ2l0aXplbiBDQTEPMA0GA1UEBRMGMjAxNTA4MB4XDTE1MDUwMTE4NTQ1NFoXDTI1MDQyNTIzNTk1OVowczELMAkGA1UEBhMCQkUxJzAlBgNVBAMTHkplYW4tTWFyYyBWZXJiZXJndCAoU2lnbmF0dXJlKTERMA8GA1UEBBMIVmVyYmVyZ3QxEjAQBgNVBCoTCUplYW4tTWFyYzEUMBIGA1UEBRMLNjcwMjIzMzAzNDAwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCwbnf998lxC5nc7YZUhnMIQ+n3VAjrFU2IOIzmHHSJ6aMASYOMYOlLx7XDrjbmh/MyhlpGYmNsF0iLwEYWXNwF4ChmfHqvoI/P29aqNkcojV2cFpZj+ocgnyf+f2cwn3z/kGh9kI6x4eS5IroFpABvzxWi0WD3W7wSJKyeRoMaGOtw07iA43S4fjDzjkKTYGor6PIOv6UtCfrZqPjTg+822kFhERz/3KiqSn2Hx324IIN/mZCSDd5ixKl0tdCsX+bPbXJI4tOyE0RDUl5/+iMAQWjli45opKj8eTMx2kmSycw9Du4zkFzgnp81XGDqEHZp53wSg8uZ5QR8EUjU3xNbAgMBAAGjggI1MIICMTAfBgNVHSMEGDAWgBRqb1HlzCddZQnuqBsSlAPwQKAI8jBwBggrBgEFBQcBAQRkMGIwNgYIKwYBBQUHMAKGKmh0dHA6Ly9jZXJ0cy5laWQuYmVsZ2l1bS5iZS9iZWxnaXVtcnMzLmNydDAoBggrBgEFBQcwAYYcaHR0cDovL29jc3AuZWlkLmJlbGdpdW0uYmUvMjCCARgGA1UdIASCAQ8wggELMIIBBwYHYDgKAQECATCB+zAsBggrBgEFBQcCARYgaHR0cDovL3JlcG9zaXRvcnkuZWlkLmJlbGdpdW0uYmUwgcoGCCsGAQUFBwICMIG9GoG6R2VicnVpayBvbmRlcndvcnBlbiBhYW4gYWFuc3ByYWtlbGlqa2hlaWRzYmVwZXJraW5nZW4sIHppZSBDUFMgLSBVc2FnZSBzb3VtaXMgw6AgZGVzIGxpbWl0YXRpb25zIGRlIHJlc3BvbnNhYmlsaXTDqSwgdm9pciBDUFMgLSBWZXJ3ZW5kdW5nIHVudGVybGllZ3QgSGFmdHVuZ3NiZXNjaHLDpG5rdW5nZW4sIGdlbcOkc3MgQ1BTMDkGA1UdHwQyMDAwLqAsoCqGKGh0dHA6Ly9jcmwuZWlkLmJlbGdpdW0uYmUvZWlkYzIwMTUwOC5jcmwwDgYDVR0PAQH/BAQDAgZAMBEGCWCGSAGG+EIBAQQEAwIFIDAiBggrBgEFBQcBAwQWMBQwCAYGBACORgEBMAgGBgQAjkYBBDANBgkqhkiG9w0BAQUFAAOCAgEAJ9OdfZ1C/G+mWS/MaTIK80oGEjapyYgZnXxJ5sFuUGv4oKev2Tq9FwzeKTpo+ufb6chMSWDguX+HkkwBlCj8Dt3ND4FFDzAsgoGnorKuWkO54Pa8KpXEb7OjsWvMnJhz2iG/rEnm7b2QjN/jxbS7ZzCJhW6mXuQ1K9FUnO6VzBV59N3KdoIUEEXZlPMVYhlQEJPG3PsmMXUwcQthDQgRpgbyiPPtzUJdS86dZu0eRds2xjAAzl7EVnHvSVcBFwaikB9YuECb7NfjD9yU+WshStCjvZb1aW9qGQXb5RrWP2kdKe6VMKsQh9dwpXPZ0cFABK9IJxAJB0vhV0JKD9FtcCJ4GA8oxX5Ul57oHGeFBVazT+OKaaNwNM/1zpowv6QwYowX4Y9NZJ/CYRkMNeNwCuB88mvDvIZY/a/IZTzVwqX2KuGZeFTJInN8esUu1uROd3jRkguSs93R/6Ch8xOS6uyeNY7IyrlW9IbSJ6Sza9viZRN8FhQARNa0sLPwXeX2zHUQ1xLSU2+E0E7ruBtMT0o5jTbViDmrmSb0PPmbSRnBlLsjf8PcgKkRzrGUDWfhoGnqu4dJs3uipwsPPVaoInZ26DIPgEDlneLmYi9Kt3T+yxG57lOq8E9Ip6HzBeiTXKGB+C5o484w32E97mtnP6dvMLL7VsoyegfJhO/3/lU=

—–END CERTIFICATE—–

 

2.
—–BEGIN CERTIFICATE—–

MIIHATCCBOmgAwIBAgIDGpmWMA0GCSqGSIb3DQEBCwUAME4xCzAJBgNVBAYTAkxVMRYwFAYDVQQKDA1MdXhUcnVzdCBTLkEuMScwJQYDVQQDDB5MdXhUcnVzdCBHbG9iYWwgUXVhbGlmaWVkIENBIDMwHhcNMTYwOTE1MDkwMDEyWhcNMTkwOTE1MDkwMDEyWjCB/TELMAkGA1UEBhMCQkUxCzAJBgNVBAcTAkJFMRwwGgYDVQQKExNFdXJvcGVhbiBDb21taXNzaW9uMRUwEwYDVQQLEwwwOTQ5LjM4My4zNDIxHDAaBgNVBAMTE01hYXJ0ZW4gSm9yaXMgT3R0b3kxDjAMBgNVBAQTBU90dG95MRYwFAYDVQQqEw1NYWFydGVuIEpvcmlzMR0wGwYDVQQFExQxMDMwNDQ0NDExMDA4MDgzNzU5MjEpMCcGCSqGSIb3DQEJARYabWFhcnRlbi5vdHRveUBlYy5ldXJvcGEuZXUxHDAaBgNVBAwTE1Byb2Zlc3Npb25hbCBQZXJzb24wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCyUn5NvdLXpWSAPF7S+tOy/M6uY8Un5sNt2cHIOs/OHvcfY+ghBXwz91EffNXku2RKqwgw3+dyRBI1eOq2l7r0z9dgNd40zB7a/p. 9M10SsDT41MJB5iQRYE4kQ73FGA61oXD530fYNzxCA9dWXzQ40L+wdpPbrVtfgi+pRTZSXocZF2VHpuiPEVexHPHt68rX/G8pYHg7zmYOEBPLsjjQAwbrVZIKb9Ypgkwb4ziaFg6UZemMfRtl7S08UWjjhOUUjZ+216ie9V6cMSXzg+5Co9HVSXPdqooNhMrOShTI7IzDja3rXAcw6TkvPDgZEpCJZ73HCxz+DWnW7D2JuXMelAgMBAAGjggI2MIICMjAMBgNVHRMBAf8EAjAAMGYGCCsGAQUFBwEBBFowWDAnBggrBgEFBQcwAYYbaHR0cDovL3FjYS5vY3NwLmx1eHRydXN0Lmx1MC0GCCsGAQUFBzAChiFodHRwOi8vY2EubHV4dHJ1c3QubHUvTFRHUUNBMy5jcnQwggEeBgNVHSAEggEVMIIBETCCAQMGCCuBKwEBCgMBMIH2MIHHBggrBgEFBQcCAjCBuhqBt0x1eFRydXN0IFF1YWxpZmllZCBDZXJ0aWZpY2F0ZSBvbiBTU0NEIGNvbXBsaWFudCB3aXRoIEVUU0kgVFMgMTAxIDQ1NiBRQ1ArIGNlcnRpZmljYXRlIHBvbGljeS4gS2V5IEdlbmVyYXRpb24gYnkgQ1NQLiBTb2xlIEF1dGhvcmlzZWQgVXNhZ2U6IFN1cHBvcnQgb2YgUXVhbGlmaWVkIEVsZWN0cm9uaWMgU2lnbmF0dXJlLjAqBggrBgEFBQcCARYeaHR0cHM6Ly9yZXBvc2l0b3J5Lmx1eHRydXN0Lmx1MAgGBgQAizABATAiBggrBgEFBQcBAwQWMBQwCAYGBACORgEBMAgGBgQAjkYBBDALBgNVHQ8EBAMCBkAwHwYDVR0jBBgwFoAUY4/CiwOxq47YU0eWHZmoffasqHUwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC5sdXh0cnVzdC5sdS9MVEdRQ0EzLmNybDARBgNVHQ4ECgQIR8OxCQGxgiswDQYJKoZIhvcNAQELBQADggIBACWb5+Xt6sOaxE8bpakXFo2BoWYphyq5XAXRM6e7QDS57CaHW8Ly6ep0I23EZ3KcI3mpqg2UDaEZhGhvnE/SVEyh4go6E8Hljv9iyrdGccc+RgTM87rbkoUi6sZ+BcLlG7WNo2c5BqRyElch5o1/9AEnft3inLK4R47BHtbRkf/FkptiQWjSVzJ6LEHIi8EF215Qg5X/yaUQdxIfMPcQ580rGujGN/Dl2H9rxBUdPUCO0i7zbPeJtfah1zSXxYjy9V4x2Q+cVbcMpa5fSys9c/YQA6XAkA5oKrkSsjCGBULDi2APC3FMehp6BcI/5k202iwebq3xgDWFvuD+swgZ8P0YxS4dZMcjtseYvzGCArFEcoI7buZb30A/Z7K3qx3D895NHupfz20dskujjCV7PVgxx0PCXJPBquuPFV+aYgDCLr7XQMmU8wo0HGKZ/mXThY2F2POLF0uKgY6F5mZBIhRYU5IgybGrayqEpaEcr8LMBKzr2DRpLzDojU5k9apmVnoQJ2cSfTrQ87ZXOaG+6h/Md6cVaUI0J8iOpFLinKRGRBEkwE+pxFE2tOoyaK9iLKurRYdfd8WETatEsEyi4o4CFPD//bthgwvSl0Cfrkj8V5lIR13140D+NQtX0vSx/PHq5ySOKq9ZPUo42r8ihX/ZP0Z+Vrg5ATqpSCcqn01Z

—–END CERTIFICATE—–

 

3.
—–BEGIN CERTIFICATE—–

MIIHDjCCBPagAwIBAgIDHiEoMA0GCSqGSIb3DQEBCwUAME4xCzAJBgNVBAYTAkxVMRYwFAYDVQQKDA1MdXhUcnVzdCBTLkEuMScwJQYDVQQDDB5MdXhUcnVzdCBHbG9iYWwgUXVhbGlmaWVkIENBIDMwHhcNMTcwNTExMTAyNzI1WhcNMjAwNTExMTAyNzI1WjCCAQkxCzAJBgNVBAYTAk5MMQswCQYDVQQHEwJCRTEcMBoGA1UEChMTRXVyb3BlYW4gQ29tbWlzc2lvbjEVMBMGA1UECxMMMDk0OS4zODMuMzQyMSEwHwYDVQQDExhNaWNoYWVsIFRoZW9kb29yIGRlIEJvZXIxEDAOBgNVBAQTB2RlIEJvZXIxGTAXBgNVBCoTEE1pY2hhZWwgVGhlb2Rvb3IxHTAbBgNVBAUTFDEwMzAzOTY5NDUwMDg1MDQ2NDI0MSswKQYJKoZIhvcNAQkBFhxtaWNoYWVsLmRlLWJvZXJAZWMuZXVyb3BhLmV1MRwwGgYDVQQMExNQcm9mZXNzaW9uYWwgUGVyc29uMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAq2G70g/Tsyt8nyI1PXYHgIm6a6DawB2ATZMsMxkS1flXjkPNMd/e1Go/G1+IFsqA6iBlfxmFhABJa9FbFallOMBrE3Ao0SdHpT4UbrhVyWx5iV/DjInxPMCzx3Przus3CVy7YhKHO9Jt/qPruWeLCf3YFMV8N02lig904Vbc6pxjx5yqKij7skHSiMyAzdgw/VIQZjJF8PiA10eguvwgS/BU6ip5M03DoGOZPBvIt3q/Av4YHtd7LaOFTYl/zRcn2f12FqO4JMiNR5LxfByRbMmUJQe8sjtC0/ho7cG3BWuusLUe/LtQIGCT/uXXdF9qKuOiPDQ3OpfhJIhElaJPpwIDAQABo4ICNjCCAjIwDAYDVR0TAQH/BAIwADBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9xY2Eub2NzcC5sdXh0cnVzdC5sdTAtBggrBgEFBQcwAoYhaHR0cDovL2NhLmx1eHRydXN0Lmx1L0xUR1FDQTMuY3J0MIIBHgYDVR0gBIIBFTCCAREwggEDBggrgSsBAQoDATCB9jCBxwYIKwYBBQUHAgIwgboagbdMdXhUcnVzdCBRdWFsaWZpZWQgQ2VydGlmaWNhdGUgb24gU1NDRCBjb21wbGlhbnQgd2l0aCBFVFNJIFRTIDEwMSA0NTYgUUNQKyBjZXJ0aWZpY2F0ZSBwb2xpY3kuIEtleSBHZW5lcmF0aW9uIGJ5IENTUC4gU29sZSBBdXRob3Jpc2VkIFVzYWdlOiBTdXBwb3J0IG9mIFF1YWxpZmllZCBFbGVjdHJvbmljIFNpZ25hdHVyZS4wKgYIKwYBBQUHAgEWHmh0dHBzOi8vcmVwb3NpdG9yeS5sdXh0cnVzdC5sdTAIBgYEAIswAQEwIgYIKwYBBQUHAQMEFjAUMAgGBgQAjkYBATAIBgYEAI5GAQQwCwYDVR0PBAQDAgZAMB8GA1UdIwQYMBaAFGOPwosDsauO2FNHlh2ZqH32rKh1MDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwubHV4dHJ1c3QubHUvTFRHUUNBMy5jcmwwEQYDVR0OBAoECED2Gny4nY/ZMA0GCSqGSIb3DQEBCwUAA4ICAQBvdAp4qOITVgjyiZkdUMoQC5HPDvptyJrF+j4aZmCIYbg8UEy5RqurLv5icKUWjp0nYO8Qq4drrMGHbOMlWiVZ6yUiy8oXv62gv/hiSGGrwDKekfZcJ3K9wUT50TaM3sROmY0BzbYqatsDOoHb2BwhNMooFwo+sUZ+5Qt1Lv+FMLKHxeO9rM4ezXPO8Vsfh6d5zddGl29WrxbBZj7bp3cfSBHJa1t6NIIr5+sU9Xu+GvTSXuSSht3kmVU9ofctXetQ8Qq+mxPwPhNTyNu8IaQgQQBnWTMb6PQgtIaWOJak9mpRhvvlH9+sdIjNvGO46BCNykUPu4Mdgi0Zq5rsoCJUp5EpUWrAmdM5yMufMMKXqW8XHqU0KsTGyBcIkoElmhvtCQBBTfE5vh7yOS6hYpzTop9fLTJ+uQJI14DTOu+iVSmw5Oh8AYTPKh5wzKkEWTiq5Z0KiwmmOIxo8T9Ytlhsae/7aO1nC3WxFKaqWAFQx5UPIs4bQ0rRW39n1T6PovJxkKTPEW6TPmYrYjR2DYlsSnIbR9ebHUbRB/v/o9Pvqx6dArlpVuhDWWDjuAT1bW3ej+/jIJGyQtwKqL9fnDcmuUqzoBa9fXJuB1e8m3+tI1H5e9F/JH3kdkPsrV9DMS13+MYIeQJgAK3ofJcuKCKYQ5uUEZaU2CKiR6TzvzzGqQ==

—–END CERTIFICATE—–

 

4.
—–BEGIN CERTIFICATE—–

MIIGlTCCBH2gAwIBAgIDMg6dMA0GCSqGSIb3DQEBCwUAME4xCzAJBgNVBAYTAkxVMRYwFAYDVQQKDA1MdXhUcnVzdCBTLkEuMScwJQYDVQQDDB5MdXhUcnVzdCBHbG9iYWwgUXVhbGlmaWVkIENBIDMwHhcNMTgwMjIwMTI1MjIxWhcNMjEwMjIwMTI1MjIxWjCCAQ0xKzApBgkqhkiG9w0BCQEWHGFkcmlhbi5jcm9pdG9ydUBlYy5ldXJvcGEuZXUxCzAJBgNVBAYTAlJPMQswCQYDVQQHEwJCRTEcMBoGA1UEChMTRXVyb3BlYW4gQ29tbWlzc2lvbjEVMBMGA1UECxMMMDk0OS4zODMuMzQyMSMwIQYDVQQDExpDb25zdGFudGluLUFkcmlhbiBDcm9pdG9ydTERMA8GA1UEBBMIQ3JvaXRvcnUxGjAYBgNVBCoTEUNvbnN0YW50aW4tQWRyaWFuMR0wGwYDVQQFExQxMDMwNDM4NzU0MDEwNjEwMTc0MDEcMBoGA1UEDBMTUHJvZmVzc2lvbmFsIFBlcnNvbjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKUebuK3GcmFVx01U3T3ex4VNteTsj9Cl0uaRROF8k7t9F48AG0RL1Pu1qwGGcmEz3mP0oV4m/TqkQt0YIkN1DS8aJHrBgWUxoO4F7NUc9EtlOIN0QgT/GXdYm4zUojyMPkW7FcW5OiaJV/LtSBVOw5/gRmaGH5/gdxE37lHq9V9rFKC2erUSbWXQB5uXsxMyzx1tJgV81WHpkn4OCIxFSjZDiYuZdpUZaE56zh8vZS5L22EHwCdUfxVTo5yeK7AHA2nKtXEn80eDb96cAuWuAoOiiJtjU6lx96iJQ99QLi2qhX+Tu+9YxlS5hPpxjBGhWkhgWZaMFE5cmdbeUGRRWUCAwEAAaOCAbkwggG1MB8GA1UdIwQYMBaAFGOPwosDsauO2FNHlh2ZqH32rKh1MIGBBggrBgEFBQcBAwR1MHMwCAYGBACORgEBMAgGBgQAjkYBBDBIBgYEAI5GAQUwPjA8FjZodHRwczovL3d3dy5sdXh0cnVzdC5sdS91cGxvYWQvZGF0YS9yZXBvc2l0b3J5L1BEUy5wZGYTAkVOMBMGBgQAjkYBBjAJBgcEAI5GAQYBMGYGCCsGAQUFBwEBBFowWDAnBggrBgEFBQcwAYYbaHR0cDovL3FjYS5vY3NwLmx1eHRydXN0Lmx1MC0GCCsGAQUFBzAChiFodHRwOi8vY2EubHV4dHJ1c3QubHUvTFRHUUNBMy5jcnQwTgYDVR0gBEcwRTA4BggrgSsBAQoDGjAsMCoGCCsGAQUFBwIBFh5odHRwczovL3JlcG9zaXRvcnkubHV4dHJ1c3QubHUwCQYHBACL7EABAjAzBgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLmx1eHRydXN0Lmx1L0xUR1FDQTMuY3JsMBEGA1UdDgQKBAhGofvti7EAqjAOBgNVHQ8BAf8EBAMCBkAwDQYJKoZIhvcNAQELBQADggIBAHRVNf1uz9NJu6F3eBbwqlqA1RugR+z9wKuGno/8cF8eCv+iCjf8c3TrWjuJKBoyBlMxEwU8MmBElEMAaSNdWDBQWS8vD0kibHLjz0WfwHJgKZBUhW9W8250PF3yU/Z9kh/dDBLbDvWoqYnzQbBd+4BnnLUH2iQpGF4Cqw0hmclgr0Ld4QJ1h1HuXhjJKt3iQAlmrE75dzZEkmxQzuzY+cQxxu/xRkLUTpScdKDtCiylKW6JBHCFpZaqlGY7vIy1n//LYzd3nWmyRYF26/J6rnkdd/P78BzK72xXoMa0klF4dZfHtMCQw/jbFAM4xB0245pqZeYZYo9fdd2XCqEVSp9DcNTTOI+BwXnuM+xFmr5PTuZ7LPQ/FtJIzJT4KqZRovQ/IgddwJk/sxq/Y73ZIg5qMisBGqQvAwohjYyQ8MC8NI8zlDPLj5+lTcX5ATmxzgpi0XoUsA9sv4tvVEgj4EBUmNi0UWPMYIvsIehx43f9YmW/kjA8Q0ado6DWZh1H9ama/wvq+dZoBEW8zg62RX///CWUtUCj8c6kauFFyCF9ZVgRP4Ec3h/aWP8SPN79pBUHXEpceh3sbl3ReOIS/ZtddB2aCwWtTv9zSdnM0Bb3C4wfDsvc4lsMIRBkB8B+cl60jE1tHCJq8+VDKMKTukJCA0ny/13Ln+tTFU0qoOgr

—–END CERTIFICATE—–

 

5.
—–BEGIN CERTIFICATE—–

MIIGiDCCBXCgAwIBAgIQaED4tIulqHJbg9RoxVfK+jANBgkqhkiG9w0BAQsFADBcMQswCQYDVQQGEwJFUzEoMCYGA1UECgwfRElSRUNDSU9OIEdFTkVSQUwgREUgTEEgUE9MSUNJQTENMAsGA1UECwwERE5JRTEUMBIGA1UEAwwLQUMgRE5JRSAwMDEwHhcNMTgwODI3MTAzNzI3WhcNMjAwODI3MTAzNzI3WjBqMQswCQYDVQQGEwJFUzESMBAGA1UEBRMJMzgxNDQ2NTRNMQ8wDQYDVQQEDAZCVVJHT1MxDjAMBgNVBCoMBU9TQ0FSMSYwJAYDVQQDDB1CVVJHT1MgUEFMT01BUiwgT1NDQVIgKEZJUk1BKTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALw60PnYzRKiVQ9g8XHWpx7Mrx6ET99Q2/XBUgU0V4n9HDme9PTN1VU+0cmHwDvad8iWAiwoz3O77tMF17d1PYvJoMSqKhOYyrvxHiDFeAXnsCr4noENQQpiCbT80pPIW7qX9xLdJL+hpP2SGW2xk7CRJ+wwy9ewhySJVgQ8tH3tEoit3H7eXXYcigN5bUzNUhFkY1J0P1a6SyXX9V8/Kg1SrdWYji3d+ Ia1GG0CGKNABmbjlNqb0KiT7Ua/ra25CXutQCDNzj+5noWOjaZ0nPBneyhp/4CXma0W5ugi63W0zr5 p. 99CG3ejOKUMzdGfOmSQVWAmhPn9Q0Q7nzBqE44ECAwEAAaOCAzYwggMyMAwGA1UdEwEB/wQCMAAwHQYDVR0OBBYEFJAT0XlvtTHto3Wxfvn82fLUpZHsMB8GA1UdIwQYMBaAFBqJqMXuj3ZdVXGJ8zs1vaoFAJVvMIGQBggrBgEFBQcBAwSBgzCBgDAIBgYEAI5GAQEwCAYGBACORgEEMBMGBgQAjkYBBjAJBgcEAI5GAQYBMEgGBgQAjkYBBTA+MB0WF2h0dHBzOi8vd3d3LmRuaWUuZXMvcGRzEwJlbjAdFhdodHRwczovL3d3dy5kbmllLmVzL3BkcxMCZXMwCwYGBACORgEDAgEPMF8GCCsGAQUFBwEBBFMwUTAfBggrBgEFBQcwAYYTaHR0cDovL29jc3AuZG5pZS5lczAuBggrBgEFBQcwAoYiaHR0cDovL3d3dy5kbmllLmVzL2NlcnRzL0FDMDAxLmNydDB9BgNVHSAEdjB0MHIGCGCFVAECAgIDMGYwIgYIKwYBBQUHAgEWFmh0dHA6Ly93d3cuZG5pZS5lcy9kcGMwQAYIKwYBBQUHAgIwNAwyRElSRUNDScOTTiBHRU5FUkFMIERFIExBIFBPTElDw41BLCBWQVRFUy1TMjgxNjAxNUgwgfAGCCsGAQUFBwECBIHjMIHgMDICAQEwCwYJYIZIAWUDBAIBBCAwUUYFyZJGyR1D4JgERkESSKZr0r0cbCfKbDtrF6AkRDAyAgEAMAsGCWCGSAFlAwQCAQQgFtIcqpTy1MUjIRV82AcM7DljtnO6JkYYpOYuvQB25iswOgYJYIVUAQICBAIBMAsGCWCGSAFlAwQCAQQgO449boTpr1MEM+n+II5PTew4l85rQC5jf8fVpx6sYHUwOgYJYIVUAQICBAIGMAsGCWCGSAFlAwQCAQQgzFPwjmVxH4i/kytghdWzW+1MuMb3bYpkihr1R1ZB+/UwKAYDVR0JBCEwHzAdBggrBgEFBQcJATERGA8xOTc4MDYyMzEyMDAwMFowQgYIYIVUAQICBAEENjA0MDICAQIwCwYJYIZIAWUDBAIBBCAvRtDJFzmzSfcsNHkxS7x8ondm2dtB/XI0tqyWUl2d3DAOBgNVHQ8BAf8EBAMCBkAwDQYJKoZIhvcNAQELBQADggEBACO4yfrwqFM8qMjN3FUgk4AgMK+lliATakVI7qQyFh5P3hG26rH/x1wCGAWPtkeUImLIxZcRfYwA0Sn7ro2k6y1xEtUo2L0SOf/Lsmpq1d2VQBNjagyHng0fqKECmHRLVeYmKUYdG9F2TesLfk4cAf11UiOaSPNv+wYQdhF60FOJnZeR1oRUWpMml4mVaxPd2Zh8qqp8E3MTTmDC7v1dcWJAHyCCAeOeVjZw50su5kalA7LOGr1K6RhYjO9SOHIF32lBEaMWzl7jNW8AXpexu40now1xWdISG2nngs28l811VaZIFUQTjPP9qvM/loWepvk9xq0buu4XKiBAMhYXezg=

—–END CERTIFICATE—–

 

6.
—–BEGIN CERTIFICATE—–

MIIG7zCCBNegAwIBAgIQEAAAAAAAnuXHXttK9Tyf2zANBgkqhkiG9w0BAQsFADBkMQswCQYDVQQGEwJCRTERMA8GA1UEBxMIQnJ1c3NlbHMxHDAaBgNVBAoTE0NlcnRpcG9zdCBOLlYuL1MuQS4xEzARBgNVBAMTCkNpdGl6ZW4gQ0ExDzANBgNVBAUTBjIwMTgwMzAeFw0xODA2MDEyMjA0MTlaFw0yODA1MzAyMzU5NTlaMHAxCzAJBgNVBAYTAkJFMSMwIQYDVQQDExpQYXRyaWNrIEtyZW1lciAoU2lnbmF0dXJlKTEPMA0GA1UEBBMGS3JlbWVyMRUwEwYDVQQqEwxQYXRyaWNrIEplYW4xFDASBgNVBAUTCzcyMDIwMzI5OTcwMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAr7g7VriDY4as3R4LPOg7uPH5inHzaVMOwFb/8YOW+9IVMHz/V5dJAzeTKvhLG5S4Pk6Kd2E+h18FlRonp70Gv2+ijtkPk7ZQkfez0ycuAbLXiNx2S7fc5GG9LGJafDJgBgTQuQm1aDVLDQ653mqR5tAO+gEf6vs4zRESL3MkYXAUq+S/WocEaGpIheNVAF3iPSkvEe3LvUjF/xXHWF4aMvqGK6kXGseaTcn9hgTbceuW2PAiEr+eDTNczkwGBDFXwzmnGFPMRez3ONk/jIKhha8TylDSfI/MX3ODt0dU3jvJEKPIfUJixBPehxMJMwWxTjFbNu/CK7tJ8qT2i1S4VQIDAQABo4ICjzCCAoswHwYDVR0jBBgwFoAU2TQhPjpCJW3hu7++R0z4Aq3jL1QwcwYIKwYBBQUHAQEEZzBlMDkGCCsGAQUFBzAChi1odHRwOi8vY2VydHMuZWlkLmJlbGdpdW0uYmUvY2l0aXplbjIwMTgwMy5jcnQwKAYIKwYBBQUHMAGGHGh0dHA6Ly9vY3NwLmVpZC5iZWxnaXVtLmJlLzIwggEjBgNVHSAEggEaMIIBFjCCAQcGB2A4DAEBAgEwgfswLAYIKwYBBQUHAgEWIGh0dHA6Ly9yZXBvc2l0b3J5LmVpZC5iZWxnaXVtLmJlMIHKBggrBgEFBQcCAjCBvQyBukdlYnJ1aWsgb25kZXJ3b3JwZW4gYWFuIGFhbnNwcmFrZWxpamtoZWlkc2JlcGVya2luZ2VuLCB6aWUgQ1BTIC0gVXNhZ2Ugc291bWlzIMOgIGRlcyBsaW1pdGF0aW9ucyBkZSByZXNwb25zYWJpbGl0w6ksIHZvaXIgQ1BTIC0gVmVyd2VuZHVuZyB1bnRlcmxpZWd0IEhhZnR1bmdzYmVzY2hyw6Rua3VuZ2VuLCBnZW3DpHNzIENQUzAJBgcEAIvsQAECMDkGA1UdHwQyMDAwLqAsoCqGKGh0dHA6Ly9jcmwuZWlkLmJlbGdpdW0uYmUvZWlkYzIwMTgwMy5jcmwwDgYDVR0PAQH/BAQDAgZAMBMGA1UdJQQMMAoGCCsGAQUFBwMEMGwGCCsGAQUFBwEDBGAwXjAIBgYEAI5GAQEwCAYGBACORgEEMDMGBgQAjkYBBTApMCcWIWh0dHBzOi8vcmVwb3NpdG9yeS5laWQuYmVsZ2l1bS5iZRMCZW4wEwYGBACORgEGMAkGBwQAjkYBBgEwDQYJKoZIhvcNAQELBQADggIBACBY+OLhM7BryzXWklDUh9UK1+cDVboPg+lN1Et1lAEoxV4y9zuXUWLco9t8M5WfDcWFfDxyhatLedku2GurSJ1t8O/knDwLLyoJE1r2Db9VrdG+jtST+j/TmJHAX3yNWjn/9dsjiGQQuTJcce86rlzbGdUqjFTt5mGMm4zy4l/wKy6XiDKiZT8cFcOTevsl+l/vxiLiDnghOwTztVZhmWExeHG9ypqMFYmIucHQ0SFZre8mv3c7Df+VhqV/sY9xLERK3Ffk4l6B5qRPygImXqGzNSWiDISdYeUf4XoZLXJBEP7/36r4mlnP2NWQ+c1ORjesuDAZ8tD/yhMvR4DVG95EScjpTYv1wOmVB2lQrWnEtygZIi60HXfozo8uOekBnqWyDc1kuizZsYRfVNlwhCu7RsOq4zN8gkael0fejuSNtBf2J9A+rc9LQeu6AcdPauWmbxtJV93H46pFptsR8zXo+IJn5m2P9QPZ3mvDkzldNTGLG+ukhN7IF2CCcagt/WoVZLq3qKC35WVcqeoSMEE/XeSrf3/mIJ1OyFQm+ tsfhTceOFDXuUgl3E86bR/f8Ur/bapwXpWpFxGIpXLGaJXbzQGSTtyNEYrdENlh71I3OeYdw3xmzU2B3tbaWREOXtj2xjyW2tIv+vvHG6sloR1QkIkGMFfzsT7W5U6ILetv

—–END CERTIFICATE—–

 

7.
—–BEGIN CERTIFICATE—–

MIIG3jCCBMagAwIBAgIUGuqe9pHg6UIaItA5/9FCYe0jS3IwDQYJKoZIhvcNAQELBQAwczELMAkGA1UEBhMCQkUxGTAXBgNVBGEMEE5UUkJFLTA1Mzc2OTgzMTgxIDAeBgNVBAoMF1F1b1ZhZGlzIFRydXN0bGluayBCVkJBMScwJQYDVQQDDB5RdW9WYWRpcyBCZWxnaXVtIElzc3VpbmcgQ0EgRzIwHhcNMTgwMzA3MTYwMTQzWhcNMjEwMzA3MTYxMTAwWjBxMQswCQYDVQQGEwJCRTEUMBIGA1UECwwLSW5mb3JtYXRpY3MxGzAZBgNVBGEMElZBVEJFLTA5NDkuMzgzLjM0MjEcMBoGA1UECgwTRXVyb3BlYW4gQ29tbWlzc2lvbjERMA8GA1UEAwwIRUNfRElHSVQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCnRky4DfnlZEM8 p. 9TbPr2Rw4FiMVKNEBG1PMymxuvpRJOUFYpMt0fksGm6sQui2mCNdyOJV6BSXiwZktKYCQUhzizrrsV5sja8r2NN/vJEvs+x9TsG6l6Sq1XK+RfU3D8UNvHtcklrcPdr0LWdATOm4SDwLNidKF4HunHFTo3fkRlGh7grrt/WCPNXqEZiPtWA7AoGEK+VVYwVU8PopoL9gg1acSZHoCKgh3tTVziX15fvn/DiP3TAQGITVVY/66UFZy15pcdMSzMiumP/etNEQm9a6yz9nXVTXfZdR0dHeu2jlhr5ATZBirgkUrxqWkUdoq8H6dNcAaYFfUglnxmbAgMBAAGjggJqMIICZjB3BggrBgEFBQcBAQRrMGkwOAYIKwYBBQUHMAKGLGh0dHA6Ly90cnVzdC5xdW92YWRpc2dsb2JhbC5jb20vcXZiZWNhZzIuY3J0MC0GCCsGAQUFBzABhiFodHRwOi8vdXcub2NzcC5xdW92YWRpc2dsb2JhbC5jb20wHQYDVR0OBBYEFM8doj2/7+PpPvEU6kOk0Dty0hTzMB8GA1UdIwQYMBaAFIfJvDGXEnpzu37APUVRtAEllVGrMFoGA1UdIARTMFEwRAYKKwYBBAG+WAGDEDA2MDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnF1b3ZhZGlzZ2xvYmFsLmNvbS9yZXBvc2l0b3J5MAkGBwQAi+xAAQMwOwYDVR0fBDQwMjAwoC6gLIYqaHR0cDovL2NybC5xdW92YWRpc2dsb2JhbC5jb20vcXZiZWNhZzIuY3JsMA4GA1UdDwEB/wQEAwIGwDApBgNVHSUEIjAgBggrBgEFBQcDAgYIKwYBBQUHAwQGCisGAQQBgjcKAwwwEwYKKoZIhvcvAQEJAgQFMAMCAQEwNAYKKoZIhvcvAQEJAQQmMCQCAQGGH2h0dHA6Ly90cy5xdW92YWRpc2dsb2JhbC5jb20vYmUwgYsGCCsGAQUFBwEDBH8wfTAVBggrBgEFBQcLAjAJBgcEAIvsSQECMAgGBgQAjkYBATAIBgYEAI5GAQQwEwYGBACORgEGMAkGBwQAjkYBBgIwOwYGBACORgEFMDEwLxYpaHR0cHM6Ly93d3cucXVvdmFkaXNnbG9iYWwuY29tL3JlcG9zaXRvcnkTAmVuMA0GCSqGSIb3DQEBCwUAA4ICAQADskuxFuqHe4hUCFe41oYX+7NP+MBPqtpyNbi1S4TIyVvXL1xxF1pa/qJmFnpJ7aui4DXqjU0VkLpDV6vO0SQEFNcrnVCU8bG/31k2DLgssDo0d1jCmGWK+8C5GCrZlU7dyaeaMZY2bj+OJ85Ab7jYFFTuT8J53xUR8SMb+kn0qLsuQAzII4tYW4rG1cqwHreGjSzMDCWwgMRyAM6L8g9VmXH/BBb6 p. 6vD6uwnKiQQy45qieBTIrjo1tkDVJRm1OYxT4hYxR+3qAL9PMNuA1CqZJ7FDnQ0zm3Ojd936JFGA/YBdnoRDRR+W5Pua2uwGp9ESVsiDAcFRmg0Ol/j8JrH3KnZCfNSbKbiizFZDLsROZnC4mqROdFZxnl2HDqKGl8Hp+LfJS8dgOkJYNuAJPtk4gtsbUvEmO0zC4u4BN5J2vpvrcd9QERRadNFsfkQIxKqvE7/SehvlFPeQJP7iQ+jNftafu7LOQMe4KyrT6HR/hRb2jwqE4zpytYQ3uKQdYwif+PlKdbDn9jOiWBJ50miecTCh6oAvDjsONLMhKLQm7cn7P7s8S/uadkcHJ07T/BjMqak2JQYruREK3K3A8y7NM4pSydW+S/Iq5AzNWmwUSlfiVXOAMJEktjiPA6z9RZaDHoPA9ybzRLl2WL9xHQVfdiKzUJl1hTDp4qApm6VRQ==

—–END CERTIFICATE—–

 

8.
—–BEGIN CERTIFICATE—–

MIIG3TCCBMWgAwIBAgIUWXcucAZpt2afsBLFzdE8OigaCREwDQYJKoZIhvcNAQELBQAwczELMAkGA1UEBhMCQkUxGTAXBgNVBGEMEE5UUkJFLTA1Mzc2OTgzMTgxIDAeBgNVBAoMF1F1b1ZhZGlzIFRydXN0bGluayBCVkJBMScwJQYDVQQDDB5RdW9WYWRpcyBCZWxnaXVtIElzc3VpbmcgQ0EgRzIwHhcNMTgwMzA3MTYwMDQzWhcNMjEwMzA3MTYxMDAwWjBwMQswCQYDVQQGEwJCRTETMBEGA1UECwwKREcgQ09OTkVDVDEbMBkGA1UEYQwSVkFUQkUtMDk0OS4zODMuMzQyMRwwGgYDVQQKDBNFdXJvcGVhbiBDb21taXNzaW9uMREwDwYDVQQDDAhFQ19DTkVDVDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAOjmsZD+GhI/ySvgMNd6OTqzIeOWQzCzDDW1LS5zx70hR+LOLaqIxQPpv8chiZOJgMEHpmmzjsvsDc42BvsX6Coz4GG4w80RtdMJXvaUqY6pvvo8zXAkqsHB/QgQSW3udTUIgLTy58pRwO8aFY77uvGsc3xpIZPQX0YMebiuyKeplXlmxwTOwHKbO3v0bNisIp7oU4mxgxQWdxuq4Ot6tYYp5wb6muc+sVyLH/5XGayXdeLzuCWsHyh60KhyLVtZftETFFwpZVYSkliMHc2DlMb/Y5EuIcQtHrzS3D4xnyT+LB0xvGaLaaTayCxL91bjL/d4H5G9UcChsqopdfZu4nsCAwEAAaOCAmowggJmMHcGCCsGAQUFBwEBBGswaTA4BggrBgEFBQcwAoYsaHR0cDovL3RydXN0LnF1b3ZhZGlzZ2xvYmFsLmNvbS9xdmJlY2FnMi5jcnQwLQYIKwYBBQUHMAGGIWh0dHA6Ly91dy5vY3NwLnF1b3ZhZGlzZ2xvYmFsLmNvbTAdBgNVHQ4EFgQU6BH8Rr4jtI8 + 97HXeN8Jl7jsRSQwHwYDVR0jBBgwFoAUh8m8MZcSenO7fsA9RVG0ASWVUaswWgYDVR0gBFMwUTBEBgorBgEEAb5YAYMQMDYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cucXVvdmFkaXNnbG9iYWwuY29tL3JlcG9zaXRvcnkwCQYHBACL7EABAzA7BgNVHR8ENDAyMDCgLqAshipodHRwOi8vY3JsLnF1b3ZhZGlzZ2xvYmFsLmNvbS9xdmJlY2FnMi5jcmwwDgYDVR0PAQH/BAQDAgbAMCkGA1UdJQQiMCAGCCsGAQUFBwMCBggrBgEFBQcDBAYKKwYBBAGCNwoDDDATBgoqhkiG9y8BAQkCBAUwAwIBATA0BgoqhkiG9y8BAQkBBCYwJAIBAYYfaHR0cDovL3RzLnF1b3ZhZGlzZ2xvYmFsLmNvbS9iZTCBiwYIKwYBBQUHAQMEfzB9MBUGCCsGAQUFBwsCMAkGBwQAi+xJAQIwCAYGBACORgEBMAgGBgQAjkYBBDATBgYEAI5GAQYwCQYHBACORgEGAjA7BgYEAI5GAQUwMTAvFilodHRwczovL3d3dy5xdW92YWRpc2dsb2JhbC5jb20vcmVwb3NpdG9yeRMCZW4wDQYJKoZIhvcNAQELBQADggIBAAfBVbR7SDdFccrLCXUTIpl5iu5bf7HcCZw1+xqaQ0cUHfYzZ51Nd51t40G856SuxjNHgt7G+8NmXwQvr01Zil4MJSxTbrNU8RaIjz2CvbvupuNXcLh3x6sCKmVk/p. 4EtY1pDMGYdEVDqUhoCgY5SnPQPDNIIOspRzWqv/Oc9dNcC7i9Aokp6IdNFc7PYy5CUI//+aPtlHG0zc56VuovGnxtkVSigPKKvRugyhjWaUBULZVVaW+7ebJRRlIRj9ssK0D+WGIGnZAIKceXU1W7UErxz0fFNlAn0KqsZ59BJCrzwAFuxe9OtwGrRsy6QGVbsQQFX/MN1PvXejzJI2nu7WlQ+dgUyuEXWNcTmSe+/S6iSNPpfe6K2YqcmSknsMzS+ uyI8Fc0x+g0gkbvKKBpN7qkGY0rlGUhuZSd34w/QZjhgb2880ETRoWpmOlHRUBkJR3oC+arCNTrhIW6G/uPK15gCZU8VmKZc1g0VnhjFq33ryUu5GvQJReYXWQIIsTh4k88vWj1T+quxcXFuquJvfVcx/idXtkFTGSxRjV/0lD0akoMw4iQfbz01NSv2xoCROmGyL4RW566zuBlgU9oV734Fr0VYfwMafmGuBUG/B0EV2Rsc7/F2vUQkuakNoPjm6Ept3YIu7WY22lGwnAMN/Gq0xyQvrHrqA1n+XuKB/hq

—–END CERTIFICATE—–

 

TPP, AISP, PISP, ASPSP – Términos de PSD2 y eIdAS

Deja un comentario

La entrada en vigor de la Segunda Directiva de Pagos (PSD2) recogida en la legislación española en el Real Decreto-ley 19/2018, de 23 de noviembre, de servicios de pago y otras medidas urgentes en materia financiera, permite el desarrollo de nuevos servicios financieros en Europa e impulsa un nuevo marco de competencia.

Aparecen nuevos términos, que conviene conocer en inglés y en español para entender mejor el nuevo contexto competitivo marcado por el «Open Banking».

Término Descripción
AIS Account Information Services. Servicios de Información de Cuentas. Servicios accesibles mediante API (Application Program Interface) para los TPP (Third Party Provider) Prestadores Financieros  en los que obtener información de los usuarios de servicios de pago.
AISP Account Information Service Provider. Proveedor de servicios de información sobre cuenta.  Prestador Financiero que obtiene información de varias entidades en nombre de un usuario de servicios de pago y se las presenta de forma consolidada.
API Application Programming Interface. Interfaz de Programación de Aplicación. Una API proporciona a una entidad una forma sistemática de obtener información o iniciar acciones en otra entidad. Mediante parámetros y opciones pueden programarse diferentes servicios a terceros.
ASPSP Account Servicing Payment Service Provider.  Proveedor de servicios de pago gestor de cuenta. Una entidad financiera en la que un usuario de servicios de pago tiene cuentas a cuya información un Prestador Financiero puede acceder en su nombre o en la puede iniciar una transferencia.
Autenticacion El proceso de confirmar la identidad de un Prestador Financiero o de un usuario de servicios de pago. Existen pautas como SCA – Strong Customer Authentication (Autenticación Reforzada de Cliente) o mecanismos como los certificados eIdAS para garantizar la correcta identificación.
Autorización El proceso de confirmar la  funcionalidad permitida según las credenciales de un Prestador Financiero o de un usuario de servicios de pago. Inicialmente la funcionalidad se limita a acceder a información de cuentas o iniciar transferencias, según el tipo de prestador (AISP o PISP).
Consentimiento El acuerdo por el que el usuario de servicios de pago otorga al Prestador la posibilidad de acceder a su información bancaria o iniciar transferencias.
eIdAS Reglamento UE 910/2014 que regula, entre otros aspectos los requisitos de expedición de certificados cualificados QWAC para sitios web y certificados cualificados para sello electrónico de los diferentes Prestadores. Los certificados los expiden  QTSPs – Qualified Trust Service providers, Prestadores cualificados de servicios electrónicos de confianza
NCA National Competent Authority. Autoridad Nacional Competente.  Organismo regulador o supervisor de entidades financieras que autoriza a un Prestador Financiero a operar en el nuevo marco de servicios financieros PSD2 cuando cumpla ciertos requisitos. En España, es el Banco de España.
PIS Payment Initiation Services. Servicios de iniciación del pagos. Servicios de transferencia bancaria gestionados por un Prestador Financiero en nombre de un usuario de servicios de pago a través de una API ofrecida por su Proveedor de servicios de pago gestor de cuenta.
PIIS Payment Issuer Instrument Service. Servicio asociado a medio de pago para solicitar por API la autorización de pago con tarjeta indicando el importe (comprueba la validez de la tarjeta y la disponibilidad del importe).
PISP Payment Initiation Service Provider. Proveedor de servicios de iniciación de pago. Prestador Financiero de servicios de transferencia bancaria gestionados en nombre de un usuario de servicios de pago a través de una API ofrecida por su Proveedor de servicios de pago gestor de cuenta. Puede requerirse por parte del ASPSP la confirmación del usuario.
PSU Payment Service User. Usuario de servicios de pago.
QTSP Qualified Trust Service Provider. Prestadores cualificados de servicios electrónicos de confianza. Expiden certificados cualificados QWAC para sitios web y certificados cualificados para sello electrónico de los diferentes Prestadores Financieros. Los certificados permiten identificar a los Prestadores Financieros cuando usan las APIs de otras entidades en entornos de Producción.
SCA Strong Customer Authentication. Autenticación Reforzada de Cliente. Proceso de confirmar la identidad del usuario. Normalmente se usan dos o más factores de autenticación:
  • «Algo que sabes»
  • «Algo que tienes»
  • «Algo que te caracteriza»
Sandbox Experimentos con gaseosa. Zona de pruebas.

El término en inglés Sandbox se refiere a una zona de juegos para niños en la que no estropean nada ni se hacen daño.  Se amplía a usos profesionales en los que se prueban desarrollos con funcionalidades similares a las del entorno real antes del paso a producción.
TPP Third Party Provider. Prestador Financiero. AISP o PISP.  Actúa en nombre de un usuario de servicios de pago accediendo a su información bancaria en otra entidad o iniciando una transferencia. Requiere una licencia por parte de una NCA y puede operar en otros países en virtud del concepto de «pasaporte» haciendo uso de certificados eIdAS.

Prestador-Financiero

Contacte con EADTrust para obtener Certificados Cualificados PSD2 , llame al 917160555.

Resuelto uno de los frenos a los certificados cualificados de PSD2

1 respuesta

EIDAS-CAB-forumEl CAB Forum ha aprobado una modificación del documento «Extended Validation Guidelines» para permitir incluir guiones en el campo organizationIdentifier (OID 2.5.4.97) de los certificados EV (Extended Validation), con lo que los certificados expedidos en el contexto de la norma ETSI TS 119 495 ya no serán incompatibles con las comprobaciones que realizan los navegadores. De esta forma se podrán expedir certificados QWAC compatibles con EV para entidades financieras y otras entidades que operan en aplicación de la Directiva (UE) 2015/2366 llamada Segunda Directiva de Pagos (PSD2).

La propuesta SC17 se ha aprobado con 23 votos favorables de entidades emisoras de certificados y 6 de las entidades desarrolladoras de navegadores (comprobadores de certificados).

Votos a favor:

  • Emisores:  Actalis, Buypass, Camerfirma, Certigna (DHIMYOTIS), Certum (Asseco), Chunghwa Telecom, Comsign, D-TRUST, DarkMatter, DigiCert, eMudhra, Entrust Datacard, Firmaprofesional, GDCA, GlobalSign, GoDaddy,  SHECA, SSC, SecureTrust (anteriormente Trustwave), TurkTrust.
  • Comprobadores: Apple, Cisco, Google, Microsoft, Mozilla, 360

1 Abstención (Emisores): TrustCor

Con este resultado, se permite la inclusión de información adicional en los certificados EV para cumplir con ciertas regulaciones de la Unión Europea.

La motivación argumentada que dio lugar a la solicitud que se ha votado fue:

  • El Reglamento de la Unión Europea Nº 910/2014 (eIDAS)  define ciertos requisitos reglamentarios para los certificados con un nivel de calidad acordado denominado «Cualificado». Este reglamento especifica en el Anexo IV los requisitos específicos para «Certificados cualificados para la autenticación de sitios web», incluida la declaración de que el certificado contendrá: «para personas jurídicas: al menos el nombre de la persona jurídica a la que se expida el certificado y, cuando proceda, el número de registro, tal como se recojan en los registros oficiales;
  • Se entiende que este requisito se relaciona con los atributos validados para la identificación del sujeto del certificado y, por lo tanto, se ajusta mejor al nombre distinguido del sujeto (subject’s distinguished name).
  • En línea con el marco regulatorio, ETSI ha definido una estructura general para llevar «números de registro» en la norma TS 119 412-1 (en la actualidad EN 319 412-1). Ver cláusula 5.1. 4. En ella se utiliza el identificador de organización (organizationIdentifier) de la norma  X.520 dentro del nombre distinguido del  sujeto el propósito de servir como «identificación de una organización diferente del nombre de la organización». Esto se utiliza para los requisitos de ETSI para llevar los números de registro para certificados, cualificados o de otro tipo.
  • Se considera que este uso de organizationIdentifier es compatible con el propósito principal de los certificados de EV como se indica en la sección 2.1.1 de las Directrices de EV como «otra información desambiguadora».
  • Un reciente Reglamento delegado de la UE 2018/389 sobre comunicaciones seguras para servicios de pago establece en el artículo 34.2 que para los Certificados de sitio web cualificados (QWAC), el número de registro requerido en eIDAS «será el número de autorización del proveedor de servicios de pago (…) o equivalente [referencia hecha a regulaciones anteriores relacionadas con entidades financieras]».
  • ETSI ha especificado los requisitos de la norma TS 119 495 para incluir los números de registro relacionados con PSD2 en la estructura general para los números de registro definidos en la citada norma TS 119 412-1 en su cláusula 5.1 .4
  • ETSI se ha esforzado por garantizar y siempre ha intentado que los requisitos relacionados con los certificados de sitios web en el nivel Cualificado estén en línea con las pautas de Extended Validation de CA / B Forum.
  • Esta propuesta solo incluye algunos de los Esquemas de registro utilizados en la norma ETSI TS 119 412-1, que tienen reglas de validación claras (NTR, VAT, PSD) que brindan una seguridad razonable de acuerdo con las «EV Guidelines«. Se propone que los IPR (intellectual property rights) para la semántica de este esquema se cedan al CA / B Forum, lo que le permitirá extender aún más el uso del Identificador de la organización (organizationIdentifier) para incluir otros Esquemas de registro (por ejemplo, LEI, Legal Entity Identifier) y las reglas de validación correspondientes, a discreción del CA / B Forum.  Además, cualquier cambio futuro realizado por ETSI a la norma ETSI TS 119 412-1 ya no tendrá impacto adicional en CA / B Forum.
  • Al tomar conciencia de que la interpretación del CA / B Forum de los «Requisitos de EV» en la sección 9.2.8 “Otros Atributos” no estaba en línea con la forma de entenderlos por los expertos de ETSI, este organismo desearía armonizar su interpretación con la de CA / B Forum para reflejar en los certificados diferentes formas de establecer números de registro para PSD2 y otros esquemas de identificación alfanumérica de entidades.

Por otro lado, las preocupaciones específicas del CA / B Forum eran:

  • Los requisitos con respecto a los atributos que se han de incluir en el DN (Distinguished Name) del sujeto deben recogerse de forma explícita en el apartado 9.2.
  • Las organizaciones pueden desear identificar las unidades organizativas dentro de su organización. No está claro si esto está permitido actualmente en las Directrices de EV (ambigüedad similar a la de la sección 9.2.8).
  • Se han argumentado objeciones al uso específico de ETSI del campo Distinguished Name.
  • Los procedimientos para la validación del atributo deben estar claramente establecidos.
  • Puede haber otros usos del campo organizationIdentifier  en varias PKI, sin embargo, no se considera un problema. dado que la semántica única que se está especificando para cada identificador, las aplicaciones deben ser capaces de comprender los diferentes usos del campo organizationIdentifier  por diferentes emisores y usuarios. Hay muchas «PKI» diferentes que pueden usar todos los atributos de X.500 de manera diferente y con una validación diferente o sin ninguna validación. Según parece, el WebPKI no ha usado anteriormente este atributo de subjectDN antes para los Certificados de confianza pública (Publicly-Trusted Certificates). Por lo tanto, no hay «conflicto» al usar este atributo en las Directrices EV para Certificados SSL / TLS, y tal vez más adelante para Certificados de Firma de Código EV.
  • Este uso de organizationIdentifier debe ser extensible para permitir el uso de otros números de registro asignados por diferentes esquemas de registro. Algunos miembros de CAB Forum han expresado interés en incluir números de registro que no sean para identificar el tipo de sociedad dentro de Certificados EV. Esto está previsto en la propuesta actual.
  • Algunos miembros del CA / B Forum tienen interés en incluir las identificaciones LEI dentro de los certificados del CA / B Forum, pero hasta ahora el esquema de registro LEI no se considera lo suficientemente extendido como para ser reconocido explícitam como un esquema de numeración de registro para ser aceptado por el CA / B Forum. Por lo tanto, esta propuesta solo introduce un conjunto limitado de esquemas de registro (a saber, NTR, IVA, PSD) que tienen reglas de validación razonablemente sólidas.
  • Algunos miembros del CA / B Forum han indicado la posible necesidad de múltiples identificadores en el campo «nombre del sujeto». Sin embargo, esto no se puede lograr utilizando el campo definido en la norma X.520 organizationIdentifier que definió este atributo como «SINGLE VALUE».

Los cambios aprobados, que se reflejarán el documento «EV Guidelines» son:

  • Agregar a la sección 4 las siguientes definiciones:
    “Entidad legal: una organización privada, entidad gubernamental, entidad comercial o entidad no comercial.
    Referencia de registro: un identificador único asignado a una entidad legal (persona jurídica).
    Esquema de registro: un esquema para asignar una referencia de registro que cumple con los requisitos identificados en el Apéndice H. «
  • Cambiar el título de la Sección 9.2 para indicar»Campos de Nombre Distinguido del Sujeto» (Subject Distinguished Name Fields).
  • Eliminar la Sección 9.2.2 y renumerar las secciones 9.2.3 a 9.2.8 como 9.2.2 a 9.2.7.
  • Insertar una nueva sección 9.2.8:
    “9.2.8. Campo identificador de organización del sujeto
    ** Campo de certificado **: organizationIdentifier (OID: 2.5.4.97)
    ** Requerido / Opcional **: Opcional
    ** Contenido **: Si está presente, este campo DEBE contener una referencia de registro para una entidad legal asignada de acuerdo con el Esquema de registro identificado.
    El organizationIdentifier DEBE estar codificado como PrintableString o UTF8String (ver RFC 5280).
    El Esquema de Registro DEBE identificarse utilizando la siguiente estructura en el orden presentado:
    * Identificador de esquema de registro de 3 caracteres;
    * Se utilizará el código de país ISO 3166 de 2 caracteres para la nación en la que opera el Esquema de Registro, o si el esquema se opera globalmente, se utilizará el código ISO 3166 “XG”
    * Para el identificador del Esquema de Registro NTR, si es requerido bajo la Sección 9.2.4, un identificador ISO 3166-2 de dos caracteres para la subdivisión (estado o provincia) de la nación en la que opera el Esquema de Registro, precedido por el signo más “+” ( 0x2B (ASCII), U + 002B (UTF-8));
    * un guión (signo menos) «-» (0x2D (ASCII), U + 002D (UTF-8));
    * Referencia de registro asignada de acuerdo con el Esquema de Registro identificado.Nota: las Referencias de Registro PUEDEN contener guiones, pero los Esquemas de Registro, los códigos de país ISO 3166 y los identificadores ISO 3166-2 no PUEDEN contenerlos. Por lo tanto, si aparece más de un guión en la estructura, el guión más a la izquierda es un separador, y los guiones restantes forman parte de la Referencia de Registro.Como en la sección 9.2.4, la información de ubicación especificada DEBE coincidir con el alcance del registro al que se hace referencia. Ejemplos:
    * NTRGB-12345678 (esquema NTR, Gran Bretaña, cuyo identificador único a nivel de país es 12345678)
    * NTRUS + CA-12345678 (Esquema NTR, Estados Unidos – California, cuyo identificador único a nivel estatal es 12345678)
    * VATDE-123456789 (Esquema de IVA o CIF, Alemania, cuyo Identificador único a nivel de país es 12345678)
    * PSDBE-NBB-1234.567.890 (Esquema de PSD2, Bélgica, con identificador de la NCA (National Competent Authority) por sus siglas NBB, y con identificador único del sujeto asignado por la NCA formado por la secuencia 1234.567.890)Los esquemas de registro enumerados en el Apéndice H se reconocen actualmente como válidos bajo estas pautas («Guidelines»).

    La CA DEBE:
    1. confirmar que la organización representada por la Referencia de Registro es la misma que la organización nombrada en el campo de organización como se especifica en la Sección 9.2.1 dentro del contexto de la jurisdicción del sujeto según se especifica en la Sección 9.2.4;
    2. Verificar además que la Referencia de registro coincida con otra información verificada de acuerdo con la sección 11;
    3. Tomar las medidas adecuadas para desambiguar entre diferentes organizaciones como se describe en el Apéndice H para cada Esquema de Registro;
    4. Aplicar las reglas de validación relevantes al Esquema de Registro como se especifica en el Apéndice H. «

  • Insertar nueva sección 9.8 (renumerar las siguientes secciones según sea necesario):
    “9.8. Extensiones de Certificado
    Las extensiones enumeradas en la Sección 9.8 se recomiendan para la máxima interoperabilidad entre los certificados y los navegadores / aplicaciones, pero no son obligatorias en las CA, excepto cuando se indica como «Requerido». Las CA pueden usar otras extensiones que no están enumeradas en esta Sección 9.8, pero se les recomienda que propongan su inclusión en esta sección de vez en cuando para ayudar a aumentar la estandarización de la extensión en toda la industria.Si una CA incluye una extensión en un certificado que tiene un campo de Certificado que se menciona en esta Sección 9.8, la CA debe seguir el formato especificado en esa subsección. Sin embargo, ninguna extensión o formato de extensión será obligatorio en una CA a menos que se indique específicamente como «Requerido» en la subsección que describe la extensión.9.8.1. Extensión del nombre alternativo del sujeto (Subject Alternative Name Extension)
    ** Campo del certificado: ** _subjectAltName: dNSName_
    ** Requerido / Opcional: ** Requerido
    ** Contenido: ** Esta extensión DEBE contener uno o más nombres de dominio de host que sean propiedad o estén controlados por el sujeto y que estén asociados con el servidor del sujeto. Dicho servidor PUEDE ser propiedad y operado por el Sujeto u otra entidad (por ejemplo, un servicio de alojamiento). Los certificados comodín no están permitidos para los certificados EV.9.8.2. Campo de identificador de organización del foro de CA / navegador
    ** Nombre de la extensión **: _cabfOrganizationIdentifier_ (OID: 2.23.140.3.1)
    ** OID detallado **: {joint-iso-itu-t (2) international-Organizations (23) ca-browser-forum (140) extensiones de certificado (3) cabf-organization-identifier (1)}
    ** Requerido / Opcional **: Opcional (pero ver más abajo)
    ** Contenido **: Si el asunto: organizationIdentifier está presente, este campo DEBE estar presente.

    A partir del 31 de enero de 2020, si está presente el campo sujeto: organizaciónIdentificador, este campo DEBE estar presente.
    Si está presente, este campo DEBE contener una Referencia de Registro para una entidad legal asignada de acuerdo con el esquema de registro identificado.

    El esquema de registro DEBE estar codificado como se describe en la siguiente gramática ASN.1:

    id-CABFOrganizationIdentifier OBJECT IDENTIFIER ::= 
{ joint-iso-itu-t(2) international-organizations(23) 
ca-browser-forum(140) certificate-extensions(3) 
cabf-organization-identifier(1) }

ext-CABFOrganizationIdentifier EXTENSION ::= 
{ SYNTAX CABFOrganizationIdentifier IDENTIFIED BY 
id-CABFOrganizationIdentifier }

CABFOrganizationIdentifier ::= SEQUENCE {

registrationSchemeIdentifier   PrintableString (SIZE(3)),

registrationCountry            PrintableString (SIZE(2)),

registrationStateOrProvince    [0] IMPLICIT PrintableString OPTIONAL (SIZE(0..128)),

registrationReference          UTF8String

}

    donde están los subcampos y tienen los mismos significados y restricciones descritos en la Sección 9.2.8. La CA DEBE validar el contenido utilizando los requisitos de la Sección 9.2.8 «.

  • Añadir nuevo Apéndice H – Esquemas de registro
    “Los siguientes esquemas de registro se reconocen actualmente como válidos según estas pautas:** NTR **: La información incluida en este campo será la misma que se guardó en el campo Número de registro del sujeto como se especifica en 9.2.5 y el código de país utilizado en el identificador del esquema de registro coincidirá con el de la jurisdicción del sujeto según se especifica en la Sección 9.2.4.
    Cuando la Jurisdicción de constitución de la entidad o el Campo de Registro en 9.2.4 incluya más que el código del país, la información de localidad adicional se incluirá como se especifica en las secciones 9.2.8 y / o 9.8.1.** IVA **: Referencia asignada por las autoridades fiscales nacionales a una entidad jurídica. Esta información se validará utilizando la información provista por la autoridad fiscal nacional contra la organización identificada por el campo Nombre de la organización del sujeto (ver 9.2.1) y el campo del número de registro del sujeto (ver 9.2.5) dentro del contexto de la jurisdicción del sujeto según se especifica en la Sección 9.2.4.

    ** PSD **: Número de autorización especificado en ETSI TS 119 495, cláusula 4.4, asignado a un proveedor de servicios de pago y que contiene la información especificada en ETSI TS 119 495 cláusula 5.2.1. Esta información SE DEBE obtener directamente del registro de la autoridad nacional competente para servicios de pago o de una fuente de información aprobada por una agencia gubernamental, organismo regulador o legislación para este propósito. Esta información DEBE validarse comparándola directa o indirectamente (por ejemplo, haciendo coincidir un número de registro único global) con la organización identificada por el campo Nombre de la organización del sujeto (ver 9.2.1) y el Campo del número de registro del sujeto (ver 9.2.5). ) dentro del contexto de la jurisdicción del sujeto según se especifica en la Sección 9.2.4. La dirección indicada de la organización combinada con el nombre de la organización NO SERÁ la única información utilizada para desambiguar la organización «.