검색결과
-
[특집-기술위원회] TC 153 - 밸브(Valves)… 현재까지 28개 표준 발행스위스 제네바에 본부를 두고 있는 국제표준화기구(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 등도 포함된다.ISO/TC 153 밸브(Valves)와 관련된 기술위원회는 TC 146, TC 147, TC 148, TC 149, TC 150과 마찬가지로 1971년 결성됐다. 사무국은 프랑스 표준화기구(Association Française de Normalization, AFNOR)에서 맡고 있다.위원회는 헬렌 크로스(Mme Hélène Cros)가 책임지고 있다. 현재 의장은 파스칼 빈지오(M Pascal Vinzio)으로 임기는 2025년까지다.ISO 기술 프로그램 관리자는 메르세 페레 에르난데스(Mme Mercè Ferrés Hernández), ISO 편집 관리자는 파비올라 카라골 리베라(Ms Fabiola Caragol Rivera) 등으로 조사됐다.범위는 산업용 밸브, 어태치먼트 포함한 밸브 액츄에이터, 스팀 트랩 분야의 표준화다. 호환성을 다루는 매개변수, 액추에이터 장착을 위한 밸브 결합 세부 사항, 테스트, 마킹, 품질 요구 사항, 용어 및 기타 관련 매개 변수를 포함하고 있다. 단, 아래 사항은 153 표준화에서 제외된다.△ISO / TC 185의 책임인 안전 및 릴리프 밸브 및 기타 압력 릴리프 장치△ISO/TC 67의 책임인 석유 및 천연가스 산업용 크로스 컨트리 파이프라인용 웰헤드 장비용 생산 밸브 및 밸브△IEC / TC 65의 책임을 맡은 산업 공정 제어 시스템에 사용되는 최종 제어 요소를 형성하는 밸브△ISO / TC 138의 책임을 맡은 주로 플라스틱으로 만들어진 외피를 가진 밸브△위생용 밸브△솔레노이드현재 ISO/TC 153 사무국의 직접적인 책임 하에 발행된 표준은 28개며 SO/TC 150 사무국의 직접적인 책임 하에 개발 중인 표준은 2개다. 참여하고 있는 회원은 20개국, 참관 회원은 25개국이다.□ ISO/TC 153 사무국의 직접적인 책임 하에 발행된 표준 28개 중 15개 목록▷ISO 5115:2023 Industrial valves — Part-turn valve actuation▷ISO 5117:2023 Automatic steam traps — Production and performance characteristic tests▷ISO 5208:2015 Industrial valves — Pressure testing of metallic valves▷ISO 5209:2019 General purpose industrial valves — Marking▷ISO 5210:2023 Industrial valves — Multi-turn valve actuator attachments▷ISO 5211:2023 Industrial valves — Part-turn actuator attachments▷ISO 5752:2021 Metal valves for use in flanged pipe systems — Face-to-face and centre-to-face dimensions▷ISO 6002:2021 Industrial valves — Bolted bonnet steel gate valves▷ISO 6552:1980 Automatic steam traps — Definition of technical terms▷ISO 6552:1980/Cor 1:2009 Automatic steam traps — Definition of technical terms — Technical Corrigendum 1▷ISO 6553:2016 Automatic steam traps — Marking▷ISO 6554:1980 Flanged automatic steam traps — Face-to-face dimensions▷ISO 6704:1982 Automatic steam traps — Classification▷ISO 7121:2016 Steel ball valves for general-purpose industrial applications▷ISO 10434:2020 Bolted bonnet steel gate valves for the petroleum, petrochemical and allied industries □ ISO/TC 153 사무국의 직접적인 책임 하에 개발 중인 표준 2개 목록 ▷ISO 5640 Industrial valves — Mounting kits for part-turn valve actuator attachment ▷ISO/CD 12101 Industrial valves — Measurement, test and qualification procedures for fugitive emissions — Classification system and qualification procedures for type testing of stem seals for valves
-
ISO, 기후 위기 대응을 위한 ‘Net zero’ 가이드라인 발표국제표준화기구(ISO)가 기후 위기에 대응하기 위한 'Net Zero' 가이드라인을 발표했다. 이 가이드라인은 기업을 포함한 조직이 2050년까지 Net Zero 온실가스(GHG) 배출을 달성하기 위한 로드맵을 제공한다. ISO의 가이드라인에 따르면 'Net Zero'는 인간 활동에 의한 온실가스 배출이 특정 기간과 범위 내에서 인간 주도의 제거되어 균형을 이루는 상태로 정의된다. 이러한 균형은 배출 감소, 오프셋, 혁신적인 기술을 포함한 복잡한 프로세스를 통해 달성된다. Net Zero로의 전환은 원천에서의 배출 감소와 이에 대한 탄소배출의 균형을 맞추기 위한 작업으로 이루어진다. 이는 온실가스의 직접적인 감소를 포함한다. 온실가스에는 이산화탄소뿐만 아니라 메탄, 아산화질소, 하이드로플루오로카본 등도 존재한다. 또한 이산화탄소 흡수를 위한 '탄소 흡수기' 투자도 이에 포함된다. 이는 나무 심기, 토양 탄소 관리, 바이오차, 대기 중 이산화탄소 흡수를 위한 직접 공기 캡처 및 저장과 같은 프로젝트를 통해 대기 중 이산화탄소를 흡수하는 것이다. 오프셋은 기업이 다른 기업이나 프로젝트에서 생성된 탄소 크레딧을 구매하여 균형을 맞추는 것을 의미한다. 여기서 Net Zero는 탄소 중립과 차이를 보인다. 기업이 '탄소 중립'을 의미할 때, 그들은 탄소 발자국을 추정하고 이를 줄이기 위해 노력한 뒤 남은 발자국을 오프셋하는 것을 의미한다. 반면에 'Net Zero'는 미래 지향적인 목표로, GHG 배출을 줄이고 이산화탄소 제거를 최대한으로 높이는 것을 의미한다. 또한, 발자국이 남아있을 경우 이를 탄소 크레딧을 통해 상쇄시키는 것을 목표로 한다. 이러한 활동을 위하여 ISO는 COP27에서 Net Zero에 대한 지침을 발표했다. 위 지침은 기업을 포함한 조직이 2050년까지 GHG 배출을 줄이기 위한 표준을 제공하고 있다. Net Zero를 달성하기 위한 표준은 기업들이 일관된 방식으로 협력하고, 환경 오염을 최소화하기 위한 노력을 촉진하는 데 중요한 도구가 된다. 구체적인 핵심 지침 요소로는 ▲배출 감소(에너지 효율성, 재생에너지 등) ▲탄소 오프셋 ▲탄소 크레딧 ▲투명성 및 책임성(배출 모니터링 및 보고 등) ▲이해관계자 참여(집단적 행동 촉진) ▲지속가능한 목표 등이 있다. 이러한 ISO의 Net Zero 가이드라인은 기업들이 환경 목표를 설정하고 노력하는 데 유용한 참고 자료가 된다. 가이드라인 제정을 통해 환경 표준 ISO 14000 시리즈를 보완하며, 향후 기후 변화 대응을 위한 일관된 접근 방식을 도모할 수 있다. - ISO 14090:2019 Adaptation to climate change - ISO 14064-1:2018 Greenhouse gases - ISO 14068-1:2023 Climate change management
-
[미국] 특허법 101조는 발명의 성립성에 대한 내용 규정미국 특허법 101조는 발명의 성립성에 대한 내용을 규정하고 있다. 발명이 특허로 인정을 받을 수 있도록 특허법에서 규정된 형식에 맞도록 특허 명세서가 작성돼야 한다.이와 관련된 예를 보여주는 미국 연방순회항소법원(Federal Circuit)의 2019년 ChargePoint Inc.(원고) 와 Sema Connect Inc.(피고) 사이의 판결은 아래와 같다.국문요약:미국 연방순회항소법원은 본 특허가 “향상된 충전소”에 대한 것이 아니라 “전기 충전소에 인가된 네트워크"에 관한 아이디어라는 점을 언급했다.결과적으로 “네트워크화된 충전소”와 관련된 특허를 무효화했다. 특허 명세서가 미국 특허법의 규칙에 맞지 않아 특허등록이 무효화돤 사례이다.영문요약 : S101 Involving Electric Vehicle TechnologyChargePoint Inc. v. Sema Connect Inc. (F.C. 2019)History:S101 Invalidation:•FC affirmed and invalidated a patent related to networked charging stations.•Patent owner argued that the invention improved charging stations by allowing the stations to be managed from a central location, and allowing drivers to locate stations, and allowing users to interact intelligently with the electricity grid.•Not abstract b/c the invention is tangible and builds a better machine.•District Court:•Disagreed with the patent owner.•Asserted claims were directed to the abstract idea of communication over a network to interact with a device connected to the network.•Federal Circuit:•FC affirmed and analyzed specification:•“specification also makes clear –by what it states and what it does not –that the invention is the idea of network-controlled charging stations.”•“the specification never suggests that the charging station itself is improved from a technical perspective.”•Patent is directed to the idea of communicating over a network applied to electric car charging stations, instead of being directed to an improved charging station.•Many consider this case to be inconsistent with the new USPTO guidance.•Claim 1 included numerous physical electrical components, but FC ignored them.•It may take some time for USPTO and FC to reach an agreement on S101 analysis.
-
식약처, ‘생물학적제제 품질관리실험실 네트워크(Lab-Net) 워크숍’ 개최식품의약품안전처는 백신·혈장분획제제 품질관리에 대한 최신 기술정보를 공유하는 ‘2023년 생물학적제제 품질관리실험실 네트워크(Lab-Net) 워크숍’을 23일 오송 C&V센터에서 개최한다고 밝혔다. 이번 워크숍으로 백신·혈장분획제제 업계의 품질관리 역량을 강화하는 데 도움이 될 것으로 기대된다. ‘생물학적제제 품질관리실험실 네트워크(Lab-Net)’는 식약처와 백신·혈장분획제제 제조·수입업체, 품질 검사기관 등이 참여하는 민·관 협의체로 2011년에 출범한 이후 품질관리 분야에서 활발하게 교류하며 국내 백신, 혈장분획제제 품질을 높이는 데 기여해 왔다. 이번 워크숍은 전문가 강연과 2023년 Lab-Net 운영 현황 및 내년도 계획 등에 대한 발표로 구성돼 있다. 전문가 초청 강연에서는 ▲시험방법 밸리데이션을 위한 통계 방법 ▲미국약전 생물학적 정량법 밸리데이션 ▲데이터 완전성과 컴퓨터 시스템 밸리데이션 ▲오염 관리 전략 수립 접근방법 등을 소개한다. 아울러 ▲백신 역가 시험법 개선 ▲항트롬빈III제제국가표준품 확립공동연구 ▲혈장분획제제 동물대체시험법 추진 등 Lab-Net 운영 성과와 내년도 계획에 대해서도 안내한다. 식약처 관계자는 “이번 워크숍이 백신·혈장분획제제 업계의 품질관리 역량을 강화하는 데 도움을 줄 것으로 기대한다”며 “앞으로도 전문성과 규제과학에 기반한 철저한 품질관리를 수행하여 안전한 제품이 국민께 공급될 수 있도록 최선을 다해 노력할 계획”이라고 밝혔다.
-
[미국] 메드트로닉, 인공호흡기 IP를 다른 업체에 공유미국 의료기기제조업체인 메드트로닉(Medtronic)에 따르면 다른 사람들이 인공 호흡기 제품의 일부 또는 전부를 복사할 수 있도록 전체 설계 사양을 공개할 계획이다.특히 모든 인공 호흡기 지적재산권(IP)을 Puritan BennettTM560(PB560) 인공 호흡기에 사용할 수 있게 했다. 이에 따라 캐나다 기업인 베이리스메디컬(Baylis Medical)은 메드트로닉의 설계 사양을 이용해 인공 호흡기를 생산할 예정이다.이와 같이 많은 생명과학회사들이 코로나(COVID)-19 팬데믹 동안 자신의 지적재산권(IP)에 액세스하는 것을 허락하는 것으로 알려졌다.국제보건기구(WHO)도 COVID-19 관련 특허에 대한 특허풀의 생성을 권장하고 있다. 회사가 특허풀에 특허를 넣으면 특허풀의 라이센스는 다른 사람이나 회사가 자유롭게 사용할 수 있게 된다.또한 일부 제약회사는 COVID-19 임상시험 및 약물개발을 위해 특허를 받은 약물 지적재산권(IP)에 대한 액세스를 허용했다. 이를 위해 제약회사는 라이센스를 자유롭게 부여하거나 경우에 따라 공개 도메인에 특허를 넣을 수 있다.공식적인 특허풀이 아닌 무료로 라이센스 액세스를 허용하는 예로는 http://opencovidpledge.org/가 있다. 이는 인텔 및 기타 회사에서 지원하는 이니셔티브이다.또한 백신 타이탄과 경쟁사인 Sanofi와 GSK는 COVID-19 백신을 개발하기 위해 서로의 기술을 공유할 방침이다. 이와 같은 협력을 통해 COVID-19 팬데믹과 같은 긴급한 위기 상태를 극복하기 위한 희망이 보다 빨리 제시될 수 있을 것으로 기대된다.
-
[기획-디지털 ID 표준] ⑰산업단체와 포럼 - W3C(World Wide Web Consortium)디지털 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) 등이다.W3C(World Wide Web Consortium)는 월드와이드웹(World Wide Web, W3)의 주요 국제 표준 조직으로 1994년 설립됐다. 팀 버너스리(Tim Berners-Lee)가 이끌고 있으며 W3의 장기적인 성장을 보장하기 위한 개방형 표준 개발에 중점을 두고 있다.디지털 ID와 관련된 기술 사양은 △검증 가능한 자격 증명 데이터 모델(Verifiable credentials data model) △웹 인증 : 공개 키 자격 증명 레벨 2에 접근하기 위한 API(Web authentication: An API for accessing public key credentials level 2) △분산 식별자(DID) 기술 사양(decentralised identifiers (DIDs) technical specification) 등이다.검증 가능한 자격 증명 데이터 모델(Verifiable credentials data model)은 웹에서 자격 증명을 표현하는 메커니즘이자 암호화 방식으로 안전하고 개인 정보를 존중하며 기계 확인이 가능한 방식이다.웹 인증 : 공개 키 자격 증명 레벨 2에 접근하기 위한 API(Web authentication: An API for accessing public key credentials level 2)는 강력한 인증을 위해 웹 어플리케이션에서 강력하고 증명되고 범위가 지정된 공개 키 기반 자격 증명을 생성 및 사용할 수 있는 API다.분산 식별자(DID) 기술 사양(decentralised identifiers (DIDs) technical specification)은 DID와 관련된 데이터 형식 및 프로토콜을 지정하고 있다.
-
신기술·신제품 인증기업, 평균 매출 및 신규고용 증가했다‘신기술(NET)·신제품(NEP)인증 최고경영자 포럼’에서 신기술(NET)·신제품(NEP) 인증기업과 인증신청 희망기업들이 함께 인증성과를 공유하고 제도 개선을 모색했다. 산업통상자원부 국가기술표준원은 “신기술(NET)·신제품(NEP) 인증기업들이 인증 전(前) 대비 평균 매출 122~163%, 신규고용 5.1~11명 증가한 것으로 조사됐다”고 3일 더케이호텔에서 개최된 ‘신기술(NET)·신제품(NEP)인증 최고경영자 포럼’에서 밝혔다. 신기술(NET)은 New Excellent Technology, 신제품(NEP)은 New Excellent Product를 의미한다. 아울러 신제품(NEP) 인증제품 매출액 중 공공기관 의무구매 비중이 평균 43.3% 차지했다. 특히 정보통신 분야는 97.4%를 차지함에 따라 다른 분야에 비해 신제품(NEP) 인증기업의 매출액 증가에 공공기관 의무구매제도가 상당한 기여를 한 것으로 조사됐다. 분야별 매출액 중 의무구매 비중은 정보통신이 97.4%, 전기전자가 63.8%, 건설・환경이 44.7% 등을 기록했다. 한편 포럼에 참석한 기업들은 ▲현(現) 20% 이내인 공공기관 의무구매비율 확대 ▲정부 연구개발(R&D)사업 평가 시 인증기업에 가점 부여 ▲금융 투자 지원 신설 등 지원제도 강화 ▲과도한 인증유효기간으로 인해 인증 신기술․제품의 공공기관 의무구매제도가 사실상 시장자율경쟁을 저해하고 있어 제도 개선 등을 요청했다. 이에 인증제도 운영기관, 공공구매 조달기관, 창업투자회사, 인증평가기관 및 관련협회 등 관계자들이 참여한 패널토론에서 동 건의사항에 대한 다양한 찬반 토론을 통해 “적극적인 지원과 개선방안 마련이 필요하다”는 의견을 같이 했다. 국가기술표준원 관계자는 “이번 포럼이 신기술(NET)·신제품(NEP) 인증기업과 인증신청 희망기업들이 함께 인증성과를 공유하고 제도 개선을 모색하는 소통의 시발점이 되기를 희망한다”며 “앞으로 다양한 현장의견을 수렴하여 개선방안을 마련하겠다”고 밝혔다.
-
[기획-디지털 ID 표준] ⑯산업단체와 포럼 - SOG-IS(Senior Officials Group-Information Systems Security)디지털 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) 등이다.SOG-IS(Senior Officials Group-Information Systems Security)는 유럽연합(EU) 또는 유럽 자유 무역 연합(European Free Trade Association, EFTA) 국가의 정부 조직 또는 정부기관간 협정으로 이사회 결정 92/242/EEC (12) 및 후속 이사회 권장 사항 95/144/EC (13)에 따라 작성됐다.SOG-IS 암호 워킹그룹(Crypto Working Group)이 발행한 'SOG-IS Crypto Evaluation Scheme Agreed Cryptographic Mechanisms' 문서는 주로 개발자와 평가자를 대상으로 작성됐다.어떤 암호화 메커니즘이 동의된 것으로 인식되는지, 즉 SOG-IS 암호화 평가 체계의 모든 SOG-IS 참가자가 수락할 순비가 됐는지 지정하는 것을 목적으로 하고 있다.'SOG-IS Crypto Evaluation Scheme Agreed Cryptographic Mechanisms' 문서의 목차를 살펴보면 다음과 같다.목차(Table of contents)1. Introduction1.1 Objective1.2 Classification of Cryptographic Mechanisms1.3 Security Level1.4 Organization of the Document1.5 Related Documents2. Symmetric Atomic Primitives2.1 Block Ciphers2.2 Stream Ciphers2.3 Hash Functions2.4 Secret Sharing3. Symmetric Constructions3.1 Confidentiality Modes of Operation: Encryption/Decryption Modes3.2 Specific Confidentiality Modes: Disk Encryption3.3 Integrity Modes: Message Authentication Codes3.4 Symmetric Entity Authentication Schemes3.5 Authenticated Encryption3.6 Key Protection3.7 Key Derivation Functions3.8 Password Protection/Password Hashing Mechanisms4. Asymmetric Atomic Primitives4.1 RSA/Integer Factorization4.2 Discrete Logarithm in Finite Fields4.3 Discrete Logarithm in Elliptic Curves4.4 Other Intractable Problems5. Asymmetric Constructions5.1 Asymmetric Encryption Scheme5.2 Digital Signature5.3 Asymmetric Entity Authentication Schemes5.4 Key Establishment6. Random Generator6.1 Random Source6.2 Deterministic Random Bit Generator6.3 Random Number Generator with Specific Distribution7. Key Management7.1 Key Generation7.2 Key Storage and Transport7.3 Key Use7.4 Key Destruction8. Person AuthenticationA Glossary
-
[기획-디지털 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