▲ 디지털 ID 산업의 발전 전략 [출처=iNIS]디지털 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 산업의 발전 전략 [출처=iNIS]디지털 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

▲ 아랍에미리트(UAE) 보건부(Ministry of Health and Prevention, MoHAP) [출처=홈페이지]아랍에미리트(UAE) 보건부(Ministry of Health and Prevention, MoHAP)에 따르면 2023년말까지 스마트 디지털 의료 규제 프레임워크(Smart Digital Health regulatory framework)를 도입하기로 결정했다.지난 3월 보건부 산하 디지털의료부(Digital Health Department) 전략투자실(Strategy and Investment Section)은 두바이에서 개최된 원격포럼에서 도입 계획을 발표했다.UAE에서 도입되는 새로운 규제 프레임워크는 모든 의료 제공업자들이 환자를 위해 최소 하나의 원격 서비스 형태를 제공해야 될 의무를 부담하도록 했다.의료제공업자들은 컨설팅, 약물 처방, 환자 모니터링 또는 로봇 수술과 같은 이러한 서비스 중 적어도 하나를 원격으로 제공해야 된다. 새로운 규제는 공공 및 민간 영역의 의료 서비스 제공업자 모두에게 해당된다.의료 시설은 현재 운영하고 있는 가상 또는 원격 의료 서비스에 대해 보건부에 보고해야 된다. 만약 의료시설이 어떤 것도 보유하고 있지 않다면 올해 연말까지 원격 서비스 중 하나를 갖추도록 협력해 나갈 계획이다.모든 원격 의료 서비스를 규제하고 있는 포괄적인 의료 규제 프레임워크는 의료 시설 및 환자 권리에 대한 역할과 책임을 정의하고 있다.의료 분야의 기술 발전이 급속도로 발전함에 따라 의료 시설에서 원격 서비스를 촉진하는 것이 시급하기 때문이다.정부는 의료 관광으로 진화해 나가고 있는 상황에서 원격 의료 진료와 같은 기본 서비스가 필요하다고 판단했다. 또한 의료 부문 디지털화를 나아가기 위해서도 원격 의료 서비스 도입이 절실한 실정이다.보건부는 의료 진단 및 처방, 원격진료에 대한 의료적 책임이 필요하다고 보고 있으며 이를 위해 명확한 규정을 마련했다. 규칙과 규정을 통해 의료 서비스 제공자에게 경계를 명확히 설정할 수 있을 것으로 전망된다.

▲ 미국 특허청 특허등록 이미지미국 특허 명세서에서 참고 자료는 해당 발명의 배경을 나타내거나 발명의 기술 상태를 도해하는 데에 이용된다.참고 자료의 통합은 해당 발명이 속하는 기술 분야의 당업자가 발명과 관련된 정보를 중복해서 자료를 조사하는 상황을 방지하기 위해 이용된다.특히, 발명의 청구 범위를 지지하거나 적정한 공개에 필요한 필수적인 자료인 경우에는 참고 자료에 의해 통합될 수 있는 자료가 등록된 미국 특허 또는 승인된 미국 특허 출원서다.필수적이지 않은 주재료가 참고 자료에 의해 통합되어질 수 있는 자료는 등록된 미국 특허, 외국 특허, 특허 출원서, 비특허 간행물이다.미국 특허 명세서에는 "참고 자료에 의해 통합된 자료"라는 것을 명백하게 표시해야 한다. 다른 자료에서 인용된 단순한 참고자료로서는 불충분하기 때문이다.만약 최초 출원 명세서에 참고 자료로 자료를 통합할 의사를 표하지 않았다면 통합하기 위한 수정은 새로운 자료로 간주돼 출원일이 변경된다.참고자료에 사용되는 참고번호는 상위의 번호로서 일련번호인 것이 좋으며, 일관성 있게 참고 자료의 번호를 사용하는 것이 바람직하다.가능한 미래 시제보다 현재 시제를 사용하는 것이 좋다. 하지만 "must", "always", mandatory"와 같은 절대적 문구를 사용하지 않는 것이 바람직하다.

싱가포르 항공사인 싱가포르항공(SIA)에 따르면 싱가포르거래소(SGX)에서 주식 발행 계획을 승인받았다. 해당 계획은 싱가포르항공의 S$ 88억달러 펀드 유치계획의 일환이다. 최대 17억7000만 주에 대한 상장과 견적이 승인됐다. 이중에서 권리 MCB(mandatory convertible bond) 부문은 최대 35억달러 규모로 발행될 수 있다. 싱가포르 수집품 스타트업인 Mighty Jaxx에 따르면 시리즈 A 라운드 전에 S$ 450만달러를 추가로 유치했다. US$ 320만달러에 달하는 금액으로 해당 스타트업은 수집품을 디자인하고 제조한다. 투자 라운드는 한국의 KB 인베스트먼트(KB Investment)에서 주도했다. 이번 투자 라운드로 해당사의 전체 자본은 660만달러로 상승됐다. 글로벌 상업부동산서비스기업인 쿠쉬먼&웨이크필드(Cushman & Wakefield)에 따르면 2020년 1분기 싱가포르 자산 투자판매는 S$ 30억2000만달러로 집계됐다.  2019 회계연도 4분기와 대비해 37% 하락한 것으로 코로나바이러스 영향이 주요인이다. 글로벌 주식시장의 급격한 주식 판매와 판데믹에 의한 직접적인 충격을 받은 것으로 조사됐다.  ▲쿠쉬먼&웨이크필드(Cushman & Wakefield) 홈페이지 

영국 글로벌 항공사인 버진아틀란틱(Virgin Atlantic)에 따르면 여성 승무원의 화장의무를 폐지하기로 결정했다. 자신만의 방식으로 표현할 수 있도록 새로운 가이드라인을 제시했다.화장을 하지 않고는 일을 할 수는 없다. 하지만 립스틱과 기초 화장은 해야 한다. 또한 여성 승무원이 입을 수 있도록 바지도 제공할 방침이다. 화장은 저임금 근로자에게 비용으로 다가와 부담으로 작용했다.저비용 항공사인 이지젯(easyJet), 라이언에어(Ryanair) 등도 승무원의 복장이나 화장에 대해 관대하게 대하고 있다. 반면 대형 항공사들은 아직도 승무원에 대한 규제가 강한 편이다.브리티시에어웨이(British Airways)는 2016년 여성 승무원이 바지를 입지 못하도록 하는 규제를 철폐했다. 2018년 £20억파운드에 달하는 이익을 기록했음에도 불구하고 조종사의 90%에 대해 임금을 삭감했다.▲버진아틀란틱(Virgin Atlantic) 항공기(출처 : 홈페이지)