Zusammenfassung
Digitale Identität bleibt strukturell starr, wenn sie an Provider Accounts, veränderliche Handles, einzelne soziale Kontexte und lokale Wallet Schemes gebunden ist. Dieses Paper definiert eine rechenschaftsfähige Hash-Anchor Tier oberhalb von Wallets und Credential Schemes. Aufbauend auf einem Companion Model für Legal Identity Assurance bindet die Tier einen inerten Root Anchor an einen event-backed Entity Actor Identity (EAID) Assurance-Zustand, unterstützt nicht verknüpfbare Profile Anchors für getrennte Kontexte und erlaubt relying parties, gate-spezifische Assurance-at-Time über offengelegte unabhängige Confirmation-Event Cluster zu evaluieren. Das formale Modell formuliert die Trennungsinvariante von Identifier und Capability, definiert Root und Profile Anchors, modelliert Disclosure und lawful resolution als Constraints und gibt eine zweischichtige Erasure-Konstruktion für aufbewahrte Commitments und off-chain Personenverknüpfung. Es modelliert ausserdem Trust als Reliance Event, in dem pseudonyme Interaktion rational wird, wenn eine Presentation das angeforderte Gate erfüllt und Recourse den rechtlich relevanten Imputation Point erreichen kann. Das Ergebnis ist eine scheme-agnostische Aggregation Layer, die national wallets ergänzt, natürliche, juristische und maschinelle Actor Constellations unterstützt und Bedingungen formuliert, unter denen Pseudonymität, lawful access, data erasure und retention gemeinsam erfüllt werden können.
Einleitung
Digitale Identität wird starr, wenn sie an einen Provider Account, einen veränderlichen Contact Handle, einen einzelnen sozialen Kontext und ein einzelnes Rechtssystem gebunden ist. Natürliche Personen bewegen sich zwischen familiären, beruflichen, zivilgesellschaftlichen und pseudonymen Kontexten, und sie können auch mehrere jurisdiktionale Identitäten halten. Platform Accounts falten diese Publika auf eine Präsentationsfläche zusammen, eine Dynamik, die als Context Collapse und als Audience Management in sozialer Interaktion untersucht wird.(Marwick and boyd 2011; Goffman 1959) Auch das Privacy Problem ist kontextuell: Ein Datum kann in einer Beziehung angemessen und in einer anderen unangemessen sein, auch wenn es wahr ist und rechtmässig gehalten wird.(Nissenbaum 2010)
Aus diesem Account-Level Design folgen vier Starrheiten. Anchor Rigidity entsteht, wenn Identität an eine Telefonnummer, E-Mail-Adresse, einen Platform Account oder eine Wallet Instance geschweisst wird statt an eine portable Root. Context Rigidity entsteht, wenn ein Identifier zugleich familiäre, berufliche, öffentliche und pseudonyme Interaktion bedienen muss. Portability Rigidity entsteht, wenn eine Identitätsprüfung durch eine Institution von einer anderen nicht ohne erneute Erhebung wiederverwendet werden kann. Jurisdiction Rigidity entsteht, wenn ein Scheme einen Rechtsrahmen trägt, während Leben und Transaktionen des Actors Grenzen überschreiten. Die gemeinsame Ursache ist architektonisch: Flexible Nutzung verlangt ein Identitätsobjekt oberhalb von Wallets, Providern und lokalen Schemes.
Regulatorische Druckpunkte laufen auf denselben architektonischen Bedarf zu. Data-protection law gewährt Rechte auf Erasure und Minimisation, während anti-money-laundering law Customer Due Diligence und Aufbewahrung von Identitätsaufzeichnungen verlangt.(European Union 2016, 2024b) Electronic-identity law unterstützt selective disclosure und Pseudonymnutzung, während regulierte Aktivität weiterhin rechtmässige Identifizierbarkeit und Recourse verlangt.(European Union 2024a) Diese Pflichten können in getrennten Rechtsinstrumenten formuliert werden, aber ein System, das rechtlich relevante digitale Handlungen vermittelt, muss sie gemeinsam implementieren. Die fehlende Architektur ist eine rechenschaftsfähige Middle Layer: Gewöhnliche Interaktion bleibt pseudonym und minimal, während definierte Bedingungen Resolution, Audit und Verantwortung erhalten.
Das Companion Paper liefert das Legal-Identity-Assurance Substrat für diese Layer.(Kurz 2026b) Es definiert natürliche, juristische und maschinelle Entitäten; unterscheidet Entitäten von Actors; repräsentiert Assurance durch Entity Actor Identity (EAID) Coordinates über Assertion Rows und Source Classes; erfasst Confirmation und Reliance als Events; und formuliert Capability Gates als Prädikate über diesen Assurance-Zustand. Es fixiert auch den hier verwendeten Machine-Actor Caveat: Eine Maschine kann technisch handeln, aber rechtliche Verantwortung wird unter geltendem Recht durch eine natürliche oder juristische Actor-Entität zugerechnet. Dieses Paper setzt oberhalb dieses Substrats an und definiert die Hash-Anchor Tier, die den rechtlichen Assurance-Zustand bindet, trennt, präsentiert und aggregiert.
Aus systemtheoretischer Perspektive ist der Hash Anchor ein Beobachtungspunkt für Operationen statt eine digitale Person. Das System registriert Credential Issuance, Confirmation, Presentation, Consent, Resolution, Revocation, Reliance und Dispute als Events um einen inerten Anchor, während rechtliche Identität nur durch governte Linkage erreichbar bleibt.(Luhmann 1995) Die Designfrage ist kybernetisch: Wie viel unabhängige, frische und rechtlich erreichbare Evidenz gibt einer relying party genug Varietät, damit eine pseudonyme Gegenpartei mit glaubwürdigem Recourse handeln kann.(Ashby 1956)
Dieses Paper leistet fünf miteinander verbundene Beiträge. Erstens definiert es eine above-wallet Hash-Anchor Tier, die an den event-backed Assurance-Zustand von Paper 14 bindet und Credential Schemes innerhalb und ausserhalb der Europäischen Union verbindet. Zweitens definiert es Root und Profile Anchors, damit Kontexttrennung und rechenschaftsfähige Pseudonymität nebeneinander bestehen können. Drittens definiert es gate-spezifische triangulierte Assurance-at-Time über unabhängige Confirmation-Event Cluster, wobei Freshness, Revocation, Source Independence, Binding Strength und Jurisdiction zur Reliance Time evaluiert werden. Viertens modelliert es Disclosure, lawful resolution, governed erasure und retention als Constraints, die unter benannten Annahmen gemeinsam erfüllt werden können. Fünftens modelliert es assurance-mediated trust als Reliance Event, in dem verifizierbare Gate Satisfaction und glaubwürdiger Recourse pseudonymen Parteien Transaktionen erlauben.
Beitrag
Die Bausteine sind Standards, privacy-preserving Credential Primitives und das Legal-Assurance Substrat, das Paper 14 liefert. Paper 15 trägt die Anchor Tier bei, die dieses Substrat präsentierbar, über Kontexte trennbar und für Trust Decisions nutzbar macht.
Erstens definiert das Paper eine above-wallet Hash-Anchor Tier. Ein Root Hash Anchor legt sich auf den off-chain EAID Assurance-Zustand fest, während Profile Anchors derselben Entität erlauben, in getrennten Kontexten zu handeln, ohne den Root Anchor in gewöhnlicher Interaktion offenzulegen. Die Tier konsumiert Credentials und Wallet Presentations als Evidence Packages und behandelt Paper 14 Confirmation Events als Assurance-Einheiten.
Zweitens formuliert das Paper die Identifier and Capability Separation Invariant für die Anchor Tier. Der Hash Anchor benennt und legt fest; private Keys authentifizieren; expliziter Consent und Gate Satisfaction autorisieren. Diese Trennung erklärt, weshalb der Anchor öffentlich sein kann, weshalb Credentials und Capabilities off-chain bleiben und weshalb Erasure auf Linkage und Profile-Binding State zielen kann statt auf das Ledger Commitment selbst.
Drittens definiert das Paper gate-spezifische triangulated assurance-at-time. Das Modell evaluiert unabhängige Confirmation-Event Cluster gegen ein konkretes Gate Predicate zur Reliance Time. Die Funktion diskontiert gemeinsame Issuers, Ceremonies, Status Authorities und Proof Failure Modes, während sie Binding Strength, Freshness, Revocation und jurisdiktionale Passung berücksichtigt.
Viertens kombiniert das Paper accountable pseudonymity, lawful resolution und governed erasure als Constraints in einer Architektur. Profile Anchors unterstützen gewöhnliche pseudonyme Interaktion; threshold-governed resolution erhält Recourse unter gültigem legal process; das zweischichtige Erasure Model erhält erforderliche Records, während es Personal Linkage entfernt, sobald Retention nicht mehr gilt.
Fünftens modelliert das Paper assurance-mediated trust über Reliance Events. Eine relying party kann mit einem Profile Anchor ein Geschäft abschliessen, wenn die Presentation das Gate erfüllt und ein Dispute den rechtlich relevanten Imputation Point erreichen kann. Dies verbindet Identity Assurance mit praktischer Kooperation zwischen Parteien, die ohne direkte Kenntnis voneinander starten.
Systemmodell und formaler Rahmen
Inputs aus Legal Identity Assurance
Dieses Paper baut auf dem Legal-Identity-Assurance Substrat auf, das im Companion Paper entwickelt wurde.(Kurz 2026b) Dieses Substrat unterscheidet Entitäten von Actors: Eine Entität existiert, während ein Actor eine Entität in der evaluierten Handlung ist. Es definiert natürliche Entitäten (N), juristische Entitäten (J) und maschinelle Entitäten (M). Eine maschinelle Entität kann technisch handeln, ist unter dem gegenwärtigen Rechtsrahmen aber nicht die finale Trägerin rechtlicher Verantwortung. Rechtlich relevante maschinelle Handlung wird durch eine zulässige Konstellation präsentiert, etwa N+M, restricted J+M oder J+N+M, in der eine natürliche oder juristische Entität den Imputation Point liefert. Eine standalone M Presentation ist für rechtlich folgenreiche Gates unzulässig, sofern künftiges Recht dieser maschinellen Entität keine eigenständige rechtliche Identität gibt; bis dahin verlangen J+M und J+N+M Presentations zusätzlich Rollen-, Mandats- oder Control Evidence, die die maschinenvermittelte Handlung mit dem rechenschaftsfähigen natürlichen oder juristischen Record verbindet.
Dasselbe Substrat definiert die Entity Actor Identity (EAID) Coordinate Grammar. Eine EAID Coordinate, etwa EAID-N6-S7, benennt eine Assertion Row und eine Source-of-Information Rung: welches identitätsrelevante Item offengelegt wird und wer oder was hinter diesem Item steht. Gefüllte Cells werden durch Confirmation Events gestützt. Ein Confirmation Event erfasst die geprüften Cells, Source Class, Binding Evidence, Valid Time, Record Time, Revocation oder Status Pointer, Policy Version und Proof Package. Ein Reliance Event erfasst die konsumierende Handlung: wer relied, für welche Capability, unter welchem Gate, Recht, Actor Constellation, Zeitpunkt und Liability Boundary. Paper 15 nimmt diese Legal Grammar als Input. Es definiert die Hash-Anchor Layer, die daran bindet, sie präsentiert und unabhängige Confirmation-Event Cluster für ein konkretes Relying-Party Gate aggregiert.
Definition 1 (Identifier und Anchor). Der Paper 15 Root Anchor ist ein selbst ausgegebener, öffentlicher, inerter Hash , der zu einem off-chain EAID Assurance-Zustand festlegt und keine Capability verleiht. Er wird auf einem Distributed Ledger als tamper-evident, timestamped Commitment registriert. Ein Profile Anchor ist ein öffentliches, inertes pseudonymes Commitment für einen definierten Kontext. Sein öffentliches Commitment ist kontextspezifisch; seine Beziehung zu wird im verschlüsselten Binding Registry von Definition 4 gehalten und einer relying party nur durch einen gate-spezifischen Predicate Proof oder durch lawful resolution gezeigt. In diesem Paper bezeichnet Hash Anchor diesen ledger-fixed point. Er unterscheidet sich vom Jurisdictional Anchor des Companion Papers, der eine zeitindexierte rechtliche Beziehung ist, mit der eine Handlung unter einem Governing Law evaluiert wird.
Definition 2 (Evidence Set). Für einen Hash Anchor bezeichne die Menge der Confirmation Events, die an den entsprechenden Root EAID State gebunden sind. Jedes Event kann durch ein verifiable credential, eine Presentation, einen Status Entry, einen Ledger Proof oder ein anderes signiertes Evidence Package getragen werden, aber die Assurance-Einheit ist das Confirmation Event und nicht der Credential Container.(World Wide Web Consortium 2025; Terbu et al. 2025)
Anchors und Trennung
Definition 3 (Trennungsinvariante). Ein Identifier benennt; er autorisiert nie. Jede Capability entsteht ausschliesslich aus dem Besitz privater Keys (Authentication) zusammen mit einem expliziten, frischen, consented Grant (Authorisation). Formal liefert Kenntnis von allein keine zulässige Handlung.
Definition 3 trennt drei Funktionen, die Legacy Identifiers vermischen: Der Anchor benennt, Keys beweisen und Consent erlaubt. Zwei Folgen ergeben sich daraus. Der Anchor kann sicher publiziert und auf einem Public Ledger verankert werden, weil er inert ist. Das sensitive Material ist die off-chain Linkage zwischen dem rechenschaftsfähigen Legal Record und dem Anchor, zusammen mit den privaten Keys.
Definition 4 (Anchor-Hierarchie). Eine Entität hält einen Root Hash Anchor innerhalb einer Governance Domain und kann Profile Anchors halten. Das Binding Registry zwischen Root und Profile Anchors wird off-chain und verschlüsselt gehalten, wie die Linkage zwischen dem rechenschaftsfähigen Legal Record und Root Anchor. Das Registry wird nie publiziert. Aus und allein soll eine beobachtende Partei nicht bestimmen können, ob beide Profile Anchors an dieselbe Root binden, sofern die Implementierung auch Capabilities und Correlation Channels über Profile hinweg partitioniert.
Die Hierarchie löst Context Rigidity. Familiäre, berufliche und pseudonyme Beziehungen adressieren jeweils einen getrennten Profile Anchor, während wiederverwendbare Legal Identity Assurance an die Root bindet. Eine Presentation durch einen Profile Anchor beweist, dass der Root EAID State ein Gate Predicate erfüllt, ohne die Root oder ein Sibling Profile offenzulegen. Die Konstruktion nutzt die in den verwandten Arbeiten diskutierte Anonymous-Credential und unlinkable-proof Familie, während das vollständige Root/Profile Predicate Primitive eine Annahme dieses Papers bleibt. Lawful resolution gilt einheitlich: Unter dem Constraint von Gleichung 3 löst sich ein Profile Anchor zuerst über zu seiner Root und danach zur Legal Linkage auf, sodass Context Separation Accountability erhält.
Unlinkability ist eine Eigenschaft der gesamten Capability Surface, nicht der Identifier allein. Jede Capability, die Profile Anchors gemeinsam nutzen, etwa ein gemeinsames Payment Instrument, ein gemeinsamer Recovery Handle oder korrelierte Transport Metadata, bildet einen Linkage Channel, der die Trennung kollabieren lässt. Das Threat Model behandelt Cross-Profile Capability Sharing als Attack Surface, und eine konforme Implementierung partitioniert Capabilities pro Profile.
Triangulierte Assurance und Disclosure
Eine relying party deklariert ein Gate für eine konkrete Capability. Sein Demand Predicate importiert Paper 14s Gate Grammar: erforderliche EAID Cells, Source Floors, Freshness Windows, Jurisdictional Anchors, Revocation Conditions und zulässige Actor Constellations. Für eine Disclosure Response durch einen Profile Anchor sei die Menge der Confirmation Events, die als Unterstützung von zum Zeitpunkt offengelegt oder predicate-proven werden. Die verifier-facing Assurance Calculation ist auf Events begrenzt, die durch präsentiert werden. Events sind äquivalent, geschrieben , wenn sie einen Confirmer, eine Ceremony, einen Custody Path, eine Status Authority oder einen für relevanten Proof Failure Mode teilen. Nur Äquivalenzklassen zählen als unabhängige Corroboration.
Sei das Independence Weight einer Event Class, ihr Binding and Source-Strength Term und ihr gate-spezifischer Validity-, Freshness-, Revocation- und Jurisdiction Term. Wo mehrere Events in eine Äquivalenzklasse kollabieren, spezifiziert die Gate Policy die Class Summary Rule, wobei der konservative Default den schwächsten anwendbaren Binding-, Status- und Freshness Term nimmt. Die verifier-facing triangulated assurance-at-time der Response für Gate ist
Gleichung 1 ist eine gate-spezifische Attribution-Resilience Form. Sie verknüpft die unabhängigen Confirmation-Event Cluster, die in präsentiert werden, diskontiert gemeinsame Failure Modes und liest Status und Freshness zur Reliance Time. Allgemeines Reputation Scoring bleibt ausserhalb des Modells. Der Wert wird evaluiert, nachdem die verpflichtenden Gate Predicates adressiert wurden; für sich allein gewährt er keine Permission. Mehrere offizielle Identitäten, Adressen, Payment-Control Events und Jurisdictional Anchors können Assurance für ein Gate erhöhen, wenn sie source-diverse Corroboration liefern. Wiederholte Evidence, die auf demselben Issuer oder derselben Ceremony ruht, wird in ihre Event Class kollabiert, und der Verlust oder die Revocation eines Events lässt nur die verbleibenden unabhängigen Event Classes verfügbar. Die Product Form ist eine einfache independence-adjusted Fusion Rule für diese Architektur, während breitere Trust und Evidence-Fusion Formalismen Vergleichsmassstäbe statt Voraussetzungen bleiben.(Jøsang 2016)
Eine Disclosure Response an eine relying party ist nur zulässig, wenn sie expliziten Holder Consent trägt, nicht mehr als angefordert offenlegt, nur holder-bound Evidence Packages präsentiert und nur frische, nicht widerrufene Evidence Packages präsentiert. Mit jedem Faktor in ,
und wird genau dann an freigegeben, wenn . Der letzte Faktor bedeutet, dass das offengelegte Package das deklarierte Gate Predicate erfüllt, einschliesslich der erforderlichen EAID Cells, Source Floors, Freshness Windows, des Jurisdictional Anchor und der Constellation Family. Wo ein Gate zusätzlich einen Assurance Threshold deklariert, enthält der Faktor . Der Threshold filtert ansonsten zulässige Presentations; er ersetzt nie erforderliche Cell-, Status-, Binding- oder Constellation Predicates. Credential und Presentation Standards liefern das Trägerformat; die Gate Semantics kommen aus dem Legal-Identity-Assurance Model.(World Wide Web Consortium 2025; Fett et al. 2025; Terbu et al. 2025; Kurz 2026b)
Resolution, Erasure und Trust
Lawful resolution der Linkage zwischen dem Anchor und dem rechenschaftsfähigen Legal Record ist governed statt unilateral. Sie verlangt eine gültige Legal Order und ein Quorum von mindestens aus Escrow Key Holders,
Gleichung 3 beschreibt authorised resolution als Legal-State Predicate. Threshold Secret Sharing kann sicherstellen, dass weniger als Key Holders das escrowed secret nicht rekonstruieren können.(Shamir 1979) Collusion durch Key Holders ohne gültige Order ist ein Governance und Audit Breach und nicht eine kryptografische Unmöglichkeit. Die Architektur adressiert dies, indem sie Operator Access von Key Custody trennt und jedes Resolution Event für spätere Attribution notarisiert.
Definition 5 (Erasure in zwei Schichten). Immutable on-ledger artifacts sind Commitments und Proofs, und sie werden aufbewahrt. Solange die Linkage besteht, bilden sie pseudonymisierte personenbezogene Daten und werden auf einer Retention Basis verarbeitet (European Union 2016; European Data Protection Board 2025). Die Linkage und das Binding Registry werden off-chain und verschlüsselt gehalten. Bei einem Erasure Request zum Zeitpunkt werden löschbare Linkage und Profile-Binding Entries entfernt, sofern keine Retention Obligation für das betroffene Profile, Gate, Reliance Event , Dispute Window oder die regulierte Record Class besteht. Deletion wird nur für die verpflichteten Entries aufgeschoben und ausgeführt, wenn die Obligation endet. Nach Deletion ist der Design Claim auf die Entfernung operator-seitiger Attribution Means unter dem benannten Threat Model begrenzt; frühere relying parties und Institutionen, die offengelegte Preimages rechtmässig aufbewahren, bleiben ihren eigenen Retention Duties unterstellt.
Definition 5 bringt das Recht auf Erasure mit Retention Duties auf Architekturebene in Einklang: Die Chain bleibt erhalten, die Personal Linkage wird gesetzesabhängig entfernt, und Anonymisation wird durch Löschung von Linkage statt von Records verfolgt. Die Architektur verteidigt einen sequenzierten Claim: pseudonym, solange Linkage besteht, und anonym erst, wenn die verbleibenden Daten und vernünftigerweise verfügbaren Hilfsinformationen unter einer kontextspezifischen rechtlichen Beurteilung keine Attribution mehr erlauben. Zusammen formulieren Gleichungen 2 und 3 mit Definition 5 hinreichende architektonische Bedingungen, unter denen Pseudonymität, lawful access, erasure und retention koexistieren können.
Betrachten wir eine prüfende Partei , die entscheidet, ob sie mit einer pseudonymen Gegenpartei in einem Reliance Event für Gate zum Zeitpunkt ein Geschäft abschliesst. Die prüfende Partei sieht eine zulässige Presentation durch einen Profile Anchor plus den gate-spezifischen Assurance Value . Wenn defected, gewinnt sie , aber Defection löst Recourse mit Wahrscheinlichkeit aus, wobei die rechtliche Erreichbarkeit der eingereichten Actor Constellation und des Resolution Path bezeichnet. Recourse zieht eine Strafe nach sich.
Proposition 1. Cooperation ist s beste Antwort, wann immer . Wenn Recourse ausreichend glaubwürdig und punitiv ist, sodass , und wenn mit gate-spezifischer Assurance für die eingereichte Konstellation steigt, existiert ein Threshold , sodass bei Cooperation die Defection dominiert. Eine Gate Policy, die Assurance als Transaction Screen nutzt, sollte für die relevante Handlung setzen. Wenn , reicht Assurance für dieses Gate nicht aus, um Defection abzuschrecken, und die rationale prüfende Partei lehnt die Transaktion ab oder collateralises sie.
Proposition 1 formalisiert den zentralen Claim: Trust zwischen Fremden entsteht aus einer verifizierbaren, gate-scoped Assurance Presentation in Verbindung mit glaubwürdigem Recourse. Die relying party muss die zivile Identität während gewöhnlicher Interaktion nicht erfahren. Sie muss wissen, dass der Profile Anchor durch einen Root EAID State gedeckt ist, der das Gate erfüllt, und dass ein Dispute den rechtlich relevanten Imputation Point durch den governed Resolution Path erreichen kann.
Sechs Threats und ihre Mitigations folgen aus dem Modell. Eine geliehene oder replayed Presentation wird durch den Holder-Binding Factor in Gleichung 2 abgewehrt. Die Kompromittierung oder Coercion eines einzelnen Confirmers wird durch die Event-Cluster Form von Gleichung 1 begrenzt, da gate-spezifische Assurance auf keinem einzelnen Issuer, keiner einzelnen Ceremony und keiner einzelnen Status Authority ruht. Assurance Inflation durch Corroboration Farming wird durch die Äquivalenzrelation und durch die Independence Weights begrenzt, deren Governance Abschnitt 7 offenlässt. Tampering with Evidence wird durch Ledger Notarisation von Proofs, Consents und Dispute Records erkannt. Unauthorised Resolution of Identity wird operational durch Threshold Custody, Legal Approval, Separation of Duties und notarised Resolution Events beschränkt; Collusion durch ein gültiges Quorum bleibt ein Governance Breach mit forensic evidence statt einer unmöglichen Handlung. Cross-Profile Linkage durch gemeinsame Capabilities ist nur ausgeschlossen, wenn eine Implementierung Payment, Recovery und Transport Capabilities pro Profile Anchor partitioniert (Definition 4). Zwei Restrisiken bleiben: Registry-Level Scraping inerter Anchors, das unter Definition 3 keine Capability verleiht, und Coercion der haltenden Person, die kein holder-bound Scheme eliminiert.
Diskussion
Die Assurance Presentation wird über eine Actor Constellation evaluiert statt allein über einen isolierten Identifier. Eine relying party muss wissen, welche Konstellation den Anchor präsentiert hat, welche Confirmation-Event Cluster das angeforderte Gate stützen und welcher Recourse Path besteht, falls die Operation später disputed wird. Die Hash-Anchor Layer trägt oder löst zu genügend strukturiertem State auf, damit die relying party unterscheiden kann zwischen einer natürlichen Actor-Entität, die allein handelt, einer juristischen Actor-Entität, die durch eine rechenschaftsfähige natürliche Actor-Entität handelt, einer juristischen Actor-Entität, die durch einen Natural Anchor und einen Machine Actor handelt, einer restricted juridical-machine constellation mit rechtlich hinreichender Delegation Evidence und einer natürlichen Actor-Entität, die mit einer maschinellen Actor-Entität handelt. Standalone Machine Presentations werden im gegenwärtigen Rechtsrahmen als technische Handlung ohne finale rechtliche Imputation behandelt. Die Reliance-Frage ist, ob diese Konstellation für die angeforderte Operation glaubwürdig ist und ob Recourse den passenden Imputation Point erreichen kann.
Die Konstruktion zeigt Bedingungen, unter denen Anforderungen, die gewöhnlich als konkurrierend behandelt werden, gemeinsam erfüllt werden können. Selective disclosure und Pseudonymität koexistieren mit rechtmässiger Identifizierbarkeit durch accountable pseudonymity und threshold-governed resolution; das Recht auf Erasure koexistiert mit Retention durch das zweischichtige Modell. Weil authorised resolution sowohl eine Legal Order als auch ein Key Quorum verlangt, bleibt Accountability erhalten, während dem Operator keine unilaterale Resolution Power zukommt.
Anwendungen im Agnostyca Core
Die Tier dient natürlichen, juristischen und maschinenvermittelten Actor Constellations über mehrere Anwendungsdomänen hinweg. Eine Family-Safety Anwendung nutzt accountable pseudonymity und Contact Gating direkt. Platform Attestations instanziieren bereits einen Teil des Musters in Production: Die deklarierte Age Range eines mobilen Betriebssystems (Apple Inc. 2026) ist ein attested claim, in einigen Jurisdiktionen verification-backed, den eine relying party als ein Confirmation Event für ein age-related gate konsumieren könnte, ohne die zugrunde liegenden Daten offenzulegen. Eine Higher-Education Anwendung nutzt Credential Binding und gate-spezifische Assurance für Enrolment und für signierte, ledger-timestamped akademische Arbeit. Eine Enterprise-Artificial-Intelligence Anwendung bindet Agent Identity, Attestations und accountable action an dieselbe Anchor Tier, sodass ein Agent evaluieren kann, ob ein anderer die erforderliche Constellation und den Recourse Path für eine angeforderte Operation präsentiert. Das Companion Agent-Orchestration Framework (Kurz 2026a) governed, wie Actors koordinieren; die vorliegende Tier governed, welche Assurance und welcher Imputation State sie präsentieren, und beide teilen ein Ledger Substrate.
Komplementarität mit national wallets
Die Tier kann nationale Credentials als hochwertige Confirmation Sources konsumieren und präsentieren, wenn deren Issuance und Presentation das relevante Gate erfüllen. Eine relying party, die die EU Digital Identity Wallet akzeptiert (European Union 2024a; European Commission 2025), erhält eine routed Presentation; eine relying party mit scheme-spezifischer rechtlicher Anforderung erhält das spezifische Credential, während eine relying party, die event-backed Corroboration akzeptiert, das gate-spezifische Assurance Result von Gleichung 1 erhält. Eine natürliche Person, die zum Beispiel ein österreichisches Credential, ein Schweizer Credential (Swiss Confederation 2024) und ein nicht-europäisches Credential hält, kann alle drei an einen Root Assurance State binden und zugleich nur das Profile und Evidence Package präsentieren, das für die Handlung erforderlich ist. Durch die Akzeptanz von Credentials, welche die nutzende Person bereits hält, gibt die Tier neuen Deployments eine initiale Evidence Base über Schemes und Jurisdiktionen hinweg.
Fazit
Digitale Identität ist starr, wenn Provider Accounts, Wallet Instances, Kontext und Jurisdiktion in einer operativen Identität verschmolzen sind. Dieses Paper hat argumentiert, dass die fehlende Layer oberhalb von Wallets liegt: eine rechenschaftsfähige Hash-Anchor Tier, die an Paper 14s rechtlichen Assurance-Zustand bindet, Root und Profile Anchors trennt und relying parties gate-spezifische Assurance-at-Time über offengelegte unabhängige Confirmation-Event Cluster evaluieren lässt. Der Hash Anchor ist bewusst inert. Er benennt und legt fest, während Keys authentifizieren, Consent erlaubt, Gate Predicates autorisieren und governed resolution Recourse erhält.
Das Modell macht diese Architektur inspizierbar. Die Root/Profile Hierarchy trennt Kontexte und erhält zugleich einen rechtmässigen Weg zum rechenschaftsfähigen Record. Die Assurance Equation evaluiert offengelegte Confirmation-Event Cluster zur Reliance Time und diskontiert gemeinsame Issuers, Ceremonies, Status Authorities und Proof Failure Modes. Das Disclosure Predicate fixiert Consent, Minimisation, Holder Binding, Freshness, Status und Gate Satisfaction als Release Conditions. Die Resolution-, Erasure- und Reliance-Konstruktionen formulieren danach, wie Pseudonymität, lawful access, erasure, retention und rational trust unter den Annahmen des Papers zusammenhalten können.
Für die Paper Series liefert P15 die Anchor und Assurance-at-Time Layer zwischen progressive legal identity assurance und accountable ledger operation. P14 definiert Actor Grammar, Confirmation Events, Reliance Events, Jurisdictional Anchors und Capability Gates. P15 überführt diesen State in Root und Profile Anchors, die präsentiert, getrennt, aufgelöst, gelöscht und relied on werden können. Die folgende Ledger Layer kann dann Validator Identities, Observer Records und Evidentiary Commitments an Anchors binden, deren Assurance State bereits gate-scoped, replayable und rechtlich zurechenbar ist.
Limitationen und weitere Forschung
Mehrere Constraints begrenzen die vorliegende Arbeit. Registry-Level Invisibility ist eine weiche Eigenschaft mit verbleibendem Access Risk, auch wenn die Separation Invariant verhindert, dass der Anchor Capability trägt. Holder Binding setzt sichere Key Storage und ein praktikables Cross-Device Recovery Model voraus, was die operativ anspruchsvollste Komponente ist. Confirmation-Event Governance, einschliesslich der Fragen, welche Events in Gleichung 1 eingehen, welche gemeinsamen Failure Modes definieren, welche Summary Rule innerhalb jeder Event Class gilt und welche Weights für Event Classes gelten, verlangt einen institutionellen Prozess, den dieses Paper nur im Umriss spezifiziert. Das Modell behandelt Event-Class Weights zudem als skalare Terme, während reale Evidence Sources pairwise oder higher-order correlations aufweisen können, zum Beispiel zwei Credentials, die auf dasselbe Civil Registry zurückgreifen. Die Modellierung dieser Correlation Structure ist künftige Arbeit. Presentations von Profile Anchors setzen ein Predicate-Proof Primitive voraus, das Gate Satisfaction beweist, ohne den Root Anchor, Sibling Profiles oder einen stabilen Cross-Relying-Party Correlator offenzulegen. Anonymous Credentials, AnonCreds, U-Prove und BBS-style derived proofs liefern wichtige Teile dieses Primitive; eine vollständige Konstruktion, die diese Proofs an die Root/Profile Hierarchy und den rechtlichen Assurance-Zustand bindet, bleibt künftige Arbeit.(Camenisch and Lysyanskaya 2001; Paquin and Zaverucha 2013; World Wide Web Consortium 2026; Hyperledger AnonCreds Project 2026) Threshold Custody verlangt ausserdem ein rechtliches und operatives Design für Key Holders, Collusion Controls und die Orders, die authorised resolution auslösen. Der Erasure Claim bleibt kontextspezifisch: Das Löschen von Linkage und Profile-Binding State entfernt operator-seitige Attribution Means, während frühere relying parties, AML Records, Dispute Files und andere lawful preimage holders durch ihre eigenen Legal Bases governed bleiben. Das Modell ist analytisch; empirische Validierung durch eine Reference Implementation und einen cross-jurisdiction Pilot ist künftige Arbeit, ebenso die formale Verifikation des Joint-Satisfiability Claims unter adversarial Confirmation-Event Behaviour.