Public sandbox

Test against a live AAS Studio endpoint

Interoperability is not a diagram. If you build an AAS server, a GS1 resolver, a verifiable-credential verifier, or a product-trust layer, point it at the live, conformant, public surfaces below and prove your tool composes with ours against a real endpoint. No key, no account, synthetic data. Every request on this page runs today.

Nothing here asks you to trust us. Hash the bytes yourself, compare them to the strong ETag we served, and repeat the request tomorrow to confirm they have not moved. A verifier can bind at this boundary without touching our registry, discovery or authorization. Add at the boundary. Don't replace the stack.

Live surfaces

Four anonymous, production surfaces you can bind to:

GS1 Digital Link resolver: a phone-scannable identifier resolves to the DPP. Content-negotiated via Accept: JSON, XML, or HTML (302 to the viewer).
GET https://aas-studio.eu/api/dpp/01/9580000000015
Strong ETag content anchor: every representation carries a strong ETag that is the SHA-256 of the exact bytes served, per representation. Your independent digest of the entity body equals our ETag. If-None-Match → 304.
Representation version: every DPP delivery response carries X-DPP-Representation-Version (currently 1). It names the SHAPE of the response, never its content, and it is the discriminator you need when a digest you anchored stops matching:
• hash changed, version unchanged → the passport content moved. Check canonicalSha256 on /integrity, which is what our ES256 signature actually commits to.
• hash changed, version bumped → we changed the serialisation. Re-baseline; the content may be identical.
We bump it in the same change that alters the served bytes, and a CI gate fails the build if the envelope shape changes without it. It rides in a header, not the body, so introducing it did not alter a single byte anyone had already anchored.
One caveat, stated rather than left to be discovered: on a 304 Not Modified the edge strips non-standard headers, so this one is absent there (as is X-DPP-Tier). That is harmless: a 304 means your If-None-Match matched our ETag, which is the digest of the exact bytes, so the representation is provably the one you already hold. The version is present on every 200, which is the only case where it can have changed.
Live Asset Interface Description (IDTA-02017): an AID submodel whose HTTP interface points at a live datapoint that returns a changing value. Poll it like any WoT/AID client.
GET https://aas-studio.eu/api/demo/voltage
Conformance gate: served AAS is validated against the AAS 3.1 XSD + the AASd-* metamodel constraints + the official IDTA aas-test-engines. Send us an AAS and get a precise report back.

Run the boundary test

The boundary handshake, reproducible in three commands. Resolve, hash the exact bytes, and confirm your digest equals our strong ETag:

# 1) resolve the DPP (anonymous, public tier)
curl -s https://aas-studio.eu/api/dpp/01/9580000000015 \
  -H "Accept: application/json" -o body.json

# 2) your independent SHA-256 of the exact bytes
shasum -a 256 body.json

# 3) our strong ETag for the same representation
curl -sI https://aas-studio.eu/api/dpp/01/9580000000015 \
  -H "Accept: application/json" | grep -i etag
# -> the quoted value equals your digest from step 2. Deliberately not
#    reproduced here: a hash printed in documentation is stale the moment
#    the content changes, and then it disproves the very claim it is
#    meant to demonstrate. Compare against the header you just received.

# 4) record the representation version alongside your receipt
curl -sI https://aas-studio.eu/api/dpp/01/9580000000015 \
  -H "Accept: application/json" | grep -i x-dpp-representation-version
# X-DPP-Representation-Version: 1
# -> if this number is still 1 when a future digest stops matching,
#    the CONTENT moved. If it changed, the SHAPE did.

Confirm change detection with a conditional GET:

# feed back the ETag you received, rather than one copied from a page
ETAG=$(curl -sI https://aas-studio.eu/api/dpp/01/9580000000015 \
  -H "Accept: application/json" | grep -i '^etag:' | tr -d '\r' | cut -d' ' -f2-)

curl -s -o /dev/null -w "%{http_code}\n" \
  -H "Accept: application/json" -H "If-None-Match: $ETAG" \
  https://aas-studio.eu/api/dpp/01/9580000000015
# 304  (unchanged)  ->  a mutation flips this to 200 with a new ETag

Poll the live AID datapoint:

curl -s https://aas-studio.eu/api/demo/voltage
# {"value":51.2,"unit":"V","at":"..."}  (moves on every read)

Bring your tool

Pick the experiment that fits what you build:

AAS server / SDK (BaSyx, FA³ST, aas-core3.0, …): load one of our AAS files, re-serialize it, and confirm the canonical bytes and the strong ETag survive the round-trip.
GS1 Digital Link resolver: point your resolver at our Digital Link, follow it to the AAS endpoint, and confirm content-negotiation + the ETag match end-to-end.
Verifiable-credential verifier / EUDI wallet: we issue a VC attesting a DPP's content hash; your wallet validates it against the live endpoint bytes, and we test revocation.
Product-trust / anti-counterfeit layer: your verify step calls our endpoint, hashes the exact bytes, matches our ETag, and we co-sign a receipt.
Live-asset runtime (Node-RED, OPC-UA/MQTT gateways): read our AID submodel and poll the datapoint, or serve one we point our AID poller at.

What you get

A clean, byte-level interop result both sides can publish.
An independent conformance signal for your tool against a live, standards-native endpoint.
No integration lift: the surfaces are public and anonymous, so you test on your schedule.
The full IDTA-01002 Part 2 Shell/Submodel Repository API, machine-readable: OpenAPI 3.0 schema at /api/v3/openapi.json, self-description (profiles, capabilities) at /api/v3/description.

The existing registry, discovery and authorization stay exactly as they are. You compose at the boundary, you don't rebuild it.

Propose an experiment

Ran the boundary test, or want a scoped one for your tool? Tell us what you found. Public sandbox, synthetic data, no account, and we set up our side same-day.