Verifying a Conformance Log#

When a Cross App Access tester on xaa.dev reports a passing flow, you can publish a signed, shareable conformance log. xaa.dev independently re-verifies the evidence, then signs the log with its own key and stores it at a stable URL. Anyone — a partner, an IdP vendor, an auditor — can fetch that URL as JSON and cryptographically confirm that:

1. the result was issued by xaa.dev, and
2. it has not been modified since it was issued.

This turns a conformance result into tamper-evident proof, rather than a JSON file that could be edited after download.

The shareable record#

A GET on a share URL such as https://xaa.dev/conformance/cfm_… returns exactly the same conformance log every tester already produces — schema, generatedAt, result, checks, evidence, and so on — with one field added:

• jws is authoritative. It is a compact JWS (RFC 7515) whose payload is the rest of this same object (every field except jws itself), signed with EdDSA (Ed25519).
• The surrounding fields are a convenience copy for humans. Never trust them over the verified jws payload — decode jws and treat its payload as the canonical log.

How the signature proves identity#

The jws protected header carries iss (which xaa.dev deployment signed it), kid (which key), and typ: "conformance-log+jws". xaa.dev publishes its public verification keys as a standard JWKS at the well-known path on that same issuer:

{iss}/.well-known/conformance-jwks.json

Verifying the jws against that JWKS proves the log was signed by the holder of xaa.dev's private key and has not been altered by a single byte.

Verify it (Node.js, jose)#

If the signature or the payload has been tampered with, compactVerify throws — treat any error as verification failed.

Verify it in other languages#

Any JWS/JOSE library that supports EdDSA (Ed25519) works — read record.jws, decode its protected header to get iss and kid, fetch the JWKS from {iss}/.well-known/conformance-jwks.json, select the key by kid, and verify. For example:

• Python — PyJWT or joserfc
• Go — github.com/lestrrat-go/jwx
• Java — Nimbus JOSE + JWT

What xaa.dev verifies before signing#

xaa.dev never signs a result it cannot confirm itself:

• Requesting-app conformance — xaa.dev re-queries its own Authorization Server and Resource Server event logs and re-runs every check. The evidence lives on xaa.dev; the tester only names what to look for.
• Resource-app conformance — xaa.dev re-verifies the ID-JAG and access-token signatures against their issuers' published JWKS, and re-calls the protected API with the access token.

If any check cannot be independently confirmed, the request is rejected and nothing is signed.