검색결과
-
국표원, ‘한-아세안 표준협력 공동연구 워크숍’ 개최작년 한-아세안 정상회의에서 발표한 ‘한-아세안 연대구상’의 충실한 이행을 지원하기 위해 우리나라 제2의 교역파트너이자 세계 5위 경제권인 아세안과 표준협력을 강화한다. 산업통상자원부 국가기술표준원은 13일 서울 인터컨티넨탈 코엑스 호텔에서 한국과 아세안 간 표준협력 강화 방안을 모색하기 위해 아세안 10개국 표준 담당관 56명 등 120여 명이 참석한 가운데 ‘한-아세안 표준협력 공동연구 워크숍’을 개최했다고 밝혔다. 이에 치열한 국제표준 경쟁에 대응해 한-아세안 간 정례적인 표준대화채널이 구축될 전망이다. 이번 행사는 처음으로 개최되는 한국과 아세안 간 표준협력 워크숍으로 2019년부터 수행해온 공동연구 성과를 공유하고 협력분야 확대 등 향후 발전 방안을 논의하기 위해 마련됐다. 한-아세안 양측 표준전문가들은 스마트제조, 스마트시티, 녹색건축 등 3개 우선협력분야에 대한 기술 현황 및 표준화 동향을 발표하고 실질적인 성과 도출 방안을 제안했다. 본 행사에 이어 17일에는 국표원-아세안표준품질자문위 간 제4차 공동연구그룹 회의를 개최해 이번 워크숍 결과를 반영한 한-아세안 표준협력체계 수립 방안을 협의할 예정이다. 진종욱 국표원장은 “이번 워크숍은 올 9월 한국과 아세안 정상이 한-아세안 관계를 최고 파트너십인 ‘포괄적 전략 동반자 관계’로 격상할 것을 합의한 상황에서 양측 간 표준 파트너십을 강화하는 뜻깊은 자리”라며 “치열한 국제표준 경쟁에 대응하여 한-아세안 간 정례적인 표준대화채널을 구축해 나가겠다”고 밝혔다.
-
국내 시험만으로 전기차충전기 미국인증 획득한다산업통상자원부 국가기술표준원은 14일 전기차충전기 전문업체인 대영채비㈜를 방문해 상호인정을 통한 해외인증 획득 성공사례를 청취하고 성과 확산 방안을 논의했다고 밝혔다. 대영채비㈜는 지난 4월 대통령 미국 국빈 방문 시 한국기계전기전자시험연구원(KTC)과 미국 UL(미국 대표 시험인증기관)이 체결한 업무협약을 통해 미국 에너지스타 인증을 국내 시험만으로 획득했다. 10월에는 사우디 국빈 방문 시 경제사절단으로 참여해 사우디에 전기차 충전 인프라 수출 계약을 체결하는 데 성공했다. 국표원은 국표원이 지난 6월 발표한 ‘해외인증 종합지원 전략’의 일환인 해외 시험인증기관과 국내기관 간 상호인정 협약을 적극 활용하고 정부의 세일즈 외교를 기회로 활용한 성공사례로 큰 의미가 있다고 언급했다. 현장에서 배경수 대영채비㈜ 전무는 “제품을 해외로 보내지 않고도 국내 시험으로 해외인증을 획득함으로써 시험 비용뿐만 아니라 물류비, 인증획득 기간 등도 절감되는 상호인정 효과를 톡톡히 보았고, 앞으로도 적극 활용할 예정”이라고 말했다. 진종욱 국표원장은 “해외인증 애로의 어려움을 근본적으로 해소하기 위해서는 상호인정뿐만 아니라 국내에서 시험인증이 가능하도록 기반 마련도 중요하다”며 “앞으로도 국표원은 해외인증을 위한 상호인정 품목 및 기반을 지속 확대하는 한편 단기적으로는 국내 시험인증기관과 협력해 해외인증 시험 비용 인하, 패스트트랙 등을 통해 수출 확대를 지원하겠다”고 밝혔다.
-
국표원-식약처, 세계무역기구 무역기술장벽 위원회 회의 참석산업통상자원부 국가기술표준원과 식품의약품안전처는 7일부터 10일까지 진행된 2023년 제3차 세계무역기구 무역기술장벽(WTO TBT) 위원회 정례회의에 참석해 국내 기업 수출에 걸림돌이 되는 해외기술규제에 대해 상대국에 애로를 제기하고 협력 방안을 논의했다고 밝혔다. 이번 위원회에서는 우리 주요 수출 품목인 자동차, 반도체 등에 영향을 줄 것으로 예상되는 과불화화합물(PFAS) 사용 제한 규제를 포함해 6개국을 대상으로 배터리, 휴대폰, 화장품, 의료기기 등 산업 관련 11건의 규제에 대해 특정무역현안으로 이의를 제기했다. 또한 과불화화합물(PFAS) 규제 대응 관련 미국, 일본과 양자회의를 통해서도 국내 업계 우려를 전달하고 협력 강화를 제안하는 한편 유아용 섬유제품 안전기준 등 관련해 유럽연합(EU) 측과 양자협의를 실시하고 무역기술장벽과 관련 애로 해소를 위해 지속적으로 협력해 나가기로 했다. 정부는 이번 협상 결과를 수출기업 및 관계 부처와 공유할 예정이다. 국표원 관계자는 “해결되지 않은 애로에 대해서는 산업계와 함께 대응 전략을 마련해 WTO TBT 위원회를 통해 지속적으로 이의를 제기하고 해외 규제당국과의 대화, 협력을 통한 해결방안 모색 등 다양한 노력을 기울일 계획”이라고 전했다. 이어 “해외기술규제로 어려움을 겪는 수출기업들은 ‘해외기술규제대응 정보시스템(KnowTBT)’을 통해 정부의 도움을 요청해 달라”고 덧붙였다.
-
한국표준과학연구원, 국제도량형위 물질량자문위원회 개최한국표준과학연구원(KRISS)은 7일부터 10일까지 국제도량형위원회(CIPM) 산하 물질량자문위원회(CCQM)의 연례 가을 회의를 개최했다고 밝혔다. 이번 회의는 첨단바이오 분야 미래 측정표준을 만들 중요한 계기가 될 것으로 기대된다. CIPM은 전 세계 측정표준을 관장하는 국제기구로 산하에 전기, 시간 등 국제단위계를 관장하는 10개 자문위원회를 두고 있다. 이 가운데 CCQM은 화학, 의료, 바이오 등 인류 삶의 질과 직결된 국제 과학기술 현안을 협의해 CIPM에 자문을 제공하는 역할을 한다. 팬데믹 이후 3년 만에 대면 개최되는 이번 회의에는 미국, 영국, 일본, 독일 등 21개국에서 125명의 바이오 분야 측정표준 전문가들이 참석했다. 참석자들은 이틀간 핵산, 단백질, 세포 등 3개 실무분과별로 기술적인 논의를 거친 후 셋째 날 전체 회의를 통해 새로운 팬데믹 발생 시 대응 방안, 첨단바이오 산업계와의 발맞추기 전략 등을 논의했다. 3개 분과가 모두 참여하는 전체 회의는 분야별 측정기술을 융합해 산업의 급격한 발전에 대응하기 위함으로, 분과 수립 후 10년 만에 최초 개최됐다. CCQM 회의의 국내 개최는 지난 2006년 이후 처음이다. 팬데믹을 겪으며 국내 바이오산업의 국제적 위상이 높아진 것에 더해 전 세계 표준기관 중에서도 독보적인 KRISS의 첨단바이오 측정능력을 인정받은 결과다. KRISS는 CCQM의 창립 멤버로서 각국 표준기관 간 국제비교를 적극 주관하며 바이오물질 측정표준의 새로운 접근법을 제시해왔다. KRISS 바이오분석표준그룹 박상열 책임연구원은 지난 2018년부터 CIPM 위원이자 CCQM 의장으로 활동 중이다. 박상열 책임연구원은 “이번 회의 개최는 글로벌 수준의 바이오 측정표준 연구개발을 선도하는 KRISS의 입지를 한층 강화할 것”이라고 전했다. 박현민 KRISS 원장은 “전 세계 표준기관 바이오 전문가들이 머리를 맞댈 이번 행사는 첨단바이오 분야 미래 측정표준을 만들 중요한 계기가 될 것”이라고 밝혔다.
-
TTA, 대구지역 ICT 표준 인사이트 개최한국정보통신기술협회(TTA)는 15일에 ‘AI·로봇’을 주제로 대구 엑스코(EXCO)에서 ‘ICT 표준 인사이트’를 개최한다고 밝혔다. ‘ICT 표준 인사이트(ISI, ICT Standards Insight)'는 지역별 주력산업과 정보통신기술(ICT) 간 융합 촉진을 통한 지역 산업 발전 및 경제 활성화를 위해 지역 기업 및 대학(원)생을 대상으로 개최되는 맞춤형 교육 프로그램이다. 이번 행사에 AI·로봇 분야 전문가들이 한자리에 모여 기술과 표준, 지식과 경험을 공유하는 협력과 교류의 장이 될 전망이다. 이번 행사는 대구광역시 주최의 제12회 대구국제로봇산업전의 부대행사로 개최되며 인간과 AI·로봇이 공존하는 미래를 지향하는 관련 기술과 표준을 중심으로 다양한 프로그램이 마련됐다. ICT 표준화 전문기관인 TTA에서 ICT 표준의 개요 및 산·학·연에 제공하는 표준화 활동지원 사업 소개를 시작으로 ▲로봇 기술 ▲로봇 표준 ▲AI 표준 등 3가지 세션으로 진행될 예정이다. 로봇 기술 세션에서는 로봇 R&D 현황, 5G 기반 로봇 실증사업 및 제조, 의료 및 웨어러블 AI 로봇 등 첨단 융합 기술을 소개하고, 로봇 표준 세션에서는 자율주행 로봇, 서비스 지원 로봇 등 글로벌 표준화 동향 및 이슈에 대해 살펴본다. 마지막 AI 표준 세션에서는 차세대 인공지능 국제표준 선점을 위한 로드맵, 생성형 AI의 역할과 신뢰성 확보 방안 등으로 프로그램을 구성해 AI·로봇 분야 전문가들이 한자리에 모여 기술과 표준, 지식과 경험을 공유하는 협력과 교류의 장이 될 것으로 기대된다. 손승현 TTA 회장은 “로봇과 인공지능 기술이 안전성과 신뢰성을 확보하기 위해서는 표준이 필수적”이라며 “이번 행사를 통해 관련 기술과 표준을 폭넓게 이해하는 계기가 되길 바란다” 고 밝혔다. 이어 “지역 기업과 대학이 지역 거점 기술을 발전시키고 인재를 육성하여 지역경제 발전을 견인할 수 있도록 지역 맞춤형 ICT 표준 교육을 지속적으로 지원할 것”이라고 말했다.
-
TTA, 데이터 품질인증 서비스 개시한다한국정보통신기술협회(TTA)는 7일부터 데이터 품질인증 서비스를 개시한다고 밝혔다. 데이터 품질인증 서비스는 다양한 분야에서 생산·활용되는 데이터의 품질수준을 높이고 국내 데이터 산업 활성화의 발판이 될 것으로 기대된다. 데이터 품질인증제도는 ‘데이터 산업진흥 및 이용 촉진에 관한 기본법’을 기반으로 데이터의 내용 및 관리체계를 심사하여 인증을 부여하는 제도로 지난 7월 과기정통부는 TTA를 포함하여 3개 품질인증기관을 지정했다. TTA는 데이터 품질인증기관으로 지정받은 후 과기정통부와 인증 서비스 개시를 위한 각종 규정 및 절차를 논의해왔으며 7일 본격적인 인증 서비스를 시작하기로 했다. 이번에 개시하는 데이터 품질인증 서비스는 정형 데이터를 대상으로 하며 네년에는 데이터 관리체계 및 비정형 데이터까지 인증 범위를 확대할 예정이다. 손승현 TTA 회장은 “이번 데이터 품질인증 서비스는 다양한 분야에서 생산·활용되는 데이터의 품질수준을 높이고, 궁극적으로는 국내 데이터 산업 활성화의 발판이 될 것으로 기대한다”며 “특히 TTA는 의료, 금융 및 AI 데이터에 대한 전문성을 확보하고 있으며 이를 통해 공신력 있는 시험인증 서비스를 제공할 것”이라고 밝혔다.
-
[기획-디지털 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와 관련된 데이터 형식 및 프로토콜을 지정하고 있다.
-
[기획-디지털 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