Especificações do OpenID Connect publicadas como normas ISO

 (self-issued.info)
1 pontos por GN⁺ 2024-11-11 | 1 comentários | Compartilhar no WhatsApp
  • Nove especificações do OpenID Connect foram publicadas como normas ISO/IEC, colocando o Core 1.0, Discovery, Dynamic Client Registration, especificações de logout e modos de resposta OAuth 2.0 dentro do sistema internacional de normas
  • A OpenID Foundation submeteu as especificações à ISO em dezembro de 2023 pelo processo PAS (Publicly Available Specifications) e, depois, concluiu a publicação após a votação de aprovação da ISO
  • Com a padronização ISO, a implantação do OpenID Connect pode se tornar mais fácil também em jurisdições que exigem especificações de organismos de padronização reconhecidos por tratados internacionais
  • Antes da submissão, o OpenID Connect working group conduziu o processo de aplicação de errata corrections para que a versão ISO incluísse correções conhecidas
  • Com base na experiência deste processo PAS, a OpenID Foundation planeja submeter também o FAPI 1.0 e, após a finalização, os conjuntos de especificações eKYC-IDA e FAPI 2.0 para publicação pela ISO

Especificações publicadas como normas ISO/IEC

Submissão PAS e aprovação ISO

  • A submissão das especificações OpenID Connect em nome da OpenID Foundation foi feita em dezembro de 2023 na forma de PAS (Publicly Available Specifications)
  • Após a votação de aprovação da ISO, essas especificações foram publicadas como normas ISO/IEC
  • Como a ISO é um dos organismos de padronização reconhecidos por tratados internacionais, isso pode ampliar as possibilidades de adoção do OpenID Connect em jurisdições que exigem legalmente o uso de normas desses organismos

Correções incluídas na versão ISO

  • Antes da submissão, o OpenID Connect working group conduziu o processo de aplicação de errata corrections às especificações
  • Como resultado, as correções conhecidas foram refletidas na versão ISO

Próximos planos de submissão à ISO

  • Depois de concluir uma vez o processo de submissão ISO PAS, a OpenID Foundation planeja submeter outros conjuntos de especificações finais para publicação pela ISO
  • O próximo alvo inclui a especificação FAPI 1.0
  • As especificações eKYC-IDA e FAPI 2.0 estão previstas para submissão após sua finalização

Leituras relacionadas

1 comentários

 
GN⁺ 2024-11-11
Opiniões no Hacker News

  • Mesmo tendo me envolvido bastante com OpenID há cerca de 17 anos (https://simonwillison.net/search/?tag=openid&year=2007), levei um tempo constrangedor para entender que o OpenID Connect tem pouquíssima relação com a ideia original do OpenID de que “o identificador é uma URL e você prova a propriedade dessa URL”
    OpenID Connect é, na prática, mais próximo de uma evolução do OAuth

    • Como anotação para meu eu futuro: OpenID Connect (OIDC) lida principalmente com autenticação, enquanto OAuth, mais precisamente OAuth v2.0, lida com autorização
      Vejo o OpenID Connect não tanto como uma evolução do OAuth, mas, em termos de visão e espírito, mais como uma evolução do OpenID. Assim como o OpenID, o OIDC foca em identificação e autenticação de usuários, mas, diferentemente do OpenID, não recriou um fluxo de autenticação totalmente novo; ele atingiu seu principal objetivo ao colocar um fluxo de autenticação sobre a especificação OAuth, que já vinha sendo usada indevidamente para autenticação
    • OAuth2 é flexível demais na forma como pode ser combinado, e o OIDC oferece muitas boas práticas sobre “como combinar” essas peças
      Por isso, mesmo sistemas cujo objetivo não é conformidade com OIDC muitas vezes seguem partes do OIDC. Se uma parte do padrão OIDC já oferece o que é necessário, não há motivo para reinventar a roda
    • A nomenclatura é um pesadelo total
      OpenID Connect é uma extensão que adiciona uma camada de autenticação ao OAuth2 (RFC 6749), e OAuth2 é um framework de autorização para conceder permissões
      Por outro lado, OAuth 1.0/1.0a e OpenID 1/2 são protocolos que só têm nomes parecidos, mas não têm relação entre si e não são compatíveis, então em 2024 são em grande parte irrelevantes. É preciso ter cuidado ao pesquisar
    • Entendo o OpenID Connect mais como uma especialização construída sobre OAuth2
    • Comecei a me interessar por OpenID graças a uma apresentação feita no Webstock em 2008

  • Isso não é uma coisa boa sob nenhum aspecto. Primeiro, padrões pagos, que exigem pagamento para serem lidos, são realmente ruins
    Em segundo lugar, eu gostaria que houvesse mais esforço em projetar padrões e implementações que, quando necessários, não se transformem em um poço sem fim de perda de tempo

    • Concordo sobre a ISO, mas, neste caso, é difícil dizer que exista uma barreira de pedágio significativa. O padrão em si já está publicado gratuitamente, e isto parece mais a atribuição de um identificador no namespace de padronização da ISO
      Dito isso, não sei bem qual é a vantagem de receber um número de padrão ISO em comparação com publicar um documento HTML na internet
    • No lado da internet, fico me perguntando por que algo assim não vira um RFC. E-mail e TCP são RFCs, assim como outros componentes essenciais, e empresas globais também os usam o tempo todo

  • Padrões são bons, mas é irritante que grandes organizações de padronização como a ISO cobrem dinheiro para você ver os padrões
    Imagino que seja porque algumas empresas ou setores exigem um padrão “de verdade” dessas organizações, em vez de algo criado pelo IETF ou por algum grupo hippie imundo de open source

    • O argumento deles é que isso serve para fornecer acessibilidade e financiamento a regiões menos desenvolvidas
    • “Padrão” e “custa dinheiro” parecem ideias conflitantes. Se você quer que um método se torne padrão, isto é, a forma mais comum, ele precisa ser acessível o suficiente para ser amplamente implementado
    • A maioria dos padrões é vendida por preços baixos, a ponto de dar prejuízo. Se, em vez disso, você quiser doar para a ISO ou a IEEE, isso ajudaria a reduzir os custos de elaboração de padrões
    • Em contextos governamentais ou nacionais, entendo que, como a ISO é reconhecida em vários tratados internacionais, muitas vezes é mais fácil obter aprovação para usar um padrão ISO do que um padrão da OpenID Foundation
      Por isso, se o OpenID Connect for publicado com um número ISO, a adoção ficará mais fácil em alguns projetos. Claro que o OpenID Connect em si continuará podendo ser lido e usado gratuitamente, mas as pessoas que estão nas situações acima passam a ter uma opção mais fácil

  • A ISO é um lixo não livre e não ajuda o ecossistema de software
    Basta olhar para a ISO 8601: ela é complexa demais, muitas vezes não é implementada corretamente porque os mantenedores usaram rascunhos gratuitos, e, na prática, nem resolve nada direito. Por exemplo, ela não consegue representar horário de relógio de parede, o que causa problemas com datas futuras em que o fuso horário pode mudar
    Já trabalhei com mp4 antes e descobri que havia mudanças na stack da Apple, então a ISO sozinha não era suficiente

    • Entendo essa reclamação específica, mas vejo o fato de não representar horário de relógio de parede mais como um recurso
      A crítica geralmente acaba em hipóteses como mudanças de horário de verão. É comum ouvir algo como: “quero especificar 14:00 no horário local de Absurdistan daqui a 4 anos, seja qual for sua relação com UTC, mas não consigo”. Mas, se levarmos a hipótese um pouco mais longe, Absurdistan pode anexar territórios ultramarinos, entrar em uma aliança ou alterar seus fusos horários e o horário de verão
      Pensando no problema, a própria definição de horário local pode mudar; portanto, a menos que você defina exaustivamente todas as mudanças possíveis, é impossível especificar um horário local futuro. No fim, é preciso fixar um número futuro de tiques de relógio atômico (TAI) e interpretá-lo como horário local no momento de uso, ou especificar um horário fixo e interpretá-lo como horário local no momento de uso
    • Fico curioso se existe alguma alternativa à ISO 8601. Minha única reclamação era que parece haver mais de uma forma de expressar algumas coisas, e eu não conhecia o problema do horário de relógio de parede
      Também me pergunto se a nova API JS Temporal lida com isso. Parece que ela foi bem fundo no assunto

  • Padrões pagos para leitura, como os da ISO, atrapalham ativamente o progresso da humanidade. Eu preferiria que esse tipo de prática não fosse incentivado

    • No caso do C++, os rascunhos mais recentes do padrão são disponibilizados gratuitamente https://en.cppreference.com/w/cpp/links#C.2B.2B_standard_doc...
      Entendo que o rascunho final e o padrão oficial são praticamente iguais em termos de conteúdo efetivo. Imagino que o rascunho do padrão OIDC também esteja publicado em algum lugar
    • Nem tudo precisa ser preto no branco. Dá para reconhecer que existem zonas cinzentas
      É estranho dizer que esses engenheiros estão criando progresso para a humanidade e, ao mesmo tempo, prejudicando ativamente o progresso da humanidade

  • Provisionamento de identidade é um monstro que nunca deveria ter sido inventado
    Em meados dos anos 2000, eu era fã a ponto de operar meu próprio servidor OpenID, mas não percebia o quanto todo esse conceito era fundamentalmente falho
    Identidade é um atributo inalienável inerente ao indivíduo, não algo que outro indivíduo, uma empresa/site, governo etc. possa “fornecer”. Eles só podem fornecer credenciais para comprová-la, como emitir um passaporte
    Pelo menos o WebAuthn acertou essa parte

    • Isso não parte da premissa de que a identidade fornecida é exatamente você e somente você? Eu sempre vi essas identidades como pseudônimos sobre algum provedor de identidade, e as usei assim
      Algumas identidades eu uso em lugares suficientes para que seja difícil negar, para certos atores, que elas são minhas, mas mesmo nesse caso os atores que viram essa identidade e conseguem provar que sou eu são apenas um pequeno subconjunto
    • Fico me perguntando se a distinção entre comprovação e provisionamento tem consequências práticas, ou se é uma distinção puramente filosófica

  • Ainda existem emissores OIDC independentes fora de Google, MS e Apple onde se possa criar uma conta?
    Um tempo atrás eu queria criar uma conta no Tailscale sem usar uma conta do GitHub, mas não consegui
    Acho que antigamente openid.net e Ubuntu One ofereciam esse tipo de serviço, mas pelo que sei foram descontinuados

    • Ainda restam alguns, e https://gitlab.com é um que uso com frequência
      Dito isso, os custos de segurança e suporte necessários para esse tipo de serviço são altos; especialmente oferecê-lo de graça não é muito viável para organizações pequenas. As economias de escala que tornam isso possível são grandes, e funcionam especialmente bem quando empresas grandes pagam por produtos corporativos

  • OpenID Connect é um protocolo bastante simples. Li a especificação (https://openid.net/specs/openid-connect-core-1_0.html) e consegui entender a maior parte em cerca de um dia
    Para quem não quer ler a especificação, também escrevi um tutorial abrangente sobre como implementar um cliente OpenID com requisições HTTP simples (https://spapas.github.io/2023/11/29/openid-connect-tutorial/)
    Os exemplos usam Python, mas não deve ser difícil implementar na linguagem que você quiser. A maior parte da complexidade está em decodificar e validar tokens JWT
    Estou usando esse cliente escrito à mão em um projeto de produção real há cerca de um ano para autenticação com Keycloak, e tudo está funcionando perfeitamente
    PS: sei que meu site tem anúncios demais. Infelizmente não tive tempo de configurar o Google Ads direito e também não encontrei uma alternativa melhor. Ao ler, é só usar um bloqueador de anúncios

    • O texto é muito interessante e bem escrito
      Mas é melhor tomar cuidado com expressões subjetivas como simples. Se o leitor achar difícil e o autor disser que é simples, isso pode ser bastante intimidador
    • Excelente tutorial
      Ainda assim, não estou convencido de que OIDC seja fácil. O Keycloak esconde uma complexidade enorme, e os desenvolvedores não fizeram isso por tédio. Por exemplo, há muitas configurações diferentes de timeout: timeout de SSO, timeout de cliente, timeouts de vários tokens etc.

  • A monetização e a operação das organizações em torno dos padrões ISO, no geral, parecem muito suspeitas
    Um truque menos conhecido: dá para procurar versões mais baratas dos padrões no simpático site estoniano https://evs.ee. Eles frequentemente criam versões próprias com conteúdo quase igual ao original. Infelizmente, neste caso, parece que oferecem apenas o padrão real por um preço parecido https://www.evs.ee/en/search?OnlySuggestedProducts=false&que...
    Vale a pena ficar de olho no site para ver se depois aparece uma versão própria com preço melhor. Normalmente o preço fica em torno de 10% do original. Mais um dado a favor da Estônia fazendo coisas legais
    Como trabalho com conformidade regulatória de dispositivos médicos, lido com organizações de padronização bastante suspeitas com frequência https://openregulatory.com/accessing-standards/
    Já ouvi todos os argumentos comuns, como “padronização custa dinheiro” e “essas organizações fazem um bom trabalho”, mas não concordo nem um pouco. Se algo é um padrão, acho que ele se torna parecido com uma lei. As pessoas precisam poder cumpri-lo e, para isso, precisam ter acesso livre a ele. O advogado-geral da UE parece concordar https://openregulatory.com/maybe-eu-standards-are-becoming-f...
    Há muitas padronizações que não precisam vender PDFs de forma suspeita. ECMAScript e ANSI C vêm à mente, e a lista continua

  • Transformar isso em uma publicação ISO vira um escudo para fugir de responsabilidade do ponto de vista dos departamentos de compras
    Afinal, ninguém nunca foi demitido por exigir conformidade com um pacote de padrões ISO