Jurisdiktionsübergreifende rechtliche Identitätssicherung für Capability Gating

Identifikationsschwellen für fähigkeitstragende Interaktionen

Identity Assurance wird hier als soziotechnisches Zurechnungssystem modelliert: als geordnete Umgebung, in der handelnde Einheiten, Evidenzquellen, Relying Services, Regulierungsstellen und jurisdiktionale Regeln zusammenwirken. Die Systemgrenze wird um die identitätsrelevante Interaktion gezogen, nicht um eine Datenbank, eine Wallet oder einen einzelnen Provider. Innerhalb dieser Grenze besteht das Gestaltungsproblem darin, einen Assurance-Zustand zu erzeugen und wiederzuverwenden, der bewertet werden kann, wenn eine Capability angefordert wird.

Das System steht zwischen Actors und Capabilities. Es beobachtet einen Actor anhand vorgelegter Evidenz, erfasst die Quellen- und Zeitstruktur dieser Evidenz, ordnet den Actor einem jurisdiktionalen Rahmen zu und lässt einen deklarierten Gate den daraus entstehenden Zustand konsumieren. Die Kernfrage lautet, wer oder was welche Handlung vornehmen darf, unter welchem Recht, auf welcher Evidenz, zu welchem Zeitpunkt und mit welcher Relying Party, die welche verbleibende Verantwortung akzeptiert.

Die Gestaltungsprämisse ist capability-proportionale Teilnahme. Innerhalb des anwendbaren Rechtsrahmens genügt ein Zustand niedriger Assurance für Interaktionen mit geringen Folgen, während Handlungen mit höheren Folgen stärkere Evidenz, frischere Bestätigung oder ein explizites regulatorisches Mapping erfordern. Dies ist die Nicht-KYC-Untergrenze des Papers: legitime Teilnahme mit minimaler Identitätslast, durch Capability begrenzt und nicht als gescheiterte Verifizierung behandelt. Eine Anforderung zusätzlicher Informationen wird durch ein Gate-Prädikat, eine Rechtsgrundlage oder eine Risikoentscheidung der Relying Party gerechtfertigt, und die Folge eines nicht erfüllten Prädikats bleibt auf die angeforderte Capability beschränkt. Wiederverwendbare Assurance macht Verifizierung zu mitgeführter Evidenz: Ein verifizierter Claim kann mit Einwilligung, Quelle, Zeit und Scope erneut vorgelegt werden, während Relying Parties ihre eigenen Gates und Aufbewahrungspflichten anwenden. Das Design verschiebt wiederholte Identitätserhebung hin zu prüfbarer Reliance auf einen bitemporalen Assurance-Zustand.

Der Grenzfall macht die Last sichtbar. Eine Gesellschaft heisst täuschungsfrei, wenn keine teilnehmende Einheit lügt, stiehlt oder missbraucht, was sie erfährt. Der Fall ist nicht allwissend: Teilnehmende können sich weiterhin irren, vergessen, kollidieren und sterben. In einer solchen Gesellschaft fällt die Identitätsabgabe beinahe auf null. Eine reisende Person nennt an einer Grenze ihren Namen und wird auf Grundlage dieser Behauptung beurteilt, ohne Pass, Passwort oder Nachweis, weil Behauptung und Wahrheit nicht auseinanderfallen.

Aufschlussreich ist, was übrig bleibt. Identität fällt nicht auf null; sie fällt auf den nackten Identifier. Ein Name, ein Geburtsdatum und Geburtsort oder eine stabile Referenz wie eine nationale Nummer werden weiterhin benötigt, um eine Person von einer anderen zu unterscheiden, die richtige Partei anzusprechen und Aufzeichnungen korrekt zu halten, wenn ehrliche Teilnehmende sich falsch erinnern. Dokumentation überlebt aus demselben Grund: Sie trägt Information von einer Partei zur nächsten und von einer Zeit zur anderen. Der täuschungsfreie Grenzfall trennt zwei Dinge, die gewöhnliche Praxis verschmilzt: den Identifier, der koordiniert, und die Bestätigung, die gegen Täuschung schützt. Der erste überlebt vollkommene Ehrlichkeit; die zweite ist die Abgabe.

Selbst vollkommene Ehrlichkeit lässt einen Rest, den ein Actor nicht über sich selbst liefern kann. Ob er weiterhin existiert, ob er rechtsfähig ist und ob eine andere Partei ihm Befugnis eingeräumt hat, sind Tatsachen, die keine ehrliche Erklärung feststellen kann, weil der Actor nicht ihre Quelle sein kann. Eine täuschungsfreie Gesellschaft braucht für solche Tatsachen weiterhin externe Bestätigung. Deshalb ist das Selbst die Untergrenze der Bestätigungsskala und nie ihre Garantie.

Wir behandeln die beiden reinen Fälle, vollständige Ehrlichkeit und vollständige Täuschung, als Grenzidealisierungen, so wie die exakten Wissenschaften von einer reibungsfreien Ebene oder einem idealen Körper her denken: Keines der Extreme tritt in reiner Form auf, aber beide legen das Gesetz frei, das alles zwischen ihnen beherrscht. Am täuschungsfreien Pol fällt die geforderte Assurance auf die Identifier-Untergrenze; am Gegenpol, an dem jede Partei lügen kann, steigt sie auf flache Maximalverifizierung. Reale Interaktionen liegen dazwischen, und wo eine bestimmte Interaktion liegt, hängt von der Handlung ab: davon, wie stark sie Täuschung ausgesetzt ist und welches Gewicht ihre Folgen haben. Geforderte Assurance lässt sich dann als Funktion dieser beiden Grössen schreiben,

Das Label «know your customer» benennt den Apparat nach einer Beziehung (der Kundschaft) und einem epistemischen Zustand (Wissen), und keines von beiden trägt das rechtliche Gewicht. Das Gewicht liegt anderswo: Eine Handlung findet statt, sie hat Folgen, und das Rechtssystem muss diese Handlung einem Punkt zurechnen, den es verantwortlich halten kann. Dieses Paper liest Kelsen und Luhmann als Stütze dieser Zurechnungssicht: Rechtspersönlichkeit funktioniert als Zurechnungspunkt, als point of imputation, als der Ort, an dem Rechte, Pflichten und die Folgen von Handlungen landen.(Kelsen 1967; Luhmann 1995, 2004) Natürliche und juristische Personen sind zwei Arten eines solchen Punktes. Die Rahmung formuliert die elementare Tatsache neu, dass ein Actor handelt und die Handlung Folgen hat, in den Begriffen, die das Rechtssystem bereits für sich selbst verwendet.

«Actor» ist in dieser Lesart kein weicheres Wort für «user», sondern die Bezeichnung für dasjenige, dem eine folgenreiche Handlung zugerechnet wird. Der Identitätsapparat, Customer Due Diligence eingeschlossen, existiert, um Zurechnung vertretbar zu machen: um sicherzustellen, dass bei einer Handlung mit Rechtswirkung ein rechenschaftsfähiger Punkt dahintersteht und die Evidenz vorhanden ist, die sie dort bindet. Identity Assurance ist in diesem Sinn Infrastruktur für Zurechnung, und die Konstruktion «know your customer» benennt das Nebenprodukt (eine Gegenpartei kennen) statt der Funktion (eine Handlung zurechnen).

Damit wird die systemtheoretische Lesart zurückgewonnen. Soziale Systeme bestehen nach Luhmann aus Kommunikationen und Handlungen, nicht aus Personen, und der Mensch gehört zur Umwelt des Systems. Das System «kennt die Kundschaft» nicht; es registriert Handlungen und konditioniert sie. «Know your customer» ist dann gleich doppelt ein Kategorienfehler: Es setzt eine Person dort, wo das System nur Handlungen hat, und eine Beziehung dort, wo das System nur Zurechnung hat. Eine Actor-zentrierte Rahmung stellt beides wieder her, sodass die Einheit die Handlung ist, der Actor ihr Zurechnungspunkt, und Assurance die Stärke, mit der das System dahinterstehen kann, eine Folge auf diesen Punkt zu richten. Das Prinzip, an dem sich die Frage entscheidet, warum ein System überhaupt identifiziert, lautet deshalb wie folgt.

Ein System verlangt Identität nur in dem Mass, in dem die Folgen einer Handlung einem rechenschaftsfähigen Punkt zurechenbar sein müssen, und nur proportional zum Gewicht dieser Folgen.

Das Prinzip hat eine Umkehrung, die es vervollständigt. An der Grenze der täuschungsfreien Gesellschaft wird der reisenden Person aufs Wort geglaubt, doch ihr kann die Einreise weiterhin verweigert werden: Die geforderte Assurance ist auf die Identifier-Untergrenze gefallen, während die Entscheidung, zuzulassen oder abzuweisen, unberührt bleibt. Wie stark ein Actor identifiziert ist und ob seine Handlung erlaubt ist, sind unabhängige Grössen. Ein Design, das eines aus dem anderen ableitet, indem es das andere setzt, hat zwei verschiedene Fragen verschmolzen. Dies ist die zweite Gestaltungsverpflichtung: Der Assurance-Zustand wird von dem Capability Gate getrennt gehalten, das ihn konsumiert, sodass derselbe Zustand einen Gate passieren, an einem anderen scheitern und später für ein Audit erneut abgespielt werden kann, ohne für eines davon neu erhoben zu werden.

Der täuschungsfreie Grenzfall ergibt ein weiteres strukturelles Resultat, und auf diesem baut der Rest dieses Papers auf. Der Grenzfall spaltete Identität in zwei Komponenten, die gewöhnliche Praxis verschmilzt: den Identifier, der koordiniert, und die Bestätigung, die schützt. Die beiden beantworten verschiedene Fragen und variieren unabhängig. Welche Tatsachen über den Actor eine Handlung lesen können muss, wird durch die Funktion der Handlung und ihr rechtliches Mapping festgelegt: Ein altersbeschränkter Kauf braucht ein Geburtsdatum und nichts anderes, eine Auszahlung braucht eine Zahlungsroute, eine Eigentumsübertragung braucht den bürgerlichen Namen in der Urkunde. Wie stark jede Tatsache geschützt werden muss, wird durch Exposition und Gewicht der Handlung festgelegt, die beiden Argumente von Gl. 1. Ein Modell, das Identität auf einer einzigen Skala bewertet, hat keinen Ort, an dem es diesen Unterschied halten kann: Es muss mit einer Zahl antworten, wo jede Handlung zwei Fragen stellt, nämlich welche Tatsachen und wie stark jede einzelne. Der Assurance-Zustand braucht zwei orthogonale Achsen, eine Assertion-Achse, die erfasst, was eine Entität offengelegt hat, und eine Source-of-Information-Achse, die erfasst, wer hinter jedem offengelegten Element steht. Was eine Handlung verlangt, ist eine Menge gepaarter Anforderungen,

Alles Nachgelagerte, die Entitätstaxonomie, die Assertion- und Source-Achsen, das Grid und seine Koordinate, die Capability Gates und wiederverwendbare Reliance, ist Maschinerie, um Zurechnung in der richtigen Stärke, zum richtigen Zeitpunkt und für den richtigen Actor zu erzeugen.

Entitätstaxonomie für Assurance-Bewertung

Das Assurance-Subjekt wird typisiert, bevor es bewertet wird. Der Abschnitt verwendet zwei Begriffe strikt. Eine Entität ist die statische Trägerin eines Assurance-Zustands, präsent, weil sie gehalten werden kann oder weil sie actuate kann. Ein Actor ist diese Entität in der Handlung, der eine Folge zugerechnet wird. Die Unterscheidung ist wichtig, weil technische Handlung und rechtliche Identität nicht zusammenfallen müssen. Eine Maschine kann den Zustand eines Systems ändern und muss aus diesem Grund als Entität modelliert werden; geltendes Recht leitet Pflichten und Haftung weiterhin durch natürliche oder juristische Personen um die Maschine herum, etwa Provider, Deployer, Hersteller:innen und andere Wirtschaftsbeteiligte.(European Parliament and Council of the European Union 2024e, arts. 3, 16, 25, and 26)(European Parliament and Council of the European Union 2024b, art. 4) Die Taxonomie ist durch diesen Zweck festgelegt: Ein System identifiziert eine Entität, damit es, falls Schaden folgt, eine Folge auf den rechenschaftsfähigen Punkt eines Actors richten kann, während nichts offengelegt wird, bis eine Handlung es verlangt. Für eine Handlung einzustehen hat eine operative Bedeutung. Für eine Handlung wird eingestanden, wenn ihre Folge an einen Punkt adressiert werden kann, den die Rechtsordnung halten, also verklagen kann. Die Taxonomie dreht sich um eine Frage, die an alle Teilnehmenden gestellt wird, und um eine zweite, die nur an jene gestellt wird, die die erste bestehen.

Die erste Frage ist, ob die teilnehmende Einheit verklagbar ist: ob das Recht erlaubt, eine Handlung oder einen Vermögenswert in ihrem eigenen Namen an sie zu adressieren. Die zweite, an die Verklagbaren gerichtete Frage ist die Quelle des Verhaltens: ob sie eine Handlung hervorbringen kann oder ob durch sie gehandelt wird. Die beiden Fragen partitionieren den Raum. Eine verklagbare teilnehmende Einheit, die Verhalten hervorbringt, ist eine natürliche Entität (N), ein natürlicher Wille, der sowohl handelt als auch gehalten werden kann. Eine verklagbare teilnehmende Einheit, die kein eigenes Verhalten hervorbringt, durch die aber gehandelt wird, ist eine juristische Entität (J), ein Konstrukt, das das Recht hält, obwohl Handlung sie durch Organe, Vertretungen, Trustees oder mandatierte Maschinen erreicht. Eine teilnehmende Einheit, die Verhalten hervorbringt, aber nicht verklagbar ist, ist eine Maschinen-Entität (M), ein gebauter Aktuator, der das System verändert, aber nicht als rechtlicher Endpunkt von Verantwortung stehen kann. Im rechtlich relevanten Betrieb muss sie an eine verklagbare N oder J angeschlossen sein oder an eine zulässige Konstellation, die diesen Endpunkt liefert. Die verbleibende logische Kombination, eine teilnehmende Einheit, die weder handelt noch gehalten werden kann, ist ein träges Objekt ausserhalb des Assurance-Modells. Die Accountability-Achsen ergeben genau drei Entitätstypen, die sich der Art nach unterscheiden und nicht dem Grad nach.

Zwei Qualifikationen halten die Partition exakt. Erstens deckt der Maschinentyp gebaute oder programmierte Aktuatoren ab, die unter einem Mandat handeln, das das System lesen kann. Blosse kausale Kräfte werden je nach rechtlicher Beziehung, die sie in die Handlung einbringt, als Instrumente oder Objekte in einem Accountability-Pfad behandelt. Zweitens hat Verklagbarkeit zwei Grade, und nur der formale Grad typisiert die Entität. Eine teilnehmende Einheit ist formal verklagbar, wenn sie als beklagte Partei benannt werden kann, und materiell verklagbar, wenn tatsächlich ein Wille, ein Vermögen oder eine rechtlich adressierbare Accountability-Oberfläche vorhanden ist, die gehalten werden kann. Der Typschnitt verwendet formale Verklagbarkeit; materielle Verklagbarkeit steuert den Zulassungszustand des Artefakts. Eine juristische Hülle ohne rückverfolgbaren Kontrollpunkt und eine Maschine ohne rechenschaftsfähigen Anschluss können in manchen Settings formal adressierbar, für das Assurance-System aber materiell leer sein; das Modell hält sie innerhalb ihres Typs dormant. Dormancy ist ein Zulassungszustand, kein vierter Typ.

Die resultierende Taxonomie, dargestellt in 1, zeigt diese zweifache Herleitung zusammen mit den drei Entscheidungen, die das Modell am stärksten von einer konventionellen Identitätsontologie unterscheiden. Sie präsentiert die drei Typen als Ergebnis der Schnitte Verklagbarkeit und Verhaltensquelle, nicht als entlehnte Liste rechtlicher Kategorien; sie zeichnet den juristischen Typ als einen einzigen Katalog, dessen Gesellschafts-, Vereins-, Stiftungs-, öffentlich-rechtliche Körperschafts- und Partnerschaftsformen Werte eines Registerparameters sind, statt eigene Zweige zu bilden, mit dem Legal Arrangement als seiner flachen, trustee-zugerechneten Ecke; und sie ersetzt einen Maschinen-Unterbaum durch drei Deskriptorachsen, Capability, Trust und Control, unter denen die vertrauten Labels Bot, Smart Contract und künstliche Intelligenz Regionen statt Arten sind. Nach unten gelesen löst sich jeder Typ in ein Grid von offengelegtem Assertion Scope gegen Source of Information auf, aus dem ein Tier abgeleitet wird. Die Figur ist in diesem Sinn eine Karte, wo Folgen landen können und wie stark jeder Landepunkt belegt ist, keine Rangliste.

Mit diesem festen Vokabular ist die Figur als Zurechnungskarte zu lesen, nicht als Bevölkerungsliste. Natürliche Personen, juristische Entitäten einschliesslich der unten besprochenen Legal Arrangements und Maschinen, die unter Mandat handeln, können alle einen Assurance-Zustand tragen. Zu Actors werden sie nur in einer Handlung. Die Entität ist das, was klassifiziert, belegt, gegated und später auditiert werden kann; der Actor ist die Entität, während das System eine Folge auf sie richtet.

Zwei Folgen ergeben sich. Erstens ist Entitätstyp ein Zurechnungsregime und kein klassifikatorischer Behälter: Wofür eine natürliche Person gehalten werden kann, was als ihre Identität zählt und welche Evidenz sie bindet, unterscheidet sich von einer juristischen Entität und wiederum von einem Legal Arrangement, das innerhalb des juristischen Typs als eigene Ecke sitzt, während nichts davon für eine Maschine gilt, die actuate kann, aber nicht der rechtliche Wurzelpunkt der Zurechnung sein kann. Die Entitätstaxonomie ist die Struktur der Zurechnung selbst, weshalb sie tragend ist und weshalb sie dem Assurance-Modell vorausgeht: Sie ist die Karte, wo Folgen landen können.

Entitätstypen unterscheiden sich nicht nur darin, wie sie identifiziert werden, sondern auch darin, ob sie überhaupt Handlung hervorbringen können, und diese Asymmetrie, der zweite Schnitt, prägt sowohl das Threat Model als auch die Struktur der Accountability. Natürliche und maschinelle Entitäten sind Quellen von Verhalten: Eine natürliche Person handelt durch Körper und Willen, und eine Maschine führt Handlungen aus und kann dies adversarial tun, sei es durch Autonomie, Misalignment oder Capture. Eine juristische Entität, die in sie eingefalteten Legal Arrangements eingeschlossen, hat kein eigenes Verhalten; sie handelt nur durch die natürlichen Personen, die als ihre Organe oder Trustees dienen, oder durch Maschinen, die unter ihrem Mandat handeln. Die Unterscheidung ist kategorial: Eine natürliche oder maschinelle Entität verhält sich, während durch eine juristische Entität gehandelt wird.

Auf dieser Grundlage schlagen wir vor, dass Malice, verstanden als Verbindung von Verhalten und Absicht, in einer verhaltenstragenden Entität entsteht. Eine juristische Entität ist der rechtliche Ort, dem eine andere Verhaltensquelle zugerechnet wird: die Handlung einer natürlichen Person oder die Handlung einer mandatierten Maschine zusammen mit dem natürlichen oder juristischen Punkt, der sie kontrolliert. Was umgangssprachlich als malicious entity bezeichnet wird, ist strukturell die Malice natürlicher Personen, die durch die Entität handeln und ihr zugerechnet werden, oder die rechtlich zugewiesene Folge einer Maschinenhandlung unter Mandat. Die Common-Law-Doktrin der Unternehmenszurechnung drückt dieselbe Asymmetrie in einem dogmatischen Setting aus, wenn sie schuldhafte Unternehmenszustände konstruiert, indem sie die Absicht einer natürlichen Person der Entität durch die directing-mind- oder identification doctrine zurechnet.(United Kingdom House of Lords 1971) In diesem Modell ist juristisches Verschulden ein zugerechneter Zustand und keine ursprüngliche Verhaltensquelle.

Diese Asymmetrie bestimmt, wogegen jeder Entitätstyp verifiziert werden muss. Eine natürliche Entität wird gegen die Nachahmung eines lebenden, wollenden Körpers verifiziert, da die Bedrohung ein falscher Wille ist, der als echt präsentiert wird. Eine Maschinenentität wird gegen Handeln ausserhalb ihres Mandats und gegen Capture verifiziert, da die Bedrohung Verhalten ist, das ihre Autorität überschreitet oder verrät. Eine juristische Entität wird gegen die Nachahmung der registrierten Entität und gegen die Integrität der natürlichen Personen verifiziert, die für sie rechenschaftsfähig sind, da die Entität selbst weder wollen noch delinquieren kann; die Bedrohung besteht darin, dass eine impostorische Partei als Entität auftritt oder dass die natürlichen Personen hinter ihr sie als Vehikel verwenden.

Eine juristische Entität ohne rechenschaftsfähige Verhaltensquelle hinter sich ist für dieses Artefakt ein ursprungsloses Konstrukt: ein Zurechnungspunkt ohne etwas, von dem zugerechnet werden könnte. Das System hält eine solche Entität dormant. Die Anschlussanforderung ist eine aus Zurechnung und Beneficial-Ownership-Druck abgeleitete Designregel: Eine aktive juristische Entität muss einen rückverfolgbaren Eigentums-, Kontroll-, Organ-, Trustee- oder Vertretungspfad vorlegen, der mindestens eine identifizierte natürliche Person oder eine rechtlich anerkannte Amtsträger:in in treuhänderischer Eigenschaft erreicht. Zwischenglieder in der Kette können andere juristische Entitäten sein, wie in gewöhnlichen Holdingstrukturen, aber die transitive Hülle des eingereichten Assurance-Pfads muss einen natürlichen Willen enthalten, bevor die Entität einen aktiven Assurance-Zustand erhalten kann. Eine Kette von Konstrukten, die in keinem rechenschaftsfähigen natürlichen oder treuhänderischen Punkt endet, ist die Struktur, die die Regel ausschliesst, und die Struktur, die opakes Eigentum ausnutzt.

Diese Anforderung ist enger als das Beneficial-Ownership-Recht und von ihm informiert. Quellen zur Bekämpfung der Geldwäscherei verlangen Transparenz juristischer Personen und Legal Arrangements, damit Behörden und Verpflichtete die natürlichen Personen identifizieren können, die sie letztlich besitzen oder kontrollieren.(European Parliament and Council of the European Union 2024d, arts. 51–63)(Financial Action Task Force 2025, recs. 24–25)(Financial Action Task Force 2023, 2024) Dieses Regime wird gewöhnlich als Compliance-Pflicht dargestellt. Die Zurechnungslesart liefert die Artefaktregel: Weil natürliche Personen Handlung hervorbringen, sollte Accountability für den Assurance-Zustand einer juristischen Entität in identifizierten natürlichen Personen oder treuhänderischen Amtsträger:innen verankert sein, deren Befugnis belegt werden kann. Der Beitrag hier besteht darin, diesen rechtlichen Druck in eine Zulassungs- und Gate-Regel zu übersetzen, nicht darin zu behaupten, dass geltendes Recht die Regel bereits in genau dieser Form formuliert.

Dasselbe Prinzip, als Grösse statt als Bedingung formuliert, ergibt die später entwickelte inheritance bound: Die Assurance einer juristischen Entität kann die Assurance der natürlichen Personen, die für sie rechenschaftsfähig sind, nicht übersteigen, und ein zusammengesetzter Gate über einer juristischen Entität liest den Zustand der Entität, die Zustände der angeschlossenen natürlichen Personen und die Gültigkeit der Delegation zwischen ihnen zusammen. Die Anschlussregel stellt fest, dass die rechenschaftsfähigen natürlichen Personen existieren und identifiziert sind; die inheritance bound stellt fest, wie ihre Assurance auf die Entität propagiert. Weil gewöhnlich mehr als eine natürliche Person rechenschaftsfähig ist, ein Board, eine Gruppe von Partner:innen, ein Gremium von Kontrollpersonen, erfolgt der Anschluss an eine Menge statt an einen einzelnen Anchor, und die Bound wird pro Handlung über die Teilmenge bewertet, die die Delegation der Handlung tatsächlich durchläuft: Die Assurance einer gemeinsam erforderlichen Zeichnung ist die ihrer schwächsten erforderlichen zeichnenden Person, während die Entität dort, wo eine von mehreren handeln darf, ihre stärkste vorlegen kann. Die Menge trägt zwei Lesarten, die der Gate auseinanderhält: die Entscheidungsregel, die die autorisierende Teilmenge und damit die Bound auswählt, und den Haftungsmodus, der die Recovery Surface festlegt.

Formal ausgedrückt, mit $\tau(\cdot)$ als dem Tier, den ein Gate aus dem gefüllten Grid einer Entität ableitet (4.8), und $\mathcal{Q}(a)$ als der Familie von Teilmengen rechenschaftsfähiger natürlicher Personen, deren Delegation Handlung $a$ wirksam autorisiert, lautet die inheritance bound

Innerhalb eines Typs wird eine Entität auf zwei Achsen bewertet, die der Typ auswählt, aber nicht verändert: dem offengelegten Assertion Scope, dem Katalog von Identitätselementen, die sie offenlegen kann, und der Source of Information, dem rechenschaftsfähigen Gewicht hinter jedem offengelegten Element. Der Katalog unterscheidet sich je nach Typ in der Länge, reich für eine natürliche Entität, registergebunden für eine juristische, ein kurzer Deskriptorsatz für eine Maschine, während die Source-Achse gemeinsam ist. Beide Achsen, das von ihnen aufgespannte Grid und die Koordinate, die eine Zelle benennt, werden in den Unterabschnitten zu Assertion-Granularität, Source of Information und Koordinate unten entwickelt; hier genügt, dass der Typ festlegt, welchen Katalog eine Entität trägt, und die Handlung festlegt, welche seiner Zellen gelesen werden müssen. Was lose als Tier bezeichnet wird, ist ein aus dem gefüllten Grid gegen eine Schwelle abgeleiteter Wert, niemals eine Zeile darin. Deshalb zeigt 1 ein Grid und keine Leiter.

Der juristische Typ wirkt in der Figur fast so flach wie der natürliche, und eine lesende Person wird berechtigterweise einwenden, dass das Recht offensichtlich viele Arten von Rechtsperson kennt, eine Gesellschaft, einen Verein, eine Stiftung, eine öffentlich-rechtliche Körperschaft, eine Partnerschaft, einen Trust, die jeweils eine eigene Behandlung zu verdienen scheinen. Sie unterscheiden sich, aber nicht dort, wo das Modell typisiert. Eine Unterscheidung verdient nur dann einen eigenen Typ, wenn sie den Assertion-Katalog oder das Verhalten der Bestätigungsachse verändert, und die registrierten juristischen Formen verändern keines von beiden. Sie teilen eine Katalogform, rechtlicher Name, Gründungsinstrument, Registereintrag, Organe oder Vertretungen, Zweck, Status und die rechenschaftsfähigen natürlichen Personen dahinter; sie teilen die eine Source-Skala; und sie teilen ein einziges Zurechnungsregime, einen konstruierten Punkt, den das Recht hält und der über den Anschluss in natürlichen Personen gründet. Was zwischen ihnen variiert, ist, welches autoritative Register die Source-Achse beantwortet, ein Handelsregister für eine Gesellschaft, eine Aufsichtsbehörde für eine Stiftung, ein öffentlich-rechtliches Instrument für eine öffentlich-rechtliche Körperschaft, gar keines für einen nicht registrierten Verein, zusammen mit einer kleinen Menge von Prädikaten, die ein Gate direkt liest: ob die Form eigene Persönlichkeit trägt, ob Beneficial-Ownership-Tracing gilt und wo Zurechnung landet.(European Parliament and Council of the European Union 2017; Financial Action Task Force 2023, 2024) Jede Form als eigenen Subtyp zu zeichnen, würde formgleiche Kataloge vervielfachen und Unterschiede bewahren, die kein Gate aus dem Typ liest. Das Modell hält sie aus demselben Grund als juristische Formprädikate, aus dem es Übererhebung ablehnt: Seine Maschinerie soll nur die Unterschiede verfolgen, die eine Handlung tatsächlich konsumiert.

Die Unterschiede bewegen sich vom Typbaum, wo sie zu separater Maschinerie verhärten würden, in eine Prädikatmenge, die ein Gate einzeln abfragen kann. Die zwei echten Variationen des Regimes zeigen, wie. Eine Partnerschaft wird wie eine Gesellschaft registriert und bewertet, wo das geltende Recht ein Register bereitstellt, doch das Modell kann persönliche Haftung über separate-personality=false an Partner:innen routen, wo dies die Rechtsfolge ist. Ein Legal Arrangement wie ein Trust wird über die Fiduzialperson oder den Trustee behandelt, auf die oder den Zurechnung fällt, wobei Beneficial-Ownership- und Transparenzregeln als Legal-Arrangement-Prädikate behandelt werden, nicht als neuer Entitätstyp.(Financial Action Task Force 2024) Die äussere Grenze des Typs folgt demselben funktionalen Test: Eine Formation ist juristisch, wenn das Recht sie in ihrem eigenen Namen oder durch eine erforderliche Amtsträger:in oder treuhänderische Eigenschaft verklagbar macht, mit einem von ihren Teilnehmenden getrennten Vermögen oder Patrimonium. Wo das Recht stattdessen zu den Teilnehmenden durchgreift, wie bei einer informellen Gruppe, ist das Assurance-Subjekt eine Konstellation der natürlichen Personen selbst. Ein Register ist starke Evidenz, dass diese Linie überschritten wurde, nie ihre Definition.

Eine Maschinenentität trägt keinen Katalog von Lebenstatsachen; sie wird stattdessen durch drei orthogonale Achsen beschrieben, die ein Gate zusammen liest. Ihre Capability ist der Handlungsumfang, den ihre Konstruktion erlaubt, geordnet als deterministischer Aktuator, dessen Entscheidungsweg keine Modellinferenz enthält (M1), als modellgetriebener Aktuator, der innerhalb eines menschengeschriebenen Mandats handelt (M2), und als reservierte Klasse für einen künftigen Aktuator, der Ziele jenseits eines menschengeschriebenen Mandats setzt (M3). Ihr Trust ist ein fixer, versionierter Vektor von Bestätigungsdimensionen, Provenance, Integrität der laufenden Instanz gegenüber ihrem attestierten Artefakt, Verifizierungs- und Auditstatus, Erklärbarkeit und Datensouveränität, jeweils gelesen durch den Gate, der davon abhängt, statt zu einer Zahl gemittelt zu werden. Ihre Control erfasst, wie der Aktuator eingefangen werden kann: immutable, upgradeable oder governed, die Custody eines administrativen Schlüssels und die Recovery Surface, die verfügbar ist, wenn er fehlfunktioniert. Die vertrauten Labels, ein Bot, ein Smart Contract, ein Artificial-Intelligence-Agent, sind Regionen dieses Deskriptorraums statt Typen: Ein Bot und ein Smart Contract sind beide deterministisch (M1) und unterscheiden sich nur in Integrity und Control, ein On-Ledger Contract im Bytecode verifizierbar und ohne administrativen Custodian ausführend, wo ein Bot operator-attested und operator-held ist. Automated Contracting Instruments bestätigen, dass automatisierte Systeme an rechtlich relevanten Vertragsprozessen teilnehmen können, während Accountability weiterhin durch rechtliche Actors um das System herum aufgelöst wird.(United Nations Commission on International Trade Law 2024) Die Labels bilden eine Maschinenüberschrift, das Analogon zu den natürlichen und juristischen Klassen, und sind wie diese niemals Gate Input. Wo das Recht eine autoritative Klassifikation bereitstellt, mappt sie auf diese Achsen: Die Artificial-Intelligence-Risikoklasse der Europäischen Union ist eine Obergrenze für erlaubte Capability, während ihre Konformitätsbewertung und Benanntenstellen-Attestierung eine Source of Confirmation für den Trust Vector sind.(European Parliament and Council of the European Union 2024e, arts. 6, 43) Der rechtliche Endpunkt bleibt weiterhin ausserhalb von M. Zeitgenössische EU-Instrumente regulieren das System, indem sie Pflichten und Haftung rechtlichen Actors um es herum zuweisen, und das Europäische Parlament hat zivilrechtliche Haftung für AI-Systeme ausdrücklich so behandelt, dass sie rechenschaftsfähige Personen verlangt statt Rechtspersönlichkeit für das System selbst.(European Parliament 2020, para. 7) Das Modell folgt derselben Trennung: M kann technisch handeln, aber eine rechtlich relevante M-Operation wird über N+M, J+N+M oder einen eingeschränkten J+M-Pfad nur dort zugelassen, wo der geltende Rechtsrahmen direkte juristische Verantwortung, Recovery und Compensation bereitstellt.

Ein Smart Contract ist die kanonische Maschinenentität: deterministischer On-Ledger-Code, der durch seine eigene Adresse adressiert wird, Vermögenswerte hält und Wirkungen hervorbringt, ohne einen eigenen Willen zu haben. Eine Decentralised Autonomous Organisation ist eine Anwendung eines solchen Contracts, und sie zeigt den Typschnitt bei der Arbeit. Eine registrierte DAO liefert in einer Jurisdiktion, die einer solchen Organisation einen gesetzlichen Wrapper gibt, ein verklagbares Konstrukt mit eigenem Vermögen und ist eine juristische Entität, die durch eine Maschine handelt, wobei J+M durch einen rechenschaftsfähigen natürlichen Anchor als J+N+M für folgenreichen Betrieb vervollständigt wird.(Wyoming Legislature 2021, 2024) Eine wrapperlose DAO wirft andere Fragen auf; Enforcement- und Prozesspraxis können zu den Teilnehmenden durchgreifen oder die Vereinigung über die verfügbare prozessuale Kategorie behandeln.(Commodity Futures Trading Commission 2023) Das Modell erfasst diesen Grenzfall als Maschine, die an die Menge der natürlichen Personen angeschlossen ist, die sie kontrollieren, $\mathrm{M}+\{\mathrm{N}\dots\}$, zugestellt über die Contract-Adresse und verantwortbar über diese Kontrollpersonen, wo das geltende Recht diesen Weg erlaubt. Das Beispiel ist ein Designtest für die Taxonomie, keine Behauptung, dass alle Jurisdiktionen DAOs gleich auflösen.

Die Anschlussanforderung ist als Artefaktregel gegenüber dem Substrat indifferent. Eine Kontrollkette, die in keiner natürlichen Person und keinem treuhänderischen Accountability-Punkt endet, ist für Assurance-Zwecke ursprungslos, ob sie aus juristischen Hüllen oder autonomen Maschinen gebaut ist, und das Modell hält sie in beiden Fällen dormant. Beneficial-Ownership-Recht liefert den rechtlichen Druck für juristische Ketten; Quellen zu AI und automatisiertem Contracting liefern den rechtlichen Druck für maschinenvermittelte Handlungen.(Financial Action Task Force 2023, 2024; European Parliament and Council of the European Union 2024e; United Nations Commission on International Trade Law 2024) Wo eine Maschine jenseits eines im Voraus festgelegten Scope handeln kann, also eine modellgetriebene oder zielsetzende Maschine (M2 oder M3), ist Live Control oder Live Recovery erforderlich, bevor ihr aktive Capability gewährt wird, weil ihr Verhalten durch Aufsicht statt durch fixen Code begrenzt wird. Eine deterministische und immutable Maschine (M1) ist der einzige Fall, der ohne gegenwärtiges Mittel zum Anhalten handeln darf, da ihr gesamtes Verhalten bei Zulassung fixiert ist und eine Recovery- oder Liability Surface im Voraus auf den Schaden dimensioniert werden kann, den dieses begrenzte Verhalten verursachen kann. Live Control liefert, was Immutability bereits bereitstellt, nämlich eine Verhaltensgrenze vor der Handlung, und ist zwingend, wo Verhalten nicht so begrenzt werden kann.

Weil der Typ das rechtliche Regime festlegt, legt er auch fest, was offengelegt werden darf, und deshalb muss die Taxonomie exakt sein. Identifikation beweist, dass ein Accountability-Pfad existiert, dass eine Handlung die einer Maschine war, angeschlossen an eine natürliche Person, handelnd für eine juristische Entität, ohne eine von ihnen zu benennen, bis eine Handlung es verlangt; und wenn Namen verlangt werden, wählt der Typ das Regime aus, unter dem jeder Name freigegeben wird. Eine natürliche Entität wird unter dem Datenschutzregime ihrer geltenden Jurisdiktion offengelegt, als betroffene Person, deren Angaben minimiert und nur bei Bedarf herausgegeben werden. Im EU-Recht wird eine registrierte juristische Entität durch Handelsregistermechanik öffentlich offengelegt, während die DSGVO natürliche Personen schützt und juristische Personen ausserhalb ihres Data-Subject-Scope lässt.(European Parliament and Council of the European Union 2017)(European Parliament and Council of the European Union 2016, recital 14) Die natürlichen Personen hinter einer juristischen Entität behalten ihren Schutz, wenn die Entität gelesen wird: Der Gerichtshof der Europäischen Union erklärte den allgemeinen öffentlichen Zugang zu Beneficial-Ownership-Registern aus diesem Grund für ungültig und bewahrte Transparenz juristischer Entitäten, während die Personen in ihr Datenschutzinteressen behalten.(Court of Justice of the European Union 2022) Eine Maschinenentität legt ihren Anschlusspfad offen, der zu einer natürlichen oder juristischen Entität aufgelöst wird und dann durch das Regime dieser Entität gesteuert wird. Eine Einzelunternehmer:in bestätigt die Regel statt sie zu brechen: Eine natürliche Person, die unter einem registrierten Geschäftsnamen handelt, wird als natürliche Entität mit einer durch den Registrierungsakt hinzugefügten Offenlegungspflicht offengelegt, nicht als juristische umklassifiziert, weil Offenlegung dem Typ folgt, nicht der Tätigkeit.

Ein ausgearbeiteter Fehlerfall zeigt den Pfad, den die Taxonomie rekonstruiert. Angenommen, eine Maschine behandelt Informationen, die sie verarbeitete, falsch und verliert sie. Das System löst die Identität der Maschine auf und liest ihren Anschluss so, wie er zum Zeitpunkt der Handlung bestand, wodurch eine natürliche Person benannt wird. Diese Person handelte innerhalb eines gültigen Mandats als Organ einer juristischen Entität, daher rechnet die Spur die Folge zuerst der juristischen Entität zu, die Zweck und Mittel der Verarbeitung bestimmte, während Controller-Pflichten, Processor-Pflichten, Entschädigung und ein allfälliger interner oder persönlicher Regress anschliessend nach dem anwendbaren Datenschutz- und Organisationsrecht bewertet werden.(European Parliament and Council of the European Union 2016, arts. 4(7), 24, 28, and 82) Wäre die Maschine Drittsoftware gewesen, hätte der Anschluss stattdessen ihre Vendor-Organisation benannt, eine weitere juristische Entität, ohne einen neuen Typ einzuführen. Das Beispiel ist eine Assurance-Spur, kein vollständiges Haftungsurteil: Der Pfad wird aus dem zeitpunktbezogenen, haftungszugeordneten Record der Handlung unter dem Recht abgespielt, das galt, als die Handlung stattfand.

Jurisdiktionales Anchoring und zeitliche Zurechnung

Das multi-jurisdiktionale Design behandelt jurisdiktionales Anchoring als zeitindexiertes Attribut des Assurance-Zustands der Entität, das für einen Actor ausgewählt wird, wenn eine Handlung bewertet wird. Eine natürliche Entität kann zu einem Zeitpunkt in Österreich leben, später nach Kanada ziehen, die österreichische Staatsbürgerschaft behalten, einen Pass der Vereinigten Staaten besitzen, ein kanadisches Aufenthaltsartefakt hinzufügen und weiterhin denselben rechtlichen Identity-Assurance-Zustand verwenden. Der Zustand erfasst parallele jurisdiktionale Artefakte und die gültige Zeit jedes Artefakts, während die angeforderte Handlung den Anchor und die rechtlichen Prädikate auswählt, die für ihre Bewertung relevant sind.

Minimal formuliert sei $A_E(t)$ die Menge der jurisdiktionalen Artefakte, die für Entität $E$ zum Handlungszeitpunkt $t$ gültig sind. Der aktive Anchor für Handlung $a$ ist das ausgewählte Element

Dies trennt gespeicherte Tatsachen von jurisdiktionsrelativen Prädikaten. Ein Geburtsdatum, Adressartefakt, eine Staatsangehörigkeit, ein Aufenthaltsstatus, Steuerstatus, Registereintrag oder Mandat kann als Tatsache mit eigener gültiger Zeit gespeichert werden. Ob diese Tatsache den Actor volljährig, ansässig, autorisiert, berechtigt, reguliert, geschützt oder ausgeschlossen macht, ist ein Prädikat, das unter dem aktiven Anchor und dem geltenden Recht der angeforderten Handlung bewertet wird. Dieselbe Tatsache kann einen Gate in einer Jurisdiktion erfüllen und anderswo an einem anderen scheitern, ohne die Tatsache selbst zu ändern.

Account-gebundene Systeme verlieren diese Unterscheidung. Wenn ein Account dauerhaft an die Jurisdiktion gebunden ist, in der er erstellt wurde, werden spätere Lebensereignisse strukturell falsch dargestellt: Eine Person, die umzieht, kann so behandelt werden, als ob das ursprüngliche Land weiterhin alle Capability-Entscheidungen steuert, oder sie kann gezwungen sein, den Account aufzugeben und einen neuen zu erstellen. Rechtliche Identity Assurance trennt Entitätskontinuität von jurisdiktionalem Zustand. Die Entität bleibt über die Zeit dieselbe Trägerin des Assurance-Zustands, und der Actor bleibt in jeder Handlung der rechenschaftsfähige Punkt, während der aktive jurisdiktionale Anchor, Wohnsitz, Steuerstatus, Adresse, regulatorische Berechtigung und Capability-Prädikate sich ändern und prüfbar bleiben können.

Zurechnung trägt auch eine Uhr. Eine Handlung wird gegen den rechtlichen und Policy-Zustand bewertet, der zu dem für diese Handlung relevanten Zeitpunkt in Kraft ist, während ein späteres Audit unter einem anderen Record-Zustand und in einer anderen rechtlichen Umgebung stattfinden kann. Bitemporale Records, gültige Zeit neben Transaktions- oder Record-Zeit gehalten, halten diese Unterscheidung stabil über ein Leben, das zwischen Jurisdiktionen wechselt.(Jensen et al. 1992) Spätere Reliance-Records konsumieren diese Struktur: Sie können erneut abspielen, welche Artefakte gültig waren, welcher Anchor aktiv war und welche rechtlichen Prädikate die Handlung zum Zeitpunkt ihres Auftretens steuerten.

Anforderungen an multi-jurisdiktionale rechtliche Identity Assurance

Die vorangehende Herleitung liefert die Anforderungen, gegen die das Artefakt später bewertet wird. Sie werden erst nach Taxonomie und jurisdiktionalem Anchor formuliert, weil zwei von ihnen diese Konstrukte benötigen: Maschinenhandlung kann erst bewertet werden, wenn M als technischer Actor mit geliehener rechtlicher Accountability definiert ist, und jurisdiktionale Kontinuität kann erst bewertet werden, wenn die Anchor-Funktion eingeführt ist. Die Anforderungen sind Design Constraints. Eine Kandidatenarchitektur für Assurance erfüllt sie, wenn ihre Datenstrukturen, Gates und Reliance-Records die Constraint durchsetzen können, ohne sich allein auf institutionelle Gewohnheit zu stützen. Die Checkliste in 1 übersetzt diese Herleitung in sechs testbare Constraints und verbindet jede Anforderung mit ihrem rechtlichen oder Standardisierungsdruck sowie mit dem Konstrukt, das sie erfüllt.

Die Tabelle fixiert auch die Grenze zwischen der allgemeinen Assurance-Schicht und sektoraler Regulierung. Vereinfachte, standardmässige und verstärkte Sorgfaltspflichten zur Bekämpfung der Geldwäscherei werden als ein oberes Mapping über der Architektur behandelt. Sie liefern konkrete Gate-Prädikate, wo die angeforderte Capability in den AML-Bereich fällt, während das allgemeine Artefakt breiter bleibt: Es definiert die Entität, die Evidenzzellen, den jurisdiktionalen Anchor, den Gate und den Reliance-Record, die auch andere rechtliche Mappings konsumieren können.

Assertion-Granularität und Datenminimierung

Die Assertion-Achse wird zuerst gebaut, und sie wird von der Bedarfsseite her gebaut. Die Bedarfsmenge von Gl. 2 setzt voraus, dass eine Handlung die Tatsachen benennen kann, die sie verlangt, $R(a)$, und diese und nichts anderes erhält; die Achse muss granular genug sein, dass jeder rechtlich unterscheidbare Bedarf separat adressierbar ist. Die Einheit der Achse ist die Assertion Class: eine Art von Identitätsinhalt, den eine Entität offenlegen kann, ein Geburtsdatum, ein Kontaktkanal, ein bürgerlicher Name, ein staatliches Identitätsdokument. Eine Klasse ist eine Zeile des Katalogs des Typs, und der Katalog ist die vollständige geordnete Liste der Klassen, die der Typ zulässt.

Der rechtliche Treiber dieser Granularität ist Datenminimierung: Personenbezogene Daten müssen dem Zweck angemessen und erheblich sowie auf das für die Zwecke der Verarbeitung notwendige Mass beschränkt sein.(European Parliament and Council of the European Union 2016, art. 5(1)(c)) Die Pflicht ist gegenüber der sammelnden Stelle formuliert, aber die Datenstruktur entscheidet, ob die Pflicht durchsetzbar ist. Ein gepackter Identity Record, das einzelne «identity verified»-Objekt, das Name, Geburtsdatum, Adresse, Dokumentenscans und Biometrie als einen Block trägt, macht Minimierung in der Praxis undurchsetzbar: Ein Gate, der ein Element benötigt, erhält den Block, weil der Block das einzige adressierbare Objekt ist. Die gepackte Instanz setzt auch den Anreiz. Wo die Grenzkosten des Fragens null sind und der Record ganz ankommt, sammelt jeder Service das Maximum, und der Regulator bleibt dabei, Absichten statt Strukturen zu auditieren. Zeilengranularität kehrt dies um. Wenn jede Klasse ein separat offenlegbares Objekt ist, kann ein Gate eine Klasse nur anfordern, indem er sie benennt, eine nicht angeforderte Klasse ist strukturell nicht offengelegt statt durch Policy zurückgehalten, und Minimierung hört auf, ein Versprechen zu sein, und wird zu einer Eigenschaft des Adressraums.

Was auf die Achse gehört, wird durch einen zweiten Schnitt begrenzt: Die Grenze zwischen rechtlich erforderlicher und funktional benötigter Information verläuft entlang der Rolle des Actors in der Interaktion, nicht entlang des Datentyps. Dieselbe E-Mail-Adresse ist assurance-relevant, wo sie der bestätigte Kontaktkanal ist, auf den eine Recovery- oder Zustellpflicht angewiesen ist, und rein funktional, wo sie ein Newsletter-Feld ist; dasselbe Bild ist ein bestätigtes Abbild in einer Verifizierungszeremonie und gewöhnlicher Inhalt in einem Galerie-Upload. Funktionale Daten bleiben service-lokal und ausserhalb des Assurance-Zustands; der Katalog trägt nur Inhalte, die ein Gate-Prädikat oder rechtliches Mapping verlangen kann.

Die Zeilen sind nach Offenlegungsbereitschaft geordnet, nach den Offenlegungskosten, die die Entität trägt, nicht danach, wo die Evidenz lebt oder wie stark sie gemacht werden kann; Zeilen können sich innerhalb eines kleinen Bandes verschieben, wenn die Praxis lehrt, aber Zeilen verschmelzen nie, weil eine verschmolzene Zeile eine Adresse ist, die die Bedarfsmenge nicht mehr bilden kann. Zwei Zeileneigenschaften vervollständigen die Maschinerie. Die erste ist Optionalität: Genau eine Zeile jedes Katalogs ist obligatorisch, die mit der Taxonomie eingeführte Existenzstatus-Zeile, Zeile null jedes Typs, und jede andere Zeile ist freiwillig, wobei leer ein legitimer Zustand einer freiwilligen Zeile ist. Eine Entität, die nur ihre Statuszeile hält, ist eine willkommene teilnehmende Einheit, die nichts tun kann, was Trust verlangt: Die Untergrenze des Modells ist Präsenz ohne Verdacht, das strukturelle Gegenteil des Verdachts an der Tür im flachen Design. Die zweite ist Kardinalität: Eine Klasse lässt entweder einen Slot oder eine offene Menge von Instanzen zu. Ein bürgerlicher Name und ein Geburtsdatum sind Single-Slot; Kontaktkanäle, Adressen, staatliche Dokumente und Zahlungsrouten sind offene Mengen, weil eine Person legitimerweise mehrere davon hält.

Eine Open-Set-Klasse, die mehrere unabhängig bestätigte Instanzen hält, weist Artefaktmultiplikität auf, und die Lesart des Modells ist tragend: Mehr Artefakte derselben Klasse erhöhen die Bestätigung, nie den Level. Drei Pässe aus drei ausstellenden Staaten bleiben eine Klasse, das staatliche Identitätsdokument; was wächst, ist die Bestätigung dieser Klasse, weil drei Ausstellende keinen Failure Mode teilen, und die Bereitschaft, weitere Instanzen bereitzustellen, ist selbst ein Signal. Schreibt man $\mathcal{C}_E(r)$ für die Menge von Bestätigungen, die hinter den Artefakten stehen, die eine Entität $E$ bei Klasse $r$ hält, zählt der Confirmation Index

Source-of-Information-Skala

Die Source-of-Information-Achse ist die zweite Achse, auf der eine Zelle gelesen wird, und sie ist der Spiegel des Schnitts, der Entitäten typisiert. Wo die Entitätsachse fragt, wer für eine Handlung gehalten werden kann, fragt diese Achse, wer für eine Bestätigung gehalten werden kann, wie viel unabhängiges und rechenschaftsfähiges Gewicht hinter einer offengelegten Assertion steht. Sie misst nicht, ob das Subjekt vertrauenswürdig ist; das Wort Trust reservieren wir für die gate-seitigen Grössen, die aus Reliance abgeleitet werden. Sie sagt nur die evidenzielle Stärke der vorgelegten Assertion aus, und sie tut dies auf einer homogenen Skala, dargestellt in 2, die alle drei Entitätstypen teilen; je nach Typ unterscheidet sich, welche Confirmers bei einem gegebenen Element jede Klasse besetzen können, was mit den typspezifischen Katalogen entwickelt wird.

Die Skala hat das Selbst als ihre Untergrenze, weil eine Entität sich nicht selbst bestätigen kann. Eine selbst deklarierte Assertion ist Bereitstellung, nicht Verifizierung: Sie erfasst, dass das Subjekt es gesagt hat, was wahr oder falsch sein kann, per Design als unzuverlässig vermutet, und diese Vermutung ist die Prämisse, auf die das ganze System antwortet. Jeder Schritt oberhalb der Untergrenze fügt eine bestätigende Instanz hinzu, die vom Subjekt unabhängig ist und in einem gewissen Grad dafür einsteht, wenn die Bestätigung falsch ist, sodass die Skala durch die Accountability der bestätigenden Instanz ansteigt und nicht durch den Mechanismus, den sie verwendet. Eine Maschinenbestätigung (S2) ist unabhängig von der Behauptung des Subjekts, ein automatisierter Check, eine kryptografische Signatur, ein Liveness-Test, trägt aber nur die Accountability derjenigen Stelle, die sie deployed hat. Ihre Stärke folgt daher dem, was hinter dem Check steht, nicht der Tatsache, dass eine Maschine ihn durchgeführt hat.(National Institute of Standards and Technology 2025b; European Union Agency for Cybersecurity 2024) Eine Register-API-Bestätigung (S3) fragt die Source of Truth für die Tatsache ab und vergleicht: Welches Register das ist, variiert mit der Zeile, ein Einwohnerregister für Geburtsdatum oder bürgerlichen Namen, das Handelsregister für eine Gesellschaft, die Bank für ihre eigene Kontobeziehung, der Carrier für eine Nummer, jeweils eine Institution mit einer rechtlichen oder regulierten Record-Pflicht, diesen Record korrekt zu halten.(European Parliament and Council of the European Union 2017; Financial Action Task Force 2020) Eine menschliche Bestätigung fügt eine identifizierte, geschulte verifizierende Person hinzu, die auf den Check gehalten werden kann; eine notarielle oder qualifizierte öffentliche Bestätigung fügt eine rechtlich ermächtigte Amtsperson oder einen Trust-Service-Proofing-Kontext hinzu, dessen Attestierung in der relevanten Jurisdiktion oder im relevanten Scheme höheres rechenschaftsfähiges Gewicht trägt.(Hague Conference on Private International Law 1961; European Telecommunications Standards Institute 2025; United Nations Commission on International Trade Law 2022)

Die menschlichen und öffentlichen/qualifizierten Tiers teilen sich jeweils in eine digitale und eine In-Person-Klasse, und die Teilung ist kategorial, nicht darstellerisch. Eine Remote-Zeremonie und eine physisch kopräsente unterscheiden sich in der Angriffsfläche: Kopräsenz entfernt den Remote-Kanal, und sie verändert, was die verifizierende Person tun kann, ein Dokument in der Hand drehen statt es einer Kamera vorlegen, eine Person körperlich statt in Pixeln anwesend haben.(Goffman 1967; European Union Agency for Cybersecurity 2024; European Telecommunications Standards Institute 2025) Jede Klasse auf der Skala ist prinzipiell fälschbar, das ist die Prämisse, auf der das System ruht; ein verbleibender Angriff gegen eine Klasse, ein Deepfake gegen eine Remote-Zeremonie, wird in das evidenzielle Gewicht eingepreist, das eine Relying Party aus der Zelle ableitet, nie verwendet, um die Klasse kollabieren zu lassen, weil Kosten, rechtliche Exposition und Aufwand pro Account, ihn auszuführen, Teil dessen sind, was die Klasse wert ist. Die daraus resultierende Ordnung ist S4 menschlich digital, S5 menschlich in person, S6 öffentlich oder qualifiziert digital, S7 öffentlich oder qualifiziert in person: Innerhalb jedes Tiers steht Kopräsenz über dem Remote-Kanal, während die rechtliche Accountability der Amtsperson oder der qualifizierten bestätigenden Instanz den trained-human Tier übertreffen kann, sodass die in-person human verification weiterhin unter der digitalen öffentlichen oder qualifizierten Klasse steht, wo die geltende Jurisdiktion oder das geltende Scheme diese Attestierung anerkennt.

Self (S1), machine (S2), register API (S3), human digital (S4), human in person (S5), public or qualified digital (S6) und public or qualified in person (S7) sind benannte Klassen dieser Skala, geordnet nach dem rechenschaftsfähigen Gewicht, das hinter der Bestätigung steht, nicht nach dem Mechanismus, den sie verwendet. Ein Gate kann entweder eine Untergrenze verlangen, mindestens S3, oder eine spezifische Source-Art, wo der Mechanismus zählt. Zwei Unterscheidungen liegen unter der einzelnen Koordinate. Die erste ist jene zwischen Source of Truth und Source of Confirmation: Ein autoritatives Register ist der kanonische Ursprung einer Tatsache, während eine öffentliche oder qualifizierte bestätigende Instanz einen vorgelegten Claim dagegen verifiziert; das Modell behandelt beide als rechenschaftsfähiges Gewicht hinter der Zelle und privilegiert keine Form. Die zweite ist Binding: Eine Bestätigung ist nur so stark wie ihre Verbindung zu diesem Subjekt und dieser Instanz, daher komponiert jede Klasse die Accountability der Source mit der Stärke des Binding zwischen der bestätigten Tatsache und der Entität am Gate. Ein Registereintrag, der nicht an die vorlegende Partei gebunden werden kann, bestätigt eine Tatsache über jemanden, nicht über den Actor.

Drei Regeln hängen an der Register-API-Klasse, und die erste reicht über sie hinaus. Ein Confirmation Event versiegelt genau die Zeilentatsachen, die der bestätigende Akt geprüft hat, nie einen Indexbereich: Ein Registeraufruf, der ein Geburtsdatum, einen bürgerlichen Namen, ein Abbild und eine Dokumentennummer gegen den Record validiert, füllt die S3-Zelle jeder dieser Zeilen in einem einzigen Event, genauso wie ein öffentlicher oder qualifizierter In-Person-Akt die Tatsachen abdeckt, die das vorgelegte Dokument trägt. Zellen, die durch ein Event gefüllt werden, sind korreliert, ein Aufruf, ein Failure Mode, daher zählen sie im Confirmation Index von Gl. 5 nie als unabhängige Bestätigung, und sie ziehen sich gemeinsam zurück, wenn sich das Event selbst als gespooft erweist. Zweitens hat die Klasse zwei Formen. Ein Data Pull fragt das Register über jemanden ab und bestätigt die Tatsache, ohne eine vorlegende Person zu binden; ein holder-triggered Connect, eine Wallet-Bestätigung oder eine Electronic-Identity-PIN lässt das Subjekt aus seiner eigenen Kontrolle heraus in das Register greifen und liefert Source und Sole-Control-Binding in einem Akt. Beide sind eine Klasse, wobei das Binding im Confirmation Event erfasst wird. Wo der Record ein Referenzabbild hält, liefert das Register die Tatsache, während der Live-Abgleich der vorlegenden Person dagegen ein Maschinenakt (S2) bleibt; die zwei Zellen bleiben getrennt. Drittens ist eine Bestätigung eine Handlung, und eine Partei, die im System nicht gehandelt hat, hat in ihm nichts bestätigt. Ein externer Verification Provider tritt auf eine von zwei Arten ein: als Issuer, der Confirmation Events übermittelt, die die Klasse des zugrunde liegenden Checks erben, die er dokumentieren kann, und die nicht mehr wert sind als ihr schwächstes verifizierbares Glied; oder als geschulte menschliche verifizierende Instanz von S4 und S5, wenn er die Person tatsächlich bestätigt, statt Fakten über eine Person weiterzuleiten.

Zwei Regeln folgen daraus, Stärke als rechenschaftsfähiges Gewicht zu lesen. Eine Bestätigung, die aus mehreren Gliedern zusammengesetzt ist, ist nur so stark wie ihr schwächstes erforderliches Glied, dieselbe Weakest-Link-Regel, die die inheritance bound steuert, sodass ein notariell beglaubigtes Dokument, das auf einem unverifizierten zugrunde liegenden Claim ruht, nicht stärker ist als dieser Claim. Und Bestätigung kaskadiert: Eine höhere Source kann das Ergebnis einer niedrigeren attestieren, eine öffentliche oder qualifizierte bestätigende Instanz attestiert, dass eine menschliche Instanz einen Maschinencheck verifiziert hat. Dadurch kann die Skala eine Kette von Bestätigungen in einen einzelnen rechenschaftsfähigen Punkt teleskopieren.

Die Skala ist für alle drei Entitätstypen ein und dieselbe; nur die Confirmers, die jede Klasse besetzen können, ändern sich mit dem Typ. Das Register of Record bei S3 ist ein Einwohnerregister für eine natürliche Entität und das Handelsregister für eine juristische; die öffentliche oder qualifizierte bestätigende Instanz bei S7 attestiert die Urkunde einer Person oder das Instrument einer Gesellschaft in physischer Anwesenheit, wo diese Funktion verfügbar ist. Eine Maschinenentität wird durch die Confirmers bestätigt, die ihre Deskriptoren auf derselben Skala zulassen: Eine kryptografische Attestierung des laufenden Artefakts ist eine Maschinenbestätigung (S2), eine Konformitätsbewertung oder Benanntenstellen-Attestierung eine Registerbestätigung (S3), ein unabhängiges Audit eine accountable human verification (S4, S5) und eine notarielle, Public-Officer- oder qualifizierte Mandatsbestätigung eine Public or Qualified Confirmation mit hoher Accountability (S6, S7). In jedem Katalog ist eine Zelle dort, wo für ein Element keine Source einer gegebenen Klasse existiert, unanwendbar statt gescheitert: Ein biometrisches Muster hat kein autoritatives Register, ein nicht registrierter Verein keinen Handelsregistereintrag, eine staatenlose Person keine nationale Identitätsquelle. Das Modell erfasst dies als vollwertigen Leerwert, unterschieden von einem unbestätigt gelassenen Element, sodass eine Entität Assurance durch die ihr verfügbaren Klassen erreicht, statt für die Abwesenheit einer Klasse bestraft zu werden, die sie nie verwenden könnte. Dies erlaubt der abgestuften Skala, Teilnehmende aufzunehmen, die eine flache Maximalverifizierungsgrenze ausschliessen würde, und es ist die in der Related Work vorweggenommene Regel: Assurance bleibt durch den stärksten anerkannten nicht-souveränen Bestätigungskanal erreichbar, der für die relevante Tatsache und Jurisdiktion verfügbar ist, sodass ein souveränes Scheme den Zustand beschleunigt, ohne je Vorbedingung dafür zu sein.

Assertion-Kataloge pro Typ

Der natürliche Katalog ist die Entwicklungswurzel, und seine Zeilen werden abgeleitet, indem die Ordnung der Offenlegungsbereitschaft von der Untergrenze aufwärts durchlaufen wird; jede Zeile wird aufgenommen, weil ein Gate-Prädikat oder eine rechtliche Zuordnung sie verlangen kann und weil sie separat offenlegbar ist. N0, die Statuszeile, ist der obligatorische Existenzanker: Sie hält fest, dass die Entity existiert und ob sie lebt oder verstorben ist, den Grundfakt, den jede andere Zeile voraussetzt, und die einzige Zeile, die eine blosse teilnehmende Entity ausfüllen muss. N1, das Geburtsdatum, ist der kostengünstigste rechtlich folgenreiche Fakt, da Altersprädikate die häufigsten gesetzlichen Gates sind und der Fakt, sobald er bestätigt ist, nicht verfällt. N2, Kontaktkanäle, eine offene Menge, trägt die Erreichbarkeit, das operationelle Minimum der Teilnahme, und ist durch einen Kontrollnachweis bestätigbar. N3, der zivile Name, ein einzelner Slot, ist der koordinierende Identifier, den die täuschungsfreie Grenze bewahrt hat: Er unterscheidet Parteien voneinander und gilt, bis ihn ein rechtliches Event ändert. N4, Adressen zusammen mit dem jurisdiktionalen Anker, eine offene Menge, bindet die Entity an die rechtlichen Rahmen der obigen Untersektion zur jurisdiktionalen Verankerung. N5, das Personenbild, eine offene Menge, ist das Binding-Substrat von Verifikationszeremonien und die Zeile mit der höchsten Freshness-Sensitivität. N6, staatliche Identitätsdokumente, eine offene Menge, enthält die zusammengesetzten Artefakte, die ein Staat ausstellt; jedes Dokument ist eine Instanz, separat bestätigt, und die Claims, die ein Dokument trägt, ein Geburtsdatum, ein Name, bleiben Claims ihrer eigenen Zeilen. N7, Zahlungsdetails, und N8, Zahlungsschnittstellen, sind unterschiedliche offene Mengen, weil ihre Bestätigungsinstanzen und Fehlermodi verschieden sind: Eine Bankbeziehung wird durch die regulierte Institution bestätigt, die sie hält, eine Verbindung zu einer Zahlungsschnittstelle durch Kontrollnachweis gegenüber dem Provider. N9 und N10, Stimm- und Gesichtsmuster, schliessen den Katalog ab: Biometrische Muster stehen zuletzt, weil ihre Offenlegungskosten am höchsten und am wenigsten reversibel sind, und sie zeigen die unzutreffende Zelle, da kein Register of Record sie hält. 2 stellt den Katalog der Quellenskala gegenüber.

Der juristische Katalog folgt derselben Konstruktion über die Elemente, welche die Taxonomie bereits identifiziert hat. Seine Zeile null, J0, hält fest, ob die Entity aktiv, aufgelöst, suspendiert oder in Insolvenz ist, obligatorisch wie jede Existenzstatus-Zeile. J1 hält den rechtlichen Namen fest, unter dem die Entity angesprochen wird. J2 hält Rechtsform und anwendbares Recht fest, weil Gesellschaft, Verein, Stiftung, Personengesellschaft, öffentliche Körperschaft und Trustee-zugerechnete Gestaltung sich nach Rechtsform unterscheiden und nicht nach Typ. J3 hält das Gründungsinstrument oder den konstitutiven Akt fest. J4 hält das Register, das öffentlich-rechtliche Instrument oder die anerkannte registerlose Grundlage fest, die die Entity verankert. J5 hält Organe, Ämter, Vertretungsbefugnisse, Trustees oder andere autoritätstragende Positionen fest. J6 hält Zweck, Fähigkeit und Aktivitätsgrenzen fest. J7 hält die rechenschaftspflichtigen natürlichen Personen, wirtschaftlich Berechtigte, Kontrollierende, Partner:innen, Trustees oder treuhänderische Amtsträger:innen hinter der Entity fest.(Europäisches Parlament und Rat der Europäischen Union 2017; Financial Action Task Force 2023, 2024) 3 macht diese rechtlichen Adressierungselemente zu Zeilenadressen, sodass ein Gate Evidenz für Organisationsstatus, Autorität, Fähigkeit oder Kontrollpfad verlangen kann, ohne die juristische Entity so zu behandeln, als ob sie selbstständig handelte.

Die juristische Tabelle fixiert Zeilenadressen, aber sie lässt einen juristischen Actor nicht allein handeln. Das Kompositum bleibt ausserhalb der Zeilenliste. Ein Gate über J liest die J-Zellen der Entity, die N-Raster der relevanten natürlichen Personen und die Delegations- oder Amtsbeziehung, die sie unter der Vererbungsgrenze von Gl. 3 verbindet. Der Registerparameter bleibt ebenfalls ein Parameter und keine Typaufspaltung: Wo ein Handelsregister existiert, ist es die gewöhnliche S3-Quelle für Zeilen wie J0, J1, J2, J4 und J5; wo die juristische Form eine öffentliche Körperschaft, Stiftung, Personengesellschaft, ein Verein oder eine trust-ähnliche Rechtsgestaltung ist, ist die Quelle das zuständige öffentliche Instrument, Aufsichtsregister, der Trustee-Datensatz oder der vom anwendbaren Recht anerkannte treuhänderische Nachweis. Eine Zelle, deren Quellenklasse für diese Form nicht existieren kann, wird als unzutreffend statt als fehlgeschlagen markiert.

Der Maschinenkatalog ist kürzer, weil die Maschine keinen Katalog von Lebensfakten hat. M0 hält Existenz, Zulassungsstatus und Anbindungspfad fest: aktiv, aufgegeben, gesperrt, suspendiert oder ausgemustert, zusammen mit dem Accountability-Pfad, der die Maschine enthält, N+M, J+N+M oder der eingeschränkte J+M-Pfad, wenn das anwendbare Rahmenwerk direkte juristische Verantwortung für die Handlungen der Maschine bereitstellt. M1, M2 und M3 sind Capability-Zeilen und bewahren die Capability-Klassen, die bereits in der Taxonomie eingeführt wurden. M1 ist ein deterministischer Aktuator, dessen Entscheidungspfad keine Modellinferenz enthält. M2 ist ein modellgetriebener Aktuator, der innerhalb eines menschlich verfassten Mandats handelt. M3 ist eine reservierte zielsetzende Klasse für einen Aktuator, der Ziele jenseits eines menschlich verfassten Mandats setzt. Jede Maschinenzeile trägt zwei Deskriptoren als Zellmetadaten, nicht als zusätzliche Zeilen: einen Trust Vector, Provenienz, Artefaktintegrität, Audit-Status, Erklärbarkeit und Data-Sovereignty-Claims; und einen Kontrollvektor, Unveränderlichkeit, Upgrade-Autorität, administrative Custody, Live-Aufsicht, Live-Wiederherstellung und Recovery Surface. 4 macht diese Einschränkung sichtbar, indem es den Anbindungspfad in M0 setzt und die übrigen Zeilen als Capability-Evidenz behandelt, die Gates nur durch eine zulässige Konstellation akzeptieren dürfen.

Diese Zeilenzuweisung hält die Maschinendefinition mit dem zuvor vorgebrachten rechtlichen Punkt ausgerichtet. M0 ist obligatorisch, weil eine aktive Maschine offenlegen muss, wo Verantwortung anknüpft, bevor ihre Ausgabe rechtlich relevant sein kann. M1 lässt sich durch Analyse festen Verhaltens vor der Zulassung begrenzen. M2 braucht Evidenz zu Mandat, Aufsicht und Wiederherstellung, weil ihr Verhalten durch einen Betriebsrahmen statt durch festen Code begrenzt wird. M3 bleibt im Katalog reserviert, damit künftige zielsetzende Systeme eine Adresse haben, während gegenwärtige Gates aktive Capability ablehnen können, bis das anwendbare Rahmenwerk Rechenschafts-, Kontroll- und Wiederherstellungsbedingungen bereitstellt. Bestätigung läuft auf der gemeinsamen Quellenskala über die Bestätigungsinstanzen, die die Zeile zulässt: Artefaktprüfungen bei S2, Register oder Konformitätsstellen bei S3, Audits bei S4 und S5, und notarielle, amtliche oder qualifizierte Mandatsbestätigungen bei S6 und S7.(Europäisches Parlament und Rat der Europäischen Union 2024e, 2024b; Europäisches Parlament 2020; Kommission der Vereinten Nationen für internationales Handelsrecht 2024)

Legal Identity-Assurance Coordinate und Event-Modell

Die erste Achse ist kein moralischer oder verhaltensbezogener Score. Sie ist eine offengelegte Identity-Scope-Achse. Für eine natürliche Entität stellt N0 bis N10 den Umfang von Identity Assertions dar, die für einen konkreten Capability-Kontext verfügbar sind, von ihm verlangt werden und in ihn offengelegt werden. Sie verbindet vier Designfakten: was das Gate verlangt, was das anwendbare Recht oder die regulatorische Zuordnung verlangt, was die Entität in den vom Holder getragenen Assurance-Zustand eingebracht hat und was die Entität für die Offenlegung in der jeweiligen Presentation freigibt. Bereitstellung und Offenlegung bleiben getrennt: Eine Entität kann ein Artefakt in der Wallet halten, ohne es gegenüber einem Relying Service offenzulegen.

Die zweite Achse ist die Source-of-Information-Achse. Sie fragt, wie verlässlich die offengelegte Assertion sein könnte, gegeben wer oder was hinter ihr steht. Ein selbst angegebenes Geburtsdatum auf S1 kann wahr oder falsch sein; das Modell zeichnet es als mit Eigenprovenienz versehen auf, nicht als extern bestätigt. Eine öffentliche oder qualifizierte Confirmation des Geburtsdatums auf S7 trägt einen anderen Beweisstatus, weil eine rechtlich verantwortliche Confirmation Source dahintersteht. Die Source-Achse behauptet nicht, dass die handelnde Entität vertrauenswürdig ist. Sie benennt die Beweisstärke der offengelegten Assertion.

Die kombinierte Coordinate ist als niedrige oder hohe offengelegte Assurance zu lesen, nicht als gute oder schlechte Identität. N1S1 ist ein legitimer Zustand: Die Entität kann neu aufgenommen sein, keinen Grund haben, mehr offenzulegen, stärkere Artefakte halten, ohne sie offenzulegen, oder tatsächlich gefälscht sein. Die Systemantwort ist Capability Containment statt Bestrafung. Eine Entität mit niedriger offengelegter Assurance kann im System existieren, während sie Capabilities nicht ausüben kann, deren rechtliche oder operative Folgen stärkere Attribution verlangen, etwa unaufgeforderte Kontaktaufnahme, öffentliches Posten, Geschäftsabschluss, Zahlung oder Asset-Bewegung.

Jurisdiktionsübergreifende Artefakte sind Instanzen dieses Modells, keine Ausnahmen davon. Eine natürliche Entität kann ein EUDI-Artefakt für personenbezogene Identifikationsdaten, einen Reisepass der Vereinigten Staaten, ein Identitätsdokument eines US-Bundesstaates, ein österreichisches Adressartefakt, ein kanadisches Wohnsitzartefakt, Nachweis über Bankkontrolle oder andere jurisdiktionale N-Instanzen halten. Der Legal Identity-Assurance-Zustand speichert diese Artefakte und ihre zeitliche Gültigkeit, während ein Capability Gate nur das signierte Package konsumiert, das für die angeforderte Handlung unter der relevanten jurisdiktionalen und regulatorischen Zuordnung benötigt wird.

Die beiden Achsen fügen sich zu einer einzelnen Coordinate pro offengelegter Assertion zusammen, der Zelle, und der Assurance-Zustand einer Entität ist die Menge der Zellen, die sie gefüllt hat, wobei ein Assertion-Item bei einer Source bestätigt ist. Weil eine starke Zelle eine fehlende nicht ersetzen kann, ist der Zustand eine Menge, kein aufsummierter Score.

Formal ausgedrückt trägt eine Entität $E$ vom Typ $T$ den Katalog $R_T$, und ihr Assurance-Zustand ist das binäre Grid

Ein Tier ist schliesslich ein Wert, den ein Gate aus dem gesamten gefüllten Grid gegen seine deklarierte Schwelle ableitet, nie eine Eigenschaft, die das Grid speichert, und nie eine einzelne Zelle, die als Rang gelesen wird. Diese Disziplin lässt sich am besten verteidigen, indem man ihre Alternative zeigt. Die Assurance-Designs, die in der Evaluation verglichen werden, lassen sich als Faltungen des Grids in Gl. 6 lesen: Projektionen, die Zeilen zu Bündeln zusammenführen, Spalten zu einem verified bit zusammenführen oder die Diagonale des Grids als eine geordnete Leiter von Levels lesen, wie in 3 gezeichnet.(European Commission 2015; National Institute of Standards and Technology 2025a, 2025b; Sporny et al. 2025) Eine Faltung ist keine ordentlichere Darstellung derselben Information. Jede Faltung löscht die Adressierbarkeit einer bestimmten Familie von Zellen und damit einen Demand, den Gl. 2 sonst ausdrücken könnte; 5 benennt die wichtigsten Faltungen und die Capability, die jede davon amputiert.

Die Faltungen sind auch der Grund, warum der Assurance-Zustand als das Grid selbst getragen werden muss und nicht als abgeleitete Zusammenfassung: Eine Zusammenfassung, die Zeilen, Spalten oder Zellenprovenienz kollabiert, ist eine Faltung, und jede Faltung zahlt mit einer benannten Capability. Die Vergleichsmodelle der Evaluation unten, der flache einzelne Balken und die Level-Leiter pro Credential, sind die erste und die letzte institutionalisierte Faltung. Genau das macht den Vergleich zu einem Test der Struktur und nicht einer bestimmten Parametereinstellung.

Das Grid ist nur wiederverwendbar, wenn seine Zellen Provenienz als Events tragen und nicht als lose Dokumentattribute. Ein Confirmation Event ist der signierte Record, mit dem eine Source eine oder mehrere Zellen von $G_E$ füllt. Er zeichnet auf, was geprüft wurde, welche Source Class die Prüfung ausgeführt hat, wie die geprüften Fakten an die Entitätsinstanz binden, wann der zugrunde liegende Fakt gültig war, wann die Prüfung in den Assurance Record einging, welcher Status- oder Widerrufskanal ihn regelt und welche Policy Version die bestätigende Stelle angewandt hat. Verifiable-Credential- und Presentation-Standards liefern das Substrat für Credential, Proof, Status und Holder Presentation; das Assurance Event fügt darum die zellbezogene Source- und Binding-Semantik des Beitrags hinzu.(Sporny et al. 2025; World Wide Web Consortium 2025b, 2025a; OpenID Foundation 2025) Das implementierungsnahe Feldset in 6 ist bewusst Event-zentriert: Es bewahrt genug Source-, Binding-, Timing-, Status- und Proof-Kontext, um später an einem Gate erneut abzuspielen, warum eine Zelle akzeptiert wurde.

Das Event fixiert auch Korrelation. Wenn ein Confirmation Event vier Zellen füllt, teilen diese vier Zellen dieselbe Source, Ceremony, Policy Version und denselben Failure Mode. Sie können vier unterschiedliche Row Demands erfüllen, aber sie können nicht als vier unabhängige Confirmations zählen. Das ist die formale Version der Coverage-Regel, die in der Source Scale formuliert wurde: Das Event versiegelt, was der bestätigende Akt geprüft hat, und es entzieht oder schwächt dieselben abgedeckten Zellen, wenn sein Proof, Status oder seine Authority später scheitert. Corroboration zählt über unabhängige Confirmation Events hinweg, nicht über die Anzahl der Fakten, die ein einzelnes Event getragen hat.

Über Events gelesen ist der Confirmation Index in Gl. 5 ein Quotient über Event-IDs. Sei $C_E(r,s)$ die Menge der Confirmation Events, die Zelle $(r,s)$ füllen, sodass $(r,s) \in G_E$ genau dann gilt, wenn $C_E(r,s)$ nicht leer ist. Es gelte $e \sim e'$, wenn zwei Events eine bestätigende Stelle, Ceremony, Custody Path, Status Authority oder einen Proof Failure Mode teilen. Die Row-Level-Corroboration-Anzahl ist dann

Ein Reliance Event ist das konsumseitige Gegenstück. Es zeichnet auf, dass ein Relying Service eine Presentation für einen konkreten Akt unter einem deklarierten Gate akzeptiert oder zurückgewiesen hat. Das Confirmation Event beantwortet, was hinter der Evidence stand; das Reliance Event beantwortet, wer sich darauf verlassen hat, für welche Capability, unter welchem Recht und welcher Gate Version, mit welcher Akteurskonstellation und mit welcher Liability Boundary. Temporale Datenbankterminologie trennt den Zeitpunkt, zu dem die zugrunde liegenden Fakten gültig waren, vom Zeitpunkt, zu dem der Reliance Record geschrieben wurde. So wird späteres Replay möglich, ohne vorzugeben, dass der spätere Rechts- oder Datenzustand bereits zur Aktzeit wahr gewesen sei.(Jensen et al. 1992) 7 spiegelt die Confirmation-Event-Tabelle auf der konsumierenden Seite, sodass Wiederverwendung einen konkreten Record der Entscheidung, des Gates, des präsentierten Package und der Verantwortungsgrenze hinterlässt.

Das Reliance Event ist auch die Privacy Boundary. Datenschutzrecht verlangt rechtmässige, zweckgebundene, minimale Verarbeitung by Design, während Anti-Money-Laundering-Recht Reliance auf Dritte erlaubt, ohne die letztendliche Verantwortung von der verpflichteten Entität wegzuverschieben.(European Parliament and Council of the European Union 2016, arts. 5, 6, and 25)(European Data Protection Board 2020)(European Parliament and Council of the European Union 2015, arts. 25–27)(Financial Action Task Force 2025, rec. 17) Die Event-Struktur beantwortet beide Anforderungen: Die Relying Party erhält nur die Presentation, die ihr Gate deklariert hat, aber der Record bewahrt dennoch genug Source-, Status-, Zeit-, Rechts- und Verantwortungsmetadaten, um später zu zeigen, warum die Capability gewährt oder verweigert wurde.

Capability-Gate-Grammatik und Assurance-Trennbarkeit

Diese Rahmung trennt Identity Assurance von Capability. Identity Assurance beschreibt den wiederverwendbaren Zustand der handelnden Entität: Assertions, Confirmation Sources, Jurisdictional Anchor, Freshness, Revocation und zeitliche Gültigkeit. Capability Gating beschreibt eine konsumierende Entscheidung: ob dieser Zustand eine deklarierte Regel für eine konkrete Interaktion erfüllt. Derselbe Zustand einer handelnden Entität kann ein Kommunikations-Gate mit geringer Offenlegung bestehen, an einem Banking-Gate scheitern und später für ein Audit nach der zu diesem Zeitpunkt geltenden Rechts- und Policy-Version wiedergegeben werden.

Dieselbe Prämisse diszipliniert auch die Proxy-Nutzung im Gate-Design. Netzwerkursprung, Gerätehistorie, Contact Handles, Public-Profile-Spuren oder Plattformzugehörigkeit können in einigen Domänen operationale Signale sein, aber der rechtlich relevante Zustand wird durch Person, juristische Entität, Mandat, Credential, Transaktion und Conduct Record getragen. In einem Modell für Legal Identity Assurance sollten Gate-Prädikate an diese rechtlich relevanten Objekte anknüpfen. Das Fehlen von nicht verlangten Daten ist ein neutraler Zustand, kein allgemeiner Verdachtsmarker. Wenn eine nachteilige Entscheidung getroffen wird, sollte der Datensatz die Reason Category, Evidence Class, anwendbare Regel und den Appeal- oder Recourse-Pfad offenlegen, damit Accountability erreichbar bleibt, ohne routinemässige Offenlegung auszuweiten. Dies richtet die Architektur an den Pflichten zu rechtmässiger Grundlage, Fairness, Transparenz, Zweckbindung, Datenminimierung und Datenschutz durch Technikgestaltung im Datenschutzrecht aus.(European Parliament and Council of the European Union 2016, arts. 5, 6, and 25)(European Data Protection Board 2020)

Capability Gates bewerten Akteurskonstellationen, nicht nur isolierte Akteurstypen. Eine Konstellation erfasst, welche Entitäten an einer Operation teilnehmen und welche Relation die Operation zurechenbar macht: eine natürliche Entität, die allein handelt, eine juristische Entität, die durch eine verantwortliche natürliche Entität handelt, eine juristische Entität, die durch einen natürlichen Anchor und eine maschinelle Entität handelt, oder eine natürliche Entität, die mit einer maschinellen Entität handelt. Die relevante Frage ist, wie stark eine handelnde Entität identifiziert ist und ob die angeforderte Operation durch die eingereichte Konstellation überhaupt ausgeführt werden darf.

Die Standardgrammatik der Zulässigkeit unterscheidet sechs Konstellationsmuster. Muster A, N, ist eine natürliche Entität, die allein handelt, und ist zulässig, wo der Dienst individuelles Handeln akzeptiert. Muster B, J+N, ist eine juristische Entität, die durch eine verantwortliche natürliche Entität handelt, und ist die gewöhnliche Form für organisationale Capability. Muster C, J+N+M, ist eine juristische Entität, die durch einen natürlichen Anchor und eine maschinelle Entität handelt, und ist das Standardmuster für verantwortliche organisationale Automatisierung. Muster D, N+M, ist eine natürliche Entität, die eine maschinelle Entität nutzt oder an sie delegiert, und ist dienstabhängig. Muster E, J+M, ist technisch möglich, in diesem Artefakt aber rechtlich beschränkt und wird nur dort zulässig, wo das geltende Recht und Recovery-Mechanismen direkte juristisch-maschinelle Handlungen unterstützen. Muster F, M, ist in diesem Artefakt als eigenständige aktive Entität unzulässig, weil maschinelles Handeln ohne Imputation Anchor Systemeffekte ohne hinreichenden Verantwortungspunkt erzeugt.(European Parliament and Council of the European Union 2024e, 2024b; European Parliament 2020; United Nations Commission on International Trade Law 2024)

Diese Grammatik gilt auch für das Assurance-System selbst. Eine vom Assurance Provider betriebene aufsichtliche oder koordinierende System-AI wird als J+N+M dargestellt: der Provider als juristischer Operator, eine verantwortliche natürliche Rolle oder Stelle als Control Anchor und die maschinelle Entität als operationale Komponente. Dieselbe Regel, die für externe handelnde Entitäten gilt, steuert interne Automatisierung, sodass das System von anderen verankertes Handeln verlangt und seine eigene Automatisierung durch dieselbe Accountability-Form offenlegt.

Gates können dann als dienstspezifische Bündel deklariert werden. Ein High-Risk-Asset- oder Vertragsdienst kann für natürliche Beteiligte eine minimale Legal-Identity-Assurance-Coordinate wie EAID-N8-S4 verlangen und nur N-, J+N- und J+N+M-Konstellationen akzeptieren, während N+M, J+M und M für diese Operation ausgeschlossen werden. Ein Chat-Dienst mit niedrigem Risiko kann nur EAID-N2-S1 verlangen und N, N+M und J+N+M zulassen, während eigenständiges M weiterhin ausgeschlossen bleibt. Das Gate gibt sowohl den minimalen Assurance-Zustand als auch die zulässige Konstellationsfamilie für die angeforderte Operation an.

Ein Gate ist ein deklariertes Bündel $g = (D(g), \mathcal{K}(g), \ell(g))$: ein Demand Set im Sinn von Gl. 2, je Anforderung um ein Höchstalter erweitert, eine zulässige Konstellationsfamilie $\mathcal{K}(g)$ und das Governing Law $\ell(g)$, unter dem seine Prädikate zum Prüfzeitpunkt bewertet werden. Sei $\kappa(a)$ die eingereichte Konstellation für Act $a$. Eine Präsentation besteht zum Zeitpunkt $t$, wenn die Konstellation zugelassen ist und jede verlangte Zelle stark genug und frisch genug gehalten wird,

Die Freshness-Klausel aus Gl. 8 trennt zwei Zustände, die ein einzelnes Verification Flag verschmilzt: gültig und eligible. Ein Artefakt ist gültig, wenn es echt ist, auf der Uhr seiner ausstellenden Stelle nicht abgelaufen ist und sein Confirmation Event real ist. Es ist an einem Gate eligible, wenn die Confirmation zusätzlich innerhalb des Freshness Window dieses Gates liegt $\Delta$. Ein vor acht Monaten notariell beglaubigtes Regierungsdokument ist in jeder Hinsicht gültig und an einem Kontoeröffnungs-Gate, dessen Recht eine höchstens sechs Monate alte Verifikation verlangt, trotzdem nicht eligible. Ein vor zwanzig Jahren bestätigtes Geburtsdatum bleibt überall eligible, weil der Fakt nicht abläuft und kein Fenster gegen ihn deklariert ist. Eligibility ist ein Relying-Party-Prädikat über Coordinate und Freshness zusammen, nie ein auf der Zelle gespeichertes Flag: Die Zelle zeichnet auf, wann jede Confirmation stattgefunden hat, und jedes Gate entscheidet, was als frisch genug zählt.

Daraus ergibt sich eine weitere Unterscheidung zwischen Evidence Disclosure und Assurance Disclosure. Ein Capability Gate erhält das signierte Paket, das zur Erfüllung seiner deklarierten Anforderung nötig ist, und die Lower-Tier-Inclusions, von denen dieses Paket abhängt, unter Nutzung von holder-presented Credential- und Proof-Mechanismen statt eines Bulk Disclosure Record.(Sporny et al. 2025; World Wide Web Consortium 2025b; OpenID Foundation 2025) Wenn ein Gate EAID-N4-S5 verlangt, erhält der relying Service die N4-S5-Präsentation, ihre Provenance, Freshness, Validity, Source Class und die eingeschlossenen Lower Assertions, die nötig sind, um N4 aussagekräftig zu machen. Er erhält nicht einfach deshalb Higher-Tier-Evidence, weil die handelnde Entität sie hält, denn das Gate hat keinen rechtlichen oder funktionalen Grund für diese höhere Offenlegung deklariert.

Eine handelnde Entität kann sich dennoch entscheiden, eine Assurance Ceiling offenzulegen. Die Ceiling Statement besagt, dass ein stärkerer wiederverwendbarer Assurance-Zustand existiert, zum Beispiel EAID-N10-S7, während das signierte Evidence Package auf das niedrigere Gate beschränkt bleibt. Die Ceiling ist eine freiwillige Assurance-Attestation: Die handelnde Entität kann signalisieren, dass ein tieferer Identitätszustand verfügbar ist, während die Relying Party nur die Informationen erhält, die durch die angeforderte Capability gerechtfertigt sind. Kryptografische Techniken für Selective Disclosure können diese Trennung unterstützen, vorbehaltlich der Privacy- und Korrelationsgrenzen des gewählten Proof-Formats.(World Wide Web Consortium 2026; OpenID Foundation 2025) Dies bewahrt den praktischen Wert eines portablen High-Assurance-Signals, ohne Selective Disclosure wieder in vollständige Identitätsoffenlegung kollabieren zu lassen.

Anti-Money-Laundering-Due-Diligence wird als regulatorisches Mapping über diese Grammatik behandelt. Das aktuelle EU-AML-Recht strukturiert Third-Party Reliance durch AMLD4, während die Verordnung (EU) 2024/1624 das kommende unmittelbar anwendbare AML-Regelwerk bereitstellt, einschliesslich Customer Due Diligence Measures, Simplified Due Diligence in Fällen mit geringerem Risiko und Enhanced Due Diligence in Fällen mit höherem Risiko.(European Parliament and Council of the European Union 2015, arts. 25–27)(European Parliament and Council of the European Union 2024d, arts. 19, 20, 33, and 34) Wo AML-Recht gilt, müssen verpflichtete Entitäten diese Massnahmen nach dem zum relevanten Zeitpunkt anwendbaren Recht erfüllen. Ihr konzeptioneller Ausgangspunkt ist die AML-Beziehung zwischen einer verpflichteten Entität und einer Kundschaft, einschliesslich Beneficial-Owner- und Risk-Factor-Analyse. Die vorgeschlagene Assurance Layer beginnt eine Ebene höher: bei der rechtlich relevanten Capability, der Akteurskonstellation, die sie ausüben will, und der Evidence, die nötig ist, um die resultierende Operation zurechenbar zu machen.

Regulatorisches Mapping übersetzt eine sektorale rechtliche Anforderung in Gate-Prädikate und bewahrt dabei die allgemeine Ontologie. Ein AML Asset Transfer kann auf Simplified, Standard oder Enhanced Due Diligence Requirements gemappt werden. Ein hochwertiger Vertrag kann Proof of Age, Legal Capacity, Authority und Jurisdiction verlangen, bevor eine natürliche Entität oder eine J+N-Konstellation unterzeichnen kann. Eine minderjährige Person kann als N identifizierbar sein, während ihr die Capacity für die angeforderte Transaktion fehlt, sodass das Gate die minderjährige Person schützen muss, indem es diese Capability vorenthält oder sie durch eine zulässige Konstellation mit gesetzlicher Vertretung routet. Eine Fraud Allegation zwischen zwei natürlichen Entitäten kann Evidence für Polizei, Gericht oder zivilrechtliche Recovery verlangen, auch wenn das ursprüngliche Kommunikations-Gate ein geringes Risiko hatte. Ein maschinell erzeugter Asset Sale kann verlangen, dass das System bewahrt, wer oder was gehandelt hat, wann, unter welchem Mandate, mit welchem Ergebnis und welche N-, J+N- oder J+N+M-Konstellation den Imputation Point liefert.

Das Ergebnis ist ein zweischichtiges Design. Legal Identity Assurance speichert wiederverwendbaren Zustand von handelnden Entitäten und Evidence State, während regulatorische Mappings diesen Zustand durch deklarierte Gate-Prädikate konsumieren. AML SDD/CDD/EDD ist ein solches Mapping. Contract Capacity, Minor Protection, Mandate Verification, Organizational Authority, Machine Delegation, Consumer Protection und Evidentiary Preservation sind zusätzliche Mappings über denselben Assurance-Zustand.

Eine weitere Designfrage ist, wie der Assurance-Zustand Source Independence darstellen sollte. Das Modell sollte einen allgemeinen Trust Score vermeiden, weil niedrige Assurance legitim sein kann, wenn ein Gate mit geringen Folgen angefordert wird. Das präzisere Konzept ist Attribution Resilience: der Grad, in dem unabhängige und Source-diverse Evidence Zurechnung, Recourse und regulatorische Erfüllung tragen kann, falls eine folgenreiche Handlung später bestritten wird. Mehrere Pässe, staatliche Identitätsdokumente, regulierte Bankbeziehungen, verifizierte Adressen und Jurisdictional Anchors machen eine handelnde Entität moralisch nicht vertrauenswürdiger. Sie machen es schwieriger, den eingereichten Legal-Identity-Zustand vollständig zu fälschen, einfacher, ihn auf Inkonsistenzen gegenzuprüfen, und nützlicher, wenn rechtmässige Klärung später einen accountable point erfordert.

Dies ist wichtig, weil heutige Onboarding- und Plattformprozesse oft entweder zu viele schwache Informationen oder zu wenige rechtlich nützliche Informationen sammeln. Ein Business-Bank-Onboarding-Prozess kann öffentliche Social-Media-Spuren verlangen, die leicht zu erzeugen und nur schwach mit rechtlicher Identität verbunden sind, während stärkere Registry-, Representative-, Beneficial-Owner-, Address- und Bank-Control-Evidence langsam, dupliziert und opak bleibt. Ein plattformvermittelter Mietstreit kann einen rechtlich relevanten Konflikt bearbeiten, während die anspruchstellende Person keinen nutzbaren Weg hat, um festzustellen, ob die Gegenpartei ein privater Host, ein kommerzieller Betrieb oder eine juristische Entität hinter dem Listing ist. In beiden Fällen ist das Problem ein fehlendes regulatorisches Mapping von der angeforderten Capability oder dem Dispute Path auf das minimale Evidence Package, das für Compliance, Proportionality und Recourse nötig ist.

Die vorgeschlagene Architektur kann dies vorsehen, ohne den späteren Scoring-Mechanismus festzulegen. Gates konsumieren deklarierte Prädikate, Coordinates drücken Disclosure Scope und Confirmation Source aus, jurisdiktionale Instanzen halten die relevanten Legal Anchors, und signierte Legal-Identity-Präsentationen legen nur das Set offen, das für das angeforderte Gate nötig ist. Eine spätere Implementierung kann regulatorische Mapping Sets aus demselben Zustand ableiten, etwa ein Bank-Onboarding Set, ein Contract-Signing Set, ein Minor-Protection Set oder ein Platform-Dispute Set. Das Prinzip für den vorliegenden Beitrag ist enger: Source Diversity und Triangulation erhöhen Assurance und Attribution Resilience, während Capability Gates verhindern, dass handelnde Entitäten mit niedriger Assurance Capabilities ausüben, für die die Evidenzgrundlage unzureichend ist.

Vergleichende Design Evaluation

Die Evaluation ist analytisch, wie es für ein Design-Science-Konstrukt im Spezifikationsstadium angemessen ist. Jeder Comparator wird an den sechs Anforderungen geprüft, die in 1 festgelegt sind. Das Comparator Set folgt den Alternativen, die in den Problem- und Related-Work-Abschnitten eingeführt wurden: flache Maximalverifikation als Control Condition, Credential-bezogene Level-of-Assurance Frameworks, institutionelle reusable-KYC Reliance und das vorgeschlagene Grid mit Confirmation und Reliance Events.(European Parliament and Council of the European Union 2024d, 2014; Financial Action Task Force 2025; European Commission 2015; National Institute of Standards and Technology 2025a, 2025b; Society for Worldwide Interbank Financial Telecommunication 2026; Business Information Industry Association 2020; Sporny et al. 2025) Die Matrix berichtet Design Capacity, nicht Implementation Performance: Sie fragt, was jede Architektur ausdrücken kann, bevor lokale Policy Parameters gewählt werden. Die Scoring Rule ist primitive-basiert: Hoch bedeutet, dass die Anforderung durch native State- oder Event-Felder dargestellt wird; Teilweise bedeutet, dass ein Teil der Anforderung dargestellt wird, während ein anderer Teil externe Policy oder externer Process bleibt; Niedrig bedeutet, dass der Architektur ein nativer Ausdruck für die Anforderung fehlt. 8 wendet diese Regel auf die vier Comparators an und macht die späteren Scenario Readings auf die sechs Anforderungen rückführbar statt auf ein impressionistisches Urteil.

Dasselbe Ergebnis lässt sich durch sechs kleine Scenario Readings prüfen. Für R1 braucht eine Forum-Antwort mit geringen Folgen Status und einen erreichbaren Handle, während ein Asset Transfer stärkere Source Classes und eine reichere Konstellation braucht; nur das Grid macht diese beiden Anforderungen zu Adressen über demselben Zustand. Für R2 kann dieselbe handelnde Entität eine High-Assurance-Passzelle halten und dennoch an einem Child-Safety-, Mandate-, Payment- oder Freshness-Gate scheitern; das Grid berichtet dies als Gate Outcome und nicht als Änderung des Identitätsstatus. Für R3 ist ein maschinell erzeugtes Angebot nur durch den Attachment Path in M0 und die anwendbare N-, J- oder Composite-Relation zulässig, wodurch die Architektur technische Handlung modellieren und zugleich rechtliche Zurechnung bewahren kann. Für R4 kann ein Age Gate N1 in der erforderlichen Source Class anfordern, ohne Address-, Document-Scan- oder Biometric-Zeilen zu erhalten. Für R5 ändert ein Wechsel über Jurisdiktionen hinweg den aktiven Anchor für spätere Handlungen und bewahrt zugleich den früheren Anchor für Replay. Für R6 kann ein relying Service eine frühere Confirmation konsumieren, dennoch zeichnet das Reliance Event weiterhin auf, wer sich worauf verlassen hat, auf welches Paket, unter welcher Rule Version und innerhalb welcher Liability Boundary.

8 ergibt zwei Resultate. Erstens sind flache Maximalverifikation und Credential-bezogene LoA-Designs kohärente Baselines, aber jedes ist eine Faltung des in 5 genannten Grids. Der Verlust zeigt sich genau dort, wo eine Anforderung Cell Addressability, Event Timing oder eine Unterscheidung zwischen Assurance State und Capability Permission braucht. Zweitens unterstützt institutionelle reusable-KYC Reliance bereits einen Teil von R6 und einige juridical Due-Diligence-Arbeit, weshalb sie bei Wiederverwendung besser abschneidet als ein einfaches Verification Bit. Ihr Objekt bleibt ein sektorales Due-Diligence File statt eines portablen Legal-Identity-Assurance-Zustands mit typisierten handelnden Entitäten, Jurisdictional Anchors und Gate-scoped Reliance. Das vorgeschlagene Artefakt ist das einzige bewertete Design, dessen Primitives eins zu eins allen sechs Anforderungen entsprechen.

Designbegründung und Trade-off-Struktur

Die Evaluation zeigt, weshalb das Artefakt als Raster und nicht als Leiter organisiert ist. Der übliche Druck in Identitätssystemen besteht darin, Zustände so weit zu vereinfachen, bis eine prüfende Stelle ein einziges Signal lesen kann. Dieser Druck ist administrativ attraktiv, aber 5 und 8 zeigen seinen Preis: Jedes Ein-Signal-Design muss eine Unterscheidung aus der Architektur heraus und in Policy-Prosa, manuelle Ausnahmebehandlung oder institutionelles Vertrauen verschieben. Das vorgeschlagene Raster hält diese Unterscheidungen im Adressraum. Das ist die zentrale Designbegründung, sogar mehr als die Anzahl der Source Classes oder Assertion Rows. Die Trade-off-Karte in 9 verdichtet diese Diskussion zu fünf wiederkehrenden Spannungen und zeigt, wie das Artefakt jede Spannung in adressierbaren Zustand, deklarierte Gates oder Reliance Records verschiebt.

Die Lebendigkeit des Modells liegt in dieser Verlagerung von Veränderung. Der Assurance-Zustand kann im Zeitverlauf Bestätigungen ansammeln, während jedes Gate frei bleibt, sein Prädikat zu ändern, wenn sich Recht, Risiko, institutionelle Policy oder die angefragte Fähigkeit ändern. Ein Dienst muss nicht ein für alle Mal entscheiden, dass ein Akteur verifiziert ist. Er deklariert die Zellen, Source Classes, Frischefenster, Konstellation und den jurisdiktionalen Anchor, die ein konkreter Akt erfordert. Derselbe Akteur kann ein Forum-Gate bestehen, ein Payment-Gate nicht bestehen, ein Contract-Gate über J+N bestehen und später den Reliance-Zustand für einen Streitfall wiedergeben, ohne dass dabei ein Widerspruch im Identitätsstand entsteht.

Das erklärt auch die These der kumulativen Offenlegung. Das Artefakt ist kumulativ für die haltende Partei und selektiv für jede Relying Party. Für einen Akt gesammelte Bestätigungen können für spätere Gates verfügbar bleiben, aber spätere Gates erhalten nur die Zellen, die sie rechtfertigen können. In einem Checklistenmodell pro Dienst werden dieselben Dokumente von jeder Institution wiederholt angefragt, kopiert, interpretiert und gespeichert. Im vorgeschlagenen Modell ist Bestätigung wiederverwendbar und Reliance wird neu erfasst. Diese Unterscheidung verhindert, dass Wiederverwendung zu Verantwortungswäsche wird: Die Relying Party kann frühere Bestätigung nutzen, doch ihr eigenes Reliance Event hält die Entscheidung fest, die sie getroffen hat, und die rechtliche Grenze, innerhalb derer sie sie getroffen hat.

Institutionelle Implikationen und Adoptionsbedingungen

Für Relying Services ist die unmittelbare Implikation, dass Identitätsnachfrage veröffentlichbar wird. Ein Dienst kann ein Gate-Profil für eine Fähigkeit angeben: die zugelassenen Entitätstypen, die erforderlichen Assertion Cells, die Mindest-Source Classes, die Frischefenster, den jurisdiktionalen Anchor und das Reliance Event, das er erzeugen wird. Dadurch wird Identitätserhebung von einer verborgenen Checkliste zu einer vergleichbaren Nachfrage. Zwei Dienste, die dieselbe Fähigkeit anfragen, können offenlegen, ob einer mehr Daten, frischere Evidenz, stärkere Quellen oder eine breitere Haftungsgrenze verlangt. Diese Vergleichbarkeit ist die institutionelle Form der Verhältnismässigkeit.

Für öffentliche Behörden, qualifizierte Vertrauensdienste, Notariate, Banken, Register, Prüfstellen und andere bestätigende Stellen mit hoher Rechenschaftspflicht bedeutet dies eine Verschiebung von der Dokumentenproduktion zur Produktion von Confirmation Events. Der institutionelle Akt bleibt vertraut: ein Identitätsdokument ausstellen, eine Registertatsache bestätigen, eine Urkunde bezeugen, eine Bankbeziehung verifizieren, ein maschinelles Artefakt prüfen oder eine Rolle attestieren. Die Assurance-Schicht ändert das Ausgabeformat. Sie fordert die bestätigende Stelle auf, den Akt an explizite Zeilen, Source Class, Gültigkeitszeit, Aufzeichnungszeit, Policy-Version, Statuskanal und Beweismaterial zu binden. Verifiable-Credential-Standards können einen grossen Teil dieses Substrats tragen, während rechtliche Identity Assurance die Zeilen-, Quellen-, Jurisdiktions- und Reliance-Semantik darum herum bereitstellt.(Sporny et al. 2025; World Wide Web Consortium 2025b, 2025a; OpenID Foundation 2025)

Für Regulierungsstellen macht das Artefakt Überidentifikation und Unteridentifikation in derselben Grammatik sichtbar. Ein Kinderschutz-Gate, ein AML-Onboarding-Gate, ein Corporate-Signing-Gate, ein Consumer-Refund-Gate und ein Machine-Delegation-Gate können alle als Prädikate über einen Zustand ausgedrückt werden. Dadurch werden die Prädikate nicht identisch. Dadurch werden ihre Anforderungen auditierbar und vergleichbar. Die Regulierungsstelle kann fragen, ob ein Gate Zellen anfragt, die der Akt rechtfertigt, ob ein Weg mit geringerer Offenlegung existiert, wo das Recht einen solchen erlaubt, ob ein folgenreicher Akt einen rechtmässigen Zurechnungspunkt hat und ob ein späterer Streit den Reliance-Zustand unter der zum Zeitpunkt geltenden Regelversion wiedergeben kann.

Die Adoptionsbedingung ist Netzwerkbildung rund um Gate-Profile und Confirmation Events. Das Artefakt wird nützlich, wenn genügend Relying Services Gate-Prädikate veröffentlichen, genügend bestätigende Stellen eventgebundene Attestierungen ausstellen und genügend Wallets oder Repositories begrenzte Pakete präsentieren können. Das ist ebenso ein Standardisierungs- und Governance-Problem wie ein Engineering-Problem. Die Architektur reduziert wiederholte Erhebung nur, wenn Institutionen sich jurisdiktionsübergreifend auf Zeilenkennungen, Source-Class-Mappings, Statuskanäle, Beweisformate und Rollen-Äquivalenztabellen einigen. Maschinenakteure fügen eine weitere Adoptionsbedingung hinzu: Betreiber:innen müssen M0-Anbindung und Mandatsevidenz offenlegen, bevor automatisierte Fähigkeit als rechtlich bedeutsam akzeptiert werden kann.