เผยแพร่ข้อกำหนด 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, ข้อกำหนดการออกจากระบบ และโหมดการตอบกลับของ OAuth 2.0 เข้าสู่ระบบมาตรฐานสากล
  • OpenID Foundation ยื่นต่อ ISO ในเดือนธันวาคม 2023 ผ่านรูปแบบ PAS(Publicly Available Specifications) และหลังจากนั้นก็ผ่านการลงมติอนุมัติของ ISO จนเผยแพร่เสร็จสมบูรณ์
  • การเป็นมาตรฐาน ISO อาจช่วยให้ การนำ OpenID Connect ไปใช้งาน ทำได้ง่ายขึ้นในเขตอำนาจศาลที่กำหนดให้ต้องใช้ข้อกำหนดจากองค์กรกำหนดมาตรฐานที่ได้รับการรับรองตามสนธิสัญญาระหว่างประเทศ
  • ก่อนการยื่น OpenID Connect working group ได้ดำเนินกระบวนการใช้ errata corrections เพื่อให้เวอร์ชัน ISO รวมการแก้ไขที่ทราบอยู่แล้ว
  • OpenID Foundation มีแผนจะอาศัยประสบการณ์จากกระบวนการ PAS ครั้งนี้ เพื่อยื่น FAPI 1.0 และหลังจากสรุปขั้นสุดท้ายแล้วก็จะยื่นชุดข้อกำหนด eKYC-IDA และ FAPI 2.0 เพื่อเผยแพร่เป็น ISO ด้วย

ข้อกำหนดที่เผยแพร่เป็นมาตรฐาน ISO/IEC

การยื่นผ่าน PAS และการอนุมัติของ ISO

  • การยื่นข้อกำหนด OpenID Connect ในนาม OpenID Foundation ดำเนินการในเดือนธันวาคม 2023 ในรูปแบบ PAS(Publicly Available Specifications)
  • หลังการลงมติอนุมัติของ ISO ข้อกำหนดดังกล่าวก็ได้รับการเผยแพร่เป็นมาตรฐาน ISO/IEC
  • ISO เป็นหนึ่งในองค์กรกำหนดมาตรฐานที่ได้รับการรับรองตามสนธิสัญญาระหว่างประเทศ ดังนั้นในเขตอำนาจศาลที่กฎหมายกำหนดให้ใช้มาตรฐานจากองค์กรลักษณะนี้ โอกาสในการนำ OpenID Connect มาใช้ก็อาจเพิ่มขึ้น

การแก้ไขที่รวมอยู่ในเวอร์ชัน ISO

  • ก่อนการยื่น OpenID Connect working group ได้ดำเนินกระบวนการใช้ errata corrections กับข้อกำหนด
  • ผลคือเวอร์ชัน ISO ได้รวมการแก้ไขที่ทราบอยู่แล้วเข้าไป

แผนการยื่นต่อ ISO ถัดไป

  • หลังจาก OpenID Foundation ดำเนินกระบวนการยื่น ISO PAS สำเร็จหนึ่งครั้งแล้ว ก็มีแผนจะยื่นชุดข้อกำหนดฉบับสมบูรณ์เพิ่มเติมเพื่อเผยแพร่เป็น ISO
  • เป้าหมายถัดไปรวมถึงข้อกำหนด FAPI 1.0
  • ส่วนข้อกำหนด eKYC-IDA และ FAPI 2.0 ถูกวางไว้เป็นรายการที่จะยื่นหลังสรุปขั้นสุดท้าย

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2024-11-11
ความคิดเห็นบน Hacker News

  • แม้ผมจะเคยมีส่วนเกี่ยวข้องกับ OpenID ค่อนข้างลึกเมื่อราว 17 ปีก่อน(https://simonwillison.net/search/?tag=openid&year=2007) แต่ก็น่าอายที่ใช้เวลานานมากกว่าจะเข้าใจว่า OpenID Connect แทบไม่เกี่ยวข้องกับแนวคิด OpenID ดั้งเดิมที่ว่า “ตัวระบุเป็น URL และพิสูจน์ความเป็นเจ้าของ URL นั้น” เลย
    OpenID Connect จริง ๆ แล้วใกล้เคียงกับ วิวัฒนาการของ OAuth มากกว่า

    • ถ้าเขียนไว้เป็นบันทึกสำหรับตัวเองในอนาคต OpenID Connect (OIDC) จัดการเรื่อง การยืนยันตัวตน เป็นหลัก ส่วน OAuth หรือให้แม่นกว่านั้น OAuth v2.0 จัดการเรื่อง การอนุญาตสิทธิ์
      ผมมองว่า OpenID Connect ไม่ใช่วิวัฒนาการของ OAuth เท่าไรนัก แต่ในแง่วิสัยทัศน์และจิตวิญญาณแล้วใกล้กับวิวัฒนาการของ OpenID มากกว่า OIDC โฟกัสที่การระบุตัวผู้ใช้และการยืนยันตัวตนเหมือน OpenID แต่ต่างจาก OpenID ตรงที่ไม่ได้สร้างโฟลว์การยืนยันตัวตนใหม่ทั้งหมดขึ้นมาอีกครั้ง และบรรลุเป้าหมายหลักโดยวางโฟลว์การยืนยันตัวตนไว้บนสเปก OAuth ที่ถูกนำไปใช้ผิดวัตถุประสงค์เพื่อการยืนยันตัวตนอยู่แล้ว
    • OAuth2 มีรูปแบบการประกอบใช้งานที่ยืดหยุ่นเกินไปพอสมควร และ OIDC ให้แนวปฏิบัติที่ดีไว้มากมายสำหรับคำถามว่า “ควรประกอบมันอย่างไร”
      ดังนั้นแม้แต่ระบบที่ไม่ได้ตั้งเป้าจะรองรับ OIDC เต็มรูปแบบ ก็มักทำตาม OIDC บางส่วนอยู่ดี ถ้าบางส่วนของมาตรฐาน OIDC ให้สิ่งที่ต้องการอยู่แล้ว ก็ไม่มีเหตุผลต้องประดิษฐ์ล้อขึ้นมาใหม่
    • การตั้งชื่อนี่เป็นฝันร้ายสุด ๆ
      OpenID Connect คือส่วนขยายที่เพิ่มชั้นการยืนยันตัวตนให้ OAuth2 (RFC 6749) ส่วน OAuth2 คือเฟรมเวิร์กการอนุญาตสิทธิ์สำหรับมอบสิทธิ์
      ในทางกลับกัน OAuth 1.0/1.0a กับ OpenID 1/2 เป็นโปรโตคอลที่แค่ชื่อคล้ายกัน แต่ไม่เกี่ยวข้องกันและเข้ากันไม่ได้ ดังนั้น ณ ปี 2024 จึงแทบไม่เกี่ยวข้องแล้ว ต้องระวังเวลาเสิร์ช
    • ผมเข้าใจว่า OpenID Connect ใกล้เคียงกับ การทำให้เฉพาะทางที่สร้างอยู่บน OAuth2 มากกว่า
    • ผมเริ่มสนใจ OpenID ครั้งแรกเพราะงานนำเสนอที่ Webstock เมื่อปี 2008

  • นี่ไม่ใช่เรื่องดีในแง่ไหนเลย อย่างแรก มาตรฐานแบบเสียเงิน ที่ต้องจ่ายเงินถึงจะอ่านได้นั้นแย่มากจริง ๆ
    อย่างที่สอง อยากให้มีความพยายามมากขึ้นในการออกแบบมาตรฐานและการใช้งานจริงที่ไม่กลายเป็นหลุมดูดเวลาที่ไม่มีที่สิ้นสุดเมื่อต้องใช้

    • เรื่อง ISO ผมเห็นด้วย แต่ในกรณีนี้คงพูดได้ยากว่ามี กำแพงค่าผ่านทาง ที่มีนัยสำคัญ ตัวมาตรฐานเองเผยแพร่ให้ใช้ฟรีอยู่แล้ว และเรื่องนี้ดูเหมือนเป็นการกำหนดตัวระบุในเนมสเปซมาตรฐานของ ISO
      แต่ผมก็ไม่ค่อยแน่ใจว่าการได้หมายเลขมาตรฐาน ISO มีข้อดีอะไรเหนือกว่าการเอาเอกสาร HTML ขึ้นอินเทอร์เน็ต
    • ในฝั่งอินเทอร์เน็ต ผมสงสัยว่าทำไมของแบบนี้ไม่ทำเป็น RFC อีเมลกับ TCP ก็เป็น RFC และองค์ประกอบหลักอื่น ๆ ก็เช่นกัน บริษัทระดับโลกก็ใช้อยู่เสมอ

  • มาตรฐานเป็นเรื่องดี แต่องค์กรมาตรฐานขนาดใหญ่แบบ ISO น่าหงุดหงิดตรงที่เก็บเงินถ้าจะอ่านมาตรฐาน
    คงเป็นเพราะบางบริษัทหรือบางอุตสาหกรรมต้องการ มาตรฐาน “ของจริง” จากองค์กรแบบนั้น มากกว่าสิ่งที่ทำโดย IETF หรือพวกฮิปปี้โอเพนซอร์สสกปรก

    • ฝั่งนั้นอ้างว่าเพื่อให้การเข้าถึงและเงินทุนแก่พื้นที่ที่พัฒนาน้อยกว่า
    • คำว่า “มาตรฐาน” กับ “มีค่าใช้จ่าย” ให้ความรู้สึกขัดกันเอง ถ้าต้องการให้วิธีใดวิธีหนึ่งกลายเป็นมาตรฐาน หรือก็คือวิธีที่ใช้กันแพร่หลายที่สุด ก็ควรเข้าถึงได้มากพอเพื่อให้ถูกนำไป implement ได้อย่างกว้างขวาง
    • มาตรฐานส่วนใหญ่ราคาต่ำจนขายแบบขาดทุนด้วยซ้ำ แต่ถ้าอยากบริจาคให้ ISO หรือ IEEE ก็จะช่วยลดต้นทุนในการจัดทำมาตรฐานได้
    • ในบริบทของรัฐบาลหรือระดับประเทศ ผมเข้าใจว่าเพราะ ISO ได้รับการยอมรับในสนธิสัญญาระหว่างประเทศหลายฉบับ จึงมักขออนุมัติใช้ มาตรฐาน ISO ได้ง่ายกว่า มาตรฐานของ OpenID Foundation
      ดังนั้นเมื่อ OpenID Connect ถูกเผยแพร่ด้วยหมายเลข ISO บางโปรเจกต์ก็จะนำไปใช้ได้ง่ายขึ้น แน่นอนว่า OpenID Connect เองยังคงอ่านและใช้งานได้ฟรีต่อไป แต่คนที่อยู่ในสถานการณ์ข้างต้นจะมีตัวเลือกที่ง่ายขึ้น

  • ISO เป็นขยะที่ไม่เสรีและไม่ได้ช่วยระบบนิเวศซอฟต์แวร์
    ดู ISO 8601 สิ มันซับซ้อนเกินไป ผู้ดูแลมักใช้งานไม่ถูกต้องเพราะอาศัยร่างฉบับฟรี และจริง ๆ ก็ไม่ได้แก้ปัญหาอะไรได้อย่างเหมาะสม ตัวอย่างเช่น มันแสดงเวลาแบบนาฬิกาบนผนังไม่ได้ จึงมีปัญหากับวันที่ในอนาคตที่เขตเวลาอาจเปลี่ยนได้
    ผมเคยจัดการกับ mp4 มาก่อน และพบว่ามีการเปลี่ยนแปลงในสแต็กของ Apple ทำให้ ISO อย่างเดียวไม่เพียงพอ

    • เข้าใจข้อร้องเรียนเฉพาะเจาะจงนะ แต่ผมมองว่าการไม่แสดงเวลาแบบนาฬิกาบนผนังเป็นฟีเจอร์มากกว่า
      คำวิจารณ์มักไหลไปสู่สมมติฐานอย่างการเปลี่ยนแปลงเวลาออมแสง เช่น “อยากระบุเวลา 14:00 ตามเวลาท้องถิ่นของ Absurdistan ในอีก 4 ปีข้างหน้า โดยไม่สนว่ามันสัมพันธ์กับ UTC อย่างไร แต่ทำไม่ได้” คำวิจารณ์แบบนี้พบได้บ่อย แต่ถ้าดันสมมติฐานต่อไปอีกหน่อย Absurdistan อาจเพิ่มดินแดนโพ้นทะเล เข้าร่วมพันธมิตร หรือเปลี่ยนเขตเวลาและเวลาออมแสงก็ได้
      ถ้าคิดถึงปัญหานี้ นิยามของ เวลาท้องถิ่น เองก็อาจเปลี่ยนได้ ดังนั้นตราบใดที่ไม่ได้กำหนดการเปลี่ยนแปลงที่เป็นไปได้ทั้งหมดไว้อย่างครบถ้วน การระบุเวลาท้องถิ่นในอนาคตก็เป็นไปไม่ได้ สุดท้ายจึงต้องกำหนด จำนวนติ๊กของนาฬิกาอะตอม (TAI) ในอนาคตแล้วตีความเป็นเวลาท้องถิ่น ณ เวลาที่ใช้งาน หรือกำหนดเวลาคงที่สักค่าแล้วตีความเป็นเวลาท้องถิ่น ณ เวลาที่ใช้งาน
    • สงสัยว่ามีทางเลือกอื่นแทน ISO 8601 ไหม ข้อไม่พอใจของผมมีแค่ดูเหมือนว่าบางอย่างมีวิธีเขียนมากกว่าหนึ่งวิธี และไม่รู้เรื่องปัญหาเวลาแบบนาฬิกาบนผนังเลย
      สงสัยด้วยว่า JS Temporal API ใหม่จัดการเรื่องนี้หรือเปล่า เหมือนจะลงลึกพอสมควร

  • มาตรฐานที่ต้องจ่ายเงินเพื่ออ่าน แบบ ISO ขัดขวางความก้าวหน้าของมนุษยชาติอย่างจริงจัง ไม่อยากให้สนับสนุนพฤติกรรมแบบนี้

    • ในกรณีของ C++ ร่างมาตรฐานล่าสุดเผยแพร่ให้ใช้ฟรี https://en.cppreference.com/w/cpp/links#C.2B.2B_standard_doc...
      ผมเข้าใจว่าร่างสุดท้ายกับมาตรฐานอย่างเป็นทางการแทบเหมือนกันในแง่เนื้อหาสาระ ร่างมาตรฐาน OIDC ก็น่าจะเผยแพร่อยู่ที่ไหนสักแห่งเหมือนกัน
    • ทุกอย่างไม่จำเป็นต้องเป็นขาวดำ ยอมรับได้ว่ามีพื้นที่สีเทาอยู่
      มันแปลกที่จะบอกว่าวิศวกรเหล่านั้นสร้างความก้าวหน้าให้มนุษยชาติ ขณะเดียวกันก็กำลังทำร้ายความก้าวหน้าของมนุษยชาติอย่างจริงจัง

  • การ provision ตัวตน เป็นสัตว์ประหลาดที่ไม่ควรถูกประดิษฐ์ขึ้นมาเลย
    ช่วงกลางทศวรรษ 2000 ผมเป็นแฟนถึงขั้นรันเซิร์ฟเวอร์ OpenID เอง แต่ตอนนั้นไม่รู้เลยว่าแนวคิดทั้งหมดนี้มีข้อบกพร่องเชิงพื้นฐานแค่ไหน
    ตัวตนเป็นคุณลักษณะที่โอนให้กันไม่ได้ซึ่งมีอยู่ในตัวบุคคล ไม่ใช่สิ่งที่บุคคลอื่น บริษัท/เว็บไซต์ รัฐบาล ฯลฯ จะมา “จัดให้” ได้ พวกเขาทำได้เพียงให้ข้อมูลรับรองเพื่อพิสูจน์ คล้ายกับการออกหนังสือเดินทาง
    อย่างน้อย WebAuthn ก็จับประเด็นนี้ได้ถูกต้อง

    • นี่ไม่ได้ตั้งอยู่บนสมมติฐานว่าตัวตนที่ถูกจัดให้นั้นคือคุณอย่างแม่นยำ และเป็นคุณเท่านั้นหรือ? ผมมองและใช้งานตัวตนเหล่านี้เป็น นามแฝง บนผู้ให้บริการตัวตนบางรายมาโดยตลอด
      ตัวตนบางอย่างถูกใช้ในที่ต่าง ๆ มากพอจนสำหรับบางฝ่ายแล้วจะปฏิเสธได้ยากว่านั่นเป็นของผม แต่ถึงอย่างนั้น ในบรรดาฝ่ายที่เคยเห็นตัวตนนั้น ก็มีเพียงกลุ่มย่อยเล็ก ๆ เท่านั้นที่พิสูจน์ได้ว่าเป็นผม
    • สงสัยว่าการแยกระหว่าง การพิสูจน์ กับ การ provision มีผลในทางปฏิบัติจริงไหม หรือเป็นแค่การแยกเชิงปรัชญาล้วน ๆ

  • ยังมี ผู้ออก OIDC อิสระ ที่ให้สร้างบัญชีนอกเหนือจาก Google, MS, Apple อยู่ไหม?
    ไม่นานมานี้ผมอยากสร้างบัญชี Tailscale โดยไม่ใช้บัญชี GitHub แต่ทำไม่ได้
    เมื่อก่อนเหมือนว่า openid.net กับ Ubuntu One เคยให้บริการแบบนี้ แต่เท่าที่รู้คือหยุดไปแล้ว

    • ยังเหลืออยู่บ้าง และ https://gitlab.com เป็นที่ที่ผมใช้บ่อย
      แต่ต้นทุนด้านความปลอดภัยและการสนับสนุนที่บริการแบบนี้ต้องการนั้นสูง โดยเฉพาะถ้าให้ฟรีก็ยิ่งไม่สมจริงสำหรับองค์กรเล็ก ๆ มี economies of scale ขนาดใหญ่ที่ทำให้เรื่องนี้เป็นไปได้ และจะเข้าทางเป็นพิเศษเมื่อบริษัทใหญ่ ๆ จ่ายเงินให้ผลิตภัณฑ์สำหรับองค์กร

  • OpenID Connect เป็นโปรโตคอลที่ค่อนข้างเรียบง่าย ผมอ่านสเปก (https://openid.net/specs/openid-connect-core-1_0.html) แล้วเข้าใจส่วนใหญ่ได้ในราวหนึ่งวัน
    สำหรับคนที่ไม่อยากอ่านสเปก ผมก็เขียนทิวทอเรียลแบบครบถ้วนที่อิมพลีเมนต์ไคลเอนต์ OpenID ด้วย HTTP request ธรรมดาไว้ด้วย (https://spapas.github.io/2023/11/29/openid-connect-tutorial/)
    ตัวอย่างใช้ Python แต่การอิมพลีเมนต์ด้วยภาษาที่ต้องการก็น่าจะไม่ยาก ส่วนที่ซับซ้อนส่วนใหญ่อยู่ที่การถอดรหัสและตรวจสอบ JWT token
    ไคลเอนต์ที่เขียนเองด้วยมือนี้ถูกใช้กับการยืนยันตัวตนผ่าน Keycloak ในโปรเจกต์โปรดักชันจริงมาราว 1 ปีแล้ว และทุกอย่างทำงานได้สมบูรณ์
    ป.ล. ผมรู้ว่าเว็บผมมีโฆษณาเยอะเกินไป น่าเสียดายที่ผมไม่มีเวลาตั้งค่า Google Ads ให้ดี และก็ยังหาทางเลือกที่ดีกว่าไม่ได้ ใช้ ad blocker ตอนอ่านได้เลย

    • บทความน่าสนใจมากและเขียนได้ดี
      แต่ควรระวังถ้อยคำเชิงอัตวิสัยอย่าง เรียบง่าย ถ้าผู้อ่านรู้สึกว่ายาก แต่ผู้เขียนบอกว่าเรียบง่าย ก็อาจทำให้เขารู้สึกเสียความมั่นใจได้มาก
    • เป็นทิวทอเรียลที่ยอดเยี่ยม
      แต่ผมก็ยังไม่มั่นใจว่า OIDC ง่าย Keycloak ซ่อนความซับซ้อนมหาศาลไว้ และนักพัฒนาไม่ได้ทำให้เป็นแบบนั้นเพราะว่างจัด ตัวอย่างเช่นมีการตั้งค่า timeout หลายแบบเยอะมาก ทั้ง SSO timeout, client timeout, timeout ของ token หลายชนิด ฯลฯ

  • การหารายได้และการบริหารองค์กรรอบ ๆ มาตรฐาน ISO โดยรวมแล้วให้ความรู้สึกน่าสงสัยมาก
    มีเคล็ดลับที่ไม่ค่อยมีคนรู้ คือคุณลองหามาตรฐานเวอร์ชันที่ถูกกว่าจากเว็บไซต์เอสโตเนียใจดี https://evs.ee ได้ พวกเขามักทำเวอร์ชันของตัวเองที่มีเนื้อหาเกือบเหมือนต้นฉบับอยู่บ่อย ๆ น่าเสียดายที่กรณีนี้ดูเหมือนจะมีแต่มาตรฐานจริงในราคาพอ ๆ กัน https://www.evs.ee/en/search?OnlySuggestedProducts=false&que...
    ก็คุ้มที่จะคอยดูไซต์นั้นว่าในภายหลังจะมีเวอร์ชันของตัวเองที่ราคาดีกว่าออกมาหรือไม่ ปกติราคาจะอยู่ราว 10% ของต้นฉบับ นี่เป็นอีกข้อมูลหนึ่งที่ชี้ว่าเอสโตเนียทำเรื่องเจ๋ง ๆ
    จากการทำงานด้านการปฏิบัติตามกฎระเบียบของอุปกรณ์การแพทย์ ผมต้องรับมือกับองค์กรจัดทำมาตรฐานที่ค่อนข้างน่าสงสัยอยู่บ่อย ๆ https://openregulatory.com/accessing-standards/
    ผมเคยได้ยินเหตุผลทั่วไปอย่าง “การทำมาตรฐานมีค่าใช้จ่าย”, “องค์กรเหล่านี้ทำเรื่องดี ๆ” มาหมดแล้ว แต่ไม่เห็นด้วยเลย ถ้าอะไรบางอย่างเป็นมาตรฐาน ผมมองว่ามันคล้ายกับกฎหมาย ผู้คนควรจะสามารถปฏิบัติตามมันได้ และเพื่อให้ทำได้ก็ต้องเข้าถึงได้อย่างเสรี ดูเหมือนอัยการสูงสุดของ EU ก็เห็นด้วย https://openregulatory.com/maybe-eu-standards-are-becoming-f...
    มีมาตรฐานมากมายที่ไม่จำเป็นต้องขาย PDF แบบเก็บเงินอย่างน่าสงสัย ECMAScript กับ ANSI C ผุดขึ้นมาในหัว และยังมีอีกมากต่อไปเรื่อย ๆ

  • การทำให้เป็นสิ่งพิมพ์ของ ISO ทำให้ฝ่ายจัดซื้อมี โล่สำหรับเลี่ยงความรับผิดชอบ
    เพราะอย่างไรก็ไม่เคยมีใครถูกไล่ออกเพราะกำหนดให้ต้องปฏิบัติตามชุดมาตรฐาน ISO