Zusammenfassung

  • Das vorgeschlagene Agent Authorization Center verwaltet die Zuordnung von Nutzern zu Agenten und eine Liste für selbstständigen Zugriff. Gelistete Dienste werden ohne neue Rückfrage freigegeben, gesperrte abgewiesen und unbekannte dem Nutzer vorgelegt.
  • Das Zugriffstoken soll Nutzerkonto, Agent und Center kennzeichnen. Ob die Freigabe automatisch oder durch einen Menschen erfolgte, muss es nicht sagen. Der Abschnitt zu Sicherheitsfragen steht noch auf TBD.

Der schnellste Genehmigungsdialog ist einer, der gar nicht erscheint. Im Entwurf zum Agent Authorization Center erkauft eine vorab angelegte Liste diese Ruhe. Der Vorschlag gilt für Agenten auf persönlichen Geräten, die Dienste im Namen des Nutzers besuchen. Die eigentliche Entscheidung fällt früher: Wer trägt einen Dienst ein und wie lange darf dieser Eintrag spätere Anfragen beantworten?

Das AAC soll Identität, Agentengruppen, einzelne Agenten und individuelle Zugriffsregeln verwalten. Der Agent meldet sich beim Dienst mit Nutzer- und AAC-Kennung; der Dienst verweist ihn an das Center. Dort werden Nutzer, Agent und Dienst abgeglichen. Auf der autonomen Liste folgt die Freigabe ohne menschliche Beteiligung bei diesem Vorgang. Die Sperrliste führt zur Ablehnung. Fehlt der Dienst in beiden Listen, soll der Nutzer bestätigen.

Nach der Freigabe läuft ein OAuth-Autorisierungscode zum Dienst, der ihn gegen ein Token tauscht, dieses prüft und nach den Rechten des Nutzers handelt. Nutzerkonto, Agent und AAC sollen im Token stehen. Die Angabe, ob ein Mensch oder die Liste freigegeben hat, ist dagegen nur möglich, nicht verpflichtend. Ein Dienst kann also den Aussteller kennen und die Freigabeart nicht.

Für wiederkehrende Routine ist das praktisch. Der sechsseitige Entwurf bestimmt aber weder einzelne erlaubte Handlungen bei einem gelisteten Dienst noch Version, Ablaufzeit oder Widerrufsfolge des Listeneintrags. Zwar bleibt der Dienst an die Rechte des Nutzers gebunden. Ein Eintrag für einen Dienst beantwortet jedoch nicht von selbst, ob ein Kauf, eine Datenfreigabe oder eine Kontoänderung im konkreten Auftrag liegt. Hier treffen Center-Regel und lokale Entscheidung aufeinander.

Der ganze Abschnitt „Security Considerations“ lautet TBD. RFC 9700 enthält Sicherheitsregeln für OAuth; RFC 7636 beschreibt PKCE zum Schutz von Autorisierungscodes. Der Entwurf muss angeben, welche dieser Maßnahmen Agent, AAC und Dienst im neuen Ablauf jeweils anwenden; einen Einführungstest nennt er nicht.

Im Datatracker steht das Papier als individueller Informational-Entwurf mit Status I-D Exists. Ein brauchbarer Versuch würde einen Dienst freigeben, einen eng begrenzten Auftrag ausführen lassen, den Listeneintrag ändern und beim nächsten Token prüfen, welche Entscheidung der Dienst tatsächlich nachvollziehen kann. Ein gültiges Token ist noch kein Protokoll darüber, wer diese Handlung wollte.