‫Digital Credentials API: זהות מאובטחת ופרטית באינטרנט

Natalia Markoborodova

José Luis Zapata

פורסם: 3 באוקטובר 2025

אנחנו שמחים להודיע ש-Digital Credentials API מופעל עכשיו כברירת מחדל החל מ-Chrome 141. בנוסף, ב-iOS 26 נוספה תמיכה ב-Digital Credentials API ב-Chrome ובדפדפנים אחרים. ה-API הזה מספק רמת אבטחה ופרטיות חדשה לאימות זהויות באינטרנט, ומאפשר לאתרים לבקש ולקבל מידע שניתן לאימות מהמשתמשים בדרך סטנדרטית.

אחרי תקופת ניסיון של מקור מוצלחת, ה-API של אישורים דיגיטליים תומך עכשיו בהצגת אישורים באותו מכשיר ב-Android ובהצגת אישורים במכשירים שונים ב-Chrome במחשב.

רקע

עד עכשיו, אימות הזהות באינטרנט היה תהליך מורכב, שלרוב דרש מהמשתמשים להעלות סריקות של תעודות הזהות שלהם. המשמעות של השיטה הזו היא לרוב שיתוף של יותר נתונים מהנדרש, מה שיוצר חששות משמעותיים לגבי הפרטיות של המשתמשים. גם מפתחים חשופים לסיכון, כי הם צריכים לוודא שהפתרון שלהם מסוגל לעבד ולאחסן נתונים רגישים, שלרוב הם לא אחידים, בצורה מאובטחת וששומרת על הפרטיות.

במקביל, תקנות כמו eIDAS 2.0 מחייבות את הממשלות לספק לציבור אמצעי זיהוי דיגיטליים. ארנקים דיגיטליים כאלה צריכים לאפשר אחסון של פרטי כניסה שונים, כולל הוכחת זהות וגיל. ספקי שירותים אונליין יכולים לבקש את האישורים האלה כדי לאמת את זהות המשתמש.

קהילת תקני האינטרנט ב-W3C מודעת לפוטנציאל של אישורים דיגיטליים לענות על דרישות המשתמשים לפרטיות ועל הצורך של המפתחים לאמת את נתוני המשתמשים, ולכן פיתחה פתרון: Digital Credentials API. מטרת Digital Credentials API היא לפתור את הבעיה באמצעות ממשק מובנה לאימות מידע על משתמשים, וכך לשפר את האבטחה, הפרטיות וחוויית המשתמש בהשוואה לחלופות. בעזרת ה-API הזה, המשתמשים לא צריכים יותר להעלות מסמכים רגישים כמו סריקות של תעודות זהות לכמה אתרים. במקום זאת, אתרים יכולים לבנות אמון עם המשתמשים שלהם על ידי בקשה רק של נתונים ספציפיים וחתומים קריפטוגרפית שהם צריכים מנפיקים מהימנים.

תכונות עיקריות

ה-API של פרטי כניסה דיגיטליים מבוסס על שלושה עקרונות מרכזיים: פרטיות, תמיכה בפלטפורמות שונות ותקנון.

פרטיות

‫Digital Credentials API משפר את הפרטיות והאבטחה אונליין. המשתמשים יכולים להציג תעודה דיגיטלית מהארנקים הדיגיטליים שלהם לאתרים כדי לאמת עובדות ספציפיות בלי לחשוף את הנתונים הרגישים שמאחורי העובדות האלה. לדוגמה, ה-API יכול לאמת שמשתמש הוא מעל גיל 18 בלי לחשוף את תאריך הלידה המלא שלו. העיקרון הזה של 'חשיפה סלקטיבית' מבטיח שאתרים יקבלו רק את המידע המינימלי הדרוש.

ממשק Digital Credentials API תואם גם לפרוטוקולים של הוכחות אפס ידע (ZKP), כמו Longfellow ZK של Google, שמבטיח את פרטיות המשתמשים על ידי החזרת הוכחה קריפטוגרפית לכך שטענת זהות מסוימת נכונה, בלי לחשוף מידע אחר.

תמיכה בפלטפורמות שונות

מטרת Digital Credentials API היא לתמוך בפלטפורמות שונות, כדי שהמשתמשים יוכלו להציג בקלות מידע מאומת במכשירים שונים.

ב-Android: מספק ממשק משתמש מובנה שמאפשר למשתמשים לבחור פרטי כניסה מאפליקציית הארנק המותקנת שלהם.

במחשב: משתמשים יכולים להציג פרטי כניסה מהארנק הדיגיטלי בנייד באתר בדפדפן במחשב. כשסורקים קוד QR, המערכת יוצרת חיבור מאובטח ומוצפן מקצה לקצה בין המחשב לנייד, שמוגן מפני פישינג. החיבור הזה משתמש בפרוטוקול CTAP כדי לאמת את הקרבה של המשתמש באמצעות BLE, וכך לוודא שהוא נמצא פיזית בשני המכשירים ושולט בהם.

תקנון

יכולת פעולה הדדית היא גורם מרכזי. ב-Chrome, ‏ Digital Credentials API הוא פרוטוקול בלתי תלוי בפלטפורמה ותואם לפרוטוקולים שונים של הצגה, למשל, OpenID4VP ו-Annex C of ISO 18013-7. בנוסף, אפל הציגה תמיכה ב-Digital Credentials API החל מ-Safari 26.0.

בנוסף, Digital Credentials API מבוסס על התמיכה המובנית בניהול פרטי כניסה ב-Android ועל מערכת אקולוגית גדלה של ארנקים תואמים. ‫Google Wallet היא אפליקציה שמאמצת טכנולוגיות חדשות, ותוכלו בקרוב להשתמש בה עם Samsung Wallet ו-1Password.

מה חדש מאז גרסת המקור לניסיון?

אם השתתפתם בגרסת המקור לניסיון הקודמת שלנו, תשימו לב שממשק Digital Credentials API עבר מ-navigator.identity.get() ל-navigator.credentials.get(), כדי להתאים אותו למאמץ הרחב יותר לאיחוד הזהויות באמצעות Credential Management API. בנוסף, שם הפרמטר providers שונה ל-requests, ושם הפרמטר request שונה ל-data.

הטמעה

שילוב של Digital Credentials API כולל שני שלבים עיקריים: זיהוי תכונות ושליחת בקשה לקבלת פרטי הכניסה. המפתחים צריכים גם להטמיע לוגיקה מותאמת אישית כדי לקבוע אם האפליקציה שלהם יכולה להשתמש בפרטי הכניסה.

זיהוי תכונות

לפני שמציגים את הלחצן 'אימות באמצעות פרטי כניסה דיגיטליים', צריך לבדוק אם Digital Credentials API זמין בדפדפן של המשתמש.

if (typeof DigitalCredential !== "undefined") {
  // Digital Credentials API is supported
} else {
  // Digital Credentials API is not supported
}

בקשת פרטי כניסה

בקשה לקבלת פרטי כניסה כוללת קריאה ל-navigator.credentials.get() עם הפרמטר digital. בתוך סוג האישורים הדיגיטליים, מוסיפים מערך requests שמכיל DigitalCredentialGetRequest עם הפרמטרים הבסיסיים הבאים:

• ‫protocol: מציינים פרוטוקול חילופי באמצעות מחרוזת. לדוגמה,"openid4vp" או "org-iso-mdoc". כדי לזהות אם הדפדפן תומך בפרוטוקול:

  if (DigitalCredential.userAgentAllowsProtocol("example-protocol")) {
      // Create a request with this protocol
    } else {
      // Protocol is not supported
  }
  

• ‫data: אובייקט עם הפרמטרים שאפליקציות של ארנקים דיגיטליים מקבלות עבור הפרוטוקול שצוין. ב-"openid4vp", הפרמטרים מוגדרים ב-OpenID for Verifiable Presentation (OID4VP) עבור מפרט W3C Digital Credentials API.

  try {
    const digitalCredential = await navigator.credentials.get({
      digital: {
        requests: [{
          protocol: "openid4vp-v1-unsigned",
          data: {
            response_type: "vp_token",
        nonce: "[some-nonce]",
            client_metadata: {...},
        dcql_query: {...}
          }
      }]
      }
    });
  
    // Decrypt payload respons and verify credentials on the backend
    const response = await fetch("/verify", {
      method: "POST",
        body: JSON.stringify(digitalCredential.data),
        headers: {
            'Content-Type': 'application/json'
        }
    });
  } catch (e) {
    // Handle errors, such as the user canceling the request
    console.error(e);
  }
  

לדוגמה, כדי לבקש את שם המשפחה, השם הפרטי וערך בוליאני שמציין אם המשתמש מעל גיל 21, אפשר לציין את מטען הייעודי (payload) הבא:

{
  protocol: 'openid4vp-v1-unsigned',
  data: {
    response_type: 'vp_token',
    nonce: '[some-nonce]',
    // Contains the Verifier metadata values, including supported credential formats and response encryption public key
    client_metadata: {
  // Supported credential formats. Refer to the documentation for specific values
        vp_formats_supported: {...},
   // Public key(s). Refer to the documentation for more detail.
        jwks: {...}
    },
    dcql_query: {
      // A wallet will try to find credentials it holds that match these definitions.
      credentials: [
        {
          // A locally unique identifier for this credential definition within the query.
          id: "cred_vc",
          format: "dc+sd-jwt",
          meta: {
            // 'vct_values' specifies the Verifiable Credential allowed type.
            // In this case, it's a European Digital Identity (EUDI) Personal Identification Data (PID) credential.
            vct_values: [
              "urn:eudi:pid:1"
            ]
          },
          // 'claims' is an array of specific data that's being requested.
          claims: [
            {
              // The path ["age_equal_or_over", "18"] corresponds to accessing `credential.age_equal_or_over['18']`.
              path: [
                "age_equal_or_over",
                "18"
              ]
            }
          ]
        }
      ]
    }
  }
}

בדוגמה הזו, התג client_metadata צריך לציין רשימה של פורמטים נתמכים. כדי לראות באילו ערכים אפשר להשתמש, צריך לעיין במפרט. הערך האופציונלי jwks שמוגדר ב-client_metadata צריך להכיל מפתחות ציבוריים שמשמשים להצפנת התשובה. אפשר גם לעיין בקוד ההדגמה כדי לראות עוד דוגמאות.

דוגמה למטען ייעודי (payload) של תגובה מוצפנת של אובייקט DigitalCredential:

{
    // This is an example for a response using an OpenID4VP protocol.
    // The format of the 'data' object will differ for other protocols.
    "protocol": "openid4vp-v1-unsigned",
    "data": {
        // To decrypt this JWE payload, use the private key.
   // The decrypted payload will be a JSON object containing the
       // Verifiable Presentation in the 'vp_token' claim.
        "response": "[jwe-token]"
    }
}

בדוגמה הזו, המערכת מבקשת את פרטי הכניסה באמצעות הפרוטוקול openid4vp-v1-unsigned והתשובה מכילה את הערך response במאפיין data.

הדרך המדויקת לנתח את התגובה תלויה בפרוטוקול. בדרך כלל צריך:

1. מפענחים את מטען הנתונים של התגובה. שיטת הפענוח תלויה בפרוטוקול שבו נעשה שימוש. במאמרים הבאים מוסבר איך לפענח את מטען הייעודי (payload) של openid4vp (באמצעות JWE) ושל org-iso-mdoc (באמצעות הצפנה היברידית של מפתח ציבורי).
2. אימות החתימות והגורם המנפיק. פרטים נוספים זמינים במאמר בנושא אישור אונליין של מסמכים דיגיטליים.

כדי לראות דוגמאות קוד לפרוטוקולים שונים, אפשר לעיין בקוד של ההדגמה או בגרסה הפעילה שמתארחת בשרת.

אימות המהימנות של המנפיק

החתימה הקריפטוגרפית של פרטי הכניסה הדיגיטליים מוכיחה שפרטי הכניסה אותנטיים. עם זאת, המפתחים צריכים לוודא שהגורם המנפיק מתאים ומהימן לתרחיש השימוש הספציפי שלהם. לדוגמה, כדי להעניק הנחה לסטודנטים באוניברסיטה, אתר מסחר אלקטרוני יצטרך אישור שהונפק על ידי אוניברסיטה מוכרת, וידחה אישור שנחתם על ידי ישויות אחרות. דרך נפוצה לאימות האמון במונפק היא לנהל רשימה של מנפיקים מאושרים ולדחות כל מנפיק שלא תואם.

שנתחיל?

מוכנים להתחיל לבנות? הנה מה שחשוב לדעת.

• זמינות: ב-Chrome 141 ואילך, ה-API של אישורים דיגיטליים מופעל כברירת מחדל בפלטפורמות שונות.
• דרישות מוקדמות: המשתמשים צריכים מכשיר תואם, למשל מכשיר Android עם Google Play Services בגרסה 24.0 ואילך, או מכשיר iOS עם גרסה 26 ואילך. במכשיר צריכה להיות מותקנת אפליקציית ארנק דיגיטלי שתומכת ב-Digital Credentials API, למשל Google Wallet או ארנק הדגמה.
• כדאי לנסות את ההדגמה: הדרך הכי טובה להבין את חוויית המשתמש ולבדוק את ההטמעה היא לנסות את ההדגמה הפעילה בכתובת https://verifier.multipaz.org באמצעות Chrome 141 ואילך.

משאבים

מידע נוסף זמין במשאבים הבאים:

• מדריך למפתחים: Digital Credentials API
• מפרט: W3C Digital Credentials
• תמיכה ב-Android: תמיכה ב-Android באישורים דיגיטליים

שיתוף משוב

עכשיו, אחרי שהשקנו את Digital Credentials API, נשמח לשמוע על חוויית השימוש שלך בו. שליחת משוב כדי לשתף משוב או לדווח על באגים.