검색결과
-
TTA아카데미, 국립안동대학교와 SW 전문인력 양성 위해 협력 강화TTA아카데미는 2023년 11월 21일, 국립안동대학교 SW융합교육원과 함께 SW(소프트웨어) 산업의 발전과 전문인력 양성을 목표로 업무협약(MOU)을 체결하였다. 이 협력을 통해 양 기관은 SW 역량 강화 및 교육, 연구, 컨설팅 분야에서 협력하여 국내 및 국제적인 SW 분야에서의 경쟁력 향상을 약속하였다. 이번 MOU 체결을 통하여 지역 SW산업의 역량 향상과 창의적이고 전문적인 인력을 양성하는 데 기여할 것으로 보인다. 참고로, TTA아카데미는 ICT 표준, SW테스트, 보안 등 SW 품질 역량 강화를 위한 전문 교육을 제공하고 있으며, 특히 SW 품질 확보를 위한 인재 배출을 목적으로 국가공인 SW테스트전문가(CSTS*) 자격시험을 운영하고 있다. * CSTS : Certified Software Test Specialist 최근 글로컬대학에 선정된 국립안동대학교 SW융합교육원에서는 SW전문가 양성을 목적으로 국가공인 SW테스트 전문가(CSTS) 양성교육을 TTA아카데미와 협력하여 운영하는 등 다양한 프로그램으로 학생들의 IT기술 함양과 기술 습득을 지원하고 있다. 그뿐만 아니라 교육 및 연구를 통해 SW 분야에서 우수 인재 양성을 위한 노력을 기울이고 있으며, 이를 통해 SW산업의 역량 강화와 지속적인 성장을 지원하고 있다. 양 기관은 협약을 통해 ▲SW 산업 발전을 위한 우수한 SW 인재 양성 ▲SW 품질 전문 인력 양성을 위한 교육 기회 공동 제공 ▲SW 테스트 및 시험인증 분야에서 연구 및 컨설팅 활동 공동 추진 등을 협력하기로 하였다.
-
[미국] 특허법 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.
-
[미국] 스트린트스펙트럼과 프리즘테크놀로지의 특허 무효 시 손해 배상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.
-
[미국] 특허법, 명세서의 내용으로부터 청구범위의 내용 제한시 “a clear and unmistakable disclaimer” 원칙 준수미국 특허법에 따르면 명세서의 내용으로부터 청구범위의 내용을 제한할 경우에 “a clear and unmistakable disclaimer” 원칙을 준수해야 한다.특허권의 권리는 발명을 서술한 명세서에 작성된 청구항을 통해 확보할 수 있다. 이에 따라 서술된 청구항의 해석에 따라 권리범위가 적용될 수 있는 범위가 달라질수 있으므로 이에 대한 이해는 매우 중요하다. 예를 들면 특허 명세서에 개시된 발명의 서면 설명에 비춰 특허의 청구를 해석해야 하는지 여부 또는 미국 항소 법원이 우선 청구조건의 일반적인 의미를 결정해야 하는지 여부도 중요한 하나의 요소가 될 수 있다.이에 대한 실례로서 컨티넨털서킷(Continental Circuits)과 인텔(Intel)간의 소송을 소개한다. 이 판례에서는 특허권자가 주장 범위를 명확하고 명백하게 반박하지 않았다.그 과정이 청구된 발명의 필수 부분이라는 것을 명확하게 하지 않은 경우, 제품 청구를 제한적으로 해석하는 것은 부적절하다는 점을 보여준다.국문요약: 본 판례는 청구항에 언급된 “surface”, “removal”, “etching”, “dielectric material’의 용어가 명세서에 언급된 “repeated desmear process”용어에 의해 한정되는지 여부에 관한 것이다.연방 순회 항소 법원에서는 비록 명세서에 “repeated desmear process”용어가 사용됐지만 청구항에서는 이에 대한 용어가 직접 사용되지 않고 있다는 점을 언급하면서 지방법원의 잘못을 지적했다.또한 명세서의 내용으로부터 청구범위의 내용을 제한할 때에는 반드시 “a clear and unmistakable disclaimer” 원칙을 준수해야 한다는 점을 언급했다.영문요약: Incorporating Limitation from Specification(Issue of Claim Construction)Continental Circuits v. Intel (F.C. 2019)History: •Continental asserted four patents directed to a “multilayer electrical device … having a tooth structure” against Intel.•Claims included the limitations regarding “surface,” “removal,” “etching,” and “dielectric material.”•Issue: whether the claim construction of these terms should be limited to a repeated desmear process.District Court:•Interpreted the limitations to require repeated process.•Determined that the Continental characterized “The present invention” as using a repeated desmear process.•Specification also seems to distinguish the invention from the single desmear process in the prior art.Federal Circuit:•Held that district court erred in costruing the terms to require that the dielectric material be “produced by a repeated desmear process.”•The plain claim language does not include this repeated process and the specification does not unmistakably limit the claims to require this process.•Although the claims do not stand alone and must be read in view of the specification, FC held that none of the asserted claims actually recite a “repeated desmear process.”•Specification may include an intentional disclaimer, or disavowal, of claim scope, but it is not the case here.•FC acknowledged difficulty in determining between whether to construe the claims in light of the specification or improperly importing a limitation from the specification into the claims.•Must follow “a clear and unmistakable disclaimer” standard when importing limitations from specification to the claims.
-
[특집-기술위원회] TC 132 - 합금철(Ferroalloys)스위스 제네바에 본부를 두고 있는 국제표준화기구(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 등도 포함된다.ISO/TC 132 합금철(Ferroalloys)과 관련된 기술위원회는 TC 130, TC 131과 마찬가지로 1969년 결성됐다. 사무국은 중국 국가표준화관리위원회(国家标准化管理委员会, Standardization Administration of China, SAC)에서 맡고 있다.위원회는 롱 쓰우(Ms Rong ZHU)가 책임지고 있다. 현재 의장은 춴성 루(Mr Chunsheng LU)로 임기는 2027년까지다.ISO 기술 프로그램 관리자는 스테판 소바쥬(M Stéphane Sauvage), ISO 편집 관리자는 앤 기앳(Ms Anne Guiet) 등으로 조사됐다.범위는 철과 강철 제조에 사용되는 합금철 및 기타 합금 첨가제, 합금철 원료에 사용되는 망간 광석 및 크롬 광석 분야의 표준화다. 단, ISO/TC 155에 따른 페로니켈 표준화는 제외한다.현재 ISO/TC 132 사무국의 직접적인 책임 하에 발행된 표준은 69개며 ISO/TC 132 사무국의 직접적인 책임 하에 개발 중인 표준은 2개다. 참여하고 있는 회원은 7개국, 참관 회원은 26개국이다.□ ISO/TC 132 사무국 분과위원회(Subcommittee)의 책임 하에 발행된 표준 15개 목록▷ISO 310:1992 Manganese ores and concentrates — Determination of hygroscopic moisture content in analytical samples — Gravimetric methodISO 312:1986 Manganese ores — Determination of active oxygen content, expressed as manganese dioxide — Titrimetric method▷ISO 315:1984 Manganese ores and concentrates — Determination of nickel content — Dimethylglyoxime spectrometric method and flame atomic absorption spectrometric method▷ISO 317:1984 Manganese ores and concentrates — Determination of arsenic content — Spectrometric method▷ISO 320:1981 Manganese ores — Determination of sulphur content — Barium sulphate gravimetric methods and sulphur dioxide titrimetric method after combustion▷ISO 548:1981 Manganese ores — Determination of barium oxide content — Barium sulphate gravimetric method▷ISO 549:1981 Manganese ores — Determination of combined water content — Gravimetric method▷ISO 619:1981 Manganese ores — Determination of chromium content — Diphenylcarbazide photometric method and silver persulphate titrimetric method▷ISO 3713:1987 Ferroalloys — Sampling and preparation of samples — General rules▷ISO 4139:1979 Ferrosilicon — Determination of aluminium content — Flame atomic absorption spectrometric method▷ISO 4140:1979 Ferrochromium and ferrosilicochromium — Determination of chromium content — Potentiometric method▷ISO 4158:1978 Ferrosilicon, ferrosilicomanganese and ferrosilicochromium — Determination of silicon content — Gravimetric method▷ISO 4159:1978 Ferromanganese and ferrosilicomanganese — Determination of manganese content — Potentiometric method▷ISO 4293:1982 Manganese ores and concentrates — Determination of phosphorus content — Extraction-molybdovanadate photometric method▷ISO 4295:1988 Manganese ores and concentrates — Determination of aluminium content — Photometric and gravimetric methods □ ISO/TC 132 사무국 분과위원회(Subcommittee)의 책임 하에 개발 중인 표준 목록▷ISO/WD 6331 Chromium ores and concentrates — Determination of chromium content — Titrimetric method▷ISO/WD 7692 Ferrotitanium — Determination of titanium content — Titrimetric method□ ISO/TC 132 사무국의 작업그룹(Working Group, WG) 현황▷ISO/TC 132/WG 3 Chromium ores and concentrates - Determination of chromium content - Titrimetric method Working group▷ISO/TC 132/WG 4 Ferrotitanium— Determination of titanium content— Titrimetric method Working group
-
[기획-디지털 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
-
국표원, ‘제53회 계량측정의 날’ 기념식 개최산업통상자원부 국가기술표준원은 31일 ‘제53회 계량측정의 날’ 기념식을 개최하고 계량측정분야 국가경쟁력 강화에 기여한 유공자·단체를 대상으로 총 57점의 포상을 수여했다고 밝혔다. 포상은 산업훈장 1점(동탑), 대통령 표창 3점, 국무총리 표창 4점, 장관 표창 17점, 공모전 상장 32점 등이다. ‘계량측정의 날’은 세종대왕이 계량 체계를 확립한 1446년 10월 26일을 기념하고 공정한 상거래 질서확립을 위한 계량측정의 중요성을 알리기 위해 1970년부터 시작해 올해로 53번째를 맞이했다. 계량측정은 우리 일상 생활과 가장 가까이에 있으며 첨단산업의 글로벌 초격차 선도에 근간이 되는 핵심기술이다. 계량측정산업의 지속적인 기술개발과 신뢰성 제고를 통해 산업경제의 발전이 기대된다. 이날 기념식에서 ㈜한국정밀기기센터 김명희 연구소장은 50년간 계량측정분야 교육계 및 첨단산업분야 국가교정기관에 종사하면서 기술인력 양성 및 산업발전에 기여한 공로를 인정받아 동탑산업훈장을 수상했다. 더불어 ㈜나노하이테크와 서진인스텍㈜이 유공단체에게 주어지는 대통령 표창과 국무총리 표창을 각각 수여받는 등 총 25점의 정부포상이 수여됐다. 또한 바른단위 사용을 장려하기 위한 어린이 포스터, 유튜브쇼츠, 서포터즈 활동 및 계량측정의 중요성 우수사례 입상자 32점에 대한 시상도 진행됐다. 진종욱 국표원장은 축사를 통해 계량측정산업 발전에 기여해 온 계량측정업계의 노고와 초등학생, 대학생, 일반인 등 공모전 수상자의 많은 관심에 감사를 표했다. 이어 “계량측정은 전통시장의 저울에서부터 주유소, 전기차 충전기에 이르기까지 우리 일상 생활과 가장 가까이에 있으며 첨단산업의 글로벌 초격차 선도에 근간이 되는 핵심기술이므로, 계량측정산업의 지속적인 기술개발과 신뢰성 제고를 통해 국민 행복과 산업경제의 발전에 기여할 수 있도록 모두가 함께 노력하자”고 전했다.
-
[기획-디지털 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