Autenticação Gov o plugin não é obrigatório

[eSoares]

No caso do site autenticacao.gov.pt o plugin Java mencionado não é de uso obrigatório, pois é possível fazer autenticação pela chave móvel digital.

Além disso, creio não há formas standard de aceder a um smartcard por APIs dos browsers.
Existe algumas tentativas de resolver a questão, por exemplo em [1] é apontado usar-se WebUSB para aceder ao leitor, mas além de ser pouco suportado nos browsers [2] a resposta refere que o acesso a smartcards é bloqueado.
Outras soluções apontadas, acabam sempre por recorrer a extensões dos browsers, ficando dependente destes e não são realmente standard ou future proof .

Não havendo assim uma alternativa a apontar-se, não creio que faça sentido apontar-se como defeito o uso do dito plugin.

[1] - https://stackoverflow.com/a/32763770
[2]- https://caniuse.com/#search=webusb

[marado]

Com o disclaimer de que isto não é uma análise legal (IANAL), aquilo que considero sobre este assunto:

métodos de autenticação alternativos

É verdade que cada site que opte por usar o Autenticação.Gov pode também optar por métodos alternativos de autenticação. Esta entrada está assim por uma questão de simplificação, na realidade o potencial incumprimento será de quem usa este modelo de autenticação. Por outro lado, o proprio site do autenticação Gov tem autenticação, também ela no modelo apontado: com uma alternativa de autenticação através da CMD.

Haver uma forma alternativa (que cumpra o RNID) é suficiente para não ser uma violação ao regulamento (por exemplo, um documento publicado em OOXML mas também em ODF), mas tem de ser alternativa real. Tal como "entregar o IRS usando a app offline" não é considerada alternativa à entrega via web, não me parece comparável a autenticação via cartão de cidadão (que, assume-me, todo o utilizador tem) e a autenticação com a chave móvel digital (para qual a criação de credenciais é um processo offline, em que as credenciais não ficam logo disponíveis, a não ser que o pedido seja feito após autenticação pelo outro método).

o uso do actual plugin

Um site tendo esta como forma de autenticação não cumpre o RNID, por o actual plugin não constituir uma norma aberta, com todos os problemas que daí advém (por ex., a impossibilidade de usar o plugin em Android, que hoje é Sistema Operativo mais usado, com 40% do mercado).

Nenhuma das exceções inscritas na Lei ou Regulamentos aparentam aplicar-se ao caso actual, e tudo indica que não foi pedida excepção específica neste caso. Talvez mais informação sobre isso seja publicado no (obrigatório, por lei) relatório anual da interoperabilidade digital... Quando um for feito. Lei de 2011, e o relatório "anual" ainda terá de ter o seu primeiro número a ver a luz do dia.

Resta, assim, optar-se por uma implementação que cumpra o RNID. De notar que, mesmo que fosse pedida uma exceção para este caso, seria necessário avaliar "se existe já um projecto de desenvolvimento avançado de uma solução de tipo aberto", o que, neste caso (e a meu ver), faria com que tal excepção fosse rejeitada.

Uma implementação cumpridora do RNID

Ainda que o foco deste repositório seja apontar os casos de incumprimento, e não o desenho de soluções, parece-me que a análise do estado da arte está equivocada.

A solução técnica para este tipo de cenários (autenticação na web via smartcards) parece-me ser o FIDO2[1], que assenta sobretudo nas normas CTAP (para a comunicação com o hardware) e Webauthn (que é a norma que faz esta solução ser suportada nos browsers que a implementam). FIDO2 funciona numa panóplia de Sistemas Operativos (e é livremente implementável), e o Webauthn está já implementado na maioria dos browsers (incluindo todos os mais populares)[2].

[1] https://fidoalliance.org/fido2/
[2] https://caniuse.com/#search=webauthn

A autenticação nesta lista

Vou manter a entrada da autenticação na lista de incumprimentos, ainda que se aceitem sugestões sobre uma melhor forma de representar este incumprimento na tabela. Claro que contra-argumentos são bem vindos, ainda que a mais correcta forma de levar este debate adiante é proceder ao pedido de cumprimento para este caso em particular, e ter em atenção à resposta.

[marado]

Um ano sem comentários... vou fechar este issue, mas estejam à vontade para comentar, pode-se sempre reabrir.

[hugopeixoto]

Não quero questionar a decisão de manter ou remover este incumprimento, mas gostava de elaborar aqui mais um bocado.
Assumam que todas as frases têm "acho eu", porque não tenho grande certezas aqui.

Sobre o Webauthn

A solução técnica para este tipo de cenários (autenticação na web via smartcards) parece-me ser o FIDO2

Andei a ler sobre Webauthn, e não me parece adequado.

O Webauthn é um mecanismo alternativo a passwords para registo/login. Durante o registo num site, o dispositivo autenticador cria um par de chaves novo, envia a chave publica para o site, e no próximo login essa chave é usada para verificar que é a mesma pessoa. Sempre que há um registo num site diferente, o autenticador gera uma chave nova para evitar correlações.

O standard tem um mecanismo para garantir que o autenticador pertence a um certo fabricante (ou que é certificado pela entidade X, como o estado português), mas não tem mecanismo para te identificar como cidadãe nr 12345678. O "evitar correlações" é exactamente o oposto disto.

Identificação à parte, o cartão de cidadão não deve ter o necessário para implementar a geração e armazenamento das chaves, ou seja, o protocolo CTAP que falaste. Não sei se o leitor tem de de implementar algo ou se é só o cartão.

Sobre o incumprimento

não me parece comparável a autenticação via cartão de cidadão (que, assume-me, todo o utilizador tem) e a autenticação com a chave móvel digital (para qual a criação de credenciais é um processo offline, em que as credenciais não ficam logo disponíveis, a não ser que o pedido seja feito após autenticação pelo outro método).

Considerando que para usar o CC é preciso comprar e andar com um dispositivo específico (já que o CC não tem NFC), parece-me que o método de CMD até é mais acessível, mesmo que precise de ser feito o tal processo.

Com a infrastrutura actual do CC não há forma de que isto funcione sem ter software extra a correr, o que me parece ser um motivo válido para pedirem (e receberem) uma excepção.

Sobre o código (off-topic)

O middleware está licenciado sob EUPL:

Este software é disponibilizado pelo Estado Português (Agência para a Modernização Administrativa IP e Instituto de Registos e Notariado IP) sob licença EUPL v1.1.

Julgo que o código seja este: https://github.com/amagovpt/autenticacao.gov

Suponho que com isto seja possível construir algo que funcione em android. Curioso não o terem feito, mas talvez a CMD seja um esforço mais proveitoso para chegar a mais cidadães.

[marado]

sobre a alternativa

Na versão 4.0 do "Overview of Member States’ eID strategies" da Comissão Europeia ( https://ec.europa.eu/cefdigital/wiki/download/attachments/364643428/eID_Strategies_v4.0.pdf ) é dito que na Bélgica estão a considerar o FIDO2 (mas sem grandes detalhes). Será talvez interessante tanto entender o que eles estão a pensar fazer ao certo, como olhar para esse documento com calma e perceber o que vai sendo feito ou planeado nos outros países.

sobre o off-topic

Julgo que o código seja este: https://github.com/amagovpt/autenticacao.gov

Esse repositório tem o código (quase total) da app para o cartão de cidadão, mas não do plugin (que é outro projecto, desenvolvido por outra equipa, e - que eu saiba - sem código disponível).

[hugopeixoto]

sobre a alternativa

Na versão 4.0 do "Overview of Member States’ eID strategies" da Comissão Europeia ( https://ec.europa.eu/cefdigital/wiki/download/attachments/364643428/eID_Strategies_v4.0.pdf ) é dito que na Bélgica estão a considerar o FIDO2 (mas sem grandes detalhes). Será talvez interessante tanto entender o que eles estão a pensar fazer ao certo, como olhar para esse documento com calma e perceber o que vai sendo feito ou planeado nos outros países.

Bom documento, vou dar uma leitura mais tarde.

Entretanto, uma pesquisa rápida levou-me a este documento: FIDO Alliance White Paper: Using FIDO with eIDAS Services

Segundo o diagrama, Webauthn serve para a parte de login ("authentication"), e não para a parte de identification:

Também referem isto na tabela da secção 2.2:

In other words, FIDO does not provide any means for identification. Hence, the
issuer of the eID needs to ensure that the enrollment process complies with
the eIDAS requirements. Therefore, the credentials enrollment to the FIDO2
authenticator needs to be done by other means, e.g. by identifying the user
with a national ID card (during the initial identification process) or when the
user authenticates to the CA online by using her eID

Parece-me um mecanismo semelhante ao da CMD, mas em vez de associares um número de telefone associas um dispositivo autenticador (yubikey com FIDO2 ou semelhante), mas esse processo sofre das mesmas limitações que mencionaste para a CMD:

a criação de credenciais é um processo offline, em que as credenciais não ficam logo disponíveis, a não ser que o pedido seja feito após autenticação pelo outro método

sobre o off-topic

Esse repositório tem o código (quase total) da app para o cartão de cidadão, mas não do plugin (que é outro projecto, desenvolvido por outra equipa, e - que eu saiba - sem código disponível).

Hm, o .deb do plugin tem um ficheiro copyright que diz que o software está sobre a EUPL. Pode ser uma questão de o pedir à AMA? O changelog indica um rui.martinho@ama.pt.