A scoping brief: what we have built, why a trustless collection interface is feasible, and the open RBAC / permissioning problems we need you to solve so partnering factories can grant us scoped help with their DPP duties without surrendering their data security.
範圍說明：我們已建置的內容、為何一個去信任（trustless）的蒐集介接是可行的，以及需要你們協助解決的權限控管（RBAC）難題 — 讓合作工廠能在不交出資料安全的前提下，授予我們有範圍限制的協助，以履行其 DPP 義務。
Under the EU ESPR, every textile product will need a Digital Product Passport (DPP). The legal issuer is the economic operator — our overseas buyer — but the data lives across a chain of independent factories (spinner → weaver → dye house → finisher → laminator → garment), each in a different jurisdiction, on different systems, owing different duties. Our platform is the evidence-orchestration layer that collects that data and assembles it into a passport.
在歐盟 ESPR 之下，每件紡織品都將需要數位產品護照（DPP）。法定簽發者是經濟營運者 — 即我們的海外買家 — 但資料分散於一連串獨立工廠（紡紗 → 織布 → 染整 → 後加工 → 貼合 → 成衣），各處不同法域、不同系統、負不同義務。我們的平台是證據協調層，負責蒐集這些資料並組裝成護照。
The tension this spec exists to resolve: to assemble the passport we must sit on the supply chain's most sensitive asset — the supply graph (who buys from whom, at what volume, through which tiers). That is precisely the data that would let anyone disintermediate the factories. So the factories' rational stance is to distrust us. The interface must therefore earn adoption without asking for trust.
本規格要解決的張力：為了組裝護照，我們必然握有供應鏈最敏感的資產 — 供應關係圖（supply graph）（誰向誰採購、數量多少、經過哪些層級）。這正是足以讓任何人「跳過」工廠的資料。因此工廠的理性立場就是不信任我們。介接必須在不要求信任的前提下贏得採用。
This is not greenfield. The following are built and in-repo; you are designing the factory-facing interface and permission layer on top of them, not the data model.
這並非從零開始。以下皆已建置並存於程式庫；你們要設計的是其上的面向工廠的介接與權限層，而非資料模型本身。
| Asset資產 | What it is內容 | State |
|---|---|---|
| CWA 18291 data modelCWA 18291 資料模型 | The eBIZ/TRICK XML schema the DPP is built on — productComponent, processStep, certificates, sustainability indicators. XML on the wire, JSON Schema generated.DPP 所依據的 eBIZ/TRICK XML 結構 — productComponent、processStep、證書、永續指標。傳輸用 XML，JSON Schema 由其產生。 |
have |
| 7-stage collection model七階段蒐集模型 | content/fabric-process.json — every fabric-making stage mapped to its component code and a per-factory list of collectible fields (machine, lot, test, doc).content/fabric-process.json — 每個製布階段對應其元件代碼，並列出各工廠可蒐集的欄位（機台、批號、測試、文件）。 |
have |
| Blockchain-neutral split區塊鏈中立切分 | Per CWA §4.2 / cl. 5.6.1: hashes on-chain, documents off-chain. The chain only proves nobody rewrote history; privacy is won or lost off-chain.依 CWA §4.2／條款 5.6.1：雜湊上鏈、文件留鏈下。鏈只證明歷史未被竄改；隱私的成敗全在鏈下。 | have |
| Privacy architecture canvas隱私架構圖 | content/architecture.json — a two-sided design (13 nodes, 5 domains), a 7-technique privacy toolkit (options A–G) and a 3-phase rollout. Editorial, not yet implemented.content/architecture.json — 雙邊設計（13 節點、5 領域）、七項隱私技術工具箱（選項 A–G）與三階段推進。屬編輯構想，尚未實作。 |
Kannesh Team |
| Factory / machine datasets工廠／機台資料集 | Researched real + synthetic per-stage datasets (OPC UA / EPCIS 2.0 grounded) for a process simulator that emits records matching each stage's fields.已研究各階段的真實＋合成資料集（以 OPC UA／EPCIS 2.0 為基礎），供製程模擬器產生符合各階段欄位的紀錄。 | have |
| Permission / RBAC layer權限／RBAC 層 | How factories authenticate, scope what we may touch, grant & revoke — and how that survives a trustless substrate. This is the gap.工廠如何驗證身分、限定我們可觸及的範圍、授予與撤回 — 以及這一切如何在去信任基礎上成立。這正是缺口。 | Kannesh Team |
“Trustless” here does not mean no trust at all; it means the factory should not have to trust us, the platform operator. Three structural facts make that achievable:
此處的「去信任」並非毫無信任，而是指工廠不必信任我們這個平台營運者。三項結構性事實使其可達成：
Order of operations. Every factory runs a local gateway that hashes → anchors → signs → encrypts a contribution before anything crosses our boundary. We only ever receive ciphertext plus a commitment. We cannot read, alter, or forge it; we can only relay and assemble.
操作順序。每家工廠運行一個本地閘道，在任何資料越過我們的邊界之前，先雜湊 → 上鏈錨定 → 簽章 → 加密。我們收到的只有密文加承諾值（commitment）。我們無法讀取、竄改或偽造，只能轉送與組裝。
The chain holds us to it. Because the hash is anchored on a public ledger (e.g. EBSI / OpenTimestamps) at the moment of creation, any later tampering by us is publicly detectable. Integrity does not depend on our honesty.
由鏈約束我們。由於雜湊在產生當下即錨定於公開帳本（如 EBSI／OpenTimestamps），我們日後任何竄改都可被公開偵測。完整性不取決於我們的誠實。
We are outside the liability path. The buyer is the legal DPP issuer; we are the evidence orchestrator — indispensable but not the operator of record. The factory's relationship of obligation runs to the buyer, not to us, which is exactly why our access must be cryptographically bounded rather than contractually promised.
我們在責任鏈之外。買家是法定 DPP 簽發者，我們是證據協調者 — 不可或缺，但非法定營運者。工廠的義務關係指向買家而非我們，這正是為何我們的存取必須以密碼學界定，而非以合約承諾。
The crown jewel is the graph, not the field. A single test report leaking is recoverable; the topology — which spinner feeds which weaver feeds which dye house, for this buyer's order — is not. The interface's first duty is to hide the graph, even from us.
真正的核心資產是「關係圖」，而非單一欄位。單一測試報告外洩尚可挽回；拓樸結構 — 為了這位買家的訂單，哪家紡紗供應哪家織布、再供哪家染整 — 一旦外洩則無法挽回。介接的首要職責是隱藏這張圖，甚至對我們也隱藏。
The privacy toolkit already mapped (architecture.json, options A–G). You do not need all of it at once; the 3-phase rollout below shows the minimum at each step and the trust statement the factory earns.
隱私工具箱已盤點完成（architecture.json，選項 A–G）。不需一次全用；下方三階段推進顯示每一步的最低需求，以及工廠在該階段所取得的信任保證。
Reports/certs issued as W3C VCs (BBS+ / SD-JWT); DPP reveals only the fields a verifier needs.
報告／證書以 W3C VC（BBS+／SD-JWT）簽發；DPP 僅揭露驗證者所需欄位。
Each tier proves its processStep consumes the tier-above's output without naming it. Hides the graph.
每層證明其 processStep 消耗上一層的產出，而不指名。藉此隱藏關係圖。
Blind assembly runs in an attested enclave; the gateway verifies the exact code before sending.
盲組裝於經認證的安全隔離區中執行；閘道在送出前驗證將觸及資料的確切程式碼。
Gateway encrypts XML per recipient / under policy-gated keys; our endpoint becomes a dumb encrypted store.
閘道依接收者／策略門控金鑰加密 XML；我們的端點淪為「無腦」加密儲存。
Benchmarks/models trained where raw data never leaves the gateway. A product line, not a compliance cost — and the layer where your team leads.
在原始資料不離開閘道之處訓練基準／模型。是產品線，而非合規成本 — 也是你們團隊主導的一層。
Sector aggregates (“avg water/kg across 12 dye houses”) with no party — us included — seeing inputs.
產業層級彙總（「十二家染廠平均每公斤用水」），任何一方（含我們）皆看不到個別輸入。
| # | Layers in play啟用層 | Trust statement the factory earns工廠取得的信任保證 |
|---|---|---|
| 1 | F + factory-side hashing & anchoring工廠端雜湊與錨定 | “They store ciphertext and can't alter anything.” 「他們存的是密文，且無法竄改任何東西。」 |
| 2 | A (VCs) + C (attested endpoint認證端點) | “Verifiers see only the fields I disclose; I verified the endpoint code before sending.” 「驗證者只看到我揭露的欄位；我在送出前已驗證端點程式碼。」 |
| 3 | B (ZK mass-balance零知識質量平衡) + D | “Anyone can verify my claims; nobody — not even the auditor, until disputed — sees my numbers.” 「任何人都能驗證我的宣稱；在爭議發生前，沒有人 — 連稽核員 — 看得到我的數字。」 |
Feasibility verdict: Phase 1 is buildable today with mature, off-the-shelf components and earns the load-bearing trust statement (“ciphertext only, tamper-evident”). Phases 2–3 deepen disclosure control and graph-hiding but are not prerequisites for onboarding. The architecture is therefore incrementally adoptable — which is itself a trust argument: a factory can start with the weakest commitment and verify each layer before granting the next.
可行性結論：第一階段以成熟的現成元件即可建置，並取得最關鍵的信任保證（「只有密文、可偵測竄改」）。第二、三階段深化揭露控制與關係圖隱藏，但非上線前提。因此整體架構是可漸進採用的 — 這本身即是信任論據：工廠可從最弱的承諾開始，逐層驗證後再授予下一層。
Scope, so the permission model has something concrete to gate. Each stage is one factory's productComponent + processStep; the full per-field list is in content/fabric-process.json.
界定範圍，讓權限模型有具體標的可控管。每一階段即一家工廠的 productComponent ＋ processStep；完整逐欄清單見 content/fabric-process.json。
| Stage階段 | Code | Representative data the gateway emits閘道輸出的代表性資料 |
|---|---|---|
| Polymer / recycler聚合物／回收 | rawCode | chip lot, polymer class, GRS transaction cert, RSL declaration粒料批號、聚合物類別、GRS 交易證書、RSL 聲明 |
| Spinner紡紗 | yarnCode | yarn spec (denier/twist), lot, tenacity test紗規（丹尼／撚數）、批號、強伸度測試 |
| Weaver織布 | texCode | construction, warp beam, loom, 4-point inspection組織規格、經軸、織機、四分制檢驗 |
| Dye & finish染整 | texCode | recipe/ΔE, batch, fastness, effluent COD配方／ΔE、批號、堅牢度、放流水 COD |
| Laminator貼合 | rawCode·acsCode | membrane spec, adhesive, peel test, rain test膜規格、貼合膠、剝離測試、淋雨測試 |
| Garment成衣 | garment*Code | panel/garment ID, trims, seam-seal, garment rain test版片／成衣編號、輔料、車縫密封、成衣淋雨測試 |
Key interface constraint: what crosses the boundary is not this table — it is a commitment to each record plus the minimum disclosed subset a given verifier (EU authority, buyer, consumer) is entitled to. The permission model governs exactly which subset, to whom, for how long.
關鍵介接限制：越過邊界的並非這張表本身，而是對每筆紀錄的承諾值，加上特定驗證者（歐盟主管機關、買家、消費者）有權取得的最小揭露子集。權限模型所控管的，正是「哪個子集、給誰、多久」。
This is the core of the engagement. Classic server-side RBAC (roles → permissions enforced by our backend) directly contradicts everything in §3–4: it re-introduces us as the authority that decides who sees what. Below are the obstacles we need a coherent answer to.
這是本案的核心。傳統伺服器端 RBAC（由我們後端執行「角色 → 權限」）與 §3–4 的一切正面矛盾：它把我們重新置於「決定誰看到什麼」的權威地位。以下是需要你們給出一致解法的障礙。
A permission row in our database is a promise we could override. For anything touching the crown jewel, “permission” must be a cryptographic capability (a key, a VC, a policy the chain enforces) we cannot override — not an ACL we maintain. Where exactly is the line between convenience-RBAC (server-enforced, revocable, for non-sensitive coordination) and capability-enforcement (cryptographic, for sensitive data)?
我們資料庫中的一條權限紀錄，是一個我們可以推翻的承諾。凡觸及核心資產者，「權限」必須是我們無法推翻的密碼學能力（金鑰、VC、由鏈執行的策略），而非我們維護的 ACL。便利型 RBAC（伺服器執行、可撤回、用於非敏感協調）與能力執行（密碼學、用於敏感資料）之間的界線，究竟劃在哪裡？
Even if data is encrypted, a central role/grant mapping (“T1-garment may read T3-spinner’s field X”) is the supply graph in metadata form. The access-control metadata is as sensitive as the payload. How do we authorize cross-tier reads without any single store holding the who-can-see-whom map?
即使資料已加密，一份集中的「角色／授權」對應表（「T1 成衣可讀取 T3 紡紗的欄位 X」），其本身就是以中繼資料形式存在的供應關係圖。存取控制中繼資料與酬載同等敏感。我們要如何在沒有任何單一儲存體握有「誰可看誰」對應表的情況下，授權跨層讀取？
Factories are not our user accounts; they are sovereign organisations granting us scoped, revocable help. This is delegated authorization across trust domains (think OAuth consent / UMA, or VC-based ABAC), not internal roles. What is the grant primitive, what does a factory actually click to say “you may assemble my disclosed fields into this buyer’s DPP, nothing more”, and how is it revoked?
工廠並非我們的使用者帳號，而是授予我們有範圍、可撤回之協助的主權組織。這是跨信任域的委派授權（類似 OAuth 同意／UMA，或以 VC 為基礎的 ABAC），而非內部角色。授權的基本單位（grant primitive）是什麼？工廠實際上要點選什麼，來表達「你可以把我揭露的欄位組裝進這位買家的 DPP，僅此而已」？又如何撤回？
The rules are relational and asymmetric: the buyer sees no further than T1; T1 must not see T3’s identity; an auditor sees nothing until a dispute fires; a consumer sees a minimal public subset. This is attribute- and relationship-based (ReBAC/ABAC), and partly conditional (audit-on-dispute). A role enum cannot express it. What policy language and evaluation point do you propose?
規則是關係式且不對稱的：買家看不到 T1 以上；T1 不得看到 T3 的身分；稽核員在爭議觸發前什麼都看不到；消費者只看到最小公開子集。這屬於以屬性與關係為基礎（ReBAC／ABAC），且部分為條件式（爭議時才稽核）。角色列舉無法表達。你們建議採用何種策略語言與評估點？
Under client-side encryption (F), “granting access” literally means “a recipient’s key can decrypt this” — implemented via threshold/proxy re-encryption or policy-gated keys that release only when an on-chain condition fires. Revoking then cannot mean “delete a row”; it means key rotation / re-encryption without re-touching the whole corpus. How do grant, revoke, expiry and audit-trigger map onto a key-management scheme the factory controls?
在用戶端加密（F）之下，「授予存取」字面上就是「某接收者的金鑰能解密此項」 — 透過門檻／代理重加密，或僅在鏈上條件觸發時才釋出的策略門控金鑰來實作。如此一來，「撤回」不能是「刪一筆紀錄」，而是金鑰輪替／重加密，且不需重新處理整個資料集。授予、撤回、到期與稽核觸發，要如何對應到一套由工廠掌控的金鑰管理機制？
A factory IT lead wants a comprehensible toggle: “help this buyer with their passport — yes / scope / revoke.” The substrate underneath is keys, VCs and proofs. The interface’s success depends on collapsing that gap without the simplification quietly re-creating a trust-us shortcut. How do we present cryptographic capabilities as a permission UX a non-cryptographer will correctly reason about?
工廠的 IT 主管想要一個可理解的開關：「協助這位買家製作護照 — 是／限定範圍／撤回。」其底層卻是金鑰、VC 與證明。介接的成敗取決於能否弭平此落差，又不讓這層簡化悄悄退化成「相信我們」的捷徑。我們要如何把密碼學能力呈現為一套非密碼學專家也能正確推理的權限 UX？
Working position (challenge it): RBAC splits in two. A thin convenience layer — server-enforced roles for non-sensitive coordination (campaign membership, task status, contact routing) where we are trusted because nothing sensitive is at stake. And a capability layer — VCs + policy-gated keys + ZK + on-chain conditions for anything touching field data or the graph, where we are structurally unable to be the authority. The deliverable is the precise boundary between them and the migration path from a Phase-1 thin layer to a Phase-3 capability layer.
暫定立場（歡迎挑戰）：RBAC 一分為二。一層薄的便利層 — 以伺服器執行的角色，用於非敏感協調（活動成員、任務狀態、聯絡路由），此處我們可被信任，因無敏感事物受影響。另一層能力層 — 以 VC ＋策略門控金鑰＋零知識＋鏈上條件，用於一切觸及欄位資料或關係圖者，此處我們在結構上不可能成為權威。交付標的即兩者間的精確界線，以及從第一階段薄層遷移至第三階段能力層的路徑。
Factory gateway spec — the local component that hashes/anchors/signs/encrypts before the boundary: footprint, deployment modes (on-prem / hosted-but-key-isolated), and its minimal API surface.
工廠閘道規格 — 在邊界前負責雜湊／錨定／簽章／加密的本地元件：佔用資源、部署模式（自建／代管但金鑰隔離）、以及其最小 API 介面。
Permission & consent model — the grant primitive, the RBAC↔capability boundary (O1), the policy language for tiered visibility (O4), and grant/revoke/expiry under key-release semantics (O5).
權限與同意模型 — 授權基本單位、RBAC↔能力層界線（O1）、分層可見性的策略語言（O4），以及金鑰釋出語意下的授予／撤回／到期（O5）。
Graph-hiding metadata design — how authorization works without any store holding the who-sees-whom map (O2/O3).
關係圖隱藏的中繼資料設計 — 在無任何儲存體握有「誰可看誰」對應表的前提下，授權如何運作（O2／O3）。
Onboarding & permission UX — the non-cryptographer-facing surface that resolves O6, with the per-phase trust statement made legible to the factory.
導入與權限 UX — 面向非密碼學專家、解決 O6 的介面，並讓各階段的信任保證對工廠清晰可讀。
Phase-1 reference build — the smallest deployable slice (F + hashing/anchoring) that earns “ciphertext only, tamper-evident”, with a chosen anchoring backend (OpenTimestamps now, EBSI-ready).
第一階段參考實作 — 取得「只有密文、可偵測竄改」的最小可部署切片（F ＋雜湊／錨定），並選定錨定後端（先 OpenTimestamps，預留 EBSI）。
Federated analytics across tiers — an area where you know the framework far better than we do, so we’d love your perspective on what it could offer here. For instance, could models like carbon intensity or defect prediction be trained across factories while raw data stays at the gateways? Where does it shine, where are its limits, and is there anything we should be mindful of (such as whether supply relationships could be inferred from what is shared)? We’d also be curious how it might fit alongside the graph-hiding of O2.
跨層聯邦式分析 — 在這個領域，你們對框架的掌握遠勝於我們，因此很希望聽聽你們的看法：它在我們的情境下能帶來什麼？例如，能否在原始資料留在閘道的前提下，跨工廠訓練碳強度、瑕疵預測等模型？它的強項在哪、限制為何、有沒有我們該留意之處（例如供應關係是否可能從共享內容中被推斷出來）？也想了解它如何與 O2 的關係圖隱藏相互搭配。
Editorial note / 編註
The architecture, options A–G and phasing are our editorial design, not CWA 18291 wording. The CWA contributes only the data model and the on-chain/off-chain split; everything about privacy and permissioning is ours to specify — which is why this engagement exists.
架構、選項 A–G 與分階段為我們的編輯設計，非 CWA 18291 原文。CWA 僅提供資料模型與鏈上／鏈下切分；隱私與權限的一切皆由我們界定 — 這正是本案存在的原因。