SCAP: como validar identidade profissional com PKI na prática

>Portugal acabou de dar mais um passo silencioso, mas tecnicamente relevante, na digitalização de identidade profissional. A app gov.pt agora aceita a cédula profissional do médico dentista em formato digital e integra o SCAP — o sistema que permite a enfermeiros assinarem documentos com validação profissional atrelada ao certificado. Segundo o Sapo.pt, a novidade surge dentro da estratégia de concentrar documentos oficiais no smartphone. Para nós, devs, o que importa mesmo está debaixo do capô: PKI, atributos certificados e validação criptográfica em ambiente mobile. É isso que vou dissecar.

O que mudou concretamente na gov.pt

Antes de entrar na parte técnica, o resumo rápido para quem não leu a fonte: a partir de agora, médicos dentistas conseguem carregar a cédula profissional direto no app gov.pt, com a mesma validade legal do documento físico. Enfermeiros, por sua vez, passam a poder assinar documentos digitalmente via integração com o SCAP (Sistema de Certificação de Atributos Profissionais).

Na prática, isso significa três coisas:

• Identidade profissional portátil — o documento deixa de viver em plástico e passa a viver em um container criptográfico no dispositivo.
• Assinatura com atributo vinculado — o SCAP embute a profissão e o número de licença dentro do próprio certificado, não só o nome do titular.
• Validação offline-friendly — a app permite apresentar o documento mesmo sem conexão, porque a cadeia de confiança é embarcada.

SCAP: a engrenagem técnica por trás da novidade

O SCAP é, traduzindo para a linguagem que a gente usa no dia a dia, um sistema de PKI com atributos profissionais embarcados no certificado. Quem trabalha com e-CPF no Brasil ou com o Cartão de Cidadão em Portugal já viu esse padrão: o certificado X.509 não carrega só chave pública e nome — ele carrega extensões com OIDs customizados que descrevem papéis, números de registro e qualificações.

Quando um enfermeiro assina um documento via SCAP, o que está sendo validado em três camadas simultâneas é:

1. Integridade — o hash do documento bate com a assinatura RSA/ECDSA?
2. Autenticidade — a chave usada pertence mesmo ao certificado apresentado?
3. Atributo profissional — o certificado foi emitido por uma autoridade certificadora subordinada à Ordem dos Enfermeiros, com o OID específico da profissão válido e não revogado?

Esse terceiro ponto é o que diferencia uma assinatura digital comum de uma assinatura profissional qualificada. Sem ele, qualquer pessoa com um certificado eIDAS poderia assinar um documento de enfermagem — o que juridicamente não valeria.

Comparativo: como outros países estão resolvendo o mesmo problema

O movimento de Portugal se aproxima mais do modelo estoniano do que do americano. Isso é relevante porque o stack europeu tende a convergir para o eIDAS 2.0, que padroniza carteiras digitais em toda a UE até 2026 — o gov.pt está se posicionando para interoperar.

Na Prática: verificando uma assinatura com atributo profissional

Para quem vai integrar um sistema desses — seja para validar documentos no back-end, seja para emitir credenciais —, o fluxo se resume a: carregar o certificado, validar a cadeia até a AC raiz, extrair as extensões de atributos e validar a assinatura sobre o documento. Em Python, com a lib cryptography, fica assim:

from cryptography import x509
from cryptography.hazmat.primitives import hashes, serialization
from cryptography.hazmat.primitives.asymmetric import padding
from cryptography.x509.oid import NameOID

def verify_professional_signature(cert_pem: bytes,
                                   document: bytes,
                                   signature: bytes,
                                   expected_oid: str) -> dict:
    # 1. Carrega o certificado X.509 do profissional
    cert = x509.load_pem_x509_certificate(cert_pem)

    # 2. Extrai o nome do titular e atributos relevantes
    subject = cert.subject
    common_name = subject.get_attributes_for_oid(NameOID.COMMON_NAME)[0].value

    # 3. Procura a extensão profissional customizada
    professional_attrs = []
    for ext in cert.extensions:
        if ext.oid.dotted_string == expected_oid:
            professional_attrs.append(ext.value)

    # 4. Valida a assinatura sobre o documento
    try:
        cert.public_key().verify(
            signature,
            document,
            padding.PKCS1v15(),
            hashes.SHA256()
        )
        signature_ok = True
    except Exception:
        signature_ok = False

    return {
        "titular": common_name,
        "atributos_profissionais": professional_attrs,
        "assinatura_valida": signature_ok,
        "valido_ate": cert.not_valid_after_utc.isoformat(),
    }

Esse é o esqueleto mínimo. Em produção você ainda precisa checar revogação via CRL ou OCSP, validar o caminho de certificação contra a AC raiz da Ordem profissional e — em mobile — armazenar a chave privada no Secure Enclave (iOS) ou Android Keystore (Android). Sem isso, o sistema é inútil do ponto de vista jurídico.

Erros comuns que devs cometem ao integrar identidade digital

Já vi (e cometi) alguns equívocos clássicos. Anota aí:

• Confiar só na assinatura, não no atributo. Validar RSA/ECDSA é o fácil. Esquecer de checar que o OID da profissão está presente e não expirou é o erro que derruba sistemas em auditoria.
• Não verificar revogação. Certificado revogado ontem ainda valida criptograficamente hoje. Sem CRL ou OCSP, sua app aceita documentos de profissionais suspensos.
• Armazenar chave privada no shared preferences. No mobile, a chave do SCAP tem que ir pro Keystore/Secure Enclave com setUserAuthenticationRequired(true). Armazenar em texto plano é tirar a razão de ser do sistema.
• Assumir que o cartão SIM é seguro. O SIM não é um hardware seguro confiável para identidade. Usar eSE (embedded Secure Element) ou TEE é o caminho sério.
• Ignorar o relógio do dispositivo. Validade de certificado depende de tempo. Apps que não usam NTP confiável criam brechas de janela de validade.

Na minha experiência, o ponto que mais derruba equipes é o terceiro. A tentação de “simplificar” colocando a chave em local acessível é grande — mas é exatamente o que diferencia uma carteira digital real de um app que só exibe uma imagem do documento.

FAQ

O SCAP substitui o certificado digital eIDAS?
Não. O SCAP é uma camada adicional que vincula atributos profissionais ao certificado. Ele opera sobre a infraestrutura eIDAS, não em substituição.

Um dev fora de Portugal pode testar essa integração?
Sim, indiretamente. O ecossistema de atributos profissionais segue padrões W3C Verifiable Credentials, então dá pra simular com carteiras compatíveis e OIDs próprios. Para produção real, é necessário acordo com a Ordem profissional emissora.

Qual a diferença prática entre a cédula física e a digital no app?
Tecnicamente, nenhuma diferença jurídica — ambas têm fé pública. A diferença operacional é que a versão digital permite validação automática por terceiros via leitura de QR code assinado, eliminando conferência visual.

Esse padrão vai abrir caminho para outras profissões?
Quase certamente. O eIDAS 2.0 europeu pressiona por carteiras de atributos interoperáveis até 2026. O movimento português com dentistas e enfermeiros é piloto para expansão a farmacêuticos, psicólogos e engenheiros técnicos.

Vale a pena aprender PKI a fundo em 2026?
Se você trabalha com identidade, fintech, saúde ou governo — sim, é uma das habilidades mais mal-distribuídas do mercado. A maioria dos devs sabe “HTTPS usa TLS”, mas poucos sabem validar uma cadeia X.509 com atributos customizados. É diferencial real.

Gostou? Me segue no GitHub e deixa um comentário se tiver dúvida ou quiser aprofundar algum ponto. Se quiser que eu detalhe a integração com Android Keystore ou o fluxo OCSP/SCAP no back-end, é só pedir.