--- title: "Agenten-Nachweis prüfen: Mandat, Beleg, Zeitstempel" url: https://knowyouragent.ch/pruefen lang: de-CH updated: 2026-10-12 license: © Innopulse Consulting GmbH --- # Nachweis prüfen Zehn Prüfschritte, ein Urteil, eine Stufe auf der Prüfskala. Nichts verlässt Ihren Browser. ## Nachweis einfügen Token, Nachweispaket, Beleg-Kette oder ZeitstempelEinfügen oder eine Datei hierher ziehen. Binäre RFC-3161-Dateien gehen über «Datei wählen». PrüfenDatei wählenLeeren Beispiele. Echte Signaturen aus den öffentlichen Testvektoren und dem IETF-Standard RFC 9421. **Vollständiges Paket**Mandat, Entscheid, Beleg und Zeitstempel: alles belegt.**Korrekt abgelehnt**Über dem Limit – der Prüfpunkt hat abgelehnt.**Manipulierte Beleg-Kette**Ein Betrag wurde nachträglich geändert.**Mandat ohne Statusliste**Widerruf nicht prüfbar, Ergebnis unbestimmt.**Aussteller per did:web**Der Schlüssel kommt von der Prüfstelle.**Cloudflare Web Bot Auth**Signierte Anfrage: Identität belegt, keine Befugnis.**Mastercard Verifiable Intent**Agent kauft innerhalb der Nutzer-Bedingungen (Referenz).**IETF RFC 9421 (Anhang B.2.6)**Offizielles Beispiel aus dem Standard: Signatur gültig, Befugnis offen. Vertrauen der PrüfstelleoptionalVertrauenswürdige Schlüssel (JWK oder JWKS)Schlüssel, denen Sie als prüfende Stelle vertrauen, z. B. aus dem veröffentlichten JWKS des Ausstellers. Statuslisten (Token)Statuslisten-Token nach IETF Token Status List. Mehrere durch Leerzeichen oder Zeilenumbruch trennen. Zeitstempel-Anker (PEM-Zertifikat)Zertifikat der Zeitstempelstelle oder ihrer Wurzel, dem Sie vertrauen. Die Prüfung läuft vollständig in Ihrem Browser. Nichts wird übertragen oder gespeichert. Die Prüfung läuft im Browser und braucht JavaScript. A0 KYA-Prüfschein Noch nicht geprüft Fügen Sie einen Nachweis ein oder wählen Sie ein Beispiel. **Agent** – **Auftraggeber** – **Mandat** – **Handlung** – **Entscheid** – **Beleg** – **Zeitstempel** – **Format** – KYA<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< ## Was Sie einfügen können | Eingabe | Erkannt an | Was geprüft wird | |---|---|---| | Mandat oder Agent Passport (SD-JWT VC) | Aussteller-JWS, gefolgt von Disclosures mit ~ | Signatur, Disclosures, Key Binding, Gültigkeit, Umfang, Widerruf, Delegation | | Entscheid-Token (JWS) | Claim decision mit allow, deny oder escalate | Signatur, Aussteller, Agent, Handlung | | Beleg-Kette | kya-chain/1 oder Liste mit entry_hash | Hash jedes Eintrags, Verkettung, Bezug auf Entscheid und Mandat | | Nachweispaket | kya-pack/1 | Manifest und alle Teile zusammen, inklusive Querbezüge | | Zeitstempel | RFC-3161-Token oder TimeStampResp, Binär, Base64 oder PEM | CMS-Signatur, Zweckbindung, Bindung an den Inhalt, Pfad zum Anker | | Signierte HTTP-Anfrage (RFC 9421, Web Bot Auth) | Rohe Anfrage mit Anfragezeile und Headern Signature-Input, Signature, optional Signature-Agent; Schlüssel als JWKS der Prüfstelle | Signaturbasis nach RFC 9421, Ed25519, ECDSA und RSA-PSS, Schlüssel über kid oder JWK-Thumbprint, Bindung des Betreibers | | Mastercard Verifiable Intent | JSON mit l1, l2 und optional l3 oder je Rolle l2_payment/l3_payment, l2_checkout/l3_checkout | Signaturen aller Schichten, sd_hash-Bindungen, Delegation an den Agentenschlüssel, Betragsrahmen und Zahlungsempfänger, Querbezug Zahlung und Checkout | Erkannt, aber in dieser Version nicht geprüft: klassische AP2-JSON-Mandate und reines Schlüsselmaterial. Die mit Verifiable Intent konvergierte AP2-Kette läuft über den VI-Adapter. Das Ergebnis sagt das ausdrücklich, statt still zu scheitern. ## Woher die Schlüssel kommen Eine gültige Signatur beweist nur, dass der Inhalt zum Schlüssel passt. Wer ausgestellt hat, belegt erst die Herkunft des Schlüssels. Deshalb weist jeder Bericht die Schlüsselherkunft aus. | Herkunft | Bedeutung | Belegt den Aussteller | |---|---|---| | did | aus der Aussteller-DID | ja | | trusted | von der prüfenden Stelle | ja | | embedded | im Token selbst (selbst behauptet) | nein | | bundled | dem Paket beigelegt (selbst behauptet) | nein | Schlüssel per `did:web` oder aus einem JWKS werden nicht automatisch geladen, weil die Prüfung keine Netzwerkanfragen stellt. Kopieren Sie den veröffentlichten Schlüssel des Ausstellers unter «Vertrauen der Prüfstelle» hinein. ## Was mit Ihren Daten geschieht Nichts. Der Prüfkern ist ein JavaScript-Modul, das in Ihrem Browser rechnet. Die Seite verbietet sich Netzwerkverbindungen selbst über die Content-Security-Policy `connect-src 'none'`, und der Quelltext enthält keine Netzwerk- oder Speicheraufrufe. Beides wird bei jedem Release automatisch geprüft. ## Bericht reproduzieren Der Bericht enthält den SHA-256 der Eingabe, einen Digest der Optionen, die Version des Prüfkerns und die Policy-Version. Auf der Kommandozeile entsteht derselbe Bericht: ``` node cli/kya-verify.mjs nachweis.json --now 2026-10-12T10:00:00Z --anchors tsa.pem ``` Stimmt der `reportDigest` überein, haben beide Seiten dasselbe geprüft und dasselbe Ergebnis erhalten. ## Häufige Fragen ### Welche Nachweise kann ich hier prüfen? Mandate und Agent Passports als SD-JWT VC, Entscheide als JWS, Nachweispakete, Beleg-Ketten, Zeitstempel nach RFC 3161, Verifiable Intent und signierte HTTP-Anfragen. ### Woher bekomme ich die Schlüssel der Aussteller? Aus deren veröffentlichtem JWKS oder einer anderen vertrauenswürdigen Quelle. Sie hinterlegen sie unter «Vertrauen der Prüfstelle». ### Warum ist mein Ergebnis unbestimmt? Weil nichts widerlegt, aber nicht alles Wesentliche belegt ist. Der Prüfschein nennt, was fehlt, etwa eine Statusliste oder ein Zeitstempel-Anker. ### Kann ich den Prüfschein speichern? Ja, mit «Prüfschein als JSON». Er enthält einen reportDigest und lässt sich mit denselben Daten jederzeit nachrechnen. --- Quelle: https://knowyouragent.ch/pruefen · KYA – Know Your Agent