검색결과
-
KTC, 전기차 충전기 업계 기술 간담회 개최한국기계전기전자시험연구원(KTC)은 20일 송도센트럴파크 호텔에서 전기차 충전기 제조업체의 시험·인증 서비스 강화를 지원하기 위해 ‘전기차 충전기 업계 기술 간담회’를 개최했다고 밝혔다. 이번 간담회는 충청북도에서 주관하는 ‘시군 산업거점 고도화 패키지 지원사업’의 일환으로 전기차 충전기 제조업체 25개 사가 참석했다. 이날 KTC는 지원사업 소개를 시작으로 전기차 충전기의 ▲안전성·계량 검증·전자파·효율 관리 등 평가 분야별 인증 동향 ▲외부 전문가 초청 해외 인증 ▲급속충전기 국제표준(IEC)개정 사항 ▲재검정 등에 대해 소개했다. 또한 인증기관과 전기차 충전기 제조업체의 상생 방안에 대한 논의도 진행됐다. 이날 KTC는 전 세계 8번째 OCPP 시험기관으로 지정됨을 밝혔다. Open Charge Alliance(OCA)에서 제정 및 운영하는 전기차 충전기 운영 서버 간 개방형 통신규약인 OCPP(Open Charge Point Protocol)는 미국 및 유럽에서 표준 적용 의무가 논의되고 있어 기업의 인증 수요가 증가하고 있으나 국가당 단 한 곳의 시험기관만 지정하는 OCA의 원칙으로 인해 인증 적체 현상이 발생하고 있었다. KTC는 연내 OCPP 시험서비스를 제공할 계획이라고 밝혔다. KTC는 이외에도 전기차 충전기 분야에서 독일 티유브이 라인란드(TUV Rheinland), 미국 유엘 솔루션즈(UL Solutions)등 다수의 글로벌 인증기관의 시험소로 지정되어 있어 국내기업의 수출지원에 앞장서고 있다. 안성일 KTC 원장은 “이번 간담회를 통해 전기차 충전기 제조업체들이 국제표준 동향과 시험·인증 절차를 이해하고, 해외 시장 진출을 위한 경쟁력을 강화할 수 있을 것으로 기대된다”며 “앞으로도 전기차 충전기 산업의 발전을 위해 시험·인증 서비스 강화와 기술지원을 아끼지 않겠다”고 밝혔다.
-
TTA, ‘주소지식모델’ 표준 제정으로 주소 정보 디지털 서비스 확대한국정보통신기술협회(TTA)는 한국의 고유한 주소체계에 대한 개념과 특징을 명세하고 데이터 관점에서 일관성 있게 주소체계를 기술하기 위하여 ‘주소지식모델’ 표준 제정을 추진한다고 5일 밝혔다. 이 표준은 주소체계에 대한 의미 관계를 그래프 형태로 표현하며 기계가 읽을 수 있는 데이터 구조로 주소 체계를 재구성하는 것을 목표로 한다. 현재 한국의 주소 정보는 문자 기반으로, 각 단어의 의미와 관계를 명확하게 정의하지 못하는 한계가 있었다. 이러한 문제를 해결하기 위해 TTA는 주소정보의 산업 분야 확산을 목표로 하는 이 표준을 연내에 제정할 예정이다. 해당 표준은 도로정보, 교통시설, 기반시설 등의 공공 데이터와과 민간의 다양한 데이터가 서로 연결돼 인공지능 환경에서 데이터를 융합·분석하는 데 활용 가능해 관련 분야의 다양한 서비스 확대가 기대된다. '주소지식모델' 표준은 세 부분으로 구성된다. '제1부 주소체계'는 데이터 관점에서 주소체계를 기술하며, '제2부 주소 어휘'는 주소참조체계, 국가주소정보, 주소지능정보 등을 주소지식모델로 표현하기 위한 어휘를 명세한다. 마지막으로 '제3부 웹 URI 체계'는 주소 개체 식별을 위한 주소정보 웹 URI의 설계 원칙과 패턴을 정의한다. 이 표준은 한국의 주소체계에 일정한 규칙을 부여하고 주소지식모델로 표현할 수 있는 프레임워크를 제공한다. 이를 통해 도로명주소, 사물주소를 포함한 다양한 형태의 주소를 표현할 수 있게 되며, 주소와 관련된 다양한 데이터들을 상호 연결하고 융합하는 체계가 마련돼 지능형 주소정보 확장이 가능하다. ‘주소지식모델’ 표준은 중앙대학교, 군산대학교, 행정안전부 등 정부와 민간이 공동으로 참여하여 TTA에 제안하였다. 이 표준은 주소기반산업협회에서 진행 중인 주소기반지식그래프 연구에 적용될 예정이다. 현재 TTA 빅데이터프로젝트그룹(PG1004)에서 제정을 추진 중이며, 해당 프로젝트그룹에는 와임, 올포랜드, 제이아이엔시스템, 크라우드웍스, 한국크라우드컴퓨팅연구조합, 한국전자통신연구원, 한국지능정보사회진흥원, 한국교통연구원, 국토연구원, 행정안전부 등 22개의 산업, 학술, 연구기관이 참여하고 있다. 손승현 TTA 회장은 이 표준이 제정되면 “주소 데이터를 비롯하여 도로정보, 교통시설, 기반시설 등의 공공 데이터와과 민간의 다양한 데이터가 서로 연결되어 인공지능 환경에서 데이터를 융합·분석하는 데 활용될 수 있다”며 “이를 통해 관련 분야의 다양한 서비스를 확대할 수 있을 것”이라고 말했다.
-
‘2023 K-데이터사이언스 컨퍼런스&해커톤’ 데이터사이언스 분야 혁신의 장이 되다과학기술정보통신부가 11월 30일 서울대학교 시흥캠퍼스에서 "2023 K-데이터사이언스 컨퍼런스&해커톤"을 개최했다. 행사는 데이터사이언스 융합인재 양성을 지원하기 위한 목적으로 개최됐으며, 10개 대학원과 서울대학교 데이터사이언스대학원을 포함한 300여명의 연구자가 참여했다. 해커톤은 11월 28일부터 11월 29일까지 진행되었고, 49개 팀 중 26개 팀이 예선을 통과하여 본선에 진출했다. 참고로, 해커톤(Hackathon)은 해킹과 마라톤의 합성어로, 제한된 시간 동안 개발자, 디자이너, 기획자 등이 팀을 이루어 주제에 맞는 서비스 등을 개발하는 공모전 형식의 이벤트를 말한다. 참가자들은 '빅데이터 기반의 학령인구 예측'과 자유과제로 '데이터사이언스 기반 아이디어 제안 및 솔루션 개발' 주제로 경쟁했다. 수상팀 중 박장대소팀(고려대)은 지정과제, SSSCI팀(서울대)은 자유과제에서 우수한 프로그램을 개발하여 장관상을 수상했다. 컨퍼런스에서는 데이터사이언스대학원 교수들의 튜토리얼과 대학원생들의 연구발표회가 개최되었다. 최현준 박사과정생(서울대)은 UCB기반 밴딧 알고리즘을 활용한 다중 컨텐츠 추천 모델을 개발하여 우승했다. 또한, 데이터사이언스분야 발전토론회에서는 대학들이 참여한 데이터사이언스 융합인재 양성사업의 성과를 발표하고 협력 방안을 모색했다. 끝으로 노경원 연구개발정책실장은 데이터사이언티스트의 역할을 강조하며, 대한민국 데이터사이언스 학계의 혁신과 디지털 전환 시대의 중요성을 강조했다.
-
산업부, ‘커넥티드 모빌리티 얼라이언스’ 총회 개최로 민관 협업 이끌다산업통상자원부(장관 방문규)는 11월 30일(목) 오후 2시, 송도 컨벤시아 그랜드볼룸에서 '커넥티드 모빌리티 얼라이언스' 총회를 성공적으로 개최했다. 이번 행사에서는 자동차, 정보통신기술(ICT), 소프트웨어(SW) 등 다양한 분야의 산‧학‧연 관계자들이 참석해, 커넥티드 모빌리티 산업 생태계를 조성하기 위한 민관 합동 협업을 본격적으로 추진하기로 합의했다. 지난해 출범한 '커넥티드 모빌리티 얼라이언스'는 4개 분과, 37개 기관으로 시작하여 자동차뿐만 아니라 지상‧항공 모빌리티를 아우르는 산업으로 확장에 성공했다. 지난 1년간 얼라이언스는 전기차 충전 보안 표준화, 기업 간 상호 연계 실증, 자율주행시스템 개발 협력 등 다양한 협업과제를 논의하며 커넥티드 모빌리티 협업생태계를 조성해왔다. 참고로, 커넥티드 모빌리티(Connected Mobility)는 차량, 인프라, 네트워크 등 다양한 기술이 융합되어 협력하는 혁신적인 모빌리티 서비스를 말한다. 주로 정보통신 기술과 자동차 기술이 결합돼 구현되며, 다양한 기기가 상호 연결되어 혁신적인 서비스를 제공하고 있다. 최근 커넥티드 모빌리티는 미래 도시 교통체계의 지속 가능성을 향상시키는 해결책으로도 떠오르고 있다. 내년에는 20개 이상 기업 간 실질적인 협업사례 도출 등 가시적인 성과 창출에 주력할 예정이며, 독일 대표 클러스터 'ITS MOBILITY'와 표준화 및 공동연구 협력 양해각서(MOU)를 추진하고 독일 내 현지사무소를 통해 유럽지역 대규모 실증사업을 착수할 계획이다. 산업부는 "커넥티드 모빌리티 얼라이언스가 미래 모빌리티 산업 경쟁력을 한 단계 더 도약할 수 있는 발판이자, 산업생태계를 이끌어가는 주요 핵심 동력이 되기를 기대한다"고 강조하며, "정부는 기술개발 로드맵 수립, 데이터 표준화를 위한 빅데이터 플랫폼 구축, 사이버보안 대응체계 강화 등을 통해 적극적으로 지원하겠다"고 밝혔다.
-
국표원, ‘전기전자분야 시스템 표준화 포럼’ 개최융복합기술 상호운용성을 시스템 표준으로 해결한다. 고령자용 인공지능(AI) 전자제품, 스마트시티와 같이 제품‧서비스에 인공지능(AI), 빅데이터 등 첨단기술이 결합되는 다양한 융복합 분야에서 전체 시스템 단위에서의 표준 개발이 효과를 내고 있다. ‘시스템 표준화’는 기술 간 유기적 연동이 어려운 기존 개별 부품 위주 표준에서 벗어나 시스템 전체 또는 시스템 간 상호운용성 확보를 위해 요구되는 표준을 개발하는 접근법이다. 이렇게 개발된 시스템 표준은 차세대 직류전력망, 스마트제조, 스마트에너지 등 융복합산업 분야에 적용되고 있다. 산업통상자원부 국가기술표준원은 30일 ‘전기전자분야 시스템 표준화 포럼’을 개최하고 국내기업의 ‘고령자용 AI 스피커’, ‘저압 직류배전’ 등 분야에 대한 시스템 표준화 적용 성과를 공유했다고 밝혔다. 특히 복약시간 알람 등 고령자용 AI스피커 서비스 개발 요구사항, 가정용 저압 직류배전 아크 위험 및 안전 지침이 국제표준안(IEC)으로 제안돼 개발이 진행되고 있다. 이번 포럼에서 한국전자기술연구원은 국가표준기술력향상사업을 통해 시스템 표준 개발 접근법 활용을 위한 지침과 프로그램 개발하고, 저압직류 배전 분야에 대한 상호운용성 실증 사례를 소개했다. 또한 포럼 참석 전문가들은 토론을 통해 메타버스, 바이오 디지털제품 등 첨단 융합산업 분야로 시스템적 접근을 통한 표준 개발을 확대해 나갈 것을 제안했다. 오광해 표준정책국장은 “시스템 표준 개발 활용 사례를 확산하여 기업들이 융복합분야의 표준에 대한 접근을 쉽게 하고 우리나라의 표준화 적용 사례는 국제표준으로 제안될 수 있도록 민간 전문가들의 활동을 지원해 나가겠다”고 밝혔다.
-
[미국] 스트린트스펙트럼과 프리즘테크놀로지의 특허 무효 시 손해 배상2016년 스위스 다보스포럼에서 클라우스 슈밥이 '제4차 산업혁명'이라는 용어를 처음 사용한 이후 4년이 흘렀다. 이러한 4차 산업혁명의 시대는 초기술 융합의 시대라고 부른다.예를 들어 4차산업의 대표적인 분야인 드론의 경우에 첨단소재, 배터리, 카메라, 운영체제(OS) 등 첨단기술 집약체이다. 특히 인공지능(AI), 로봇, 자율주행 자동차, 빅데이터, 블록체인과 융·복합적으로 관련돼 있다.이와 같은 초기술 융합의 시대에서는 특허권의 확보를 통한 특허경영이 기업의 미래뿐만 아니라 국가의 미래를 결정할 수도 있다. 또한 유효한 특허권을 적절히 확보해 외부의 공격으로부터 방어하는 것 역시 더욱 더 중요해지고 있다.아래에 제시된 판례는 스프린트스펙트럼(Sprint Spectrum)과 프리즘테크놀로지(Prism Technology) 간의 특허권의 무효에 따른 영향을 보여준다.국문요약: 스프린트스펙트럼이 프리즘테크놀로지에 대한 $US 3200만불의 손해 배상 책임 판결을 받았다. 하지만 아직 집행되지 않은 상태에서, 이후에 T-모바일이 프리즘테크놀로지의 특허를 무효화시켰다.이에 따라 스프린트스펙트럼은 이전 판결에 대한 구제를 요청해 지방법원은 스프린트스펙트럼의 요청을 받아들였다. 프리즘테크놀로지는 이에 대해 항소했으며 연방순회항소법원은 지방법원의 판결이 적절했다고 판결했다. 영문요약: Effect on Damages when Patent Is Invalidated Prism Tech. v. Sprint Spectrum L.P. (F.C. 2019)Case History:•Sprint was liable for $32M damage, which was affirmed in March 2017 by FC.•Prism had another litigation with T-Mobile.•T-Mobile challenged the eligibility of the patents under S101 and won.•On June 2017, FC affirmed the invalidation of the Prism’s patent at issue. FC Decision:•FC ruled in favor of Sprint.•After the invalidation of the patent, Sprint filed a motion for Relief from Judgment based on FC’s decision on invalidation.•District court agreed and FC found no abuse of discretion.Key Point:•Sprint was able to avoid paying $32M in damages due to T-Mobile’s effort to invalidate Prism’s patent.•Sprint took as much time as possible to stick around and see how the case between Prism and T-Mobile would turn out, and that turned out beneficial to Sprint.•There was a strong federal patent policy against enforcing an unexecuted judgment of the patent liability when the patent claims underlying that judgment had been held invalid by another decision.
-
[기획-디지털 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 표준] ⑮산업단체와 포럼 - 오픈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 표준] ⑫산업단체와 포럼 - 신속 온라인 인증(Fast Identity Online, FIDO)디지털 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) 등이다.신속 온라인 인증(Fast Identity Online, FIDO)은 2013년 2월 출범한 개방형 산업협회다. 전 세계 비밀번호에 대한 과도한 의존을 줄이는 데 도움이 되는 인증 표준을 개발하고 홍보하는 것을 사명으로 삼고 있다.디지털 ID와 관련된 내용은 로밍 인증자와 다른 클라이언트/플랫폼 간 통신을 위한 어플리케이션 계층 프로토콜을 설명하는 클라이언트-인증자 프로토콜(Client to Authenticator Protocol, CTAP)이다.다양한 물리적 매체를 사용해 이 어플리케이션 프로토콜을 다양한 전송 프로토콜에 결합하고 있다. 클라이언트-인증자 프로토콜(Client to Authenticator Protocol, CTAP) 관련 목차를 살펴보면 다음과 같다.목차(table of contents)1. Introduction1.1 Relationship to Other Specifications2. Conformance3. Protocol Structure4. Protocol Overview5. Authenticator API5.1 authenticatorMakeCredential (0x01)5.2 authenticatorGetAssertion (0x02)5.3 authenticatorGetNextAssertion (0x08)5.3.1 Client Logic5.4 authenticatorGetInfo (0x04)5.5 authenticatorClientPIN (0x06)5.5.1 Client PIN Support Requirements5.5.2 Authenticator Configuration Operations Upon Power Up5.5.3 Getting Retries from Authenticator5.5.4 Getting sharedSecret from Authenticator5.5.5 Setting a New PIN5.5.6 Changing existing PIN5.5.7 Getting pinToken from the Authenticator5.5.8 Using pinToken5.5.8.1 Using pinToken in authenticatorMakeCredential5.5.8.2 Using pinToken in authenticatorGetAssertion5.5.8.3 Without pinToken in authenticatorGetAssertion5.6 authenticatorReset (0x07)6. Message Encoding6.1 Commands6.2 Responses6.3 Status codes7. Interoperating with CTAP1/U2F authenticators7.1 Framing of U2F commands7.1.1 U2F Request Message Framing ### (#u2f-request-message-framing)7.1.2 U2F Response Message Framing ### (#u2f-response-message-framing)7.2 Using the CTAP2 authenticatorMakeCredential Command with CTAP1/U2F authenticators7.3 Using the CTAP2 authenticatorGetAssertion Command with CTAP1/U2F authenticators8. Transport-specific Bindings8.1 USB Human Interface Device (USB HID)8.1.1 Design rationale8.1.2 Protocol structure and data framing8.1.3 Concurrency and channels8.1.4 Message and packet structure8.1.5 Arbitration8.1.5.1 Transaction atomicity, idle and busy states.8.1.5.2 Transaction timeout8.1.5.3 Transaction abort and re-synchronization8.1.5.4 Packet sequencing8.1.6 Channel locking8.1.7 Protocol version and compatibility8.1.8 HID device implementation8.1.8.1 Interface and endpoint descriptors8.1.8.2 HID report descriptor and device discovery8.1.9 CTAPHID commands8.1.9.1 Mandatory commands8.1.9.1.1 CTAPHID_MSG (0x03)8.1.9.1.2 CTAPHID_CBOR (0x10)8.1.9.1.3 CTAPHID_INIT (0x06)8.1.9.1.4 CTAPHID_PING (0x01)8.1.9.1.5 CTAPHID_CANCEL (0x11)8.1.9.1.6 CTAPHID_ERROR (0x3F)8.1.9.1.7 CTAPHID_KEEPALIVE (0x3B)8.1.9.2 Optional commands8.1.9.2.1 CTAPHID_WINK (0x08)8.1.9.2.2 CTAPHID_LOCK (0x04)8.1.9.3 Vendor specific commands8.2 ISO7816, ISO14443 and Near Field Communication (NFC)8.2.1 Conformance8.2.2 Protocol8.2.3 Applet selection8.2.4 Framing8.2.4.1 Commands8.2.4.2 Response8.2.5 Fragmentation8.2.6 Commands8.2.6.1 NFCCTAP_MSG (0x10)8.2.6.2 NFCCTAP_GETRESPONSE (0x11)8.3 Bluetooth Smart / Bluetooth Low Energy Technology8.3.1 Conformance8.3.2 Pairing8.3.3 Link Security8.3.4 Framing8.3.4.1 Request from Client to Authenticator8.3.4.2 Response from Authenticator to Client8.3.4.3 Command, Status, and Error constants8.3.5 GATT Service Description8.3.5.1 FIDO Service8.3.5.2 Device Information Service8.3.5.3 Generic Access Profile Service8.3.6 Protocol Overview8.3.7 Authenticator Advertising Format8.3.8 Requests8.3.9 Responses8.3.10 Framing fragmentation8.3.11 Notifications8.3.12 Implementation Considerations8.3.12.1 Bluetooth pairing: Client considerations8.3.12.2 Bluetooth pairing: Authenticator considerations8.3.13 Handling command completion8.3.14 Data throughput8.3.15 Advertising8.3.16 Authenticator Address Type9. Defined Extensions9.1 HMAC Secret Extension (hmac-secret)10. IANA Considerations10.1 WebAuthn Extension Identifier Registrations11S ecurity ConsiderationsIndexTerms defined by this specificationTerms defined by referenceReferencesNormative ReferencesInformative ReferencesIDL Index
-
국정원, 경력직 재난·안전 정책 및 산업재해·안전 전문가 채용, 중앙대 ICT융합안전 전공자 모집 안내국가정보원(이하 국정원)은 2023년 9월26일(화)~10월17일(화)까지 2023년도 재난·안전 정책 및 산업재해·안전 관련 경력직 전문가를 채용하고 있다.최근 안타깝게 발생한 청주시 오송 지하차도 참사뿐 아니라 용산 이태원 참사 등 국가 차원의 재난 대응에 실패한 사례가 속출하고 있어 국정원이 처음으로 재난 및 안전 전문가 채용에 돌입했다.우리나라 뿐 아니라 전 세계에서 전례가 없는 기상이변으로 재난 규모가 확대되고 재난의 양태가 다양화되고 있다. 따라서 국가 차원의 재난 대응 실패가 국정수행 실패에 따른 비난 및 국가위기 상황이 직면할 수 있다고 판단하고 있기 때문이다.국정원이 경력직 재난 전문가를 채용하는 분야 및 자격, 유의 사항을 살펴보면 아래와 같다.1. 선발분야 및 지원자격·유의사항■ 특정직 6급 ○ 재난·안전 정책 - 학사 이상 학위(전공 무관) 소지자로 - 재난 대응·예방·정책 분야 실무 경력 6년 이상인 자(석사 학위 소지자는 경력 4년 이상, 박사학위 소지자는 1년 이상) ※. 우대사항은 국가정보원 채용공고 확인필요 ○ 건축구조 기술 - 건축학·건축공학·토목공학 관련 전공 학사 이상 학위 소지자로 - 건축 설계 또는 감리 분야 실무 경력 6년 이상인 자(석사 학위 소지자는 경력 4년 이상, 박사 학위 소지자는 경력 무관) ※. 우대사항은 국가정보원 채용공고 확인필요■ 특정직 7급 ○ 산업재해·안전 - 건축학·안전관리 관련 전공 학사 이상 학위 소지자로 - 산업안전 관련 유관기관에서 산업재해·안전 분야 실무 경력 3년 이상인 자(석사 학위 소지자는 경력 1년 이상, 박사 학위 소지자는 경력 무관) ※. 우대사항은 국가정보원 채용공고 확인필요■ 지원자격 및 유의사항 ※. 국가정보원 채용공고 확인필요2. 전형일정■ 원서접수 : 2023.9.26(화) 16:00 ~ 10.17(화) 16:00■ 서류심사 : 10월 중 합격자 발표■ 면접 : 서류심사 통과자에 한하여 11월 중 실시■ 신체검사 : 면접 합격자에 한하여 11월~12월중 실시■ 임용 : 합격자 대상 추후 통지 ※. 자세한 내용은 국정원 채용사이트 참고기후위기로 인해 기상기후재난 발생 양태가 복잡·다양해 지고 있으며 예측 불가능한 각종 재난 상황이 빈발함에 따라 예방과 대응을 위한 선제적 활동의 중요성이 증대되고 있다.재난 전문가 채용에 앞서 재난・재해의 예측과 대비, 감지 및 전파, 사고 수습 및 복구에 있어 기존 재난안전 기술에 4차 산업혁명 기반의 ICT를 결합해 대응할 필요성도 증가하고 있다.따라서 중앙대 ICT융합안전 전공 정상 교수는 ICT와 안전을 융합해 재난 현장에 적용할 수 있는 전문인력의 필요성을 느껴 학과를 신설해 전문가 육성에 매진하고 있다.서울시와 국민안전교육 진흥 기본법 제20조에 따른 협력의 일환으로 2020년 2학기부터 ICT융합안전전공 신입생을 선발해 결실을 맺고 있다.ICT융합안전은 4학기 동안 4차 산업혁명 시대를 맞아 ICT 안전 솔루션과 인프라를 능숙하게 활용할 수 있는 ICT융합 안전 전문인력을 양성하게 된다.현대사회에 다양하고 복잡한 양태를 띄고 있는 재난에 대비하기 위해 ICT융합안전 전문인력의 양성이 중요하다. 중앙대학교 일반대학원 의회학과 ICT융합안전 전공은 2024년도 전반기 일반대학원 일발전형 모집요강에 따라 2023 ICT융합 안전·안전교육 석박사 전문인력 선발에 들어갔다.선발 인원은 의회학과 ICT융합안전 전공 석·박사과정 20명으로 ICT융합 안전에 관심이 있는 분이나 재난 빅데이터, 메타버스, 디지털, 트윈 플랫 폼 연구에 관심 있는 사람이라면 지원 가능하다.또한 전공에 상관없이 학부 졸업예정자나 재난 안전 안전분야 재직자, 다양한 안전분야에 관심이 있거나 향후 안전분야 진출을 희망하는 사람도 지원 가능하다.□ 모집 인원 및 지원 분야○ 모집 인원 : 석·박사과정 20명○ 지원 분야 : 중앙대 일반대학원 의회학과 ICT융합안전 전공○ 대상 : 제한 없음○ 수업 연한 : 4학기○ 학사 운영 : 야간 및 토요일□ 전형 일정○ 원서접수- 2023.10.19(목) ~ 11.13(월) 23:59○ 서류제출- 2023.11.14(화) 17:00까지○ 면접전형- 2023.12.9(토)○ 합격자발표- 2023.12.22(금) 예정○ 등록금 납부- 2024.1. 예정