Verificar documentos de identidad en la web

¡Hola! Soy Erik, ingeniero del equipo de Wallet y Apple Pay. Hola, soy Marcos, ingeniero de Normas del equipo de WebKit. Hoy te mostraré a agilizar los flujos de verificación de identidad en línea mediante documentos de identidad digital. Si eres desarrollador de sitios web que quiere mejorar sus flujos de verificación de identidad, desarrollador de apps que quiere que su app ofrezca pruebas de identidad, o solo alguien a quien le interese la identidad digital, esta sesión es para ti. Los documentos de identidad digitales son cada vez más comunes, pues representan una gran variedad de documentos de identificación, como los permisos de conducir y otros emitidos por el gobierno. Estos documentos de identidad digitales prometen algunos beneficios clave frente a los documentos físicos: primero, son más fáciles de usar en línea. Hoy en día, para comprobar mi identidad en línea, debo subir fotos de mi identificación física. Esta no es una gran solución ni para el usuario ni para la empresa que intenta verificar la identificación. Para el usuario, es una mala experiencia. Primero debe buscar su identificación física. Luego, debe buscar un fondo adecuado para tomarse una foto, cuidando también que la foto sea legible y no esté borrosa. Por otro lado, la empresa necesita crear una solución compleja que pueda procesar estas fotos y determinar si son auténticas. Un problema difícil de resolver. Los documentos móviles, o "mdocs", son un tipo de documento de identidad digital que busca resolver este problema. Los mdocs ofrecen algunas propiedades únicas: en primer lugar, se definen en la norma ISO 18013-5. Esto les permite ser interoperables en diferentes plataformas.

También ofrecen al usuario más privacidad. Si quien solicita solo necesita verificar mi nombre y edad, entonces esa es la única información que debería compartir. Esto es posible gracias a mdocs. Por último, ofrecen más elementos de seguridad que una identificación física, de modo que son más confiables. Por ejemplo, la información de un mdoc lleva la firma criptográfica de su emisor, por lo que una empresa puede confiar en que la información es legítima. Las identificaciones de Apple Wallet son ejemplos de documentos basados en el formato mdoc y las normas ISO 18013 que los acompañan.

Actualmente, los usuarios pueden mostrar su identificación en Apple Wallet de forma física en ciertos controles de seguridad en aeropuertos de EE. UU., en algunos comercios y locales, y en los Apple Store de todo el país. También pueden usar su identificación en ciertas apps que utilicen nuestra API Verify with Wallet. Si tienes una app y quieres adoptar la API Verify with Wallet para verificar la identidad, ve la sesión "“What’s new in Wallet and Apple Pay”" de la WWDC22. También vimos que algunas jurisdicciones crearon apps de proveedores de documentos en formato mdoc. Estas apps permiten a los usuarios almacenar y usar sus documentos de identidad físicamente. Para simular una autoridad local de permisos de conducir, creamos una app de demostración que administra las licencias de conducir. Le pusimos este nombre: Local Driving Authority. Este año, nos complace anunciar algunas mejoras para esta clase de aplicaciones proveedoras de documentos, así como en ID en Wallet. En nuestras próximas versiones, introduciremos la compatibilidad con la API Digital Credentials del W3C para solicitar mdocs desde Safari y WebKit. Te explico cómo funciona. Digamos que intento alquilar una nave espacial en Spaceship Rentals. Estoy en Safari y ya seleccioné mi nave espacial y el itinerario de viaje a través de su sitio web. Ahora estoy en el paso donde necesitan verificar mi identidad. Continuaré y tocaré el botón “Verify Identity”. Este botón activa la API Digital Credentials de JavaScript. Mi licencia de conducir está almacenada en dos apps: la app Local Driving Authority y Apple Wallet. Esta interfaz de selección de apps me deja elegir qué app quiero usar para verificar mi identidad.

Por ahora usaré Apple Wallet.

Ahora aparece la hoja de consentimiento para que la revise. Puedo ver quién solicita ver datos de mi identificación a través del ícono y el nombre de la marca. También puedo ver los elementos particulares que solicitan y si tienen la intención de almacenar esta información o no. Continuaré y aprobaré esta verificación de identidad autorizándola con Face ID. Vemos ahora que la información aparece de nuevo en el sitio web de Spaceship Rentals. ¿No es genial?

Oye Erik, funcionó muy bien con un iPhone. ¿Pero y si estuviera en una Mac? Buena pregunta. Déjame mostrarte.

Aquí estoy de nuevo en Safari, pero ahora en mi Mac. Estoy en el mismo sitio web de Spaceship Rentals que usé antes.

Continuaré y haré clic en el botón “Verify Identity”. Se me pide que continúe en mi iPhone cercano. Luego, aparece una notificación en mi iPhone que me permite completar mi verificación de identidad. La toco y veo la misma opción para elegir qué aplicación quiero usar. Usaré Apple Wallet otra vez. Aparece la misma hoja de consentimiento: donde puedo ver quién hace esta solicitud, qué elementos solicita y si almacenarán esta información. Me parece bien, así que lo confirmaré con Face ID.

¡Increíble! Ahora vemos que la información del documento se envió de vuelta a Spaceship Rentals en mi Mac. No solo implementamos la compatibilidad para Safari en Mac, sino también compatibilidad estandarizada para la verificación de identidad multiplataforma en otros sistemas operativos y navegadores. Aunque alquile mi nave espacial desde otra plataforma o navegador, puedo usar mi identificación desde el iPhone. Lo haré escaneando el código QR que muestra el navegador. Los flujos que acabas de ver se crearon a partir de un conjunto de normas. Utiliza la API Digital Credentials de W3C, específicamente con el perfil de solicitud definido en el Anexo C de ISO 18013-7 e ISO 18013-5. El protocolo FIDO CTAP se utiliza para el flujo multiplataforma. Significa que cualquier código que un sitio web escriba para integrarse con las plataformas de Apple funciona con otros navegadores y apps que adopten estas mismas normas.

La experiencia se creó para ser multiplataforma desde el principio. Esto incluye compatibilidad con iPhone, iPad y Mac, así como con otros navegadores y sistemas operativos. No importa dónde navegue un usuario en Internet, puede usar los documentos en su iPhone para verificar la identidad. Finalmente, creamos un grupo de API Document Provider para plataformas de Apple. Estas API permiten que apps como Local Driving Authority sean una opción durante un flujo de verificación de identidad. Desglosaré las demostraciones que acabas de ver y te explicaré cómo funciona esto. La verificación de mdoc en Internet comienza cuando un usuario visita un sitio web en un navegador. Luego, el sitio web se comunica con su servidor para crear y firmar una solicitud de mdoc. Cuando el sitio web recibe su solicitud, puede utilizar la API Digital Credentials. Cuando el usuario realice una acción para iniciar la verificación de identidad, el sitio web accederá a la API Digital Credentials con la solicitud.

Luego, el navegador enviará esa solicitud al sistema operativo subyacente. El sistema operativo combina la solicitud y la interacción del usuario para determinar la fuente del documento que responderá a la solicitud. Puede tratarse de una app proveedora de documentos instalada localmente en el dispositivo, o incluso de otro dispositivo.

Una vez decidida, la solicitud se envía a la fuente del documento adecuada para su procesamiento. El usuario autorizará entonces la divulgación de su documento. A continuación, la fuente de documentos emite una respuesta cifrada que regresa al sitio web solicitante. Finalmente, el sitio web envía esta respuesta a su servidor, para descifrarla y validarla.

Si ampliamos un poco la imagen, entenderemos mejor los distintos componentes de una verificación mdoc en Internet en plataformas de Apple. Hay dos puntos de entrada distintos para aquellos que deseen participar en este flujo. Si eres desarrollador de una app de proveedor de documentos en iOS, tal vez te interese la API Document Provider. Esta API permitirá que tu app para iOS aparezca como una opción para completar una verificación mdoc en línea.

Si tu sitio web está interesado en hacer verificaciones de identidad en línea, deberás implementar la API Digital Credentials de W3C y la lógica de procesamiento de solicitudes y respuestas asociada. Veamos en qué consiste este flujo.

A grandes rasgos, hay tres pasos que un sitio web debe seguir para solicitar un mdoc.

Uno, cuando el usuario visita el sitio web para verificar su identidad, debe solicitar a su servidor que cree y firme una solicitud de documento. Dos, cuando el usuario puede hacer la verificación de identidad, debe pasar la solicitud al navegador mediante la API Digital Credentials de W3C.

Finalmente, al recibir una respuesta, el sitio web debe enviar la respuesta cifrada a su servidor para su descifrado y validación. Marcos, te ves como un desarrollador Full Stack apasionado. ¿Por qué no nos explicas cómo el sitio web de Spaceship Rentals integra un paso de verificación de identidad en su flujo de pago? Claro. Primero, voy a mostrarte cómo crear y firmar una solicitud con la API Digital Credentials de W3C. La solicitud que crearemos se ajustará a lo estandarizado en ISO 18013-7, Anexo C. La solicitud se puede dividir en dos partes: una solicitud de dispositivo y la información de cifrado. Analizaremos cada una. La solicitud del dispositivo contiene dos datos cruciales. Contiene una lista de solicitudes de documentos, donde puedo declarar qué documento quiero solicitar al usuario. Spaceship Rentals desea verificar una licencia de conducir, así que insertaré en la estructura la cadena docType para licencias de conducir móviles. Luego, agregaré las propiedades particulares de la licencia de conducir que quiero solicitar. Esto se hace con una serie estandarizada de espacios de nombres e identificadores de elementos. En este caso, solicitaré el nombre y apellido, si la persona es mayor de 21 años, la fotografía del usuario y su permiso de conducir.

El otro parámetro importante en la solicitud del dispositivo es la lista “Reader Authentication All”. Aquí es donde el sitio web firma la solicitud. Usaremos esta propiedad en un momento, así que la dejaré vacía por ahora. La segunda parte de la solicitud es la información de cifrado. Aquí es donde puedo colocar los parámetros que utiliza el proveedor de documentos para cifrar la respuesta.

Necesitaré generar un nonce para utilizarlo en el cifrado. El nonce es una característica de seguridad importante que nos protege contra ataques de repetición. También generaré un par de claves de cifrado de destinatario. Este par de claves se utilizará en el cifrado de la respuesta del documento. Pondré la clave pública del destinatario en la Estructura de información de cifrado y conservaré la clave privada del destinatario para usarla después. Esto me permitirá descifrar en su momento la respuesta del documento, por lo que es importante que la proteja en mi servidor. Todo esto constituye una solicitud completa.

Ahora que creé la solicitud, puedo proceder a firmarla. Cada app proveedora de documentos puede tener requisitos distintos para firmar la solicitud. Quiero que Spaceship Rentals acepte una identificación en Apple Wallet, así que primero firmaré la solicitud en Wallet.

Antes de firmar la solicitud, necesito un certificado de firma de Apple Business Connect. Para eso, hay que generar primero un par de claves de firma y, luego, enviar una solicitud de firma de certificado a Apple Business Connect. Una vez obtenido el certificado, puedo continuar con lo que debo hacer en tiempo de ejecución. Luego, debo generar una transcripción de sesión con dos datos: la URL de origen de mi sitio web y la estructura de información de cifrado que generé antes. Esta transcripción de sesión también se usa para operaciones posteriores. Ya que tengo la transcripción de la sesión, puedo firmar. Para ello, usaré el par de claves de firma y el certificado de firma que recibí de Apple Business Connect. El resultado es una estructura de autenticación firmada.

Luego, puedo integrar esta estructura de autenticación firmada para Wallet en la lista Reader Authentication All. Este es un mecanismo definido en ISO 18013-5. Ten en cuenta que otras apps proveedoras de documentos pueden tener requisitos algo diferentes para firmar una solicitud. Quiero aceptar documentos desde la aplicación Local Driving Authority, pero requieren que firme la solicitud con un certificado completamente diferente al que me emitieron.

Pero, como la lista Reader Authentication All es una lista, puedo firmar mi solicitud varias veces. Entonces, creé una nueva estructura de autenticación firmada con el certificado de Local Driving Authority. Puedo insertarlo junto con la estructura de autenticación firmada para Wallet.

Ya que tengo la solicitud, lo siguiente es pasarla al navegador mediante la API Digital Credentials de W3C en JavaScript. Ya podemos tomar los datos de solicitud que creamos en el servidor y ponerlos en el diccionario de solicitudes. Fíjate que también definí que es una solicitud “mdoc” a través de la propiedad “protocol” con la cadena estandarizada “org-iso-mdoc”. Ya estamos listos para llamar al método navigator.credentials.get y esperar su respuesta. Esta llamada a un método hará que el navegador muestre la interfaz de usuario del sistema, donde el usuario elegirá una credencial digital. Ten en cuenta que la llamada al método get debe hacerse mediante un gesto del usuario, como un clic del mouse o presionar un botón. Una vez recibida la respuesta, podemos enviarla de vuelta al servidor para su descifrado. Las respuestas se pueden serializar en formato JSON, por lo que se envían fácilmente de vuelta al servidor por la API Fetch o XHR. Finalmente, si algo sale mal, la API Digital Credentials de W3C ofrece un amplio conjunto de excepciones para que tu programa se recupere. También puedes recurrir a un método de verificación de identidad existente, como una imagen escaneada de tu ID subida por un formulario HTML. ¡Muy bien, genial! Probemos nuestro código para ver que funcione. ¡Fantástico! Cuando presiono el botón “Verify Identity”, aparece la interfaz de usuario del sistema. Eso significa que nuestra solicitud funciona. Y Wallet y la app Local Driving Authority aparecen como opciones para el usuario. ¿Qué te parece, Erik? Me parece genial hasta ahora, Marcos. Antes de ir al siguiente paso, voy a hablar sobre la seguridad de este flujo. Al procesar información tan sensible como datos de identificación, hay que asegurarse de tener las protecciones de seguridad adecuadas. Quizás te estés haciendo algunas de estas preguntas: ¿Quién solicita los datos de identificación? ¿Están protegidos estos datos de identificación? ¿Es auténtico? ¿O copiaron esta información? Voy a analizar todas las protecciones de seguridad existentes en las normas para responder a estas preguntas.

Ya analizamos la autenticación de solicitud. Así es como el sitio web solicitante puede identificarse y cómo las apps del proveedor de documentos ayudan a los usuarios a saber quién realiza la solicitud. Esto se hace mediante un certificado que se utiliza para firmar la solicitud.

Luego, viene el cifrado de respuesta. La respuesta se cifra de extremo a extremo con una clave generada por el servidor del sitio web solicitante. Esto evita que otras partes puedan leer los datos de identidad, incluidos el navegador y el sistema operativo. La autenticación del emisor se usa para demostrar la autenticidad de los datos de identidad. Esto permite que el sitio web solicitante determine quién emitió los datos y si se debe confiar en este. También evita la modificación de los datos que se devuelven. Finalmente, la autenticación mdoc evita la duplicación de datos. Esto permite que el sitio web solicitante verifique que el mdoc que recibió proviene del mismo dispositivo al que se emitió. Esto evita la posibilidad de duplicar el mdoc en varios dispositivos.

Marcos, ¿por qué no nos muestras cómo intervienen estas propiedades de seguridad al procesar la respuesta? ¡Claro! Vamos.

Lo último que necesito hacer para finalizar la implementación de Spaceship Rentals es procesar la respuesta que llega del proveedor de documentos. Al igual que con la solicitud, el formato de respuesta de JavaScript se define en ISO 18013-7, Anexo C. La respuesta también contiene dos propiedades. Una es el texto cifrado que debo descifrar. Y la otra es la clave que la app proveedora de documentos generó como parte de su proceso de cifrado. El texto cifrado se encripta mediante cifrado de clave pública híbrido, o HPKE, que se define en RFC-9180.

Los datos de entrada para el descifrado incluyen tanto el texto cifrado como la clave pública del remitente de la respuesta. También incluye la clave privada del destinatario que generamos anteriormente en el servidor al crear la solicitud. El dato de entrada final es la misma transcripción de sesión que generamos anteriormente para firmar la solicitud. El resultado de esta operación es una respuesta del dispositivo descifrada. Cada documento en la respuesta contiene un objeto de seguridad móvil. Este objeto es inalterable y está firmado por el emisor. Y contiene información que es crucial para validar que los datos devueltos sean auténticos. El objeto de seguridad móvil se autentica a través de la estructura de autenticación del emisor. Esta estructura contiene un certificado de firmante de documentos que primero debe validarse. Esto se hace encadenándolo a un certificado raíz de entidad emisora de confianza que el emisor publica. El servidor de Spaceship Rentals tiene una lista de certificados raíz de entidad emisora confiable para determinar qué mdocs aceptar. Si un certificado de firmante de documentos no es confiable, debemos descartar la respuesta. Después de verificar el certificado, ahora necesito validar la firma. Una vez validada la estructura de autenticación del emisor, puedo validar el objeto de seguridad móvil. Hay una serie de validaciones que realizar aquí y, lo más importante, necesito validar la autenticidad de los elementos que se devolvieron. Estos elementos devueltos están en “Issuer Namespaces”. Por ejemplo, aquí podemos ver que se devolvió el nombre “Kelly”. Pero antes de poder usarlo, necesito demostrar que este elemento no fue manipulado. Para ello, calculamos un resumen hash de toda la estructura de información del elemento. Luego, comparamos el resumen con un resumen particular que existe en el objeto de seguridad móvil. Busco con qué resumen comparar usando el identificador de resumen proporcionado en la estructura del elemento. Una vez que se comparan con éxito los resúmenes, puedo estar seguro de que los datos son auténticos. Por último, necesito validar la autenticación del mdoc. El objeto de seguridad móvil contiene una clave pública del dispositivo. Esa clave es única para el dispositivo al que se emitió el documento. Luego, usaré esa clave para validar la estructura de autenticación del dispositivo. Al hacerlo, se confirma que el documento proviene del dispositivo al cual fue emitido. Con esto finaliza el procesamiento de la respuesta. Lo que abarcamos aquí es una descripción general del trabajo necesario para validar la respuesta. Para conocer el procedimiento de validación preciso que debes realizar, consulta la norma ISO 18013-5. Ahora probaré el resto del flujo. Seleccionaré Wallet para responder la solicitud de Spaceship Rentals y, luego, haré la autenticación. Vemos que el flujo funciona y que Spaceship Rentals descifró y validó la información. ¡Ya podemos sacar nuestra nave espacial alquilada a dar una vuelta! ¿Erik, qué te pareció? ¡Buen trabajo! Voy a repasar algunos de los beneficios clave que se destacaron durante esta implementación. Primero, la API Digital Credentials es la mejor experiencia para los usuarios que deben verificar su identidad en la web, sin lugar a dudas. La integración con la API significa que tu sitio web accede a funciones de plataforma intuitivas, como los flujos entre dispositivos. Segundo, los sitios web que solicitan mdocs implementan un conjunto común de normas. Esto significa que el código que escribes funciona en cualquier navegador que admita esas mismas normas, permitiendo una mayor interoperabilidad. Por último, la API es simple y sencillamente más segura. Además de las protecciones mencionadas, esta API permite que las apps proveedoras de documentos validen el dominio en el sitio web solicitante. Esto dificulta los ataques de suplantación de identidad.

Con esto finaliza la implementación necesaria para integrarse con la API Digital Credentials de W3C. Creamos y firmamos una solicitud, la enviamos a través de la API Digital Credentials y procesamos la respuesta cifrada. Dejemos el tema del sitio web para solicitar un documento de identidad y centrémonos en la API Document Provider que hemos creado para que las apps participen en la verificación de documentos de identidad en línea. Mientras realizaba la verificación de identidad con Spaceship Rentals anteriormente, tuve la opción de usar una segunda app: la app Local Driving Authority. Esta es la app de muestra que creamos y que puede almacenar mi licencia de conducir.

Si selecciono la app Local Driving Authority, veremos la interfaz de usuario de autorización. Esta IU la brinda una extensión de app de IU que implementa la app. Si ya tienes una app de iOS que proporciona documentos, agregarás fácilmente esta extensión a tu app para habilitar la verificación de identidad en línea.

Esta experiencia se refuerza incorporando una nueva estructura centrada en los documentos de identidad: IdentityDocumentServices. Veamos cómo funciona. El primer paso se da fuera de la extensión de tu app. Cada vez que tu app proporcione un documento de identidad que puede mostrarse, registrarás ese documento con iOS. Esto permite que se muestre en la interfaz de usuario de selección. Cuando registres tu documento, deberás proporcionar el tipo de documento y las autoridades de certificación en las que confías para autorizar al sitio web solicitante. iOS conservará este registro de documento localmente en el dispositivo.

Luego, viene el flujo de verificación de identidad. El usuario activará este flujo. Después, iOS utiliza los registros de documentos almacenados para determinar qué apps pueden responder la solicitud. Después, muestra la IU de selección que vimos anteriormente.

A continuación, el usuario selecciona qué app desea utilizar. Luego, iOS envía una solicitud parcial a la app del proveedor de documentos para su uso. Quizás te estés preguntando esto: “¿Qué es una solicitud parcial?”. Bien, la solicitud de dispositivo ISO 18013 entrante tiene propiedades que que contienen blobs de datos sin procesar y analizables. Se codifican así para permitir a los proveedores de documentos calcular y validar las firmas con precisión. Pero analizar un blob de datos sin procesar de un sitio web sin ninguna interacción segura con el usuario podría ser una amenaza para los componentes del SO responsables de los datos del usuario. Para mitigar esto, el sistema analiza una parte de esta solicitud desde una zona protegida segura. Antes de analizar la solicitud, el sistema operativo valida primero las firmas en la solicitud. El resultado es una solicitud parcial que lleva la información necesaria para crear una IU, como solicitudes de documentos y certificados de autenticación.

Tu app recibirá esta solicitud parcial, que puedes usar para crear la IU que se mostrará en la extensión de tu app.

Luego, tras la autorización del usuario para divulgar su documento, la solicitud completa del dispositivo ISO 18013 se envía a la app proveedora de documentos para su uso. Entonces, la app proveedora de documentos compara las dos solicitudes para ver que coincidan y, luego, valida las firmas en la solicitud del dispositivo ISO 18013.

Una vez validada, la app puede generar su respuesta de documento y cifrarla en el sitio web solicitante.

Después, la respuesta se envía de vuelta a iOS, que la reenvía al sitio web. Marcos, ¿conoces algún Swift? Sé lo suficiente como para ser peligroso. ¡Excelente! Local Driving Authority necesita ayuda con su app, ¿puedes ayudar a integrar las API Document Provider? Por supuesto. Comencemos. ¡De acuerdo! Lo primero que debemos implementar es el paso de registro. Hay que hacer este paso cuando la app Local Driving Authority haya creado un mdoc. Todas las acciones de registro ocurren a través del tipo IdentityDocumentProviderRegistrationStore, así que primero inicializaré una tienda. Luego, crearé una instancia de un objeto MobileDocumentRegistration. Este objeto contiene la información para registrar un mdoc. Local Driving Authority emite licencias de conducir, así que pondré la cadena de tipo de documento estandarizado para licencias de conducir móviles. Puedes comprobarlo mediante la cadena mobileDocumentType “mDL”. Después, puedo indicar en qué identificadores de clave de autoridad confío. Esto permite que mi app aparezca en los momentos adecuados. Si llega una solicitud que no está firmada por una de estas autoridades de certificación, entonces mi app quedará oculta en la hoja de selección. Después, puedo proporcionar un identificador de documento. Este identificador puede vincularse fácilmente al almacenamiento que tengo para mi mdoc en mi app. Tras crear mi objeto de registro, puedo llamar al método addRegistration() para registrarlo con iOS.

Les di a los usuarios de mi app la posibilidad de eliminar sus licencias de conducir. Si eliminan su licencia de conducir, quiero asegurarme de que mi app ya no aparezca como una opción. Puedo lograrlo eliminando el registro que coincide con la licencia de conducir eliminada. Esto se hace a través del método removeRegistration(). Pasaré el identificador del documento que coincide con el registro del mdoc que creé anteriormente. Puede haber instancias en las que mi app necesite consultar los registros que están almacenados actualmente en el sistema. La propiedad de registros me permite hacer exactamente eso. Luego, puedo iterar a través de la lista de registros devuelta para inspeccionarlos. Lo siguiente es agregar la extensión de app de la IU a mi app.

Puedo hacerlo agregando un nuevo objetivo a mi proyecto Xcode y seleccionando la plantilla “Identity Document Provider”

Esto generará la extensión que debo implementar. Hay dos lugares donde se puede completar el código. El método performRegistrationUpdates() se ejecuta cuando un usuario autoriza a la app Local Driving Authority verificar su identidad en línea. Este método debe verificar todos los mdocs guardados en el almacenamiento de mi app y asegurarse de que estén registrados con iOS. El otro lugar a implementar es el contenido de la “Escena de solicitud de documento móvil ISO 18013”. Aquí es donde puedo crear la IU de autorización que aparece cuando el usuario selecciona mi app. Para implementar la IU, definiré un RequestAuthorizationView y le pasaré el contexto que recibo. Veamos la implementación de esta nueva vista. La vista recibe un ISO18013MobileDocumentRequestContext, que proporciona la extensión de app. Este tipo contiene la información de la solicitud y el método de devolución de llamada necesario para enviar una respuesta.

Al implementar el cuerpo de esta vista, hay tres partes principales de la interfaz de usuario. Necesito crear una vista que contenga información sobre quién realiza la solicitud y qué solicita. Para esto, definiré un RequestInfoView que toma la solicitud que recibo del objeto de contexto. Esta es la solicitud parcial de la que Erik habló antes. Después, debo implementar el botón para que el usuario “Acepte” la verificación de identidad. Esto implica llamar a un método acceptVerification() que definí en mi vista. Vamos a implementarlo. Cuando esté listo para aceptar la verificación, llamaré al método sendResponse() en el objeto de contexto de solicitud. Este método acepta un cierre. El cierre recibe un parámetro rawRequest. Aquí es donde la solicitud de dispositivo ISO 18013 entra a escena. Una vez que se recibe la solicitud del dispositivo, debo compararla con la solicitud parcial del objeto de contexto de solicitud. Ahora necesito validar la firma de la solicitud sin procesar. Esto es para ayudarme a confirmar que el sitio web es aquel en el que mi app confía.

Una vez que la solicitud se vea bien, crearé y cifraré la respuesta del documento. Finalmente, devolveré los datos de respuesta resultantes del cierre. Luego, esta respuesta se envía de vuelta al sitio web solicitante.

Con esto terminamos la implementación del método acceptVerification().

Lo último que necesitamos para completar nuestra IU es un botón “Decline”. Para implementarlo, solo hay que llamar al método de cancelación del contexto de solicitud.

Esa es la implementación básica de la app Local Driving Authority, Erik. Gracias, Marcos.

Ese fue nuestro recorrido por el flujo de verificación de mdoc en línea. Las dos API que abarcamos son muy flexibles, ya que permiten una amplia gama de experiencias de verificación de identidad en tus sitios web. Creemos que es la mejor solución para verificar la identidad en la web. Antes de irte, estos son algunos pasos para que empieces a integrarte con la API Digital Credentials. Si desarrollas sitios web y te interesa solicitar datos de identidad de los ID de Wallet, considera la posibilidad de registrarte en Apple Business Connect y recibir un certificado. Si quieres solicitar información de identidad de otras apps, como la de un gobierno local, habla con ellos sobre los requisitos adicionales de integración. En cambio, si desarrollas apps y te interesa proporcionar documentos de identidad, implementa la extensión de app Identity Document Provider en tu app. Independientemente de qué API utilices, consulta las distintas normas de las que hemos hablado a lo largo de esta sesión. Son tus fuentes de la verdad y te ayudarán a comprender los detalles del proceso de implementación.

Muchas gracias por ver nuestra sesión y ¡disfruta de la WWDC!