W3C ने वेबऑथ्न स्तर 3 उम्मीदवार सिफारिश प्रकाशित की

क्या हुआ

13 जनवरी 2026 को W3C ने वेब ऑथेंटिकेशन (WebAuthn) स्तर 3 का एक उम्मीदवार सिफारिश स्नैपशॉट प्रकाशित किया। यह अपडेट मल्टी-डिवाइस पासकी व्यवहारों को समेकित करता है, कई नए क्लाइंट APIs और सीरियलाइजेशन हेल्पर्स जोड़ता है, प्रमाणन/संबंधित-उत्पत्ति प्रबंधन को कड़ा करता है, और iframe और अनुमतियों की नीति इंटरैक्शन को स्पष्ट करता है। यह दस्तावेज़ अब उम्मीदवार सिफारिश चरण में है जबकि कार्यान्वयनकर्ता अंतिम स्वीकृति के लिए परीक्षण डेटा इकट्ठा कर रहे हैं। (w3.org)

यह पूर्ण-स्टैक टीमों के लिए क्यों महत्वपूर्ण है

• पासकी और मल्टी-डिवाइस क्रेडेंशियल अब केवल विक्रेता एक्सटेंशन नहीं हैं - स्तर 3 उन APIs और विकल्पों को औपचारिक बनाता है जो समन्वयित पासकी और मल्टी-डिवाइस पंजीकरण को पहले श्रेणी के व्यवहार बनाते हैं।
• नए क्लाइंट तरीके (उदाहरण के लिए, getClientCapabilities(), JSON डीसिरियलाइजेशन हेल्पर्स जैसे parseCreationOptionsFromJSON/parseRequestOptionsFromJSON(), और क्रेडेंशियल सिग्नल तरीके) ऐप्स को समर्थन का पता लगाने, विकल्पों को सीरियलाइज करने, और प्रमाणीकरण संकेतों का जवाब देने के तरीके को बदलते हैं - जिसका सीधा प्रभाव सर्वर↔क्लाइंट पेलोड प्रारूपों और SDKs पर पड़ता है।
• प्रमाणन और संबंधित-उत्पत्ति नियमों के लिए स्पष्ट मार्गदर्शन है; जो पक्ष प्रमाणन स्वीकार करते हैं उन्हें अद्यतन प्रमाणन प्रारूपों और प्रमाणपत्र नियमों की पुष्टि करनी चाहिए जो विनिर्देश में वर्णित हैं।
• अनुमतियों की नीति, iframe उपयोग, और क्रॉस-उत्पत्ति संबंधित-उत्पत्ति सत्यापन को स्पष्ट रूप से संबोधित किया गया है - यह उन टीमों के लिए महत्वपूर्ण है जो फ़्रेम में प्रमाणीकरण प्रवाह को एम्बेड कर रही हैं, या प्रतिनिधि लॉगिन या SSO के लिए क्रॉस-उत्पत्ति लॉगिन प्रवाह का उपयोग कर रही हैं।
• विनिर्देश की उम्मीदवार सिफारिश स्थिति का मतलब है कि W3C अंतिमकरण से पहले कार्यान्वयन परीक्षण की अपेक्षा करता है; ब्राउज़र और प्लेटफ़ॉर्म विक्रेता इस स्नैपशॉट का उपयोग फीचर समर्थन या फ्लैग जोड़ने के लिए करेंगे।

मुख्य व्यावहारिक परिवर्तन (उच्च-प्रभाव)

• क्लाइंट क्षमता पहचान: पंजीकरण/प्रमाणीकरण प्रवाह शुरू करने से पहले प्रमाणीकरणकर्ता क्षमताओं को पूछने के लिए एक मानकीकृत API (विशेषता पहचान ह्यूरिस्टिक्स को कम करता है)।
• JSON (डी)सीरियलाइजर्स: विनिर्देश स्तर के parse* हेल्पर्स जो यह सामान्य करते हैं कि सर्वर को WebAuthn विकल्प कैसे भेजने और प्राप्त करने चाहिए (सर्वर लाइब्रेरी और ब्राउज़र कार्यान्वयन के बीच अंतःक्रियाशीलता के अंतर को कम करता है)।
• सिग्नल तरीके: पृष्ठों के लिए प्रमाणीकरणकर्ताओं को संदर्भ जानकारी भेजने के नए तरीके (जैसे, वर्तमान उपयोगकर्ता विवरण, क्रेडेंशियल सूचियाँ) जो मौन/खोज प्रवाह को सुधारते हैं और उपयोगकर्ता के अनुभव को कम करते हैं।
• प्रमाणन स्पष्टताएँ: पैक्ड/TPM/Android प्रमाणन प्रारूपों और प्रमाणपत्र सत्यापन के लिए अद्यतन नियम जो सर्वर सत्यापनकर्ताओं को लागू करने चाहिए ताकि वे अनुपालन और सुरक्षित रह सकें।
• iframe / संबंधित उत्पत्ति: iframe के अंदर और संबंधित उत्पत्तियों के बीच WebAuthn का उपयोग करने के लिए स्पष्ट प्रबंधन और सत्यापन पैटर्न (एम्बेडेड विजेट, SSO प्रवाह, और मल्टी-टेनेंट सेटअप के लिए महत्वपूर्ण)।
• अनुमतियों की नीति एकीकरण: यह पंजीकरण पृष्ठों को WebAuthn संचालन से ऑप्ट-इन/ऑप्ट-आउट करने के लिए नीति हेडर के माध्यम से पंजीकृत करता है।

इंजीनियरिंग टीमों के लिए तात्कालिक क्रियाएँ

1. उम्मीदवार सिफारिश स्नैपशॉट पढ़ें और अपने स्टैक (सर्वर लाइब्रेरी, क्लाइंट कोड, तृतीय-पक्ष SDKs) के लिए डिफ़्स को मैप करें। (w3.org)
2. सर्वर सत्यापन लाइब्रेरी का ऑडिट करें (fido2 / webauthn लाइब्रेरी): सुनिश्चित करें कि वे स्तर-3 प्रमाणन प्रारूपों और प्रमाणपत्र प्रतिबंधों को स्वीकार करते हैं या जब विक्रेता पैच आते हैं तो अपग्रेड करने की तैयारी करें। परीक्षण वेक्टर कवरेज आवश्यक है।
3. JSON अंतःक्रियाशीलता को मानकीकृत करें: अपने API अनुबंधों में निर्माण/अनुरोध विकल्पों के लिए विनिर्देश की अनुशंसित सीरियलाइजेशन को अपनाएँ ताकि क्रॉस-ब्राउज़र असंगतताओं से बचा जा सके।
4. क्षमता जांचें: उपयुक्त UX (रेजिडेंट कीज़, खोज योग्य क्रेडेंशियल, समन्वयित पासकी) प्रस्तुत करने के लिए getClientCapabilities() (या सहज विशेषता पहचान) का उपयोग करें।
5. iframe और अनुमतियों की नीति के उपयोग की समीक्षा करें: यदि आपका उत्पाद प्रमाणीकरण प्रवाह को एम्बेड करता है, तो अनुमत व्यवहार की पुष्टि करें और आधुनिक ब्राउज़रों में संबंधित-उत्पत्ति सत्यापन प्रवाह का परीक्षण करें।
6. कैनरी/प्रायोगिक ब्राउज़रों पर परीक्षण करें: चूंकि यह एक उम्मीदवार सिफारिश है, प्रारंभिक ब्राउज़र समर्थन फ्लैग के पीछे दिखाई दे सकता है - उन निर्माणों के खिलाफ एकीकरण परीक्षण चलाएँ ताकि अंतःक्रियाशीलता के अंतर को पकड़ सकें।
7. उत्पाद और सुरक्षा का समन्वय करें: समन्वयित पासकी के लिए खतरे के मॉडल और रोलआउट योजनाओं को अद्यतन करें (विभिन्न खाता पुनर्प्राप्ति और फ़िशिंग विचार)।

सिफारिश की गई रोलआउट योजना (संक्षिप्त)

• सप्ताह 0–2: WebAuthn उपयोग का इन्वेंटरी (एंडपॉइंट, SDKs, iframe/एंबेडेड प्रवाह), वर्तमान व्यवहार के लिए स्वचालित परीक्षण जोड़ें।
• सप्ताह 2–6: ब्राउज़र निर्माणों के खिलाफ एकीकरण परीक्षण चलाएँ जो स्तर-3 सुविधाओं को उजागर करते हैं; सर्वर लाइब्रेरी को अपडेट करें या विक्रेता सुधारों को पिन करें।
• सप्ताह 6–12: क्लाइंट क्षमता-चालित UX के लिए नियंत्रित रोलआउट (फीचर फ्लैग) का चरण; त्रुटियों और प्रमाणन सत्यापन लॉग की निगरानी करें।
• निरंतर: W3C परीक्षण अपडेट और ब्राउज़र रिलीज़ नोट्स की सदस्यता लें - विनिर्देश अंतिमकरण से पहले कार्यान्वयन परीक्षण की अपेक्षा करता है (दस्तावेज़ कार्यान्वयन अनुभव के बाद सिफारिश की ओर प्रगति को नोट करता है)। (w3.org)

निचोड़

WebAuthn स्तर 3 महत्वपूर्ण पासकी, प्रमाणन, और एम्बेडिंग व्यवहारों को अनियोजित कार्यान्वयनों से एक औपचारिक विनिर्देश में स्थानांतरित करता है। पूर्ण-स्टैक टीमों को इस स्नैपशॉट को प्रमाणीकरण कोडपाथ का ऑडिट करने, सीरियलाइजेशन और प्रमाणन सत्यापन को विनिर्देश के साथ संरेखित करने, और ब्राउज़र पूर्वावलोकन निर्माणों के साथ एकीकरण परीक्षण शुरू करने के लिए एक ट्रिगर के रूप में मानना चाहिए - लेकिन केवल तभी फीचर रोलआउट की योजना बनाएं जब विक्रेता लाइब्रेरी और कम से कम एक या दो ब्राउज़र स्थिर समर्थन प्राप्त करें।

स्रोत

वेब ऑथेंटिकेशन: सार्वजनिक कुंजी क्रेडेंशियल्स तक पहुँचने के लिए एक API — स्तर 3 (W3C उम्मीदवार सिफारिश स्नैपशॉट, 13 जनवरी 2026)। (w3.org)

स्रोत

• Source