چرخش Internet Identity به سمت MCP: یک ریدایرکت که هویت عامل را آشکار می‌کند

آخرین انتشار Internet Identity بخش کوچک اما مهمی از تجربه ورود MCP را تغییر می‌دهد: اتصال اکنون می‌تواند از انتقال مبتنی بر URL و ریدایرکت استفاده کند، نه اینکه فقط به جریان‌های توکار یا اختصاصی هر برنامه متکی باشد.

انتشار ۳۱ ژوئیه ۲۰۲۶ با عنوان «عرضه عمومی MCP» معرفی شده و می‌گوید Internet Identity را برای عرضه عمومی MCP آماده می‌کند. مشخص‌ترین تغییر پروتکلی آن، پشتیبانی از انتقال URL در ICRC-167 به‌عنوان انتقال امضاکننده است. در عمل، اتصال MCP می‌تواند کاربر را از طریق یک ریدایرکت مرورگری عبور دهد؛ Internet Identity احراز هویت را انجام می‌دهد و نتیجه مجوز را به برنامه درخواست‌کننده بازمی‌گرداند.

اهمیت این تغییر از آنجا می‌آید که کلاینت‌های MCP به‌تدریج به رابط دوم برنامه‌ها تبدیل می‌شوند. کاربر ممکن است در مرورگر احراز هویت کند و سپس به یک عامل اجازه دهد از طرف او ابزارهایی را فراخوانی کند. انتقال مبتنی بر ریدایرکت یک مرز آشنای مرورگری برای این واگذاری ایجاد می‌کند: کلاینت اتصال را آغاز می‌کند، Internet Identity کاربر را احراز هویت می‌کند و برنامه، delegation حاصل را از طریق انتقال تعریف‌شده دریافت می‌کند.

این انتشار همچنین انتخاب هویت را در صفحه اتصال MCP قابل مشاهده می‌کند. طبق توضیح Internet Identity، رابط اکنون نشان می‌دهد اتصال قرار است با کدام هویت عمل کند. این فقط یک بهبود تجربه کاربری نیست. کاربران می‌توانند چند هویت اینترنت کامپیوتری داشته باشند و عاملی که با principal اشتباه کار کند، ممکن است وضعیت نادرست برنامه را بخواند یا تغییر دهد. نمایش هویت انتخاب‌شده یک نقطه کنترل پیش از واگذاری اختیار به کاربر می‌دهد.

همین انتشار شامل آزمون رگرسیون برای تصاحب SSO میان‌دامنه‌ای و مستندات مدل تهدید نیز هست. همچنین مسیر ثبت‌نام را تغییر می‌دهد تا دسترسی هوش مصنوعی هنگام ثبت‌نام فعال شود و همه anchorهای موجود به دسترسی هوش مصنوعی در اتصال رسمی منتقل شوند. این تغییرات نشان می‌دهند مرز امنیتی فقط خود امضا نیست؛ هویت انتخاب‌شده، دامنه آغازکننده جریان و شیوه ثبت اتصال نیز بخشی از آن هستند.

سازندگان ICP باید این به‌روزرسانی را یک تغییر در یکپارچه‌سازی مجوز بدانند، نه دلیلی برای قابل‌اعتماد دانستن گسترده عامل‌ها. راهنمای توسعه‌دهندگان Internet Identity همچنان مدل اصلی را توضیح می‌دهد: کاربر با passkey یا یک ارائه‌دهنده OpenID احراز هویت می‌کند، Internet Identity یک هویت delegation موقت می‌سازد و canister، principal حاصل را به‌عنوان فراخواننده می‌بیند. delegationها منقضی می‌شوند و هر مبدأ frontend معمولاً principal متفاوتی دریافت می‌کند تا از ردیابی میان برنامه‌ها جلوگیری شود.

برای یک برنامه ICP مجهز به MCP، چک‌لیست عملی چنین است:

• پیش از اعطای دسترسی، principal یا زمینه هویت انتخاب‌شده را نمایش دهید.
• ابزارها و مجوزها را به حداقل اقدام‌های موردنیاز عامل محدود کنید.
• هنگام پیاده‌سازی callback، اعتبارسنجی مبدأ و ریدایرکت را حفظ کنید.
• delegation منقضی‌شده، ورود لغوشده، انتخاب هویت اشتباه و رفتار میان‌دامنه‌ای را آزمایش کنید.
• امضاکننده Internet Identity و داده delegation را در backend بررسی کنید؛ یک امضای معتبر به‌تنهایی اثبات نمی‌کند صادرکننده چه کسی بوده است.

یک محدودیت factual همچنان وجود دارد: یادداشت انتشار می‌گوید Internet Identity را برای عرضه عمومی MCP آماده می‌کند، اما به‌طور مستقل ثابت نمی‌کند که همه اتصال‌های production همین انتقال جدید را پذیرفته‌اند. بنابراین سازندگان باید نسخه استقرار و اتصالی را که واقعاً هدف گرفته‌اند بررسی کنند.

تغییر بزرگ‌تر معماری است. مجوزدهی MCP در حال تبدیل شدن به یک جریان درجه‌یک در Internet Identity است؛ جریانی با ریدایرکت مرورگری، مرحله صریح انتخاب principal و مدل امنیتی‌ای که می‌توان آن را در مرز میان کاربر، عامل، اتصال و canister بازبینی کرد.