AAS labels the shell's asset identity "gtin" whatever scheme issued it

[LKSNDRTMLKV]

Found by the #328 identifier scan.

build_aas_from_passport takes the asset identity as a bare gtin: &str and emits it twice under a GS1 label:

// crates/dpp-aas/src/builder.rs:89
SpecificAssetId { name: "gtin".into(), value: gtin.to_owned() }
// :124
global_asset_id: format!("urn:odal-node:product:{gtin}")

The doc comment on the function already says so, and calls it pre-existing.

Why it is worth a ticket now rather than staying a documented quirk

#295 made it reachable. While every product group payload carried a mandatory gtin, the label was always true — a caller had nothing else to pass. EN 18219 schemes 2 and 3 are self-issuing and carry no GTIN, so the label is now false for exactly the passports the identifier work exists to enable.

That is the same shape as dpp-engine #376, where a GTIN was scraped out of the carrier URI and the internal UUID substituted when there was none: a scheme-1 assumption that was harmless only because scheme 1 was universal.

It matters more here than in an internal struct because an AAS Environment is an interop document. A consuming toolchain reads specificAssetIds by name; one asking for gtin and receiving did:web:acme.example.com:b:1 has been told something untrue by a document it treats as authoritative. globalAssetId carries the same value into a urn:odal-node:product: URN.

The tension to resolve, which is why this is a decision and not a patch

The parameter is deliberately not read off the passport — the unsold-goods mapper's module note records why: the asset identity is the caller's, and a file export or an AASX package assembled for a reporting authority may legitimately key on something that is not the passport's product identifier at all. So "just use product_identifier()" is not the answer; it would break the case the parameter exists for.

Options, roughly in increasing cost:

1. Name the slot from the value. Take &ProductIdentifier where the caller has one and derive the specificAssetId name per scheme — reusing dpp_registry::{SCHEME_GTIN, SCHEME_IDENTIFICATION_LINK, SCHEME_DID}, which already state those three strings once and record all three as RegistryBasis::Assumed.
2. Take a (name, value) pair and keep the identity fully the caller's, which makes the mislabel impossible to produce by accident but pushes the choice out.
3. Keep &str, rename the slot to something scheme-neutral (productIdentifier) — cheapest, but silently changes a key an existing AAS consumer may match on.

Option 1 is the one that matches what dpp-registry already does for the same question on the registry wire.

Check while fixing

crates/dpp-tests/fixtures/aas/environments/*.json carry "gtin" as a specificAssetId name in all twelve environments; whichever option is taken, those goldens move with it.

Related: #328, #295, #322.

[LKSNDRTMLKV]

Options, and the one I recommend

	Shape	Mislabel still possible?	Keeps the caller-chosen identity?
1	Take &ProductIdentifier, derive the slot name per scheme	no	no — breaks the case the parameter exists for
2	Take a (name, value) pair	yes, by a careless caller	yes
3	Keep &str, rename the slot productIdentifier	yes — still one fixed name for any value	yes
4	An AssetIdentity enum: either the passport's identifier, or an explicitly named pair	no	yes

🚨 Recommended: option 4

Options 1 and 2 each solve half. The unsold-goods module note records why the identity is the caller's — a file export or an AASX package assembled for a reporting authority may key on something that is not the passport's product identifier at all — so option 1 breaks a real case. Option 2 keeps that case but leaves the mislabel one careless argument away, and option 3 does not fix the defect at all: a fixed slot name is what is wrong, whatever the name is.

Making the identity self-describing covers both:

pub enum AssetIdentity<'a> {
    /// The passport's own EN 18219 identifier. The `specificAssetId` name is
    /// derived from the scheme, so it cannot disagree with the value.
    Product(&'a ProductIdentifier),
    /// A caller-chosen asset key — a file export, an AASX package for an
    /// authority, an asset that is not a trade item.
    Named { name: &'a str, value: &'a str },
}

The common path becomes correct by construction; the escape hatch stays and now has to be asked for by name, which is the point — a caller passing an internal key is making a visible choice rather than inheriting a default that happens to be wrong.

Scheme names come from dpp_registry::{SCHEME_GTIN, SCHEME_IDENTIFICATION_LINK, SCHEME_DID}, which already state those three strings once and already record all three as RegistryBasis::Assumed. No fourth spelling.

Cost, stated plainly

• Breaking signature change to build_aas_from_passport and build_aas_environment. ~10 call sites, all inside dpp-aas (tests and one example) — none in production code in this repo. Any real caller lives outside it.
• 12 AAS golden environments regenerate.
• globalAssetId currently interpolates the same value into urn:odal-node:product:{…}. Worth deciding in the same change whether a non-GTIN identity belongs in a :product: URN at all.

Sequence it with #333

#333 moves the same 12 goldens. Doing them as one change regenerates them once and settles "does the AAS carry the scheme or only the value" in one place rather than twice with a chance of disagreeing.

[LKSNDRTMLKV]

✅ DECISION LOCKED — option 4, the AssetIdentity enum

Locked by the founder 2026-09-22. Not to be re-derived; implement this shape.

build_aas_from_passport and build_aas_environment take an AssetIdentity rather than gtin: &str:

• AssetIdentity::Product(&ProductIdentifier) — the specificAssetId name is derived from the clause 5 scheme using dpp_registry::{SCHEME_GTIN, SCHEME_IDENTIFICATION_LINK, SCHEME_DID}. No fourth spelling of those three strings.
• AssetIdentity::Named { name, value } — the caller-chosen key the unsold-goods module note requires, now asked for by name rather than inherited as a default that happens to be wrong.

Rejected: deriving from the passport alone (breaks the file-export / AASX case), a bare (name, value) pair (mislabel one careless argument away), and renaming the slot (a fixed name is the defect, whatever the name).

Sequenced with #333 — same 12 AAS goldens, same open question about whether the scheme travels.

Open sub-question carried into implementation, not settled by this lock: what globalAssetId should be when the identity is not a GTIN. See the edge-case note following.

[LKSNDRTMLKV]

Edge-case testing of the locked decision — it holds, and the open sub-question now has an answer

Ran the current builder against four identity values. Output, verbatim:

--- 09506000134352
    globalAssetId    = urn:odal-node:product:09506000134352
    specificAssetIds = ["gtin=09506000134352", "serialId=01a0…"]
--- https://id.acme.example.com/b/1
    globalAssetId    = urn:odal-node:product:https://id.acme.example.com/b/1
    specificAssetIds = ["gtin=https://id.acme.example.com/b/1", "serialId=01a0…"]
--- did:web:acme.example.com:b:1
    globalAssetId    = urn:odal-node:product:did:web:acme.example.com:b:1
    specificAssetIds = ["gtin=did:web:acme.example.com:b:1", "serialId=01a0…"]
--- urn:uuid:5b6c0f6a-…
    globalAssetId    = urn:odal-node:product:urn:uuid:5b6c0f6a-…
    specificAssetIds = ["gtin=urn:uuid:5b6c0f6a-…", "serialId=01a0…"]

gtin=did:web:… — the defect, demonstrated rather than argued. The AssetIdentity lock fixes that.

🚨 But globalAssetId is a second defect, and the lock as written does not reach it

Look at the left column. A URI is being wrapped inside a URN:

• urn:odal-node:product:https://id.acme.example.com/b/1 — a URN whose NSS contains another scheme, authority and path.
• urn:odal-node:product:did:web:… — a DID, which is already a URI, nested inside a URN.
• urn:odal-node:product:urn:uuid:… — a URN inside a URN.

The AAS globalAssetId is an Identifier/IRI. A scheme 2 identification link and a scheme 3 DID are already globally unique IRIs — they need no wrapper and are damaged by one. Only scheme 1 is not a URI at all (a bare 14-digit GTIN), and that is the only case a wrapper is for.

Amendment to the implementation, within the locked shape: AssetIdentity drives globalAssetId as well as the specificAssetId name.

variant	globalAssetId
Product(Gs1 { gtin })	wrapped — a bare GTIN is not a URI
Product(IdentificationLink { url })	the URL itself
Product(Did { did })	the DID itself
Named { value }	the value if it is already a URI, wrapped otherwise

Second hardening, cheap

Named { name, value } can still impersonate a scheme — Named { name: "gtin", value: <a DID> } reproduces the exact defect through the escape hatch. Reserve the three scheme names: Named refuses gtin, identificationLink and did. The hatch exists for asset keys that are not the product identifier, so it never has a legitimate reason to use one of those names.

Noted, pre-existing, not part of this

urn:odal-node: is not a registered URN namespace (RFC 8141 §5.1). Out of scope here, but it is the reason the wrapper deserves a second look rather than a port.