검색결과
-
[특집-기술위원회] TC 154 - 상업, 산업 및 행정 분야 프로세스, 데이터 요소 및 문서(Processes, data elements and documents in commerce, industry and administration)스위스 제네바에 본부를 두고 있는 국제표준화기구(ISO)에서 활동 중인 기술위원회(Technical Committeee, TC)는 TC 1~TC 323까지 구성돼 있다. 기술위원회의 역할은 기술관리부가 승인한 작업범위 내 작업 프로그램 입안, 실행, 국제규격의 작성 등이다. 또한 산하 분과위원회(SC), 작업그룹(WG)을 통해 기타 ISO 기술위원회 또는 국제기관과 연계한다. ISO/IEC 기술작업 지침서 및 기술관리부 결정사항에 따른 ISO 국제규격안 작성·배포, 회원국의 의견 편집 등도 처리한다. 소속 분과위원회 및 작업그룹의 업무조정, 해당 기술위원회의 회의 준비도 담당한다. 1947년 최초로 구성된 나사산에 대한 TC 1 기술위원회를 시작으로 순환경제를 표준화하기 위한 TC 323까지 각 TC 기술위원회의 의장, ISO 회원, 발행 표준 및 개발 표준 등에 대해 살펴볼 예정이다. 이미 다룬 기술위원회와 구성 연도를 살펴 보면 △1947년 TC 1~TC 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~TC 107, △1963년 TC 108~TC 111, △1964년 TC 112~TC 115, TC 117, △1965년 TC 118, △1966년 TC 119~TC 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, TC 147, TC 148, TC 149, TC 150, TC 153 등도 포함된다. ISO/TC 154 상업, 산업 및 행정 분야 프로세스, 데이터 요소 및 문서(Processes, data elements and documents in commerce, industry and administration)와 관련된 기술위원회는 1972년 결성됐다. 사무국은 중국 국가표준화관리위원회(国家标准化管理委员会, Standardization Administration of the P. R. C, SAC))에서 맡고 있다. 위원회는 장 지안팡(Mr Jianfang Zhang)이 책임지고 있다. 현재 의장은 유 시(Mr Yu Shi)로 임기는 2024년까지다. ISO 기술 프로그램 관리자는 로라 매튜(Ms Laura Mathew), ISO 편집 관리자는 이본느 헨(Mrs Yvonne Chen) 등으로 조사됐다. 범위는 비즈니스, 행정 프로세스의 국제 표준화 및 등록이다. 또한 개별 조직 내 및 조직간 정보 교환에 사용되는 지원 데이터의 국제 표준화 및 등록, 산업 데이터 분야의 표준화 활동을 지원한다. 다음과 같은 애플리케이션별 메타 표준 개발 및 유지 관리도 포함된다. △프로세스 사양(다른 기술위원회의 개발이 없는 경우) △콘텐츠가 포함된 데이터 사양 △양식 레이아웃(종이/전자) △표준 개발 및 유지 관리 △프로세스 식별(다른 기술위원회의 개발이 없는 경우) △데이터 식별 △EDIFACT 구문의 유지 관리 현재 ISO/TC 154 사무국의 직접적인 책임 하에 발행된 표준은 37개며 SO/TC 154 사무국의 직접적인 책임 하에 개발 중인 표준은 7개다. 참여하고 있는 회원은 17개국, 참관 회원은 28개국이다. □ ISO/TC 154 사무국의 직접적인 책임 하에 발행된 표준 37개 중 15개 목록 ▷ISO 5054-1:2023 Specification for an enterprise canonical model — Part 1: Architecture ▷ISO 6422-1:2010 Layout key for trade documents — Part 1: Paper-based documents ▷ISO 7372:2005 Trade data interchange — Trade data elements directory ▷ISO 8439:1990 Forms design — Basic layout ▷ISO 8440:1986 Location of codes in trade documents ▷ISO 8440:1986/Cor 1:2000 Location of codes in trade documents — Technical Corrigendum 1 ▷ISO 8601-1:2019 Date and time — Representations for information interchange — Part 1: Basic rules ▷ISO 8601-1:2019/Amd 1:2022 Date and time — Representations for information interchange — Part 1: Basic rules — Amendment 1: Technical corrections ▷ISO 8601-2:2019 Date and time — Representations for information interchange — Part 2: Extensions ▷ISO 9735-1:2002 Electronic data interchange for administration, commerce and transport (EDIFACT) — Application level syntax rules (Syntax version number: 4, Syntax release number: 1) — Part 1: Syntax rules common to all parts ▷ISO 9735-2:2002 Electronic data interchange for administration, commerce and transport (EDIFACT) — Application level syntax rules (Syntax version number: 4, Syntax release number: 1) — Part 2: Syntax rules specific to batch EDI ▷ISO 9735-3:2002 Electronic data interchange for administration, commerce and transport (EDIFACT) — Application level syntax rules (Syntax version number: 4, Syntax release number: 1) — Part 3: Syntax rules specific to interactive EDI ▷ISO 9735-4:2002 Electronic data interchange for administration, commerce and transport (EDIFACT) — Application level syntax rules (Syntax version number: 4, Syntax release number: 1) — Part 4: Syntax and service report message for batch EDI (message type — CONTRL) ▷ISO 9735-5:2002 Electronic data interchange for administration, commerce and transport (EDIFACT) — Application level syntax rules (Syntax version number: 4, Syntax release number: 1) — Part 5: Security rules for batch EDI (authenticity, integrity and non-repudiation of origin) ▷ISO 9735-6:2002 Electronic data interchange for administration, commerce and transport (EDIFACT) — Application level syntax rules (Syntax version number: 4, Syntax release number: 1) — Part 6: Secure authentication and acknowledgement message (message type - AUTACK) □ ISO/TC 154 사무국의 직접적인 책임 하에 개발 중인 표준 7개 목록 ▷ISO/WD 5909 Data interchange processes of blockchain based negotiable maritime bill of lading related to e-Commerce platform ▷ISO/AWI 7372 Trade data interchange — Trade data elements directory ▷ISO 8601-2:2019/DAmd 1 Date and time — Representations for information interchange — Part 2: Extensions — Amendment 1 ▷ISO/AWI 14533-3 Processes, data elements and documents in commerce, industry and administration — Long term signature profiles — Part 3: Long term signature profiles for PDF Advanced Electronic Signatures (PAdES) ▷ISO/WD TR 19626-3 Processes, data elements and documents in commerce, industry and administration —Trusted communication platforms for electronic documents — Part 3: Blockchain-based implementation guideline ▷ISO/DIS 20197-1 Buy-Ship-Pay Reference Data Model — Part 1: Business Requirement Specification (BRS) ▷ISO/DIS 23355 Visibility data interchange between logistics information service providers
-
[기획-디지털 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
-
[영국] MSL(MSL Solution Providers), UKAS 4045로부터 살생물제 서비스에 대한 최신 ISO/IEC 17025:2017 인증 획득영국 선도적인 미생물 테스트 회사 MSL(MSL Solution Providers)에 따르면 2022년 7월 15일 UKAS 4045로부터 살생물제 서비스에 대한 최신 ISO/IEC 17025:2017 인증을 획득했다.UKAS의 평가에 따라 2022년 6월 30일 승인됐으며 UKAS 4045인증을 받은 화장품 테스트 서비스 업체로 부상했다. MSL은 사내 실험실과 모든 모든 필수 시험들이 업데이트된 ISO/IEC 17025 표준을 준수하고 있음을 보장받게 됐다.또한 MSL은 UKAS에 의해 ISO/IEC 17025:2017 표준을 인증받은 소수의 독립 연구소 중 하나다. 이는 가능한 최고의 품질 테스트 서비스를 제공하겠다는 MSL의 의지를 반영하고 있다.ISO/IEC 17025:2017 표준은 테스트 연구소의 역량에 대한 일반적인 요구사항을 명시하고 있다. 이전에는 실험실만 인증의 대상이었으나 개정된 표준은 해당시험이 수행되는 실험실뿐 아니라 필수 시험 자체를 포함한다.최근 MSL은 환경 지속 가능성과 관련한 ISO 14001 인증과 최고 수준의 정보 보안 관리를 준수하고 있음을 확인해 주는 ISO 27001 인증을 추가로 획득했다.
-
[미국] 국제표준화기구(ISO), 조직과 전문가들의 클라우드 보안 사고 해결 ISO/IEC 27017표준국제표준화기구(International Organization for Standardization, ISO)에 따르면 국제전기기술위원회(International Electrotechnical Commission, IEC)와 함께 개발한 ISO/IEC 27017 표준이 클라우드 보안 사고를 해결할 수 있다.ISO/IEC 27017 표준은 정보보안 통제 구현에서 클라우드 서비스 고객, 클라우드 서비스 제공자(cloud service providers, CSPs)를 지원하는 지침을 제공한다.지침 중 일부는 클라우드 서비스 고객과 관련이 있으며 일부는 CSP와 연관돼 있다. 지침의 적용은 위험 평가 결과와 보안 요구사항의 특성에 따라 다르다.ISO 27017은 자산관리, 반환, 접근 통제, 물리적 보안, 준수 등을 포함해 주요 제어 영역에 초점을 맞춰 ISO/IEC 27001/270702 지침을 보완하고 있다. 국제표준은 다음과 같이 7가지 새로운 규제를 제시하고 있다.6.3.1 클라우드 컴퓨팅 환경 내에서 역할 및 책임공유8.1.5 클라우드 서비스 고객 자산 제거9.5.1 가상 컴퓨팅 환경에서의 분리9.5.2 가상 시스템 강화12.1.5 관리자의 운영 보안12.4.5 클라우드 서비스 모니터링13.1.4 가상 및 물리적 네트워크에 대한 보안 관리 조정ISO/IEC 27017 표준은 조직과 보안 전문가들이 고민하고 있는 문제를 해결하는데 도움이 된다. 미국 IT기업 뉴스 제공업체 베타뉴스(BetaNews)의 설문조사 결과에 따르면 "응답자의 36%가 지난 12개월 동안 심각한 클라우드 보안 데이터 유출 및 침해 사고에 시달리고 있다."고 밝혔다.클라우드 전문가 300명을 대상으로 실시한 설문조사에서 참가자 10명 중 8명이 클라우드 구성 오류와 관련한 데이터 유출에 취약할 것이라고 우려했다. 응답자의 64%는 1년 후에도 문제가 그대로 유지되거나 악화될 것이라고 답변했다.클라우드 전문가 20%는 피로 경고, 잘못된 긍정, 인적 오류 등이 클라우드 보안 노력을 방해하고 있다고 봤다. 또한 "36% 이상은 클라우드 보안 전문가를 고용하고 보유하는데 어려움이 있다"고 밝혔다.나머지 36% 가까운 응답자는 "클라우드팀에 보안 교육을 시키는데 어려움을 겪고 있어 클라우드 보안 유출 및 침해 사고 예방을 위해 전략적 접근 방식이 필요하다"고 지적했다.