ورود با تغییر مسیر: انتقال ICRC-167 اینترنتایدنتیتی احراز هویت MCP را با مرورگرهای بیشتری سازگار میکند
انتشار ۳۱ ژوئیه اینترنتایدنتیتی، انتقال URL مبتنی بر ICRC-167 را اضافه کرده است؛ بنابراین جریان ورود MCP میتواند بهجای اتکا به پنجرههای بازشو و postMessage از تغییر مسیر کامل مرورگر استفاده کند. این تغییر سازگاری را افزایش میدهد، اما توسعهدهندگان همچنان به فهرست مجاز دقیق callback و نمایش روشن هویت نیاز دارند.

آخرین گام اینترنتایدنتیتی برای MCP بیشتر از آنکه افزودن یک قابلیت هوش مصنوعی دیگر باشد، تغییر محل انجام احراز هویت است. در انتشار ۳۱ ژوئیه ۲۰۲۶، انتقال URL مبتنی بر ICRC-167 بهعنوان یکی از روشهای انتقال امضاکننده اضافه شد و مسیر ورود به برنامه روانتر گردید. همین انتشار همچنین اعلام میکند که اینترنتایدنتیتی برای دسترسی عمومی MCP آماده شده است.
در انتقال URL، مرورگر بهصورت سطحبالا به صفحه دیگری هدایت میشود. برنامه بهجای باز کردن امضاکننده در پنجرهای جدا و تبادل پیام از طریق postMessage، درخواست را در قطعه URL ارسال میکند؛ امضاکننده آن را پردازش میکند و مرورگر با پاسخ، به callback URL طرفِ متکی بازمیگردد. بسته رسمی @icp-sdk/signer این روش را برای زمانی مناسب میداند که پنجرههای بازشو در دسترس نیستند؛ از جمله در جریانهای ورود با تغییر مسیر کامل صفحه.
این جزئیات برای کلاینتهای MCP اهمیت دارد. ابزارهای هوش مصنوعی بیشتر در محیطهایی اجرا میشوند که رفتار پنجرههای بازشو در آنها محدود، ناپایدار یا اساساً ناممکن است. جریان مبتنی بر تغییر مسیر، یک واگذاری معمول مرورگر ایجاد میکند و مدل امضاکننده را حفظ میکند: برنامه همچنان درخواست مجوز یا امضا میدهد و اینترنتایدنتیتی همچنان تأیید کاربر را میانجیگری میکند.
این انتشار در کنار انتقال جدید، دو نشانه مهم ایمنی نیز اضافه میکند. نخست، رابط کاربری نشان میدهد اتصال MCP با کدام هویت عمل خواهد کرد. دوم، انتشار شامل مهاجرتی است که دسترسی هوش مصنوعی را برای anchorهای متصل به رابط رسمی فعال میکند. این تغییرها زمینه مجوز را شفافتر میکنند و خطر تأیید اقدامی را کاهش میدهند که کاربر بدون آگاهی از هویت واگذارشده انجام دهد.
توسعهدهندگان باید callback URL را یک مرز امنیتی بدانند، نه صرفاً یک پارامتر رفاهی. مستندات SDK میگوید callback باید یک URL مطلق روی مبدأیی باشد که طرف متکی کنترل میکند و همان مبدأ باید آن را در فهرست مجاز /.well-known/ii-auth-callbacks اعلام کرده باشد. بهتر است هر جریان اصلی—اتصال، امضا یا درخواست ویژگیها—مسیر و callback URL جداگانه خود را داشته باشد تا شروع درخواست و بازگشت امضاکننده بهصورت قطعی مدیریت شوند.
نتیجه عملی این است که احراز هویت ICP در لبه مرورگر انعطافپذیرتر میشود. یکپارچهسازیهای MCP میتوانند از محیطهای مبتنی بر پنجره بازشو و تغییر مسیر پشتیبانی کنند، بدون آنکه سامانهای جدا برای اعتبارنامه بسازند؛ اما مسیر تغییر مسیر نیاز به کنترل مبدأ، اعتبارسنجی callback، شفافیت رضایت کاربر و محدودسازی دقیق هویت را از بین نمیبرد.
یک ملاحظه واقعی باقی میماند: انتشار ۳۱ ژوئیه و بسته SDK، انتقال و تغییرهای اینترنتایدنتیتی را مستند میکنند، اما ثابت نمیکنند که همه طرفهای متکی شخص ثالث این انتقال را در محیط تولید پذیرفتهاند. پذیرش همچنان به هر برنامه وابسته است.
خبرخوان را در ایمیل بگیرید
هر سیگنال تازه، مستقیم از خط تولید. بدون مزاحمت، لغو عضویت در هر زمان.


