Federated Credential Management API (FedCM) נשלח ב-Chrome בגרסה 108 (כרגע בערוץ הבטא). כשהממשק היציב של Chrome יישלח בסוף נובמבר 2022, ה-API של FedCM יפעל ב-Chrome בלי צורך בסימון או באסימון גרסת מקור לניסיון.
FedCM הוא ממשק API של ארגז חול לפרטיות שמספק הפשטה ספציפית לתרחיש לדוגמה עבור תהליכי זהות מאוחדים באינטרנט. FedCM חושף תיבות דו-שיח בגישור של דפדפן שמאפשרות למשתמשים לבחור חשבונות מספקי זהויות כדי להתחבר לאתרים.
בודקים את השינויים האחרונים ב-API בדף העדכון המצטבר.
אנחנו מתכננים להוסיף כמה תכונות חדשות על סמך המשוב שקיבלנו מספקי זהויות (IdP), מצדדים נסמך (RP) ומספקי דפדפנים. אנחנו מקווים שספקי זהויות יאמצו את FedCM, אבל חשוב לזכור ש-FedCM הוא עדיין API בפיתוח פעיל ושצפויים שינויים לא תואמים לאחור עד הרבעון הרביעי של 2023.
כדי למזער את האתגרים שכרוכים בפריסת שינויים לא תואמים לאחור, יש לנו כרגע שתי המלצות לספקי זהויות:
- הירשמו לניוזלטר שלנו, שבו נספק עדכונים עם התפתחות ה-API.
- אנחנו ממליצים מאוד לספקי IdP להפיץ את ה-API של FedCM באמצעות ערכות SDK של JavaScript בזמן שה-API מתבגר, ולא לעודד אותם להשתמש ב-SDK באירוח עצמי. כך תוכלו להבטיח שה-IdPs יוכלו לבצע שינויים כשה-API יתפתח, בלי שיצטרכו לבקש מכל הצדדים המסתמכים שלהם לבצע פריסה מחדש.
רקע
בעשור האחרון, איחוד שירותי אימות הזהות שיחק תפקיד מרכזי בהעלאת רמת האמינות של האימות באינטרנט מבחינת אמינות, קלות השימוש (לדוגמה, כניסה יחידה (SSO) ללא סיסמה) ואבטחה (למשל, עמידות משופרת למתקפות פישינג ודחיסת פרטי כניסה) בהשוואה לשם המשתמש ולסיסמאות באתר.
לצערנו, המנגנונים שאיחוד שירותי אימות הזהות הסתמך עליהם (iframes, הפניות אוטומטיות וקובצי cookie) מנוצלים באופן פעיל כדי לעקוב אחר משתמשים באינטרנט. מכיוון שסוכן המשתמש לא יכול להבחין בין איחוד זהויות לבין מעקב, ההקלות בסוגים השונים של ניצול לרעה מקשות על הפריסה של איחוד שירותי אימות הזהות.
FedCM הוא תהליך רב-שלבי לשיפור הזהות באינטרנט. בשלב הראשון אנחנו מתמקדים בצמצום ההשפעה של הפסקת השימוש בקובצי cookie של צד שלישי על זהות מאוחדת (בהמשך מוסבר מה השלב הבא).
Chrome מבצע ניסויים עם FedCM מאז גרסה 101 של Chrome.
צוות Google Identity Services השתתף בגרסת המקור לניסיון והוכיח שמעבר לתהליך כניסה פרטי ומאובטח יותר שלא מסתמך על קובצי cookie של צד שלישי, יכול להתבצע בשקיפות באמצעות עדכונים תואמים לאחור בספרייה הקיימת שלהם. הם הפעילו את FedCM ב-20 גורמים מסתמכים שונים ויותר מ-300 אלף משתמשים שנכנסו אליהם במהלך גרסאות המקור לניסיון. מידע נוסף על הסרת התלות שלהם בקובצי Cookie של צד שלישי
אנחנו שמחים למצוא מכנה משותף עם Mozilla, שהתנהלה באופן פעיל בדיונים בנושא עיצוב והתחילו ליצור אב טיפוס של FedCM ב-Firefox. Apple ציינה תמיכה כללית במפרט, ומתחילה להשתתף בדיונים ב-FedID CG.
המאמרים הבאים
אנחנו פועלים להשקת מספר שינויים ב-FedCM.
יש כמה דברים שאנחנו יודעים שעדיין צריך לעשות, כולל בעיות ששמענו עליהן מ-IdP, מגורמים מוגבלים ומספקי דפדפנים. אנחנו מאמינים שאנחנו יודעים איך לפתור את הבעיות האלה:
- תמיכה ב-iframe ממקורות שונים: ספקי IdP יכולים לקרוא ל-FedCM מתוך iframe ממקורות שונים.
- לחצן בהתאמה אישית: ספקי IdP יכולים להציג זהות של משתמש חוזר בלחצן הכניסה מתוך iframe ממקורות שונים.
- נקודת קצה של מדדים: מספקת מדדי ביצועים ל-IdP.
בנוסף, אנחנו בוחנים באופן פעיל בעיות שעדיין לא נפתרו, כולל הצעות ספציפיות שאנחנו בודקים או יוצרים אב טיפוס:
- CORS: אנחנו מדברים עם Apple ו-Mozilla כדי לשפר את מפרט האחזורים של FedCM.
- Multiple-IdP API: אנחנו בוחנים דרכים לתמוך במספר IdPs כדי לאפשר שיתוף פעולה ב-FedCM בבוחר החשבונות של FedCM.
- IdP Sign-in Status API: Mozilla זיהתה בעיית התקפה מתוזמנת, ואנחנו בוחנים דרכים שבהן IdP שיודיע לדפדפן על סטטוס הכניסה של המשתמש באופן יזום כדי לצמצם את הבעיה.
- כניסה ל-IdP API: כדי לתמוך בתרחישים שונים, כשמשתמש לא מחובר ל-IdP, הדפדפן מספק ממשק משתמש כדי שהוא יכול להיכנס בלי לצאת מה-RP.
לבסוף, יש דברים שאנחנו חושבים שצריך לעשות עדיין, על סמך משוב של Mozilla, Apple ובודקים של TAG. אנחנו פועלים כדי להעריך את הפתרון הטוב ביותר לשאלות הפתוחות הבאות:
- שיפור היכולת להבין את המשתמשים וכוונת ההתאמה שלהם: כפי שציינו ב-Mozilla, אנחנו רוצים להמשיך לחקור ניסוחים שונים של חוויית משתמש ואזורי שטח, וגם קריטריונים שונים ליצירת מודעות.
- מאפייני זהות וגילוי נאות סלקטיבי: כפי שציינו הבודקים של TAG, אנחנו רוצים לספק מנגנון לשיתוף סלקטיבי יותר או פחות מאפייני זהות (כמו כתובות אימייל, טווח גילים, מספרי טלפון וכו').
- העלאת מאפייני הפרטיות: כפי ש-Mozilla הציעה כאן, אנחנו רוצים להמשיך לחקור מנגנונים כדי להציע התחייבויות טובות יותר לפרטיות, כמו עיוורון של IdP ומזהים מכוונים.
- היחסים עם WebAuthn: כפי שהוצע על ידי Apple, אנחנו שמחים לראות את ההתקדמות במפתחות הגישה ולעבוד על יצירת חוויה עקבית ואחידה בין FedCM, הסיסמאות, WebAuthn ו-WebOTP.
- סטטוס התחברות: כפי ש-Apple הציעה עם Login Status API של Privacy CG, אנחנו משתפים את האינטואיציה שסטטוס ההתחברות של המשתמש הוא מידע שימושי שיכול לעזור לדפדפנים לקבל החלטות מושכלות, ואנחנו שמחים לראות את ההזדמנויות בעקבות כך.
- Enterprise ו-Education: כפי שברור ב-FedID CG, יש עדיין הרבה תרחישים לדוגמה שלא משרתים היטב את FedCM, ואנחנו רוצים לעבוד עליהם. למשל, התנתקות מהערוץ (היכולת של IdP לשלוח אות ל-RPs להתנתקות) ותמיכה ב-SAML.
- קשר עם mDL, VCs ואחרים: המשיכו להבין איך הם מתאימים ל-FedCM, למשל ל-Mobile Document Request API.
משאבים
- אפשר לנסות את ההדגמה של FedCM.
- אם יש לכם חשבון IdP ואתם רוצים להטמיע את FedCM, תוכלו לקרוא את המדריך למפתחים. אם אתם בעלי מוגבלויות (RP), כדאי לשאול את ה-IdP אם בכוונתו להטמיע את FedCM.
- בודקים את עדכוני ה-API של FedCM.
- אם יש לכם בקשות, בקשות או בקשות להוספת תכונות, או אם אתם נתקלים בבעיות, אפשר להגיש אותן מול המאגר הציבורי של FedCM ב-GitHub.