UNTP DPP credential as a second door

[LKSNDRTMLKV]

GET a passport with Accept: application/vc+jwt and receive a UNTP DigitalProductPassport credential that verifies against the operator's published did:web key.

Why

AAS is the industrial-systems door. UNTP — the UN Transparency Protocol — is the trade and customs door, and it is where the non-IDTA half of the ecosystem is converging. Serving one and not the other means an integrator's answer to "can you talk to our stack?" depends on which stack they have.

The primitives are already ours: did:web identity, JWS signing, W3C VC types, status lists, canonicalisation. This is a mapping exercise plus a media type, not new cryptography.

Settled against the specification

Read 2026-07-31 against the UNTP Verifiable Credentials profile:

• MUST implement the enveloping proof mechanism defined in W3C VC-JOSE-COSE with JOSE. So vc+jwt, which reuses the existing kid → DID → verify path. Embedded Data Integrity proofs are not required; defer that form.
• MUST implement did:web as an organisational identifier — already shipped.
• No signature algorithm is named. EdDSA stands; see the curve discussion in dpp-core ci: gate PR titles on conventional commits #78.

Do this first

Check whether the did:web document we publish carries what an off-the-shelf VC verifier expects — publicKeyJwk shape, verification relationships, assertionMethod. This is a likelier source of interop failure than anything about the algorithm, and it is cheap to test before any mapping is written.

Then

• Vendor the UNTP DPP schema with its version and retrieval date; validate against that copy in CI. It is pre-1.0, so the pinned copy is what tells us what changed when it moves.
• Map an already-masked passport to the credential subject, per product group. A second, non-battery product group is what proves the mapping is typed rather than dumped into an open bag of characteristics.
• Add the media type to the negotiation seam from Serve the AAS projection over content negotiation #69.
• Wire revocation to the existing status-list machinery — connection, not construction.

Merge gate

• Accept: application/vc+jwt returns a credential validating against the vendored UNTP schema
• The credential's JWS verifies against the key at the operator's did:web document using an off-the-shelf JOSE library, not our own verifier — verifying our signature with our own code proves less than we need here
• A restricted-tier field appears in no credential, asserted from the catalog disclosure map
• A revoked credential is reported revoked; an unreachable status list fails closed
• Both a model-level and an item-level credential are produced, and the item links to its model

Scope boundary

No conformance claim — "validates against UNTP DPP schema vN, retrieved on date". No vc+ld+json. No non-public credential: one carrying restricted data is a different artefact with a different access story.