검색결과
-
[기획-디지털 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 11671397)미국 데이터 분석 기업 아웃리드스(Outleads)에 따르면 2023년 6월6일 '오프라인 데이터와 온라인 활동을 연관시키기 위한 시스템(System for associating offline data with online activity)' 명칭의 미국 특허(US 11671397)가 등록됐다.본 등록 특허는 미국 모출원 특허(US 9137360) 및 분할출원 특허(US 10798046)를 기초로 2020년 10월6일 계속 출원(US 17/064394)된 후 미국 특허청에 의해 심사를 받았다.미국 모출원 특허(US 9137360)는 2013년 10월25일 가출원(US 61/895544)된 후 2014년 10월27일 본출원(US 14/524949)되어 2015년 9월15일 등록됐다.본 등록 특허의 패밀리 특허로서 이스라엘 특허(IL 245269, IL 252867), 브라질 특허(BR 112016009199, BR 112017013138)가 심사 중이다. 캐나다 특허(CA 2927971), 미국 특허(US 9342843, US 9491249, US 9762529, US 10218666, US 10523627, US 10798046)이 등록됐다.본 등록 특허는 외부 컴퓨터 시스템에서 생성되고 제공된 고유 식별자와 데이터 파일을 연관시켜 데이터를 수집하고 인덱싱하기 위한 시스템에 대한 특허이다.본 등록 특허의 일 실시예에 따르면 데이터 파일은 사용자 조작 컴퓨터 시스템으로부터 획득된다. 컴퓨터 시스템은 네트워크를 통해 서로 신호 통신에 제공된 일련의 컴퓨터를 포함한다.데이터 파일은 웹 서버에 의해 호스팅된 웹 사이트에 의해 제공된 형태에 의해 수집된 데이터를 포함할 수 있다. 에이전트에 의해 동작되는 컴퓨터 시스템과 같은 다른 소스에서 수집된 추가 데이터는 문의 관리회사가 수집한 데이터 파일과 연관된다.수집된 데이터 및 관련 레코드는 온라인 사용자/방문자를 추적하는 컴퓨터 시스템으로 전달된다. 프로세스는 웹 사이트 활동에 대한 컴퓨터 수집된 데이터를 웹 사이트와 독립적인 활동으로 표시할 수 있다.
-
식약처, 의료기기 안전사고 대응 위해 ‘재난 대응 안전한국 훈련’ 실시식품의약품안전처는 식품·의약품 등 안전사고 발생 시 신속한 대응으로 위기 확산을 방지하고 의료기기 안전사고 위기대응 체계를 점검하기 위해 1일 충북 오송 소재 식품의약품안전처와 인천 송도 소재 ㈜아이센스송도공장에서 ‘2023년 재난 대응 안전한국훈련’을 실시했다고 밝혔다. 재난 대응 안전한국훈련은 ‘재난 및 안전관리 기본법’ 제35조(재난대비훈련 실시)에 근거해 매년 중앙부처, 지자체, 공공기관 총 335개 기관이 소관 재난 및 위기에 대비하는 훈련이다. 이번 훈련은 당뇨환자가 사용하는 디지털 의료기기 오작동 사고로 인한 인명 피해 발생 상황을 가정하여 식품·의약품 등 안전사고 주요 상황 대응 매뉴얼에 따라 진행했다. 특히 올해는 무허가 소프트웨어 유포 등 디지털의료기기의 사이버보안 위협에 대응하는 훈련을 처음으로 실시했으며 영상 시스템을 활용해 위기 수준 평가 등을 위한 토론훈련과 제조사 생산라인 점검 등 현장훈련을 통합하여 진행했다. 주요 훈련 내용은 ▲안전사고 상황점검 및 전파 ▲위기단계 결정 및 비상대응기구 구성·운영 ▲유통·수급 관리 및 안전성 정보 제공 등 대응 조치 ▲유관기관 협력 체계 가동 ▲사이버보안 분야 강화 후속대책 논의 등이다. 훈련에는 행정안전부, 과학기술정보통신부 등 중앙행정기관을 비롯해 의료기기 부작용 관련 정보를 수집·분석하는 한국의료기기안전정보원과 사이버보안 전문기관인 한국인터넷진흥원 등이 참가했으며, 국민체험단이 위기 상황 발생부터 훈련 평가까지 전 과정에 참여했다. 국민체험단은 안전한국훈련에 대한 국민 관심과 이해도를 높이고 다양한 의견을 반영해 훈련기관의 재난대응 역량을 향상시키고자 기관별 모집(10명 내외)・운영한다. 이번 훈련으로 식품·의약품 안전 관련 위기 발생 시 초기에 진화할 수 있는 대응체계를 구축·운영해 국민이 안심하고 식품·의약품 등을 소비할 수 있는 환경이 조성될 전망이다. 오유경 처장은 “이번 훈련은 디지털전환 시대에 발맞춰 디지털헬스 분야 위기대응 체계를 구축하고 사이버보안 안전관리 강화를 위해 처음으로 실시했다는 점에서 큰 의미가 있다”며 “식약처는 기술 발전 등 급변하는 환경 속에서 새로운 위기 상황 발생에 대비해 유관기관과 긴밀한 협력 체계를 지속적으로 유지하겠다”고 전했다.
-
혁신기술에 기반한 새로운 서비스, 국제표준으로 해외시장 진출 발판 마련산업통상자원부 국가기술표준원(원장 진종욱)은 첨단기술과 융합한 새로운 서비스 분야의 국제표준을 선점하여 우리 기업의 해외시장 진출을 지원한다. 팬데믹 시기를 지나면서 정보통신‧로봇‧보안 등 첨단기술의 급속한 발전과 함께 이에 기반한 서비스 시장도 성장하고 있다. 이에 국가기술표준원은 우리 업계의 기술력과 시장환경을 고려하여 ▲하이브리드 미팅, ▲교육용 메타버스, ▲병원 로봇 물류, ▲스마트홈 기기(고령자 편의), ▲주거시설 범죄예방, ▲무인사업장 등에 적용되는 서비스의 국제표준화를 선제적으로 추진 중이다. 국가기술표준원은 11.1.(수), 산학연 전문가가 참석한 「융합서비스표준오픈포럼」 계기에 융합서비스 분야에 대한 국제표준화 활동 성과를 공유하고, 진행 중인 표준화 과제에 대한 추진 전략 등을 논의하였다. * 융합서비스표준오픈포럼(회장 - 이학성 LS일렉트릭 고문) : IT 등 첨단기술과 융합한 서비스 표준화 수요에 대응하기 위해 2020년부터 산‧학‧연 전문가로 구성‧운영 중 이와 같은 혁신기술과 융합한 서비스의 표준은 새로운 시장의 창출 및 확장은 물론, 국민 편익 증진과 안전성 확보에도 기여할 것으로 기대된다. 오광해 표준정책국장은 “첨단산업에서 서비스 표준은 신(新)기술의 사업화와 신(新)시장의 창출을 앞당기는 촉매로, 기술 변화와 시장 수요를 고려한 지속적인 표준화 활동을 통해 우리 기업의 기술 혁신과 세계시장 진출을 위해 적극 지원하겠다”고 말했다.
-
성별 응답형 표준, 기술표준과 성별 간 상호작용에 집중하다성별은 기술 표준 개발에 중요한 고려 사항으로 등장하고 있다. UL Standards & Engagement의 국제 표준 이사인 Sonya Bird는 성별 응답형 표준 공동 전략 자문 위원회의 창립 멤버 중 한 명이다. 그녀는 성별이 표준의 안전과 사용자 평등에 어떻게 영향을 미치는지에 대해 의견을 남겼다. 모든 표준은 사용자의 안전을 지키기 위해 모든 성별에 적용 가능해야 한다. 이를 위해 성별 응답형 표준이 필요하다. 이는 신체적 차이부터 사회적 및 문화적 측면까지 다양한 영향을 측정하고 고려하기 때문이다. 현재 IEC와 ISO는 UN의 지속가능한 개발 목표(SDG)를 달성하기 위해 헌신하고 있으며, 성별을 표준 개발에 고려하는 것이 SDG 5 달성에 기여할 수 있다고 말한다. 구체적으로 전기기술 분야에서도 성별은 중요한 역할을 한다. 예를 들어, 무선 통신 장치의 무선 주파수에 노출되는 인체의 특정 흡수율(SAR)을 평가하는 IEC 62209-3의 새로운 표준은 여성과 남성 모형을 활용하여 테스트되었다. 일부 전문가들은 전기기술 분야에서 성별 차이가 미미하다고 주장하지만, 모든 표준에서 성별 관련 영향을 확인하는 것은 결코 무시될 수 없는 중요한 요소가 되어가고 있다. Sonya Bird는 모든 표준 개발자들은 성별 응답형 표준을 개발하는데 기여해야 한다며 의견을 덧붙였다.
-
[기획-디지털 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
-
ETRI, 노코드 기계학습(MLOps) 개발도구 오픈소스로 공개 및 깃허브 커뮤니티 확산한국전자통신연구원(이하 ETRI)이 노코드 기계학습(MLOps) 개발도구 TANGO 프레임워크를 오픈소스로 공개했다. 이는 깃허브 커뮤니티를 통해 확산되며 국내 산업 현장의 인공지능 기술 수요를 충족시킬 것으로 전망된다. ETRI는 과학기술정보통신부(이하 과기정통부)와 정보통신기획평가원(이하 IITP)의 지원을 받아 개발한 노코드 기계학습 개발도구(MLOps)의 핵심기술을 오픈소스로 공개하고, 깃허브 커뮤니티 확산을 위한 공개 세미나를 1일 과학기술회관에서 개최한다고 밝혔다. ETRI 연구진은 2021년부터 공장, 의료 등 산업 분야에서 인공지능 전문지식이 부족한 사용자들도 노코드 기반으로 신경망을 자동생성하고 배포 과정까지 자동화하는 탱고(TANGO) 프레임워크를 개발하고 있으며, 작년부터 핵심기술을 오픈소스로 공개하고 있다. 탱고 프레임워크란 인공지능이 적용된 응용SW를 자동으로 개발하고, 클라우드, 쿠버네티스 엣지 환경, 온디바이스 등 다양한 디바이스 HW 환경에 맞게 최적화하여 배포해주는 기술이다. 기존의 인공지능 응용SW 개발방식은 데이터 라벨링은 도메인 전문가가 담당하고, 인공지능 모델 개발·학습 및 응용SW의 설치·실행은 SW개발자가 직접 하는 구조였다. 인공지능 기술의 확산과 함께 전 산업에서 소프트웨어에 대한 수요가 높아지고 있지만, 이러한 수요를 충족시킬 인공지능·소프트웨어 전문가는 부족한 상황이다. 최근 이러한 문제를 개선하고자 인공지능 응용SW 개발·배포를 자동화하기 위한 연구가 아마존, 구글, 마이크로소프트 등 글로벌 업체를 중심으로 시작되었으나, 자사의 서비스 환경만을 위한 개발환경을 제공하여 국내 산업 현장의 다양한 HW를 지원하기는 어려운 점이 있었다. ETRI는 이와 같은 국내 산업 현장의 수요를 반영, 객체 인식에 최적화된 신경망 자동화 개발 알고리즘을 개발하고 있다. 특히 의료·스마트 공장 등 산업 현장에서 실제 활용할 수 있도록 데이터 라벨링, 인공지능 모델 생성, 인공지능 학습 및 응용SW 배포 전 과정에 대한 최적화, 자동화도 지원한다. ETRI는 “탱고 프레임워크를 적극적으로 공개하고, 산업체·학계·커뮤니티 등과 협력, 공동 개발해 빠르게 기술 상용화할 예정이다. 앞으로도 매년 반기별로 새로운 버전의 소스코드를 깃허브로 공개할 것이며 연 1회 하반기에는 공개 세미나를 개최, 기술을 공유할 계획이다”라고 전했다.
-
TTA, 세계 최초 차량용 모바일 디지털 키 국제공인시험기관 자격 획득한국정보통신기술협회(TTA, 회장 손승현)는 지난 10월 26일 `자동차 연결 컨소시엄(CCC: Car Connectivity Consortium)`으로부터 세계 최초로 차량용 모바일 디지털 키(이하 디지털 키) 기술에 대한 국제 공인시험기관 자격을 인정받아 시험서비스를 제공한다고 밝혔다. CCC는 스마트폰과 차량간 연결을 활용해 사용자 편의 솔루션 개발을 주도하고 있는 단체로 국내외 주요 차량 제조사와 스마트폰 제조사 등 380여 개 사가 참여하여 디지털 키 규격 및 인증 프로그램을 개발해 왔다. 디지털 키는 스마트폰과 차량 간 비접촉식 무선통신을 통해 차량의 물리적인 키를 대신하는 기술이다. 단순히 문을 열고 시동을 거는 동작 외에도 키 공유와 회수, 히터나 에어컨 설정, 차량 위치추적 등 다양한 활용이 가능하기 때문에 개인 차량뿐 아니라 렌터카 등 차량 공유서비스 용도로도 주목받고 있다. 최근 국내 및 해외 차량 제조사는 삼성전자, 구글, 애플과의 협업을 통해 디지털 키의 성능과 편의성을 크게 향상시키는 등 기술 고도화와 서비스 확산에 주력하고 있다. 이번 CCC의 디지털 키 국제공인 시험소 승인은 전 세계에서 TTA가 유일하다. 이에 따라 디지털 키를 적용한 국내외 기업들은 인증획득을 통해 다양한 차종과 스마트폰 간 호환성 확보 및 서비스 출시가 용이해질 것으로 기대된다. 또한 TTA는 디지털 키의 기반 기술인 NFC, 블루투스, UWB(초광대역무선통신) 국제공인 시험서비스도 제공 중으로 이와 연계한 원스톱 인증 서비스가 가능해졌다. TTA는 시험인증을 통해 디지털 키 기술의 신뢰성과 호환성을 향상시켜 관련 산업의 활성화 및 국내 기업의 경쟁력 강화를 위해 적극 지원하겠다고 밝혔다.
-
[기획-디지털 ID 표준] ⑬산업단체와 포럼 - 국제인터넷표준화기구(IETF)디지털 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) 등이다.국제인터넷표준화기구(Internet Engineering Task Force, IETF)는 1986년 설립됐다. 인터넷 관련 표준 개발 기구(standards development organization, SDO)다.IETF는 인터넷 사용자, 네트워크 운영자, 장비 공급업체가 자주 채택하는 자발적인 표준을 만들어 인터넷 개발 궤적을 형성하는데 도움을 주고 있다.특히 IETF가 발행한 대부분의 의견 요청(requests for comments, RFCs)은 데이터 교환(data exchanges) 및 형식(formats)을 다루고 있으며 전자 서명(electronic signatures), PKI, 신뢰 서비스 분야 구성요소로 간주되고 있다.
-
[기획-디지털 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