Technical Guide — ระบบตรวจสอบมาตรฐานสินค้าดิจิทัล

สัญลักษณ์

ที่มาของแต่ละ Feature

ทุก feature และ component ในระบบนี้มาจากแหล่งที่ต่างกัน — อ่านแล้วรู้ว่าอะไรเป็นมาตรฐาน อะไรเป็นข้อเสนอของเรา

🔵 Beckn Core Official spec — Beckn Foundation (Linux Foundation)
ใช้ได้เลย มีเอกสารอ้างอิง

🟠 ONDC (อินเดีย) Open Network for Digital Commerce — ใช้งานจริงแล้ว
เราใช้เป็น pattern / ต้นแบบ

🟡 ION (อินโดนีเซีย) Indonesia Open Network — เป้าหมาย ก.ค. 2569
กำลังพัฒนา เราติดตามไว้

🟢 Thai Custom ออกแบบใหม่สำหรับไทย — ยังไม่มีที่ไหนทำ
ต้อง formalize เป็น spec ก่อน production

🟣 เพิ่มเติม/อนาคต ยังไม่มีใครทำ หรืออยู่ใน roadmap ระยะไกล
พูดถึงเพื่อความสมบูรณ์เท่านั้น

ℹ️

หลักการอ่านเอกสารนี้: สีเขียว (Thai Custom) หมายความว่าเราออกแบบขึ้นมาเอง — ยังไม่มี official spec รองรับ ถ้าจะนำไปใช้จริงต้องผ่านกระบวนการ formalize ก่อน สีน้ำเงิน (Beckn Core) อ้างอิง spec ได้เลย

Scenario / Feature	ที่มา	Status ใน POC	Official Reference
B-1 — ค้นหาข้ามร้านค้า (search / on_search)	🔵 Beckn Core	✅ ทำแล้ว	Beckn Core Spec v1.1 — API: search
B-2 — badge ผ่าน Item.tags[]	🔵 Beckn Core	✅ ทำแล้ว	Beckn Core Spec — Item schema, tags[]
B-3 — transaction ครบวงจร (select/init/confirm)	🔵 Beckn Core	⏳ ยังไม่ทำ	Beckn Core Spec — API: select, init, confirm
O-1 — บล็อกผู้ขายที่ไม่มีใบอนุญาตตั้งแต่ upload	🟠 ONDC pattern	✅ ทำแล้ว	ONDC — FSSAI validation (ref: India Food Safety)
O-2 — Transaction-Level Contract (TLC)	🟠 ONDC	⏳ ยังไม่ทำ	ONDC Transaction-Level Contract spec
I-1 — Halal cert layer (Beckn 2.0)	🟡 ION อินโดนีเซีย	— ไม่อยู่ใน POC	ION Halal cert layer — in development (Jul 2026)
I-2 — ASEAN DEFA cross-border	🟡 ION 🟢 Thai Custom	— ไม่อยู่ใน POC	ASEAN DEFA framework (ข้อตกลงกำลังเจรจา)
T-1 — ตรวจสอบ มอก. อัตโนมัติ (statutory_reqs + สมอ. API)	🟢 Thai Custom	✅ ทำแล้ว (mock API)	ออกแบบใหม่ — ต้องขอ สมอ. เปิด REST API จริง
T-2 — ซ่อนสินค้าอัตโนมัติเมื่อใบอนุญาตหมดอายุ	🟢 Thai Custom	✅ ทำแล้ว	ออกแบบใหม่ — logic ใน BPP
T-3 — เพิกถอนทันที (Real-time Revocation) ⭐	🟢 Thai Custom	✅ ทำแล้ว	ออกแบบใหม่ — ยังไม่มีประเทศไหนทำ
T-4 — ตรวจสอบ อย. อัตโนมัติ	🟢 Thai Custom	✅ ทำแล้ว (mock API)	ออกแบบใหม่ — ต้องขอ อย. เปิด REST API จริง
T-5 — บล็อก upload (Thai + ONDC pattern)	🟢 Thai Custom ONDC	✅ ทำแล้ว	ปรับจาก ONDC FSSAI pattern สำหรับ มอก./อย.
PKI / Ed25519 Signing	🔵 Beckn Core	✅ ทำแล้ว	Beckn Core Spec v1.1 — Section 7: Security Model
A-1 — EU Digital Product Passport (DPP)	🟣 เพิ่มเติม	— roadmap 2569–2573	EU Regulation (EU) 2024/1781 — DPP (เริ่มบังคับ 2027)

ภาพรวม

Architecture

ระบบประกอบด้วย 5 component หลัก — 4 component แรกเป็น Beckn spec, Government API เป็น Thai Custom

BECKN NETWORK

🛍️ BAP

Consumer App
port :3001 / :5004

Beckn Core

search ⟶

⟵ on_search

async callback

🔀 Gateway

Router + PKI Verify
port :5001

Beckn Core

multicast

⟶ /search

BPP-XYZ :5002

XYZ Import

BPP-Panasonic :5003

Panasonic TH

BPP-Shopee :5010

Shopee (5 sellers)

BPP-Lazada :5011

Lazada (5 sellers)

Beckn Core

📋 Registry

Subscriber + Public Keys
(in-memory / mock)

Beckn Core

⟵ key lookup (Gateway + BAP + BPP ใช้ในการ verify)

🏛️ Government API

สมอ./อย. License Status
port :3003 (mock)

Thai Custom

⟵ BPP side-call (ทุก search)

⚠️

ใน POC: Registry เป็น in-memory object ใน registry.ts ไม่ใช่ HTTP service จริง · Gateway, BAP, BPP รัน process แยกกัน · Government API เป็น Next.js route ใน poc-government · ใน production ทุก component ต้องเป็น service แยกที่ scale ได้

Components

Deep Dive แต่ละ Component

แต่ละ component มีหน้าที่และ spec ที่ต้องอ้างอิงต่างกัน

🛍️

BAP — Beckn Application Provider

Beckn Core :3001 / :5004

บทบาท: ฝั่งผู้บริโภค — เริ่ม transaction ทุกครั้ง

สร้าง search request พร้อม Context object
Sign request ด้วย BAP private key (Ed25519)
ส่ง POST /search ไปที่ Gateway
รับ callback /on_search จาก BPP แต่ละตัว (async)
Verify signature ของ BPP ก่อน process ผล
แสดงผลใน UI พร้อม badge จาก statutory_reqs tags

In POC: poc-consumer (Next.js :3001) + beckn-bap (ts-node :5004)

🔀

Gateway (BG)

Beckn Core :5001

บทบาท: Router กลาง — รับจาก BAP, กระจายไปยัง BPP ทุกตัว

Verify BAP signature (ก่อนรับ request)
Lookup BPPs จาก Registry ตาม domain
Multicast: forward search ไปทุก BPP พร้อมกัน (async)
Re-sign payload ด้วย Gateway private key
ตอบ ACK ทันที ไม่รอ BPP response

In POC: beckn-gateway (ts-node Express :5001)

📋

Registry

Beckn Core in-memory

บทบาท: สมุดรายชื่อ subscriber + public keys ของทุกคนใน network

เก็บข้อมูล: subscriber_id, uri, domain[], publicKey (Ed25519 base64)
ให้ Gateway lookup BPPs ตาม domain
ให้ทุก party lookup public key เพื่อ verify signature
Production: ต้องเป็น HTTP service จริง พร้อม HTTPS + auth

In POC: registry.ts (in-memory array, hardcoded keys)

🏪

BPP — Beckn Provider Platform

Beckn Core :5002–5003, :5010–5011

บทบาท: ฝั่งผู้ขาย/platform — รับ search, ตอบ catalog

Verify Gateway signature (ก่อนรับ)
Filter catalog ตาม search query
Side-call Gov API เพื่อดู live license status (Thai Custom)
อัปเดต statutory_reqs tag status ตาม response
Sign on_search response ด้วย BPP private key
POST กลับไปที่ BAP callback URI

In POC: bpp-xyz.ts, bpp-panasonic.ts, bpp-shopee.ts, bpp-lazada.ts (ts-node Express)

🏛️

Government API — สมอ./อย. License Service

🟢 Thai Custom :3003 (mock)

บทบาท: ให้ข้อมูล live status ของใบอนุญาต มอก./อย.

Endpoint: GET /api/licenses/{licenseId}
Response: {"status": "active"|"expired"|"revoked"}
BPP เรียกทุกครั้งที่ search — timeout 2 วินาที
ถ้า timeout → fail-open (assume "active")
Revocation: POST /api/licenses/{id} — เปลี่ยน status ทันที

In POC: poc-government Next.js :3003 (in-memory store)

สิ่งที่ต้องทำใน Production:

สมอ. เปิด REST API จริงที่ appdb.tisi.go.th
อย. เปิด REST API จริงที่ oryor.com
Authentication: API Key หรือ mTLS
Rate limiting: กัน BPP ทุก request ยิงไม่หยุด
Webhook (optional): push notification เมื่อ revoke

⚠️

Government API ไม่ใช่ส่วนของ Beckn Protocol — เป็น external service ที่ BPP ใช้ฝั่งเดียว ออกแบบและ maintain โดย สมอ./อย.

Security Model

PKI & Digital Signature Beckn Core

ทุก hop ใน Beckn network ต้องมีการ sign และ verify — ไม่มีใครเชื่อใครโดยไม่มีหลักฐาน cryptographic

🔐

ทำไมต้อง PKI? ใน Beckn network ไม่มี "central authority" ที่ทุกคนเชื่อถือ — BAP ไม่รู้จัก BPP โดยตรง BPP ไม่รู้จัก BAP โดยตรง ทุกคนเชื่อกันผ่าน digital signature ที่ verify ได้จาก Registry public key เท่านั้น ป้องกันการปลอม message, แก้ไข payload ระหว่างทาง, และ replay attack

Ed25519 Key Pairs Beckn Core

แต่ละ subscriber มี 1 key pair: private key (เก็บความลับ) + public key (ลง Registry ให้ทุกคน lookup)

// ตัวอย่าง key pair ที่ถูกเก็บใน keys.json
"bap": {
  "publicKey":  "MCowBQYDK2VdAyEA...",  // base64url — บันทึกใน Registry สาธารณะ
  "privateKey": "MC4CAQAwBQYDK2Vd..."   // base64url — เก็บ server เท่านั้น
}

// ผู้เล่นที่ต้องมี key pair ทุกคน:
// bap, gateway, bppXyz, bppPanasonic, bppSellerPoc, bppShopee, bppLazada

3-Hop Signing Chain

🛍️ BAP

📤 Sign
body ด้วย BAP private key

keyId: "bap-sandbox|ed25519"

✅ verify on_search
จาก BPP (ปลายทาง)

⟶

🔀 Gateway

✅ Verify
BAP signature ก่อนรับ

❌ 401 ถ้า invalid

📤 Re-sign
ด้วย Gateway private key

keyId: "gateway.sandbox|ed25519"

⟶

🏪 BPP

✅ Verify
Gateway signature ก่อนรับ

❌ 401 ถ้า invalid

📤 Sign on_search
ด้วย BPP private key

keyId: "bpp-xyz.sandbox|ed25519"

⟶

🛍️ BAP (รับกลับ)

✅ Verify
BPP signature

❌ ทิ้ง ถ้า invalid

ถ้าผ่าน → เก็บผล
แสดงใน UI

Authorization Header Format Beckn Core

// HTTP Header ที่แนบทุก request ใน Beckn
Authorization: Signature
  keyId="bap-sandbox|ed25519",
  algorithm="ed25519",
  created=1748700000,
  expires=1748700030,
  headers="(created) (expires) digest",
  signature="base64-encoded-ed25519-signature=="

// Signing string ที่ใช้ sign (ต้องตรงทั้งสองฝั่ง)
"(created): 1748700000\n(expires): 1748700030\ndigest: SHA-256=<base64-body-hash>"

// หมายเหตุ: Beckn Core Spec แนะนำ BLAKE2b-512 สำหรับ body digest
// POC ใช้ SHA-256 เพื่อความง่าย — ต้องแก้ใน production

องค์ประกอบ	POC ทำอะไร	Beckn Spec บอกว่า	แก้ก่อน Production?
Algorithm	Ed25519 ✅	Ed25519 (recommended)	ไม่ต้องแก้
Body digest	SHA-256	BLAKE2b-512	ต้องแก้
Validity window	30 วินาที	กำหนดเองได้ (TTL)	ปรับได้ตามต้องการ
Key storage	keys.json (shared)	แยกต่างหากต่อ service	ต้องแก้ — ใช้ HSM/Vault
Registry lookup	in-memory hardcoded	HTTP endpoint	ต้องแก้

Message Flow

Search → on_search ทีละ step Beckn Core

pattern นี้เรียกว่า "async callback" — BAP ส่ง search แล้วรอรับ on_search กลับมาทีหลัง ไม่ใช่ synchronous request/response

BAP สร้าง Context + Search Intent

สร้าง transaction_id (UUID ใหม่) และ message_id · กำหนด domain: "nic2004:52110" · ระบุ query ใน message.intent.item.descriptor.name

📤 sign ด้วย BAP private key

BAP → Gateway: POST /search

แนบ Authorization header · Gateway ต้องตอบ ACK ทันที (ไม่เกิน 30 วินาที)

✅ Gateway verify BAP signature ⟳ async ต่อจากนี้

Gateway lookup Registry → Multicast ไปทุก BPP

หา BPP ทั้งหมดที่ลง domain "nic2004:52110" · สร้าง context ใหม่สำหรับแต่ละ BPP: อัปเดต bpp_id, bpp_uri, message_id (ใหม่), timestamp · ส่งพร้อมกันทุกตัว (fire-and-forget)

📤 Gateway re-sign ด้วย GW private key

BPP รับ search → verify → ประมวลผล

Verify Gateway signature · ACK ทันที · แล้ว async: filter catalog ตาม query · เรียก Gov API เพื่อดู live status ของแต่ละใบอนุญาต (Thai Custom)

✅ BPP verify Gateway signature 🟢 side-call สมอ./อย. API

BPP → BAP: POST /on_search (callback)

ส่ง catalog พร้อม statutory_reqs tags ที่อัปเดตแล้ว · ใช้ bap_uri จาก context เดิม · แนบ Authorization header ของ BPP

📤 BPP sign ด้วย BPP private key

BAP รับ on_search จากแต่ละ BPP

Verify BPP signature · เก็บผลลัพธ์ใน memory (group by transaction_id) · BPP แต่ละตัวส่งมาแยกกัน — UI รวมผล aggregate เอง · ถ้า verify ไม่ผ่าน → ทิ้ง ไม่แสดง

✅ BAP verify BPP signature

Context Object Evolution Beckn Core

// BAP ส่งออก (transaction_id คงเดิมตลอด)
{
  domain:         "nic2004:52110",
  action:         "search",
  core_version:   "0.9.4",
  bap_id:         "bap-sandbox",
  bap_uri:        "http://localhost:5004",
  transaction_id: "uuid-AAAA",  // ← คงเดิมทุก hop
  message_id:     "uuid-1111",  // ← เปลี่ยนทุก hop
  timestamp:      "2026-06-01T10:00:00Z"
}

// Gateway forward ไป BPP-XYZ (เพิ่ม bpp_id/bpp_uri)
{
  ...(เหมือนเดิม),
  bpp_id:     "bpp-xyz.sandbox",  // ← เพิ่ม
  bpp_uri:    "http://localhost:5002",
  message_id: "uuid-2222",  // ← ใหม่
}

// BPP ตอบกลับ (action เปลี่ยน)
{
  ...(เหมือนเดิม),
  action:     "on_search",  // ← เปลี่ยน
  message_id: "uuid-3333",  // ← ใหม่อีกครั้ง
}

Thai Custom Extension

statutory_reqs Tag — ข้อเสนอของไทย 🟢 Thai Custom

Beckn Core กำหนดแค่ว่า Item มี tags[] ได้ — รหัสที่ใช้จริงเป็น "extension" ที่แต่ละประเทศ/domain กำหนดเอง สิ่งที่ POC นี้เสนอ ยังไม่มี official spec

⚠️

ต้อง Formalize ก่อน Production: tag codes ด้านล่างเป็นข้อเสนอของทีม POC — ต้องผ่านกระบวนการ Working Group (ETDA + สมอ. + อย.) เพื่อ publish เป็น Thailand Beckn Domain Specification ก่อนที่ BPP/BAP จะ implement จริง

Tag Structure ที่ใช้ใน POC

// Item.tags[] ใน on_search response — สินค้า มอก.
{
  code: "statutory_reqs",  // ← ชื่อ tag group (Thai Custom)
  list: [
    { code: "tis_license", value: "TIS-0045821"          },  // เลขใบอนุญาต
    { code: "tis_mark",    value: "มอก.1650-2549"         },  // เลขมาตรฐาน
    { code: "tis_holder",  value: "XYZ Import Co., Ltd."  },  // ชื่อผู้ถือ
    { code: "tis_expiry",  value: "2025-12-31"            },  // วันหมดอายุ
    { code: "tis_status",  value: "active"                }   // ← อัปเดต live จาก Gov API
  ]
}

// สินค้า อย. — ใช้ prefix "fda_" แทน "tis_"
{
  code: "statutory_reqs",
  list: [
    { code: "fda_reg",    value: "10-1-00001-1-0001"     },  // เลขทะเบียน อย.
    { code: "fda_type",   value: "อาหารเสริม"              },
    { code: "fda_holder", value: "HealthPlus (Thailand)"  },
    { code: "fda_expiry", value: "2026-05-31"            },
    { code: "fda_status", value: "active"                }
  ]
}

Live Status Side-call Pattern 🟢 Thai Custom

BPP ไม่ได้เก็บ status ไว้เอง — ทุกครั้งที่ search จะ query Gov API ใหม่เสมอ ทำให้ผู้บริโภคเห็นสถานะล่าสุดเสมอ

// BPP logic (bpp-xyz.ts) — ทุกครั้งที่ search
async function applyLiveStatus(item) {
  const licenseNum = extractLicenseNum(item.tags);  // "TIS-0045821"
  try {
    const res = await axios.get(
      `http://127.0.0.1:3003/api/licenses/${licenseNum}`,
      { timeout: 2000 }  // timeout 2 วินาที
    );
    const status = res.data?.status ?? "active";  // default: active
    return updateTagStatus(item, status);  // อัปเดต tis_status หรือ fda_status
  } catch {
    return item;  // fail-open: ถ้า Gov API down → ไม่บล็อก search
  }
}

💡

ทำไม fail-open? ใน POC เลือก fail-open (ถ้า Gov API down → ถือว่า active) เพื่อไม่ให้การ down ของ สมอ./อย. API ทำให้ platform ล่มทั้งหมด — ใน production ต้องหารือกับ สมอ. ว่าจะ fail-open หรือ fail-close และต้องมี SLA ของ Gov API ด้วย

Path to Formalization — ต้องทำก่อน Production

สิ่งที่ต้องทำ	ใครทำ	ผลลัพธ์	อ้างอิง Pattern
กำหนด statutory_reqs tag codes อย่างเป็นทางการ	Working Group: ETDA + สมอ. + อย.	Thailand Beckn Domain Spec v1.0	ONDC Domain Specifications
กำหนด status values ("active", "expired", "revoked", "suspended")	สมอ./อย.	Enumeration spec	FSSAI License Status (ONDC)
สมอ. เปิด REST API สาธารณะ	สมอ.	API spec + endpoint + SLA	appdb.tisi.go.th
อย. เปิด REST API สาธารณะ	อย.	API spec + endpoint + SLA	oryor.com
ETDA ตั้ง Production Registry + Gateway	ETDA	Beckn Network infrastructure	Beckn Core Spec — Registry API

Implementation Guide

บทบาทและสิ่งที่ต้อง Implement

แต่ละฝ่ายต้องรู้ spec คนละชุด — ตารางนี้บอกว่าใครต้องอ่านอะไร และอะไรเป็น official spec vs ข้อเสนอที่ต้อง formalize

🏢

ETDA — Beckn Network Operator

ผู้ดูแล infrastructure กลาง: Registry, Gateway, Network Policy

ต้อง Implement

Registry Service — HTTP API สำหรับ subscriber lookup และ public key lookup ที่ scale ได้
Gateway Service — verify, multicast, load balancing, rate limiting
Subscriber Onboarding — กระบวนการลงทะเบียน BPP/BAP ใหม่, key submission, domain approval
Network Policy — กติกาในเครือข่าย: ใครเข้าได้, domain ไหนบ้าง

Specs ที่ต้องอ่าน

Beckn Core Spec v1.1 Beckn Registry API Beckn Gateway Spec ONDC Network Policy (pattern)

ต้อง Define เอง (ยังไม่มี spec)

Thailand Beckn Domain Spec — กำหนด statutory_reqs tag codes
Certification criteria สำหรับ BPP ที่จะลง network
SLA ที่ต้องการจาก Government API (สมอ./อย.)

อ้างอิงจาก

🔵 Beckn Core
🟠 ONDC Network Policy

🛍️

BAP Developer

Consumer platform (Shopee, Lazada, หรือ app ของรัฐ)

ต้อง Implement

สร้าง Context object + search intent ตาม spec
Sign request ด้วย Ed25519 private key
รับ /on_search callback + verify signature
Parse statutory_reqs tags และแสดง badge ใน UI
Handle หลาย BPP response (aggregate)

Specs ที่ต้องอ่าน

Beckn Core Spec — search/on_search Beckn Context object HTTP Signature (Authorization) Thailand Domain Spec (เมื่อ publish)

อ้างอิงจาก

🔵 Beckn Core (search/on_search, Context, HTTP Signature)
🟢 Thai Custom (statutory_reqs display logic)

🏪

BPP Developer

Seller / platform ที่จะเข้า network (ร้านค้า, Shopee, Lazada)

ต้อง Implement

Expose POST /search endpoint + verify Gateway signature
Sign on_search response ด้วย BPP private key
เพิ่ม statutory_reqs tags ใน catalog
เรียก สมอ./อย. API ก่อน respond ทุกครั้ง
Handle timeout + fail-open/fail-close ตาม network policy
ลง Registry กับ ETDA พร้อม public key + domain

Specs ที่ต้องอ่าน

Beckn Core Spec — on_search Item schema + tags[] Thailand Domain Spec สมอ./อย. API Spec

อ้างอิงจาก

🔵 Beckn Core (BPP endpoint, on_search, signing)
🟢 Thai Custom (statutory_reqs tag spec, Gov API integration)
🟠 ONDC FSSAI (upload validation pattern)

🏛️

สมอ. / อย. — Government API Team

เปิด REST API สำหรับ license status lookup

ต้อง Implement

GET /licenses/{id} → {"status":"active"|"expired"|"revoked"}
Authentication: API Key หรือ mTLS สำหรับ BPP
Rate limiting: ป้องกัน BPP ทุก platform ยิงไม่หยุด
Response time SLA: แนะนำ <500ms (BPP timeout 2 วินาที)
Webhook (optional): push เมื่อ status เปลี่ยน

ไม่ใช่ Beckn

Government API เป็น standard REST API ธรรมดา — ไม่ต้องรู้ Beckn Protocol เลย · ออกแบบร่วมกับ ETDA เพื่อกำหนด format ที่ BPP ทุกเจ้าใช้ได้

อ้างอิงจาก

🟢 Thai Custom (ETDA + สมอ./อย. ออกแบบร่วมกัน)

ต้นแบบ: FSSAI API (ONDC/India) สำหรับ food safety verification

📐

Thailand Beckn Domain Spec Working Group

ETDA + สมอ. + อย. + ผู้แทน platform — formalize ข้อเสนอ POC เป็น official spec

สิ่งที่ต้อง Formalize

statutory_reqs tag spec — ชื่อ code, type, format ของ value ทุกฟิลด์
status enumeration — "active" | "expired" | "revoked" | "suspended" | ...
cert_type taxonomy — มอก., อย., มอก.+อย., อื่นๆ ในอนาคต
Error/fallback behavior — ถ้า Gov API down ต้อง fail-open หรือ fail-close

กระบวนการ Publish

ร่าง Thailand Beckn Domain Specification v1.0
Public comment period (เหมือน ONDC process)
Publish บน GitHub/Portal ที่ BPP/BAP ดาวน์โหลดได้
Version management — backward compat

ต้นแบบ

🟠 ONDC Domain Specifications

ONDC มีกระบวนการออก domain spec สำหรับ retail, food, healthcare ฯลฯ — ไทยสามารถ follow pattern เดียวกัน

Spec References

แหล่งอ้างอิงทั้งหมด

สีของแต่ละแถวบ่งบอก status — น้ำเงินอ่านได้เลย, เขียว/ส้ม ต้องอ่าน + formalize เพิ่ม

เอกสาร / Spec	ที่มา	สิ่งที่ใช้	Status
Beckn Core Specification v1.1 `developers.becknprotocol.io/docs/core-specification`	🔵 Beckn Core	Context object, API flow (search/on_search/select/...), HTTP Signature, Item.tags schema, Error handling	✅ Official — อ่านได้เลย
Beckn Core Spec — Security Model `Section 7: Authentication and Authorization`	🔵 Beckn Core	Ed25519 signing, Authorization header format, Registry key lookup, replay protection	✅ Official — อ่านได้เลย
Beckn Registry API Specification `developers.becknprotocol.io/docs/registry`	🔵 Beckn Core	Subscriber registration, public key format, lookup API	✅ Official — อ่านได้เลย
ONDC Network Policy v2.0 `ondc.org/network-policy`	🟠 ONDC	Seller upload validation pattern (ref: O-1), Network Participant onboarding, FSSAI integration model	✅ Published — ใช้เป็น pattern
ONDC Domain Specification — Retail `ondc.org/specs/retail`	🟠 ONDC	Domain-specific tag extension pattern — เราทำแบบเดียวกันสำหรับ มอก./อย.	✅ Published — ใช้เป็น pattern
ION — Indonesia Open Network `Beckn 2.0 (เป้าหมาย ก.ค. 2569)`	🟡 ION	Halal cert layer pattern (I-1), ASEAN DEFA cross-border model (I-2)	⏳ In development — ติดตามไว้
Thailand Beckn Domain Specification `ยังไม่มี URL — ต้องสร้าง`	🟢 Thai Custom	statutory_reqs tag codes, status values, Gov API format, Thai network policy	⚠️ ยังไม่มี — ต้อง formalize
สมอ. License Database API `appdb.tisi.go.th`	🟢 Thai Custom	Source ข้อมูล มอก. — ปัจจุบันยังไม่มี REST API สาธารณะ	⚠️ ต้องขอ สมอ. เปิด API
อย. Consumer Portal API `oryor.com/check-product-serial`	🟢 Thai Custom	Source ข้อมูล อย. — ปัจจุบันยังไม่มี REST API สาธารณะ	⚠️ ต้องขอ อย. เปิด API
Beckn_API_Spec_TH_Certification.docx `_archive/docs/ — เอกสารภายใน`	🟢 Thai Custom	API spec ทั้ง 10 flows พร้อม JSON ตัวอย่าง — ร่างโดยทีม POC	📄 Draft ภายใน — ยังไม่ publish
EU Digital Product Passport (DPP) `EU Regulation 2024/1781`	🟣 เพิ่มเติม/อนาคต	รูปแบบ "ป้ายดิจิทัล" บนสินค้าส่งออก EU — compatible กับ Beckn Item.tags ได้	📅 บังคับปี 2027 — roadmap ระยะไกล

📁

เอกสาร research ภายใน: ดูได้ที่ /opt/beckn-poc/_archive/docs/ — มี Beckn_ONDC_Thai_Strategy.docx, POC_Scenario_Matrix (rev02), Beckn_API_Spec_TH_Certification.docx, และ slides ทั้งหมด