Verifique documentos de identidade na web

Olá! Meu nome é Erik. Sou engineer da equipe Wallet & Apple Pay. Oi! Eu sou Marcos, standards engineer na equipe WebKit. Hoje vamos mostrar como simplificar fluxos de verificação de identidade online usando documentos de identidade digital. Se você desenvolve sites e quer melhorar a verificação de identidade, desenvolve apps e quer permitir que seu app forneça comprovantes de identidade ou alguém que se interessa por identidade digital, esta sessão é para você. Documentos de identidade digital estão mais comuns, pois representam vários documentos, incluindo carteiras de habilitação e outros documentos emitidos pelo governo. Os documentos de identidade digital oferecem vantagens importantes em relação aos documentos físicos: uma é que são mais fáceis de usar online. Hoje, para provar minha identidade online, preciso carregar fotos do documento de identidade físico. Essa não é uma boa solução para o usuário nem para a empresa que está tentando verificar sua identidade. Para o usuário, é uma experiência ruim. Ele precisa primeiro pegar o documento de identidade físico. Depois, precisa encontrar um fundo adequado para tirar uma foto legível, que não esteja desfocada. Já a empresa precisa desenvolver uma solução complexa que processe as fotos e determine se os documentos são autênticos. É um problema difícil de resolver. Os documentos móveis, ou “mdocs”, são um exemplo de formato de documento de identidade digital que visa resolver isso. Os mdocs têm características únicas: São definidos pelo padrão ISO 18013-5. Isso permite que sejam usados em diferentes plataformas.

Eles também oferecem uma experiência de usuário mais privada. Se um solicitante só precisa confirmar meu nome e idade, essas são as únicas informações que eu deveria compartilhar. Os mdocs tornam isso possível. Eles contam com mais recursos de segurança do que um documento de identidade físico, sendo mais confiáveis. Por exemplo, as informações em um mdoc são assinadas criptograficamente pelo emissor para que uma empresa possa confiar que as informações recebidas são legítimas. Documentos de identidade no app Carteira da Apple são exemplos de documentos no formato mdoc e estão em conformidade com as normas ISO 18013.

Hoje, é possível apresentar documentos de identidade do app Carteira em alguns postos de segurança de aeroportos americanos, em algumas empresas e locais e nas Apple Stores nos EUA. Também é possível usar o documento de identidade em alguns apps que adotaram nossa API Verify with Wallet. Se você tem um app e gostaria de adotar a API Verify with Wallet para fazer a verificação de identidade, confira a sessão “Novidades do app Carteira e Apple Pay”, da WWDC22. Algumas jurisdições criaram apps de fornecimento de documentos no formato mdoc. Esses apps permitem que os usuários armazenem e usem documentos de identidade pessoalmente. Para imitar uma autoridade de trânsito local, criamos um app de demonstração que gerencia carteiras de habilitação. Nós demos um nome bem apropriado: Local Driving Authority. Este ano, temos o prazer de anunciar melhorias nos apps de fornecimento de documentos e no documento de identidade no app Carteira. Nossos próximos lançamentos, incluiremos compatibilidade com a API Digital Credentials do W3C para solicitar mdocs pelo Safari e pelo WebKit. Vou explicar como isso funciona. Digamos que eu esteja tentando alugar uma nave espacial da Spaceship Rentals. Já selecionei minha nave espacial e o itinerário pelo site no Safari. Agora, a empresa precisa verificar minha identidade. Vou tocar no botão “Verificar identidade”. Esse botão aciona a API Digital Credentials do JavaScript. Minha carteira de habilitação está armazenada em dois apps: Local Driving Authority e Carteira da Apple. Essa interface de seleção de app permite escolher qual usar na verificação de identidade.

Por enquanto, vou usar o app Carteira da Apple.

A página de consentimento é exibida para leitura. Posso ver quem está solicitando os dados do meu documento de identidade no ícone e nome da marca. Também posso ver exatamente o que a empresa está solicitando e se pretendem armazenar essas informações ou não. Vou autorizar essa verificação de identidade com o Face ID. Vemos que as informações são exibidas no site da Spaceship Rentals. Não é legal?

Erik, isso funcionou bem em um iPhone. Mas e no Mac? Excelente pergunta. Vou mostrar.

Estou novamente no Safari, desta vez no Mac. Acessei aquele mesmo site da Spaceship Rentals.

Vou clicar no botão “Verificar identidade”. Sou solicitado a continuar no meu iPhone. Uma notificação aparece no iPhone. Ela permite verificar minha identidade. Ao tocar nela, vejo a mesma opção para escolher qual app quero usar. Vou usar o app Carteira da Apple de novo. A mesma página de consentimento aparece: vejo quem está fazendo essa solicitação, quais informações está solicitando e se elas serão armazenadas. Eu aceito, então vou confirmar com o Face ID.

Incrível! Vemos que as informações do documento foram enviadas para a Spaceship Rentals no meu Mac. Além de incluir a compatibilidade com o Safari no Mac, também implementamos a compatibilidade padronizada para verificação de identidade entre plataformas com outros sistemas operacionais e navegadores. Portanto, ao alugar uma nave espacial em outra plataforma ou navegador, ainda posso usar meu documento de identidade no iPhone. Farei isso escaneando o código QR que o navegador exibe. Os fluxos abordados foram criados com base em um conjunto de padrões. Eles usam a API Digital Credentials do W3C, especificamente com o perfil de solicitação definido nas normas ISO 18013-7, Anexo C, e ISO 18013-5. O protocolo CTAP da FIDO é usado no fluxo multiplataforma. Portanto, os códigos que um site escrever para integrar as plataformas da Apple podem funcionar com outros navegadores e apps que adotam esses mesmos padrões.

A experiência é criada para ser multiplataforma desde o início. Isso inclui compatibilidade com iPhone, iPad e Mac, bem como outros navegadores e sistemas operacionais. Os usuários podem usar os documentos no iPhone para verificar a identidade em qualquer site. Por fim, criamos um conjunto de APIs Document Provider para as plataformas da Apple. Com essas APIs, apps como o Local Driving Authority aparecem como opção durante um fluxo de verificação de identidade. Vou detalhar as demonstrações que você acabou de ver e explicar como isso tudo funciona nos bastidores. A verificação do mdoc na Internet começa quando um usuário acessa um site no navegador. O site entra em contato com o próprio servidor para que ele crie e assine uma solicitação de mdoc. Assim que o site consegue a solicitação, pode usar a API Digital Credentials. Quando o usuário executa uma ação para iniciar a verificação de identidade, o site chama a API Digital Credentials com a solicitação.

O navegador encaminhará essa solicitação para o sistema operacional subjacente. O sistema operacional usa uma combinação da solicitação e da interação do usuário para determinar uma fonte de documento para atender à solicitação. Pode ser um app de fornecimento de documentos instalado no dispositivo ou até mesmo em outro dispositivo.

Após a decisão, a solicitação é encaminhada para a fonte de documentos apropriada para ser processada. O usuário autoriza a liberação do documento. Uma resposta criptografada é retornada da fonte de documento para o site solicitante. Por fim, o site envia essa resposta ao seu servidor para descriptografia e validação.

Ao diminuir o zoom, temos uma imagem mais clara dos vários componentes da verificação de um mdoc online nas plataformas da Apple. Existem dois modos diferentes para participar desse fluxo. Se você desenvolveu um app de fornecimento de documentos para iOS, pode se interessar na API Document Provider. Essa API permitirá que o app para iOS apareça como uma opção para concluir a verificação de um mdoc online.

Se você tem um site e quer verificar identidades online, implemente a API Digital Credentials do W3C e a lógica de processamento de solicitações e respostas associada. Vamos analisar melhor nesse fluxo.

Em termos gerais, há três etapas que um site deve seguir para solicitar um mdoc.

Quando o usuário acessa o site para a verificação de identidade, o site deve pedir para o próprio servidor criar e assinara solicitação de um documento. Quando o usuário estiver pronto para a verificação do documento de identidade, o site deverá passar a solicitação para o navegador por meio da API Digital Credentials do W3C.

Por fim, após receber uma resposta, o site deverá enviar a resposta criptografada ao próprio servidor para descriptografia e validação. Marcos, você parece ser um dedicado desenvolvedor full stack. Poderia nos mostrar como o site Spaceship Rentals pode integrar uma etapa de verificação de identidade em seu fluxo de check-out? Claro. Primeiro, vou mostrar como criar e assinar uma solicitação usando a API Digital Credentials do W3C. A solicitação que criaremos estará em conformidade com os padrões da norma ISO 18013-7, Anexo C. O pedido pode ser dividido em duas partes: a solicitação de um dispositivo e as informações de criptografia. Vamos ver mais detalhes sobre cada uma. A solicitação do dispositivo contém duas informações cruciais. Ela contém uma lista de solicitações de documentos, que é onde posso declarar qual documento desejo solicitar ao usuário. A Spaceship Rentals quer verificar uma carteira de habilitação, então vou incluir a string docType para carteiras de habilitação móveis na estrutura. Depois, adiciono as propriedades específicas da carteira de habilitação que quero solicitar. Isso é feito por meio de um conjunto padronizado de namespaces e identificadores de elementos. Aqui, vou solicitar o nome e sobrenome e, se a pessoa tiver mais de 21 anos, a foto de usuário e o status da carteira de motorista.

O outro parâmetro importante da solicitação do dispositivo é a lista “Reader Authentication All”. É aqui que o site assina a solicitação. Vamos usar essa propriedade daqui a pouco, então vou deixá-la em branco por enquanto. A segunda parte da solicitação são as informações de criptografia. É aqui que posso incluir os parâmetros que são usados pelo app de fornecimento de documentos para criptografar a resposta.

Vou precisar gerar um nonce para usar na criptografia. O nonce é um recurso de segurança importante que ajuda a nos proteger contra ataques de repetição. Também gerarei as chaves de criptografia de destinatário. Essas chaves serão usadas na criptografia da resposta do documento. Vou colocar a chave pública do destinatário na estrutura de informações de criptografia e guardar a chave privada do destinatário para usar depois. Isso permitirá descriptografar a resposta do documento, por isso é importante mantê-la seguro no meu servidor. Tudo junto, isso compõe uma solicitação completa.

Agora que criei a solicitação, posso assiná-la. Apps de fornecimento de documentos diferentes podem ter requisitos diferentes para assinar a solicitação. Quero que a Spaceship Rentals aceite um documento de identidade no app Carteira da Apple, então vou assinar a solicitação para a Carteira.

Antes de assinar a solicitação, preciso obter um certificado de assinatura do Apple Business Connect. Para isso, gero as chaves de assinatura e envio uma solicitação de assinatura de certificado para o Apple Business Connect. Agora que tenho o certificado, posso focar no que preciso fazer em tempo de execução. Depois, preciso gerar uma transcrição da sessão usando duas informações: o URL de origem do meu site e a estrutura de informações de criptografia que gerei anteriormente. Essa transcrição de sessão também será usada em operações posteriores. Após gerar a transcrição da sessão, poderei assinar. Para isso, usarei as chaves e o certificado de assinatura que recebi do Apple Business Connect. O resultado é uma estrutura de autenticação assinada.

Depois, posso incluir essa estrutura de autenticação assinada para o app Carteira na lista Reader Authentication All. Esse é um mecanismo definido na norma ISO 18013-5. Outros apps de fornecimento de documentos podem ter requisitos diferentes para a assinatura da solicitação. Quero aceitar documentos do app Local Driving Authority, mas eles exigem que eu assine a solicitação com um certificado completamente diferente que foi emitido.

No entanto, como Reader Authentication All é uma lista, posso assinar minha solicitação várias vezes. Então, criei outra estrutura de autenticação assinada usando o certificado do app Local Driving Authority. Posso inseri-la com a estrutura de autenticação assinada para o app Carteira.

Agora que tenho a solicitação, preciso passá-la para o navegador pela API Digital Credentials do W3C em JavaScript. Podemos pegar os dados da solicitação que criamos no servidor e colocá-los no dicionário de solicitações. Também defino que essa é uma solicitação “mdoc” por meio da propriedade “protocol” com a string padronizada “org-iso-mdoc”. Agora, podemos chamar o método navigator.credentials.get e aguardar sua resposta. Chamar esse método faz o navegador apresentar a interface do sistema que permite selecionar uma credencial digital. A chamada do método get deve ser feita por meio de uma ação do usuário, como um clique do mouse ou o pressionamento de um botão. Assim que recebermos a resposta, poderemos enviá-la de volta ao servidor para descriptografia. As respostas são serializáveis em JSON e podem ser facilmente enviadas de volta ao servidor com a API Fetch ou com XHR. Se algo der errado, a API Digital Credentials do W3C fornecerá um conjunto de exceções para ajudar seu programa a se recuperar. Você também pode recorrer a um método de verificação de identidade existente, como a verificação de uma imagem do documento de identidade carregada em um formulário HTML. Ótimo. Vamos testar nosso código para garantir que ele funcione. Fantástico! Quando pressiono o botão Verificar identidade, a interface do sistema aparece. Isso significa que nossa solicitação está funcionando. Os apps Carteira e Local Driving Authority aparecem como opções para o usuário. O que você acha, Erik? Está ótimo até agora, Marcos. Antes de passarmos para a próximo etapa, vou falar sobre a segurança desse fluxo. Ao lidar com informações confidenciais como dados do documento de identidade, é importante implementar as proteções corretas. Você talvez tenha alguma destas dúvidas: Quem solicita os dados do documento de identidade? Os dados do documento de identidade estão protegidos? Eles são autênticos? Ou foram copiados? Vou analisar cada uma das proteções que existem nos padrões para responder a essas perguntas.

Já falamos sobre a solicitação de autenticação. Com ela, os sites solicitantes se identificam e os apps de fornecimento de documentos ajudam os usuários a entender quem está fazendo a solicitação. Isso é feito por meio de um certificado usado para assinar a solicitação.

Em seguida, temos a criptografia da resposta. A resposta é criptografada de ponta a ponta usando uma chave gerada pelo servidor do site solicitante. Isso impede que outras partes leiam os dados de identidade, entre elas, o navegador e o sistema operacional. A autenticação do emissor é usada para provar a autenticidade dos dados de identidade. Isso permite que o site solicitante determine quem emitiu os dados e se eles são confiáveis. Também impede a modificação dos dados retornados. Por fim, a autenticação do mdoc evita a duplicação dos dados. Isso permite que os sites solicitantes verifiquem se o mdoc que receberam é do mesmo dispositivo para o qual foi emitido. Isso evita a possibilidade de duplicação do mdoc em vários dispositivos.

Marcos, poderia nos mostrar como essas propriedades de segurança entram em ação ao lidar com a resposta? Claro! Vamos lá!

Para terminar a implementação do Spaceship Rentals, só preciso lidar com a resposta enviada pelo app de fornecimento de documentos. Tal como acontece com a solicitação, o formato de resposta em JavaScript está definido no padrão ISO 18013-7, Anexo C. A resposta também contém duas propriedades. Uma delas é o texto cifrado que preciso descriptografar. A outra é a chave que o app de fornecimento de documentos gerou como parte do processo de criptografia. O texto cifrado usa criptografia de chave pública híbrida, ou HPKE, que é definida na norma RFC-9180.

As entradas para a descriptografia incluem o texto cifrado e a chave pública do remetente da resposta. Elas também incluem a chave privada do destinatário que geramos anteriormente no servidor ao criar a solicitação. A entrada final é a mesma transcrição de sessão que geramos anteriormente para assinar a solicitação. O resultado dessa operação é uma resposta de dispositivo descriptografada. Cada documento na resposta contém um objeto de segurança móvel. Esse objeto é imutável e é assinado pelo emissor. Ele contém informações importantes para validar que os dados retornados são autênticos. O objeto de segurança móvel é autenticado por meio da estrutura de autenticação do emissor. Essa estrutura contém um certificado de signatário de documento que precisa ser validado antes. Isso é feito vinculando-o a um certificado raiz da autoridade emissora confiável que o emissor publica. O servidor da Spaceship Rentals mantém uma lista de certificados raiz confiáveis da autoridade emissora para determinar quais mdocs aceitar. Se um certificado de signatário de documento não for confiável, devemos descartar a resposta. Depois de verificar o certificado, precisarei validar a assinatura. Depois que a estrutura de autenticação do emissor for validada, poderei passar para a validação do objeto de segurança móvel. Há várias validações a serem feitas aqui, e o mais importante é que preciso validar a autenticidade dos elementos retornados. Esses elementos retornados podem ser encontrados nos namespaces do emissor. Por exemplo, aqui podemos ver que o nome “Kelly” foi retornado. Antes que eu possa usá-lo, preciso provar que esse elemento não foi adulterado. Para isso, processamos um resumo de hash em toda a estrutura de informações do elemento. Depois, comparamos o resumo com um resumo específico que existe no objeto de segurança móvel. Posso encontrar o resumo com o qual comparar usando o identificador de resumo fornecido na estrutura do elemento. Após a comparação dos resumos, posso ter certeza de que os dados são autênticos. Por fim, preciso validar a autenticação do mdoc. O objeto de segurança móvel contém uma chave pública do dispositivo. Essa chave é exclusiva do dispositivo para o qual o documento foi emitido. Usarei essa chave para validar a estrutura de autenticação de dispositivo. Isso confirma que o documento veio do dispositivo para o qual foi emitido. Isso conclui o processamento da resposta. Abordamos aqui uma visão geral do trabalho necessário para validar a resposta. Para obter o procedimento de validação preciso que deve ser executado, consulte o padrão ISO 18013-5. Agora, vou testar o restante do fluxo. Vou selecionar Carteira para responder à solicitação da Spaceship Rentals e fazer a autenticação Notamos que o fluxo funciona e as informações foram descriptografadas e validadas pela Spaceship Rentals. Agora podemos dar uma volta na nossa nave espacial alugada. Erik, o que você achou? Bom trabalho! Vou relembrar alguns benefícios importantes destacados durante a implementação. Primeiro, a API Digital Credentials oferece a melhor experiência para usuários que precisam verificar a identidade na Internet. Ao integrar a API, seu site tem acesso a recursos fáceis de usar da plataforma, como os fluxos entre dispositivos. Segundo, os sites que solicitam mdocs estão implementando um conjunto comum de padrões. Portanto, o código que você escreve funciona em qualquer navegador compatível com esses padrões, permitindo uma interoperabilidade mais ampla. Por fim, a API é mais segura. Além das proteções que mencionamos, essa API permite que os apps de fornecimento de documentos validem o domínio no site solicitante. Isso dificulta a execução de ataques de phishing.

Isso conclui a implementação necessária para a integração da API Digital Credentials do W3C. Criamos e assinamos uma solicitação, enviamos a solicitação pela API Digital Credentials e processamos a resposta criptografada. Vou parar de falar sobre o trabalho que o site precisa fazer para solicitar um mdoc e me concentrar na API Document Provider que criamos para permitir que apps participem da verificação online do mdoc. Ao verificar a identidade na Spaceship Rentals, havia a opção de usar outro app: o Local Driving Authority. É o app de exemplo que criamos que pode armazenar minha carteira de habilitação.

Ao escolher o app Local Driving Authority, esta interface de autorização aparece. Ela é fornecida por uma extensão de apps na interface implementada no app. Se já tiver um app para iOS que forneça documentos, você poderá adicionar essa extensão facilmente para permitir a verificação de identidade online.

Essa experiência é viabilizada pela adição de um novo framework focado em documentos de identidade: IdentityDocumentServices. Vou mostrar como funciona. A primeira etapa acontece fora da extensão de apps. Sempre que seu app provisionar um documento de identidade que possa ser apresentado, você registrará esse documento no iOS. Assim, ele ficará disponível para ser exibido na interface da seleção. Ao registrar o documento, você informa o tipo desse documento e em quais autoridades de certificação você confia para autorizar o site solicitante. O iOS manterá o registro desse documento localmente no dispositivo.

Em seguida, acontece o fluxo de verificação de identidade. O usuário acionará esse fluxo. O iOS usará os registros de documentos armazenados para determinar quais apps podem responder à solicitação. Depois, ele exibirá a interface da seleção que já vimos.

O usuário seleciona qual app gostaria de usar. O iOS envia uma solicitação parcial para o app de fornecimento de documentos usar. Você deve estar se perguntando: “O que é uma solicitação parcial?” A solicitação do dispositivo recebida em conformidade com ISO 18013 contém várias propriedades com blobs de dados brutos e analisáveis. Eles são codificados como tal para permitir que apps de fornecimento de documentos processem e validem assinaturas com precisão. Porém, analisar um blob de dados brutos de um site sem interação garantida do usuário pode ser uma ameaça para os componentes do sistema operacional responsáveis pelos dados do usuário. Para evitar isso, o sistema analisa uma parte dessa solicitação dentro de um sandbox seguro. Antes de analisar a solicitação, o sistema operacional valida as assinaturas na solicitação. Isso gera uma solicitação parcial que contém as informações necessárias para criar uma interface, como as solicitações de documentos e os certificados de autenticação.

Seu app receberá essa solicitação parcial, que você poderá usar para criar a interface a ser exibida na extensão do app.

Depois que o usuário autorizar a liberação do documento, a solicitação do dispositivo completa em conformidade com ISO 18013 é liberada para uso no app de fornecimento de documentos. O app de fornecimento de documentos compara as duas solicitações para garantir que sejam consistentes e valida as assinaturas na solicitação do dispositivo em conformidade com ISO 18013.

Após a validação, o app cria sua resposta do documento e a criptografa para o site solicitante.

A resposta é enviada de volta para o iOS, que a encaminha para o site. Marcos, você sabe programar em Swift? Sei o suficiente para fazer estrago. Ótimo. A autoridade de trânsito local precisa de ajuda no app. Você pode ajudá-la a integrar as APIs Document Provider? Claro. Vamos lá! OK! Primeiro, precisamos implementar a etapa de registro. Essa etapa deve acontecer assim que o app Local Driving Authority criar um mdoc. Todas as ações de registro acontecem por meio do tipo IdentityDocumentProviderRegistrationStore, então vou iniciar uma função store. Depois, vou instanciar um objeto MobileDocumentRegistration. Este objeto contém as informações para registrar um mdoc. A autoridade de trânsito local emite carteiras de habilitação, então vou incluir a string de tipo de documento padronizado para carteiras de habilitação móveis. Notamos isso pela string “mDL” em mobileDocumentType. Posso indicar em quais identificadores de chave de autoridade eu confio. Isso permite que meu app seja exibido nos momentos apropriados. Se chegar uma solicitação não assinada por uma dessas autoridades de certificação, meu app ficará oculto na página de seleção. Depois, posso fornecer um identificador de documento. Esse identificador pode ser facilmente vinculado ao armazenamento que tenho para meu mdoc no app. Após criar meu objeto de registro, poderei chamar o método addRegistration() para registrá-lo no iOS.

Eu disponibilizei aos usuários do meu app a capacidade de remover suas carteiras de habilitação. Quero garantir que, se fizerem isso, meu app não apareça mais como uma opção. Para isso, removo o registro que corresponde à carteira de habilitação apagada com o método removeRegistration(). Passarei o identificador do documento que corresponde ao registro do mdoc que criei anteriormente. Pode haver casos em que meu app precise consultar os registros que estão armazenados no sistema. A propriedade registrations permite fazer exatamente isso. Posso iterar usando a lista retornada de registros para inspecioná-los. Posso adicionar a extensão de apps na interface ao meu app.

Para isso, adiciono um novo destino ao meu projeto do Xcode e seleciono o modelo “Identity Document Provider”.

Isso vai gerar a extensão que devo implementar. Há dois lugares onde o código pode ser preenchido. O método performRegistrationUpdates() é chamado quando um usuário autoriza o app Local Driving Authority a verificar a identidade online. Esse método deve verificar todos os mdocs armazenados no meu app e confirmar se estão registrados no iOS. Também posso implementar no conteúdo ISO18013MobileDocumentRequestScene. É aqui que posso criar a interface da autorização que é exibida quando o usuário seleciona meu app. Para implementar a interface, vou definir um RequestAuthorizationView e passar o contexto recebido para ele. Vamos conferir a implementação dessa nova view. Ela utiliza um ISO18013MobileDocumentRequestContext, que é fornecido pela extensão do app. Esse tipo contém as informações da solicitação e o método de callback exigido para enviar uma resposta.

Ao implementar o body dessa view, há três partes principais da interface. Preciso criar uma view com as informações sobre quem está fazendo a solicitação e o que é solicitado. Para isso, definirei um RequestInfoView que processa a solicitação que recebo do objeto de contexto. Essa é a solicitação parcial sobre a qual Erik já falou. Preciso implementar o botão para o usuário “Aceitar” a verificação de identidade. Isso envolve chamar o método acceptVerification() que defini em minha view. Vamos implementar isso. Quando estiver pronto para aceitar a verificação, chamarei o método sendResponse() no objeto de contexto da solicitação. Este método aceita um fechamento. O fechamento recebe um parâmetro rawRequest. É aqui que entra a solicitação do dispositivo em conformidade com ISO 18013. Depois que a solicitação do dispositivo for recebida, precisarei compará-la com a solicitação parcial do objeto de contexto de solicitação. Agora preciso validar a assinatura da solicitação bruta. Isso ajuda a confirmar que o site é da confiança do meu app.

Quando estiver tudo certo com solicitação, vou criar e criptografar a resposta do documento. Por fim, retornarei os dados da resposta resultantes do fechamento. Essa resposta retornada é enviada de volta ao site solicitante.

Isso conclui a implementação do método acceptVerification().

Para concluir a interface, só falta incluir o botão “Recusar” Para implementá-lo, basta chamar o método cancel do contexto de solicitação.

Essa é a implementação básica do app Local Driving Authority local, Erik. Obrigado, Marcos.

Esse foi o nosso tour pelo fluxo de verificação do mdoc online. As duas APIs que abordamos oferecem flexibilidade para viabilizar diversas experiências de verificação de identidade nos seus sites. Na nossa opinião, essa é a melhor solução para verificação de identidade na Internet. Antes de sair, confira as próximas etapas para você começar a integrar a API Digital Credentials. Se você desenvolve sites e quer solicitar informações de identidade de documentos no app Carteira, registre-se no Apple Business Connect e receba um certificado. Se quiser solicitar informações de identidade de outros apps, como um app do governo local, verifique com eles os outros requisitos de integração. Se você desenvolve apps e quer fornecer documentos de identidade, implemente a extensão Identity Document Provider no seu app. Independentemente de qual API você usar, confira os vários padrões que abordamos nesta sessão. Eles serão suas fontes da verdade e ajudarão você a entender os detalhes do processo de implementação.

Agradecemos sua participação na nossa sessão. Aproveite a WWDC!