검색결과
-
중소벤처기업부, 탄소국경조정제도(CBAM) 대응 기반(인프라)구축 지원사업 참여기업 2차 모집개시중소벤처기업부에 따르면 4월 7일(화)~5월 31일(금)까지 2024년 중소기업 탄소국경조정제도(CBAM) 대응 기반(인프라)구축 지원사업에 참여할 기업을 모집(2차)한다. 탄소국경조정제도(Carbon Border Adjustment Mechanism, 이하 CBAM)는 ‘23년 10월부터 시범 시행되었다. 유럽연합(EU)으로 탄소 집약적 제품을 수출 할 경우 생산과정에서 배출한 탄소량에 상응하는 인증서 구매를 의무화하는 제도다. 탄소집약적 제품은 철강, 알루미늄, 비료, 수소, 시멘트, 전력 등 6개 품목으로 ’24년과 ‘25년 2년간의 전환기간(보고의무만 있음)을 거쳐 ‘26년부터 본격 시행된다. 중소기업 탄소국경조정제도(CBAM) 대응 기반(인프라)구축 사업은 탄소배출량 측정‧보고‧검증 비용을 지원해 EU 수출기업의 관세 부담을 줄이는 등 국제적(글로벌) 탄소 규제에 선제적으로 대응하기 위해 올해 신설됐다. 탄소국경조정제도(CBAM) 대상 6개 품목을 EU로 직‧간접 수출하는 중소기업을 대상으로 제품별 탄소배출량 산정‧감축 상담(컨설팅)과 EU 인정기관의 검증보고서 발급을 동시에 지원할 예정이다. 현장을 방문하는 전문인력에게 맞춤형 상담(컨설팅)을 지원 받을 수 있는 분야는 △생산공정 분석 △제품별 배출량 산정을 위한 공정 분할 △배출량 산정 경계 설정 △EU 측 수입업자에 배출량 보고 등이다. 우리 중소기업이 탄소국경조정제도(CBAM)라는 제도를 이해하고 대응할 수 있도록 EU에서 인정한 기관이 본 사업의 검증기관으로 참여해 현지 노하우를 전수하는 등 직접적인 도움을 줄 것으로 기대된다. 중소벤처기업부 김우순 기술혁신정책관은 “26년 EU 탄소국경조정제도(CBAM)의 본격 시행에 대비해 우리 중소기업은 지금부터 준비할 필요가 있다”며, “본 사업을 통해 EU에 수출하는 중소기업의 탄소국경조정제도(CBAM) 대응 부담을 완화해 나가겠다”고 강조했다. 참고로 2024년 중소기업 탄소국경조정제도(CBAM) 대응 기반(인프라)구축 지원사업 모집공고의 자세한 내용은 중소벤처기업부 누리집(www.mss.go.kr), 중소벤처24 누리집(www.smes.go.kr), ESG 통합플랫폼(kdoctor.kosmes.or.kr/esgplatform) 등에서 확인할 수 있다.
-
중소벤처기업부, 해외규격인증획득지원사업 일반분야(트랙) 2차 참여기업 모집중소벤처기업부(장관 오영주)에 다르면 ‘2024년 일반분야(트랙) 2차 해외규격인증획득지원사업’에 참여할 중소기업을 5월 2일(목)부터 5월 31일(금)까지 모집한다. ‘해외규격인증획득지원사업’은 수출대상국이 요구하는 인증을 획득하는데 필요한 인증비, 시험비, 상담비(컨설팅비) 등 소요 비용의 일부(50%~70%)를 기업당 최대 1억원을 수출 희망 중소기업에 지원하는 사업이다. 지원 사업은 손속분야와 일반분야로 구분해 운영하며 신속분야(패스트트랙)는 대상 인증 7종*으로 신속 지원을 위해 평가 기간을 줄였다. 일반분야(트랙)는 7종 외 536종의 인증 획득을 지원하게 된다. 패스트트랙 대상 인증은 유럽 CE(전기전자, 통신 및 기계분야), 미국 FCC(전기전자), 국제 IECEE(전기전자), 일본 PSE(전기전자), 유럽 CPNP(화장품), 국제 HALAL(식품, 화장품 등), 미국 FDA(의료기기 class1)등이다. 이번 일반분야(트랙) 2차 모집은 유럽 CE, 미국 FDA, 중국 NMPA 등 수출대상국에서 요구하는 536개 해외인증 획득 비용을 약 200개사 내외에 지원할 예정이다. 따라서 일반분야(트랙) 536종 인증은 5월 말까지 지원해야 된다. 신속분야(패스트트랙) 인증 7종을 획득하고자 하는 기업은 신속분야(패스트트랙)로 신청해야 하며 8.30.(금)까지 상시 접수를 진행하고 있다. 중소벤처기업부 최원영 글로벌성장정책관은 “국제적(글로벌) 보호무역주의 기조가 강화됨에 따라 중소기업의 해외인증 지원 수요가 증가하고 있다.”며, “중기부는 해외규격인증획득지원사업을 통해 이러한 수요를 지속적으로 충족해 나가겠다.”고 밝혔다. ‘해외규격인증획득지원사업’ 공고문의 구체적인 내용은 중소벤처기업부 누리집(www.mss.go.kr), 해외규격인증획득지원센터 누리집(www.smes.go.kr/globalcerti), 관리기관(KTR) 누리집(www.ktr.or.kr) 등에서 확인할 수 있으며 해외규격인증획득지원센터 누리집(www.smes.go.kr/globalcerti)을 통해 신청할 수 있다.
-
중소벤처기업부, 중소기업 인력양성대학 주관기관 신규 모집중소벤처기업부(장관 오영주)에 따르면 지난 4월 15일(월) 중소기업 인력양성대학 사업에 참여할 주관대학 및 사업단 등 주관기관 신규 모집을 발표했다. 중소기업 인력양성대학은 대학-중소기업 산학협력 교육을 통해 우수 인재를 양성하고 중소기업으로의 인력 유입을 촉진하는 사업이다. ‘중소기업 계약학과’와 ‘기술사관’으로 구성되어 있다. 중소기업 계약학과는 대학에 학위과정을 개설하고 중소기업 재직자(또는 채용예정자)를 대상으로 학위취득(전문학사~박사, 과정당 2년)을 지원해 기업의 핵심 인력으로 양성하는 선취업-후진학 방식의 인재 양성 프로그램이다. 기술사관은 직업계고 2년, 전문대학 2년 등 4년간의 연계교육을 실시해 중소기업 현장에서 요구하는 기술 인력을 체계적으로 양성하는 프로그램이다. 2024년 신규 모집 규모는 ‘중소기업 계약학과’ 3개와 ‘기술사관’ 1개다. 모집 분야는 산업구조 개편에 따른 인력 수요(5대 핵심분야* 등)에 부응하기 위해, 첨단산업**, 지역 전략산업 등 미래 유망분야를 우선 선정할 방침이다. * 참고로 5대 핵심분야는 첨단분야 인재양성 전략의 일환으로 2023년 2월 출범한 제1차 인재양성전략회의에 포함된 △항공·우주·미래모빌리티 △바이오헬스 △첨단부품·소재(반도체) △디지털 △환경·에너지 분야 등이다. 5대 핵심분야는 △정책일관성(국정과제, 첨단분야 주요 정책 등) △시급성(인력수급전망) △국제표준(OECD 산업분류 체계)을 고려해 범부처 협업을 통해 국가적 역량 결집이 필요하다고 판단해 도출됐다. 첨단산업은 △반도체 △바이오·헬스 △미래 모빌리티 △친환경·에너지(탄소중립) △로봇 △빅데이터·AI △사이버보안·네트워크 △우주항공·해양 △차세대 원전 △기술보호 등이다. 중소벤처기업부는 신규로 선정되는 중소기업 계약학과에 7천만원, 기술사관 사업단에 3.2억원 내외의 교육과정 운영비를 매년 지원할 계획이며 중소기업 계약학과 학생에게는 등록금의 일부를(65~100%) 학위과정 2년 동안 지원한다. 또한 기술사관 참여 학생에게는 산업기능요원 우선 추천 등을 지원한다. 중소벤처기업부 박종찬 중소기업정책관은 “중소기업의 현장수요를 반영한 교육과정 운영을 통해 신기술·신산업 분야 우수 기술기능인력을 양성하고, 청년 일자리 창출과 중소기업 인력난 해소에 기여하기를 기대한다. 첨단산업 분야 중소기업 전문인력 양성을 위해 중소기업 계약학과, 기술사관 등 중소기업 인력양성 프로그램을 지속적으로 확대할 계획이다”고 밝혔다. 참여를 희망하는 학교는 4월 15일(월)부터 5월 10일(금)까지 중소기업인력지원 종합관리시스템 누리집(smes.go.kr/sanhakin)을 통해 신청 가능하며 자세한 내용은 인력정책과(민준현 사무관 : 044-204-7450)에 문의하면 된다.
-
식약처-싱가포르 보건과학청, 의약품 상호인정협정 체결식품의약품안전처는 싱가포르 보건과학청과 대한민국-싱가포르 간 의약품 제조소에 대한 제조·품질관리기준(GMP) 실태조사 결과를 상호인정하는 ‘의약품GMP 상호인정협정(MRA)’을 26일 체결했으며 이번 협정은 5월부터 공식 발효될 예정이라고 밝혔다. 싱가포르 보건과학청(Health Sciences Authority, HSA)은 싱가포르의 의약품, 의료기기 등 의료제품 인허가 및 안전관리를 담당하는 정부 부처다. 이날 오유경 식품의약품안전처장과 미미 총 보건과학청장은 양국을 대표해 한-싱가포르 FTA 분야별 부속서에 ‘의약품 GMP’를 추가하기 위한 교환각서에서명했으며 향후 한-싱가포르 양국은 상대국 정부가 실시한 의약품 GMP 적합 평가 결과를 자국에서도 동등하게 인정하기로 했다. 이에 따라 국내 기업들은 싱가포르에 의약품을 수출할 때 식약처가 발급한 GMP 적합판정서를 그대로 인정받아 허가 기간이 단축되고 그에 따른 비용이 절감되는 효과를 얻는다. 싱가포르는 태평양과 인도양이 만나는 지리적 위치, 우수한 연구 인력 등 높은 잠재력을 토대로 많은 다국적 제약사가 아시아 시장 진출을 위해 거점으로 삼고 있는아시아 지역 내 의약품 GMP 분야 선진 국가다. 식약처 관계자는 “이번 협정이 우리나라 GMP 관리체계가 국제적으로 인정받는 계기가 되고, 아세안 국가 대상 의약품 수출 기회 확대와 아세안내 다른 국가와 상호인정협정의 발판으로 작용할 것으로 기대한다”며 “앞으로도 우리나라 제약 업체가 아세안 지역 등 해외로 진출하는데 적극 지원할 계획”이라고 전했다.
-
[기획-디지털 ID 기술] (63)아이데미아, '양방향 신뢰 표시기' 명칭의 미국 특허 등록(US 11816680)미국 바이오 테크 기업 아이데미아(Idemia)에 따르면 2023년 11월14일 '양방향 신뢰 표시기(Bi-directional trust indicator)' 명칭의 미국 특허(US 11816680)가 등록됐다.본 등록 특허(US 11816680)는 모출원 등록 특허(US 10726426)를 기초로 2020년 7월 27일 출원(US 16/939946)된 후 미국 특허청에 의해 심사를 받았다.모출원 등록 특허(US 10726426)는 2016년 9월1일 가출원(US 62/382688)된 후 2017년 9월1일 출원(US 15/694346)되어 2020년 7월28일 등록됐다.패밀리 특허로 오스트레일리아 특허(AU 2017321895), 캐나다 특허(CA 3035623)가 포기되고 유럽 특허(EP 3507733)가 취하됐다. 하지만 브라질 특허(BR 112019004175)가 심사 중이다.본 등록 특허(US 11816680)의 일 실시예에 따르면 컴퓨팅 장치 상에 디스플레이하기 위해 컴퓨팅 장치의 디스플레이 상에서 볼 수 있는 식별 렌더링을 생성한다.식별 렌더링은 권한 표시와 개인의 디지털 이미지를 포함한다. 식별 렌더링과 연관된 상호작용 효과를 트리거하는 장치가 더 포함된다.트리거링은 트리거 입력을 수신하는 장치에 응답하여 발생한다. 트리거는 컴퓨팅 장치의 모든 입력 또는 통신 센서에서 발생할 수 있다.트리거된 상호작용 효과에는 권한 표시(authority indicator) 와 신선도 표시(a freshness indicator)가 포함된다.신선도 표시기를 통해 디스플레이를 보는 개인은 디지털 이미지와 관련된 사람의 아이디를 확인할 수 있다. 검증은 상호 작용 효과의 특징과 개인의 속성 또는 권한 표시 중 적어도 하나를 기반으로 한다.
-
[기획-디지털 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
-
[기획-디지털 ID 표준] ⑬산업단체와 포럼 - 국제인터넷표준화기구(IETF)디지털 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) 등이다.국제인터넷표준화기구(Internet Engineering Task Force, IETF)는 1986년 설립됐다. 인터넷 관련 표준 개발 기구(standards development organization, SDO)다.IETF는 인터넷 사용자, 네트워크 운영자, 장비 공급업체가 자주 채택하는 자발적인 표준을 만들어 인터넷 개발 궤적을 형성하는데 도움을 주고 있다.특히 IETF가 발행한 대부분의 의견 요청(requests for comments, RFCs)은 데이터 교환(data exchanges) 및 형식(formats)을 다루고 있으며 전자 서명(electronic signatures), PKI, 신뢰 서비스 분야 구성요소로 간주되고 있다.