This local verifier checks a supplied evidence package. A successful report is not certification, endorsement, or a test of every behavior of an implementation.
AURA-STANDARD release v1.2.1 (DOI 10.5281/zenodo.22071523) retains the manifest schemas v1.0.0 and v1.1.0. Release and manifest versions differ. Source: https://github.com/romainbenabdelkader/AURA-STANDARD/tree/91b2d51fd6808c6882728c6104e75becee2b9578
src/base-schemas.js embeds the two schema objects from schema/.
The checker implements their assertion keywords: type, const, required,
properties, pattern, minLength, items and local $ref. Additional properties
remain allowed. The date-time format is annotation-only, as in the default
JSON Schema 2020-12 vocabulary. Separate verifier policy checks the declared
date calendar/offset and identifier consistency; see below. This is not a general JSON Schema engine.
Only manifest versions 1.0 and 1.1 are supported. Unknown, missing and
historical versions produce an invalid overall result. Their base-schema
dimension may still report not_checked; it never establishes version support.
Asset hashes require an explicit SHA3-256 algorithm; other declarations are
rejected and their integrity dimension is not reported as verified.
Node requires an Ed25519 public key, matching the WebCrypto import policy.
If a browser rejects a canonical Ed25519 SPKI with DataError, the verifier can
import its exact 32 public bytes instead. The full 44-byte DER wrapper is checked
before this compatibility path; digest pins still use the original DER bytes.
This handles the leading-zero public-key rejection in GCrypt-based WebKit.
Lone Unicode surrogates in property names and values are rejected under
RFC 8785 section 3.2.2.2. See compatibility notes.
The supported TDM profile is checked separately by the existing profile logic;
other profiles are not certified by a base-schema pass.
With Node.js 20 or newer, from this repository:
node bin/aura.js verify --manifest manifest.json --public-key public-key.pem --asset asset.txt --issuer issuer.json --json
node tests/run-tests.js
For a committed current-format example, use the four input files under
examples/rfc3161-freetsa/. The Python aura-core and aura-cli repositories
are historical v0.1 demonstrations, not current-format JCS signing SDKs.
To create fictional v1.0 packages locally, run
node scripts/generate-test-vector.js /path/to/a-new-directory.
This is a test generator, not an issuer onboarding or production signing tool.
Exit codes: 0 valid under the local checks; 1 warnings/incomplete checks; 2 invalid or input error. The browser verifier uses the same schema check. No external files are uploaded by these verification functions.
This contract applies starting with verifier v1.2.2.
Both verifyAuraPackage (Node) and verifyAuraPackageBrowser (WebCrypto)
expect JSON text and a public key in PEM text. A decoding failure in a supplied or embedded
PEM produces an invalid report, retaining other completed checks such as
asset integrity. If the supplied PEM cannot be decoded, its fingerprints and
issuerKeyPinOk are null; signature verification cannot succeed, and
keyStatusCheck is not_checked (or invalid_registry if the registry is
also invalid). This does not establish a signature mismatch or non-revocation.
Malformed JSON, duplicate JSON property names, and non-text JSON arguments
still reject the API promise before verification starts. They now throw
AuraInputError from src/verification-input.js, with code: "invalid_json"
and field: "manifestText" or "issuerText". Catch this error separately from
an unexpected runtime failure; neither is a successful verification. Syntactically
valid JSON with an invalid schema instead receives the usual invalid report.
For these JSON parsing errors, verify --json exits with code 2 and writes an
error object to stdout: {"status":"input_error","valid":false,"error":{"code":
"invalid_json","field":"manifestText","message":"…"}}. This is not a
verification report: signature, schema and integrity dimensions are absent
because they were not evaluated. Without --json, the CLI prints the error
to stderr. Argument, file-access and unexpected runtime errors continue to
use stderr and exit 2; callers must check the exit code, including when stdout
is empty. The browser displays a parsing error without verification badges.
Read the dimensions independently:
schemaValidation: pass/fail/not_checked, schema ID and exact field errors.signatureOk: signature verification, including the signed reference anchor.integrityStatus: exact asset bytes verified, mismatch, not checked or N/A.issuerKeyPinOk: supplied public key compared with the signed SHA3-256 pin.archiveResolution: not_checked. Presence of a DOI is not proof it resolves,
or that its archived bytes match the declared digest.archiveReferences: syntax-only inspection, with separate notices for URNs
and other non-bare-DOI references. doi_like does not establish registration,
resolution or byte integrity. Notices do not change schema or cryptographic
validity; remote archive verification remains outside this offline check.issuerIdentity: not_assessed. Supplied issuer.json is metadata, not
independent evidence that the signer represents a named organization.The generated regression fixtures use local:test identifiers and synthetic archive digests solely for syntax/cryptography tests; never copy them into production evidence. They do not pass archive verification, which is not run.
v1.0 does not require an anchor. v1.1 requires all three blocks and every required field in the pinned schema. Never fill unavailable coordinates with placeholders. The published reference-anchor template points to older, fixed reference artifacts (standard v1.1.0 and verifier v1.0.1). Those coordinates are not the same as the current standard release DOI. Use a mutually consistent artifact, version, digest and archive reference; changing a release label alone is not enough.
The template describes verifier as the reference AURA-VERIFIER artifact. The
schema fixes its name to AURA-VERIFIER. This is not a requirement to rename an
independent tool or claim that it ran. Identify the independent implementation
separately, and request clarification if its intended anchor semantics differ.
This guide does not change the published schema or resolve governance questions.
Generate a non-sensitive test asset and keep the asset, signed manifest, public key and issuer.json together. Share them with the JSON report, verifier commit, schema version and intended conformance level. Never share private keys. Run negative tests for modified assets and manifests and for malformed but correctly signed manifests. Our suite exercises both Node and WebCrypto paths.
Suggested description: “Independent implementation of the open AURA specification. Tested with [verifier commit] against [schema version]. This is not an official AURA service, certification or endorsement.”
No certification registry or new label policy is introduced by this tool.
The frozen schemas are unchanged. issuedAtValidation is separate from the
base-schema result: the verifier requires RFC 3339 syntax (T/t and Z/z accepted),
seconds and an explicit offset, and checks calendar dates and component ranges.
It does not compare the declared date with a trusted clock, certificate lifetime
or revocation time, and does not establish the date’s truth. Leap-second inputs
are not fully assessed and produce a warning, not a verified date. Negative-zero
offsets are preserved. No signed input is normalized or rewritten.
Version 1.2.0 does not compare issued_at with the local system clock. A future
date that passes syntax and calendar checks produces no future-date warning.
A date-check pass establishes format consistency only, not that issuance
occurred at that time. Applications may add a separate clock-based warning;
such a warning is not independent timestamp evidence.
Present issuer identifiers (issuer.id, reference_anchor.issuer_key.issuer_id,
issuer.json.issuer, issuer.json.issuer_id) must be non-empty strings and agree
exactly. Present signed key identifiers (issuer.key_id and the anchor’s
key_id) must agree. Optional missing v1.0 identifiers are not invented.
issuerIdentifiers reports these comparisons only, never civil or organizational
identity. The supplied registry’s current key_id need not equal an old signed
key_id: rotation and revocation are still checked by key fingerprints.
keyStatusCheck distinguishes absence of a registry, presence on its revoked
list, and absence from that supplied list. A matching current-key record with
status revoked is also refused. registryTrust explicitly leaves authenticity
and freshness unassessed. The legacy keyRevoked boolean is retained; false alone
must not be interpreted as a fresh trusted non-revocation assertion.
The human report labels the snapshot’s current record as Current registry key
status. It can be active while the examined signing key is listed as revoked.
Key revoked and the overall verdict apply to the examined key; the current
record’s active status does not override a revocation or prove registry trust.
Parsing duplicate names and semantic policy failures do not imply signature forgery. Correctly signed but inconsistent records can have signatureOk=true and an invalid overall result. Keep original evidence for historical inspection.
See AUDIT_CORRECTIONS.md before adopting this source
revision. It fixes the SHA3-256 block boundary, validates the supplied registry,
and consistently rejects non-canonical signature encodings. registryValidation
is a structural result, not a trust assertion. An invalid registry reports
keyStatusCheck: invalid_registry; never infer non-revocation from the boolean
keyRevoked alone. Historical validity remains explicitly unassessed.
Run the actual browser suite with npm run test:browser after installing the
pinned development dependency and its browsers as described in that guide.