Skip to main content

AIPS DPP — QR and URI Conventions

This document defines how AI Product Digital Product Passports (AIPS DPPs) are referenced, discovered, and verified using QR codes and canonical URIs.
It extends the general BPS DPP linking model to the AI product domain.

1. Purpose​

QR and URI conventions serve two essential goals:

  1. Discoverability: Allow users, auditors, or platforms to locate an AI product’s DPP instantly.
  2. Integrity and Traceability: Ensure every QR scan resolves to an authenticated, immutable version of the DPP issued by the producer.

2. Canonical URI Pattern​

Each AI Product DPP MUST be resolvable via a stable, versioned URI hosted by the producer or registry.
The base structure follows:

https://<domain>/dpp/<product-type>/<product-id>/<version>

Example​


[https://{your-domain}/dpp/model/cv-fairness-detector/v2.1?lite=true](https://{your-domain}/dpp/model/cv-fairness-detector/v2.1)

Required Parameters​

SegmentMeaningExample
<domain>Trusted host of the issuing producer or registryaips.kivanura.org
<product-type>Type of AI productmodel, dataset, pipeline
<product-id>Unique product identifier (URI-safe string)cv-fairness-detector
<version>Product version or DPP versionv2.1

Rule: All URIs must dereference to a JSON-LD representation of the DPP (Lite or Full) with proper application/ld+json headers.

3. QR Code Embedding​

Each physical or digital representation of an AI product (model card, dashboard, packaging, registry listing) SHOULD embed a QR code pointing to its DPP endpoint.

3.1 Encoding Specification​

ElementDescription
ContentHTTPS URI of the DPP endpoint (Lite or Full)
EncodingUTF-8
Error Correction Level≥ Q (25% recovery)
Minimum Size2 × 2 cm for physical prints; at least 128 × 128 px for screens
Optional Label“Scan for Digital Product Passport”

QR code content must never directly embed the entire DPP payload; it must only contain a resolvable URI.

3.2 Example Payload​


[https://{your-domain}/dpp/model/cv-fairness-detector/v2.1?lite=true](https://{your-domain}/dpp/model/cv-fairness-detector/v2.1&lite=true)

3.3 Version Differentiation​

ModeQuery ParameterPurpose
Lite View (Public)?lite=trueHigh-level, flattened summary for marketplaces and discovery.
Full View (Authenticated)?lite=false (default)Complete signed DPP with Inline + ByRef sections.

4. Trust and Validation Flow​

When a QR is scanned, the consumer application performs the following steps:

  1. Resolve URI → Fetch JSON-LD from the canonical DPP endpoint.
  2. Check Signature → Verify signature using the issuer’s DID or X.509 key.
  3. Check Hash Integrity → Validate contentHash matches canonicalized payload.
  4. Check Status → Optionally query /status endpoint to confirm Valid.
  5. Render UI → Display flattened DPP information and validation badges.

Simplified Flow Diagram​

5. URI Resolution Modes​

ModeUse CaseAccess Control
PublicMarketplace browsing, high-level DPP summaryOpen
AuthenticatedRegulated product or model auditOAuth2 / mTLS
Offline VerificationCached DPP verification using stored payload and signatureHash + signature validation only
  • Use permanent HTTPS redirects (301) when migrating DPP hosting domains.
  • Include Link: rel="canonical" headers for alternate versions.
  • If multiple products share the same model base, assign a distinct DPP per trained model version.
  • Maintain backward-resolvable archives for older DPPs under /archive/.

7. Integration Example — Model Card QR​

Example: The model card for cv-fairness-detector includes a QR code that resolves to:

https://{your-domain}/dpp/model/cv-fairness-detector/v2.1?lite=true

When scanned, users are shown:

  • Product identity and issuer
  • Key evaluation metrics
  • Top-level risks and mitigations
  • Signature verification result
  • Button to “View Full Passport (Authenticated)”

8. Relationship to BPS DPP Core​

The QR and URI conventions described here are consistent with the BPS DPP Core discovery framework:

LayerReference
BPS DPP CoreProvides the general QR → URI → API pattern
AIPS DPPSpecializes QR/URI format for AI models and datasets

AIPS implementations must remain compatible with the BPS discovery model so that a unified Kivanura-wide DPP scanner can interpret any product class (Physical, Data, or AI).

9. Security Considerations​

  • Always resolve DPPs over HTTPS.
  • Do not expose sensitive model internals in Lite views.
  • Use JWS-signed content for all Full DPPs.
  • Embed a short TTL (time-to-live) for cached DPP responses in mobile apps.
  • For private AIPS products, use access-scoped tokens (aud and sub claims) when generating QR codes.

10. Deprecation and Stability​

ComponentStabilityChange Policy
URI pattern✅ StableNever changed once published
QR content format✅ StableAdditive only
Query parameters (lite, version)⚙️ ExtendableBackward-compatible extensions allowed
Validation API endpoints✅ StableVersioned independently (/api/v1/dpp/...)

Status: Stable Draft Applies to: AIPS DPP 0.1 and above Maintained by: Kivanura Foundation — AIPS Working Group