IETF 123 : Résumé de la session 2 du groupe de travail OAuth (25e heure du Japon)

Cela fait un moment, et ma mémoire est un peu floue... Ci-dessous, je l'ai compilé dans NotebookLM, donc je vais essayer de m'en souvenir en le réécrivant... (Je déteste à quel point je deviens oublieux en vieillissant...)

概要

La deuxième session du groupe de travail OAuth s'est tenue à l'IETF 7 de Madrid le 25 juillet, heure du Japon. L'ordre du jour, annoncé à l'avance, est le suivant :

• Mise à jour des chaises – Rifaat/Hannes (5 min)
• Liste des statuts des jetons – Tobias/Paul/Christian (10 min)https://datatracker.ietf.org/doc/draft-ietf-oauth-status-list/
• Authentification client basée sur l'attestation – Tobias/Paul/Christian (20 min)https://datatracker.ietf.org/doc/draft-ietf-oauth-attestation-based-client-auth/
• Jetons de transaction – Pieter (10 min)https://datatracker.ietf.org/doc/draft-ietf-oauth-transaction-tokens/
• Jeton d'actualisation OAuth 2.0 et expiration du consentement – Nick Watson (15 min)https://datatracker.ietf.org/doc/draft-watson-oauth-refresh-token-expiration/
• Flux sans navigateur App2App – Yaron Zehavi (10 min)https://datatracker.ietf.org/doc/draft-zehavi-oauth-app2app-browserless/
• Revendications d'extension client OAuth 2.0 – Jeff Lombardo (10 min)https://github.com/identitymonk/draft-lombardo-oauth-client-extension-claims
• Protocole de défi d'autorisation OAuth 2.0 Step-Up – Jeff Lombardo (10 min)https://github.com/identitymonk/draft-lombardo-oauth-step-up-authz-challenge-proto
• Enregistrement client poussé – Justin (10 min)https://www.ietf.org/archive/id/draft-richer-oauth-pushed-client-registration-00.html
• Raccourci clavier différé – Justin/Brian (10 min)https://datatracker.ietf.org/doc/draft-richer-oauth-tmb-claim/

Nous avons résumé ci-dessous les principaux thèmes, idées et faits importants. (Merci NotebookLM !)

1. Liste des statuts des jetons

• Mécanisme de révocation évolutifLa liste d'état des jetons est conçue comme un mécanisme de révocation évolutif, mettant l'accent sur les propriétés de confidentialité, la facilité de compréhension et la facilité de mise en œuvre, tout en étant compatible avec les formats d'informations d'identification basés sur JOSE et COSE.
• Références et tests approfondis: Il est actuellement référencé dans les normes ISO mDL et mDOC, et figure parmi les mécanismes de statut de l'ARF européen. Il a été testé lors de nombreux événements tests et hackathons avec de bons résultats.
• Établissement d'un point d'extension et d'un registre:Ce projet va au-delà d’un mécanisme unique et établit un point d’extension et un registre pour les mécanismes de statut en général.
• Changements majeurs:
  • Depuis la dernière réunion de l'IETF, trois révisions ont été apportées, principalement des modifications éditoriales.
  • Un changement majeur est que l'en-tête de requête Accept lors de la demande d'un jeton de liste d'état auprès d'un client a été assoupli de « must » à « should ».
  • Les champs OID d'utilisation de clé définis sont désormais disponibles pour être utilisés par d'autres mécanismes du registre IANA créés par ce projet.
• Status QuoTous les problèmes ouverts et les demandes d'extraction ont été intégrés, en attente d'un examen par le berger et d'une recherche de conseils sur la manière d'accélérer ce processus.

2. Authentification client certifiée par le backend

• But:En raison des limitations de l’authentification client confidentielle traditionnelle, nous établissons un mécanisme qui permet aux instances frontales d’obtenir une attestation et de l’utiliser directement comme authentification client auprès du serveur d’authentification.
• Aperçu du fluxUne instance client génère une clé d'attestation et exécute un protocole (hors du cadre du projet) avec le backend pour obtenir une attestation sous la forme d'un JWT. Cette attestation client et sa preuve sont utilisées conjointement pour l'authentification auprès du serveur d'authentification.
• Changements depuis l'IETF 122:
  • Clarifications sur la gestion de l'identité du client, l'utilisation de l'attestation du client et le langage général.
  • Valeurs de réponse d'erreur OAuth ajoutées.
  • Le changement le plus important est que nous avons déprécié le mécanisme HTTP OPTIONS pour obtenir le défi en faveur d'un point de terminaison de défi dédié qui utilise le verbe HTTP POST, ce qui résout le problème des multiples requêtes de pré-vol dans les environnements de navigateur.
  • Considérations de sécurité et de mise en œuvre mises à jour (par exemple, protection contre la relecture, utilisation de JTI).
• Discussion sur l'optimisation avec DPoP:
  • Si ce mécanisme d'authentification client est utilisé en combinaison avec DPoP (Demonstration of Proof-of-Possession), le serveur d'authentification doit valider trois JWT : l'attestation client, l'attestation client PoP et l'attestation DPoP.
  • Une optimisation possible a été discutée : si les clés d'attestation du client PoP et DPoP sont identiques, utiliser l'attestation DPoP au lieu de l'attestation du client PoP, ce qui réduirait les en-têtes de requête et améliorerait l'efficacité.
  • En ce qui concerne les problèmes de sécurité, certains ont exprimé l’avis qu’il n’y avait aucun problème à réutiliser la même clé pour envoyer des messages signés à la même entité.
  • Cette optimisation n’est pas obligatoire et les clients doivent être prêts à travailler avec ou sans DPoP.
• Principaux problèmes non résolus:
  • Le point final du défi est considéré comme résolu et des commentaires sont sollicités sur l'adoption des optimisations DPoP. Le projet ne mentionne pas l'utilisation des en-têtes d'attestation sur les serveurs de ressources ; des commentaires sont donc sollicités pour savoir s'il convient de développer ces détails ou de les supprimer complètement.

3. Jetons de transaction

• But:Un mécanisme qui maintient les jetons d'accès et permet l'échange de jetons dans une limite de confiance donnée tout en préservant le contexte (sujet, contexte, détails d'autorisation), réduisant le risque de fuite de jetons d'accès et permettant le déploiement d'une autorisation plus précise.
• Changements depuis l'IETF 122:
  • Cohérence de la portée:La formulation a été resserrée pour garantir que les jetons de transaction n'ont pas une portée plus large que le jeton d'accès d'origine.
  • Distinguer l'authentification de l'autorisation: Il a été précisé que les jetons de transaction sont une construction d'autorisation et non une construction d'authentification.
• Problèmes de formatage d'en-tête HTTP:
  • Les commentaires des examinateurs de l’IANA ont conclu qu’aucun des types d’en-têtes structurés HTTP existants n’était adapté à cette fin.
  • Par conséquent, il a été décidé de le conserver comme un en-tête non structuré, ce qui élimine le risque de problèmes futurs.
  • La discussion a également suggéré qu'une demande de nouveaux en-têtes structurés pourrait être soumise au groupe de travail HTTP à l'avenir, mais cela n'empêcherait pas la spécification d'avancer.
• Status Quo:Les développeurs ne sont conscients d'aucun problème majeur en suspens et le problème de format d'en-tête HTTP est également considéré comme résolu.Prêt à passer au WGLC.

4. Authentification du client Spiffe

• 背景Spiffe (Secure Production Identity Framework For Everyone) est un framework permettant d'établir et de vérifier l'identité des charges de travail dans les environnements cloud natifs. Actuellement, les charges de travail utilisent le SVID (SPIFFE Verifiable Identity Document, certificat X.509 ou JWT (voir la note à la fin de cet article)) de Spiffe pour communiquer avec d'autres charges de travail, mais nécessitent des identifiants client et des secrets client à longue durée de vie provisionnés manuellement pour s'authentifier auprès des serveurs d'authentification.
• Objet de la proposition:Permet d'utiliser les SVID comme moyen d'authentification auprès des serveurs d'autorisation, avec des capacités d'attestation de certificat et de clé de courte durée qui sont automatiquement provisionnées et renouvelées par Spiffe, exploitant l'infrastructure existante et réduisant le nombre de secrets à protéger.
• Détails de la proposition:
  • Nous profilons la partie authentification client de la RFC 7523 pour JWT SVID et la partie authentification client MTLS de la RFC 509 pour X.8705 SVID.
  • Le serveur d'autorisation vérifie le SVID en récupérant la clé à partir du point de terminaison du bundle Spiffe (similaire à JWKS), une spécification Spiffe.
• Principaux points de discussion:
  • Exigences relatives aux réclamations ISS: Le JWT SVID de Spiffe aissRFC 7523issLes exigences en matière de réclamations pourraient-elles être assouplies ou les utilisateurs de Spiffe pourraient-ilsissUne discussion a eu lieu sur la question de savoir si la validation des revendications devrait être exigée, ce qui a également soulevé la possibilité de recommander un mécanisme de distribution de clés basé sur OpenID Connect Discovery.
  • Traiter le public:Il a été confirmé que Spiffe peut obtenir un JWT avec un public spécifique, et sur la base des RFC 7523 et RFC 25 BIS, le public devrait être le serveur d'authentification.
  • Brouillon unique vs. Brouillon divisé:Il a été mentionné qu'il y avait matière à discussion quant à savoir si les SVID JWT et X.509 devraient être traités dans un seul projet ou s'ils devraient être divisés en projets distincts en fonction de leurs caractéristiques respectives.
  • Status Quo:Il s'agit d'un nouveau document et votre avis et vos commentaires sont demandés.

5. Expiration du jeton d'actualisation et expiration du consentement

• But:Nous introduisons un mécanisme pour deux concepts différents mais liés : l'expiration du jeton d'actualisation et l'expiration du consentement de l'utilisateur, ce qui permet une notification proactive aux utilisateurs et une rotation proactive des jetons par les clients.
• Cas d'utilisation:
  • Expiration du consentement:Les clients de Google ont demandé que nous informions les utilisateurs à l'avance avant l'expiration de leur consentement afin d'éviter les interruptions de service.
  • Rafraîchir la rotation des jetonsSi votre client utilise les jetons rarement (par exemple, uniquement lorsqu'un utilisateur visite votre site), vous devrez peut-être savoir si une rotation agressive est nécessaire.
• Détails de la proposition: Ajoutez deux nouveaux paramètres refresh_token_expires_in et consent_expires_in à la réponse du point de terminaison du jeton, qui peuvent avoir des valeurs différentes.
• Principaux points de discussion:
  • Paramètres de demande de jeton à durée limitée:Avez-vous besoin de définir des paramètres pour que les clients demandent des jetons à durée limitée (par exemple, dans la demande de flux d'autorisation ou la demande de point de terminaison de jeton) ?
  • expire dans vs expire àLa norme RFC 6749 actuelle utilise expires_in (heure relative) pour les jetons d'accès, mais la commodité d'expires_at (heure absolue) (les clients n'ont pas besoin de vérifier l'heure système et la mise en cache locale est possible) a été évoquée. Si expires_at est adopté, l'ajout d'expires_at aux jetons d'accès sera étudié pour des raisons de cohérence.
  • Terminologie du consentementLe terme « consentement » n'étant pas explicitement défini dans la spécification OAuth de base, l'opportunité d'introduire ce concept dans les noms de paramètres a été discutée. Des termes tels que « octroi » ont été suggérés comme alternatives.
  • Notes de mise en œuvre: Devrions-nous ajouter une note d’implémentation non normative sur la manière dont les serveurs d’autorisation doivent gérer l’expiration du consentement ?
• Status QuoUn projet existe et est en cours de consultation. Des inquiétudes ont notamment été soulevées concernant la terminologie du consentement, l'utilisation de expires_at et sa connexion à l'API de gestion des subventions.

6. Fédération d'application à application sans navigateur

• 背景Les modèles proposés dans la norme OAuth RC8252 (application vers web) et dans le blog « application vers application » de Joseph Heenan (directeur technique d'Authlete) fonctionnent bien lorsque l'application cliente et l'application serveur d'autorisation appartiennent au même domaine de confiance. Cependant, dans les scénarios fédérés impliquant plusieurs domaines de confiance (par exemple, établissements universitaires ou multinationales), le navigateur est requis pour les redirections intermédiaires, ce qui entraîne une mauvaise expérience utilisateur et des problèmes potentiels (problèmes de cookies, invites de liens profonds, etc.).
• Problème:
  • Les redirections via le navigateur créent une mauvaise expérience utilisateur (retards, bégaiement, onglets encombrés).
  • Si un navigateur différent (tel qu'une vue Web) est utilisé, le flux peut être interrompu en raison d'incohérences de cookies, etc.
• Objet de la proposition:L'application agit comme son propre agent utilisateur et gère les redirections directement, en contournant le navigateur, permettant la fédération sur plusieurs domaines de confiance.
• Détails de la proposition:
  • L'application cliente agit comme son propre agent utilisateur et suit les redirections en tant que client HTTP.
  • Il trouve chaque URL, vérifie s'il existe une application sur l'appareil qui lui correspond et, si tel est le cas, appelle directement cette application.
  • Une fois que l'application d'authentification a authentifié l'utilisateur et autorisé l'opération, elle partage une URL de lien profond entre les deux applications et l'application d'authentification, contrairement aux meilleures pratiques, fait confiance à cette URL de rappel native et renvoie un rappel avec une URL de redirection.
  • La confiance peut être établie à l'aide d'OpenID Federation, de l'enregistrement automatique des clients (←quelqu'un a suggéré que cela devrait être renommé car il est différent de l'enregistrement automatique d'OpenID Federation) ou d'une confiance préenregistrée dans un écosystème fermé.
• Principaux points de discussion:
  • Comportement du serveur d'authentification:La faisabilité d'un scénario dans lequel le serveur d'authentification renvoie 30 redirections successives sans interaction de l'utilisateur.
  • Considérations de sécurité: Les inquiétudes concernant la diminution de la sensibilisation des utilisateurs à la sécurité (origine de l'authentification) due à l'absence de navigateur sont importantes. La proposition se concentre sur les chaînes de redirection qui n'entraînent aucune interaction avec l'utilisateur.
  • Options de secoursFournissez toujours une option de secours du navigateur au cas où le mode sans navigateur n'est pas possible.
• Status Quo: Cette fonctionnalité a été annoncée à l'OSW et des cas d'utilisation sont en cours. Nous prévoyons de collaborer avec l'Université de Stuttgart pour une analyse de sécurité et sollicitons vos commentaires et votre soutien. Une option de métadonnées (Déclaration du point de terminaison d'authentification natif) a également été proposée pour que les serveurs d'authentification déclarent prendre en charge ce profil.

7. Réclamations relatives aux extensions de client

• 背景En incluant des informations sur l'utilisation des mécanismes de sécurité OAuth (par exemple, MTLS, DEOP, JWT de clé privée) dans la charge utile du jeton d'accès, les serveurs de ressources peuvent les utiliser pour prendre des décisions stratégiques. Actuellement, ces informations sont dispersées à différents emplacements, tels que les en-têtes HTTP (par exemple, DPoP), les types de jetons (jeton d'identification et jeton d'accès), les types de flux d'autorisation (par exemple, code d'appareil, informations d'identification client) et les méthodes d'authentification client, ce qui nécessite un traitement complexe.
• Problème:
  • Il est compliqué de déterminer le type de jeton (jeton d'identification ou jeton d'accès).
  • Il n'y a pas suffisamment d'informations sur le flux d'octroi d'autorisation utilisé.
  • Manque d'informations sur les liaisons de clés (PKCE, RAR, JAR).
  • Manque d'informations sur les méthodes d'authentification des clients (clé privée JWT, MTLS).
  • Le problème survient lorsque ces informations sont dispersées dans les en-têtes HTTP et que les points de décision de politique backend n'ont accès qu'à la charge utile.
• Détails de la proposition:Introduit quatre nouvelles revendications dans la charge utile du jeton d'accès.
  • gty (type de subvention):Une chaîne unique décrivant le type de flux de subvention utilisé.
  • cxt (type d'extension client):Un tableau de chaînes décrivant la combinaison des méthodes d'extension d'authentification client utilisées, telles que Pixie, DPoP ou JAR.
  • ccr (référence d'identification du client): Correspond à la revendication ACR d'un utilisateur et fournit un espace de noms pour transmettre la confiance entre les AS et les ARS.
  • cmr (référence de méthode client):Nous prévoyons de décrire les méthodes d’authentification des clients (par exemple, MTLS) et d’enregistrer les valeurs dans le registre IANA.
• ??:
  • Comme il n’introduit aucun nouveau paramètre de requête, les serveurs d’autorisation peuvent renvoyer ces revendications sans modifier leurs API existantes.
  • Vous pouvez déclarer la prise en charge de ces fonctionnalités en introduisant une runtime_type_extension dans les métadonnées de votre serveur d'autorisation.
• Principaux points de discussion:
  • Similitudes avec les vecteurs de confiance:La relation avec les vecteurs de confiance (RFC 8584), un mécanisme existant pour représenter divers éléments d'une décision de confiance.
  • Normalisation des valeurs gtyIl existe des fournisseurs, tels qu'Okta et Auth0, qui utilisent déjà des revendications telles que gty, mais les valeurs peuvent varier, une normalisation est donc nécessaire.
• Appel à réviseurs:Une révision de la documentation et des commentaires sont demandés.

8. Authentification renforcée au niveau de la couche d'autorisation

• 背景La RFC 9470 (Step-Up Authentication) a fourni un mécanisme permettant aux fournisseurs de ressources de demander une authentification plus forte aux clients en renvoyant des informations supplémentaires (par exemple, un ACR différent) via l'en-tête WWW-Authenticate, mais cela était axé sur la couche d'authentification et manquait de la capacité d'envoyer un signal similaire à la couche d'autorisation (décisions de contrôle d'accès).
• Problème:
  • Les fournisseurs de ressources ne disposent pas d’un moyen leur permettant de communiquer aux clients des informations plus détaillées (par exemple, des exigences ou des conditions spécifiques) expliquant pourquoi ils ne peuvent pas procéder.
  • Des frameworks comme FAPI 2.0 et Smart on FHIR prennent en charge les exigences d'authentification des clients et les demandes d'autorisation enrichies (RAR), mais ils nécessitent la capacité des serveurs de ressources à envoyer des signaux plus détaillés pour guider les clients à travers les étapes suivantes.
  • Avec l'avènement du Shared Signal Framework (SSF), les décisions des fournisseurs de ressources peuvent changer de manière dynamique, ce qui rend nécessaire de tenir les clients informés.
• Détails de la proposition:
  • Pour activer la signalisation au niveau de la couche d'autorisation, certainsCode d'erreurEtDéfiPrésenter.
• Défis spécifiques:
  • La capacité d'un serveur de ressources à demander à un client de faire référence à ses propres métadonnées de ressources protégées OAuth 2.0.
  • La capacité de guider les clients sur la marche à suivre sous la forme d'une demande d'autorisation enrichie (RAR).
• Enveloppe de réponseEn ce qui concerne l'autorisation, nous utilisons le format RAR authorization_details comme enveloppe de réponse, ce qui nous permet de communiquer des informations au client, telles que des exigences spécifiques en matière de paiement, dans un format conforme à la spécification RAR existante.
• Avantages:
  • Le client reçoit des instructions supplémentaires du serveur de ressources pour construire la demande d'autorisation appropriée et obtenir un nouveau jeton d'accès.
  • Il renforce l’alignement avec les spécifications existantes telles que FAPI 2.0, Smart on FHIR et MCP.
• Principaux points de discussion:
  • Code d'état HTTP 401 vs 403Bien que la RFC 9470 utilise l'erreur 401, cette proposition suggère d'utiliser l'erreur 403 pour les problèmes liés aux autorisations. Cependant, l'utilisation de l'erreur 2.0 est formalisée dans le framework OAuth et FAPI 401, et certains serveurs peuvent considérer l'erreur 403 comme un état final. Nous sollicitons donc vos commentaires sur ce point.
  • Charge utile et en-têtesIl y a eu une discussion sur la question de savoir s'il fallait inclure les informations dans la charge utile ou dans l'en-tête (par exemple, en incluant le JWT dans l'en-tête).
  • Cohérence avec GNAP:La cohérence avec le GNAP (General Authorization and Negotiation Protocol) est également une considération.
• Status Quo:Cette solution a été simplifiée par rapport à la précédente, complexe, présentée à l'OSW. Nous attendons vos commentaires et avis.

9. Enregistrement client poussé

• 背景OAuth repose sur les identifiants clients, mais le concept traditionnel d'identifiants clients persistants ne s'applique pas nécessairement aux clients éphémères comme les applications SPA ou les instances d'applications natives. Les solutions précédentes (enregistrement dynamique, fédération OpenID, etc.) ont rencontré des difficultés, notamment la gestion du cycle de vie des identifiants clients après l'enregistrement (par exemple, l'accumulation d'un grand nombre d'identifiants clients inutilisés).
• Problème:
  • Gestion appropriée et cycle de vie des identifiants clients pour les clients éphémères.
  • La nécessité de nettoyer les identifiants clients excédentaires après l'enregistrement dynamique.
  • Besoins d'hébergement des métadonnées des clients.
• Détails de la proposition:Basé sur PAR (Pushed Authorization Requests), il propose un moyen de s'authentifier dynamiquement sans utiliser explicitement un identifiant client.
  • Demande PARLe client effectue une demande PAR et utilise un mot-clé spécial comme « dynamic » dans le paramètre client_id, et envoie également un document de métadonnées client.
  • Réponse PAR: Le serveur d'authentification ne renvoie pas d'ID client, juste le request_uri normal.
  • Point de terminaison d'autorisationLe client accède au point de terminaison d'autorisation à l'aide de request_uri, en utilisant à nouveau le mot-clé « dynamic » comme client_id.
  • Point de terminaison du jetonAprès avoir obtenu le code d'autorisation, le client fait une demande au point de terminaison du jeton, en utilisant à nouveau le mot-clé « dynamic » comme client_id et en fournissant la preuve de la clé introduite dans la demande d'autorisation poussée d'origine.
• Avantages:
  • Il élimine l’aller-retour supplémentaire de l’enregistrement dynamique et la nécessité de supprimer les identifiants clients persistants.
  • Vous pouvez envoyer des informations spécifiques à l'instance sans avoir à héberger les métadonnées du client.
  • Vous pouvez transmettre des informations qui peuvent être liées à l'infrastructure de confiance de votre client, telles que les attestations client et les déclarations logicielles.
• Principaux points de discussion:
  • La nécessité de résoudre le problème:Est-ce un problème qui doit être résolu par la communauté dans son ensemble ?
  • Coexistence d'approches multiples:Concernant la situation actuelle où plusieurs solutions différentes au problème d'identification du client ont été proposées, la possibilité de coexistence et la nécessité d'une approche unifiée.
  • Garde-fous de couverture:La nécessité de définir des garde-fous stricts pour les cas d’utilisation où cette approche a du sens.
• Status QuoL'implémentation du prototype est fonctionnelle et n'a révélé aucun problème de sécurité majeur. Il est demandé de discuter de l'opportunité de soumettre cette proposition au groupe de travail en vue de sa normalisation.

10. Raccourci clavier différé

• 背景Les mécanismes PoP OAuth existants (DPoP et MTLS) exigent la présentation d'une preuve de possession d'une clé avant l'émission d'un jeton, empêchant ainsi les attaques par usurpation d'identité du serveur d'authentification. Cependant, dans certains cas concrets, la présentation d'une preuve de possession d'une clé est requise après l'émission d'un jeton.
• Problème:
  • Si des clés de différents domaines doivent être liées, la ressource cible peut valider le présentateur, mais l'entité requérante ne peut pas effectuer la demande de la même manière.
  • Scénarios dans lesquels une clé est conservée sur l'appareil et un jeton est lié à cette clé, comme les clés émises par le matériel sur les appareils IoT, mais la preuve de possession de la clé ne peut pas être fournie au moment de l'émission.
  • Un scénario dans lequel l'agent Spiffe émet des jetons au nom d'une charge de travail et les remet à la charge de travail, mais l'agent Spiffe ne possède pas la clé privée de la charge de travail.
• Contenu de la proposition et options d'orientation:Un groupe de travail a été chargé de discuter de la manière de résoudre ce problème.
  • Option 0 : Ignorer:Déclarez ce comportement comme une « mauvaise pratique » et découragez-le, mais en réalité, il existe des cas où cela a déjà été fait, il ne peut donc pas être arrêté.
  • Option 1 : Documenter un modèle existantDocumentez les modèles et les cas d’utilisation existants, mettez en place des garde-fous autour des mauvaises pratiques flagrantes et assurez-vous qu’ils ne sont appliqués que lorsque cela a du sens.
  • Option 2 : Créer une spécification de protocoleCréez une extension de protocole qui formalise la manière dont les clés de vérification non détenues peuvent être présentées dans le cadre d'une demande de jeton, en s'intégrant potentiellement aux mécanismes existants basés sur la signature tels que MTLS, DEOP ou HTTP SIG.
  • Option 3 : Ajouter une spécification de données de jeton: Ajoutez un moyen de jetonner les spécifications de données telles que JWT et l'introspection pour indiquer qu'un jeton est une clé liée mais n'a pas été présenté au moment de l'émission.
• 引用L'idée de base revient à permettre au client de dire : « J'ai mon identité et je peux la prouver, mais je veux que le jeton que vous me donnez soit associé aux clés de quelqu'un d'autre. » Je veux donc que vous me rendiez le jeton associé aux clés de quelqu'un d'autre. Et croyez-moi, j'ai le droit de le faire.
• Principaux points de discussion:
  • Urgence du problème:L'opinion est que ce problème a été observé ailleurs et que s'il n'est pas résolu, personne ne sera aidé.
  • Risques de sécurité et utilisations abusives potentielles:On craint que ce mécanisme puisse être utilisé à mauvais escient et qu’il soit dangereux.
  • Relation aux politiques et au comportement dynamique:Il n’est pas clair si ce problème peut être entièrement résolu sans politiques ni comportement dynamique.
  • Similitudes avec SAML subject_confirmation_data: Conceptuellement similaire à la revendication SAML subject_confirmation_data (cnf).
  • Heures de travail communautaires:On craint que la construction des options 2 ou 3 nécessite beaucoup d’efforts.
  • L'avis de Brian:A exprimé une préférence pour l'option 0 (ne rien faire) en raison de la « paresse » et de la « crainte d'être épuisé par le travail ».
• Status QuoCe projet vise à soulever des questions et non à être adopté. Il est proposé que le groupe de travail parvienne à un consensus sur la marche à suivre, par le biais de discussions sur la liste de diffusion.

Enregistrement de la session du groupe de travail OAuth

(J'apparais aussi brièvement à la fin mdr)

Regardez cette vidéo sur YouTube.
La lecture de la vidéo vous connectera à YouTube.

(Remarque sur SVID)

SVID (SPIFFE Verifiable Identity Document) est un document défini par SPIFFE.Certificats numériques permettant aux charges de travail (telles que les applications et les services) de prouver leur « identité »Le SVID agit comme un « passeport » dans le monde réel.

主 な 特 徴 ：

• Inclut l'identifiant SPIFFE:Contient un identifiant unique spécifique à la charge de travail (un URI commençant par spiffe://).
• Signature numérique:Il est signé par une autorité de certification (CA) au sein d'un domaine de confiance, afin qu'un tiers puisse vérifier son authenticité.
• 形式:Normalisation au format de certificat X.509 (X.509 SVID) ou au format JWT (JWT SVID).
• Validité à court terme et renouvellement automatique:Pour des raisons de sécurité, la durée de validité est courte et elle est automatiquement renouvelée.
• utilisation:Authentifiez et autorisez en toute sécurité les communications entre les charges de travail, telles que les communications mTLS (TLS mutuel) entre les services et l'authentification API, sans dépendre des informations réseau telles que les adresses IP.1345.

Pour vous donner une idée, le SVID contient les informations suivantes :

• Un seul identifiant SPIFFE
• Si nécessaire, la clé publique
• Signature numérique

Un service (charge de travail) obtient son propre SVID via l'API de charge de travail SPIFFE et le présente à l'autre partie.Environnement Zero TrustIl joue un rôle central pour en faire une réalité.