Standards
Die Standards hinter der Agenten-Vollmacht
SD-JWT VC, OID4VCI, OID4VP, Token Status List, Web Bot Auth, Verifiable Intent, AP2, RFC 9396, RFC 7662, DIDs: was jeder Standard regelt — und wie Mandact ihn nutzt.
SD-JWT VC: das Format der Agenten-Vollmacht
SD-JWT VC (Selective Disclosure JSON Web Token, Verifiable Credential) ist das Credential-Format, das EUDI-Wallet und Schweizer E-ID-Infrastruktur nutzen. Einzelne Angaben sind gehasht und werden nur bei Bedarf offengelegt — der Prüfer sieht die nötigen Felder, nicht das ganze Dokument.
OID4VCI: wie Credentials ausgestellt werden
OpenID for Verifiable Credential Issuance (OID4VCI) standardisiert, wie eine Wallet oder ein Agent ein Credential bei einem Aussteller abholt — mit Token, Nonce und Besitznachweis. Es ist der Ausstellungsweg der EUDI- und E-ID-Welt.
OID4VP: wie ein Agent sein Mandat vorzeigt
OpenID for Verifiable Presentations (OID4VP) regelt die Gegenrichtung: Ein Prüfer stellt eine Anfrage, der Inhaber antwortet mit einer Präsentation, die nur die verlangten Angaben offenlegt. Es ist der Vorzeige-Weg der EUDI-Wallet.
Token Status List: Widerruf, den jeder prüfen kann
Die Token Status List ist ein kompaktes, signiertes Bitfeld, in dem ein Aussteller den Status vieler Credentials veröffentlicht. Ein Prüfer schlägt nach, ob ein bestimmtes Credential noch gültig ist — ohne dem Aussteller zu verraten, welches er prüft.
Web Bot Auth (RFC 9421): der Agent weist sich auf HTTP-Ebene aus
Web Bot Auth nutzt HTTP Message Signatures nach RFC 9421: Ein Agent signiert jede Anfrage mit seinem Schlüssel und verweist auf ein Verzeichnis, unter dem der Schlüssel veröffentlicht ist. Netzwerke wie Cloudflare und Visas Trusted Agent Protocol erkennen ihn so als registrierten Agenten.
Mastercard Verifiable Intent: dreistufige Kette für Agenten-Käufe
Verifiable Intent (VI) ist Mastercards offene Spezifikation für Agenten-Käufe: eine dreistufige SD-JWT-Kette aus Identität des Auftraggebers (L1), Mandat (L2) und Transaktionskontext (L3). Sie ist eine der beiden Grundlagen, aus denen die FIDO Alliance ihre Agentic-Commerce-Spezifikation entwickelt.
AP2 (Agent Payments Protocol): Mandate für Agenten-Zahlungen
Das Agent Payments Protocol von Google verkettet Intent-, Cart- und Payment-Mandate als signierte Credentials und ist seit April 2026 bei der FIDO Alliance. Version 0.2 erlaubt Zahlungen ohne anwesenden Menschen auf Basis vorab erteilter Anweisungen.
RFC 9396 Rich Authorization Requests: mehr als ein Scope
Rich Authorization Requests erweitern OAuth um strukturierte authorization_details: Statt eines groben Scopes wie payments beschreibt der Antrag genau, was erlaubt sein soll — Typ, Betrag, Empfänger. Damit kann ein Access Token eine echte Befugnis tragen.
RFC 7662 Token Introspection: den Status live erfragen
Token Introspection erlaubt einem Ressourcen-Server, beim Autorisierungsserver nachzufragen, ob ein Token noch aktiv ist und was es erlaubt. Für Vollmachten ist das der Mechanismus, der einen Widerruf sofort durchsetzt.
did:web und did:key: Identifikatoren für Aussteller und Agenten
Decentralized Identifiers (DIDs) sind Kennungen, zu denen ein Dokument mit öffentlichen Schlüsseln gehört. did:web veröffentlicht dieses Dokument unter einer Domain, did:key leitet es direkt aus dem Schlüssel ab — zwei Varianten für zwei Rollen.