▲ 디지털 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

▲ 도나 스포츠(Dorna Sports) 홍보자료[출처=도나 스포츠 홈페이지]스페인 국제 스포츠 매지니지먼트 회사인 도나 스포츠(Dorna Sports)에 따르면 최근 국제표준화기구(ISO)로부터 ISO 2012 인증을 획득했다. ISO 2012는 이벤트 회사의 지속가능 경영을 평가하는 표준이다. 이벤트는 마이스(MICE)로 정의되며 국제회의, 인센티브관광, 컨벤션, 전시박람회 등을 의미한다. 이러한 유형의 사업을 수행하는 이벤트 기획자, 장소, 마케팅 조직 등이 경제·환경·사회적으로 지속 가능한 경영시스템을 운영하고 있는지 평가한다. 따라서 ISO 2012 표준은 이벤트의 경제·환경·사회적 영향을 개선하거나 유지할 수 있는 프레임워크를 제공한다. 현재 표준에 적합한 운영체계를 구축해야 함을 물론 미래를 향해 지속적인 개선 계획도 수립해야 한다.이러한 노력은 모토 GP(MotoGP, Grand Prix Motorcycle Racing)의 연맹전, 제조업체, 팀, 임직원, 공급업체, 스폰서, 연맹, 팬 등을 포함한 모든 이해관계자와 협력이 필요하다.도나 스포츠는 TÜV Nord로부터 인증을 획득했으며 모토스포츠를 운영하는 기업 중 최초로 ISO 2012 인증받은 기업으로 자리매김했다. 이전에는 포뮬라 E가 ISO 2012를 획득한 유일한 모토스포츠 범주에 포함됐다.참고로 도나 스포츠는 1988년 설립됐으며 스페인 마드리드에 본사를 두고 있다. 모토싸이클 그랑프리 대회인 모토 GP의 개최자로서 상업적 권리를 보유하고 있다. 

카타르 보건부(Ministry of Public Health, MoPH)에 따르면 산하 식품안전과(Food Safety Department)는 ANSI 국제 인증 위원회(ANSI National Accreditation Board, ANAB)로부터 국제 인증을 획득했다.인증 분야는 ISO 17020 시스템에 따라 수입 및 현지 식품, 현지 업소의 검사 분야로 식품의약품안전처가 시행하는 기준 및 검사방법이 국제 기준을 준수하고 있음를 확인받은 것이다.보건부 식품안전 및 환경보건(Food Safety and Environmental Health)국은 ANAB의 국제 인증은 국제 수준에서 검사 결과에 대한 신뢰도와 신뢰성을 강화하는데 공헌했다고 판단했다. 검사 기관의 무결성과 기술 능력을 증명하는 공식적인 인정이기 때문이다.또한 ISO/IEC 17020에 따라 제공되는 서비스의 효율성과 품질에 대한 고객 및 수혜자에게 신뢰를 제공한다. 지역 수준에서 뛰어난 성과는 기술 운영의 성과를 향상시키고 절차를 가속화해 통제하는데 도움이 된다.식품안전부의 현지 및 수입 식품 통제에 특화된 부서는 ANAB 전문가들에 의해 감사를 받아 인증에 요구되는 기준과 요건을 통과했다. 보건부(MoPH)는 국내 및 수입 식품관리부서가 ISO 인증을 획득함에 따라 식품안전부 산하 모든 부서의 식품관리시스템을 최상의 국제기준에 따라 운영할 방침이다.이번 인증을 통해 카타르 정부는 글로벌 추세에 맞춰 국내 먹거리 안전 시스템을 개선할 계획이다. 전체 식품의 라이프 싸이클에서 안전 수준도 향상될 것으로 전망된다.▲ 카타르 보건부(Ministry of Public Health, MoPH) 홈페이지

남아프리카공화국 게임 테스트기업인 GLI Africa(Gaming Laboratories International Africa)에 따르면 2022년 8월 10일 중요 침투 및 취약성 평가 인증을 획득했다.GLI 아프리카는 독립성과 무결성을 바탕으로 글로벌 게임 산업 분야에서 세계적인 수준의 테스트, 인증, 전문 서비스를 제공하고 있다. 이번 새로운 인증을 통해 GLI는 파트너 기업들이 필요로하는 표준 테스트를 제공할 수 있게 됐다. GLI 아프리카는 이미 ISO/IEC 17025 테스트 및 교정 서비스(Testing and Calibration Services)를 위한 SANA 인증 서비스 및 ISO/IEC 17020 검사 서비스(Inspection Services)를 제공하고 있다.과거 20년 동안 GLI 아프리카는 2개의 인증을 획득해 파트너 기업들에게 서비스 제공했다. 이번에는  ISO 17025 인증의 한 부분인 침투 테스트 및 취약성 평가에 대한 인증을 획득해 평가 역량을 확장했다.서비스에 대한 전체 감사를 수행하기 위해 GLI 아프리카를 선택하는 고객을 위해 종단간(end-to-end) 서비스로 이어지게 된다.또한 아프리카 지역 베팅 운영자에게 정보 보안 경영 시스템 테스트가 필수적인 것과 같이 침투 테스트 및 취약성 평가 인증 혜택을 받을 수 있게 됐다.SANS 1718 파트4 기술 표준을 기반으로 하는 요구 사항은 출시일로부터 90일 이내에 모든 게임 작품은 침투 테스트 및 취약성 평가를 받아야 한다. 평가를 받은 후 12개월 마다 동일한 테스트 평가를 반복적으로 받아야 한다.▲GLI Africa(Gaming Laboratories International Africa) 홈페이지

나이지리아 GT은행(GTBank)에 따르면 중앙은행(CBN)으로부터 금융지주회사로 운용할 수 있는 승인을 받은 것으로 드러났다.GT은행은 기존의 보증신탁은행에서 금융지주회사로 사업 영역을 확장했다. 구조조정의 개요에 따르면 GT은행의 발행된 주식을 금융지주회사의 주식과 1대1로 교환할 방침이다. 기존 해외주식예탁증서(GDR)도 금융지주회사가 새로 발행할 해외주식예탁증서(GDR) 1대1로 교환하자는 제안이 나왔다.금융지주회사는 기타 금융기관으로서 중앙은행(CBN)의 규제를 받게 되며 나이지리아증권거래소(NSE)와 런던증권거래소(LSE)에 상장된다.▲GT은행(GTBank) 홈페이지