Résumé

  • Un projet individuel IETF propose que l’utilisateur choisisse lui-même les droits, la durée et éventuellement le plafond d’appels d’un agent, puis lui transmette un titre de connexion à usage unique.
  • La phrase dans laquelle il expose son objectif sert de preuve. Ce sont les droits sélectionnés, vérifiés à chaque appel, qui autorisent l’action.

La belle phrase à côté du bouton dangereux

Une personne souhaite que son assistant envoie une facture précise. Elle l’écrit dans la zone prévue. Plus bas, elle coche un droit qui permet de modifier toutes les factures. Le texte semble rassurant; la case est décisive. Le projet révisé de Christopher Emerson a le mérite de dire franchement ce que beaucoup d’interfaces de consentement laissent dans le flou: la machine applique le droit structuré, tandis que la phrase explique après coup ce que la personne voulait faire.

L’annonce du 27 octobre présente la version 01. Le registre IETF la classe comme Internet-Draft individuel actif, sans filière RFC ni approbation de l’IETF. Le document décrit un dispositif proposé. Son point de départ est une opération très concrète: l’utilisateur se connecte au service qui détient ses données, ouvre la gestion des connexions et détermine les droits qu’il remettra à l’agent. Le service calcule d’abord le plafond correspondant aux propres droits de cette personne; elle choisit ensuite le périmètre, la durée et, si elle le veut, un nombre maximal d’appels par période.

Elle voit aussi ses connexions existantes et peut en révoquer une avant d’en créer une autre. Une vérification facultative par authentificateur peut lier sa présence aux paramètres exacts: droits, échéance, plafonds et textes affichés. Le service lui montre une fois un titre temporaire à usage unique. Elle le transmet personnellement à l’agent. Celui-ci l’échange contre un jeton d’accès limité, sans renouvellement automatique. Ce passage par la personne coupe le trajet de livraison que l’agent ou sa plateforme aurait autrement pu piloter.

Le commentaire est archivé; le plafond travaille

La version 01 ajoute une section consacrée à deux textes: le but déclaré par l’application et l’intention que l’utilisateur formule librement. Ils accompagnent le consentement, les traces de contrôle des appels, les événements de révocation et l’audit. Ils ne sont pas traduits en permissions par un moteur. Les permissions restent les droits, la durée et les plafonds sélectionnés. Le document demande même que la prose ne puisse pas élargir un droit et réserve son interprétation automatique à une alerte soumise à une personne. Une formule étroite ne réduit donc pas non plus une case large.

Le formulaire doit montrer ce décalage avant que le jeton ne parte.

Le contrôle continue après la remise. Chaque appel d’API est soumis à une introspection qui vérifie les limites et consigne l’accès. Pour une opération désignée « confirmer à chaque fois », ce contrôle suspend l’appel et prépare une demande liée par empreinte à la requête exacte. L’utilisateur confirme dans son propre contexte avec un authentificateur; l’agent reprend l’appel avec l’identifiant de cette confirmation. Un refus clôt cette demande. Une révocation rend inutilisable toute confirmation restée en attente. Ce mécanisme peut protéger un envoi d’argent ou une suppression même si un droit général avait déjà été accordé.

La version 00 comportait déjà la remise humaine du titre. La version 01 précise les plafonds, l’examen des connexions existantes, la vérification de présence, la confirmation liée à une requête et la fermeture après révocation. Elle refuse surtout de faire de l’intention libre une permission cachée. C’est une bonne discipline, qui rend la conception des cases beaucoup plus exigeante: si le service n’offre qu’un « accès complet », le beau champ de texte ne sauvera personne de ce choix.

Le document décrit un service exploité par son auteur, sans fournir d’essai de conformité indépendant. Il identifie lui-même le point fragile de la confirmation: si l’agent contrôle l’écran sur lequel l’utilisateur voit l’opération, une authentification réussie ne démontre pas ce qui lui a réellement été présenté. Le lieu où l’utilisateur prend sa décision importe autant que la signature qui l’enregistre.

Documents originaux