آنچه با باز شدن تسویه‌حساب به روی عامل‌ها تغییر کرد
یک عامل مرورگر که خریدی را کامل می‌کند، در حال کلیک کردن روی یک فرم نیست. او در حال اعمال اختیار خرج کردن تفویض‌شده است. کاربر به یک فرایند نرم‌افزاری توانایی انتخاب فروشنده، چیدن سبد خرید، انتخاب روش پرداخت ذخیره‌شده و تأیید مبلغ کل را سپرده است. این یک رابطهٔ کارگزار-کارفرما به معنای حقوقی است که در مسیری از رویدادهای DOM و فراخوانی‌های شبکه فشرده شده است.
اما فروشنده یک نشست می‌بیند. یک رشتهٔ user-agent، یک کوکی، یک اثر انگشت دستگاه و یک توکن پرداخت می‌بیند. کارفرما را نمی‌بیند. کاربر یک نتیجه می‌بیند: تأیید سفارش، یک برداشت، یک تخمین تحویل. کاربر قراردادی را که برای تولید آن نتیجه شکل گرفته است نمی‌بیند. و شرایطی که عامل در میانهٔ مسیر پذیرفته است — شرایط خدمات فعلی فروشنده، سیاست بازگشت کالا، شرط داوری، شرایط تمدید اشتراک — برای هیچ‌کس جز پنجرهٔ زمینهٔ عامل قابل مشاهده نیست، که با پایان یافتن اجرا دور ریخته می‌شود.
این تغییر ساختاری است. تسویه‌حساب قبلاً یک کلیک‌کردن بود: یک انسان صفحهٔ شرایط را می‌خواند (یا نمی‌خواند) و روی دکمه‌ای کلیک می‌کرد. کلیک همان رضایت بود و صفحه همان سند. حالا رضایت توسط یک مدل تولید می‌شود، ممکن است صفحه هرگز برای انسانی رندر نشده باشد، و سند یک توالی توکن است که هیچ‌کس نگه نمی‌دارد. مسئلهٔ رضایت از یک رویداد رابط کاربری به یک قرارداد ماشینی منتقل شده است، و مصنوعاتی که قبلاً آن را مستند می‌کردند همراه آن منتقل نشده‌اند.
چرا یک کلید تنظیمات کافی نیست
پاسخ نهادی رایج یک کلید تنظیمات است: سوئیچی در پلتفرم عامل که می‌گوید آیا عامل می‌تواند معامله کند، شاید با یک فهرست مجاز فروشندگان. این یک مدل رضایت نیست. یک پرچم قابلیت است.
رضایت در تجارت جهانی نیست. به‌ازای هر معامله، هر فروشنده و هر بازهٔ مبلغ است. کاربر ممکن است به یک عامل اجازه دهد تا یک فیلتر جایگزین از یک تأمین‌کنندهٔ شناخته‌شده تا سقفی modest بخرد، و به‌طور جداگانه یک خرید یک‌باره از یک فروشندهٔ ناآشنا با مبلغی بالاتر پس از بررسی سبد خرید را مجاز کند. یک سوئیچ واحد نمی‌تواند آن تمایز را بیان کند، و نمی‌تواند تفاوت بین تمدید اشتراک دوره‌ای و اولین خرید را بیان کند. مجوز یک شکل دارد: کارفرما، عامل، فروشنده، دامنه، سقف، انقضا. یک مقدار بولی شکلی ندارد.
لغو همین مشکل را دارد. اگر تنها بازنمایی رضایت یک سوئیچ باشد، لغو یعنی چرخاندن سوئیچ و امید به اینکه عامل آن را ببیند. اما یک عامل در میانهٔ اجرا ممکن است قبلاً سبد خرید را چیده، روش پرداخت را انتخاب کرده و منتظر مرحلهٔ تأیید باشد. لغو باید در میانهٔ اجرا ممکن باشد، که مستلزم آن است که مجوز یک شیء آدرس‌پذیر باشد — چیزی که بتوان نامید، جستجو کرد و در حین پرواز مسیر باطل کرد. یک سوئیچ آدرس‌پذیر نیست. یک حالت است، نه یک سند.
اختلافات سومین شکست را آشکار می‌کنند. وقتی یک برداشت مورد اعتراض قرار می‌گیرد، سؤال این نیست که تنظیمات کاربر ماه گذشته چه بود. سؤال این است که عامل در لحظهٔ پذیرش چه شرایطی را پذیرفته است، و آیا آن شرایط در دامنهٔ مجوز کاربر بوده است. صفحات شرایط تغییر می‌کنند. فروشندگان شرط‌های داوری، هزینه‌های بازگرداندن کالا و زبان تمدید را بدون اطلاع به‌روزرسانی می‌کنند. سندی از شرایط در زمان آخرین بازدید کاربر، مدرکی از آنچه در معاملهٔ مورد اختلاف توافق شده نیست. بدون یک مصنوع به‌ازای هر معامله، فرایند اختلاف چیزی برای استدلال ندارد جز صفحهٔ فعلی فروشنده و خاطرهٔ کاربر.
طرحی از یک دفتر کل رضایت
مکانیزمی که این را حل می‌کند یک دفتر کل رضایت است: یک سند فقط-افزودنی و قابل پرس‌وجو از هر تفویض اختیار خرج کردن، که در لحظهٔ اعمال مجوز نوشته می‌شود.
هر ورودی باید حداقل شامل فیلدهای زیر باشد:
entry_id یکتا، یکنوا
principal انسان یا سازمانی که اختیار را اعطا می‌کند
agent_id هویت نرم‌افزاری که آن را اعمال می‌کند
merchant_id طرف مقابل
scope مثلاً خرید یک‌باره، تمدید اشتراک، بازگشت
amount_ceiling حداکثر مبلغی که عامل می‌تواند متعهد شود
currency کد ISO
expiry زمان پس از آن مجوز باطل است
terms_hash خلاصهٔ شرایط ارائه‌شده در زمان پذیرش
terms_uri محل سند شرایط
timestamp زمان نوشتن ورودی
parent_entry برای لغوها و اصلاحات
هش شرایط فیلد باربر است. نیازی به ذخیرهٔ سند کامل شرایط ندارد، فقط یک خلاصه که بتوان آن را با تاریخچهٔ نسخه‌های منتشرشدهٔ فروشنده بررسی کرد. اگر فروشنده بعداً صفحه را تغییر دهد، هش هنوز نسخه‌ای را که در زمان پذیرش فعال بوده شناسایی می‌کند. terms_uri به فرایند اختلاف اشاره‌گری برای بازیابی آن می‌دهد.
ورودی‌ها فقط-افزودنی هستند. لغو مجوز اصلی را تغییر نمی‌دهد؛ یک ورودی جدید با parent_entry که به مجوز اشاره می‌کند و دامنهٔ revoked می‌نویسد. اصلی قابل پرس‌وجو باقی می‌ماند. این مهم است زیرا یک اختلاف ممکن است نه تنها نیاز به اثبات پس گرفتن رضایت داشته باشد بلکه زمان آن، و اینکه آیا عامل قبلاً معامله را قبل از رسیدن لغو متعهد شده است یا خیر. یک گزارش فقط-افزودنی به آن سؤال پاسخ می‌دهد؛ یک پرچم قابل تغییر آن را پاک می‌کند.
دفتر کل باید توسط دو طرف با منافع متفاوت قابل پرس‌وجو باشد. کاربر باید در یک نما هر تفویضی که عامل‌هایش اعمال کرده‌اند را با سقف‌ها و انقضاها ببیند، و هر کدام که هنوز فعال است را لغو کند. فرایند اختلاف فروشنده باید هش شرایط و دامنه را برای یک معاملهٔ خاص بازیابی کند، بدون اینکه به سایر مجوزهای کاربر دسترسی پیدا کند. این یک مسئلهٔ مجوز خواندن است، نه یک مسئلهٔ ذخیره‌سازی، و بخشی است که به احتمال زیاد در 
k-network-cables-f7a795-35eb46.jpg)
یک تعامل مشخص: یک عامل به تسویه‌حساب می‌رسد، صفحهٔ فروشنده شرایط را ارائه می‌دهد، عامل خلاصه را محاسبه و یک ورودی دفتر کل با فروشنده، دامنه، سقف و هش می‌نویسد. مجوز پرداخت entry_id را حمل می‌کند. اگر کاربر در حالی که عامل منتظر مرحلهٔ تأیید است لغو کند، ورودی لغو نوشته می‌شود و خواندن بعدی دفتر کل توسط عامل وضعیت لغو شده را برمی‌گرداند و باعث می‌شود مسیر را رها کند. اگر معامله به هر حال تسویه شود، دفتر کل ترتیب را نشان می‌دهد: مجوز، لغو، تسویه. آن ترتیب همان مدرک است.
معاوضهٔ صادقانه
یک دفتر کل رضایت به هر تسویه‌حساب عاملی تأخیر و یک وابستگی اضافه می‌کند. نوشتن یک ورودی، هش کردن شرایط و بررسی لغو رفت‌و‌برگشت‌هایی هستند که یک انسان کلیک‌کننده روی دکمه پرداخت نمی‌کند. اگر دفتر کل در دسترس نباشد، عامل یا بسته شکست می‌خورد — رها کردن یک خرید مشروع — یا باز شکست می‌خورد، که هدف را از بین می‌برد. طراحی باید انتخاب کند، و هیچ‌کدام رایگان نیست. دفتر کلی که در هر مرحله از مسیر پرس‌وجو شود عامل را کند می‌کند؛ دفتر کلی که فقط در زمان مجوز پرس‌وجو شود لغوهای میانهٔ اجرا را از دست می‌دهد. سازش عملی این است که در زمان مجوز بنویسیم و برای لغو در بازه‌ای محدود نظرسنجی کنیم، با پذیرش پنجره‌ای که در آن یک مجوز لغوشده ممکن است هنوز متعهد شود. آن پنجره باید در ورودی ذکر شود، نه پنهان.
هزینهٔ حریم خصوصی نیز وجود دارد. یک دفتر کل از تفویض‌های خرج کردن یک سند رفتاری غنی است. باید طوری دامنه‌بندی شود که فروشندگان فقط ورودی‌های مربوط به معاملات خود را ببینند، و کاربر توانایی صادرات و حذف ورودی‌های خود را با رعایت الزامات نگهداری اختلاف حفظ کند. فقط-افزودنی به معنای جاودان نیست؛ به این معناست که حذف خودش یک ورودی است.
تعامل با ریسک تجارت
بانک‌ها و شبکه‌های کارت که تجارت عاملی را علامت‌گذاری می‌کنند، به بیش از نرخ تقلب واکنش نشان می‌دهند. آن‌ها به نبود یک مصنوع واکنش نشان می‌دهند. یک مدل ریسک که همیشه به حضور یک انسان در نقطهٔ مجوز تکیه کرده است، اکنون با نشستی بدون کارفرما، بدون رضایت قابل خواندن و بدون سند شرایط روبرو می‌شود. سیگنال تقلب ضعیف است زیرا الگوی مشروع و الگوی سوءاستفاده از سمت شبکه یکسان به نظر می‌رسند: یک اعتبارنامهٔ ذخیره‌شده که توسط نرم‌افزار استفاده می‌شود، بدون انسان در حلقه.
یک دفتر کل رضایت آن ابهام را از بین نمی‌برد، اما به سیستم‌های ریسک چیزی برای امتیازدهی می‌دهد. یک مجوز که entry_id با مجوز منطبق، سقف قابل قبول و انقضای فعال را حمل می‌کند، شیئی متفاوت از مجوزی بدون منشأ است. با گذشت زمان، حضور مصنوع خودش یک سیگنال می‌شود، و نبودش دلیلی برای رد کردن. نهادهایی که اول این کار را می‌کنند، دربارهٔ عامل‌ها محتاط نیستند؛ آن‌ها سندی را می‌سازند که تجارت عاملی را برای سیستم‌هایی که قبلاً آن را اداره می‌کنند قابل خواندن می‌کند.
به‌روزرسانی شرایط پاسخ نیست. دفتر کل پاسخ است.