검색결과
-
[미국] 특허상표청, 최후 거절 후 대응 프로그램 AFCP 2.0 활용미국 특허상표청(USPTO)은 최종 거절이유 통지(Final Office Action)가 발행된 이후 이에 대한 대응을 간소화하기 위해 AFCP((After Final Consideration Pilot) 2.0 프로그램을 운영하고 있다.이 프로그램은 최종 결정을 재고려할 수 있도록 추가적인 시간을 허용하는 미국 특허상표청의 최후거절 후의 보정범위 완화 프로그램이다.AFCP 2.0은 최종 거절이유 통지 이후 출원인이 다양하게 대응할 수 있도록 출원인의 선택 범위를 확장해 줄 수 있다.특히 출원인의 대응 전략이 실패하더라도 심사관으로부터 Adivisory Action이 발행되면 계속심사청구(Request for Continued Examination) 또는 심판(Appeal) 청구 등의 다음과 같은 대응전략을 결정할 수 있다.요약 1. 정의 : 최종거절통지의 답변(after-final response)에서 독립항의 범위를 넓히지 않는 보정을 행하면, 추가적인 관납료(fee)없이 심사관이 그 보정을 고려할 수 있도록 하는 파일럿 프로그램(pilot program).2. 목적 : 비용 및 시간 부담을 줄이면서 특허청에 계류정인 재심사(RCE) 건의 숫자를 줄이기 위한 심사관과 출원인의 협력3. 요건 : 1) 가출원, 계속출원, 분할출원 대상 (reissue 또는 Reexamination 불가능) 2) 최소 1개 이상의 독립항의 수정 (청구항의 확장은 불가능) 3) 심사관과의 인터뷰에 참여한다는 진술서(statement) 제출 4) e-filing으로 진행해야 함 (EFS-Web)4. 이후 절차(심사관) 1) 요건에 따라 제출되면 심사관은 3시간 이내에 재고려 가능한지 아니면 추가의 조사가 필요한지를 판단 2) 재고려 가능한 경우에는 보정안의 등록여부를 판단 3) 등록이 어려운 경우에는 대리인과 인터뷰 진행(선택사항) 4) 등록이 가능한 경우에는 Notice Of Allowance 발행 5) 상기 절차에서 추가의 조사가 필요한 경우이거나, 대리인과 인터뷰 결과에 대해 Advisory Action을 발행
-
[기획-디지털 ID 기술] ㊻ 마스터카드 인터내셔널, '아이디 데이터와 함께 사용하기 위한 컴플라이언스 플랫폼' 명칭의 미국 특허 등록 (US 11811926)미국 글로벌 결제 서비스 기업 마스터카드 인터내셔널(MASTERCARD INTERNATIONAL INCORPORATED)에 따르면 2023년 11월7일 '아이디 데이터와 함께 사용하기 위한 컴플라이언스 플랫폼(Compliance platform for use with identity data)' 명칭의 미국 특허(US 11811926)가 등록됐다.본 등록 특허는 2021년 5월12일 출원(US 17/318982)된 후 2022년 11월17일 공개돼 미국 특허청에 의해 심사를 받았다.패밀리 특허로 2022년 3월28일 PCT국제출원(PCT-US2022-022096)이 진행되어 2022년 11월17일 공개(WO2022-240487)된 상태다.본 등록 특허의 일 실시예에 따르면 사용자로부터 컴플라이언스 데이터 패키지를 수신한다. 상기 컴플라이언스 데이터 패키지는 사용자의 디지털 아이디 데이터에 대응하는 암호화된 증거 데이터를 포함한다.제1 암호 키를 사용해 컴플라이언스 데이터 패키지가 암호화된다. 상기 제 1 암호 키에 기초하여 사용자 키 샤드(user key shard), 요청자 키 샤드(requestor key shard), 및 레귤레이터 키 샤드(regulator key shard)가 생성된다.상기 요청자 키 샤드를 포함하는 잠금 해제 데이터 패키지가 생성된다. 제2 암호 키를 사용해 상기 잠금 해제 데이터 패키지가 암호화된다.상기 사용자 키 샤드, 상기 암호화된 잠금 해제 데이터 패키지, 및 상기 암호화된 컴플라이언스 데이터 패키지가 사용자에게 전송된다. 상기 레귤레이터 키 샤드가 레귤레이터에 송신된다.
-
[기획-디지털 ID 기술] ㊷ 오크타, '유연한 아이디 및 액세스 관리 파이프라인' 명칭의 미국 특허 등록 (US 11631081)미국 IT 서비스 관리 기업 오크타(Okta, Inc.)에 따르면 2023년 4월18일 '유연한 아이디 및 액세스 관리 파이프라인(Flexible identity and access management pipeline)' 명칭의 미국 특허(US 11631081)가 등록됐다.본 등록 특허는 2020년 4월1일 가출원(US 63/003866)된 후 2021년 3월31일 출원돼(US 17/219684) 미국 특허청에 의해 심사를 받았다.패밀리 특허로는 본 등록 특허를 기초로 2023년 4월17일 계속 출원(US 18/301809)되어 심사 중이다(US 2023-0259939).본 등록 특허는 디지털 아이디 검증을 위한 컨텍스트 기반 검증 플로우에 대한 시스템과 방법에 관한 특허다.본 등록 특허의 일 실시예에 따르면 기업의 고객들, 기업의 서비스에 적응된 다양한 기업에 대한 유연한 식별 절차를 제공한다.컨텍스트 기반 검증 시스템은 제 1 기업과 연관된 제 1 및 제 2 검증 플로우와 제 2 기업과 연관된 제 3 검증 플로우를 결정한다. 이러한 검증 플로우들은 컨텍스트 파라미터들 및 검증 파라미터들을 포함한다.컨텍스트 기반 검증 시스템은 사용자가 제1 기업과 상호작용을 요청할 때 리퀘스트의 컨텍스트 매개변수 또는 "리퀘스트 컨텍스트 매개변수(request context parameters)"를 결정한다. 리퀘스트 컨텍스트 매개변수와 실질적으로 일치하는 컨텍스트 매개변수와 연관된 검증 플로우가 결정된다.콘텍스트 기반 검증 시스템은 제1 검증 플로우의 콘텍스트 매개변수가 리퀘스트 콘텍스트 매개변수와 실질적으로 일치한다고 결정할 수 있다. 사용자의 아이디를 검증하기 위해 제1 검증 플로우의 검증 매개변수가 사용될 수 있다.
-
[기획-디지털 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 표준] ⑬산업단체와 포럼 - 국제인터넷표준화기구(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
-
[미국] 켄터키주, 6월30일 국내 최초로 테슬라(Tesla) 충전 표준 의무화 RFP 발표미국 켄터키주에 따르면 2023년 6월30일 국내 최초로 테슬라(Tesla)의 충전 표준을 의무화하는 전기자동차(EV) 충전 프로그램에 대한 켄터키의 제안 요청서(request for proposals, RFP)를 발표했다.켄터키 RFP는 경쟁 결합충전시스템(Combined Charging System, CCS)에 대한 연방 규정 외에 충전소에서 북미충전표준(North American Charging Standard, NACS)으로 알려진 테슬라의 플러그를 의무화하고 있다. 텍사스, 워싱턴이 유사한 계획을 발표한 가운데 켄터키주가 테슬라의 충전 기술을 요구하는 첫 번째 주로 자리매김했다.최근 포드자동차를 시작으로 제너럴 모터스(GM), 리비안 오토모티브(Rivian Automotive), 다수의 자동차 및 충전 기업들이 NACS 채택하기로 결정했다.EV 충전기 제조업체 및 운영업체 그룹이 테슬라 충전 기술을 포함하도록 의무화하려는 텍사스주에 대해 시기상조라고 반대 서한을 보내기도 했다. 테슬라 커넥터의 안전성과 상호 운용성에 관한 표준화, 테스트, 인증 등에 많은 시간이 필요하기 때문이다.참고로 미국 교통부는 2023년 초 발표한 정책에 따르면 충전회사가 2030년까지 50만대의 EV 충전기를 설치를 위한 연방 자금을 지원 받을 수 있다. 주 정부가 NEVI(National Electric Vehicle Infrastructure Program)로부터 지원받을 수 있는 연방 자금은 $US 50억 달러(약 6조5000억 원)다.예산 지원을 받기 위해서는 CCS 커넥터를 제공해야 된다. 또한 충전소가 국가 표준인 CCS를 충족하는 규칙에 따라 다른 커넥터가 허용된다.
-
[미국] 미국 특허 출원 정보 공개 진술서(IDS)의 시간적 요건특허 출원 정보 공개 진술서(IDS) 미국 연방규칙 37. C.F.R. 1.97에 정해진 절차와 요건에 부합되도록 제출돼야 한다. IDS는 제출되는 시점에 따라 4단계로 구별될 수 있다. 1)1단계: 실체적 내용에 대한 최초의 거절이유 통지(first Office Action)를 받기 전 또는 미국 출원일로부터 3개월 내에 제출된 IDS가 해당된다.계속 출원(RCE: Request for Continued Examination)에 있어서는 "출원일로부터 3개월 이내" 규정이 적용되지 않는다. 1단계에서 제출된 IDS에 대해서는 별도의 비용이나 증명서가 요구되지 않는다.2)2단계: 1단계 시점이 경과한 이후에 제출되고, 최종 거절이유 통지(Final Office Action), 등록 통지(notice of allowance) 및 재심사 신청(Ex parte Quayle action)중 어느 하나라도 발생되기 이전에 제출된 IDS가 해당된다.2단계에서 제출된 IDS는 미국 연방규칙 37. C.F.R. 1.97(e)에 규정된 진술서가 함께 제출되거나, 미국 연방규칙 37. C.F.R. 1.17(p)에 규정된 수수료가 납부되여야 한다.만약, 개시 의무를 가진자가 정보를 최초로 인지한 때부터 3개월이 경과해 IDS를 제출하려면 진술서(정보 인지가 3개월 이내임을 증명하는 진술서임) 대신에 미국 연방규칙 37. C.F.R. 1.17(p)에 규정된 수수료 US$180 달러를 납부해야만 제출된 IDS가 심사관에 의해 검토될 수 있다.3)3단계: 최종 거절이유 통지(Final Office Action), 등록 통지(notice of allowance) 및 재심사 신청(Ex parte Quayle action)중 어느 하나라도 발생한 이후에 제출되고 등록료 납부와 동시에 또는 그 이전에 제출된 IDS가 해당된다.3단계에서는 미국 연방 규칙 37. C.F.R. 1.97(e)에 규정된 진술서가 제출돼야 하는 동시에 미국 연방 규칙 37. C.F.R. 1.17(p)에 규정된 수수료 US$180 달러도 함께 납부돼 한다.4)4단계: 등록료가 납부된 이후, 특허공보가 발행(Issue)되기 이전에 제출된 IDS가 해당된다. 4단계에서는 심사절차가 완료돼 등록절차에 있는 출원을 다시 심사절차로 되돌리기 위한 청원(petition)을 수수료 및 RCE 비용(조건부로 지불됨)과 함께 제출해야 한다.QPIDS(Quick Path IDS) 를 진행하는 경우에는 QPIDS 청원과 수수료를 추가로 제출해야 한다. 만약에 청원(petition)없이 IDS만 제출되면 심사관에 의해 검토되지 않은 상태로 단순히 출원포대에 기록만 남겨진다.만약 특허공보가 발행되면, 출원인은 개시 의무에서 벗어나게 되며 제출되지 못한 IDS가 존재할지라도 정규의 심사절차에서 제출할 수 있는 방법은 없다.새롭게 발견한 종래기술에 대해서는 재심사(reexamination 또는 재발행(reissue) 절차를 통해 미국 특허청에 검토하도록 요청할 수도 있다.
-
[에콰도르] 경제협력개발기구(OECD), 에콰도르의 법적 및 규제 프레임워크에 관한 첫번째 피어리뷰(peer-review)를 발표프랑스 파리에 본부를 두고 있는 경제협력개발기구(OECD)는 2022년 8월 31일 에콰도르의 법적 및 규제 프레임워크에 관한 첫번째 피어리뷰(peer-review) 보고서를 발표했다.피어리뷰는 조세 목적을 위한 투명성 및 정보교환에 관한 OECD 글로벌 포럼(Global Forum)이 에콰도르(Ecuador)의 투명성 및 요청 시 재무 정보 교환(transparency and exchange of financial information on request, EOIR)에 관한 보고서이다.또한 지난 8월 발표된 2차 1단계 보고서는 에콰도르의 법적 및 규제 프레임워크, 투명성 및 EOIR에 대한 국제 표준 준수를 검토한다는 것을 포함하고 있다.보고서는 에콰도르가 특정 상황에서 유익한 소유권 정보의 가용성 및 회계 기록의 일부 개선이 필요한 기준과 일치하고 있다고 지적했다.보고서는 프레임워크가 관련 정보의 가용성, 접근성, 교환을 광범위하게 보장하고 있다. EOIR을 위한 법적 프레임워크는 제한된 결함만 식별된 정보에 대한 효과적인 접근 및 교환을 허용한다.투명성 측면에서 에콰도르가 프레임워크를 개선하고 법인 및 약정의 유익한 소유권에 대한 정보의 국제 가용성 표준을 준수하기 위해 노력해왔다는 점에 주목하고 있다.특히 2021년 11월 시행된 '경제발전 및 재정지속가능성을 위한 유기물법'을 통해 달성된 것으로, 현재 시행 중인 수익형 소유권 등록부를 도입했다.보고서에 의해 제기된 주요 권고사항은 수익소유정보 구조의 격차와 모든 경우에 수익소유정보를 이용할 수 있도록 보장해야 한다. 하지만 현재 신뢰할 수 있는 출처는 없다.따라서 OECD는 등록부를 도입하는 법의 조항과 관련 시행규정이 국제 표준을 충족해야 한다고 제안한다. 회계 기록의 가용성과 관련해 피어리뷰는 에콰도르 회사가 해산되거나 해외로 이전한 후 최소 5년의 기간 동안 사용 가능한 기본 문서와 함께 신뢰할 수 있는 기록을 보관하도록 권고하고 있다.2단계 보고서는 차후 에콰도르의 법적 프레임워크의 이행을 검토할 것다. 늦어도 2023년 6월 30일까지 글로벌 포럼에 제시돼야 한다.