שתי קריאות שרת-לשרת וכתובת אחת.

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

תיעוד ה-API (באנגלית)כל דרכי החיבור ←

המטענים בעמודים האלה מראים את מבנה החוזה. השדות והכותרות המדויקים נקבעים מול כל לקוח.

התהליך כולו.

שלושה צעדים, ורק הראשון והשלישי נוגעים בשרת שלכם.

צעד 1

השרת שלכם פותח הפעלת אימות.

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

בקשה, מצד השרת

POST <session endpoint>
Authorization: Bearer <your client token>
Content-Type: application/json

{
  "assurance_level": "substantial",
  "age_gate_min":    18,
  "return_fields":   ["verified", "meets_age", "age_gate_min"],
  "redirect_url":    "https://your-app.example/verify/return",
  "webhook_url":     "https://your-app.example/hooks/jerix"
}

כל הפעלה היא לשימוש אחד, ותוקפה פג.

צעד 2

שולחים את האדם לכתובת שחזרה.

זו כל האינטגרציה בצד הלקוח: הפניה, או אותה כתובת שנפתחת בתוך web view. כל מה שבא אחריה: הצילום, קריאת הצ’יפ ב-NFC, אימות שרשרת האמון בלי רשת, התאמת הפנים לתמונה שהמדינה המנפיקה עצמה חתמה עליה, ומחיקת התמונות, קורה בצד שלנו.

תשובה, הכתובת האחת

201 Created

{
  "session_id":  "vs_8K31QD…",
  "url":         "https://<verification-host>/s/8K31QD…",
  "expires_in":  900
}

צעד אחד בצד הלקוח, ואין ספרייה שצריך לעדכן.

צעד 3

השרת שלכם מקבל את התשובה.

או שאנחנו שולחים אותה ל-webhook חתום, או שאתם קוראים אותה כשהאדם חוזר. בוחרים לפי השאלה אם השרת שלכם יכול לקבל בקשה נכנסת. אף פעם אל תיקחו את התשובה מהדפדפן: ההפניה אומרת לכם שהאדם חזר, לא מה קרה.

3א, קוראים בעצמכם

GET <session endpoint>/vs_8K31QD…
Authorization: Bearer <your client token>

200 OK

{
  "verified":     true,
  "meets_age":    true,
  "age_gate_min": 18
}

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

3ב, או מקבלים את ה-webhook החתום

POST /hooks/jerix            (to your endpoint)
<signature header>: <hex>
<timestamp header>: <unix seconds>

{
  "session_id":   "vs_8K31QD…",
  "verified":     true,
  "meets_age":    true,
  "age_gate_min": 18
}

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

Simulation, computed in this page, no network call is made

Decide how little your server receives.

Set the level you require and the fields you are willing to hold. Both plates recompute as you change them. Shapes are illustrative.

Assurance level you require
Fields returned to your server

1, your server creates the session

POST <session endpoint>
Authorization: Bearer <your client token>
Content-Type: application/json

{
  "assurance_level": "substantial",
  "age_gate_min":    18,
  "return_fields":   ["verified", "meets_age", "age_gate_min"],
  "redirect_url":    "https://your-app.example/verify/return",
  "webhook_url":     "https://your-app.example/hooks/jerix"
}

Because you asked for an age field, the request carries the gate. The gate is a number you choose, not a date of birth we hand back.

2, the result your server reads

200 OK

{
  "verified":     true,
  "meets_age":    true,
  "age_gate_min": 18
}

Illustrative shape. Everything you did not ask for is absent, no name, no national ID number, no date of birth, no image.

לקוח יכול לקבל שלושה שדות, ותו לא.

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

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

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

ושום דבר שתקבלו לא ניתן להצלבה.

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

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

איך הארכיטקטורה מגינה על המידע ←

כל סביבה, כל שפה.

הכתובת המתארחת עובדת עם כל צד שרת. ה-SDK הנייטיב מכניס את הצילום לתוך האפליקציה שלכם.

כל צד שרת שיודע לשלוח JSON

שתי קריאות HTTPS עם bearer token. בלי SDK לשרת, בלי ספריית לקוח, בלי שילוב בתהליך הבנייה, בלי גרסה לנעול. זה הנתיב שרץ היום בייצור.

אתר סטטי בלי צד שרת

מספיקות שתי פונקציות serverless קטנות: אחת פותחת את ההפעלה, ואחת מקבלת את התוצאה או את ה-webhook. הטוקן של הלקוח נשאר בתוך הפונקציה, המקום היחיד שבו הוא צריך להיות.

React Native ו-Flutter

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

iOS ו-Android

שתי האפליקציות הנייטיב מריצות את הצילום, את קריאת הצ’יפ ואת מניפסט הצילום החתום על המכשיר. ב-iOS הבקשה נושאת גם Apple App Attest.

תכנון לפי מסמך.

תעודת זהות ישראלית: אימות מבוסס צילום.

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

תראו את שתי הקריאות רצות מול הפעלה חיה.

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

לתיאום הדגמה