검색결과
-
식약처, ‘생물학적제제 품질관리실험실 네트워크(Lab-Net) 워크숍’ 개최식품의약품안전처는 백신·혈장분획제제 품질관리에 대한 최신 기술정보를 공유하는 ‘2023년 생물학적제제 품질관리실험실 네트워크(Lab-Net) 워크숍’을 23일 오송 C&V센터에서 개최한다고 밝혔다. 이번 워크숍으로 백신·혈장분획제제 업계의 품질관리 역량을 강화하는 데 도움이 될 것으로 기대된다. ‘생물학적제제 품질관리실험실 네트워크(Lab-Net)’는 식약처와 백신·혈장분획제제 제조·수입업체, 품질 검사기관 등이 참여하는 민·관 협의체로 2011년에 출범한 이후 품질관리 분야에서 활발하게 교류하며 국내 백신, 혈장분획제제 품질을 높이는 데 기여해 왔다. 이번 워크숍은 전문가 강연과 2023년 Lab-Net 운영 현황 및 내년도 계획 등에 대한 발표로 구성돼 있다. 전문가 초청 강연에서는 ▲시험방법 밸리데이션을 위한 통계 방법 ▲미국약전 생물학적 정량법 밸리데이션 ▲데이터 완전성과 컴퓨터 시스템 밸리데이션 ▲오염 관리 전략 수립 접근방법 등을 소개한다. 아울러 ▲백신 역가 시험법 개선 ▲항트롬빈III제제국가표준품 확립공동연구 ▲혈장분획제제 동물대체시험법 추진 등 Lab-Net 운영 성과와 내년도 계획에 대해서도 안내한다. 식약처 관계자는 “이번 워크숍이 백신·혈장분획제제 업계의 품질관리 역량을 강화하는 데 도움을 줄 것으로 기대한다”며 “앞으로도 전문성과 규제과학에 기반한 철저한 품질관리를 수행하여 안전한 제품이 국민께 공급될 수 있도록 최선을 다해 노력할 계획”이라고 밝혔다.
-
[미국] 파워인터그레인션, 페어차일드와의 특허침해 손해배상에서 패소미국 법률에 따르면 특허소송은 특허 침해에서 손해를 계산하기 위해 특허권자는 피의자 제품의에서 특허를 제외한 기능이 소비자 요구에 영향을 미치지 않았다는 것을 증명해야 한다.실례로 파워인터그레이션(Power Integrations)는 페어차일드(Fairchild)에게 특허침해 소송을 제기했다. 지방법원에서 배심원은 페어차일드가 약 $1억4000만달러의 손해 배상을 입었다는 사실을 알게됐다.페어차일드는 침해 결정과 손해 배상에 항소했다. 연방순회항소법원은 특허에 따른 기능이 소비자 요구의 기초가 될 때 전체 시장가치 규칙(EMVR)을 기반으로 한 손해배상을 허용한다는 점을 반복해 강조했다.즉 제품에 다른 유용한 기능이 포함된 경우 특허권자는 다른 기능이 구매결정에 영향을 미치지 않았다는 것을 증명해야 한다.이에따라 항소법원은 파워인터그레이션이 이를 증명하지 못했음을 발견했다. 즉 제시된 증거가 전체 시장가치 규칙을 불러 일으키기에 불충분했기 때문에 손해배상을 인정하지 않았다. 국문요약: 연방순회항소법원은 입증부담을 충족하지 못한 특허권자에 대한 손해배상을 무효로 판결했다. "EMVR(entire market value rule)”에 따른 손해배상의 경우에는 특허권자가 “특허를 받지 않은 특징이 소비자가 제품을 구매하지 못하도록 함”는 점을 증명해야 한다. 즉, 특허를 받은 특징에 의해 소비자가 제품을 구매해야 한다.영문요약: Calculating DamagePower Integrations v. Fairchild (FC 2018):History:•Federal Circuit vacated the damage award ($140M) stating that the patentee had not met the burden of proof.•Burden of proof: the patentee seeking entire market value rule (“EMVR”) damages must show that the non-patented features “did not cause consumers to purchase the product.”•Basically, the patented feature should drive the sale of the product to trigger EMVR.•FC still considers the possibility of using EMVR when calculating damages, but it is still disfavored.•When non-patented features of an accused product are “simply generic and/or conventional”, the court would consider applying EMVR.
-
국표원, 국제표준화기구 리더십 개발 프로그램 개최한국이 국제표준화기구와 함께 개발도상국 표준역량 강화에 나선다. 산업통상자원부 국가기술표준원은 20일부터 24일까지 프레이저 플레이스 남대문 서울 호텔에서 사우디, 인도네시아, 싱가포르 등 아시아·태평양 및 중동지역 12개국 표준화기관 고위급 20여 명이 참석하는 ‘ISO 리더십 개발 프로그램’을 개최한다고 20일 밝혔다. 이에 향후 개발도상국이 국제표준 활용 시 기술규제가 완화돼 국내 기업의 해외시장 진출에 도움이 될 것으로 기대된다. 올해 9월 국제표준화기구(International Organization for Standardization, ISO) 연례회의에서 ISO와 체결한 ‘ISO 개발도상국실행계획’ 약정의일환으로 기술지원, 교육, 훈련 등을 통해 개발도상국의 국제표준 참여 확대 및 활용을 지원하기 위한 프로그램이다. ISO의 개발도상국 지원은 우리나라 최초로 선출된 조성환 ISO 회장이추진할 5가지 주요 정책 중 하나다. 지난 9월 ISO 이사국에진출한 우리나라는 국제표준 리더국으로서 개발도상국의 국제표준 참여 확대를 위해 ‘ISO 개발도상국 실행계획’에 2025년까지 3년간 지원할 예정이다. 5가지 주요 정책은 ISO 2030 전략구현, 글로벌 위기대응, 개도국 참여확대, 표준보급촉진, 교육역량 강화 등이다. 오광해 표준정책국장은 “우리나라는 표준강국으로서 개발도상국들이 국제표준 개발에 적극 참여할 수 있도록 지속적으로 기여하겠다”며 “향후 개발도상국들이 국제표준 활용 시 기술규제가 완화돼 우리나라 기업의 해외시장 진출에 도움이 될 것”이라고 전했다.
-
[기획-디지털 ID 기술] ㊼ 이엠씨아이피홀딩스, '디지털 아이디 값을 기반으로 멀티-요소 인증을 이용한 기본 입출력 시스템 보호' 명칭의 미국 특허 등록(US 11487862)미국 지적재산권 관리 기업 이엠씨아이피홀딩스(EMC IP Holding)에 따르면 2022년 11월1일 '디지털 아이디 값을 기반으로 멀티-요소 인증을 이용한 기본 입출력 시스템 보호(Basic input/output system protection using multi-factor authentication based on digital identity values)' 명칭의 미국 특허(US 11487862)가 등록됐다.본 등록 특허(US 11487862)는 2021년 1월18일 출원(US 17/151420)된 후 2022년 7월21일 공개(US 2022/022989)되어 미국 특허청에 의해 심사를 받았다. 본 등록 특허는 기본 입출력 시스템인 바이오스(BIOS)의 아키텍처와 관련된 특허다.본 등록 특허의 일 실시예에 따르면 하드웨어 장치의 바이오스에 의해, 사용자 장치로부터 바이오스에 액세스하기 위한 요청 및 용자 장치에 대한 디지털 아이디 값에 기초한 토큰을 획득한다.하드웨어 장치의 멀티-요소 인증(Mulfi-factor authentication, MFA) 칩에 토큰이 제공된다. 상기 MFA 칩은 토큰을 평가하고 검증 결과를 바이오스에 제공한다.검증 결과에 기초해 사용자 장치 바이오스에 액세스할 수 있게 허용한다. 사용자 장치에 대한 디지털 아이디 값은 MFA 칩의 제조 및/또는 사용자 장치의 등록시 MFA 칩에 의해 저장된다.MFA 칩은 바이오스로부터 수신된 토큰과 MFA 칩에 의해 저장된 사용자 장치에 대한 디지털 아이디 값을 비교한다.
-
[기획-디지털 ID 기술] ㊶ 존슨컨트롤티코아이피홀딩스, '액세스 컨트롤을 위한 디지털 아이디 프로필의 자동 생성 및 관리' 명칭의 미국 특허 등록 (US 11763613)미국 지적재산권 관리 기업 존슨컨트롤티코아이피홀딩스(Johnson Controls Tyco IP Holdings)에 따르면 2023년 9월19일 '액세스 컨트롤을 위한 디지털 아이디 프로필의 자동 생성 및 관리(Automatic creation and management of digital identity profiles for access control)' 명칭의 미국 특허 (US 11763613)가 등록됐다.본 등록 특허는 2021년 3월 8일에 출원(US 17/195219)된 후 미국 특허청에 의해 심사를 받았다. 패밀리 특허로 PCT 국제 출원(PCT-US2022-070973)이 2022년 3월4일 출원됐다.본 등록 특허는 액세스 제어 시스템을 통해 개인과 관련된 접근 시도를 식별하는 방법에 관한 특허다. 본 등록 특허의 일 실시예에 따르면 억세스 제어 시스템을 통해 개인의 아이디를 확인한다. 개인의 아이디를 확인하는 것에 응답하여 액세스 제어 시스템에 의해 개인에 대한 액세스를 허가한다. 액세스 시도와 동시에 캡처된 개인의 시각 데이터에 기초해 개인의 디지털 아이디 프로파일을 액세스 제어 시스템에 의해 구축한다.
-
[기획-디지털 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 표준] ⑭산업단체와 포럼 - 오아시스(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 표준] ⑪산업단체와 포럼 - 국제자금세탁방지기구(Financial Action Task Force, FATF)디지털 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) 등이다.국제자금세탁방지기구(Financial Action Task Force, FATF)는 자금세탁 방지 정책을 개발하기 위해 G7 국가의 주도로 1989년 설립된 정부 간 조직이다.FATF는 2020년 3월 정부, 금융기관, 가상 자산 서비스 제공업체, 기타 규제 기관이 디지털 ID가 고객 실사에 사용하기에 적합한지 여부를 결정하는데 도움이 되는 디지털 ID에 관한 지침(Guidance on Digital ID)을 개발했다.'디지털 ID에 대한 지침'은 정부, 규제 대상 기관(예: 금융기관) 및 기타 관련 이해관계자가 FATF 권고사항 10에 따라 고객 실사의 특정 요소를 수행하기 위해 디지털 ID 시스템을 사용할 수 있는 방법을 결정하는 데 도움을 주기 위한 간행물이다.지침을 발표한 2020년 당시 조사에 따르면 디지털 거래 건수가 매년 약 12.7%씩 증가하고 있다. 2022년 전 세계 GDP의 약 60%가 디지털화 될 것으로 예측됐기 때문이다.모든 금융 거래와 관련된 자금이 범죄 및 테러와 연관되지 않도록 고객을 이해하는 것이 필수적이라고 생각했으나 디지털 환경에서는 기존 검증 도구가 적용되지 않기 때문이다.디지털 ID 시스템이 빠르게 발전하고 있으며 디지털 ID가 적합한지 확인하려면 정부나 금융기관, 기타 이해관계자들은 디지털 ID 시스템의 기술, 아키텍처, 거버넌스 보증 수준을 이해해야 된다.또한 보증 수준을 고려해 불법 금융을 조장하는데 사용되는 잠재적 위험을 고려해 적절하게 신뢰할 수 있고 독립적인지 여부를 결정해야 된다. 다음은 FATF가 개발한 디지털 ID에 관한 지침(Guidance on Digital ID)의 목차 내용이다.□ 목차(Table of Contents)▷줄임말(ACRONYMS)▷요약(EXECUTIVE SUMMARY)▷섹션 I(SECTION I) : 소개(INTRODUCTION)▷섹션 II(SECTION II) : 디지털 ID 용어 및 주요 기능(DIGITAL ID TERMINOLOGY AND KEY FEATURES)▷섹션 III(SECTION III) : 고객 실사에 대한 FATF 표준(FATF STANDARDS ON CUSTOMER DUE DILIGENCE)▷섹션 IV(SECTION IV) : AML/CFT 규정 준수 및 관련 문제에 대한 디지털 ID 시스템의 이점과 위험(BENEFITS AND RISKS OF DIGITAL ID SYSTEMS FOR AML/CFT COMPLIANCE AND RELATED ISSUES)▷섹션 V(SECTION V) : CDD에 대한 위험 기반 접근 방식에 따라 디지털 ID 시스템이 충분히 안정적이고 독립적인지 평가(ASSESSING WHETHER DIGITAL ID SYSTEMS ARE SUFFICIENTLY RELIABLE AND INDEPENDENT UNDER A RISK-BASED APPROACH TO CDD)▷부록(APPENDIX) A : 기본 디지털 ID 시스템 및 해당 참가자에 대한 설명(DESCRIPTION OF A BASIC DIGITAL IDENTITY SYSTEM AND ITS PARTICIPANTS)▷부록(APPENDIX) B : 사례 연구(CASE STUDIES)▷부록(APPENDIX) C : 지속가능발전 식별에 관한 원칙(PRINCIPLES ON IDENTIFICATION FOR SUSTAINABLE DEVELOPMENT)▷부록(APPENDIX) D : 디지털 ID 보증 프레임워크 및 기술 표준 설정 기관(DIGITAL ID ASSURANCE FRAMEWORK AND TECHNICAL STANDARDSETTING BODIES)▷부록(APPENDIX) E : 미국 및 EU 디지털 보증 프레임워크 및 기술 표준 개요(OVERVIEW OF US AND EU DIGITAL ASSURANCE FRAMEWORKS AND TECHNICAL STANDARDS)▷용어 사전(GLOSSARY)
-
[기획-디지털 ID 기술] ㉕ 페이지, '액체 시료로부터 이미지 기반 연산 바이오마커를 결정하기 위해 이미지를 처리하는 시스템 및 방법' 명칭의 미국 특허 등록 (US 11721115)미국 인공지능 암진단 기업 페이지(Page, AI)에 따르면 2023년 8월8일 '액체 시료로부터 이미지 기반 연산 바이오마커를 결정하기 위해 이미지를 처리하는 시스템 및 방법(Systems and methods for processing images to determine image-based computational biomarkers from liquid specimens)' 명칭의 미국 특허(US 11721115)가 등록됐다.본 등록 특허는 2023년 5월30일 등록된(US 11663838) 모출원 건으로부터 2021년 11월5일 계속 출원됐다. 모 출원건(US 11663838)은 2020년 10월29일 가출원(US 63/107389)되고 2021년 10월27일 본출원(US 17/511871)된 후 등록됐다.본 등록 특허는 기계학습 모델을 사용해 태스크-특정(task-specific) 예측을 출력하는 시스템에 관한 것이다. 일 실시예에 따르면 세포학 샘플의 디지털화된 세포학 이미지를 수신하고 디지털화된 세포학 이미지의 세포를 격리시키기 위해 기계 학습 모델을 적용한다. 기계학습 모델은 디지털화된 세포학 이미지의 복수의 서브-부분들을 식별한다. 또한 기계학습 모델은 배경 또는 셀 중 하나의 서브-부분의 각 서브 부분을 식별하고, 디지털화된 세포학 이미지의 세포 서브-이미지를 결정한다.각 셀 서브-이미지는 배경 또는 셀 중 하나를 식별하는 것에 기초해 디지털화된 세포학 이미지의 셀을 포함할 수 있다.본 등록 특허에서는 셀 서브-이미지에 기초하여 복수의 특징을 결정하고 상기 복수의 특징에 기초해 집합 특징을 결정할 수 있다.이때 각 셀 서브 이미지는 상기 복수의 특징 중 적어도 하나와 연관된다. 또한 본 등록 특허는 집합 특징에 기초하여 타겟 태스크를 예측하기 위해 기계학습 모델을 트레이닝할 수 있다.
-
[기획-디지털 ID 표준] ⑨산업단체와 포럼 - CA/Browser Forum(Certification Authority Browser Forum) 소개디지털 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) 등이다.인증기관브라우저 포럼(Certification Authority Browser Forum, CA/Browser Forum)은 2005년 조직됐다. CA/브라우저 포럼은 인증기관의 자발적 그룹이자 인터넷 브라우저 소프트웨어, 운영체제, 기타 공개 키 인프라(PKI) 지원 애플리케이션 공급업체다. SSL/TLS, 코드 서명 및 S/MIME와 같은 응용프로그램에 내장된 트러스트 앵커에 연결된 X.509 버전 3(v.3) 디지털 인증서 발급 및 관리를 관리하는 업계 지침을 발표하고 있다.SSL/TLS는 Secure Socket Layers / Transport Layer Security의 약어며 S/MIME는 Secure/Multipurpose Internet Mail Extensions의 약어다.디지털 ID와 가장 관련이 있는 표준/지침은 △공개적으로 신뢰할 수 있는 인증서의 발급 및 관리를 위한 기본 요구 사항 인증서 정책(Baseline requirements certificate policy for the issuance and management of publicly-trusted certificates) △확장된 검증 인증서의 발급 및 관리에 관한 지침(Guidelines for the issuance and management of extended validation certificates) 등이다.