Evidence Credential Architecture

وقتی «MASTERED» هنوز به معنی «badge را صادر کن» نیست

یک یادگیرنده برای یک competency، state حاکمیت‌شده‌ی MASTERED دارد و دو artifact مستقلِ transfer پشت آن هستند. حالا issuer می‌خواهد یک credential قابل‌حمل صادر کند. یکی از evidenceها context حساس داخلی دارد و سرویس status credential هنوز آماده نیست. اگر پلتفرم صرفاً MASTERED را به فایل badge تبدیل کند، سه تصمیم متفاوت را یکی کرده‌ایم: یادگیرنده چه چیزی را ثابت کرده، چه کسی authority صدور claim را دارد، و credential حاصل آیا به‌صورت امن قابل verification و مدیریت در طول زمان است یا نه.

در این درس Evidence Credential Issuance & Verification Contract v1 را می‌سازیم؛ قراردادی که mastery evidence را دست‌نخورده نگه می‌دارد، issuance را تصمیمی مستقل و auditable می‌کند، disclosure را حداقلی نگه می‌دارد و قبل از اعتماد به credential، status و verification قابل مشاهده می‌خواهد.

مرز درس و مسیرهای یادگیری

MKN-006 مالک Evidence Credential Architecture است. MKN-001 prerequisite سخت و MKN-005 bridge نرم است. outcomeهای مجاور جدا می‌مانند: این درس Diagnostic/Adaptive Assessment را بازطراحی نمی‌کند و Search Relevance را جذب نمی‌کند.

مسیر Foundation با نقشه‌ی ۱۷ فیلدی و یک fixture baseline شروع می‌شود. مسیر Repair اولین field/state خراب را جدا می‌کند. مسیر Experienced باید authority issuer، privacy، verification و revocation را بدون یکی‌کردن «proof syntactically valid» با «issuance معتبر» دفاع کند. هیچ credential واقعی، wallet هویتی یا learner record واقعی در این درس تغییر نمی‌کند.

مدل ذهنی: mastery evidence → issuance decision → credential → verification/status

جریان اصلی این است:

competency + governed mastery evidence → issuance eligibility review → credential representation → proof/status → holder presentation → verifier result → status/update بدون بازنویسی mastery history

mastery snapshot می‌گوید چه evidence آموزشی تحت policy یک competency پذیرفته شده است. issuance decision می‌گوید issuer مجاز است از آن snapshot یک claim قابل‌حمل بسازد یا نه. credential representation claim، subject، issuer، criteria و referenceها را حمل می‌کند. verification credential ارائه‌شده و proof/status آن را بررسی می‌کند. revoke یا update state credential را عوض می‌کند؛ نباید به عقب برگردد و learning evidence تاریخی را حذف یا بازنویسی کند.

Contract پایه: هفده بُعد قابل ممیزی

برای identity و authority، credential_id، credential_type، subject_id، issuer_id و issuer_authority_ref را ثبت می‌کنیم. competency_id، criteria_ref، evidence_refs و mastery_snapshot_ref claim قابل‌حمل را به learning evidence حاکمیت‌شده وصل می‌کنند. issuance_decision_ref تصمیم issuance را مستقل نگه می‌دارد.

issued_at و validity_or_review زمان‌بندی lifecycle را نشان می‌دهند. credential_status_ref مسیر status/revocation را آشکار می‌کند. proof_or_verification_method و verification_result evidence فنی verification را visible می‌کنند. privacy_disclosure_state مشخص می‌کند evidence مستقیم افشا شده یا با reference حداقلی ارائه شده است. revocation_or_update_reason علت تغییر lifecycle را نگه می‌دارد.

پر بودن ۱۷ فیلد به‌تنهایی approval نیست؛ مقدارها هم باید معتبر و با هم سازگار باشند.

توضیح عمیق: FACT، INFERENCE و DESIGN را قاطی نکن

FACT — Open Badges. منابع فعلی 1EdTech، Open Badges را achievementهای verifiable با metadata تعریف‌شده درباره achievement، issuer و earner معرفی می‌کنند که criteria و در صورت نیاز evidence پشتیبان را هم می‌توانند حمل کنند. Open Badges 3.0 مدل خود را با conventionهای Verifiable Credentials Data Model 2.0 هم‌راستا کرده است.

FACT — Verifiable Credentials. W3C VC Data Model 2.0 یک ecosystem شامل issuer، holder و verifier برای credentialهای machine-verifiable تعریف می‌کند و ملاحظات security و privacy را هم پوشش می‌دهد. این data model درباره representation و exchange credential است؛ درباره اینکه learner در MAKNOW واقعاً competency را MASTER کرده یا نه تصمیم نمی‌گیرد.

INFERENCE — verification بزرگ‌تر از proof syntax است. ممکن است proof از نظر ساختاری درست باشد اما issuer authority، subject binding، status، criteria mapping یا evidence sufficiency غلط باشد. پس verification_result باید چند بُعد evidence را reconcile کند؛ «signature verifies» مساوی «credential claim educationally valid» نیست.

DESIGN — MAKNOW. evidence sufficiency، mastery snapshot governance، authorization صدور، privacy disclosure، lifecycle credential و stateهای HOLD/REVIEW_REQUIRED authority طراحی محلی هستند. استاندارد بیرونی mechanism می‌دهد، نه مجوز دورزدن این تصمیم‌ها.

مثال‌های حل‌شده: baseline hold، authority نامعتبر، privacy-preserving و transfer

Baseline — mastery معتبر است اما status service آماده نیست. mastery snapshot معتبر و دو evidence reference کافی داریم؛ issuer authority هم معتبر است و artifact حساس با reference حداقلی نمایش داده می‌شود. ولی status endpoint هنوز configured نیست و verification اجرا نشده. state محدود باید CREDENTIAL_ISSUANCE_HOLD_STATUS_VERIFICATION باشد. mastery همچنان MASTERED می‌ماند؛ فقط issuance منتظر می‌ماند.

Shortcut غلط — proof ظاهراً معتبر است ولی issuer authority حذف شده. proof نمی‌تواند credential را نجات دهد. state برابر HOLD_ISSUER_AUTHORITY است؛ داشتن proof و داشتن authority برای صدور claim یک سوال نیستند.

حالت آماده با privacy حداقلی. خود attachment حساس از credential package حذف می‌شود اما reference مجاز باقی می‌ماند، evidence sufficiency حفظ می‌شود، status آماده است و verification موفق می‌شود. بدون over-disclosure می‌توان به CREDENTIAL_ISSUANCE_REVIEW_READY رسید.

Transfer — issuer دوم و format متفاوت. همان mastery snapshot را به‌صورت reference استفاده کن، credential id و issuance-decision جدید بساز، authority/status/verification method را دوباره بررسی کن و learning evidence زیرین را duplicate یا rewrite نکن.

failure modeهایی که باید fail-closed باشند

اگر credential یا subject identity نامعلوم باشد، issuer authority وجود نداشته باشد، competency و criteria با هم نخوانند، evidence referenceها گم یا unresolved باشند، mastery snapshot یا issuance decision وجود نداشته باشد، credential صادرشده timestamp معتبر نداشته باشد، status reference نامعلوم باشد، verification method پشتیبانی نشود، privacy state evidence حساس را بیش‌ازحد افشا کند، verification شکست بخورد یا credential revoked بدون reason باشد، outcome باید HOLD بماند.

دو failure اهمیت ویژه دارند. اول، revocation مساوی rollback mastery نیست؛ تغییر mastery snapshot به‌خاطر revoke شدن credential یک history mutation است و باید fail شود. دوم، transfer مساوی copy نیست؛ issuer یا format جدید به mapping/issuance decision جدید نیاز دارد، حتی اگر همان mastery snapshot reference شود.

گزینه‌ها و trade-offها: embed، reference، status و lifecycle

Embed کردن full evidence review را ساده می‌کند اما privacy exposure و portability risk را بالا می‌برد. Reference دادن disclosure را کم می‌کند اما به resolution پایدار، authorized و provenance روشن نیاز دارد. فایل credential static ساده است، ولی به‌تنهایی revoke/suspend بعدی را نشان نمی‌دهد؛ status mechanism dependency عملیاتی اضافه می‌کند اما lifecycle را auditable می‌سازد.

Validity طولانی renewal friction را کم می‌کند اما claim stale ممکن است مدت بیشتری active بماند. review مکرر freshness را بهتر می‌کند اما هزینه دارد. format پرکاربرد portability را بهتر می‌کند ولی format هرگز evidence sufficiency را تعریف نمی‌کند. Contract این trade-offها را visible نگه می‌دارد.

پل مسیر Experienced: trust یک زنجیره است، نه یک boolean امضا

برای engineer باتجربه، trust credential را زنجیره‌ای از linkهای مستقل ببین: subject binding، issuer identity، authority issuer برای competency، criteria/evidence mapping، mastery snapshot immutable reference، issuance decision، credential status، proof verification و disclosure policy.

Cryptographic verification سوال محدودتری از educational validity جواب می‌دهد. credential می‌تواند perfectly verified باشد ولی competency غلط داشته باشد، issuer authority نداشته باشد یا revoked باشد. برعکس، revoke شدن credential اثبات نمی‌کند learner competency را «فراموش کرده». این domainها باید state machineهای جدا بمانند.

تمرین هدایت‌شده و مستقل

1. baseline را اجرا کن و توضیح بده چرا mastery معتبر می‌ماند ولی issuance hold می‌شود. 2. issuer authority را حذف کن اما proof syntax را نگه دار. 3. attachment حساس را با privacy-preserving reference جایگزین کن و evidence sufficiency را بررسی کن. 4. credential را revoked کن ولی mastery snapshot را ثابت نگه دار. 5. revocation reason را حذف کن و HOLD را ببین. 6. issuer دوم و format جدید بده و issuance mapping را بدون copy کردن baseline decision از نو بساز.

در تمرین مستقل expected state حذف می‌شود؛ فقط ۱۷ dimension Contract، facts visible fixture و deterministic rules در اختیار learner قرار می‌گیرد.

شواهد Verification: reviewer چه چیزی را باید بازسازی کند؟

Reviewer باید subject، issuer و issuer authority؛ competency و criteria؛ evidence refs و mastery snapshot؛ issuance decision؛ زمان و lifecycle؛ credential status؛ proof/verification method؛ privacy disclosure state؛ verification result و revoke/update reason را از artifactهای visible بازسازی کند. همچنین باید نشان دهد هیچ credential lifecycle action، mastery history را mutate نکرده است.

Lab deterministic baseline hold، issuance آماده، issuer authority missing، subject/criteria mismatch، evidence missing/unresolved، mastery و issuance ref missing، timing نامعتبر، status/proof/privacy/verification failure، revoke بدون reason، revoke با mastery ثابت، mastery-history mutation، privacy-preserving reference و transfer به issuer دوم با و بدون rebuild mapping را پوشش می‌دهد.

ارزیابی و Transfer: mastery یکسان، issuer و format جدید

Assessment چهار بخش blocking دارد: مرز MKN-006 و یک non-goal را توضیح بده؛ Contract baseline را بساز؛ proof ظاهراً معتبر با issuer authority حذف‌شده را diagnose کن؛ و transfer را برای issuer دوم با credential format متفاوت بازسازی کن.

Transfer فقط وقتی PASS است که mastery_snapshot_ref همان learning evidence را به‌صورت reference نگه دارد، credential/issuance decision جدید ساخته شود، issuer authority و status/verification semantics دوباره ارزیابی شوند و baseline decision oracle نباشد. اگر issuer دوم authority ندارد، outcome درست HOLD است—even اگر learning evidence هیچ تغییری نکرده باشد.

منابع، freshness و مرز authority

منابع رسمی 1EdTech Open Badges و W3C Verifiable Credentials در 2026-09-13 دوباره بررسی شدند. 1EdTech همچنان Open Badges 3.0 را achievementهای verifiable با issuer/earner، criteria و evidence metadata توصیف می‌کند و منابع specification آن مدل را با VC Data Model 2.0 هم‌راستا می‌دانند. W3C VC Data Model 2.0 همچنان Recommendation است؛ هم‌زمان W3C یک Working Draft جدیدتر 2.1 هم دارد، پس semantics evolving باید تا 2027-01-15 یا زودتر در صورت تغییر material دوباره بررسی شوند.

این استانداردها منبع FACT برای mechanism هستند. MAKNOW authority طراحی را برای evidence sufficiency، issuance eligibility، privacy policy، credential lifecycle، review ownership و ممنوعیت بازنویسی mastery history نگه می‌دارد.