검색결과
-
[신간 소개] 안전한 대한민국 초석을 다지는 국가정보전략연구소 민진규 소장 '스마트 모빌리티 안전' 발간박근혜 전 대통령의 탄핵을 촉발했던 2014년 4월16일 발생한 세월호 침몰 사고는 학생 수백 명이 목숨을 앗아갔다. 하지만 박 전 대통령 뿐 아니라 정치인 누구도 책임을 지지 않으며 정치적 공방으로 시간을 허비했다.2022년 10월29일 서울시 용산구 이태원 압사 참사 사건, 2023년 7월15일 충청북도 청주시 궁평2지하차도 침수 사고, 7월19일 경상북도 예천군 해병대원 사망 사건 모두 정부의 무능과 안일한 대응, 안전불감증이 불러온 참극이다.국가정보전략연구소(이하, 국정연) 민진규 소장은 ‘안전한 대한민국’을 건설하기 위해서는 미국 링컨 대통령이 노예제도를 반대하면서 ‘국민의, 국민에 의한, 국민을 위한 정치’를 주창한 것처럼 동일한 관점에서 안전정책을 접근해야 한다고 주장한다.민 소장은 "정부와 기업이 ‘국민’의 생명과 재산을 보호하지 못한다면 국민 스스로 안전한 사회를 만들기 위한 ‘시민운동’을 활발하게 전개할 수밖에 없다"고 강조했다.따라서 민 소장은 2019년 1월24일부터 세계로컬타임즈에 연구소에서 개발한 K-안전(K-Safety) 모델을 적용해 국내 다양한 산업과 다수 기업의 안전현황을 진단해왔다. 국민 모두가 안전한 대한민국을 위해 안전진단과 제언을 지속하고 있는 민 소장은 9월 말 중앙대 공공행정학부 송용찬 교수, ICT융합안전 정상 교수 등과 공동으로 ICT 융·복합 안전 - 스마트 모빌리티 안전(K-안전모델)을 펴냈다.또한 주변 전문가의 다양한 의견을 반영해 10월31일자로 'ICT 융·복합 안전 - 스마트 모빌리티 안전(K-안전모델)' 개정증보판을 발행하게 돼 책 서문을 소개한다. '스마트 모빌리티 안전 - 서문'인류 문명을 발전시킨 4대 발명품은 종이, 인쇄술, 화약, 나침반이지만 인류가 만든 최고의 발명품 중 하나는 수레다. 기원전 3500년 중앙아시아, 메소포타미아, 동유럽 등에서 수레를 제작하기 시작했다. 사람과 물건을 대규모로 운반하는 교통수단이 발명되며 도시가 발달하고 국가 간 교류가 활성화됐다. 이동수단인 이른바 모빌리티(mobility)의 등장은 인류의 삶을 바꿨으며 대제국을 건설할 수 있는 핵심 도구(tool)로 부상했다. 수레를 끄는 말 대신에 증기기관이 발명되고 이후 스스로 움직이는 자동차의 등장으로 현대 문명은 급격하게 발전했다. 20세기 초 비행기와 20세기 말 전기자동차, 21세기 초 드론(Drone)과 도심항공교통(Urban Air Mobility)까지 개발되며 인류는 상상 속에서만 그리던 스마트 도시(smart city)의 완성을 목전에 두고 있다. 하지만 인생사에서 빛이 있으면 그늘이 있듯이 다양한 모빌리티의 발전과 보급은 인간의 생명과 재산을 위협하고 있다. 모빌리티는 본질적으로 인간이 추구하는 행복한 삶의 디딤돌이 돼야 한다. 이 세상의 주인은 도구가 아니라 인간이기 때문이다. 지난 10여 년 동안 한국은 2014년 세월호 참사, 2022년 이태원 참사 등 크고 작은 안전사고를 다수 경험했지만 정부 차원의 대책은 미흡하다는 평가를 받는다. 근대 국가 설립 이후 국가는 국민의 생명과 재산을 보호하는 가장 중요한 임무를 수행해야 한다. 국가가 국민의 생명을 보호해주지 못한다면 존재의 가치가 없는 것이다. 국가 차원에서 모빌리티의 안전정책을 수립하기 위한 기초 자료를 제공하고자 하는 목적에서 ‘스마트 모빌리티 안전’을 집필하게 됐다. 독자들은 다음과 같은 마음가짐으로 책을 읽기를 바란다. 우선 책 제목에 ‘스마트’라는 용어를 사용한 것은 정부와 공무원이 국민의 안위를 위해 모빌리티안전을 확보하기 위해 현명한 판단을 내려줘야 한다는 점을 강조하기 위함이다. 반복되는 안전사고에도 안전 매뉴얼조차 구비하지 못해 허둥대는 어처구니가 없는 상황은 이제 종료시켜야 한다고 본다.물론 2011년 일본 도호쿠(東北) 지방을 강타한 쓰나미(tsunami)와 후쿠시마 원자력발전소 폭발사고를 수습하는 과정에서 공무원들은 매뉴얼만 맹신해 대참사를 막지 못했다. 그렇다고 해도 매뉴얼이 없는 것보다 있는 것이 안전사고를 예방하는 데 큰 도움이 된다는 점은 부정하지 못한다. 다음으로 ‘스마트’라는 말은 정부와 공무원뿐만 아니라 모든 국민에게도 적용해야 한다고 생각했다. 국민 개개인이 스스로 위험 상황을 인지하고 현명하게 대처하면 정부 차원에서 각종 재난을 대응하고 수습하는 데 투입해야 하는 예산을 줄일 수 있기 때문이다. 안전 관련 공무원을 채용하고 첨단 장비를 도입하려면 막대한 규모의 국가 예산을 투입해야 한다. 국가 예산은 국민 호주머니에서 나오는 돈이므로 이를 줄이면 국민의 세금 부담이 덜어진다. 작은 정부와 큰 정부 중 어느 것이 효율적인지에 대한 학문적 논쟁이 끝나지 않았지만 세금을 많이 내기를 희망하는 국민은 없다. 마지막으로 모빌티리의 제조・운영・수리와 연관 업종에 종사하는 기업도 ‘스마트’하게 사업을 영위하는 것이 100년 기업이 되는 지름길이라는 점을 잊지 않기를 바라는 마음을 담았다. 정부나 사회, 소비자를 속이는 기업은 장기적으로 망할 수밖에 없다. 사실 안전사고의 대부분은 모빌리티 운영자나 운영업체의 부주의나 실수로 일어난다. 눈앞에 보이는 작은 이익에 매몰돼 안전 대처 비용을 줄이는 것이 영리한 경영전략이라고 착각하는 경영자도 적지 않다. 현명한 판단을 내리지 못하면 ‘스마트’하지 않은 것이다. 이 책은 ‘한국에서 반복되는 원시적 수준의 안전사고를 어떻게 하면 줄일 수 있을까?’라는 고민에서 출발했다. 저자들은 오랫동안 안전 관련 정부의 정책, 기업의 경영전략, 국민의 안전의식 등을 연구하며 해결방안을 찾기 위해 노력했다. 부족하지만 대중 모빌리티, 개인 모빌리티, 삭도 모빌리티, 미래 모빌리티 등의 안전을 분석하기 위해 전력을 다했다. 연구 과정에 필요한 자료를 수집하고 정리해준 국가정보전략연구소 박재희 책임연구원, 김봉석객원연구원에게도 감사를 드린다. 생소한 연구 주제에 대해 체계적인 자문과 섬세한 조언을 아끼지 않았던 선배님, 지인들에게도 큰 도움을 받았다. 부족하고 아쉬운 점이 많으므로 제언과 질책이 있다면 겸허히 수용해 보완할 것을 다짐한다.
-
[기획-디지털 ID 표준] ⑮산업단체와 포럼 - 오픈ID(OpenID)디지털 ID(Digital Identity) 분야에서 상호운용(interoperable)이 가능하고 안전한 서비스 보장을 위한 표준에 대한 수요가 증가하고 있다. 다양한 표준 조직 및 산업 기관이 활동하는 이유다.디지털 ID 표준을 개발하는 곳은 유럽표준화기구(European Standardisation Organistions), 국제표준화기구(International Standardisation Organisations), 상업 포럼 및 컨소시엄, 국가기관 등 다양하다.산업단체와 포럼은 공식적으로 표준화 조직으로 간주되지 않지만 디지털 ID 영역을 포함한 특정 영역에서는 사실상의 표준을 제공하고 있다.몇몇의 경우 이들 단체들이 추가 비준을 위해 자신들이 생산한 사양을 ISO/IEC, ITU 통신 표준화 부문(ITU-T), ETSI 등 표준 기관에 제출할 수 있다.이러한 산업단체 및 포럼에는 △인증기관브라우저 포럼(Certification Authority Browser Forum, CA/Browser Forum) △클라우드 서명 컨소시엄(Cloud Signature Consortium, CSC) △국제자금세탁방지기구(Financial Action Task Force, FATF) △신속온라인인증(Fast Identity Online, FIDO) △국제인터넷표준화기구(Internet Engineering Task Force, IETF) △구조화 정보 표준 개발기구(오아시스)(Organization for the Advancement of Structured Information Standards, OASIS) △오픈ID(OpenID) △SOG-IS(Senior Officials Group-Information Systems Security) △W3C(World Wide Web Consortium) 등이다.오픈ID(OpenID)는 개인 및 기업의 비영리 국제 표준화 조직으로 OpenID(개방형 표준 및 분산 인증 프로토콜)를 활성화, 홍보, 보호하기 위해 노력하고 있다.오픈ID 코넥트 코어(OpenID Connect Core)는 핵심 OpenID 기능을 정의하고 있다. OpenID 기능은 OAuth 2.0 기반에 구축된 인증과 최종 사용자에 대한 정보를 전달하기 위한 클레임의 사용이다. 추가적인 기술 사양 문서는 검증 가능한 자격 증명 및 검증 가능한 프리젠테이션의 발급을 확장하기 위해 작성됐다. 또한 OpenID Connect 사용에 대한 보안 및 개인 정보 보호 고려 사항에 대해 설명하고 있다.아래는 오픈ID가 발행한 'OpenID Connect Core 1.0 incorporating errata set 1' 목차 내용이다.■ 목차(Table of Contents)1. Introduction1.1. Requirements Notation and Conventions1.2. Terminology1.3. Overview2. ID Token3. Authentication3.1. Authentication using the Authorization Code Flow3.1.1. Authorization Code Flow Steps3.1.2. Authorization Endpoint3.1.2.1. Authentication Request3.1.2.2. Authentication Request Validation3.1.2.3. Authorization Server Authenticates End-User3.1.2.4. Authorization Server Obtains End-User Consent/Authorization3.1.2.5. Successful Authentication Response3.1.2.6. Authentication Error Response3.1.2.7. Authentication Response Validation3.1.3. Token Endpoint3.1.3.1. Token Request3.1.3.2. Token Request Validation3.1.3.3. Successful Token Response3.1.3.4. Token Error Response3.1.3.5. Token Response Validation3.1.3.6. ID Token3.1.3.7. ID Token Validation3.1.3.8. Access Token Validation3.2. Authentication using the Implicit Flow3.2.1. Implicit Flow Steps3.2.2. Authorization Endpoint3.2.2.1. Authentication Request3.2.2.2. Authentication Request Validation3.2.2.3. Authorization Server Authenticates End-User3.2.2.4. Authorization Server Obtains End-User Consent/Authorization3.2.2.5. Successful Authentication Response3.2.2.6. Authentication Error Response3.2.2.7. Redirect URI Fragment Handling3.2.2.8. Authentication Response Validation3.2.2.9. Access Token Validation3.2.2.10. ID Token3.2.2.11. ID Token Validation3.3. Authentication using the Hybrid Flow3.3.1. Hybrid Flow Steps3.3.2. Authorization Endpoint3.3.2.1. Authentication Request3.3.2.2. Authentication Request Validation3.3.2.3. Authorization Server Authenticates End-User3.3.2.4. Authorization Server Obtains End-User Consent/Authorization3.3.2.5. Successful Authentication Response3.3.2.6. Authentication Error Response3.3.2.7. Redirect URI Fragment Handling3.3.2.8. Authentication Response Validation3.3.2.9. Access Token Validation3.3.2.10. Authorization Code Validation3.3.2.11. ID Token3.3.2.12. ID Token Validation3.3.3. Token Endpoint3.3.3.1. Token Request3.3.3.2. Token Request Validation3.3.3.3. Successful Token Response3.3.3.4. Token Error Response3.3.3.5. Token Response Validation3.3.3.6. ID Token3.3.3.7. ID Token Validation3.3.3.8. Access Token3.3.3.9. Access Token Validation4. Initiating Login from a Third Party5. Claims5.1. Standard Claims5.1.1. Address Claim5.1.2. Additional Claims5.2. Claims Languages and Scripts5.3. UserInfo Endpoint5.3.1. UserInfo Request5.3.2. Successful UserInfo Response5.3.3. UserInfo Error Response5.3.4. UserInfo Response Validation5.4. Requesting Claims using Scope Values5.5. Requesting Claims using the "claims" Request Parameter5.5.1. Individual Claims Requests5.5.1.1. Requesting the "acr" Claim5.5.2. Languages and Scripts for Individual Claims5.6. Claim Types5.6.1. Normal Claims5.6.2. Aggregated and Distributed Claims5.6.2.1. Example of Aggregated Claims5.6.2.2. Example of Distributed Claims5.7. Claim Stability and Uniqueness6. Passing Request Parameters as JWTs6.1. Passing a Request Object by Value6.1.1. Request using the "request" Request Parameter6.2. Passing a Request Object by Reference6.2.1. URL Referencing the Request Object6.2.2. Request using the "request_uri" Request Parameter6.2.3. Authorization Server Fetches Request Object6.2.4. "request_uri" Rationale6.3. Validating JWT-Based Requests6.3.1. Encrypted Request Object6.3.2. Signed Request Object6.3.3. Request Parameter Assembly and Validation7. Self-Issued OpenID Provider7.1. Self-Issued OpenID Provider Discovery7.2. Self-Issued OpenID Provider Registration7.2.1. Providing Information with the "registration" Request Parameter7.3. Self-Issued OpenID Provider Request7.4. Self-Issued OpenID Provider Response7.5. Self-Issued ID Token Validation8. Subject Identifier Types8.1. Pairwise Identifier Algorithm9. Client Authentication10. Signatures and Encryption10.1. Signing10.1.1. Rotation of Asymmetric Signing Keys10.2. Encryption10.2.1. Rotation of Asymmetric Encryption Keys11. Offline Access12. Using Refresh Tokens12.1. Refresh Request12.2. Successful Refresh Response12.3. Refresh Error Response13. Serializations13.1. Query String Serialization13.2. Form Serialization13.3. JSON Serialization14. String Operations15. Implementation Considerations15.1. Mandatory to Implement Features for All OpenID Providers15.2. Mandatory to Implement Features for Dynamic OpenID Providers15.3. Discovery and Registration15.4. Mandatory to Implement Features for Relying Parties15.5. Implementation Notes15.5.1. Authorization Code Implementation Notes15.5.2. Nonce Implementation Notes15.5.3. Redirect URI Fragment Handling Implementation Notes15.6. Compatibility Notes15.6.1. Pre-Final IETF Specifications15.6.2. Google "iss" Value15.7. Related Specifications and Implementer's Guides16. Security Considerations16.1. Request Disclosure16.2. Server Masquerading16.3. Token Manufacture/Modification16.4. Access Token Disclosure16.5. Server Response Disclosure16.6. Server Response Repudiation16.7. Request Repudiation16.8. Access Token Redirect16.9. Token Reuse16.10. Eavesdropping or Leaking Authorization Codes (Secondary Authenticator Capture)16.11. Token Substitution16.12. Timing Attack16.13. Other Crypto Related Attacks16.14. Signing and Encryption Order16.15. Issuer Identifier16.16. Implicit Flow Threats16.17. TLS Requirements16.18. Lifetimes of Access Tokens and Refresh Tokens16.19. Symmetric Key Entropy16.20. Need for Signed Requests16.21. Need for Encrypted Requests17. Privacy Considerations17.1. Personally Identifiable Information17.2. Data Access Monitoring17.3. Correlation17.4. Offline Access18. IANA Considerations18.1. JSON Web Token Claims Registration18.1.1. Registry Contents18.2. OAuth Parameters Registration18.2.1. Registry Contents18.3. OAuth Extensions Error Registration18.3.1. Registry Contents19. References19.1. Normative References19.2. Informative ReferencesAppendix A. Authorization ExamplesA.1. Example using response_type=codeA.2. Example using response_type=id_tokenA.3. Example using response_type=id_token tokenA.4. Example using response_type=code id_tokenA.5. Example using response_type=code tokenA.6. Example using response_type=code id_token tokenA.7. RSA Key Used in ExamplesAppendix B. AcknowledgementsAppendix C. Notices§ Authors' Addresses
-
[기획-디지털 ID 기술] ㉜ 다임러, '차량의 적어도 하나의 드라이빙 환경 센서를 점검하기 위한 방법' 명칭의 미국 특허 등록 (US 11787424)독일 글로벌 자동차 제조업체 다임러(Daimler AG)에 따르면 2023년 10월17일 '차량의 적어도 하나의 드라이빙 환경 센서를 점검하기 위한 방법(Method for checking at least one driving environment sensor of a vehicle)' 명칭의 미국 특허(US 11787424)가 등록됐다.본 등록 특허는, 2018년 10월30일 원출원된 독일 특허(DE10-2018-127059)건을 기초로 2019년 9월26일 PCT 국제 출원(WO2020-088857)된 후 미국 국내단계에 진입되어 미국 특허청에 의해 심사를 받았다.본 등록 특허의 패밀리 특허로서 중국 특허(CN 112955775)가 심사 중이고, 독일 특허(DE10-2018-127059)도 심사를 받고 있다.본 등록 특허의 일 실시예에 따르면 차량은 디지털 지도상에 위치되고 차량의 환경은 드라이빙 환경 센서를 이용하여 감지된다.이때, 드라이빙 환경 센서에서 인식할 것으로 예상되는 차량 내 환경에 저장된 정지 물체의 특징은 디지털 지도에서 식별된다. 주행 환경 센서의 성능 저하는 하기의 경우에 추론된다.기대에 따라 인식되어야 할 특징이 드라이빙 환경 센서에 의해 인식되지 않는 경우이거나, 드라이빙 환경 센서에 의해 실제로 인식되는 특징이 기대에 따라 인식되는 특징으로부터 크게 벗어나는 경우이다.만약 인식이 예상되는 특징이 적어도 하나의 동적 객체에 의해 은닉되어 드라이빙 환경 센서에 의해 인식되지 않는 것으로 판단되면 드라이빙 환경 검출 센서의 열화는 추론되지 않는다.
-
[기획-디지털 ID 표준] ⑭산업단체와 포럼 - 오아시스(OASIS)디지털 ID(Digital Identity) 분야에서 상호운용(interoperable)이 가능하고 안전한 서비스 보장을 위한 표준에 대한 수요가 증가하고 있다. 다양한 표준 조직 및 산업 기관이 활동하는 이유다.디지털 ID 표준을 개발하는 곳은 유럽표준화기구(European Standardisation Organistions), 국제표준화기구(International Standardisation Organisations), 상업 포럼 및 컨소시엄, 국가기관 등 다양하다.산업단체와 포럼은 공식적으로 표준화 조직으로 간주되지 않지만 디지털 ID 영역을 포함한 특정 영역에서는 사실상의 표준을 제공하고 있다.몇몇의 경우 이들 단체들이 추가 비준을 위해 자신들이 생산한 사양을 ISO/IEC, ITU 통신 표준화 부문(ITU-T), ETSI 등 표준 기관에 제출할 수 있다.이러한 산업단체 및 포럼에는 △인증기관브라우저 포럼(Certification Authority Browser Forum, CA/Browser Forum) △클라우드 서명 컨소시엄(Cloud Signature Consortium, CSC) △국제자금세탁방지기구(Financial Action Task Force, FATF) △신속온라인인증(Fast Identity Online, FIDO) △국제인터넷표준화기구(Internet Engineering Task Force, IETF) △구조화 정보 표준 개발기구(오아시스)(Organization for the Advancement of Structured Information Standards, OASIS) △오픈ID(OpenID) △SOG-IS(Senior Officials Group-Information Systems Security) △W3C(World Wide Web Consortium) 등이다.구조화 정보 표준 개발기구(Organization for the Advancement of Structured Information Standards, OASIS)는 공급업체와 사용자의 컨소시엄으로 시작됐다.오늘날 사이버보안(cybersecurity), 블록체인(blockchain), 사물인터넷(internet of things, IoT), 비상 경영(emergency management), 클라우드 컴퓨팅(cloud computing) 등 프로젝트를 발전시키는 대규모 비영리 표준 조직이다.오아시스는 '디지털 서명 서비스 핵심 프로토콜, 요소, 바인딩'과 같은 디지털 서명과 관련된 프로토콜, 프로필 등 기술 사양을 개발해왔다.오아시스는 ISO에 협력하고 있는 조직으로 각 기술위원회(TC) 또는 분과위원회(SC)가 다루는 문제에 대해 기술위원회(TC) 또는 분과위원회(SC)의 업무에 효과적으로 기여하는 조직(A liaisons)이다.기여하고 있는 기술위원회 및 분과위원회는 다음과 같다.▷ISO/IEC JTC 1/SC 6 시스템 간 통신 및 정보 교환▷ISO/IEC JTC 1/SC 34 문서 설명 및 처리 언어▷ISO/IEC JTC 1/SC 38 클라우드 컴퓨팅 및 분산 플랫폼▷ISO/IEC JTC 1/SC 40 IT 서비스 관리 및 IT 거버넌스▷ISO/TC 12 수량 및 단위▷ISO/TC 37 언어 및 용어▷ISO/TC 37/SC 5 번역, 통역 및 관련 기술▷ISO/TC 46/SC 4 기술적 상호 운용성▷ISO/TC 154 상업, 산업 및 행정 분야의 프로세스, 데이터 요소 및 문서▷ISO/TC 184/SC 4 산업 데이터▷ISO/TC 211 지리정보/지리학또한 오아시스는 2005년 10월 21일 Working Draft 34에서 Digital Signature Service Core Protocols, Elements, and Bindings Version 1.0을 발표했다.이후 2019년 12월 11일 'Digital Signature Service Core Protocols, Elements, and Bindings Version 2.0 Committee Specification 02'가 발표됐다.버전 2.0의 목차를 살펴보면 다음과 같다.■ 목차(Table of Contents) 1 Introduction 1.1 IPR Policy 1.2 Terminology 1.2.1 Terms and Definitions 1.2.2 Abbreviated Terms 1.3 Normative References 1.4 Non-Normative References 1.5 Typographical Conventions 1.6 DSS Overview (Non-normative) 2 Design Considerations 2.1 Version 2.0 goal [non-normative] 2.2 Transforming DSS 1.0 into 2.0 2.2.1 Circumventing xs:any 2.2.2 Substituting the mixed Schema Attribute 2.2.3 Introducing the NsPrefixMappingType Component 2.2.4 Imported XML schemes 2.2.5 Syntax variants 2.2.6 JSON Syntax Extensions 2.3 Construction Principles 2.3.1 Multi Syntax approach 2.4 Schema Organization and Namespaces 2.5 DSS Component Overview 2.5.1 Schema Extensions 3 Data Type Models 3.1 Boolean Model 3.2 Integer Model 3.3 String Model 3.4 Binary Data Model 3.5 URI Model 3.6 Unique Identifier Model 3.7 Date and Time Model 3.8 Lang Model 4 Data Structure Models 4.1 Data Structure Models defined in this document 4.1.1 Component NsPrefixMapping 4.1.1.1 NsPrefixMapping – JSON Syntax 4.1.1.2 NsPrefixMapping – XML Syntax 4.2 Data Structure Models defined in this document 4.2.1 Component InternationalString 4.2.1.1 InternationalString – JSON Syntax 4.2.1.2 InternationalString – XML Syntax 4.2.2 Component DigestInfo 4.2.2.1 DigestInfo – JSON Syntax 4.2.2.2 DigestInfo – XML Syntax 4.2.3 Component AttachmentReference 4.2.3.1 AttachmentReference – JSON Syntax 4.2.3.2 AttachmentReference – XML Syntax 4.2.4 Component Any 4.2.4.1 Any – JSON Syntax 4.2.4.2 Any – XML Syntax 4.2.5 Component Base64Data 4.2.5.1 Base64Data – JSON Syntax 4.2.5.2 Base64Data – XML Syntax 4.2.6 Component SignaturePtr 4.2.6.1 SignaturePtr – JSON Syntax 4.2.6.2 SignaturePtr – XML Syntax 4.2.7 Component Result 4.2.7.1 Result – JSON Syntax 4.2.7.2 Result – XML Syntax 4.2.8 Component OptionalInputs 4.2.8.1 OptionalInputs – JSON Syntax 4.2.8.2 OptionalInputs – XML Syntax 4.2.9 Component OptionalOutputs 4.2.9.1 OptionalOutputs – JSON Syntax 4.2.9.2 OptionalOutputs – XML Syntax 4.2.10 Component RequestBase 4.2.10.1 RequestBase – JSON Syntax 4.2.10.2 RequestBase – XML Syntax 4.2.11 Component ResponseBase 4.2.11.1 ResponseBase – JSON Syntax 4.2.11.2 ResponseBase – XML Syntax 4.3 Operation requests and responses 4.3.1 Component SignRequest 4.3.1.1 SignRequest – JSON Syntax 4.3.1.2 SignRequest – XML Syntax 4.3.2 Component SignResponse 4.3.2.1 SignResponse – JSON Syntax 4.3.2.2 SignResponse – XML Syntax 4.3.3 Component VerifyRequest 4.3.3.1 VerifyRequest – JSON Syntax 4.3.3.2 VerifyRequest – XML Syntax 4.3.4 Component VerifyResponse 4.3.4.1 VerifyResponse – JSON Syntax 4.3.4.2 VerifyResponse – XML Syntax 4.3.5 Component PendingRequest 4.3.5.1 PendingRequest – JSON Syntax 4.3.5.2 PendingRequest – XML Syntax 4.4 Optional data structures defined in this document 4.4.1 Component RequestID 4.4.1.1 RequestID – JSON Syntax 4.4.1.2 RequestID – XML Syntax 4.4.2 Component ResponseID 4.4.2.1 ResponseID – JSON Syntax 4.4.2.2 ResponseID – XML Syntax 4.4.3 Component OptionalInputsBase 4.4.3.1 OptionalInputsBase – JSON Syntax 4.4.3.2 OptionalInputsBase – XML Syntax 4.4.4 Component OptionalInputsSign 4.4.4.1 OptionalInputsSign – JSON Syntax 4.4.4.2 OptionalInputsSign – XML Syntax 4.4.5 Component OptionalInputsVerify 4.4.5.1 OptionalInputsVerify – JSON Syntax 4.4.5.2 OptionalInputsVerify – XML Syntax 4.4.6 Component OptionalOutputsBase 4.4.6.1 OptionalOutputsBase – JSON Syntax 4.4.6.2 OptionalOutputsBase – XML Syntax 4.4.7 Component OptionalOutputsSign 4.4.7.1 OptionalOutputsSign – JSON Syntax 4.4.7.2 OptionalOutputsSign – XML Syntax 4.4.8 Component OptionalOutputsVerify 4.4.8.1 OptionalOutputsVerify – JSON Syntax 4.4.8.2 OptionalOutputsVerify – XML Syntax 4.4.9 Component ClaimedIdentity 4.4.9.1 ClaimedIdentity – JSON Syntax 4.4.9.2 ClaimedIdentity – XML Syntax 4.4.10 Component Schemas 4.4.10.1 Schemas – JSON Syntax 4.4.10.2 Schemas – XML Syntax 4.4.11 Component IntendedAudience 4.4.11.1 IntendedAudience – JSON Syntax 4.4.11.2 IntendedAudience – XML Syntax 4.4.12 Component KeySelector 4.4.12.1 KeySelector – JSON Syntax 4.4.12.2 KeySelector – XML Syntax 4.4.13 Component X509Digest 4.4.13.1 X509Digest – JSON Syntax 4.4.13.2 X509Digest – XML Syntax 4.4.14 Component PropertiesHolder 4.4.14.1 PropertiesHolder – JSON Syntax 4.4.14.2 PropertiesHolder – XML Syntax 4.4.15 Component Properties 4.4.15.1 Properties – JSON Syntax 4.4.15.2 Properties – XML Syntax 4.4.16 Component Property 4.4.16.1 Property – JSON Syntax 4.4.16.2 Property – XML Syntax 4.4.17 Component IncludeObject 4.4.17.1 IncludeObject – JSON Syntax 4.4.17.2 IncludeObject – XML Syntax 4.4.18 Component SignaturePlacement 4.4.18.1 SignaturePlacement – JSON Syntax
-
KTR의 GCB, 한국 기업에 유럽 CE마크 직접 부여하며 유럽 진출 지원한국화학융합시험연구원(KTR)이 폴란드 바르샤바에 GCB(Global Certification Body)라고 불리는 글로벌 종합 인증기관을 설립하는데 성공했다. GCB는 KTR과 폴란드의 인증컨설팅 기관 MDR Regulator(MDRR)이 합작하여 설립한 기관으로, 현재 KTR이 주요 주주로 참여하고 있다. 현재 유럽 내에서 제품의 CE인증은 매우 필수적이다. 이런 상황에서 GCB 설립을 통해 CE마크를 직접 부여할 수 있게 됐다. 지금까지는 국내 기업들이 유럽 내 CE인증을 위해 협력 관계를 구축해 왔으나, 이번 GCB 설립으로 한국 기업에게 직접 CE마크 부여가 가능해졌다. 이를 통해 언어 장벽과 중복 시험을 줄이고 시간 및 비용 부담을 크게 경감시킬 것으로 기대된다. GCB는 주로 의료기기 CE인증, 탄소중립, 자동차부품 및 소프트웨어 인증을 주력 사업으로 추진하며, 유럽 내 공장 설립을 지원하는 등 한국 기업의 유럽 진출을 촉진하는 것을 목표로 한다. 또한, 기후변화와 탄소중립 정책에 대응할 수 있는 제품 환경평가 및 유럽 배터리법 규제 대응을 제공하며, 한국과 전 세계 기업의 유럽 소프트웨어 산업 진출을 지원한다. 이러한 노력을 통해 GCB는 한국의 글로벌 종합 인증기관으로 자리 잡을 계획이며, 의료기기 CE MDR 기관지정을 완료하고 누적매출을 키우는 등의 성장과 발전을 목표로 하고 있다. 주력 사업 분야 및 가파른 성장을 통해 명실상부한 글로벌 종합 인증기관으로 자리 매김 할 것으로 기대된다.
-
[기획-디지털 ID 표준] ⑫산업단체와 포럼 - 신속 온라인 인증(Fast Identity Online, FIDO)디지털 ID(Digital Identity) 분야에서 상호운용(interoperable)이 가능하고 안전한 서비스 보장을 위한 표준에 대한 수요가 증가하고 있다. 다양한 표준 조직 및 산업 기관이 활동하는 이유다.디지털 ID 표준을 개발하는 곳은 유럽표준화기구(European Standardisation Organistions), 국제표준화기구(International Standardisation Organisations), 상업 포럼 및 컨소시엄, 국가기관 등 다양하다.산업단체와 포럼은 공식적으로 표준화 조직으로 간주되지 않지만 디지털 ID 영역을 포함한 특정 영역에서는 사실상의 표준을 제공하고 있다.몇몇의 경우 이들 단체들이 추가 비준을 위해 자신들이 생산한 사양을 ISO/IEC, ITU 통신 표준화 부문(ITU-T), ETSI 등 표준 기관에 제출할 수 있다.이러한 산업단체 및 포럼에는 △인증기관브라우저 포럼(Certification Authority Browser Forum, CA/Browser Forum) △클라우드 서명 컨소시엄(Cloud Signature Consortium, CSC) △국제자금세탁방지기구(Financial Action Task Force, FATF) △신속온라인인증(Fast Identity Online, FIDO) △국제인터넷표준화기구(Internet Engineering Task Force, IETF) △구조화 정보 표준 개발기구(오아시스)(Organization for the Advancement of Structured Information Standards, OASIS) △오픈ID(OpenID) △SOG-IS(Senior Officials Group-Information Systems Security) △W3C(World Wide Web Consortium) 등이다.신속 온라인 인증(Fast Identity Online, FIDO)은 2013년 2월 출범한 개방형 산업협회다. 전 세계 비밀번호에 대한 과도한 의존을 줄이는 데 도움이 되는 인증 표준을 개발하고 홍보하는 것을 사명으로 삼고 있다.디지털 ID와 관련된 내용은 로밍 인증자와 다른 클라이언트/플랫폼 간 통신을 위한 어플리케이션 계층 프로토콜을 설명하는 클라이언트-인증자 프로토콜(Client to Authenticator Protocol, CTAP)이다.다양한 물리적 매체를 사용해 이 어플리케이션 프로토콜을 다양한 전송 프로토콜에 결합하고 있다. 클라이언트-인증자 프로토콜(Client to Authenticator Protocol, CTAP) 관련 목차를 살펴보면 다음과 같다.목차(table of contents)1. Introduction1.1 Relationship to Other Specifications2. Conformance3. Protocol Structure4. Protocol Overview5. Authenticator API5.1 authenticatorMakeCredential (0x01)5.2 authenticatorGetAssertion (0x02)5.3 authenticatorGetNextAssertion (0x08)5.3.1 Client Logic5.4 authenticatorGetInfo (0x04)5.5 authenticatorClientPIN (0x06)5.5.1 Client PIN Support Requirements5.5.2 Authenticator Configuration Operations Upon Power Up5.5.3 Getting Retries from Authenticator5.5.4 Getting sharedSecret from Authenticator5.5.5 Setting a New PIN5.5.6 Changing existing PIN5.5.7 Getting pinToken from the Authenticator5.5.8 Using pinToken5.5.8.1 Using pinToken in authenticatorMakeCredential5.5.8.2 Using pinToken in authenticatorGetAssertion5.5.8.3 Without pinToken in authenticatorGetAssertion5.6 authenticatorReset (0x07)6. Message Encoding6.1 Commands6.2 Responses6.3 Status codes7. Interoperating with CTAP1/U2F authenticators7.1 Framing of U2F commands7.1.1 U2F Request Message Framing ### (#u2f-request-message-framing)7.1.2 U2F Response Message Framing ### (#u2f-response-message-framing)7.2 Using the CTAP2 authenticatorMakeCredential Command with CTAP1/U2F authenticators7.3 Using the CTAP2 authenticatorGetAssertion Command with CTAP1/U2F authenticators8. Transport-specific Bindings8.1 USB Human Interface Device (USB HID)8.1.1 Design rationale8.1.2 Protocol structure and data framing8.1.3 Concurrency and channels8.1.4 Message and packet structure8.1.5 Arbitration8.1.5.1 Transaction atomicity, idle and busy states.8.1.5.2 Transaction timeout8.1.5.3 Transaction abort and re-synchronization8.1.5.4 Packet sequencing8.1.6 Channel locking8.1.7 Protocol version and compatibility8.1.8 HID device implementation8.1.8.1 Interface and endpoint descriptors8.1.8.2 HID report descriptor and device discovery8.1.9 CTAPHID commands8.1.9.1 Mandatory commands8.1.9.1.1 CTAPHID_MSG (0x03)8.1.9.1.2 CTAPHID_CBOR (0x10)8.1.9.1.3 CTAPHID_INIT (0x06)8.1.9.1.4 CTAPHID_PING (0x01)8.1.9.1.5 CTAPHID_CANCEL (0x11)8.1.9.1.6 CTAPHID_ERROR (0x3F)8.1.9.1.7 CTAPHID_KEEPALIVE (0x3B)8.1.9.2 Optional commands8.1.9.2.1 CTAPHID_WINK (0x08)8.1.9.2.2 CTAPHID_LOCK (0x04)8.1.9.3 Vendor specific commands8.2 ISO7816, ISO14443 and Near Field Communication (NFC)8.2.1 Conformance8.2.2 Protocol8.2.3 Applet selection8.2.4 Framing8.2.4.1 Commands8.2.4.2 Response8.2.5 Fragmentation8.2.6 Commands8.2.6.1 NFCCTAP_MSG (0x10)8.2.6.2 NFCCTAP_GETRESPONSE (0x11)8.3 Bluetooth Smart / Bluetooth Low Energy Technology8.3.1 Conformance8.3.2 Pairing8.3.3 Link Security8.3.4 Framing8.3.4.1 Request from Client to Authenticator8.3.4.2 Response from Authenticator to Client8.3.4.3 Command, Status, and Error constants8.3.5 GATT Service Description8.3.5.1 FIDO Service8.3.5.2 Device Information Service8.3.5.3 Generic Access Profile Service8.3.6 Protocol Overview8.3.7 Authenticator Advertising Format8.3.8 Requests8.3.9 Responses8.3.10 Framing fragmentation8.3.11 Notifications8.3.12 Implementation Considerations8.3.12.1 Bluetooth pairing: Client considerations8.3.12.2 Bluetooth pairing: Authenticator considerations8.3.13 Handling command completion8.3.14 Data throughput8.3.15 Advertising8.3.16 Authenticator Address Type9. Defined Extensions9.1 HMAC Secret Extension (hmac-secret)10. IANA Considerations10.1 WebAuthn Extension Identifier Registrations11S ecurity ConsiderationsIndexTerms defined by this specificationTerms defined by referenceReferencesNormative ReferencesInformative ReferencesIDL Index
-
[특집-ISO 2023 연례회의] ⑭3일차 : 지속가능성 및 무역(Sustainability and trade)지난 9월18~22일 5일간 2023 ISO 연례회의(Annual Meeting)가 오스트레일리아 브리즈번(Brisbane)에서 개최됐다. 올해 국제표준화기구(International Organization for Standardization, ISO)가 개최한 연례회의 에디션의 주제는 '글로벌 니즈 충족(Meeting global needs)'이다.1주일 동안 개최된 연례회의는 오늘날 지구가 직면한 가장 시급한 문제에 대해 건설적인 대화에 참여할 수 있는 기회를 제공하고 참가자들이 협력 솔루션을 찾을 기회를 제공하는 것이다.연례 회의는 다양한 정부, 업계 및 시민단체 대표 뿐 아니라 ISO 커뮤니티 전문가와 리더가 가장 큰 트렌드 및 과제에 대해 생각을 공유하기 위한 목적으로 참여했다.이번 회의는 인공지능(Artificial intelligence), 순환경제(Circular economy), 청정 에너지(Clean energy), 사이버보안(Cybersecurity), 스마트 농업(Smart farming) 등을 중심으로 논의가 진행됐다.3일차 연례회의의 주제는 지속 가능성과 무역(Sustainability and trade) 이다. 이날 연례회의는 △정책 분야 표준(Standards in policy) △도시를 탄력적으로 만들기(Making cities resilient) △지속 가능성을 위한 동맹 구축(Forging alliances for sustainability) △무역에 대한 신뢰(Trust in trade) △고객 경험(The customer experience) 등을 중심으로 토론이 이뤄졌다.3일차 도시를 탄력적으로 만들기(Making cities resilient)라는 세션은 불확신한 세상에서의 회복력 구축에 대해 심도 있는 토론이 진행됐다.이번 세션은 10:00~11:00까지 개최됐으며 참석 패널은 찬탈 가이(Chantal Guay, 캐나다 표준 위원회 CEO), 쉬울리 고쉬(Shiulie Ghosh, Aero Production Ltd.의 국제 저널리스트 겸 진행자), 콜린 시발링검(Collin Sivalingum, 오스트레일리아 적십자사 주 응급 서비스 관리자), 벡 도슨(Beck Dawson, 시드시 시 최고 복원력 책임자), 앨리슨 드루리(Alison Drury, 오스트레일리아 연방 정부 산업·과학·에너지 및 자원부(DISR) 무역 및 국제 부서 총괄 관리자), 키리 아타에라(Kiri Ataera, 기획 및 프로젝트 국장, 인프라부) 등이다.패널리스트들은 21세기 도시를 지속 가능하고 탄력적이며 안전하게 만드는데 있어 협력의 중요성과 표준의 중요한 역할에 대해 논의했다.또한 불확실한 세상에서 표준이 집단적 문제를 해결하고 끊임없이 진화하는 미래를 자신감 있게 수용하기 위한 탄력성의 토대라는 개념을 재확인하는 계기가 됐다.전문가들은 표준이 문제, 목표, 우선순위에 대한 명확한 비전을 제공하는 필수 도구 역할을 하는 다각적인 방식을 탐구했다. 도시 중심을 더욱 탄력적으로 만들기 위해 주요 행위자 간 단결된 노력과 행동이 필요하다는 것이다.전례 없는 도전으로 얼룩진 세계에서 도시를 더욱 안전하고 탄력적으로 만드는 표준의 변혁적 잠재력 뿐 아니라 표준이 혁신, 준비, 발전을 위한 역동적인 도구라는 사실을 재확인했다.특히 도시가 성장함에 따라 2050년 전 세계 인구의 약 70%가 도시 지역에 거주할 것으로 예상된다. 지속적으로 도시가 성장함에 따라 생명, 생계, 경제적 자산의 노출은 기하급수적으로 증가할 가능성이 높아졌다.
-
[특집-ISO 2023 연례회의] ⑫2일차 : 기술 및 혁신(Tech & innovation) - 기술 융합 활용(Harnessing tech convergence)지난 9월18~22일 5일간 2023 ISO 연례회의(Annual Meeting)가 오스트레일리아 브리즈번(Brisbane)에서 개최됐다. 올해 국제표준화기구(International Organization for Standardization, ISO)가 개최한 연례회의 에디션의 주제는 '글로벌 니즈 충족(Meeting global needs)'이다.1주일 동안 개최된 연례회의는 오늘날 지구가 직면한 가장 시급한 문제에 대해 건설적인 대화에 참여할 수 있는 기회를 제공하고 참가자들이 협력 솔루션을 찾을 기회를 제공하는 것이다.연례 회의는 다양한 정부, 업계 및 시민단체 대표 뿐 아니라 ISO 커뮤니티 전문가와 리더가 가장 큰 트렌드 및 과제에 대해 생각을 공유하기 위한 목적으로 참여했다.이번 회의는 인공지능(Artificial intelligence), 순환경제(Circular economy), 청정 에너지(Clean energy), 사이버보안(Cybersecurity), 스마트 농업(Smart farming) 등을 중심으로 논의가 진행됐다.2일차 연례회의의 주제는 기술 및 혁신(Tech & Innovation) 이다. 이날 연례회의는 △가장 큰 위험 중 사이버 공격(Cyber-attacks among biggest risks) △세대 충돌(Clash of the generations) △AI 가속화(Accelerating AI) △음식물쓰레기 퇴치(Fighting food waste) △대규모 수소 보급을 위한 표준(Standards for large-scale hydrogen rollout) △플라스틱 오염에 함께 대처하기(Tackling plastic pollution together) △기술 융합 활용(Harnessing tech convergence) 등을 중심으로 토론이 이뤄졌다.2일차 기술 융합 활용(Harnessing tech convergence) 세션은 선도적인 기술 전문가들이 모여 기술 융합의 복잡한 환경을 탐색하는데 있어 표준의 중추적 역할을 토론했다.또한 스마트 도시, 스마트 제조, 몰입형 기술 등을 포함해 조직이 디지털 혁신의 무한한 가능성을 수용할 수 있는 표준의 강화 방법에 대해 토론했다.이번 세션은 마이클 멀퀸(Michael Mulquin, 아이에스커뮤니케이션 대표), 필 웬블롬(Phil Wennblom), iso/iec jtc 1, 인텔 정보 기술 및 표준 정책 글로벌 이사), 안토니오 쿵(antonio kung, 트라이로그 공동 창업자이자 CEO), 딩루(ding lu, WG1 iec sys 스마트 제조 컨비너, 계측기 기술 및 경제 연구소 이사), 몰리 레셔(molly Lesher, OECD 디지털 정책, 경제 및 측정 부서 책임자) 등이 참석했다.디지털 혁신이 진행과 더불어 표준은 진화하는 기술 환경에 발맞춰 적응해야 된다. 디지털 추세에 맞춰 기업, 정부, 사회 전반이 기술의 잠재력을 최대한 활용하고 빠르게 변화하는 세계에 위험을 최소화 하는 등 혁신을 촉진하도록 보장해야 된다.따라서 혁신적인 사고 방식을 채탱해야 기술 융합과 안전, 풍요로운 미래를 위한 표준을 제공할 수 있다. 표준 조직은 표준 개발 방식에 대한 새로운 접근 방식을 고려해야 된다.▲ 기술 융합 세션에 참석한 패널들 [출처 = ISO]
-
해썹인증원-한국전력공사, 주니어보드 교류 회의 개최한국식품안전관리인증원(해썹인증원)은 23일 충북 청주 본원에서 한국전력공사 주니어보드와 합동으로 조직문화 혁신 및 확산을 위한 교류 회의를 개최했다고 24일 밝혔다. 해썹인증원은 경영진과 MZ세대 직원 간의 소통 채널 구축과 조직문화 개선 등 경영혁신을 위해 ‘주니어보드’를 도입해 올해로 4년차를 맞이했다. 주니어보드란, 준견 간부인 과장급 이하의 직원들로 구성된 청년중역회의를 말한다. 중역회의나 이사회 등의 중요 정책결정에 앞서 건의사항이나 보완사항 등을 제안 및 토의하게 하는 제도다. 특히 올해는 기관 내부의 주니어보드 운영에서 나아가 혁신 네트워크 구축을 위한 외부 기관과의 정기 교류 회의를 실시하고 있으며 지난 8월 ‘서울대학교’와 1차 교류 회의에 이어서 이번 ‘한국전력공사’와 2차 교류 회의를 추진하게 됐다. 당일 두 기관의 주니어보드는 ‘조직문화 혁신’을 주제로 자유롭게 의견을 나누고 해썹인증원 본원 1층에 위치한 해썹체험관을 견학하는 시간을 가졌다. 당일 참석한 이미지 한국전력공사 노사협력처 차장은 “양 기관의 기업문화 개선 우수사례를 공유하고 우리나라 식품 안전을 책임지고 있는 HACCP 주니어보드와 새로운 조직문화 혁신 아이디어를 발굴하는 뜻깊은 시간이었다”고 밝혔다. 라정한 전략기획본부장은 “주니어보드 교류 회의는 내부 소통에서 나아가 외부 기관과 그 성과를 공유하고 의견을 나누는데 큰 의미”라며 “회의를 통해 공유된 아이디어가 우리원 경영혁신으로 이어질 수 있도록 최선을 다하겠다”고 말했다.
-
해썹인증원, ‘안전관리 우수연구실 인증제’에서 인증 추가 획득안전관리 수준 및 활동이 우수한 연구실에 대한 인증으로 국내 연구실의 안전관리 역량이 강화될 전망이다. 한국식품안전관리인증원(해썹인증원)은 과학기술정보통신부가 주관하는 ‘안전관리 우수연구실 인증제’에서 ‘미생물 실험실’ 인증을 추가 획득함에 따라 24일 현판식을 가졌다고 밝혔다. 해썹인증원은 ‘식품·의약품분야 시험·검사 등에 관한 법률’에 따른 식품 및 축산물 시험·검사기관으로 지난해 ‘이화학 실험실’에 대한 안전관리 우수연구실 최초 인증에 이어 올해 ‘미생물 실험실’ 분야를 추가로 획득하며 운영하는 전체 연구실에 대한 안전관리 역량을 인정받게 됐다. ‘안전관리 우수연구실’은 과기정통부가 국내 대학·연구기관 등의 연구실 안전관리 역량을 강화하고 안전관리 표준모델을 발굴 및 확산하기 위해 안전관리 수준 및 활동이 우수한 연구실에 대해 인증을 부여하는 제도다. 인증을 위해서는 ▲안전환경 시스템(30점) ▲활동수준(50점) ▲안전관리 관계자 안전의식(20점) 세가지 심사 분야에서 각각 80% 이상을 획득해야 하며 안전관리 전문가 현장 심사와 산·학·연 전문가 인증 심의를 거친 뒤에 안전관리 우수연구실로 인증 받게 된다. 해썹인증원 관계자는 “연구실 안전강화를 위해 안전경영 방침을 제정하고 안전환경 시스템을 구축하는 등 체계적인 안전관리 활동을 지속 전개해왔다”며 “특히 정밀안전진단, 내부심사 등에 대한 개선 및 환류 활동을 적극적으로 실행하고 안전교육 훈련을 강화하였고 이번 인증 과정에서도 이러한 부분을 높게 평가 받아 최종 인증까지 이어질 수 있었다”고 전했다. 홍진환 인증사업이사는 “해썹인증원은 연구활동 구성원의 안전을 최우선으로 생각하고 ESG 경영 실천에 앞장서고 있다”며 “앞으로도 연구실 안전환경시스템 구축에 대한 경험을 관계기관에 적극 공유하는 등 식품안전관리 전문기관으로서 최선을 다하겠다”고 말했다.