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 Zeitstempel

Einfügen oder eine Datei hierher ziehen. Binäre RFC-3161-Dateien gehen über «Datei wählen».

Beispiele. Echte Signaturen aus den öffentlichen Testvektoren und dem IETF-Standard RFC 9421.

Vertrauen der Prüfstelleoptional

Vertrauenswü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.

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: –

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.