DID के बारे में बहुत ज़्यादा बातें

 (steveklabnik.com)
1 पॉइंट द्वारा GN⁺ 5 시간 전 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Bluesky अकाउंट किसी एक खास ऐप से बंधा नहीं है और atproto आधारित कई ऐप्स में इस्तेमाल किया जा सकता है, तथा DID (decentralized identifier) ऐप से अलग एक पहचान सत्यापन आधार प्रदान करता है
  • DID का फ़ॉर्मैट did:<method>:<identifier> होता है, और DID Document में मौजूद public key और PDS location का उपयोग करके पोस्ट लिखने वाले और अकाउंट के बीच संबंध को सत्यापित किया जाता है
  • did:web डोमेन के /.well-known/did.json को देखने का एक सरल तरीका है, लेकिन यह DNS और registrar पर निर्भरता, वेब सर्वर बंद होने, और document परिवर्तन के लागू होने में देरी जैसी समस्याओं के प्रति संवेदनशील है
  • Bluesky द्वारा बनाया गया did:plc ID को किसी खास डोमेन से अलग करता है और plc.directory संचालन का बोझ संभालता है, लेकिन DNS की जगह plc.directory पर भरोसा करना पड़ता है, और Bluesky में blockchain-आधारित DID तरीकों आदि का उपयोग नहीं किया जा सकता
  • उपयोगकर्ता अतिरिक्त keys रजिस्टर करके, key rotation करके, और अपना PDS चलाकर Bluesky द्वारा बनाई गई keys हटा सकते हैं और अपनी पहचान पर वास्तविक प्रत्यक्ष नियंत्रण कर सकते हैं, बिना सभी पर जटिल key management थोपे इच्छुक लोगों को यह विकल्प दिया जाता है

Bluesky अकाउंट और DID-आधारित पहचान

  • “Bluesky अकाउंट” सिर्फ Bluesky में इस्तेमाल होने वाला अकाउंट नहीं है, बल्कि ATmosphere की कई applications में इस्तेमाल किया जा सकने वाला अकाउंट है
  • Bluesky और अन्य ऐप्स के आधार प्रोटोकॉल atproto में, उपयोगकर्ता कौन है यह दिखाने और login या पोस्ट के लेखक की पुष्टि करने के लिए DID का उपयोग किया जाता है
  • W3C द्वारा 2022 में standardize किया गया DID एक decentralized identifier है जिसे applications में पहचान के आधार के रूप में इस्तेमाल किया जा सकता है
  • DID की decentralization का मतलब यह है कि किसी एक संस्था द्वारा वैध DID प्रकार तय करने के बजाय, उपयोगकर्ता अपनी पहचान सत्यापित करने के लिए DID method चुन सकता है
  • हालांकि, applications सभी DID methods को अपने-आप संभाल नहीं सकतीं
    • हर method के लिए support code अलग से implement करना पड़ता है
    • अगर कोई ऐप foo method को support नहीं करता, तो did:foo:1243 दिखाने पर भी उसे interpret नहीं कर पाएगा

DID और DID Document

  • उदाहरण DID did:plc:3danwc67lo7obz2fmdg6jxcr colon से अलग किए गए तीन हिस्सों से बना है
    • scheme: did
    • method: plc
    • method-specific identifier: 3danwc67lo7obz2fmdg6jxcr
  • DID का उपयोग करने के लिए इसे DID Document में resolve करना पड़ता है
  • DID Document में cryptographic public keys जैसे data होते हैं, ताकि DID subject या उसके delegate स्वयं को authenticate कर सकें और उस DID से अपना संबंध साबित कर सकें
  • उदाहरण document में पहचान सत्यापन के लिए ज़रूरी जानकारी शामिल होती है
    • id: DID स्वयं
    • alsoKnownAs: at://steveklabnik.com
    • verificationMethod: Multikey प्रकार और publicKeyMultibase
    • service: AtprotoPersonalDataServer प्रकार का PDS endpoint
  • जब कोई पोस्ट यह दावा करती है कि उसे किसी खास उपयोगकर्ता ने लिखा है, तो document की verification जानकारी से इस दावे की सत्यता की जांच की जा सकती है
  • DID को document में resolve करने की प्रक्रिया method-विशिष्ट standard से तय होती है
    • did:plc PLC standard का पालन करता है
    • Bluesky द्वारा supported दूसरा तरीका did:web है, जिसे Web method से resolve किया जाता है

did:web कैसे resolve होता है

  • did:web का उपयोग करने वाले लोग बहुत कम हैं, लेकिन इसकी संरचना सरल है इसलिए DID resolution प्रक्रिया को समझना आसान है
  • Liz Fong-Jones का did:web:lizthegrey.com अपने method-specific identifier lizthegrey.com को नीचे दिए गए URL template में डालकर resolve किया जाता है
https://<id>/.well-known/did.json
  • उस URL से मिले DID Document में यह जानकारी होती है
    • id: did:web:lizthegrey.com
    • alsoKnownAs: at://web.lizthegrey.com, did:plc:i4tfenpfog244rxry5uz4vtk
    • verificationMethod: atproto के लिए Multikey public key
    • serviceEndpoint: https://pds.lizthegrey.com

did:web की सीमाएँ

  • did:web DNS और domain registrar पर निर्भर करता है
    • registrar अगर domain वापस ले ले, तो DID पर नियंत्रण भी खो जाता है
    • domain का उपयोग बंद कर देने या expiry के बाद किसी और द्वारा खरीद लेने पर भी पहचान खो सकती है
    • registrar account hack होकर domain छिन जाने पर भी यही स्थिति होती है
  • DID Document देने वाला web server लगातार चलाना पड़ता है, और server बंद हो जाए तो document भी नहीं मिल सकता
  • DID Document में बदलाव की जानकारी clients को तुरंत बताने का भी कोई तरीका नहीं है
    • applications पुराने document का उपयोग करती रह सकती हैं
    • document update और application में उसके लागू होने के बीच देरी के कारण नया document फिर से fetch होने तक अस्थायी समस्याएँ आ सकती हैं

did:plc पहचान बनाए रखने के तरीके को कैसे बदलता है

  • Bluesky ने did:web की समस्याएँ कम करने के लिए did:plc विकसित किया
  • did:plc पूरे DID को नीचे दिए गए URL template में डालकर DID Document प्राप्त करता है
https://plc.directory/<did>;
  • URL lookup होने के मामले में यह did:web जैसा ही है, लेकिन संचालन और पहचान बनाए रखने का तरीका अलग है
    • DID किसी खास domain से बंधा नहीं होता, इसलिए steveklabnik.com को expire होने देना और steve.klabnik.com पर जाना पड़े तब भी वही DID बनाए रखा जा सकता है
    • web server चलाने का काम उपयोगकर्ता के बजाय plc.directory संभालता है, जिससे संचालन का बोझ कम हो जाता है
  • भरोसे की ज़रूरत पूरी तरह खत्म नहीं होती
    • did:web में DNS और domain registrar पर भरोसा करना पड़ता है
    • did:plc में यह भरोसा करना पड़ता है कि plc.directory ID नहीं छीनेगा और खुद compromise नहीं होगा
  • जो उपयोगकर्ता DNS और plc.directory दोनों पर भरोसा नहीं करना चाहते, वे blockchain आदि से नाम resolve करने वाले दूसरे DID methods चुन सकते हैं
  • लेकिन Bluesky ऐसे methods को support नहीं करता, इसलिए Bluesky applications में उनका उपयोग नहीं किया जा सकता

accessibility की समस्या और नए DID तरीके

  • did:web को सीधे सेट up करने के लिए non-expert उपयोगकर्ताओं के लिए बोझिल काम करने पड़ते हैं
    • domain register करना और लगातार उसकी फ़ीस देना
    • web server सेट करना और DID Document के लिए JSON लिखना
    • server को लगातार चालू रखना
    • private key को store करना और सुरक्षित रूप से manage करना
  • यह प्रक्रिया सामान्य web app signup की तुलना में कहीं अधिक जटिल है, इसलिए यह उस Bluesky लक्ष्य से मेल नहीं खाती जिसमें non-expert उपयोगकर्ता भी platform का उपयोग कर सकें
  • अगर plc.directory ये संबंधित काम संभाल ले, तो उपयोगकर्ताओं को ये चरण खुद नहीं करने पड़ते
  • did:webvh did:web का विस्तार करके उसकी कुछ कमियों को दूर करने की कोशिश करने वाला तरीका है और 1.0 तक पहुँच चुका है, लेकिन इसकी विस्तृत specification यहाँ तुलना का हिस्सा नहीं है

Bluesky में अपनी पहचान सीधे अपने नियंत्रण में कैसे रखें

  • default setting में Bluesky उपयोगकर्ता की key pair बनाता है और secret key तक पहुँच रख सकता है, इसलिए एक अर्थ में कहा जा सकता है कि पहचान Bluesky के नियंत्रण में है
  • did:plc ID में अतिरिक्त key pairs register करने और signing key को rotate करने की सुविधा देता है
    • Bluesky द्वारा बनाई गई keys हटाई जा सकती हैं
    • उन्हें उपयोगकर्ता द्वारा स्वयं बनाई गई keys से बदला जा सकता है
  • सिर्फ keys बदल देने से Bluesky infrastructure से पूरी तरह अलगाव नहीं हो जाता
    • PDS को पोस्ट पर sign करने के लिए उपयोगकर्ता की keys इस्तेमाल करनी पड़ती हैं
    • अगर Bluesky-managed PDS इस्तेमाल किया जाता है, तो आमतौर पर keys Bluesky infrastructure में store रहती हैं
  • Bluesky और पहचान को अलग करने के लिए अपना PDS चलाने के बाद key rotation करना होगा
    • keys उपयोगकर्ता के स्वामित्व वाले infrastructure में store होंगी
    • इसके बाद Bluesky उन keys को नियंत्रित नहीं कर पाएगा
  • भले ही अधिकांश उपयोगकर्ता अपना PDS और key management न चुनें, यह तथ्य कि इच्छुक उपयोगकर्ता वास्तव में अपनी पहचान के मालिक बन सकते हैं, एक महत्वपूर्ण design property है
  • सभी उपयोगकर्ताओं पर direct key management थोपने के बजाय, इच्छुक उपयोगकर्ताओं को विकल्प देना अधिकांश उपयोगकर्ताओं के लिए अधिक उपयुक्त तरीका है

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

1 टिप्पणियां

 
GN⁺ 5 시간 전
Lobste.rs की टिप्पणियाँ
  • plc.directory शुरू में Bluesky के नियंत्रण में था, लेकिन अभी यह स्विस गैर-लाभकारी संस्था के रूप में स्वतंत्र होने की प्रक्रिया में है
  • सच कहें तो DID, बड़ी tech कंपनियों के unified authentication (SSO) से बेहतर समाधान है। बस इसे did:plc: की तरह आम लोगों के लिए भी उपयोगी होना चाहिए, और भले ही इसका स्वामित्व किसी non-profit के पास हो, केंद्रीय संस्था पर पूरी तरह भरोसा करना चाहिए या नहीं, इस पर सोचना होगा
    Keybase को फिर से implement करते हुए W3C DID और W3C Verifiable Credentials (VC) को support करने वाला एक project develop कर रहा हूँ। लक्ष्य यह है कि इंसान होने को unique लेकिन private तरीके से prove किया जा सके, और लोगों के पास अपने control वाली decentralized identity हो
    • क्या आप FOKS develop कर रहे हैं, या कोई अलग project है?
      https://foks.pub/
  • शीर्षक देखकर लगा था कि यह DID specification से link होगा, लेकिन असल लेख भी छोटा और उपयोगी है
    • लेख का पहला link ही specification link है
  • आज पता चला: DID का मतलब Docker in Docker नहीं था
    • मुझे पहली बार पता चला कि Docker in Docker को DID भी पढ़ा जा सकता है। मैंने हमेशा इसे DinD या और भी confusing dind के रूप में संक्षिप्त सुना था; नहीं पता यह workplace की practice है या सामान्य notation
    • इसका मतलब Direct Inward Dialing भी नहीं है
  • Bluesky इस्तेमाल न करने वाले readers के लिए क्या आप बता सकते हैं कि PDS क्या है?
    • PDS का मतलब Personal Data Server है, यानी posts जैसी content का origin server
    • Bluesky/AT में सभी users की posts को एक बड़े database में डालने के बजाय, हर user के पास PDS नाम का अलग data store होता है। आप Bluesky द्वारा दिए गए PDS का इस्तेमाल कर सकते हैं, self-host कर सकते हैं, या किसी third-party service का उपयोग कर सकते हैं, और अपने पूरे account history को बनाए रखते हुए PDS के बीच transparently migrate भी कर सकते हैं
      यह Mastodon instance जैसा नहीं है, और AT तथा ActivityPub की concepts का एक-दूसरे से साफ़-साफ़ one-to-one mapping नहीं है
  • अगर did:web के लिए .well-known server host करना पड़ता है और data भी लगभग static है, तो TXT record की तरह URL जैसा पढ़ा जा सकने वाला, ज़्यादा cache होने की संभावना वाला और accidental outage की संभावना कम रखने वाला DNS सीधे इस्तेमाल क्यों नहीं किया जाता?
    DNS dependency और did.json updates को आसानी से detect न कर पाने की समस्या तो रहेगी, लेकिन अगर मकसद किसी खास domain को किसी व्यक्ति की identity से जोड़ना है, तो components को minimum रखना और सीधे DNS functionality से जोड़ना बेहतर लगता है। जानना चाहूँगा कि यह तरीका काम क्यों नहीं करता या practical तौर पर मुश्किल क्यों है