Supported Standards

Last updated: August 28, 2026

Every specification this debugger implements, in the workflow that implements it. The right-hand column says what the tool actually does against the document rather than claiming the document whole: a debugger that overstates its coverage is worse than one that lists nothing, because people use this to learn the protocols.

Two things this list is not. It is not the list of specifications the test identity provider implements — the mock STS bundled with this project publishes its own list at /admin/sts-metadata, and it speaks the server side of most of what is below. And it is not a conformance claim: nothing here has been through a certification programme.

Where the work happens. Almost all of it is in your browser — the signing, the verification, the decoding and the key generation. Four protocols cannot be done from a browser at all and run in this tool’s API backend instead: Kerberos and SPNEGO (DER over port 88), LDAP (BER over port 389), SPIFFE’s two gRPC surfaces, and the TLS / mutual-TLS connection test. Those pages are greyed out on the hosted site and work in the containerized deployment.

OAuth 2.0
OpenID Connect
JOSE — JWS, JWE, JWK, JWA, JWT
SAML 2.0 and SAML 1.1
WS-Trust, WS-Federation, WS-Security
XML Signature and XML Encryption
Verifiable credentials — SD-JWT VC, OID4VCI, OID4VP
Decentralized identifiers and Data Integrity
WebAuthn
Kerberos v5
SPNEGO
LDAP
SCIM 2.0
Shared Signals — SSF, SET, subject identifiers
SPIFFE and SPIRE
PKI, X.509 and TLS
Cryptographic algorithms and key formats
Encoding, registries and infrastructure
Named here, and deliberately not implemented

OAuth 2.0

The OAuth2 / OIDC workflow (request and response pages), plus the introspection and UserInfo tools.

Specification	What the debugger does with it
RFC 6749 — The OAuth 2.0 Authorization Framework IETF	Authorization Code, Implicit, Client Credentials, Resource Owner Password and Refresh Token grants, built parameter by parameter and sent either from the browser or through this tool’s backend. Error responses are decoded rather than swallowed.
RFC 6750 — Bearer Token Usage IETF	The `Authorization: Bearer` presentation used by the UserInfo, Introspection, SCIM and OID4VCI credential requests.
RFC 7009 — Token Revocation IETF	Revokes an access or refresh token at the revocation endpoint, with the `token_type_hint`.
RFC 7591 — Dynamic Client Registration IETF	Registers a client at the registration endpoint from the DCR pane, with the full metadata set.
RFC 7592 — Dynamic Client Registration Management IETF	Read, update and delete of a registered client using the Registration Access Token and the client configuration endpoint.
RFC 7636 — PKCE IETF	Generates and carries `code_challenge` / `code_challenge_method` at the authorization endpoint and `code_verifier` at the token endpoint; both `S256` and `plain`, so a downgrade can be demonstrated.
RFC 7662 — Token Introspection IETF	The introspection page: posts a token to the introspection endpoint and describes every member of the response.
RFC 7800 — Proof-of-Possession Key Semantics IETF	The `cnf` claim, read wherever it appears: `cnf.jkt` on a DPoP-bound token and `cnf.jwk` as an SD-JWT VC’s holder binding.
RFC 8252 — OAuth 2.0 for Native Apps IETF	Section 7.3’s loopback port exception, which is the one carve-out the RFC 9700 exact-match redirect URI rule makes.
RFC 8414 — Authorization Server Metadata IETF	Loads `/.well-known/oauth-authorization-server`, fills the endpoints from it, and validates the document member by member — type, required/optional, and the members whose absence changes what a client may assume.
RFC 8628 — Device Authorization Grant IETF	The device authorization request, the user code and verification URI, and the polling token request with `authorization_pending` and `slow_down` handled as the specification requires.
RFC 8693 — Token Exchange IETF	Impersonation and delegation: a `subject_token`, an optional `actor_token`, an audience and a requested token type. The test suite chains two exchanges and draws the resulting delegation map.
RFC 8707 — Resource Indicators IETF	The `resource` parameter, repeatable, at the authorization and token endpoints, and the `aud` it produces.
RFC 9068 — JWT Profile for OAuth 2.0 Access Tokens IETF	The token detail and JWT tools pages recognise the `at+jwt` type and check the claims the profile requires.
RFC 9101 — JWT-Secured Authorization Request (JAR) IETF	Fetches a signed Request Object from a `request_uri` and verifies it, on the VC presentation workflow.
RFC 9207 — Authorization Server Issuer Identification IETF	Reads the `iss` authorization response parameter and checks it against the issuer the metadata named — a mixed-up issuer is reported rather than ignored.
RFC 9396 — Rich Authorization Requests IETF	`authorization_details` as a first-class request parameter, including the OID4VCI use of it to ask for a particular credential configuration and a subset of its claims.
RFC 9449 — DPoP IETF	Builds the proof JWT (`htm`, `htu`, `jti`, `iat`, `ath`), carries `dpop_jkt`, follows the `DPoP-Nonce` handshake, and reads `cnf.jkt` off the issued token.
RFC 9700 — OAuth 2.0 Security Best Current Practice IETF	A compliance mode on the request page: exact-string redirect URI matching, PKCE with S256 required of public clients, no response type that returns an access token from the authorization endpoint, no password grant, and the rest. Off by default, because the point of a debugger is to be able to send the request the BCP forbids and see what happens.
OAuth 2.0 Form Post Response Mode OpenID Foundation	`response_mode=form_post`, including the POST landing that a static deployment answers with an edge function.

OpenID Connect

Specification	What the debugger does with it
OpenID Connect Core 1.0 OpenID Foundation	All three authentication flows — Authorization Code, Implicit and Hybrid — with `nonce`, `prompt`, `max_age`, `acr_values`, `login_hint` and `display`; the ID Token decoded, its signature verified against the OP’s JWKS, and every claim described.
OpenID Connect Discovery 1.0 OpenID Foundation	Loads `/.well-known/openid-configuration` and validates it against the specification’s own table of members, side by side with the RFC 8414 document — the two differ in where the path is inserted for a tenant issuer, which is a real interoperability trap.
OpenID Connect RP-Initiated Logout 1.0 OpenID Foundation	The logout pane: `end_session_endpoint` with `id_token_hint`, `client_id`, `post_logout_redirect_uri` and `state`, and a landing page to come back to.
OpenID Connect Dynamic Client Registration 1.0 OpenID Foundation	The same DCR pane as RFC 7591/7592, with the OIDC-specific client metadata members.
UserInfo endpoint (Core 1.0 section 5.3) OpenID Foundation	The UserInfo page: calls the endpoint with the access token, from the browser or through this tool’s backend, and describes the claims that come back — in all four shapes section 5.3.2 allows. A plain JSON response, a signed one (a JWS), an encrypted one (a JWE), or a JWS inside a JWE, which is what a client that registered both gets. Every step is reported separately, because “decrypted” is not “verified”: an encrypted response proves who it was encrypted to and says nothing about who wrote it. The section 5.3.2 checks are made and named: `iss`, an `aud` that must include this client, and a `sub` that must match the ID Token’s.

JOSE — JWS, JWE, JWK, JWA and JWT

One JWS implementation serves every workflow here (Digital Signature, JWT Tools, JWKS, DPoP, SD-JWT VC and the OID4VP Key Binding JWT), so a signature that verifies on one page verifies on all of them.

Specification	What the debugger does with it
RFC 7515 — JSON Web Signature IETF	Signs and verifies in all three serializations — compact, flattened JSON and general JSON with multiple signatures — with detached payloads, protected and unprotected headers, and every registered algorithm.
RFC 7516 — JSON Web Encryption IETF	Compact serialization on the Encryption page, behind the password-protected JWK export, and for an encrypted UserInfo response. Key management: `RSA-OAEP` and `RSA-OAEP-256`, `ECDH-ES` direct and its three key-wrapping variants, `A256KW`, and `PBES2-HS256+A128KW`. Content encryption: all six of section 5 — `A128GCM`, `A192GCM`, `A256GCM` and the AES-CBC-HMAC family, `A128CBC-HS256`, `A192CBC-HS384` and `A256CBC-HS512`, whose construction is checked against RFC 7518’s own Appendix B vector and against OpenSSL. All of it works in the browser, and none of it depends on what the browser implements: Chrome does AES at 128 and 256 and refuses 192 outright — for GCM, CBC and key wrapping alike — so `A192GCM`, `A192CBC-HS384` and `ECDH-ES+A192KW` are performed in JavaScript instead, with the key wrap checked against RFC 3394’s own vectors. What a browser can do decides which engine runs here, never which algorithms you are offered.
RFC 7517 — JSON Web Key IETF	The JWKS page and every key pane: JWK and JWK Set parsing, key selection by `kid`, `use` and `alg`, and conversion to and from PEM in both directions.
RFC 7518 — JSON Web Algorithms IETF	HS256/384/512, RS256/384/512, PS256/384/512, ES256/384/512, EdDSA and `none` for signatures; the JWE algorithm and encryption identifiers above; and the JWK member layout for every key type.
RFC 7519 — JSON Web Token IETF	Decode, describe, verify, edit and re-sign. Registered claims are checked for type and time-validity; every claim gets a description from the IANA registry or from a vendor dictionary.
RFC 7638 — JWK Thumbprint IETF	Computed for DPoP’s `jkt`, for `cnf.jwk` comparisons in the SD-JWT VC workflow, and shown beside any key you generate.
RFC 7797 — JWS Unencoded Payload Option IETF	`b64: false` with the required `crit` member, signing and verifying — including the detached-and-unencoded combination that most libraries get wrong.
RFC 8037 — CFRG Curves in JOSE IETF	The `OKP` key type and `EdDSA` over Ed25519 and Ed448, plus X25519/X448 for ECDH-ES.
RFC 8725 — JSON Web Token Best Current Practices IETF	The checks the BCP asks for are applied and reported: the algorithm is chosen by the verifier and never taken from the header alone, `none` is refused unless explicitly asked for, and a key confusion between an HMAC secret and a public key is called out.
RFC 8812 — secp256k1 in JOSE / COSE IETF	`ES256K` signing and verification, and the `secp256k1` curve in a JWK.

SAML 2.0 and SAML 1.1

The SAML workflow speaks both versions of the protocol — and SAML 1.1 is a different protocol rather than an older spelling of the same one: no request message, a QName status code, and no Single Logout.

Specification	What the debugger does with it
SAML 2.0 Core OASIS	Builds an `AuthnRequest` field by field; parses a `Response`, its `Assertion`, conditions, subject confirmation, authentication statement and attribute statements, and checks every condition against the clock. Also builds and validates assertions offline on the SAML Tools page.
SAML 2.0 Bindings OASIS	HTTP-Redirect (with the DEFLATE encoding and the query-string signature), HTTP-POST, HTTP-Artifact with an `ArtifactResolve` over SOAP, and the SOAP binding itself.
SAML 2.0 Profiles OASIS	SP-initiated Web Browser SSO end to end, and Single Logout — `LogoutRequest` and `LogoutResponse`, front channel and SOAP.
SAML 2.0 Metadata OASIS	Reads an IdP’s metadata to fill the endpoints and the signing certificate, and generates the SP metadata document to hand back to the IdP.
SAML 2.0 Authentication Context OASIS	The `RequestedAuthnContext` classes offered on the request and named in the assertion — password, TLS client, Kerberos, smartcard PKI and the rest.
SAML 1.1 Core OASIS	Parses and builds a SAML 1.1 `Response` and `Assertion` — the QName `StatusCode`, `AuthenticationStatement`, `AudienceRestrictionCondition`, and the `AssertionID` rules that differ from 2.0.
SAML 1.1 Bindings and Profiles OASIS	Browser/POST and Browser/Artifact, with `TARGET` in place of `RelayState` and no request message at all — the IdP-initiated shape.

WS-Trust, WS-Federation and WS-Security

Specification	What the debugger does with it
WS-Trust 1.4 (and 1.0, 1.1, 1.2, 1.3) OASIS	Builds a `RequestSecurityToken` for Issue, Renew, Validate and Cancel against an STS, in whichever of the five namespace versions the STS wants, and parses the `RequestSecurityTokenResponse`. Delegation both ways: `<wst:OnBehalfOf>` for impersonation and `<wst14:ActAs>` for composite delegation.
WS-Security UsernameToken Profile 1.1 OASIS	The `UsernameToken` in the SOAP security header, with a password type, nonce and created timestamp.
WS-Security SOAP Message Security and WS-Addressing OASIS / W3C	Signs the SOAP request with an X.509 token in the security header, adds the `wsa:Action`, `wsa:To`, `wsa:MessageID` and `wsa:ReplyTo` headers, and speaks both SOAP 1.1 and SOAP 1.2.
WS-Federation 1.2 OASIS	The Passive Requestor Profile: reads federation metadata, builds a `wa=wsignin1.0` request with `wtrealm`, `wreply`, `wctx` and `whr`, optionally signs it, and decodes the SAML token inside the `wresult` — including an encrypted one. `wsignout1.0` as well.

XML Signature and XML Encryption

One implementation, shared by the SAML, WS-Trust, WS-Federation and Digital Signature pages and by the backend’s SAML binding signer. A canonicalizer is a reading of a specification, and two readings are two chances to disagree with the identity provider at the far end.

Specification	What the debugger does with it
XML Signature Syntax and Processing 1.1 (RFC 3275) W3C / IETF	Enveloped, enveloping and detached signatures; signing and verification; a configurable transform chain; and the `KeyInfo` forms an identity provider actually sends.
Exclusive XML Canonicalization 1.0 and Canonical XML 1.0 W3C	All four methods — inclusive and exclusive, with and without comments — with the `InclusiveNamespaces` prefix list, processing instructions retained, and namespace rendering done per element.
XML Encryption Syntax and Processing 1.1 W3C	Decrypts a SAML `EncryptedAssertion` and a WS-Federation encrypted token: `EncryptedKey` with RSA-OAEP or RSA-1.5, `EncryptedData` with AES-CBC or AES-GCM at 128/192/256.
RFC 4051, RFC 6931 and RFC 9231 — additional XML Security URIs IETF	The `xmldsig-more` algorithm identifiers: the RSA-SHA-2 family, ECDSA, HMAC variants and the digest URIs that go with each, so a `SignatureMethod` from any of the three documents is recognised rather than reported as unknown.

Verifiable credentials — SD-JWT VC, OID4VCI and OID4VP

Two workflows: issuance (a wallet obtaining a credential) and presentation (a wallet showing one to a verifier).

Specification	What the debugger does with it
OpenID for Verifiable Credential Issuance 1.0 OpenID Foundation	Both entry points — wallet-initiated, and from an issuer’s Credential Offer with the pre-authorized code grant and its `tx_code`. Issuer metadata, the Credential Endpoint with a `jwt` proof of possession, deferred issuance, the Notification Endpoint, batch issuance and response encryption.
OpenID for Verifiable Presentations 1.0 OpenID Foundation	Reads the verifier’s authorization request in any of its three forms (by value, by `request_uri`, or pasted), evaluates the DCQL query against the held credential, and returns a `vp_token` in the direct POST or redirect response mode.
RFC 9901 — Selective Disclosure for JWTs (SD-JWT) IETF	Builds and parses the SD-JWT combined format: salted digests, individual and recursive disclosures, decoy digests, array element disclosures, and the Key Binding JWT over the verifier’s nonce and audience with the `sd_hash`.
SD-JWT-based Verifiable Credentials IETF draft (draft-ietf-oauth-sd-jwt-vc)	The `dc+sd-jwt` credential format: the `vct` type, `cnf` holder binding, status and the two key-resolution routes the draft defines — `/.well-known/jwt-vc-issuer` and an inline `x5c`.
Verifiable Credentials Data Model 1.1 and 2.0 W3C	The `jwt_vc_json` and `ldp_vc` formats, with both context versions bundled locally so the workflow does not depend on a live context fetch.

Decentralized identifiers and Data Integrity

Specification	What the debugger does with it
DID Core 1.0 W3C	The DID Tools page resolves and describes a DID document, and the issuance workflow verifies a credential whose issuer is named by DID. Methods: did:web, did:key and did:jwk, with the verification relationships honoured — a key authorised to authenticate is not thereby authorised to assert.
Well Known DID Configuration DIF	Verifies domain linkage: the Domain Linkage Credential is fetched from the origin, its signature checked against the keys the DID authorises to assert, and `credentialSubject.origin` required to be the origin it came from — and to be for the DID asked about.
Data Integrity BBS Cryptosuites — bbs-2023 W3C	Selective disclosure over an `ldp_vc`: the credential is canonicalized to N-Quads, each statement becomes one BBS message, and the holder derives an unlinkable proof over the subset it chooses to reveal.
RDF Dataset Canonicalization (RDFC-1.0 / URDNA2015) and JSON-LD 1.1 W3C	Expansion to RDF quads and canonical blank-node labelling, the step everything about a Data Integrity proof depends on: one byte of difference and every signature fails while looking exactly like a broken signature.
BBS Signatures IRTF draft (draft-irtf-cfrg-bbs-signatures)	Both ciphersuites over BLS12-381, on the Digital Signature page as a primitive and behind `bbs-2023`: sign a list of messages, then derive a proof revealing any subset of them.

WebAuthn

Specification	What the debugger does with it
Web Authentication Level 3 W3C	The Lab runs a real registration and authentication ceremony against a security key with this origin as the relying party; the Analyzer decodes and verifies somebody else’s artifacts with no ceremony at all — client data, authenticator data and its flags, attestation object, the COSE public key, the signature counter, and extension outputs. Attestation statement formats recognised: `packed`, `tpm`, `android-key`, `android-safetynet`, `apple`, `fido-u2f` and `none`.
RFC 9052 and RFC 9053 — COSE IETF	Reads a `COSE_Key` into a JWK and a SPKI PEM, handling the negative labels correctly per key type — `-1` is the curve for an EC2 key and the modulus for an RSA one.
RFC 8949 — CBOR IETF	A decode-only, bounded reader. Maps decode to a real `Map`, because COSE keys include negative integers; indefinite lengths are refused, because canonical CBOR forbids them and one in an attestation object is a finding rather than something to absorb.

Kerberos v5

Six pages, and the only workflow here that is not HTTP: DER over TCP and UDP port 88, relayed byte for byte by this tool’s backend.

Specification	What the debugger does with it
RFC 4120 — The Kerberos Network Authentication Service (V5) IETF	The AS exchange with the `KDC_ERR_PREAUTH_REQUIRED` round trip and `PA-ETYPE-INFO2`, the TGS exchange, renewals, cross-realm referrals and the AP exchange. Every message, ticket and error is decoded field by field and the encrypted parts are opened when you hold the key.
RFC 3961, 3962, 8009 and 4757 — Kerberos encryption IETF	The encryption-type framework and five etypes: `aes128-cts-hmac-sha1-96`, `aes256-cts-hmac-sha1-96`, `aes128-cts-hmac-sha256-128`, `aes256-cts-hmac-sha384-192` and `rc4-hmac` — with string-to-key, salting and key derivation, verified against the RFCs’ own test vectors.
RFC 4121 and RFC 2743 — the Kerberos GSS-API mechanism IETF	The GSS token framing a real service is handed: the InitialToken wrapper, the checksum with its channel-binding and flag fields, the delegated credential, and the AP-REP that proves the service back.
[MS-PAC] — Privilege Attribute Certificate Microsoft Open Specifications	Decodes the PAC inside a ticket — logon info, group membership, the UPN and client name buffers, and the two signatures — including the NDR encoding ([MS-RPCE]) and the types from [MS-DTYP] and [MS-SAMR] that it carries.
[MS-SFU] — Service for User and Constrained Delegation Microsoft Open Specifications	The delegation page: S4U2Self, S4U2Proxy under either authorization model, and forwarded tickets — with the refusals shown as clearly as the successes.
[MS-KILE] — Kerberos Protocol Extensions Microsoft Open Specifications	The Windows-specific fields and flag semantics a real domain controller sends, which is what the AWS-hosted Windows Server 2025 test run exists to keep honest.
MIT keytab file format MIT Kerberos	The decoder reads a keytab: versions 0x0501 and 0x0502, every entry, principal, key version and encryption type.

SPNEGO

Specification	What the debugger does with it
RFC 4178 — SPNEGO (and its predecessor RFC 2478) IETF	Encodes and decodes `NegTokenInit` with the optimistic mechToken and `NegTokenResp` in all four `negState` values, with the `mechListMIC` in both directions and section 5’s rule for when it is mandatory.
RFC 4559 — SPNEGO-based HTTP Authentication IETF	The SPNEGO page: the `401 WWW-Authenticate: Negotiate` challenge, the token a browser would send, and the AP-REP that comes back in the response header — every byte visible, which a cross-origin `fetch` cannot give you.
[MS-SPNG] Microsoft Open Specifications	The Windows variations on the negotiation, including where they differ from RFC 4178 in a way a client has to tolerate.

LDAP

RFC 4511 is BER over a TCP socket, so the whole protocol runs in this tool’s backend and the page is available only in the containerized deployment.

Specification	What the debugger does with it
RFC 4511 — LDAP v3: The Protocol IETF	Bind and unbind, search, add, delete, modify, modifyDN and compare, over plain TCP or LDAPS, with every result code reported by name rather than by number.
RFC 4512 — Directory Information Models IETF	The root DSE, the naming model, and the object class rules a directory enforces on an add.
RFC 4514 — String Representation of Distinguished Names IETF	Parses and composes DNs, with the escaping rules that decide whether a comma in a CN is a separator.
RFC 4515 — String Representation of Search Filters IETF	The full filter grammar — presence, equality, substring, greater/less, approximate, extensible match and the boolean combinators — with all three search scopes.
RFC 4519 — Schema for User Applications IETF	The attribute types and object classes the user and group forms are built from.
RFC 2696 — Simple Paged Results Control IETF	Pages a large search, carrying the cookie from one page to the next.

SCIM 2.0

The provisioning page: every endpoint by hand, or scenario batches that create, modify and deprovision populations of users and groups and check each step against what the plan said would happen.

Specification	What the debugger does with it
RFC 7642 — SCIM: Definitions, Overview, Concepts and Requirements IETF	The use cases the scenario harness is built from — onboarding, change, offboarding — and the vocabulary the page uses.
RFC 7643 — SCIM: Core Schema IETF	User, Group, EnterpriseUser and the common attributes, including a generator for a User carrying every optional attribute section 4.1 defines — which is how you find out what a server silently drops.
RFC 7644 — SCIM: Protocol IETF	Create, read, list, replace, PATCH (section 3.5.2 in full, including `emails[type eq "work"].value` paths), delete, both shapes of `.search`, bulk, filtering, sorting, pagination, attribute projection and the three discovery documents.
RFC 7235, 7617, 7616 and 7486 — HTTP authentication schemes IETF	All the schemes RFC 7644 section 2 names: Basic, Digest (all three registered algorithms — SHA-256, SHA-512-256 and MD5 — with the `-sess` variants and the `stale` retry), HOBA, bearer and DPoP tokens, a session cookie, and a TLS client certificate.

Shared Signals — SSF, Security Event Tokens, subject identifiers

The Shared Signals page, and the one protocol here that runs the other way round: SAML and OpenID Connect authenticate at one instant, and the session that follows stays good for hours whatever happens next. Shared Signals inverts it — the identity provider tells the relying party when something changed.

SSF is the pipe and not the vocabulary. It defines how two parties agree a stream, who the events are about, what they travel in and how they get there — and exactly two events of its own, both about the pipe. The vocabularies are CAEP (what happened to a session) and RISC (what happened to an account); both are named in deliberately not implemented below, and the page says so itself rather than leaving a two-item list to be read as a broken page.

Specification	What the debugger does with it
OpenID Shared Signals Framework 1.0 — final, 2 September 2025 OpenID Foundation	The receiver’s half in full: the transmitter configuration metadata, the stream management API (create, read, replace, merge, delete), the status endpoint with all three statuses, add and remove subject, verification, and both of the two event types SSF defines. Every endpoint is discovered from the metadata document — SSF fixes no paths, so this page composes none. Complex subjects and `critical_subject_members` are implemented, and the page can also act as the transmitter: build any event, sign it, and push it at a receiver.
RFC 8417 — Security Event Token (SET) IETF	The envelope: a JWT with an `events` map keyed by event-type URI, `iss`/`jti`/ `iat`/`aud`, the subject in `sub_id`, and optional `txn` and `toe`. No `exp` — section 4.1.4 says a SET must not be considered to expire, and one that carries an `exp` is reported as a finding. So is a `sub` claim, which section 2.2 discourages and which a client reading it takes for the subject.
RFC 9493 — Subject Identifiers for Security Event Tokens IETF	All eight formats — `account`, `email`, `issuer_subject_id`, `opaque`, `phone_number`, `decentralized_identifier`, `uri` and `aliases` — with each format’s closed member set enforced: an identifier carrying a member its format does not define is one every conforming receiver must reject, and it looks perfectly fine in a log. The section 3.2.8 ban on nesting an `aliases` identifier is refused rather than flattened.
RFC 8935 — Push-Based Delivery of Security Event Tokens IETF	Both directions. This tool pushes a SET it signed, as `application/secevent+jwt` — or as `application/jwt` on purpose, which is the only way to find out whether a receiver dispatching on the media type drops it. Receiving a push needs this tool’s backend, because a browser cannot be an HTTP server: that is the specification rather than a limitation here, and it is the one thing the hosted site cannot do.
RFC 8936 — Poll-Based Delivery of Security Event Tokens IETF	The receiver comes to the transmitter, so this one works with no backend at all. `ack` for what was stored, `setErrs` for what was refused — both take an event off the transmitter’s queue — and `moreAvailable`, which is the member a client most often ignores and which means one poll does not drain the queue.

SPIFFE and SPIRE

Two of SPIFFE’s three surfaces are gRPC, which a browser cannot produce, so the page runs against this tool’s backend and is available only in the containerized deployment.

Specification	What the debugger does with it
SPIFFE-ID SPIFFE (CNCF)	The whole grammar, checked on the raw text rather than through a URL parser — which is the point, because `new URL()` lower-cases a host for you and hides an upper-case trust domain that is invalid.
X509-SVID and JWT-SVID SPIFFE (CNCF)	Fetches and inspects both: the URI subjectAltName and the constraints an X509-SVID must satisfy, and the JWT-SVID’s audience and claims.
SPIFFE Trust Domain and Bundle SPIFFE (CNCF)	Reads a trust bundle document, including the rule that costs people days: a JWK with no `use` is one a consumer MUST ignore, so a bundle of them verifies nothing and reports no error anywhere.
SPIFFE Workload API and Workload Endpoint SPIFFE (CNCF)	Calls the Workload API over a Unix domain socket or TCP, unauthenticated as the specification requires — a workload has no root of trust until that call gives it one.
SPIRE Server API SPIRE (CNCF)	All forty-two methods across its six services — Agent, Bundle, Debug, Entry, SVID and TrustDomain — over mutual TLS — where hostname verification cannot apply, because a SPIRE server’s certificate carries no DNS name, and is replaced by a check on the SPIFFE ID in its URI subjectAltName. The `.proto` files are vendored verbatim.

PKI, X.509 and TLS

The certificate authority page builds a Root, an Intermediate and an Issuing CA in the browser, and then makes a real connection with what it issued.

Specification	What the debugger does with it
RFC 5280 — X.509 certificates and CRLs IETF	Issues certificates with full X.509v3 extension control — basic constraints, key usage, extended key usage, SAN in every name form, name constraints, policies and policy mapping, AIA and CRL distribution points, SKI and AKI — and validates a chain: signatures, validity, path length, and the extension rules that decide whether a CA may sign what it signed. CRLs are referenced rather than issued: the CRL distribution point and freshest-CRL extensions are built and read, and nothing here produces a revocation list.
RFC 2986 — PKCS#10 Certification Request IETF / RSA	Generates and parses a CSR, with the requested extensions in the attribute set.
RFC 7633 — TLS Feature (“must-staple”) IETF	Available as an extension when issuing, and named when describing a certificate that carries it.
RFC 4556 — PKINIT IETF	The `KRB5PrincipalName` otherName SAN and the PKINIT extended key usages, so a certificate meant for smartcard logon can be built and recognised.
RFC 8446 (TLS 1.3) and RFC 5246 (TLS 1.2) IETF	Makes a real TLS or mutual-TLS connection with a certificate you just issued and reports the handshake: version, cipher suite, the chain the server sent, the anchor it verified against, and whether the client certificate was accepted. A browser can do none of that — it cannot choose a client certificate, cannot be given a truststore, and cannot read the handshake it made — so this runs in the backend.

Cryptographic algorithms and key formats

The Digital Signature and Encryption / Decryption pages, and the key-material pane every workflow shares. All of it runs in your browser and none of it is stored.

Specification	What the debugger does with it
RFC 8017 — PKCS #1 v2.2 (RSA) IETF / RSA	RSASSA-PKCS1-v1_5 and RSASSA-PSS signing; RSAES-OAEP and RSAES-PKCS1-v1_5 encryption, with the maximum message length reported the moment a key is generated, because it depends on the modulus, the padding and the hash.
FIPS 186-5 and SEC 2 — ECDSA and the named curves NIST / SECG	ECDSA over P-256, P-384, P-521 and secp256k1, against any hash on the page; Schnorr (BIP-340) over secp256k1; and the curve parameters used by `did:key` point decompression.
RFC 8032 — EdDSA IETF	Ed25519 and Ed448 signing and verification, and the `OKP` JWK and PEM encodings that carry those keys.
RFC 7748 and RFC 8410 — X25519/X448 and their ASN.1 encoding IETF	ECDH over the CFRG curves for ECIES and for JWE `ECDH-ES`, and the SubjectPublicKeyInfo / PKCS#8 forms that carry Ed and X keys.
FIPS 203, FIPS 204 and FIPS 205 — ML-KEM, ML-DSA, SLH-DSA NIST	Post-quantum, at every parameter set: ML-KEM-512/768/1024 for encapsulation (alone or hybridised with X25519), ML-DSA-44/65/87 and all twelve SLH-DSA parameter sets for signing.
FIPS 197 and NIST SP 800-38A/D — AES and its modes NIST	AES at 128/192/256 in GCM, CBC, CTR, CFB, OFB and ECB, with PKCS#7 padding where the mode needs it — and ECB offered precisely so its failure mode can be seen.
RFC 8439 — ChaCha20 and Poly1305 IETF	The AEAD construction, the bare Poly1305 MAC and the raw ChaCha20 keystream, verified against the RFC’s own vectors.
RFC 2104 and RFC 4493 — HMAC and AES-CMAC IETF	The MAC panes: HMAC over any hash, KMAC, keyed BLAKE, AES-CMAC, CBC-MAC, GMAC, Poly1305 and SipHash — labelled separately from the signature panes, because a MAC uses a shared secret and is not a digital signature.
RFC 5869 (HKDF), RFC 8018 (PBKDF2 / PKCS #5) and RFC 7914 (scrypt) IETF	Key derivation: the password-based pane, the PBES2 JWE that protects an exported key, and the HKDF step inside ECIES and DHIES.
RFC 3526 — MODP Diffie-Hellman groups IETF	Groups 14 and 15 behind ElGamal and DHIES on the finite-field pane. (There is no such thing as DSA encryption, and the pane says so rather than mislabelling something else.)
FIPS 180-4, FIPS 202 and RFC 7693 — hash functions NIST / IETF	SHA-1, the SHA-2 family, SHA-3 and SHAKE, BLAKE2b, BLAKE3, RIPEMD-160 and MD5 — the broken ones included and labelled as such, because interoperating with something old is a real debugging need.
PKCS #8 (RFC 5958), PKCS #12 (RFC 7292), PKCS #9, PEM (RFC 7468) and RFC 5915 IETF / RSA	The export matrix every key pane offers: PEM, DER, JWK and PKCS#12, encrypted or not, in both directions — and a keystore you can hand straight to OpenSSL, Java or a browser. PKCS #1 and SEC 1 private key framings are read as well as written.
ITU-T X.680 / X.690 — ASN.1 and DER ITU-T	Underneath all of the above, and visible in its own right in the Kerberos decoder and the certificate describer.

Encoding, registries and infrastructure

Specification	What the debugger does with it
RFC 4648 — Base16, Base32, Base64 and Base64url IETF	The encoding tools, and every place a token, certificate or key is shown — base64url without padding where the specification says so, which is a surprisingly common source of “invalid signature”.
RFC 3986 — Uniform Resource Identifier IETF	Percent-encoding and decoding on the encoding tools page, the exact-match redirect URI comparison in RFC 9700 mode, and the `htu` normalization a DPoP proof needs.
RFC 4122 — UUIDs IETF	Message and assertion identifiers, in the NCName form XML requires (an XML `ID` may not start with a digit).
RFC 1951 — DEFLATE IETF	The SAML HTTP-Redirect binding’s compression, used when composing a request and when reading somebody else’s on the SAML decoder pages. Raw DEFLATE, with no zlib header, which is the detail that makes a redirect message undecodable in half the tools that try. (WS-Federation does not compress: its sign-in request is plain query parameters.)
IANA JSON Web Token Claims Registry IANA	Every registered claim gets its registered description in the JWT and token detail views, from a cached copy of the registry — alongside a dictionary of vendor claims that are not registered anywhere.
XML 1.0 and Namespaces in XML W3C	Parsed inertly — no external entities, no DTD, no network fetch — because a SAML response is a document from somebody you are still deciding whether to trust.

Named here, and deliberately not implemented

Things the pages mention, and that a reader could reasonably read as a claim. They are not.

Specification	Why not
OpenID CAEP 1.0 — Continuous Access Evaluation Profile OpenID Foundation	Not yet. CAEP is the enterprise session vocabulary spoken over SSF — session revoked, token claims change, credential change, assurance level change, device compliance change — and it says this session is no longer trustworthy. The Shared Signals page names it and marks it absent rather than leaving a two-item event list to be read as a broken page. The pipe it needs is all there; adding it is rows in one table.
OpenID RISC 1.0 — Risk Incident Sharing and Coordination OpenID Foundation	Not yet. RISC is the account-lifecycle vocabulary, aimed across providers rather than within one enterprise — account disabled, purged, credentials compromised, identifier changed or recycled — and it says this account is no longer trustworthy, which is a different sentence from CAEP’s. Same position as CAEP above.
CTAP2 FIDO Alliance	JavaScript receives a WebAuthn ceremony’s artifacts and never the authenticator: no commands, no USB frames, no PIN protocol. This is a WebAuthn debugger and not a CTAP one; a CTAP debugger needs a native application with HID access.
RFC 8705 — mTLS client authentication and certificate-bound tokens IETF	Named on the DPoP pane as the other way to sender-constrain a token. The debugger does mutual TLS on the PKI page, but it does not do RFC 8705 token binding at an OAuth token endpoint.
[MS-KKDCP] — Kerberos KDC Proxy Microsoft Open Specifications	The bundled mock KDC answers it; the debugger’s own Kerberos transport is raw TCP and UDP only.
RFC 6113 — Kerberos FAST IETF	The `FX-COOKIE` pre-authentication type is recognised and named in a decoded message. The armoured exchange itself is not performed.

Found something wrong? A list like this is only worth having if it is accurate. Corrections and additions go to the issue tracker.