Summary

  • Unter /.well-known/agent-capabilities sollen Anwendungen Abläufe, Autorisierungsserver und Aufrufstellen für Agenten bekanntgeben.
  • Eine Operation außerhalb aller bekanntgegebenen Abläufe ist geschlossen. Der Ressourcenserver darf sie auch dann nicht ausführen, wenn eine bereits genehmigte Autorisierungsinstanz sie aufführt.

Der Agent hält eine Genehmigung in der Hand. Der Dienst hat den betreffenden Ablauf inzwischen aus seiner öffentlichen Liste gestrichen. Nach dem neuen IETF-Entwurf entscheidet die aktuelle Liste: Kein veröffentlichter Ablauf, keine Ausführung. Der Ressourcenserver muss den Aufruf zurückweisen; der Autorisierungsserver sollte eine Instanz mit der geschlossenen Operation ablehnen. Das JSON-Dokument auf dem Ursprungssystem ist damit eine Stellschraube für ausführbare Rechte.

Eine reguläre Streichung kann den Zugang schnell beenden. Abschnitt 8.6 beschreibt zugleich den Angriffspfad: Hat ein Angreifer Schreibzugriff auf statische Inhalte des Ursprungs, kann er das Dokument ersetzen. Danach entdeckende Agenten ließen sich zu anderen Aufrufstellen lenken oder von echten Abläufen fernhalten, ohne dass sich der Anwendungscode ändert. Die Autoren empfehlen deshalb dieselbe Änderungskontrolle wie für die Anwendung selbst. RFC 8615 hatte bereits darauf hingewiesen, dass Administratoren .well-known-Pfade leicht übersehen. Hier wäre ein übersehener Pfad Teil der Zugriffssteuerung.

Native Apps dürfen eine Kopie für die Offline-Entdeckung mitliefern. Vor der ersten entfernten Operation einer Sitzung muss die App aber das Dokument ihres zugeordneten Ursprungs prüfen. Bei Abweichung gilt die dort gelieferte Fassung. Eine aus ihr entfernte Operation bleibt geschlossen, auch wenn das installierte Paket noch das Gegenteil behauptet. Der Vertriebskanal der App ist also kein letzter Schiedsrichter über die aktuelle Freigabe.

Anzeigename und Logo gelten im Entwurf nicht als Identitätsnachweis. Maßgeblich sind Ursprung und authentifizierte Übertragung; bei zusätzlicher OAuth-Metadatenveröffentlichung müssen die Autorisierungsserver-Listen übereinstimmen. Der IETF-Eintrag führt den Text als individuellen Entwurf. Für ein Urteil über einen realen Dienst fehlen dessen Dateihistorie und Protokolle tatsächlich abgelehnter Aufrufe.