DEVELOPER REFERENCE · STEP 4 + STEP 8 + STEP 9

Portable AstruVerify assertions

Verified results are issued as compact, signed JWTs so a relying organisation can validate the result without sharing AstruVerify's private signing key.

Current assertion profile

Format
JWT / compact JWS
Algorithm
RS256
Profile
1.1 · environment-aware
Token type
astruverify+jwt
Issuer
https://astruverify.com
Current key ID
3FLov2L5BpISzcNGFQaLoccdspuSjujQRmyOvHZ9NH8
Public keys
/.well-known/jwks.json
Metadata
/.well-known/astruverify-configuration

What a relying organisation must validate

  1. Require exactly alg=RS256 and typ=astruverify+jwt; do not accept an algorithm supplied dynamically by the token.
  2. Use the header kid to select the matching RSA public key from AstruVerify's JWKS.
  3. Verify the JWS signature over the compact header and payload.
  4. Require the exact configured iss and the organisation's own expected aud.
  5. Validate nbf and exp and reject expired tokens.
  6. Use jti and verification_request_id for traceability and replay controls.
  7. Require astruverify_version=1.1 and the exact environment your integration expects (test or live). Treat older profile 1.0 assertions as TEST-only.
  8. Read only the fields under verified_claims that the citizen consented to release.
Step 9 supports signing-key rotation. The current key signs new assertions, while public keys listed in AstruVerify:AssertionValidationPublicKeyPaths remain published in JWKS for the overlap period so still-valid older tokens can be verified.