Zusammenfassung

  • Release 5 lässt getrennte CAPIF Core Functions Service-APIs über Domänengrenzen teilen.
  • Jede Verbindung prüft den Peer, nutzt gegenseitiges TLS und wendet Freigaben sowie Sichtbarkeitsregeln des Anbieters an.

OpenCAPIF hat die Tür zum API-Nachbarn gefunden. Release 5 stellt erst einmal das Klemmbrett daneben.

ETSI kündigte OpenCAPIF 5.0.0 am 26. Oktober an. Die Hauptfunktion, CAPIF Interconnection, verbindet getrennte OpenCAPIF-Installationen. Sie können APIs über Organisationsgrenzen hinweg veröffentlichen und entdecken. Ein Invoker an einer CAPIF Core Function (CCF) kann so eine Service-API hinter einer anderen CCF erreichen. Der Knackpunkt ist, wer auf der anderen Seite steht und welche API der Anbieter herausrücken will.

Der Administrator der lokalen CCF startet die Verbindung. CCF-A kontaktiert CCF-B über gegenseitiges TLS und sendet CCF-ID, Domäne, Angaben zur Zertifizierungsstelle und öffentlichen Schlüssel. CCF-B speichert den Peer und antwortet mit der eigenen Identität. Anschließend synchronisieren beide Seiten die freigegebenen APIs. Der Handschlag ist technisch beschrieben; das anschließende Sortiment bleibt eine Entscheidung des Anbieters.

Eine API reist nur mit passender Freigabe. isShareable muss gesetzt sein, und capifProvDoms muss die Zieldomäne nennen. Quelle und bisheriger Veröffentlichungspfad werden ebenfalls geprüft. Eine empfangene API wird als nicht weiter teilbar markiert, damit sie nicht über denselben Weg zurückläuft. Das verhindert, dass ein sauberer Austausch in eine API-Pingpong-Partie kippt.

Open Discover beantwortet eine Frage vor dem Onboarding: Gibt es die gesuchte API, Version oder den Endpunkt in dieser Installation? Ein gültiges Token aus dem Register Service genügt für die Abfrage. Erst nach dem Treffer muss der Invoker den längeren Aufnahmeprozess durchlaufen. Das Klemmbrett kommt also nach der Inventur zum Einsatz, nicht davor.

Visibility Control steuert, was in der Antwort auftaucht. Anbieter und Administratoren können Regeln für Anbieter, APIs und API Exposing Functions (AEFs) setzen, Ausnahmen für einzelne Invoker eintragen, standardmäßig erlauben oder verweigern, Regeln aktivieren und Fristen festlegen. Discover wendet die aktiven Regeln auf jede Anfrage an. Ein API-Katalog kann deshalb je nach Fragesteller anders aussehen.

Gleiche API-Namen dürfen jetzt aus verschiedenen AEFs kommen. Innerhalb derselben AEF bleibt ein Duplikat unzulässig. Der Name wird im Kontext der Funktion behandelt, die den Dienst exponiert.

3GPP führte CAPIF Interconnection in Release 16 ein und beschreibt die Referenzpunkte CAPIF-6/6e sowie Sicherheitsverfahren. Details der Umsetzung bleiben teilweise offen. OpenCAPIF kennzeichnet den konkreten Ablauf als eigenen SDG-Implementierungsvorschlag innerhalb der 3GPP-Architektur. Release 5 macht diese Entscheidung überprüfbar: welche Identität übermittelt wird, welche APIs die Filter passieren und wie zwei CCFs synchronisieren.

31 neue Tests verteilen sich auf elf Interconnection-, zwölf Visibility-, sechs Open-Discover- und zwei Same-Name-Fälle zwischen AEFs. Die Zahl zeigt, wo die Entwicklungsarbeit landete. Im Betrieb sollte das Klemmbrett weitergeführt werden: Peer, API, Freigabe, sichtbare Invoker und Rücknahme der Kopie beim Ende der Beziehung.

Sources