Find files, editable templates and browser test targets by what you need to make or test. Explore complete business kits for connected records, templates and expected results.
Page 162 of 221; 24 results per page.
The P-256 key behind the EC leaf certificate, in PKCS#8. Its scalar is derived deterministically from a fixed label so the whole wave reproduces byte for byte.
The same P-256 scalar in the SEC 1 container (BEGIN EC PRIVATE KEY), which names the curve inline instead of through a PKCS#8 algorithm identifier. Some deployment tools accept only one of the two.
The P-256 public key in SubjectPublicKeyInfo form, carrying the named-curve OID and an uncompressed point. It matches the EC leaf certificate and the EC entry in the p7 JWK set.
The Ed25519 key behind the Ed25519 leaf and the EdDSA JWTs, in PKCS#8. RFC 8410 keys have no traditional-OpenSSL container at all, which is why only one serialisation ships.
Sample GraphQL Schema: small deterministic fixture for parsers and the in-browser editor.
Binary DER encoding of the SAMPLE intermediate CA certificate: the same bytes the PEM twin Base64-wraps. Feed it to ASN.1 decoders, Java keystores, and DER-to-PEM converters.
The issuing CA that signs every leaf in this wave, itself signed by the SAMPLE root and constrained with pathLenConstraint:0 so it cannot mint further CAs. Use it to test intermediate handling and path-length enforcement.
A single P-256 public JWK. Its x and y are fixed 32-byte base64url values, left-padded when a coordinate happens to be short: the padding rule that libraries stripping leading zeroes get wrong.
An OKP-type JWK holding the Ed25519 key pair as raw 32-byte x and d values. OKP is the newest JWK key type and the one older JOSE libraries reject outright.
The full RSA private key as a JWK, including the CRT parameters p, q, dp, dq and qi. It is the input for testing JWK-to-PEM conversion, where dropping the CRT values quietly costs a large amount of signing performance.
The symmetric HMAC secret used by this wave's HS256 tokens, expressed as an oct JWK. The secret is printed in the specs on purpose so a verifier can be wired up without guessing.
Two keys of different types published under the same kid: what a botched key rotation leaves behind. A resolver that returns the first match silently verifies against the wrong key type instead of reporting the ambiguity.
A JWK Set whose keys carry no kid at all, which RFC 7517 permits. Verifiers must then fall back to trying candidates by algorithm, and the ones that index the set by kid alone find nothing.
A three-key JWK Set publishing the public halves of this wave's RSA, P-256, and Ed25519 keys, each with a distinct kid. It is the resolver input for every p7 JWT, so kid selection can be tested against a set that really has more than one candidate.
A JWK carrying the full x5c certificate chain and an x5t#S256 thumbprint alongside the raw n/e values. The x5c array is standard Base64 while every other JWK field is base64url: a real and frequently mis-implemented detail.
The single-signature flattened JSON form of the exact same RS256 token shipped in compact serialization. Both encodings must verify to the identical payload, which is the round-trip this pair is for.
One payload carrying two independent signatures (RS256 and EdDSA) in the General JSON serialization that the compact form cannot express. Multi-signature handling is the part of RFC 7515 most libraries never implemented.
A sample JSON Web Token (JWT) signed with HS256 using a published example secret (verifiable but powerless) for testing JWT decoders and validators. Sample only, never for production. Paired with its decoded claims.
An unsecured JWS: alg is none and the signature segment is empty, leaving only the trailing dot. Any verifier that accepts it will accept a claim set an attacker wrote, which is why this is the first negative test to run.
The classic algorithm-confusion shape: a token that claims HS256 while its kid points at an RSA key, MACed with that key's public PEM as the shared secret. A verifier that picks its algorithm from the header rather than from the key type accepts it.
The decoded header and payload of the sample JWT as JSON, alongside the public signing secret and algorithm: the ground truth for checking a JWT decoder's output.
The EdDSA token with one bit of its signature flipped. Ed25519 verification either succeeds or fails with no partial credit, which makes this the cleanest possible negative case.
An EdDSA (Ed25519) token with a fixed 64-byte signature and the same claim set as the RS256 reference. EdDSA signing is deterministic, so this token is reproducible in a way an ES256 one could never be.
A symmetric HS256 token whose secret is printed in the specs and shipped as an oct JWK, so a verifier can be stood up without any key exchange. It shares its claim set with the RS256 reference token.
We use Google Analytics and show ads via Adsterra. Non-essential cookies and ad scripts run only after you allow the matching categories. See our cookie policy.
