OpenID Connect विनिर्देश ISO मानक के रूप में प्रकाशित

 (self-issued.info)
1 पॉइंट द्वारा GN⁺ 2024-11-11 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • OpenID Connect के 9 विनिर्देश ISO/IEC मानकों के रूप में प्रकाशित किए गए हैं, जिससे Core 1.0, Discovery, Dynamic Client Registration, logout विनिर्देश, और OAuth 2.0 response mode भी अंतरराष्ट्रीय मानक ढांचे में शामिल हो गए हैं
  • OpenID Foundation ने दिसंबर 2023 में इन्हें PAS(Publicly Available Specifications) तरीके से ISO को जमा किया था, और उसके बाद ISO अनुमोदन मतदान के बाद प्रकाशन तक की प्रक्रिया पूरी हुई
  • ISO मानकीकरण के कारण उन न्यायक्षेत्रों में भी OpenID Connect deployment आसान हो सकता है, जहाँ अंतरराष्ट्रीय संधियों के तहत मान्यता प्राप्त मानकीकरण संस्थाओं के विनिर्देशों की आवश्यकता होती है
  • जमा करने से पहले OpenID Connect working group ने यह सुनिश्चित करने के लिए errata corrections लागू करने की प्रक्रिया चलाई कि ISO संस्करण में ज्ञात सुधार शामिल हों
  • OpenID Foundation इस PAS प्रक्रिया के अनुभव के आधार पर FAPI 1.0 और final होने के बाद eKYC-IDA तथा FAPI 2.0 विनिर्देश समूह को भी ISO प्रकाशन के लिए जमा करने की योजना बना रहा है

ISO/IEC मानक के रूप में प्रकाशित विनिर्देश

PAS जमा और ISO अनुमोदन

  • OpenID Foundation की ओर से OpenID Connect विनिर्देशों का जमा करना दिसंबर 2023 में PAS(Publicly Available Specifications) के रूप में हुआ
  • ISO अनुमोदन मतदान के बाद ये विनिर्देश ISO/IEC मानकों के रूप में प्रकाशित किए गए
  • ISO अंतरराष्ट्रीय संधियों के तहत मान्यता प्राप्त मानकीकरण संस्थाओं में से एक है, इसलिए उन न्यायक्षेत्रों में जहाँ ऐसी संस्थाओं के मानकों का उपयोग कानूनी रूप से आवश्यक है, OpenID Connect अपनाने की संभावना बढ़ सकती है

ISO संस्करण में शामिल सुधार

  • जमा करने से पहले OpenID Connect working group ने विनिर्देशों में errata corrections लागू करने की प्रक्रिया चलाई
  • इसके परिणामस्वरूप ISO संस्करण में ज्ञात सुधार प्रतिबिंबित किए गए

अगली ISO जमा योजना

  • OpenID Foundation एक बार ISO PAS जमा प्रक्रिया पूरी करने के बाद अतिरिक्त final विनिर्देश समूहों को भी ISO प्रकाशन के लिए जमा करने की योजना बना रहा है
  • अगले लक्ष्यों में FAPI 1.0 विनिर्देश शामिल है
  • eKYC-IDA और FAPI 2.0 विनिर्देश final होने के बाद जमा करने के लिए निर्धारित हैं

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2024-11-11
Hacker News की राय

  • करीब 17 साल पहले OpenID में काफ़ी गहराई से शामिल रहने के बावजूद(https://simonwillison.net/search/?tag=openid&year=2007), यह समझने में मुझे शर्मनाक रूप से बहुत समय लगा कि OpenID Connect का OpenID के मूल विचार—“identifier एक URL है और उस URL की ownership साबित की जाती है”—से लगभग कोई संबंध नहीं है
    OpenID Connect असल में OAuth के evolved रूप के ज़्यादा करीब है

    • भविष्य के अपने लिए नोट के तौर पर लिखूं तो, OpenID Connect(OIDC) मुख्य रूप से authentication से जुड़ा है, और OAuth, ज़्यादा सटीक कहें तो OAuth v2.0, authorization से जुड़ा है
      OpenID Connect को OAuth का evolution कहने के बजाय, vision और spirit के लिहाज़ से OpenID का evolution कहना ज़्यादा सही लगता है। OIDC, OpenID की तरह, user identification और authentication पर focus करता है, लेकिन OpenID के उलट इसने पूरी तरह नया authentication flow दोबारा नहीं बनाया; इसने OAuth spec के ऊपर, जिसका पहले से authentication के लिए misuse हो रहा था, authentication flow जोड़कर अपना मुख्य लक्ष्य हासिल किया
    • OAuth2 की composition शैली बहुत ज़्यादा flexible है, और OIDC उस “कैसे compose करें” के लिए कई अच्छी practices देता है
      इसलिए जिन systems का लक्ष्य OIDC compliance नहीं होता, वे भी अक्सर कुछ हद तक OIDC का पालन करते हैं। अगर OIDC standard का कोई हिस्सा पहले से आपकी ज़रूरत पूरी कर रहा है, तो पहिया दोबारा बनाने की ज़रूरत नहीं
    • naming पूरी तरह nightmare है
      OpenID Connect, OAuth2(RFC 6749) में authentication layer जोड़ने वाला extension है, और OAuth2 permissions देने वाला authorization framework है
      दूसरी ओर OAuth 1.0/1.0a और OpenID 1/2 नाम में बस मिलते-जुलते हैं; वे आपस में असंबंधित और incompatible protocols हैं, इसलिए 2024 के हिसाब से ज़्यादातर अप्रासंगिक हैं। search करते समय सावधान रहें
    • मेरी समझ में OpenID Connect, OAuth2 के ऊपर बनी specialization के ज़्यादा करीब है
    • 2008 में Webstock में हुई एक presentation की वजह से पहली बार OpenID में मेरी दिलचस्पी जगी थी

  • यह किसी भी मायने में अच्छी बात नहीं है। सबसे पहले, पैसे देकर ही देखे जा सकने वाले paid standards सचमुच खराब हैं
    दूसरी बात, ऐसे standards और implementations design करने में और मेहनत लगनी चाहिए जो ज़रूरत पड़ने पर अंतहीन समय-खपत न बन जाएं

    • ISO के बारे में सहमत हूं, लेकिन इस मामले में कोई सार्थक toll barrier दिखना मुश्किल है। standard खुद पहले से मुफ्त में public है, और यह कदम ISO के standardization namespace में एक identifier assign करने जैसा लगता है
      हालांकि ISO standard number पाने का, internet पर HTML document डालने की तुलना में, क्या फायदा है यह मुझे ठीक से नहीं पता
    • internet side में मुझे हैरानी है कि ऐसी चीज़ को RFC क्यों नहीं बनाया जाता। email और TCP भी RFC हैं, बाकी core elements भी, और global companies भी उन्हें हमेशा इस्तेमाल करती हैं

  • standards अच्छे हैं, लेकिन ISO जैसे बड़े standardization organizations का standards देखने के लिए पैसे लेना irritate करता है
    शायद इसलिए कि कुछ companies या industries को IETF या गंदे open-source hippie groups की बनाई चीज़ों की बजाय ऐसे organizations के “real” standards चाहिए होते हैं

    • उनका दावा है कि यह कम विकसित क्षेत्रों में accessibility और funding उपलब्ध कराने के लिए है
    • “standard” और “पैसा लगता है” एक-दूसरे से टकराते हुए लगते हैं। अगर आप चाहते हैं कि कोई तरीका standard, यानी सबसे आम तरीका बने, तो उसे इतना accessible होना चाहिए कि वह व्यापक रूप से implement हो सके
    • ज़्यादातर standards की कीमत कम होती है, इस हद तक कि वे घाटे में बिकते हैं। इसके बजाय अगर आप ISO या IEEE को donation देना चाहें, तो standard लिखने की लागत घटाने में मदद मिलेगी
    • governments या national context में, क्योंकि ISO को कई international treaties में मान्यता मिली हुई है, मेरी समझ में OpenID Foundation standard की बजाय ISO standard इस्तेमाल करने की approval लेना कई बार आसान होता है
      इसलिए OpenID Connect अगर ISO number के साथ publish होता है, तो कुछ projects में adoption आसान हो जाता है। बेशक OpenID Connect खुद आगे भी मुफ्त में पढ़ने और इस्तेमाल करने के लिए उपलब्ध रहेगा, लेकिन ऊपर जैसी स्थिति वाले लोगों को एक आसान विकल्प मिल जाता है

  • ISO non-free कचरा है और software ecosystem की मदद नहीं करता
    ISO 8601 को देखें तो यह ज़रूरत से ज़्यादा जटिल है, maintainers अक्सर मुफ्त drafts इस्तेमाल करने के कारण इसे सही से implement नहीं करते, और असल में यह कुछ भी ठीक से solve नहीं करता। उदाहरण के लिए, यह wall-clock time express नहीं कर सकता, इसलिए भविष्य की उन dates में समस्या आती है जिनमें timezone बदल सकता है
    पहले mp4 के साथ भी काम किया था, और पता चला कि Apple stack में बदलाव हैं, इसलिए सिर्फ ISO काफ़ी नहीं है

    • खास शिकायत समझ में आती है, लेकिन wall-clock time को express न करना मुझे उल्टा feature लगता है
      आलोचना आम तौर पर daylight saving time changes जैसी assumptions की ओर चली जाती है। “मैं 4 साल बाद Absurdistan के local time 14:00 को specify करना चाहता हूं, UTC से उसका रिश्ता जो भी हो, लेकिन नहीं कर सकता” जैसी आलोचना आम है। लेकिन assumption को थोड़ा और आगे बढ़ाएं तो Absurdistan कोई overseas territory जोड़ सकता है, किसी alliance में शामिल हो सकता है, या timezone और daylight saving time बदल सकता है
      समस्या पर सोचें तो local time की definition खुद बदल सकती है, इसलिए जब तक सभी संभावित बदलावों को पूरी तरह define न किया जाए, future local time specify करना असंभव है। अंत में या तो future की atomic clock tick count (TAI) तय करनी होगी और इस्तेमाल के समय उसे local time के रूप में interpret करना होगा, या कोई fixed time specify करके इस्तेमाल के समय उसे local time के रूप में interpret करना होगा
    • जानना चाहूंगा कि ISO 8601 का कोई alternative है या नहीं। मेरी शिकायत बस इतनी थी कि कुछ चीज़ों को express करने के एक से ज़्यादा तरीके दिखते हैं, और wall-clock time वाली समस्या के बारे में मुझे पता नहीं था
      यह भी curious हूं कि नया JS Temporal API इसे handle करता है या नहीं। लगता है वह काफ़ी गहराई तक गया है

  • ISO जैसे pay-to-read standards मानव प्रगति को सक्रिय रूप से रोकते हैं। ऐसी चीज़ों को encourage नहीं किया जाना चाहिए

    • C++ के मामले में latest standard drafts मुफ्त में public हैं https://en.cppreference.com/w/cpp/links#C.2B.2B_standard_doc...
      मेरी समझ में final draft और official standard में practical content के लिहाज़ से बहुत कम फर्क होता है। OIDC standard draft भी कहीं न कहीं public होगा
    • हर चीज़ black-and-white होना ज़रूरी नहीं। grey area होने की बात मान लेना भी ठीक है
      यह कहना अजीब है कि वे engineers मानव प्रगति बना भी रहे हैं और साथ ही मानव प्रगति को सक्रिय रूप से नुकसान भी पहुंचा रहे हैं

  • identity provisioning एक ऐसा राक्षस है जिसका आविष्कार ही नहीं होना चाहिए था
    2000 के दशक के मध्य में मैं इतना fan था कि अपना OpenID server खुद चलाता था, लेकिन मुझे पता नहीं था कि यह पूरा concept मूल रूप से कितना flawed है
    identity किसी व्यक्ति में निहित, non-transferable attribute है; यह ऐसी चीज़ नहीं है जिसे कोई दूसरा व्यक्ति, company/website, government आदि “provide” कर सके। वे ज़्यादा से ज़्यादा passport जारी करने की तरह credentials देकर उसे prove कर सकते हैं
    कम से कम WebAuthn ने इस हिस्से को सही पकड़ा

    • क्या इसमें यह assumption नहीं है कि provide की गई identity ठीक आप ही हैं और सिर्फ आप ही? मैं इन identities को किसी identity provider के ऊपर बने pseudonym की तरह देखता और इस्तेमाल करता आया हूँ
      किसी identity को अगर पर्याप्त जगहों पर इस्तेमाल किया गया हो तो कुछ entities के लिए यह deny करना मुश्किल होगा कि वह मेरी है, लेकिन उस स्थिति में भी जिन entities ने उस identity को देखा है, उनमें से केवल एक छोटा subset ही prove कर सकता है कि वह मैं हूँ
    • सोच रहा हूँ कि proof और provisioning के distinction के कोई practical परिणाम हैं, या यह purely philosophical distinction है

  • Google, MS, Apple के बाहर account बनाने के लिए क्या कोई independent OIDC issuer अभी भी बचा है?
    कुछ समय पहले मैं GitHub account इस्तेमाल किए बिना Tailscale account बनाना चाहता था, लेकिन कर नहीं पाया
    पहले openid.net और Ubuntu One ऐसी service देते थे, ऐसा लगता है, लेकिन मेरी जानकारी में वे बंद हो चुके हैं

    • अभी भी कुछ जगहें बची हैं, और https://gitlab.com वह है जिसे मैं अक्सर इस्तेमाल करता हूँ
      हालांकि ऐसी service के लिए जरूरी security और support cost काफी बड़ी होती है, इसलिए खासकर free में देना छोटी organizations के लिए practical नहीं है। इसे संभव बनाने वाली economies of scale बड़ी हैं, और जब enterprise products के लिए बड़ी companies पैसा देती हैं तो यह खास तौर पर अच्छी तरह fit बैठता है

  • OpenID Connect काफी simple protocol है। spec(https://openid.net/specs/openid-connect-core-1_0.html) पढ़कर मैं लगभग एक दिन में इसका ज्यादातर हिस्सा समझ गया था
    जो लोग spec नहीं पढ़ना चाहते, उनके लिए मैंने simple HTTP requests से OpenID client implement करने का एक comprehensive tutorial भी लिखा है(https://spapas.github.io/2023/11/29/openid-connect-tutorial/)
    examples Python इस्तेमाल करते हैं, लेकिन इसे अपनी पसंद की language में implement करना मुश्किल नहीं होना चाहिए। complexity का ज्यादातर हिस्सा JWT tokens को decode और verify करने में है
    इस हाथ से लिखे client को मैं लगभग 1 साल से real production project में Keycloak authentication के लिए इस्तेमाल कर रहा हूँ, और सब कुछ बिल्कुल सही चल रहा है
    P.S.: मुझे पता है कि मेरी site पर ads बहुत ज्यादा हैं। अफसोस, Google Ads को ठीक से set up करने का समय नहीं मिला और बेहतर alternative भी नहीं मिला। पढ़ते समय ad blocker इस्तेमाल कर सकते हैं

    • लेख बहुत interesting और अच्छी तरह लिखा गया है
      हालांकि simple जैसे subjective शब्दों के साथ सावधान रहना बेहतर है। अगर reader को चीज़ मुश्किल लग रही हो और लेखक उसे simple कहे, तो वह काफी हतोत्साहित महसूस कर सकता है
    • बेहतरीन tutorial है
      फिर भी OIDC आसान है, इस बात पर मुझे अभी भी पूरा भरोसा नहीं है। Keycloak बहुत भारी complexity छिपाता है, और developers ने उसे यूँ ही मज़े के लिए ऐसा नहीं बनाया। उदाहरण के लिए SSO timeout, client timeout, अलग-अलग token timeouts आदि जैसी बहुत सारी timeout settings होती हैं

  • ISO standards के इर्द-गिर्द monetization और organization operations कुल मिलाकर बहुत suspicious लगते हैं
    एक कम-जानी-पहचानी trick के तौर पर, friendly Estonian site https://evs.ee पर standards के सस्ते versions खोजे जा सकते हैं। वे अक्सर अपने खुद के versions बनाते हैं जिनमें original जैसा ही लगभग वही content होता है। अफसोस, इस मामले में वे actual standard को लगभग उसी कीमत पर ही offer करते दिखते हैं https://www.evs.ee/en/search?OnlySuggestedProducts=false&que...
    बाद में बेहतर price वाला उनका अपना version आता है या नहीं, इसके लिए site पर नज़र रखना worth it है। आम तौर पर price original का करीब 10% होता है। Estonia के बढ़िया काम करने का यह एक और data point है
    medical device compliance का काम करते हुए मेरा सामना अक्सर काफी suspicious standardization organizations से होता है https://openregulatory.com/accessing-standards/
    “standardization में पैसा लगता है”, “ये organizations अच्छा काम करती हैं” जैसी common arguments मैंने सब सुनी हैं, लेकिन मैं बिल्कुल सहमत नहीं हूँ। अगर कोई चीज़ standard है, तो वह कानून जैसी हो जाती है। लोगों को उसका पालन कर पाना चाहिए, और इसके लिए उस तक freely access होना चाहिए। EU Advocate General भी सहमत लगते हैं https://openregulatory.com/maybe-eu-standards-are-becoming-f...
    ऐसी बहुत सारी standardization है जिसके लिए PDFs को suspicious तरीके से पैसे लेकर बेचना जरूरी नहीं है। ECMAScript और ANSI C याद आते हैं, और ऐसे उदाहरण और भी हैं

  • ISO publication बना देने से procurement departments के लिए यह responsibility से बचने की shield बन जाता है
    आखिर ISO standards के bundle का compliance मांगने की वजह से किसी को नौकरी से तो नहीं निकाला गया