검색결과
-
[일본] 경제산업성(経済産業省), 2030년 차세대자동차인 'SDV(Software Defined Vehicle)'의 글로벌 시장 점유율을 30% 달성할 계획일본 경제산업성(経済産業省)에 따르면 2030년 차세대자동차인 'SDV(Software Defined Vehicle)'의 글로벌 시장 점유율을 30% 달성할 계획이다.2030년 글로벌 SDV 시장의 규모는 최대 4100만 대로 전망되므로 일본계 자동차제조업체가 1200만 대를 공급하겠다는 구상이다.2035년까지 세계 DSV 시장의 규모는 6400만 대로 성장할 것으로 예상됨에 따라 일본계 기업이 1900만 대를 점유하겠다는 의지를 피력했다.특히 자동차산업은 일본경제를 뒷받침하는 핵심 산업이지만 전기자동차(EV)의 보급 확대, 자율주행기술의 개발, 자동차의 디지털화에서는 미국, 중국 등에서 뒤쳐지고 있다는 평가를 받는다.도요타자동차, 닛산자돛아, 혼다 등 자동차 3사는 소프트웨어를 연결하는 기반 부문의 공통화를 위한 연구를 시작했다. 자체적으로 개발한 소프트웨어를 연계하고 자동차용 고성능 반도체의 연구개발도 협력한다.또한 자동차의 제조부터 이용, 폐기까지 일련의 생명주기에서 생성된 데이터를 활용하는 전략도 연구 중이다. 2025년 이후 수집한 데이터를 공유해 재해시의 상황 파악, 공급망의 체질 개선 등을 도모한다.참고로 SDV는 '소프트웨어 중심 자동차'로 스마트폰처럼 인터넷을 통해 소프트웨어를 업데이트해 성능을 향상시킬 수 있는 차세대 자동차를 말한다.
-
[특집-기술위원회] TC 209 - 클린룸 및 관련 제어 환경(Cleanrooms and associated controlled environments)스위스 제네바에 본부를 두고 있는 국제표준화기구(ISO)에서 활동 중인 기술위원회(Technical Committeee, TC)는 TC 1~TC 323까지 구성돼 있다.기술위원회의 역할은 기술관리부가 승인한 작업범위 내 작업 프로그램 입안, 실행, 국제규격의 작성 등이다. 또한 산하 분과위원회(SC), 작업그룹(WG)을 통해 기타 ISO 기술위원회 또는 국제기관과 연계한다.ISO/IEC 기술작업 지침서 및 기술관리부 결정사항에 따른 ISO 국제규격안 작성·배포, 회원국의 의견 편집 등도 처리한다. 소속 분과위원회 및 작업그룹의 업무조정, 해당 기술위원회의 회의 준비도 담당한다.1947년 최초로 구성된 나사산에 대한 TC 1 기술위원회를 시작으로 순환경제를 표준화하기 위한 TC 323까지 각 TC 기술위원회의 의장, ISO 회원, 발행 표준 및 개발 표준 등에 대해 살펴볼 예정이다.이미 다룬 기술위원회와 구성 연도를 살펴 보면 △1947년 TC 1~67 △1948년 TC 69 △1949년 TC 70~72 △1972년 TC 68 △1950년 TC 74 △1951년 TC 76 △1952년 TC 77 △1953년 TC 79, TC 81 △1955년 TC 82, TC 83 △1956년 TC 84, TC 85 △1957년 TC 86, TC 87, TC 89 △1958년 TC 91, TC 92 △1959년 TC 94 △1960년 TC 96, TC 98 △1961년 TC 101, TC 102, TC 104 등이다.또한 △1962년 TC 105~107 △1963년 TC 108~111 △1964년 TC 112~115, TC 117 △1965년 TC 118 △1966년 TC 119~122 △1967년 TC 123 △1968년 TC 126, TC 127 △1969년 TC 130~136 △1970년 TC 137, TC 138, TC 142, TC 145 △1971년 TC 146~150, TC 153 △1972년 TC 154 △1973년 TC 155 △1974년 TC 156~161 △1975년 TC 162~164 등도 포함된다.그리고 △1976년 TC 165, TC 166 △1977년 TC 167, TC 168, TC 170 △1978년 TC 171~174 △1979년 TC 176, TC 178 △1980년 TC 180, TC 181 △1981년 TC 182 △1983년 TC 183~186 △1984년 TC 188 △1985년 TC 189~191 △1988년 TC 192~194 △1989년 TC 195 △1990년 TC 197, TC 198 △1991년 TC 199, TC 201, TC 202 △1992년 TC 204~206 등이 있다.ISO/TC 209 클린룸 및 관련 제어 환경(Cleanrooms and associated controlled environments)과 관련된 기술위원회는 TC 207과 마찬가지로 1993년 결성됐다. 사무국은 미국 표준협회(American National Standards Institute, ANSI)에서 맡고 있다.위원회는 로버트 미엘케(Mr Robert Mielke)가 책임지고 있다. 현재 의장은 고든 엘리(Mr Gordon Ely)이며 임기는 2026년말까지다. ISO 기술 프로그램 관리자는 마호 타카하시(Mme Maho Takahashi), ISO 편집 관리자는 아룬 ABY 파라에카틸(Mr Arun ABY Paraecattil) 등이다.범위는 시설, 지속 가능성, 장비, 프로세스 및 운영과 관련된 기타 속성 및 특성 뿐 아니라 청결도를 제어하기 위한 클린룸 및 관련 제어 환경에 대한 표준화다.현재 ISO/TC 209 사무국의 직접적인 책임 하에 발행된 표준은 20개며 ISO/TC 209 사무국의 직접적인 책임 하에 개발 중인 표준은 3개다. 참여하고 있는 회원은 26개국, 참관 회원은 22개국이다.□ ISO/TC 209 사무국의 직접적인 책임 하에 발행된 표준 20개 중 15개 목록▷ISO 14644-1:2015 Cleanrooms and associated controlled environments — Part 1: Classification of air cleanliness by particle concentration▷ISO 14644-2:2015 Cleanrooms and associated controlled environments — Part 2: Monitoring to provide evidence of cleanroom performance related to air cleanliness by particle concentration▷ISO 14644-3:2019 Cleanrooms and associated controlled environments — Part 3: Test methods▷ISO 14644-4:2022 Cleanrooms and associated controlled environments — Part 4: Design, construction and start-up▷ISO 14644-5:2004 Cleanrooms and associated controlled environments — Part 5: Operations▷ISO 14644-7:2004 Cleanrooms and associated controlled environments — Part 7: Separative devices (clean air hoods, gloveboxes, isolators and mini-environments)▷ISO 14644-8:2022 Cleanrooms and associated controlled environments — Part 8: Assessment of air cleanliness by chemical concentration (ACC)▷ISO 14644-9:2022 Cleanrooms and associated controlled environments — Part 9: Assessment of surface cleanliness for particle concentration▷ISO 14644-10:2022 Cleanrooms and associated controlled environments — Part 10: Assessment of surface cleanliness for chemical contamination▷ISO 14644-12:2018 Cleanrooms and associated controlled environments — Part 12: Specifications for monitoring air cleanliness by nanoscale particle concentration▷ISO 14644-13:2017 Cleanrooms and associated controlled environments — Part 13: Cleaning of surfaces to achieve defined levels of cleanliness in terms of particle and chemical classifications▷ISO 14644-14:2016 Cleanrooms and associated controlled environments — Part 14: Assessment of suitability for use of equipment by airborne particle concentration▷ISO 14644-15:2017 Cleanrooms and associated controlled environments — Part 15: Assessment of suitability for use of equipment and materials by airborne chemical concentration▷ISO 14644-16:2019 Cleanrooms and associated controlled environments — Part 16: Energy efficiency in cleanrooms and separative devices▷ISO 14644-17:2021 Cleanrooms and associated controlled environments — Part 17: Particle deposition rate applications□ ISO/TC 209 사무국의 직접적인 책임 하에 개발 중인 표준 3개 목록▷ISO/AWI 14644-5 Cleanrooms and associated controlled environments — Part 5: Operations▷ISO/CD TS 14644-19 Cleanrooms and associated controlled environments — Part 19: General technical requirements of modular isolation units for emergency medical use▷ISO/AWI 14644-20 Cleanrooms and associated controlled environments — Part 20: Microbiological contamination control
-
[기획-디지털 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
-
[기획-디지털 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/TC 52 기술위원회(Technical Committees) 소개스위스 제네바에 본부를 두고 있는 국제표준화기구(ISO)에서 활동 중인 기술위원회(Technical Committeee, TC)는 TC1~TC323까지 구성돼 있다.기술위원회의 역할은 기술관리부가 승인한 작업범위 내 작업 프로그램 입안, 실행, 국제규격의 작성 등이다. 또한 산하 분과위원회(SC), 작업그룹(WG)을 통해 기타 ISO 기술위원회 또는 국제기관과 연계한다.ISO/IEC 기술작업 지침서 및 기술관리부 결정사항에 따른 ISO 국제규격안 작성·배포, 회원국의 의견 편집 등도 처리한다. 소속 분과위원회 및 작업그룹의 업무조정, 해당 기술위원회의 회의 준비도 담당한다.1947년 최초로 구성된 나사산에 대한 TC1 기술위원회를 시작으로 최근 순환경제를 표준화하기 위한 TC323까지 각 TC 기술위원회의 의장, ISO 회원, 발행 표준 및 개발 표준 등에 대해 살펴볼 예정이다.ISO/TC 52 경량 게이지 금속 용기(Light gauge metal containers)와 관련 기술위원회는 TC1, TC2, TC4~TC6, TC8, TC10~TC12, TC14, TC17~TC22, TC24~31, TC33~TC39, TC41~TC48, TC51과 동일하게 1947년 구성됐다.사무국은 중국국가표준화관리위원회(Standardization Administration of China, SAC)에서 맡고 있다. 위원회는 카이 츄(Mr Kai QIU)이 책임진다. 의장은 티강 정(Mr Tiegang Zheng)으로 임기는 2025년까지다.ISO 기술 프로그램 관리자는 스테판 소바(M Stéphane Sauvage), ISO 편집 관리자는 니콜라 페루(Ms Nicola Perou) 등으로 조사됐다.범위는 공칭 재료 두께가 0.49mm와 같거나 그 이상인 경량 게이지 금속 용기 분야의 표준화다. 현재 ISO/TC 52 사무국의 직접적인 책임하에 있는 발행된 표준은 11개며 ISO/TC 52 사무국의 직접적인 책임하에 개발 중인 표준은 1개다. 참여하고 있는 회원은 11명, 참관 회원은 26명이다.□ ISO/TC 52 사무국의 직접적인 책임하에 있는 표준 11개 목록▲ISO 90-1:1997 Light gauge metal containers — Definitions and determination of dimensions and capacities — Part 1: Open-top cans▲ISO 90-2:1997 Light gauge metal containers — Definitions and determination of dimensions and capacities — Part 2: General use containers▲ISO 90-3:2000 Light gauge metal containers — Definitions and determination of dimensions and capacities — Part 3: Aerosol cans▲ISO 1361:1997 Light-gauge metal containers — Round open-top cans — Internal diameters▲ISO 5099:2022 Light gauge metal containers — Easy-open ends and peel-off ends — Classification and dimensions▲ISO 10653:1993 Light-gauge metal containers — Round open-top cans — Cans defined by their nominal gross lidded capacities▲ISO 10654:1993 Light-gauge metal containers — Round open-top cans — Cans for liquid products with added gas, defined by their nominal filling volumes▲ISO/TR 11761:1992 Light-gauge metal containers — Round open-top cans — Classification of can sizes by construction type▲ISO/TR 11762:1992 Light-gauge metal containers — Round open-top cans for liquid products with added gas — Classification of can sizes by construction type▲ISO/TS 21985:2022 Light gauge metal containers — Non-refillable LPG cartridges — General requirements▲ISO 24021-1:2022 Light gauge metal containers — Vocabulary and classification — Part 1: Open-top cans and ends□ ISO/TC 52 사무국의 직접적인 책임하에 개발중인 표준 1개 목록▲ISO/DIS 24021-2 Light gauge metal containers — Vocabulary and classification — Part 2: General cans
-
[미국] 미국 특허 청구범위의 종속항 및 젭슨 청구항미국 특허 청구 범위에서 종속항은 독립항의 전제부를 동일하게 반복한 후, "as recited in claim 1", "of claim 1", "as specified in claim 1" 또는 "as defined in claim 1"과 같은 표현을 사용해 청구항에 대한 종속성을 나타낸다. 종속항은 일렬로 숫자를 붙여 기술하며, 독립항보다 먼저 기술돼서는 안 된다. 종속항은 해당 청구항 내에 기술되는 구성요소의 상호 작용과 독립항의 구성요소들의 상호 작용에 대해서도 정의해야 한다.종속항에 새로이 나타나는 구성요소는 독립항의 구성요소들과의 작용에 대해 설명해야 한다. 또한 "further comprising", "including", 또는 "further including"과 같은 형태의 개방형 독립항은 구성요소를 부가하기 위한 종속항을 암시한다.종속항은 구성요소를 추가하거나 이미 소개된 구성요소를 보다 자세히 설명하는 경우에 독립항의 구성요소를 한정할 때 사용한다.다수의 종속항(multiple dependent claims)은 일련의 종속항을 간단히 쓰기 위한 경우에 사용되며 하나 이상의 독립항을 동시에 인용해서는 안 된다. 또한 다수의 종속항은 다른 종속항에 의해 인용돼서는 안 된다.젭슨 청구항(Jepson claim) 타입은 이미 존재하는 물건, 방법, 조성에 관한 이용발명의 경우에 사용되지만 선호되지는 않을 뿐만 아니라 권장되지도 않는다.젭슨 청구항의 전제부가 선행기술의 전제부에 포함되는 모든 요소를 허용하는 의미로 해석될 수 있기 때문이다. 특히 대부분의 발명에서 비자명성은 어떤 특정 요소간의 조합에 의해서가 아니라 일반적인 구성요소 간의 조합에 있기 때문이다.
-
카카오, '오픈체인(OpenChain) 프로젝트'의 오픈소스 국제 표준 인증(ISO/IEC 5230:2020) 획득한국 포털 및 인터넷 정보 매개 서비스 기업 카카오(kakao)에 따르면 '오픈체인(OpenChain) 프로젝트'의 오픈소스 국제 표준 인증(ISO/IEC 5230:2020)을 획득했다.'오픈체인 프로젝트'는 미국의 비영리단체인 리눅스 재단(Linux Foundation)에서 시작됐다. 기업의 오픈소스 소프트웨어 체계 및 컴플라이언스(compliance) 역량을 평가해 국제 인증을 부여한다.ISO/IEC 5230:2020 표준은 오픈 소스 라이선스 준수를 위해 핵심 사항을 정의한 최초의 프로세스 관리 국제 표준이다.카카오는 이번 국제 표준 인증을 통해 오픈소스 활용 역량을 인정받았다. 자사 오픈소스 관리 서비스 ‘올리브 플랫폼(Olive Platform)’의 공신력을 높일 것으로 기대하고 있다.오픈소스 관리 서비스 ‘올리브 플랫폼(Olive Platform)’은 2021년 6월에 출시했다. IT 분야 전반에 걸쳐 오픈소스 사용 비중과 관리의 중요성이 커지면서 누구나 쉽고 편리하게 오픈소스를 관리할 수 있도록 하기 위한 목적이다.올리브 플랫폼은 오픈소스의 라이선스 및 의무사항을 확인하고 리포트를 제공한다. 또한 신뢰할 수 있는 오픈소스 데이터베이스를 구축해 보다 쉽고, 빠르고, 정확하게 오픈소스를 검증할 수 있는 것을 특징으로 한다. 매년 이프카카오(if kakao) 개발자 컨퍼런스의 오픈소스 관련 세션에서 개발자들이 오픈소스를 이해하고 활용하는 방법을 공유하고 있다. 공개 소프트웨어를 개발하고 이를 공유하는 등 안전하고 효율적인 오픈소스 생태계 구축을 위한 활동을 전개하고 있다.개발자들은 카카오의 서비스에 공개소프트웨어를 확대 적용하고, 오픈소스 행사, 사업, 교육, 자문, 커뮤니티 활동 등에 적극적으로 참여하고 있다. 카카오는 다양한 산업 분야에서 오픈소스 사용이 증가하고 그 중요성이 커지고 있어 카카오의 오픈소스 역량을 적극적으로 공유해 개발 생태계 발전에 앞장설 것으로 전망된다.참고로 ISO/IEC 5230:2020 표준은 ▶1 Scope ▶2 Terms and definitions ▶3 Requirements ▶3.1 Program foundation ▶3.2 Relevant tasks defined and supported ▶3.3 Open source content review and approval ▶3.4 Compliance artifact creation and delivery ▶3.5 Understanding open source community engagements ▶3.6 Adherence to the specification requirements ▶Annex A (informative) Language translations of this specification 등으로 구성돼 있다.