Les spécifications OpenID Connect publiées comme normes ISO

 (self-issued.info)
1 points par GN⁺ 2024-11-11 | 1 commentaires | Partager sur WhatsApp
  • Neuf spécifications OpenID Connect ont été publiées comme normes ISO/IEC, faisant entrer dans le cadre des normes internationales Core 1.0, Discovery, Dynamic Client Registration, les spécifications de déconnexion ainsi que les modes de réponse OAuth 2.0
  • L’OpenID Foundation les avait soumises à l’ISO en décembre 2023 via la procédure PAS (Publicly Available Specifications), puis leur publication a été finalisée après un vote d’approbation de l’ISO
  • La normalisation ISO pourrait faciliter le déploiement d’OpenID Connect dans les juridictions qui exigent les spécifications d’organismes de normalisation reconnus par des traités internationaux
  • Avant la soumission, l’OpenID Connect working group a mené une procédure d’application des errata corrections afin que les corrections connues soient intégrées aux versions ISO
  • Forte de cette expérience de la procédure PAS, l’OpenID Foundation prévoit de soumettre à la publication ISO FAPI 1.0, puis les familles de spécifications eKYC-IDA et FAPI 2.0 après leur finalisation

Spécifications publiées comme normes ISO/IEC

Soumission PAS et approbation ISO

  • La soumission des spécifications OpenID Connect pour l’OpenID Foundation a été effectuée en décembre 2023 sous la forme PAS (Publicly Available Specifications)
  • Après le vote d’approbation de l’ISO, ces spécifications ont été publiées comme normes ISO/IEC
  • L’ISO étant l’un des organismes de normalisation reconnus par des traités internationaux, cela pourrait accroître les possibilités d’adoption d’OpenID Connect dans les juridictions où l’usage de normes issues de tels organismes est légalement requis

Corrections intégrées aux versions ISO

  • Avant la soumission, l’OpenID Connect working group a mené une procédure d’application des errata corrections aux spécifications
  • Les versions ISO intègrent ainsi les corrections connues

Prochaines soumissions ISO prévues

  • Après avoir mené une première fois la procédure de soumission ISO PAS, l’OpenID Foundation prévoit de soumettre d’autres familles de spécifications finales à la publication ISO
  • Les prochaines cibles incluent la spécification FAPI 1.0
  • Les spécifications eKYC-IDA et FAPI 2.0 sont prévues pour soumission après leur finalisation

À lire aussi

1 commentaires

 
GN⁺ 2024-11-11
Commentaires sur Hacker News

  • Bien que j’aie été assez impliqué dans OpenID il y a environ 17 ans (https://simonwillison.net/search/?tag=openid&year=2007), il m’a fallu un temps embarrassant pour comprendre que OpenID Connect n’a presque rien à voir avec l’idée originelle d’OpenID selon laquelle « l’identifiant est une URL et l’on prouve la propriété de cette URL »
    OpenID Connect est en pratique bien plus proche d’une évolution d’OAuth

    • Pour m’en souvenir plus tard : OpenID Connect (OIDC) traite principalement de l’authentification, tandis qu’OAuth, ou plus précisément OAuth v2.0, traite de l’autorisation
      Je vois OIDC moins comme une évolution d’OAuth que, dans sa vision et son esprit, comme une évolution d’OpenID. Comme OpenID, OIDC se concentre sur l’identification et l’authentification de l’utilisateur, mais contrairement à OpenID, il n’a pas recréé de toutes pièces un nouveau flux d’authentification ; il a atteint son objectif principal en ajoutant un flux d’authentification au-dessus de la spécification OAuth, déjà détournée de son usage initial à des fins d’authentification
    • OAuth2 est bien trop flexible dans sa manière d’être assemblé, et OIDC fournit beaucoup de bonnes pratiques sur « comment assembler tout ça »
      C’est pourquoi même des systèmes dont l’objectif n’est pas la conformité OIDC suivent souvent OIDC en partie. Si une partie du standard OIDC fournit déjà ce dont on a besoin, il n’y a aucune raison de réinventer la roue
    • Le nommage est un cauchemar absolu
      OpenID Connect est une extension qui ajoute une couche d’authentification à OAuth2 (RFC 6749), et OAuth2 est un framework d’autorisation qui accorde des permissions
      En revanche, OAuth 1.0/1.0a et OpenID 1/2 ne sont que vaguement similaires par le nom ; ce sont des protocoles sans lien et incompatibles, donc en 2024 ils sont pour la plupart hors sujet. Il faut faire attention quand on cherche des informations
    • Je comprends OpenID Connect comme une spécialisation construite sur OAuth2
    • C’est une présentation que j’avais donnée à Webstock en 2008 qui m’a fait m’intéresser pour la première fois à OpenID

  • Ce n’est une bonne nouvelle sur aucun plan. D’abord, les standards payants qu’il faut acheter pour pouvoir lire sont vraiment une mauvaise chose
    Ensuite, j’aimerais qu’on fasse plus d’efforts pour concevoir des standards et des implémentations qui ne deviennent pas un gouffre de temps sans fin quand on en a besoin

    • D’accord au sujet de l’ISO, mais dans ce cas précis, je ne pense pas qu’il y ait une barrière de péage significative. Le standard lui-même est déjà publié gratuitement, et cette démarche ressemble surtout à l’attribution d’un identifiant dans l’espace de noms de standardisation de l’ISO
      En revanche, je ne vois pas très bien quel avantage il y a à obtenir un numéro de standard ISO plutôt que de publier un document HTML sur Internet
    • Dans l’univers Internet, je me demande pourquoi on n’en fait pas un RFC. L’email et TCP sont aussi des RFC, tout comme d’autres éléments fondamentaux, et les entreprises mondiales les utilisent en permanence

  • Les standards, c’est bien, mais c’est agaçant que de grandes organisations de normalisation comme l’ISO fassent payer l’accès aux standards
    J’imagine que dans certaines entreprises ou certains secteurs, on exige des « vrais » standards émanant de telles organisations plutôt que quelque chose produit par l’IETF ou par une bande de hippies de l’open source

    • Selon eux, c’est pour fournir de l’accessibilité et du financement aux régions moins développées
    • « Standard » et « payant » donnent l’impression de se contredire. Si l’on veut qu’une méthode devienne la norme, c’est-à-dire l’approche la plus courante, elle doit être suffisamment accessible pour être largement implémentée
    • La plupart des standards sont vendus à un prix si bas qu’ils le sont à perte. En revanche, si vous voulez faire un don à l’ISO ou à l’IEEE, cela aiderait à réduire le coût de rédaction des standards
    • Dans les contextes gouvernementaux ou étatiques, je comprends qu’il est souvent plus facile d’obtenir l’approbation pour utiliser un standard ISO qu’un standard de l’OpenID Foundation, parce que l’ISO est reconnue dans de nombreux traités internationaux
      Donc si OpenID Connect est publié avec un numéro ISO, son adoption deviendra plus facile dans certains projets. Bien sûr, OpenID Connect lui-même restera librement consultable et utilisable, mais cela offrira une option plus simple à ceux qui se trouvent dans ce genre de situation

  • L’ISO est une saloperie non libre et n’aide pas l’écosystème logiciel
    Regardez ISO 8601 : c’est excessivement complexe, il est souvent mal implémenté parce que les mainteneurs se sont appuyés sur des brouillons gratuits, et en pratique ça ne résout même pas correctement certains problèmes. Par exemple, il ne permet pas de représenter une heure murale, ce qui pose des problèmes pour les dates futures où le fuseau horaire peut changer
    J’ai aussi déjà travaillé avec le mp4, et j’ai découvert qu’il y avait des modifications propres à la stack Apple, donc l’ISO seule ne suffisait pas

    • Je comprends ce grief particulier, mais à mes yeux, le fait de ne pas représenter l’heure murale est plutôt une fonctionnalité
      La critique dérive généralement vers des hypothèses du type changement d’heure d’été. On entend souvent des remarques du genre : « je veux pouvoir désigner l’heure locale 14:00 en Absurdistan dans quatre ans, quelle que soit sa relation à l’UTC, mais je ne peux pas ». Mais si on pousse un peu plus loin ce genre d’hypothèse, l’Absurdistan pourrait aussi annexer des territoires d’outre-mer, rejoindre une alliance, ou modifier son fuseau horaire et son heure d’été
      Si l’on réfléchit au problème, la définition même de l’heure locale peut changer ; il est donc impossible de spécifier une heure locale future à moins de définir exhaustivement tous les changements possibles. Au final, il faut soit fixer un futur nombre de ticks d’horloge atomique (TAI) et l’interpréter en heure locale au moment de l’utilisation, soit fixer une heure absolue puis l’interpréter en heure locale à ce moment-là
    • Je me demande s’il existe une alternative à ISO 8601. Mon seul reproche était qu’il semblait y avoir plus d’une façon de représenter certaines choses, et je ne connaissais pas le problème de l’heure murale
      Je me demande aussi si la nouvelle API JS Temporal gère cela. Ça avait l’air d’aller assez loin

  • Les standards payants à la lecture comme ceux de l’ISO entravent activement le progrès de l’humanité. J’aimerais qu’on n’encourage pas ce genre de pratique

    • Dans le cas du C++, les brouillons des standards les plus récents sont publiés gratuitement https://en.cppreference.com/w/cpp/links#C.2B.2B_standard_doc...
      Si j’ai bien compris, le brouillon final et le standard officiel sont quasiment identiques sur le fond. Il doit probablement exister quelque part des brouillons du standard OIDC
    • Tout n’a pas besoin d’être noir ou blanc. On peut reconnaître qu’il existe des zones grises
      Dire que ces ingénieurs font progresser l’humanité tout en nuisant activement au progrès de l’humanité, c’est étrange

  • La provisionnement d’identité est un monstre qui n’aurait jamais dû être inventé
    Vers le milieu des années 2000, j’étais suffisamment fan pour faire tourner mon propre serveur OpenID, mais je n’avais pas réalisé à quel point tout ce concept est fondamentalement bancal
    L’identité est une propriété inhérente à une personne, inaliénable, et non quelque chose qu’une autre personne, une entreprise/un site web, un gouvernement, etc. peut « fournir ». Ils peuvent seulement fournir des justificatifs pour la prouver, comme lorsqu’on délivre un passeport
    Au moins, WebAuthn a correctement traité cet aspect

    • N’est-ce pas partir du principe que l’identité fournie est bien exactement vous, et vous seul ? Pour ma part, j’ai toujours considéré ces identités comme des pseudonymes chez un fournisseur d’identité, et je les ai utilisées ainsi
      Certaines identités sont utilisées à suffisamment d’endroits pour qu’il soit difficile, vis-à-vis de certains acteurs, de nier qu’elles sont à moi, mais même dans ce cas, seuls quelques-uns de ceux qui ont vu cette identité sont en mesure de prouver qu’il s’agit bien de moi
    • Je me demande si la distinction entre preuve et provisionnement a des conséquences pratiques, ou s’il s’agit d’une distinction purement philosophique

  • Existe-t-il encore des émetteurs OIDC indépendants en dehors de Google, MS et Apple, qui permettent de créer un compte ?
    Il n’y a pas longtemps, je voulais créer un compte Tailscale sans utiliser de compte GitHub, mais ce n’était pas possible
    Il me semble qu’autrefois openid.net et Ubuntu One proposaient ce type de service, mais à ma connaissance ils ont arrêté

    • Il en reste encore quelques-uns, et https://gitlab.com est celui que j’utilise souvent
      Cela dit, les coûts de sécurité et de support nécessaires pour ce genre de service sont élevés, et surtout lorsqu’il est proposé gratuitement, ce n’est guère réaliste pour de petites organisations. Les économies d’échelle qui rendent cela possible sont importantes, et cela fonctionne particulièrement bien quand de grandes entreprises paient pour des produits destinés au marché entreprise

  • OpenID Connect est un protocole assez simple. J’ai pu lire la spécification (https://openid.net/specs/openid-connect-core-1_0.html) et en comprendre l’essentiel en une journée environ
    Pour ceux qui ne veulent pas lire la spécification, j’ai aussi rédigé un tutoriel complet pour implémenter un client OpenID avec de simples requêtes HTTP (https://spapas.github.io/2023/11/29/openid-connect-tutorial/)
    Les exemples utilisent Python, mais cela ne devrait pas être difficile à implémenter dans le langage de votre choix. La majeure partie de la complexité consiste à décoder et vérifier les jetons JWT
    J’utilise ce client écrit à la main en production depuis environ un an pour l’authentification Keycloak, et tout fonctionne parfaitement
    P.-S. : je sais qu’il y a trop de publicités sur mon site. Malheureusement, je n’ai pas eu le temps de configurer correctement Google Ads et je n’ai pas trouvé de meilleure alternative. Vous pouvez utiliser un bloqueur de pub pour le lire

    • L’article est très intéressant et bien écrit
      Cela dit, il vaut mieux faire attention aux formulations subjectives comme simple. Si le lecteur trouve cela difficile alors que l’auteur dit que c’est simple, cela peut être assez décourageant
    • Excellent tutoriel
      Cela dit, je ne suis toujours pas convaincu que l’OIDC soit facile. Keycloak masque une énorme complexité, et les développeurs ne l’ont pas fait par ennui. Il y a par exemple énormément de paramètres de délai d’expiration différents : délai SSO, délai client, plusieurs délais pour les jetons, etc.

  • La monétisation et le fonctionnement organisationnel autour des normes ISO donnent globalement une impression très douteuse
    Petite astuce peu connue : on peut trouver des versions moins chères des normes sur le sympathique site estonien https://evs.ee. Ils créent souvent leurs propres versions, dont le contenu est quasiment identique à l’original. Malheureusement, dans ce cas précis, ils semblent seulement proposer la véritable norme à un prix similaire https://www.evs.ee/en/search?OnlySuggestedProducts=false&que...
    Cela vaut la peine de garder un œil sur le site pour voir si une meilleure version maison apparaît plus tard. En général, le prix tourne autour de 10 % de celui de l’original. C’est un point de donnée supplémentaire montrant que l’Estonie fait des choses formidables
    Comme je travaille sur la conformité réglementaire des dispositifs médicaux, je traite souvent avec des organismes de normalisation assez louches https://openregulatory.com/accessing-standards/
    J’ai entendu tous les arguments habituels du genre « la normalisation coûte de l’argent » ou « ces organismes font du bon travail », mais je ne suis absolument pas d’accord. Si quelque chose est une norme, cela devient proche de la loi à mes yeux. Les gens doivent pouvoir s’y conformer, et pour cela il faut qu’elle soit librement accessible. L’avocat général de l’UE semble être du même avis https://openregulatory.com/maybe-eu-standards-are-becoming-f...
    Il existe de nombreuses normalisations qui n’ont pas besoin de vendre des PDF à prix douteux. ECMAScript et ANSI C me viennent à l’esprit, et la liste continue

  • En faire une publication ISO devient, du point de vue des services achats, un bouclier de défausse de responsabilité
    Après tout, personne ne s’est jamais fait licencier pour avoir exigé la conformité à tout un lot de normes ISO