دروازه‌بان تازهٔ Internet Identity: انتشار ۷ اوت برای توسعه‌دهندگان ICP چه تغییری دارد؟

Internet Identity در حال تبدیل‌شدن از یک سرویس احراز هویت سریع‌التغییر به لایه‌ای آگاه از سیاست‌های دسترسی برای برنامه‌های Internet Computer است. جدیدترین انتشار این پروژه که در ۷ اوت ۲۰۲۶ منتشر شد، «دسترس‌پذیری عمومی MVP کنترل دسترسی IdP» نام دارد. تمرکز عملی آن، کنترل ارائه‌دهندگان هویتی است که هر برنامه می‌تواند از آن‌ها استفاده کند و همچنین انتقال محدودیت‌های نشست SSO در سراسر جریان احراز هویت.

این انتشار شامل تغییرات backend است که مقدار session_max_age_seconds یک دامنهٔ SSO را تعیین می‌کند و مهلت نشست را در بستهٔ ویژگی‌ها قرار می‌دهد. در frontend نیز تفویض‌نامهٔ کاربر به طول نشست SSO محدود می‌شود. به زبان ساده، برنامه نباید تفویض‌نامه‌ای دریافت کند که بیشتر از نشست SSO بالادستی عمر داشته باشد.

این یک مرز مهم برای توسعه‌دهندگان است. تفویض‌نامهٔ طولانی‌مدت می‌تواند便利 باشد، اما ممکن است از سیاست ورود سازمانی بیشتر دوام بیاورد. با قراردادن مهلت SSO در نتیجهٔ احراز هویت، Internet Identity راه روشن‌تری برای رعایت سیاست نشست تعیین‌شده توسط Google، Apple، Microsoft یا هر ارائه‌دهندهٔ پیکربندی‌شدهٔ دیگر فراهم می‌کند. البته این انتشار نیاز به مجوزدهی در خود برنامه را از بین نمی‌برد: تفویض‌نامهٔ معتبر فقط احراز هویت را ثابت می‌کند، نه اینکه کاربر مجاز به انجام هر عملی در یک canister باشد.

زمان‌بندی این تغییر نیز مهم است. نگه‌دارندگان Internet Identity در ژوئن اعلام کردند که پروژه می‌تواند تا دو پیشنهاد انتشار در هفته ارائه کند: یک پیشنهاد اصلی در جمعه و، در صورت مناسب‌بودن تغییرات، یک پیشنهاد ثانویهٔ کوچک‌تر در ابتدای هفتهٔ بعد. انتشار اوت نشان می‌دهد این روند در عمل چگونه است: تغییرات مکرر، artifactهای جداگانه برای backend و frontend، و انتشار commit و روش بررسی hash.

برای اپراتورها، صفحهٔ انتشار artifactهای Wasm جداگانهٔ backend و frontend، hashهای SHA-256 و commit دقیق مورد استفاده برای ساخت را فهرست می‌کند. بنابراین این صفحه فقط اعلام یک قابلیت نیست. بازبین می‌تواند commit c78d1b99c5c161c74d8d8f795ad1072826f90673 را دریافت کند، ماژول‌ها را بسازد و hashهای حاصل را پیش از ارزیابی پیشنهاد ارتقا با مقادیر انتشار مقایسه کند.

برای تیم‌های سازندهٔ برنامه، سه اقدام منطقی است. نخست، مدت مؤثر نشست SSO را بخشی از طراحی مجوزدهی و خروج از حساب بدانید، نه جزئی نامرئی از ارائه‌دهندهٔ هویت. دوم، یکپارچه‌سازی backend و frontend را با انتشار فعلی Internet Identity آزمایش کنید، زیرا پروژه آن‌ها را به‌صورت artifactهای جداگانهٔ canister منتشر می‌کند. سوم، اگر برنامهٔ شما به SSO، بازیابی حساب یا کنترل دسترسی مرتبط با هوش مصنوعی وابسته است، پیشنهادهای انتشار و changelogها را دقیق دنبال کنید.

این روند یک بده‌بستان دارد. انتشار سریع‌تر می‌تواند فاصلهٔ میان اصلاح یک مشکل و رسیدن آن به کاربران را کم کند، اما مقدار مطالبی را که بازبینان پیشنهادها و توسعه‌دهندگان پایین‌دست باید دنبال کنند نیز افزایش می‌دهد. سرعت بالاتر انتشار یک برنامهٔ عملیاتی است، نه تضمینی برای اینکه هر هفته حتماً دو ارتقای production انجام شود؛ مناسب‌بودن انتشار و بررسی جامعه همچنان اهمیت دارد.

داستان بزرگ‌تر فقط اضافه‌شدن یک قابلیت ورود دیگر نیست. Internet Identity در حال قابل‌مشاهده‌ترکردن سیاست هویت در مرز canister است. برای توسعه‌دهندگان ICP، این یعنی یکپارچه‌سازی‌های احراز هویت می‌توانند دقیق‌تر شوند—به شرط آنکه برنامه‌ها فرض‌های مربوط به نشست و مجوزدهی را صریحاً منتقل کنند و ورود موفق را پایان مدل امنیتی ندانند.