KR20230153412A - 신원 전달 시스템 - Google Patents

신원 전달 시스템 Download PDF

Info

Publication number
KR20230153412A
KR20230153412A KR1020237032717A KR20237032717A KR20230153412A KR 20230153412 A KR20230153412 A KR 20230153412A KR 1020237032717 A KR1020237032717 A KR 1020237032717A KR 20237032717 A KR20237032717 A KR 20237032717A KR 20230153412 A KR20230153412 A KR 20230153412A
Authority
KR
South Korea
Prior art keywords
identity
customer
information
assertion
service provider
Prior art date
Application number
KR1020237032717A
Other languages
English (en)
Inventor
슐로미트 아즈가드-트로머
매튜 디. 그린
에란 트로머
Original Assignee
시랜스 코포레이션
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 시랜스 코포레이션 filed Critical 시랜스 코포레이션
Publication of KR20230153412A publication Critical patent/KR20230153412A/ko

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/401—Transaction verification
    • G06Q20/4014—Identity check for transactions
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/02—Payment architectures, schemes or protocols involving a neutral party, e.g. certification authority, notary or trusted third party [TTP]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/04—Payment circuits
    • G06Q20/045—Payment circuits using payment protocols involving tickets
    • G06Q20/0457—Payment circuits using payment protocols involving tickets the tickets being sent electronically
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/04—Payment circuits
    • G06Q20/06—Private payment circuits, e.g. involving electronic currency used among participants of a common payment scheme
    • G06Q20/065—Private payment circuits, e.g. involving electronic currency used among participants of a common payment scheme using e-cash
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/36—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes
    • G06Q20/367—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes involving electronic purses or money safes
    • G06Q20/3674—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes involving electronic purses or money safes involving authentication
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3821—Electronic credentials
    • G06Q20/38215—Use of certificates or encrypted proofs of transaction rights
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3825—Use of electronic signatures
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/383—Anonymous user system
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/401—Transaction verification
    • G06Q20/4016—Transaction verification involving fraud or risk level assessment in transaction processing
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3218—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using proof of knowledge, e.g. Fiat-Shamir, GQ, Schnorr, ornon-interactive zero-knowledge proofs
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q2220/00—Business processing using cryptography

Landscapes

  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • Strategic Management (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Finance (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

서비스 제공자에게 신원 어설션을 발행함으로써 금융 서비스 제공자에 대한 고객의 신원 검증을 용이하게 하도록 구성된 시스템이 제공된다. 이 시스템은 고객 정보를 저장하고 고객의 신원을 검증하며, 서비스 제공자로부터의 요청에 기초하여 정보 중 적어도 일부를 어설팅하는 신원 어설션을 생성하도록 구성된 신원 제공자 ― 어설션은 암호화된 부분을 포함함 ―; 및 고객과 연관되고 서비스 제공자에게 어설션을 제공하는 것을 용이하게 하기 위해 서비스 제공자 및 신원 제공자와 통신하도록 구성된 고객 신원 관리자를 포함한다. 이 시스템은 고객 기록의 어느 정보가 서비스 제공자에게 어설션으로 그리고 어떤 형태로든 제공될 것인지를 선택적으로 결정하기 위해 고객 기록과 정책을 추론하도록 구성된 신원 요약 엔진을 더 포함한다.

Description

신원 전달 시스템
현재 개시된 주제는 디지털 자산 시스템에 관한 것으로, 구체적으로 그러한 시스템을 사용하는 고객의 식별에 관한 것이다.
고객 알기 제도(Know Your Customer, KYC) 규정 준수는 암호화폐 거래소와 같은 가상 자산 서비스 제공자(Virtual Asset Service Provider, VASP), 금융 기관, 분산형 금융 애플리케이션, 및 디지털 통화 및 자산 분야의 기타 서비스 제공자("제공자들")에게 주요 기술적 과제를 제기한다. 많은 규제 체제에서, 각 서비스 제공자는 금융 거래를 수행하는 모든 고객의 신원(identity)을 검증해야 한다. 이러한 신원은 각각 특정 검증 절차를 갖는 다양한 형태의 데이터를 포함할 수 있다. 예를 들어, 미국의 KYC 규정에 따르면 VASP가 고객 이름과 주소 정보를 얻어서 개인의 신원 문서와 사진을 검증하는 것이 필요하다. 소득, 순자산, 또는 자금 출처 등 다양한 추가 정보가 획득되어 검증될 수 있다. 규정에 따르면 또한 제공자가 이러한 신원을 평판 점수 및 잠재적인 사기 활동 기록과 같은 고객에 대해 나중에 문제가 생길 수 있는 추가 정보와 연관시킬 필요가 있다. 더욱이 규정과 비즈니스 요구에 따라 제공자가 고객에 대한 정보를 규제 기관 및 기타 제공자와 교환해야 할 수도 있다.
기존의 기술적 접근방식은 이러한 규정 준수를 어렵게 만든다. 첫째, 현 제도에서, 각 개별 제공자는 KYC 문서를 검증하기 위해 디지털 및 인적 인프라를 생성해야 하며, 그 후 로컬 데이터 증권 표준에 따라 결과로 생성된 민감한 데이터를 안전하게 기록하고 저장해야 한다. 이러한 프로세스를 "사내" 관리해야 하는 필요성은 제공자에게 비용을 부과하고, 신규 고객 확보 프로세스에 오버헤드와 지연을 추가한다. 둘째, 식별 문서를 검증하기 위해 여러 제공자에 의해 사용되는 표준이 다를 수 있으며, 이로 인해 신원 정보 품질이 일관되지 않을 수 있다. 셋째, 여러 제공자가 단일 고객과 상호 작용하는 경우, 제공자는 해당 고객의 활동에 대한 정보를 다른 제공자와 교환하기 위해 고객을 고유하게 식별해야 할 수 있으며, 이는 제공자가 고객 신원을 기록하기 위해 상이한 표준을 각각 사용할 때 수행하기 어렵다(예를 들어, 고객 계정을 이름으로 매칭시키면 신원이 잘못되거나 신원 도용이 발생할 수 있음). 마지막으로, 규정을 준수하려면, 제공자가 개별 고객에 대한 대량의 민감한 정보를 저장하고, 및/또는 민감한 기밀 고객 정보를 다른 제공자와 공유해야 할 수 있다. 고객에 대해 각 제공자가 대량의 민감한 신원 정보를 저장해야 하는 필요성으로 인해, 고객은 데이터 유출 위험으로 인해 피해를 입을 위험이 있으며, 제공자는 민사 및 형사 책임의 위험에 노출된다.
일부 측면에 따르면, 중개자 없이 고객, 비즈니스, 법 집행 기관, 규제 기관, 가상 자산 서비스 제공자, 금융 기관 및 기타 기관 사이에 금융, 법률 및/또는 비즈니스 정보의 전자 전송을 용이하게 하는 전자 금융 플랫폼이 제공된다. 이러한 정보에는 특히 거래, 신원 검증 및 기타 보고서가 포함될 수 있다. 신원 검증 요구사항 및 상태를 포함하는 정보는 완전히 암호화된 방식으로 네트워크 내에서 안전하게 공유될 수 있다. 또한, 플랫폼은 정보가 볼 권한이 있는 당사자에게만 표시되도록 보장할 수 있다.
일부 측면에 따르면, 하나 이상의 신원 제공자가 고객 신원 정보를 수신, 검증 및 기록하는 것을 용이하게 하고, 서비스 제공자가 민감한 고객 정보를 저장하기 위한 필요를 최소화하는 방식으로 이러한 정보의 일부를 서비스 제공자와 공유하도록 구성된 시스템이 제공된다. 또한, 신원 정보 및/또는 가명 중 특정 부분을 선택된 제공자에게 배포하는 것에 대한 고객 인증 및 제어를 용이하게 하는 시스템이 제공된다. 이 시스템은 또한 예를 들어 서비스 제공자가 신원 제공자와 직접 통신하지 않고도 서비스 제공자가 그 진위를 검증할 수 있도록 하는 방식으로 신원 제공자로부터 이러한 정보를 배포할 수 있도록 추가로 구성될 수 있다. 이는 고객에게 암호화된 신원 인증서 및/또는 신원 어설션을 제공함으로써 활성화될 수 있다. (본 개시 및 첨부된 청구범위에서, 용어 "인증서" 및 "어설션" 및 연관된 용어는 문맥상 달리 명확히 하지 않는 한 상호교환적으로 사용될 것이다.)
이 시스템은 서비스 제공자에 의해, 필요한 신원 정보에 대한 요구사항을 정의하고, 신원 제공자가 이러한 요구사항을 충족하며, 신원 제공자에 의해 특정 고객 정보의 보유를 요청하도록 추가로 구성될 수 있다. 또한, 이를 통해 서비스 제공자가 고객 식별자를 비교하고 특정 고객에 대한 정보를 신원 제공자 및 기타 서비스 제공자와 공유하여 이러한 정보가 고객의 신원과 결합되도록 할 수 있다.
일부 예에 따르면, 시스템은 고객의 신원에 관한 정보가 중앙집중형 신원 제공자에 저장되는 중앙집중형 구성에서 작동하도록 구성될 수 있다. 서비스 제공자는 고객 신원에 대한 어설션을 획득하고 고객 행동에 대한 업데이트된 정보를 전송하기 위해 안전하고 인증된 네트워크 통신 채널을 사용하여 중앙집중형 신원 제공자와 직접 상호작용한다.
일부 예에 따르면, 이 시스템은 고객의 신원에 관한 정보가 암호로 인증된 형태로 고객에게 제공되는 분산형 구성에서 작동하도록 구성될 수 있으며, 서비스 제공자는 고객으로부터 이러한 정보의 서브셋을 수신한다. 서비스 제공자로부터의 업데이트는 신원 제공자에서 고객(다른 서비스 제공자에게 배포됨) 및/또는 블록체인과 같은 합의 네트워크 원장을 포함한 다양한 위치에 저장될 수 있다.
일부 예에 따르면, 이 시스템은 중앙집중형 구성과 분산형 구성 각각의 특징의 조합에 따라 작동하도록 구성될 수 있다.
현재 개시된 주제의 일부 측면에 따르면, 서비스 제공자에게 신원 어설션을 발행함으로써 금융 서비스 제공자에 대한 고객의 신원 검증을 용이하게 하도록 구성된 시스템이 제공되며, 이 시스템은,
고객 정보를 저장하고 고객의 신원을 검증하며, 서비스 제공자로부터의 요청에 기초하여 정보 중 적어도 일부를 어설팅하는 신원 어설션을 생성하도록 구성된 신원 제공자 ― 어설션은 암호화된 부분을 포함함 ―; 및
고객과 연관되고 서비스 제공자 및 신원 제공자와 통신하여 서비스 제공자에 대한 어설션 제공을 용이하게 하기 위해 서비스 제공자 및 신원 제공자와 통신하도록 구성된 고객 신원 관리자
를 포함하며,
이 시스템은 고객 기록의 어느 정보가 서비스 제공자에게 어설션으로 그리고 어떤 형태로든 제공될 것인지를 선택적으로 결정되기 위해 고객 기록 및 정책에 대해 추론하도록 구성된 신원 요약 엔진을 더 포함한다.
이 시스템은 다음 실시예 중 하나 이상에 따라 제공될 수 있다(문맥상 달리 명확하지 않는 한, 각 실시예의 예는 비제한적이다. 즉, 이들의 모든 조합은 본 개시의 일부를 구성한다).
실시예 1: 신원 요약 엔진은 서비스 제공자로부터의 신원 요청에 대한 공통 포맷과 서비스 제공자에게 발행된 어설션에 대한 공통 포맷을 정의하는 요청 언어를 정의할 수 있다.
실시예 2: 신원 요약 엔진은 고객 기록으로부터의 정보 중 적어도 일부가 일반화된 형태로 어설션에 포함되는 것으로 결정하도록 구성될 수 있다. 일부 비제한적인 예에 따르면, 본 실시예는 위의 실시예 1을 더 포함한다.
실시예 3: 신원 요약 엔진은 고객 기록으로부터의 정보 중 적어도 일부가 고객 기록으로부터의 다른 정보와 결합된 형태로 어설션에 포함되는 것으로 결정하도록 구성될 수 있다. 일부 비제한적인 예에 따르면, 본 실시예는 위의 실시예 중 어느 하나를 추가로 포함한다.
실시예 4: 신원 요약 엔진은 서비스 제공자의 신원에 기초하여, 고객 기록으로부터의 정보 중 적어도 일부가 보류되는 것으로 결정하도록 구성될 수 있다. 일부 비제한적인 예에 따르면, 본 실시예는 위의 실시예 중 어느 하나를 추가로 포함한다.
실시예 5: 신원 요약 엔진은 신원 제공자에 의해 구현될 수 있다. 일부 비제한적인 예에 따르면, 본 실시예는 위의 실시예 중 어느 하나를 추가로 포함한다.
실시예 6: 신원 제공자는 서비스 제공자에게 직접 어설션을 발행하도록 구성될 수 있다.
실시예 6의 비제한적인 예에 따르면, 고객 신원 관리자는 신원 어설션을 제공하기 위해 서비스 제공자로부터 요청을 수신하고, 적절한 신원 어설션이 획득될 수 있는 하나 이상의 신원 제공자를 식별하는 정보를 서비스 제공자에게 제공하도록 구성될 수 있다. 하나 이상의 신원 제공자를 식별하는 정보는 하나 이상의 신원 제공자를 식별하는 영지식 증명(zero-knowledge proof)을 포함할 수 있다.
일부 비제한적인 예에 따르면, 실시예 6은 위의 실시예 중 어느 하나를 추가로 포함한다.
실시예 7: 고객 신원 관리자는 신원 제공자에 의해 발행된 어설션을 서비스 제공자에게 제공하도록 구성될 수 있다.
실시예 7의 비제한적인 예에 따르면, 고객 신원 관리자는 고객이 이용할 수 있는 추가 정보를 서비스 제공자에게 제공하도록 추가로 구성될 수 있다. 고객 신원 관리자는 영지식 증명을 사용하여 요약된 추가 정보를 제공하도록 구성될 수 있다.
일부 비제한적인 예에 따르면, 실시예 7은 위의 실시예 중 어느 하나를 추가로 포함한다.
실시예 8: 신원 요약 엔진은 고객 신원 관리자에 의해 구현될 수 있다. 일부 비제한적인 예에 따르면, 실시예 8은 위의 실시예 중 어느 하나를 추가로 포함한다.
실시예 9: 시스템은 복수의 협력 신원 제공자를 포함할 수 있으며, 복수의 협력 신원 제공자는 각각 서비스 제공자에 의해 요구되는 정보의 적어도 일부에 대한 컴포넌트 어설션(assertion)을 발행함으로써, 컴포넌트 어설션의 집계된 어설션의 제공을 용이하게 한다.
실시예 9의 비제한적인 예에 따르면, 컴포넌트 어설션 중 적어도 일부는 컴포넌트 어설션 중 다른 일부에서 어설팅되지 않은 정보의 어설션을 포함할 수 있다.
실시예 9의 비제한적인 예에 따르면, 컴포넌트 어설션 중 적어도 일부는 컴포넌트 어설션 중 다른 일부에서 어설팅된 정보의 어설션을 포함한다.
일부 비제한적인 예에 따르면, 실시예 9는 위의 실시예 중 어느 하나를 추가로 포함한다.
실시예 10: 신원 제공자는 사용자에 대한 서비스 제공자로부터의 정보를 수신하고, 이를 고려하여 어설션을 업데이트하도록 구성될 수 있다.
실시예 10의 비제한적인 예에 따르면, 업데이트하는 것은 어설션의 정보 중 적어도 일부를 철회하는 것을 포함할 수 있다.
실시예 10의 비제한적인 예에 따르면, 신원 제공자는 업데이트된 어설션이 이용 가능하다는 메시지를 서비스 제공자에게 게시하도록 구성된다.
일부 비제한적인 예에 따르면, 실시예 10은 위의 실시예 중 어느 하나를 추가로 포함한다.
실시예 11: 어설션은 서비스 제공자가 고객에 대한 정보를 외부 시스템으로 보고하는 것을 용이하게 하도록 구성된 보고 정보를 포함할 수 있다.
실시예 11의 비제한적인 예에 따르면, 보고 정보는 하나 이상의 인증 토큰 및/또는 정보를 보고하기 위한 하나 이상의 위치를 식별하는 정보를 포함할 수 있다.
일부 비제한적인 예에 따르면, 실시예 11은 위의 실시예 중 어느 하나를 추가로 포함한다.
실시예 12: 어설션은 만료 날짜를 포함할 수 있다. 일부 비제한적인 예에 따르면, 실시예 12는 위의 실시예 중 어느 하나를 추가로 포함한다.
실시예 13: 고객 정보는 비(non) 신원 데이터를 포함한다. 일부 비제한적인 예에 따르면, 실시예 13은 위의 실시예 중 어느 하나를 추가로 포함한다.
실시예 14: 고객 신원 관리자는 고객과 연관된 디지털 지갑과 통합될 수 있다. 일부 비제한적인 예에 따르면, 실시예 14는 위의 실시예 중 어느 하나를 추가로 포함한다.
실시예 15: 어설션의 암호화된 부분은 영지식 증명을 구현할 수 있다. 일부 비제한적인 예에 따르면, 실시예 15는 위의 실시예 중 어느 하나를 추가로 포함한다.
실시예 16: 어설션은 암호화되지 않은 부분을 포함할 수 있다.
실시예 16의 비제한적인 예에 따르면, 암호화된 부분은 암호화되지 않은 부분 중 적어도 일부에 대해 계산된 암호화 인증 데이터를 포함할 수 있다.
일부 비제한적인 예에 따르면, 실시예 16은 위의 실시예 중 어느 하나를 추가로 포함한다.
따라서, 현재 개시된 주제에 따른 시스템은 제공자가 예를 들어 KYC 신원 증명을 수행하는 작업을 전용 제3자에게 아웃소싱할 수 있게 하여, 제공자가 비용이 많이 들고 시간 소모적인 복제 작업을 수행하지 않고도 새로운 고객을 쉽게 온보딩할 수 있다. 또한, 이 시스템은 고객에게 여러 제공자에 걸쳐 사용될 수 있는 디지털 신원을 제공하므로, 제공자가 고객을 잘못 식별할 위험 없이 단일 고객에 대한 정보를 교환할 수 있다. 남용을 방지하기 위해, 이 시스템은 고객 및 규제 기관의 통제 하에 정보 및 신원의 선택적 교환을 용이하게 할 수 있다. 또한, 정보 보안을 보장하기 위해, 이 시스템은 제공자가 규정을 준수하는 것을 방해하지 않으면서 제공자에게 중요한 정보가 전파되는 것을 최소화할 수 있다.
본 명세서에서 개시된 주제를 더 잘 이해하고 그것이 실제로 어떻게 수행될 수 있는지를 예시하기 위해, 이제 첨부 도면을 참조하여 비제한적인 예로서 실시예가 설명될 것이다.
도 1은 서비스 제공자에 대한 고객 신원의 검증을 용이하게 하기 위한 현재 개시된 주제에 따른 시스템을 도시한다.
도 2는 도 1에 도시된 시스템의 식별 요약 엔진을 도시한다.
도 3은 집계된 신원 어설션이 제공되는 도 1에 도시된 시스템의 예를 도시한다.
시스템 컴포넌트
현재 개시된 주제에 따르면, 하나 이상의 신원 제공자가 고객 신원 정보를 수신, 검증 및 기록하는 것을 용이하게 하고, 이러한 정보의 적어도 일부를 서비스 제공자와 공유하여 서비스 제공자가 민감한 고객 정보를 저장할 필요성이 최소화되도록 한다.
시스템은 예를 들어 2022년 1월 25일에 출원된 제PCT/US2022/13601호에서 설명된 바와 같이 디지털 자산 네트워크를 통한 거래를 관리하도록 구성된 준수 시스템과 함께 또는 그 일부로서 작동하도록 구성될 수 있으며, 그 전체 내용은 참조로서 여기에 포함된다. 현재 개시된 주제의 시스템은 그러한 준수 시스템의 신원 전달 시스템을 구성할 수 있다.
시스템은 고객의 신원에 대해 어설션(assertion)을 만들도록 구성될 수 있으며, 여기서 고객은 하나 이상의 디지털 자산을 소유 및/또는 제어한다. 도 1에 도시된 바와 같이, 시스템은 신원 제공자, 서비스 제공자를 포함하고, 예를 들어 컴퓨터 네트워크를 통해 서로 통신하도록 구성된 하나 이상의 고객 신원 관리자를 더 포함할 수 있다.
신원 제공자(Identity Provider, IP)는 정부가 발행한 식별 문서와 같은 고객 신원 크리덴셜(credential)을 검증하고, 각 고객에 대한 정보를 안전하게 기록하도록 구성된다. IP는 서비스 제공자에게 신원 어설션을 발행하도록 추가로 구성될 수 있다. 그러한 신원 어설션은 디지털 인증서의 형태일 수 있으며, 서비스 제공자가 스스로 검증할 수 있는 방식으로 서비스 제공자에게 고객에 관한 신원 정보 또는 IP에 신원 정보의 존재를 알리도록 구성된다.
서비스 제공자(service provider, SP)는 고객에게 하나 이상의 금융 서비스를 제공하도록 구성된다. SP의 예로는 중앙집중형 금융(centralized finance, CeFi) 거래소, 가상 자산 서비스 제공자(VASP), 은행, 결제 처리 가맹점, 신용 카드 발급자 및 자금 전송 서비스가 포함될 수 있지만 이에 제한되지는 않는다. SP는 특정 고객과의 거래를 수행하기 위해 신원 검증을 요구할 수 있으며, 신뢰할 수 있는 신원 제공자로부터 신원 어설션을 수신하도록 구성될 수 있다. SP는 하나 이상의 SP와 상호작용하여 고객에 대한 정보를 교환하고, 및/또는 여러 SP가 동일한 고객과 상호작용하는지를 검증하도록 구성될 수 있다.
일부 예에 따르면, 서비스 제공자는 분산형 금융(decentralized finance, DeFi) 기구를 제공한다. 예를 들어, SP는 공개 원장에서 사용할 수 있는 "스마트 계약"을 포함할 수 있다. 따라서, 예를 들어, 현재 개시된 주제의 시스템을 구현하여 사용자의 신원을 검증할 수 있음을 입증할 수 있는 DeFi 기구는 고객이 사용할 수 있도록 중앙집중형 금융 기관의 신뢰를 받을 수 있다.
고객 신원 관리자(customer identity manager, CIM)는 고객이 서비스 제공자 및 신원 제공자와 인터페이스할 수 있도록 구성된다. CIM 인스턴스는 암호 화폐와 같은 디지털 자산을 제어하고 저장하도록 구성된 고객 "지갑(wallet)"의 서브 컴포넌트로 통합될 수 있다. CIM은 컴퓨터 네트워크와 통신함으로써, IP 및 SP 시스템과 메시지를 전송 및/또는 수신할 수 있다. CIM 소프트웨어 또는 하드웨어는 고객에 의해 직접 제어될 수도 있고, 및/또는 고객을 대신하여 서비스 제공자에 의해 운영될 수 있다. 일부 예에 따르면, CIM은 예를 들어 범용 컴퓨터를 인터넷에 연결함으로써 간헐적으로만 인터넷에 연결되는 전용 장치(소위 "하드웨어 지갑")에 구현되는 지갑과 통합된다. 일부 예에 따르면, CIM은 소프트웨어 기반의 지갑과 통합되어 있다. 즉, 인터넷에 지속적으로 연결된 범용 컴퓨터에 설치된 소프트웨어에서 구현된다. 일부 예에 따르면, CIM은 하드웨어 지갑과 부분적으로 통합되고, 소프트웨어 기반 지갑과 부분적으로 통합된다.
주어진 시스템에는 이러한 컴포넌트 각각의 다중 인스턴스가 있을 수 있으며, 이러한 컴포넌트는 서로 정보를 교환하기 위해 컴퓨터 네트워크를 통해 통신 가능하게 결합된다.
IP, SP 및 CIM이라는 용어는 주어진 기능 세트를 설명하므로, 당사자가 IP, SP 및/또는 CIM의 역할을 동시에 수행할 수 있다는 것이 이해될 것이다. 예를 들어, 고객에게 하나 이상의 금융 서비스를 제공하고 고객 신원 크리덴셜을 검증하도록 구성된 엔티티는 서비스 제공자에게 신원 어설션을 발행하는 기능을 수행할 때 신원 제공자로서 여기에서 설명될 수 있다. 따라서, 신원 제공자는 도 1에서 다른 서비스 제공자의 일부를 구성하는 것으로 예시된다(IP와 상호 작용하는 SP와 구별하기 위해 괄호 안에 표시됨).
시스템 작동
작동 중에, 시스템은 하나 이상의 기능을 수행하며, 그 비제한적인 리스트는 다음과 같다.
신원 검증
시스템에서 신원을 설정하기 위해, 고객은 신원 제공자와 통신하여 IP에 의해 검증되는 신원 문서를 전달한다. 문서 검증은, 예를 들어 물리적 위치에서 직접, 컴퓨터 네트워크를 통해 전자적으로, 및/또는 다른 적절한 방식이나 그들의 조합을 통해 수행될 수 있다. 이러한 프로세스의 한 가지 예로는 정부 발행 식별, 고객에게 발행된 하나 이상의 청구서 등을 웹사이트에 업로드하는 것이 포함될 수 있지만 이에 제한되지는 않는다. 신원 검증은 정부 기관과의 직접적인 디지털 통신 및/또는 "스마트 카드"에 포함된 디지털 신원 문서의 사용과 같은 디지털 절차를 포함할 수 있다.
일단 신원 제공자가 고객의 신원을 검증하고 나면, 디지털 신원 크리덴셜을 생성하여 고객에게 발행할 수 있다. 이는 고객의 신원에 대한 구조화된 정보뿐만 아니라 신원 제공자에 의해 생성된 암호화 키를 사용하여 이러한 정보를 통해 계산된 디지털 서명과 같은 암호화 인증 데이터를 포함하는 디지털 파일이다. 일부 예에 따르면, IP는 신원 정보를 로컬에 저장할 수 있다.
서비스 등록
고객이 새로운 서비스 제공자(예를 들어, 이전에 등록하지 않아 현재 고객의 신원을 검증할 수 없는 SP)에 등록하기를 원하는 경우, 웹사이트나 모바일 앱을 통해 이루어진 HTTP(S) 요청과 같은 네트워크 연결을 통해 서비스 제공자와 접촉한다. 고객은 예를 들어 자신의 신원에 대한 정보를 지정함으로써 이전에 등록한 신원 제공자를 지시할 수 있다. 이러한 정보에는 고객이 보유한 신원 인증서에 저장된 정보의 서브셋과 신원 인증서에서 도출된 암호화 정보가 포함될 수 있다. 다르게는, 고객은 고객의 컴퓨터에 의해 통해 중재될 수 있는 신원 제공자와 서비스 제공자 사이의 직접 통신 시작을 촉진할 수 있다.
이러한 프로세스에서, 고객은 단일의 특정 신원 제공자를 공개할 수 있다. 다르게는, 고객은 특정 신원 제공자를 공개하지 않고 신원 제공자가 승인된 신원 제공자 세트에 속한다는 사실을 밝힐 수 있다. 후자는 예를 들어 관할권 내의 인증된 신원 제공자 리스트를 참조하거나, 또는 신원 제공자를 인증한 관할 기관에 의해 발행된 디지털 서명 인증서를 지칭하는 암호화 영지식 증명(zero-knowledge proof)을 사용하여 수행될 수 있다. 또한, 고객은 복수의 신원 제공자를 공개할 수 있으므로, 그들이 고객에 대해 제공하는 별도의 정보는 보완적이고 일관성을 확인할 수 있다.
이러한 프로세스가 끝나면, 서비스 제공자는 고객에 대한 관련 정보를 획득함으로써, 고객이 신원 제공자에 등록되어 있고 유효한 상태의 신원을 보유하고 있음을 검증할 수 있다. 이러한 정보는 서비스 제공자의 고객 계정과 연관될 수 있다. 서비스 제공자에 의해 기록되는 정보는 적어도 부분적으로 SP에 의해 요청된 정보와 IP 및 고객이 공개하기로 선택한 정보의 조합으로부터 도출될 수 있다. 일부 예에 따르면, 이러한 정보는 고객 이름과 같은 완전한 신원 정보를 공개할 수 있다. 다른 예에 따르면, 전달되는 정보에는 가명, 즉 고객의 실제 신원과 다른 고객의 식별자가 포함될 것이다. 가명은 신원 제공자가 고객을 고유하게 식별할 수 있도록 선택된다. 각 고객이 등록한 여러 SP에서 공유되는 단일 가명을 가지거나 단일 제공자에 특정한 개별 가명을 갖도록 선택될 수 있다.
서비스 제공자가 알게된 정보는 정확한 세부 사항이나 뒷받침하는 증거를 공개하지 않고 대략적인 요약으로 고객 신원의 속성을 전달할 수 있다. 예를 들어, 고객의 시민권 국가 또는 거주지(구체적인 주소는 아님), 연령대(정확한 연령이나 생일은 아님), 소득 범위 및/또는 순자산 범위가 공개될 수 있다. 신원은 또한 부정적인 성격을 가질 수도 있다. 예를 들어, 특정 시민권 국가를 공개하지 않으면서 고객의 시민권이 특정 거부 리스트에 포함되어 있지 않을 수도 있다.
서비스 제공자는 자금 이체, 가상 자산 서비스 제공자, 보안 및/또는 은행 규정 준수를 포함하되 이에 제한되지 않는 다양한 목적으로 정보를 요청할 수 있다. 예를 들어, 요청된 정보는 고객 알기 제도(KYC), 돈세탁 방지, 테러 자금 조달 방지 및 제재 명령을 준수하고, 여행 규칙 명령을 준수하며, 공인 투자자 상태(예를 들어, 1933년 미국 증권거래법 규정 D에 따른 소득, 순자산), 미국 해외금융계좌신고법(Foreign Account Tax Compliance Act, FATCA)을 준수하고, 및/또는 미국 공정하고 정확한 신용 거래(Fair and Accurate Credit Transaction, FACTA)를 준수하는 데 사용될 수 있으며, 이들 모두는 고객 정보의 수집 및 검증이 필요하다. 정보는 또한 고객을 위한 계정 한도 또는 특징(예를 들어, 옵션 거래, 마진 또는 기타 레버리지)을 결정하고, 및/또는 맞춤형 위험 기반 정책을 위한 데이터로 사용하기 위해 서비스 제공자에 의해 요청될 수도 있다.
서비스 제공자 보고
서비스 제공자가 서비스 제공자로부터 고객의 신원 정보를 수신하면, 고객을 대신하여 서비스를 수행할 수 있다. 이러한 서비스의 본성은 제공자의 특정 본성에 따라 달라질 수 있다. SP는 고객의 신원과 연관시키려는 정보를 기록할 수 있다. 예를 들어, SP는 내부 데이터베이스에 로컬로만 필요한 정보를 저장할 수 있다. 또한, SP는 시스템의 다른 당사자가 관심을 갖는 정보를 획득할 수 있다. 이러한 정보의 예로는 규제 기관이나 시스템의 다른 당사자에게 전달되어야 할 수 있는 고객의 사기 행위에 대한 보고서(예를 들어, "의심스러운 활동 보고서") 또는 체인에서의 고객 활동에 대한 유용한 정보를 전달할 수 있는 정보가 포함될 수 있지만 이에 제한되지 않는다.
이러한 기록을 용이하게 하기 위해, SP는 신원 정보와 유용하게 결합될 수 있는 정보를 신원 제공자 및/또는 다른 당사자에게 전송할 수 있다. 이는 아래에 추가로 설명되는 여러 가지 방식으로 달성될 수 있다.
신원 철회 및 업데이트
시스템의 당사자는 SP가 보유한 신원 정보에 대한 업데이트를 제공할 수 있고, 및/또는 이전에 이루어진 신원 어설션을 철회할 수 있다. 전자는 IP에서 고객 정보가 변경될 때 발생할 수 있으며, 이는 새롭고 업데이트된 정보가 SP로 전송되는 것을 필요로 한다. 다르게는, IP는 하나 이상의 서비스 제공자에 대한 고객의 신원 권한을 철회해야 할 수도 있다. 예를 들어, 서비스 제공자에 등록하기 위해 고객의 신원 정보가 부정하게 접근된 것으로 밝혀진 경우 이러한 상황이 발생할 수 있다. 이를 용이하게 하기 위해, IP는 때때로 브로드캐스트 메시징이나 SP에 전송되는 전용 메시지를 통해 하나 이상의 철회 메시지를 SP에 전송할 수 있다. 이러한 철회 메시지는 이전에 SP에 대해 수행된 신원 어설션이 더 이상 유효하지 않은 것으로 인정되어야 함을 SP가 인식하도록 구성된다. 이러한 프로세스에 대한 메커니즘은 아래에서 자세히 설명된다.
기술 및 구현 고려사항
전술한 메커니즘은 두 가지 다른 구성으로 구현될 수 있다. 중앙집중형 구성에서, 신원 제공자(예를 들어, IP에 의해 인증된 연관된 서버를 포함할 수 있음)는 서비스 제공자와 실시간으로 통신하여 신원 어설션을 전달한다. 이러한 접근 방식의 이점은 HTTP, HTTPS, REST API, HTML, 웹 쿠키 등과 같은 기존의 많은 웹 기반 기술 중 하나 이상을 사용하여 실현될 수 있다는 것이다. 분산형 구성에서, IP는 이러한 값을 저장하고 SP에게 직접 신원에 대한 어설션을 수행할 수 있는 고객의 고객 신원 관리자에게 암호화 객체를 전송한다. 이러한 구성은 상호 배타적일 필요는 없다. 예를 들어, 분산형 구성에는 SP와 IP 사이의 통신이 포함될 수 있다.
공통 요소
각각의 구성에서, 신원 제공자는 고객 및 그들의 계정에 대한 기록을 포함하는 데이터베이스를 유지한다. 기록에는 고객 이름, 주소, 시민권, 여권 세부 정보, 국가 식별 번호, 디지털 통화 주소, 개인에 대해 수행된 증빙 문서 및 검증 절차, 고객 거래 내역, 신용 점수, 자금 출처 등과 같은 정보가 포함될 수 있지만 이에 제한되지는 않는다. 신원 제공자는 또한 이러한 정보의 일부를 대체 형태, 예를 들어, 거래 내역 데이터 모음을 서비스 제공자에게 고객 활동에 대한 스냅샷 평가를 제공하는 "위험 점수"로 변환하는 형태로 요약하도록 구성될 수도 있다.
IP는 컴퓨터 네트워크와 통신하도록 구성됨으로써, 블록체인 기반 시스템(예를 들어, 비트코인, 이더륨 등)과 같은 하나 이상의 합의 네트워크에 접속할 수 있다. IP는 또한 컴퓨터 네트워크를 통해 고객 머신, 고객 신원 관리자, 서비스 제공자 및/또는 기타 연결된 컴포넌트와 상호 작용할 수도 있다. (당업자는 신원 제공자가 이러한 기능을 여러 컴퓨터 또는 위치에 걸쳐 분할할 수 있다는 것을 이해할 것이다.)
각 신원 제공자와 하나 이상의 서비스 제공자는 신뢰 관계를 설정할 수 있다. 이러한 관계에는 서비스 제공자가 해당 IP를 실제 신원 정보의 소스로서 결정하는 것이 필요하다. 서비스 제공자는 여러 신원 제공자와 신뢰 관계를 설정할 수 있으며, 이러한 신뢰 관계는 신원의 특정 요소에 따라 조건이 지정될 수 있다. 예를 들어, 서비스 제공자는 특정 관할권에 대한 신원을 검증하기 위해 신원 제공자를 신뢰할 수 있지만, 다른 관할권에 대해서는 그렇지 않다(예를 들어, 미국에 대해서는 신원을 검증할 수 있지만, 프랑스에 대해서는 그렇지 않을 수 있다.) 신뢰 관계는 또한 반대 방향으로도 적용될 수 있다. 예를 들어, IP는 미리 식별된 특정 SP에 대한 어설션만을 지원할 수 있거나, 또는 모든 SP에 대한 어설션을 지원할 수 있다.
이러한 신뢰는 신원 제공자와 서비스 제공자의 개별 쌍 사이에 설정될 수 있거나, 예를 들어 관할권 내의 인증된 신원 제공자의 리스트를 통해 또는 관할권 기관에 의해 발행된 디지털 서명 인증서를 통해 복수의 신원 제공자 및/또는 서비스 제공자를 신뢰할 수 있는 것으로 표시하는 시스템을 사용할 수 있다.
중앙집중형 구성
중앙집중형 구성에서, 신원 제공자는 예를 들어 아래에서 설명된 바와 같이, 통신 네트워크를 통해 직접적으로 또는 중개자로서 고객의 컴퓨터를 사용하여 실시간으로 SP와 통신한다.
고객은 특정 서비스 제공자와 새로운 관계를 설정할 수 있고, 및/또는 신원 검증이 필요한 SP에서 동작을 수행할 수 있다. 이러한 경우, SP와 IP는 서로(직접 또는 간접적으로) 통신하여 특정 정보를 교환할 수 있다. 이는 다음을 포함할 수 있지만, 이에 제한되지는 않는다.
1. SP는 IP에게 구체적으로 어떤 신원 정보가 필요한지를 지시한다. 이것은 사용 가능한 모든 정보가 필요한지 또는 신원 정보의 서브셋이 필요한지를 지시하는 일반적인 설명을 포함할 수 있다. 이러한 정보를 지정하는 메커니즘은 아래에서 설명된다.
2. IP는 SP가 신원에 대한 정보를 수신할 권한이 있는지 여부와 수신되어야 하는 데이터를 결정한다. 이러한 결정 프로세스에는 IP와 SP 간의 신뢰 관계 존재를 포함하여 IP에 대한 로컬 정책이 포함될 수 있다. 또한, 고객이 정보 전송에 대해 명시적인 승인을 제공하도록 요구하는 단계가 포함될 수도 있다. SP에 전달할 데이터에 대한 결정은 아래에서 설명될 신원 요약 엔진이라는 컴포넌트에 의해 수행된다.
3. IP는 고객의 신원에 대한 정보를 SP에게 전달한다. 이는 신원 정보를 필드로 인코딩하는 데이터 구조와 관련된 전송을 포함할 수 있다. 각 필드에는 고객 신원 정보의 일 측면이 포함될 수 있으며, 모든 필드는 동일한 고객에 속하는 것으로 함께 묶여 있다. 이러한 데이터 구조에는 또한 고객 식별자 값도 포함되어야 한다. IP는 또한 전달 예정인 다른 SP로부터 업데이트된 위험 정보와 같이 수신된 보조 기록을 전달할 수도 있다.
IP에 의해 SP로 전달되는 정보 중 적어도 일부는 어설션의 형태로 존재한다. 즉, 정보 자체는 SP로 전송되지 않고, IP에 남아 있다. 어설션을 통해 SP가 정보 자체에 접근하지 않고도 정보의 존재에 관해 IP에 의존할 수 있다.
4. 나중에, SP는 고객에 대한 정보(예를 들어, 사기 거래에 대한 정보 또는 업데이트된 위험 점수 정보)를 개발할 수 있다. 이러한 시점에서, SP는 고객에 대한 IP의 지식을 늘리는 데 추가로 사용될 수 있는 정보를 IP에게 보고할 수 있다. 이러한 정보는 IP의 데이터베이스에 저장될 수 있고, 및/또는 고객의 신원과 연결된 식별자를 사용하여 제3자에 의해 저장될 수 있다.
IP는 SP에게 전달하기 위해 고객의 신원 정보 중 적어도 서브셋을 식별하도록 구성될 수 있다. 여기에서의 본 개시와 첨부된 청구범위에서, "서브셋(subset)"이라는 용어는 데이터베이스의 신원 필드의 일부(즉, 문자 그대로의 의미에서 서브셋)(즉, 일부 필드가 선택적으로 전달되고, 일부는 전달하지 않음) 및 감소된 입도를 제공하는 일반화된 형태로 제공되는 정보를 포함할 수 있다. 예를 들어, IP 데이터베이스의 필드는 고객의 정확한 생년월일을 지정할 수 있지만, 그러나 IP는 정확한 데이터 대신에 대략적인 날짜나 나이(예를 들어, "고객은 21세 이상임")를 전달할 수 있다. IP는 명시적인 고객 정보 식별 대신에 가명을 생성하도록 추가로 구성될 수 있다. 이는 IP와 SP 사이에서 해당 고객에 대해 고유한 고객 식별자 또는 번호일 수 있다.
고객에게 전달되고 SP와 교환되는 정보는 중개자에 의한 무단 변조 및/또는 도청으로부터 안전한 방식으로 전달될 수 있다. 이는 인터넷 프로토콜 연결을 통해 두 머신 간에 암호화되고 암호로 인증된 통신을 제공하는 전송 계층 보안(Transport Layer Security, TLS) 프로토콜을 사용하여 SP와 IP 사이에 보안 채널을 설정함으로써 수행될 수 있다. 그러나, 대체 메커니즘이 사용될 수 있다. 예를 들어, 신원 제공자는 웹 기반 리디렉트(redirect) 및 기타 표준 웹 기술을 사용하여 정보를 SP에게 전달할 수 있으며, 이러한 정보는 변조를 방지하기 위해 암호화 방식으로 인증되어야 한다. 당업자는 JSON 웹 토큰 표준을 포함하여 그러한 통신을 위한 많은 공통 기술이 존재한다는 것을 인식할 것이다.
따라서, IP는 기밀성 및 신뢰성이 유지되고 필요한 고객 식별 정보만이 SP에게 공개되는 것을 보장하면서 고객 신원 정보를 SP에게 안전하게 전달하도록 구성될 수 있다. 또한, IP는 SP와 고객 고유 식별자를 설정하여 이러한 고객에 관한 추가 통신이 IP/SP 통신의 일부로서 고유하게 참조될 수 있도록 한다.
당업자에게 친숙할 전술한 메커니즘의 변형은 IP와 SP 사이에 직접 메시지를 전송하는 대신에, IP와 SP가 둘 사이에 메시지를 전달하기 위해 고객의 컴퓨터(예를 들어, 웹 브라우저)를 중재자로서 사용하여 메시지를 교환할 수 있다는 것이다. 이러한 중개 통신 메커니즘을 사용하는 것은 단일 사인온(Single Sign-On) 시스템과 같은 웹 기반 시스템에서 일반적인 접근 방식이다.
분산형 구성
시스템의 분산형 구성은 각 고객을 인증하기 위해 신원 제공자와 서비스 제공자 사이의 실시간 통신을 요구하지 않는다. 대신에, 고객에게는 관련 신원 정보가 포함된 암호화 인증서가 제공된다. 이러한 인증서는 고객에 의해 고객 신원 모듈(customer identity module, CIM)에 저장될 수 있다. 일부 예에 따르면, 인증서의 일부(예를 들어, 인증서의 공개 부분 및/또는 약속/해시)는 블록체인과 같은 공개 원장에 저장될 수 있다. 고객 신원 모듈은 컴퓨터 네트워크를 통해 서비스 제공자 및 신원 제공자와 통신하도록 구성될 수 있다. 서비스 제공자가 고객 신원의 인증을 요구할 때, 신원 어설션, 즉, 예를 들어 아래에서 설명된 것처럼 암호화 인증 방식으로 고객 신원에 대한 정보를 지정하는 암호화 객체를 획득하기 위해 CIM과 상호 작용한다.
고객은 특정 서비스 제공자와 새로운 관계를 설정할 수 있거나, 또는 신원 검증이 필요한 SP에서 행동을 수행할 수 있다. 이런 일이 발생하면, SP와 CIM은 특정 정보를 교환하기 위해 통신(직접적으로 또는 제2 컴퓨터를 통해 간접적으로)할 것이다. 이것은 다음을 포함하지만 이에 제한되지는 않는다.
1. SP는 CIM에 구체적으로 어떤 신원 정보가 요청되는지를 지시한다. 여기에는 사용 가능한 모든 정보가 필요하거나, 또는 신원 정보의 서브셋이 필요함을 지시하는 일반적인 설명이 포함될 수 있다. 이러한 정보 요청은 SP의 전용 통신을 통해 이루어질 수 있거나, 또는 SP가 사전에 공지할 수 있다. 특히, 정보 요청은 SP의 가상 지갑 주소에 첨부될 수 있으므로, 이러한 가상 지갑과 관련된 모든 자금 이체에는 특정 요청 정보 제공이 적용됨을 예비 고객에게 알릴 수 있다.
2. CIM은 SP가 신원에 대한 정보를 수신할 권한이 있는지 여부와 수신해야 하는 데이터를 결정한다. 이러한 결정 프로세스에는 CIM에 대한 로컬 정책뿐만 아니라 IP에 의해 정의되고 고객의 신원 인증서에 저장되는 일부 정책이 포함될 수 있다. 또한, 고객이 정보 전송에 대해 명시적인 승인을 제공하도록 요구되는 단계가 포함될 수도 있다. SP에게 전달할 데이터에 대한 결정은 이러한 구성의 CIM 내에 있는 신원 요약 엔진의 수정된 변형에 의해 이루어진다.
3. CIM은 고객의 신원에 대한 정보를 SP에게 전달한다. 이러한 전달은 신원 정보를 필드로 인코딩하는 데이터 구조를 포함하는 전송으로 구성될 수 있다. 각 필드에는 고객 신원 정보의 한 측면이 포함될 수 있으며, 모든 필드는 동일한 고객에 속하는 것으로 함께 묶여 있다. 이러한 데이터 구조에는 고객 식별자 값도 포함되어야 한다. 이러한 정보가 진짜임을 보장하기 위해, CIM은 또한 신원 인증서를 기반으로 작성된 암호화 증거(및/또는 서명)를 첨부할 수도 있다. 이러한 증거는 정보가 진짜임을 보장하기 위해 SP에 의해 검증될 수 있다. 선택적으로, 증거는 신원 요약 엔진에 의해 식별된 선택적 공개가 특정 IP 정책과 관련하여 올바르게 공식화되었음을 입증할 수 있다.
CIM에 의해 SP에게 전달되는 정보 중 적어도 일부는 어설션의 형태로 존재한다. 즉, 정보 자체는 SP에 전송되지 않고, CIM에 남아 있다. 어설션을 통해 SP는 정보 자체에 접근하지 않고도 정보의 존재 여부를 CIM에 의존할 수 있다.
4. SP는 CIM에 의해 제공되는 정보를 사용하여 선택적으로 고객 위험 점수에 대한 업데이트된 정보와 같은 고객에 대한 다른 정보를 요청할 수 있다. 이러한 정보는 공개 위치에 저장되거나(예를 들어, 블록체인에 게시되거나 공개적으로 접근 가능한 데이터 저장 시스템에 저장됨) 또는 원래 IP와 같은 개인 서비스로부터 획득될 수 있다. 이러한 서비스의 신원과 위치는 이러한 정보를 획득하는 데 필요한 고객 식별자 및 액세스 코드와 함께 단계 (3)에서 전달된 정보의 일부로서 CIM에 의해 SP에게 제공될 수 있다.
5. 나중에, SP는 고객에 대한 새로운 정보(예를 들어, 사기 거래에 대한 정보 또는 업데이트된 위험 점수 정보)를 개발할 수 있다. 이러한 시점에서, SP는 고객에 대해 알려진 정보를 늘리는 데 추가로 사용될 수 있는 정보를 보고할 수 있다. 이러한 정보는 이전 단계에서 식별된 위치(예를 들어, 공용 저장 위치 또는 IP와 같은 개인 저장 위치)로 전송될 것이다. 그것은 이러한 위치의 고객 식별자에 결합된다. 이러한 데이터를 보호하는 추가 요소로서, 공공 장소에 저장할 때 암호화될 수 있다. 이러한 데이터에 필요한 암호 해독 키는 신원 인증서에 포함되어 단계 (3)의 일부로서 CIM으로부터 SP로 전달될 수 있다.
중앙집중형 구성과 관련하여 전술한 바와 같이, CIM은 IP로부터의 입력으로 SP에게 전달하기 위해 고객의 신원 정보의 서브셋을 식별하도록 구성될 수 있다. CIM 또는 IP는 또한 명시적인 고객 식별 정보 대신에 가명을 생성할 수도 있다. 이는 IP와 SP 사이에서 해당 고객에 대해 고유한 고객 식별자 또는 번호일 수 있다.
IP가 반드시 모든 신원 어설션에 관여하는 것은 아니기 때문에, CIM이 전적으로 (SP가 신뢰할 수 없는) 고객의 통제 하에 있더라도 CIM이 SP에게 고객의 신원에 대한 유용한 정보를 어설팅할 수 있도록 암호화 기술이 제공될 수 있다. 이를 달성하기 위해, CIM은 예를 들어 익명 크리덴셜 및 영지식 증명 분야로부터 하나 이상의 암호화 기술을 구현하여 각 신원 어설션에 대해 "비대화형 정확성 증명"을 생성하도록 구성될 수 있다. 디지털 객체인 이러한 증명은 신원 인증서 및 기타 로컬 키 자료를 입력으로 사용하여 CIM에 의해 생성되며 SP에 의해 검증될 수 있다. 증명이 검증되면, SP는 신원 어설션에 포함된 정보가 진짜라는 것을 확신할 수 있다(즉, 신원 인증서에 있는 인증된 데이터의 실제 요약을 나타냄). 이것은 손상된 CIM이라도 SP에 잘못된 신원 어설션을 발행할 수 없음을 보장할 수 있다. 아래에서 설명되는 바와 같이, 신원 제공자는 고객과 연관된 신원 인증서를 철회하고, 및/또는 그러한 인증서를 업데이트된 정보로 수정하도록 구성될 수 있다.
분산형 설정은 SP에 의한 정보 보고를 추가로 지원할 수 있다. SP에 의해 제공되는 정보는 위에서 설명된 보고와 유사할 수 있다. 그러나, 보고가 발생하는 메커니즘은 다를 수 있다. 일 실시예에서, SP는 정보를 IP에게 직접 보고하고(중앙집중형 설정에서와 같이), IP로부터 직접 업데이트를 수신할 수 있다. 그러나, 다른 실시예에서, SP는 공공 또는 개인 저장 엔티티, 예를 들어, 블록체인, 파일 공유 서비스 및/또는 다른 고객에게 전달하기 위한 데이터만을 보유하는 다른 제3자와 같은 외부 시스템에게 정보를 보고할 수 있다. 이를 활성화하기 위해, 신원 인증서에는 인증 토큰과 데이터 보고 위치가 포함될 수 있으므로, SP는 이러한 서비스를 통해 데이터를 교환할 수 있다. SP에 의해 보고되는 데이터는 CIM 신원 어설션에 의해 SP에게 지정된 암호화 키로 암호화될 수도 있으며, 다른 SP로부터 SP에 의해 수신되는 보고서는 동일한 암호화 키(또는 관련 키)를 사용하여 해독될 수 있다. 이러한 메커니즘은 아래에서 추가로 자세히 설명된다.
CIM은 고객의 머신에 위치하므로, IP에서 사용할 수 없는 고객 거래에 대한 추가 정보에 접근할 수도 있다. 예를 들어, CIM이 고객의 디지털 "지갑"에 있는 경우, 수신자 정보 및 금액을 포함하여 모든 과거 거래의 전체 리스트에 접근할 수 있다. CIM은 이러한 정보를 SP에 대한 어설션에 통합하도록 구성될 수 있다. 예를 들어, 고객이 SP와 기존 관계를 갖고 있다는 증거로 일부 트랜잭션이 특정 SP에게 발행되었음을 어설팅하도록 CIM이 구성될 수 있다. 이러한 정보는 명시적으로 제공되거나(예를 들어, 디지털 통화 네트워크의 명시적인 거래를 참조하여) 또는 개인 정보 보호 암호화 기술을 사용하여 요약될 수 있다. 이는 블록체인과 같이 공개적으로 표시되는 암호화폐 원장에서 특정 기준을 충족하는 거래(또는 트랜잭션)의 존재를 지시하는 영지식 증명을 사용하여 수행될 수 있다. 그러한 증명을 계산하기 위한 적절한 기술은 해당 분야에 잘 알려져 있다.
기술적 세부 사항
신원 요약 엔진 및 신원 요청 및 어설션 신택스
여기에서 설명된 시스템은 서비스 제공자에게 저장되는 고객에 관한 고객 개인 식별 정보(Personal Identifiable Information, PII)의 양을 최소화할 수 있는 방식으로 서비스 제공자에게 정보를 선택적으로 개시하도록 구성될 수 있다. 어떤 정보가 개시될지에 대한 결정은 서비스 제공자마다 다를 수 있다. 예를 들어, 다양한 서비스 제공자 간에 데이터를 안전하게 저장하기 위한 요구사항 및 능력으로 인해 달라질 수 있다. (선택적 개시에는 특정 필드를 삭제하는 것뿐만 아니라 일부 신원 정보를 덜 구체적인 형태로 변경하는 것, 예를 들어 정확한 데이터를 카테고리 또는 요약으로 축소하는 것이 포함될 수 있다.) 시스템이 많은 수의 서비스 제공자 및 고객으로 확장될 수 있도록 하기 위해, 선택적 개시 프로세스는 상당 부분 자동화될 수 있다.
이러한 자동화된 선택적 개시 프로세스를 가능하게 하기 위해, 예를 들어 도 2에 도시된 바와 같이 신원 요약 엔진(identity summarization engine, ISE)이 제공될 수 있다. ISE는 필요한 데이터와 신원 정책과 같은 선택적인 일부 보조 정보를 자세히 설명하는 서비스 제공자로부터의 요청뿐만 아니라 하나 이상의 고객 데이터 기록을 기록하도록 구성된다. 일부 예에 따르면, 보조 정보는 비식별 데이터, 예를 들어 계정과 관련된 거래 내역, 계정과 관련되지 않은 고객 활동, 자금 출처 등을 포함하지만 이에 제한되지 않는 고객 활동 및/또는 계정(예를 들어, 블록체인 및/또는 서비스 제공자에 기록된 계정)과 관련된 데이터와 관련될 수 있다. 그런 다음, ISE는 고객 데이터로부터 특정 필드를 선택하거나 또는, 예를 들어 정확하지만 덜 구체적인 형태로 고객 데이터의 서브셋을 제공함으로써 SP에게 선택적으로 개시되어야 고객 데이터를 결정한다. ISE는 신원 제공자에 의해 직접(예를 들어, 중앙집중형 설정) 운영될 수 있거나 또는 CIM의 일부로서 배포될 수 있다.
ISE의 작동
작동 시, ISE는 SP로부터의(SP로부터 직접 또는 IP 또는 CIM에 의해 제공됨) 요청, 고객 기록 및 정책(추가 정보도 취해질 수 있더라도)을 입력으로 수신한다. ISE는 필드가 SP에게 전달되어야 하는지, SP에게 전달된 어설션에서 생략되어야 하는지, 덜 구체적인 정보를 사용하여 일반화되어야 하는지를 결정하기 위해 고객 데이터의 각 필드를 처리한다. 또한, ISE는 하나 이상의 다른 필드로부터의 정보와 결합하여 (현재 형태 또는 서브셋, 즉 그들의 일부 또는 일반화로) 해당 필드가 SP에게 전달되는 어설션에 포함되어야 하는 것으로 결정할 수 있다. 각 필드에서 ISE의 작동은 예를 들어 어떤 정보가 전달, 요약 또는 보류되어야 하는지, 및/또는 SP별로 어떤 정보가 결합되어야 하는지를 지시할 수 있는 정책에 따라 달라질 수 있다.
ISE에 의해 사용되는 정보는 구현마다 다를 수 있다. 예를 들어, SP 요청에는 SP에 필요한 필드에 대한 자세한 정보가 포함될 수 있거나, 또는 그러한 세부 정보가 포함되지 않을 수 있다. 정책은 각 필드를 처리하기 위한 규칙을 인코딩하는 범용 컴퓨터 프로그래밍 또는 스크립팅 언어로 표현될 수 있으며, 튜링 완전(Turing-complete)일 수 있다. 다르게는, 각 필드에 대해 어떤 동작이 취해질지를 결정하기 위해 데이터 처리 시스템에 의해 해석될 수 있는 보다 제한된 규칙 세트를 간단히 설명할 수 있다.
신원 요청 및 어설션 언어
ISE를 실현하기 위해, 일부 예에 따른 시스템은 SP로부터의 신원 요청뿐만 아니라 SP에 대해 수행된 신원 어설션을 지정하기 위한 요청 언어를 지정할 수 있다. 요청 언어는 SP에 필요한 신원 필드와 세부 수준을 기계 판독 포맷(예를 들어, JSON과 같은 포맷)으로 지정한다. 예를 들어, SP는,
required_fields = {full_name, age, investor_status, legal_jurisdiction}
과 같은 필수 필드의 튜플을 지정할 수 있으며,
여기서 상기 토큰 이름 각각은 고객 기록 내에 저장된 표준 정보를 나타낸다. 또한, SP는 특정 필드가 요약된 형태로 전달될 수 있음을 식별할 수 있다. 예를 들어, SP 요청은 "고객이 21세 이상인지 여부"만 알고자 요청함을 지시할 수 있다. 이는 다양한 가능한 포맷으로 표현될 수 있다. SP는 또한 신원 필드가 선택 사항으로 처리되거나 플레이스홀더(placeholder)(예를 들어, 고객 이름 대신 가명)로 대체될 수 있는 시기를 식별할 수도 있다. 예를 들어:
required_fields = {full_name, age:{>=21}, investor_status, legal_jurisdiction={!="EU"}}
는 SP가 고객이 21세 이상이며 고객이 명시적으로 "EU" 관할권에 속하지 않는다는 사실만을 요청하고 있음을 지시할 수 있다.
모든 요청은 이러한 정보가 SP에게 전달될 수 있는지 여부를 결정하기 위해 ISE에 의해 처리될 수 있으며, (허용되는 경우) 각 필요한 필드는 고객 데이터 기록으로부터 추출되어 SP에게 전달될 수 있다. 응답 메시지는 요청된 데이터를 포함하는 기계 판독 가능 형태인 어설션 언어로 표현되며, 더욱이 업데이트를 용이하게 하기 위한 고객 식별자 및 필드를 포함할 수 있다. 예를 들어:
{
"Customer_id", 92348723483,
"full_name": "Arthur Wallace Peterson",
"age": 43,
"investor_status": "accredited",
"legal_jurisdiction: "US",
"update_location": "https://identity-provider.com/updates"
"update_token": "932hbc0wehraehamsnebkaadk2efsvds2bzkhbjWz"
}
어설션 언어 메시지는 특정 요청(예를 들어, 고객 데이터 기록 지정)에 응답하는 컴포넌트를 포함할 수 있다. 또한, 정보 필드가 삭제되거나 요약된 시기를 식별하는 능력과 같은 표준 요소를 포함할 수도 있다. 예를 들어, 다음의 응답은 위에서 설명된 두 번째 쿼리에 응답하는 요약을 지시할 수 있으며, 또한 기록의 Investor_status 컴포넌트가 정책 제한으로 인해 작제되었음을 지시할 수도 있다.
{
"Customer_id", 92348723483,
"full_name": "Arthur Wallace Peterson",
"age"[>=21]: TRUE,
"investor_status": {null, not_available_with_policy},
"legal_jurisdiction"[!=EU]: TRUE,
"update_location": "https://identity-provider.com/updates"
"update_token": "932hbc0wehraehamsnebkaadk2efsvds2bzkhbjWz"
}
상기 예는 요청 및 응답 언어의 형태 중 하나이다. 전체 구현은 표준 규칙과의 상호 운용성 또는 간결성을 위해 상이한 표기법을 사용할 수 있다.
위에 예시된 바와 같이, 신원 어설션은 또한 업데이트된 정보 및 고객 철회 정보가 발견될 수 있는 위치를 포함할 수 있다. 이는 URL로 식별될 수 있으며, 데이터에 접근하고 검색된 정보를 해독하는 데 필요한 인증 토큰(예를 들어, 비밀번호) 및 해독 키와 같은 식별자를 포함할 수도 있다.
정책
SP 요청 및 고객 데이터 외에도, ISE는 신원 제공자에 의해 선택된 하나 이상의 정책을 입력으로 취하도록 구성될 수 있다. SP 요청과 함께 이러한 정책은 ISE가 어떤 필드를 반환해야 하는지 및 어떤 필드가 요약되거나 삭제되어야 하는지를 결정할 수 있게 한다. 전술한 바와 같이, 정책은 SP 요청 및 고객 데이터의 요소에 대해 작동할 수 있고, 및/또는 데이터를 출력하거나 요약하는 방법에 대한 결정을 내릴 수 있는 컴퓨터 프로그램 또는 스크립트를 포함할 수 있다. 다르게는, 정책은 ISE가 결정을 내리기 위해 이러한 데이터를 평가할 수 있는 기본 규칙을 간단히 지정할 수 있다.
정책은 전체 SP 요청 및 고객 데이터에 대해 작동하는 것으로 위에서 설명되었지만, 부분적인 고객 데이터에 대해서도 추론할 수 있다는 것이 이해될 것이다. 예를 들어, 고객 데이터는 고객 기록의 필드 이름만을 포함될 수 있으며, ISE는 어떤 필드가 요약되거나 생략되어야 하는지에 대한 지침을 출력할 수 있다.
암호화 인증
새로운 신원 어설션을 수용하기 위해, SP는 어설션이 진짜임을 보장해야 한다. 이는 두 가지를 암시한다. 이들 두 가지는 (1) 신원 어설션이 신원 제공자가 보유한 정보와 일치하는 것과, 선택적으로 (2) 전송, 생략 및 요약할 정보에 대한 특정 결정이 신원 제공자에 의해 승인되는 것이다.
중앙집중형 설정
중앙집중형 설정에서, IP와 SP는 직접 또는 고객의 컴퓨터를 중재자로 사용하여 실시간으로 통신한다. 이러한 설정에서, 암호화 인증은 다양한 방식으로 처리된다.
1. SP와 IP 사이의 직접 통신의 경우, 두 당사자는 전송 계층 보안 프로토콜(이전에 SSL로 알려짐)을 사용할 수 있다. 이러한 프로토콜은 디지털 인증서를 사용하여 두 당사자의 일방적 또는 상호 인증을 제공하고, 두 당사자 간에 암호화되고 인증된 연결을 설정한다. IP에게 직접 그러한 연결을 개시하는 SP는 암호화 프로토콜이 연결이 유효하고, 수신된 데이터가 진짜인 것, 예를 들어 제3자에 의한 수정 또는 데이터 삽입으로부터 보호되는 것을 보장하기 때문에 신원 어설션을 포함하는 연결을 통해 수신된 모든 데이터의 신뢰성을 검증할 수 있다.
2. SP와 IP 사이의 간접 통신의 경우, 두 당사자는 디지털 서명 또는 메시지 인증 코드를 사용하여 IP에서 SP 간에 전달되는 메시지를 인증할 수 있다. 이러한 값은 예를 들어 JWT 토큰이나 URL을 통해 전달될 수 있다. 중재자의 웹 브라우저를 통해 두 시스템 간에 암호화되고 인증된 정보를 전달하는 다수의 실용적인 해결수단이 문헌에 공지되어 있다.
이러한 설정에서 신원 어설션이 신원 제공자로부터 직접 도출되므로 언제든지 SP가 어설션이 진짜인지를 검증할 수 있고, SP는 신원 정보의 요약이 또한 IP에 의해 결정됨을 검증하도록 구성될 수 있다는 것이 이해될 것이다. 이는 이것이 진실임을 SP에게 증명하기 위해 추가 암호화 메커니즘을 제공할 필요성을 제거할 수 있다.
분산형 설정
이러한 설정에서, IP는 고객의 신원에 대한 관련 세부사항을 포함하는 신원 인증서를 고객(구체적으로, 고객 신원 관리자 컴포넌트)에게 제공한다. 그런 다음, CIM은 SP가 인증된 것으로 검증할 수 있도록 SP에게 신원 어설션을 수행해야 한다.
일부 예에 따르면, CIM에서 SP로의 신원 어설션은 임의의 선택적인 개시 또는 필드의 요약 없이 CIM에서 SP로 전체 신원 인증서를 전송함으로써 이루어진다. 이러한 설정에서, 신원 인증서에는 신원 제공자에 의해 공식화된 내용에 대한 디지털 서명이 포함될 수 있다. 신원 인증서를 수신하면, SP는 IP의 공개 키에 대한 서명이 유효한지를 검증함으로써 인증서가 유효한지(즉, IP에 의해 생성되는지)를 검증할 수 있다. (디지털 서명은 문서의 신뢰성을 증명한다는 점에서 실제 서명과 유사한 암호화 객체라는 점을 이해해야 한다. 디지털 서명과 관련하여, 서명 당사자[이 경우 IP]는 임의의 메시지[신원 인증서 데이터]에 대한 서명을 만들 수 있는 비밀 키를 보유하여 이러한 서명이 IP에 의해 모든 당사자에게 발행된 두 번째 관련 "공개 키"를 사용하여 진짜인지 검증될 수 있도록 할 수 있다.)
일부 예에 따르면, 시스템은 SP가 진위를 검증하도록 허용하면서 선택적 개시를 허용하도록 구성된다.
SP가 진위 여부를 검증하도록 허용하면서 선택적 개시가 허용되는 일부 예에 따르면, IP는 각 데이터 필드에 대한 디지털 약속을 계산한 후 모든 약속 값을 결합하고 결합된 결과에 서명하도록 구성된다. 신원 인증서는 서명과 함께 디지털 약속의 전체 리스트를 포함하며, CIM에는 또한 데이터 필드의 일반 텍스트 리스트와 각 필드에 대한 약속 "개방" 값도 제공된다. CIM이 신원 어설션을 SP에게 전송하는 경우, SP에게 공개하려는 데이터 필드에 해당하는 모든 약속에 대한 "개방" 값과 함께 데이터 필드 자체와 함께 약속 및 서명으로 구성된 전체 신원 인증서를 전송한다. 그런 다음, SP는 서명이 유효한지, 각 데이터 필드와 개방 값이 대응하는 약속과 일치하는지를 검증할 수 있다. (디지털 약속은 봉투와 유사한 암호화 객체이다. 약속을 하기 위해, 데이터 필드가 일부 선택적 랜덤 데이터와 함께 입력으로 제공되며, 그 결과는 데이터 필드의 내용 및 "공개" 값을 공개하지 않는 약속이라는 객체이다. 약속, 공개 값 및 내용이 주어지면, 모든 당사자는 약속이 일관성이 있는지를 검증할 수 있다. 약속의 핵심 속성은 일단 공식화되면 약속이 공식화된 것과 다른 데이터 값을 "개방"하는 것이 가능해서는 안된다.)
이러한 예에 따르면, CIM은 SP에게 데이터 필드를 선택적으로 공개하도록 구성될 수 있다. CIM이 선택적으로 공개하려는 필드의 경우, 데이터 필드와 약속 공개(신원 인증서에 포함된 약속에 추가)를 제공하도록 구성될 수 있다. CIM이 공개하고 싶지 않은 경우, 데이터 필드와 약속 공개를 생략한다. 그런 다음, SP는 선택적으로 공개된 모든 값이 신원 인증서와 일관되고 진짜라는 것을 확신할 수 있지만, SP는 CIM이 공개하지 않기로 선택한 값을 알지못한다.
보다 효율적일 수 있는 이러한 구조의 다양한 변형이 가능하다는 것이 이해될 것이다. 예를 들어, IP는 해시 트리의 잎에 포함될 수 있는 모든 약속에 대해 트리에 대한 머클 해시 트리(Merkle hash tree)를 계산하고 모든 공개된 값이 정확한 것으로 SP를 충족시키기 위해 해시 트리의 일부를 공개하도록 선택할 수 있다. CIM은 공개하려는 값에 대해 머클 해시 트리의 일부를 전송할 수 있다. 이러한 접근 방식에 따르면, SP로 전송되는 데이터의 수량은 신원 인증서의 필드 개수에 따라 저선형적(sublinear)일 수 있다.
위의 접근 방식은 신원 인증서의 필드를 선택적으로 공개하는 것을 용이하게 할 수 있다. 요약을 제공하기 위해, CIM이 인증서의 원래 값을 공개하지 않고 신원 인증서에 있는 하나 이상의 필드의 수학적 함수를 공개할 수 있게 하는 암호화 방법이 있을 수 있고, 이러한 함수가 올바르게 계산되었음을 SP에게 확신시키기 위해 제공될 수 있다. 예를 들어, 수학적 함수는 고객의 나이를 입력으로 받아 고객이 21세 이상인 경우 "참(TRUE)"을 출력할 수 있다. 다른 함수는 정보를 "버킷팅(bucketing)"하거나 그렇지 않으면 그것을 요약하는 등 고객 정보를 덜 정확한 표현으로 변환할 수 있다.
분산형 설정의 대안적인 실시예는 CIM이 신원 어설션을 생성할 수 있도록 "익명 크리덴셜" 기술을 사용한다. 구조화된 인증 문서에 대해 암호화 어설션을 수행하는 일련의 암호화 기술이 알려져 있다. 이러한 패러다임에서, 중앙 "기관"은 예를 들어 여러 필드로 구성된 정보를 포함하는 "크리덴셜"이라는 문서에 암호화 방식으로 서명한다. 이러한 크리덴셜은 기관에 의해 직접 서명되어 고객에게 제공될 수 있거나, 또는 크리덴셜 정보를 소유한 사람이 기관이 크리덴셜에 대한 정보(또는 일부)를 알지 못하고 이러한 크리덴셜에 대한 서명을 획득하기 위해 기관과 상호 작용할 수 있는 방식으로 "암묵 서명"을 사용하여 서명될 수도 있다. 그 후, 서명된 문서를 보유하고 있는 고객은 크리덴셜의 특정 내용에 대한 어설션을 생성할 수 있다. 예를 들어, 고객은 그러한 크리덴셜을 보유하고 있거나, 또는 크리덴셜이 특정 정보를 포함하는 일부 제3자("검증자"라고 함)에게 증명을 지시하는 암호화 메시지를 생성하여 크리덴셜을 "보여줄(show)" 수 있다. 이러한 검증자는 원래 기관과 동일한 당사자일 수 있거나, 또는 검증자는 제3자일 수 있다. 이러한 "익명 크리덴셜"은 크리덴셜 "표시(show)" 메시지가 해당 기관에 의해 서명된 원래 크리덴셜에 다시 쉽게 연결되지 않도록 보장할 수 있다. 따라서, 기관이 많은 크리덴셜에 서명한 후 크리덴셜에 대한 "표시" 메시지를 보게 되면, 이러한 크리덴셜 중 어느 것이 표시되는지 결정할 수 없어야 한다. 마찬가지로, 검증자에 의해 검출된 이러한 사기 행위 없이 고객이 기관에 의해 발급되지 않은 크리덴셜을 "보여주는" 것이 불가능해야 한다. 적합한 익명 크리덴셜은 해당 분야에 잘 알려져 있다.
익명 크리덴셜의 보다 강력한 변형은 역시 해당 분야에서 잘 알려진 "효율적인 프로토콜을 사용한 서명"을 사용한다. 이러한 변형은 다중 필드 익명 크리덴셜에 서명할 수 있는 서명 방식을 정의하고, 고객이 서명된 데이터에 대해 임의의 기능을 증명할 수 있도록 한다. 예를 들어, 서명된 크리덴셜을 보유한 고객은 단순히 크리덴셜의 필드를 공개할 수 있거나, 또는 크리덴셜의 필드를 생략할 수 있거나, 또는 일부 수학적 함수를 충족하는 서명된 크리덴셜의 입력 필드를 갖는 영지식 지식 증명을 게시할 수 있다. 이러한 수학적 함수는 입력 필드를 요약된 입력에 매핑하는 요약 함수일 수 있다. 이러한 프로세스의 본질은 "크리덴셜 표시"가 크리덴셜의 하나 이상의 필드의 요약을 공개하고, 표시를 수행하는 고객이 이러한 요약과 일치하는 크리덴셜을 가지고 있음을 증명할 수 있다는 것이다. 이러한 서명은 강력한(Strong) RSA 가정, 이중선형 맵 및 기타 암호화 기술을 기반으로 하는 서명을 통해 실현될 수 있다.
일부 예에 따르면, 분산형 설정은 다음과 같은 익명 크리덴셜을 사용한다. 신원 인증서를 획득하기 위해, CIM은 고객의 신원 정보에 대한 익명 크리덴셜을 획득한다. 이러한 서명된 정보는 다중 필드 익명 크리덴셜에 저장되어 암묵 서명 추출 프로토콜을 사용하여 CIM에게 전달되거나, 또는 단순히 IP가 크리덴셜에 서명하여 CIM에게 전달되도록 할 수 있다. SP가 CIM으로부터의 신원 어설션을 요구하는 경우, CIM의 ISE 시스템은 또한 CIM에도 저장된 정책을 평가하고 SP에게 공개되어야 하는 인증서 필드와 요약되어야 하는 인증서 필드를 정확하게 결정한다. 요약되어야 하는 필드의 경우, CIM은 이제 인증서 필드에 대한 수학적 요약 함수를 도출하고 요약된 값을 출력한다. 마지막으로, 공개된 요약이 서명된 인증서와 일치함을 증명하는 암호화 메시지인 크리덴셜 "표시"를 계산한다.
요약의 일 예는 각 거래서에 고유한 고객에 대한 가명을 개발하는 것이다. 신원 인증서에는 신원 제공자에게 구체적인 고객 식별자가 포함되어야 한다. 그러나, IP와 CIM은 이러한 고유한 신원 정보를 SP에게 공개하기를 원하지 않을 수 있으며, 대신에 각 SP에 대해 "의사 식별자(pseudo-identifier)"를 생성하기를 원할 수 있다. 이러한 경우를 처리하기 위해, CIM은 SP에게 구체적인 의사 ID를 획득하기 위해 고객 식별자를 SP 특정 식별자와 "얽히는" 요약 함수를 사용하도록 구성될 수 있다. 이러한 요약 함수는 예를 들어 키가 고객 식별자이고 함수에 대한 입력이 SP의 고유 식별자인 의사 랜덤 함수와 같은 함수일 수 있다.
보고
전술한 바와 같이, SP는 신원 제공자에 저장되고 및/또는 다른 서비스 제공자에게 배포되어야 하는 추가 정보를 생성하도록 구성될 수 있다. 이러한 정보에는 고객에 의해 생성된 사기 거래에 대한 정보 또는 고객 활동에 대한 새로운 정보가 포함될 수 있지만 이에 제한되지는 않는다. 이러한 정보는 시스템의 모든 참가자에게 전달되도록 의도될 수 있거나, 또는 특정 당사자에게만 제한될 수도 있다.
전술한 바와 같이, 중앙집중형 및 분산형 설정 모두에서, 정보는 신원 제공자에게 직접 전송함으로써 보고될 수 있다. 이는 보고 위치(예: URL)를 신원 인증서의 일부로서 SP에게 전달하여 수행될 수 있다. 이러한 URL은 접근을 허용하는 하나 이상의 API 키 또는 인증 토큰과 연관될 수 있다. 새로운 정보를 보고하기 위해, SP는 IP와 통신을 설정하고 예를 들어 HTTP(S) 연결을 통해 안전한 방식으로 정보를 전송한다. 그 다음, 이러한 정보는 신원 제공자에 의해 데이터베이스에 기록되고, 나중에 다른 고객 및 SP에게 전달하기 위해 처리될 수 있다.
일부 예에 따르면, 예를 들어 시스템이 분산형 설정에 따라 작동하는 경우, 이러한 정보는 방송 채널 또는 저장 시스템을 통해 다른 SP에게 전달될 수 있다. 그러한 채널 중 하나는 블록체인과 같은 합의 네트워크를 사용하는 것이다.
다수의 신원 제공자
일부 실시예에서, 단일 신원 제공자는 고객의 신원 정보를 운반하고 및/또는 보고된 정보를 저장하는 것에 대해 전적으로 책임을 지지 않을 수 있다. 예를 들어, 도 3에 개략적으로 도시된 바와 같이, 고객의 신원 정보는 집계된 신원 어설션을 제공하기 위해 협력하는 여러 협력 신원 제공자에 걸쳐 분할될 수 있다. ("협력"이라는 용어는 그러한 IP에 의해 수행되는 협력 역할을 설명하기 위해 본 개시외 첨부된 청구항에서 사용된다. 즉, 각각이 협력적인 어설션과 함께 필수적인 어설션의 일부를 제공함으로써, SP에 의해 요구되는 모든 정보를 포함할 수 있으며, 실제로 협력 IP는 반드시 서로 통신할 필요는 없다.) 이러한 메커니즘은 모든 제공자에 걸쳐 고유한 고객 식별자를 설정함으로써 실현될 수 있으며, 여기서 각 제공자는 신원 제공자가 보유한 관련 정보를 포함하는 컴포넌트 신원 어설션 또는 신원 인증서를 생성한다. 이들은 SP에서 완전한 어설션을 제공하거나 또는 CIM에서 신원 인증서로 사용하기 위한 완전한 정보 세트를 제공하기 위해, 예를 들어 고객 식별자에 따라 집계될 수 있다.
마찬가지로, SP에 의해 보고된 정보는 여러 개별 위치에 저장될 수 있다. 이러한 정보가 개별 보고 값을 함께 연결할 수 있는 일부 식별자로 식별되는 경우, 이러한 정보는 SP 및 기타 이해 당사자에 의해 획득될 수 있고, 필요한 보고 정보의 완전한 픽처를 획득하도록 결합될 수 있다.
더욱이, 부분적인 신원 어설션/인증서의 집계를 용이하게 하는 시스템의 능력은 서비스 제공자가 특정 IP에 어느 정도 의존하는지, 그리고 어떤 정보에 대해 의존하는지에 관해 선택적으로 허용한다. 예를 들어, SP는 고객의 연령에 따라 제1 IP에 의존할 수 있지만, 투자자 상태에 대한 검증이 필요하다(예를 들어, 정책에 따라 이러한 정보는 2개의 상이한 소스에 의해 어설팅되기 때문에, 정책이 예를 들어 위험 허용 수준을 기반으로 이러한 어설션을 수행하기 위해 자격이 없는 제1 IP를 정의하기 때문에 등). 따라서, SP는 제1 IP에 의해 어설팅되는 정보를 보강하기 위해 제2 IP로부터 정보를 요청할 수 있다. 이러한 정보는 예를 들어, 제1 IP가 필요한 어설션을 수행할 수 없기 때문에, SP가 제1 IP로부터 해당 정보를 요청하지 않기 때문에, 또는 기타 적절한 이유로, 제1 IP에 의해 어설팅되는 동일한 정보 및/또는 제1 IP에 의해 어설팅되지 않은 추가 정보를 포함할 수 있다. 따라서, 어설션의 집계를 허용하는 시스템의 능력으로 인해 SP가 고객의 신원을 검증할 때 향상된 상당의 주의(due diligence)를 용이하게 구현할 수 있다.
인증서의 철회 및 최신성
때때로, 발행된 신원 인증서 또는 신원 어설션이 유효하지 않게 되거나, 또는 신원 제공자가 이용할 수 있는 새로운 정보로 대체된 정보를 포함할 수 있다. 이러한 경우를 처리하기 위해, 각 신원 인증서와 신원 어설션에는 4개의 필드, 즉 어설션/인증서에 대한 신원, 어설션/인증서에 대한 만료 날짜, 어설션/인증서에 대한 업데이트된 정보를 획득하기 위해 사용하는 지침(URL과 같음), 및 각 인증서가 업데이트되어야 하는 빈도에 대한 권장 사항 중 어느 하나가 포함될 수 있다.
중앙집중형 설정에서, IP로부터 어설션을 수신하는 SP는 선택적으로 이러한 필드를 어설션의 일부로서 수신할 수 있다. SP는 이러한 정보를 사용하여 만료 날짜를 현재 시간과 비교하는 메커니즘을 통해 어설션이 만료 날짜에 도달했는지 여부를 결정할 수 있다. 마찬가지로, 분산형 설정에서, CIM은 신원 인증서가 만료되어 새로 고쳐야 하는지 여부를 결정하기 위해 만료 날짜를 현재 시간과 비교할 수 있다. 더욱이, 분산형 설정에서, CIM은 (1) 신원 인증서 만료 날짜, 또는 (2) 신원 인증서 만료 날짜의 요약을 SP에 의해 진짜로 검증될 수 있는 형태로 SP에게 전송할 수 있다. 그러한 요약의 예에는 신원 인증서가 대략 언제 만료되는지를 지시하는 요약, 또는 단순히 현재 시점에서 신원 인증서가 아직 만료되지 않았음을 지시하는 지시가 포함될 수 있지만 이에 제한되지는 않는다. 이는 이러한 정보가 숨겨져 있어야 하는 경우 이러한 정보가 SP가 CIM에 의한 다른 신원 어설션을 동일한 신원 인증서에 연결할 수 있도록 하는 정보를 SP에게 공개할 수 있기 때문에, SP에 대해 CIM에 의해 수행되는 어설션이 인증서의 정확한 만료 날짜를 유출하지 않도록 하기 위해 요구될 수 있다.
IP는 만료 날짜 이전에 신원 어설션 또는 신원 인증서의 정보를 철회 및/또는 업데이트하도록 구성될 수 있다. 이것은 예를 들어, 새로운 정보, 예를 들어 도난당한 신원 증명서나 사기 의도의 증거가 고객의 상태를 변경하는 IP에 도달하는 경우에 발생할 수 있다. 이러한 경우를 해결하기 위해, IP는 SP가 하나 이상의 고객 신원이 업데이트되어야 하는 것으로 결정할 수 있도록 하는 하나 이상의 SP에게 "철회" 메시지를 게시하도록 구성될 수 있다. 이러한 메시지에는 어설션 또는 신원 인증서 식별자가 포함될 수 있다.
SP에 의해 수신된 신원 어설션과 연관된 식별자는 고객에 대해 고유할 수 있지만, 모든 SP에 걸쳐 공유될 수 있거나, 또는 이전 섹션에서 논의된 바와 같이, 단일 고객을 식별하기 위해 각 SP/IP 조합에 사용되는 고유한 식별자일 수 있다.
웹 사이트를 보호하는 데 사용되는 것과 같은 표준 PKI 인증서를 철회하기 위한 다수의 프로토콜이 존재한다. 이들은 인증서 철회 리스트(certificate revocation list, CRL) 및 온라인 인증서 상태 프로토콜(online certificate status protocol, OCSP)을 포함하며, 이는 주어진 인증서가 철회된 것으로 시그널링하는 데 사용된다. 이러한 프로토콜은 위에서 설명된 신원 인증서 및 어설션을 약간 수정하여 적용될 수 있거나, 또는 유사한 목적을 가진 특정 프로토콜이 그들 대신에 사용될 수 있다. 인증서 해지 리스트를 사용하기 위해, 신원 제공자는 모든 철회된 신원 인증서 및/또는 어설션의 식별자를 포함하는 리스트를 게시할 것이다. OCSP 예에서, 각 서비스 제공자는 주기적으로 신원 제공자를 접촉하여 주어진 인증서/어설션 식별자가 철회되었는지 여부를 요청할 수 있다. 이러한 접근 방식의 마지막 변형은 CIM과 같은 클라이언트가 IP에 접속하여 신원 인증서가 여전히 유효하고 철회되지 않았음을 지시하는 디지털 서명 파일을 획득할 수 있는 "OCSP 스태이플링(stapling)" 프로세스와 관련된다. 이러한 파일에는 이러한 파일이 유효한 것으로 간주되어야 하는 시기(예를 들어, 요청된 날로부터 최대 3일)를 지시하는 "유효 기간"이 포함된다. 그런 다음, CIM은 파일을 SP에 대해 수행된 신원 어설션에 첨부하거나 "스테이플"할 수 있다. 다르게는, CIM은 신원 인증서에 대해 설명된 기술을 사용하여 이러한 파일의 내용을 요약할 수 있다. 이로 인해 SP가 IP와 직접 통신할 필요가 제거되고, 인증서가 여전히 유효한지를 확인함에 SP로부터의 일부 자원 비용이 제거된다.
전체 철회의 대안으로, IP는 신원 어설션 또는 신원 인증서의 내용을 간단히 업데이트하기를 원할 수 있다. 이에 대한 메커니즘은 인증서/어설션이 철회되지 않았음을 IP가 게시하는 메시지(예를 들어, CRL 또는 OCSP 메시지)의 일부로 지시해야 한다는 점을 제외하면 철회와 유사하다: 오히려 당사자는 IP로부터 업데이트된 인증서를 획득해야 한다. 중앙집중형 설정에서, SP는 이전 섹션에서 설명된 대로 IP에 접촉하여 새로운/업데이트된 어설션을 획득할 것이다. 분산형 설정에서, CIM은 업데이트된 신원 인증서를 획득하기 위해 IP에 접촉할 것이고, SP는 CIM으로부터 새로운 어설션을 획득해야 할 수도 있다.
본 발명이 속하는 기술분야의 당업자라면 현재 개시된 주제의 범위를 벗어나지 않고, 필요한 부분을 약간 수정하여 다양한 변경, 변형 및 수정이 이루어질 수 있음을 쉽게 이해할 수 있을 것이다.

Claims (27)

  1. 금융 서비스 제공자에게 신원 어설션(identity assertion)을 발행하여 상기 서비스 제공자에 대한 고객의 신원 검증을 용이하게 하도록 구성된 시스템으로서,
    고객 정보를 저장하고 고객의 신원을 검증하며, 상기 서비스 제공자로부터의 요청에 기초하여 상기 정보 중 적어도 일부를 어설팅하는 신원 어설션을 생성하도록 구성된 신원 제공자 ― 상기 어설션은 암호화된 부분을 포함함 ―; 및
    상기 고객과 연관되고 상기 서비스 제공자에게 상기 어설션의 제공을 용이하게 하기 위해 상기 서비스 제공자 및 상기 신원 제공자와 통신하도록 구성된 고객 신원 관리자
    를 포함하며,
    상기 시스템은 고객 기록의 어느 정보가 상기 서비스 제공자에게 어설션으로 그리고 어떤 형태로든 제공될 것인지를 선택적으로 결정하기 위해 상기 고객 기록 및 정책에 대해 추론하도록 구성된 신원 요약 엔진을 더 포함하는,
    시스템.
  2. 제1항에 있어서,
    상기 신원 요약 엔진은 상기 서비스 제공자로부터의 신원 요청에 대한 공통 포맷과 상기 서비스 제공자에게 발행된 어설션에 대한 공통 포맷을 정의하는 요청 언어를 정의하는,
    시스템.
  3. 제1항에 있어서,
    상기 신원 요약 엔진은 상기 고객 기록으로부터의 정보 중 적어도 일부가 일반화된 형태로 상기 어설션에 포함되는 것으로 결정하도록 구성되는,
    시스템.
  4. 제1항에 있어서,
    상기 신원 요약 엔진은 상기 고객 기록으로부터의 정보 중 적어도 일부가 상기 고객 기록으로부터의 다른 정보와 결합된 형태로 상기 어설션에 포함되는 것으로 결정하도록 구성되는,
    시스템.
  5. 제1항에 있어서,
    상기 신원 요약 엔진은 상기 서비스 제공자의 신원에 기초하여 상기 고객 기록으로부터의 정보 중 적어도 일부가 보류되는 것으로 결정하도록 구성되는,
    시스템.
  6. 제1항에 있어서,
    상기 신원 요약 엔진은 상기 신원 제공자에 의해 구현되는,
    시스템.
  7. 제1항에 있어서,
    상기 신원 제공자는 상기 서비스 제공자에게 직접 상기 어설션을 발행하도록 구성되는,
    시스템.
  8. 제7항에 있어서,
    상기 고객 신원 관리자는 신원 어설션을 제공하기 위해 상기 서비스 제공자로부터 요청을 수신하고, 적절한 신원 어설션이 획득될 수 있는 하나 이상의 신원 제공자를 식별하는 정보를 상기 서비스 제공자에게 제공하도록 구성되는,
    시스템.
  9. 제8항에 있어서,
    상기 하나 이상의 신원 제공자를 식별하는 정보는 상기 하나 이상의 신원 제공자를 식별하는 영지식 증명(zero-knowledge proof)을 포함하는,
    시스템.
  10. 제1항에 있어서,
    상기 고객 신원 관리자는 상기 신원 제공자에 의해 발행된 어설션을 상기 서비스 제공자에게 제공하도록 구성되는,
    시스템.
  11. 제10항에 있어서,
    상기 고객 신원 관리자는 상기 고객이 이용할 수 있는 추가 정보를 상기 서비스 제공자에게 제공하도록 추가로 구성되는,
    시스템.
  12. 제11항에 있어서,
    상기 고객 신원 관리자는 영지식 증명을 사용하여 요약된 추가 정보를 제공하도록 구성되는,
    시스템.
  13. 제1항에 있어서,
    상기 신원 요약 엔진은 상기 고객 신원 관리자에 의해 구현되는,
    시스템.
  14. 제1항에 있어서,
    복수의 협력 신원 제공자를 포함하며, 상기 복수의 협력 신원 제공자는 각각 상기 서비스 제공자에 의해 요구되는 정보의 적어도 일부에 대한 컴포넌트 어설션을 발행함으로써, 상기 컴포넌트 어설션의 집계된 어설션의 제공을 용이하게 하는,
    시스템.
  15. 제14항에 있어서,
    상기 컴포넌트 어설션 중 적어도 일부는 상기 컴포넌트 어설션 중 다른 일부에서 어설팅되지 않은 정보의 어설션을 포함하는,
    시스템.
  16. 제14항에 있어서,
    상기 컴포넌트 어설션 중 적어도 일부는 상기 컴포넌트 어설션 중 다른 일부에서 어설팅된 정보의 어설션을 포함하는,
    시스템.
  17. 제1항에 있어서,
    상기 신원 제공자는 상기 사용자에 대해 상기 서비스 제공자로부터의 정보를 수신하고, 이를 고려하여 상기 어설션을 업데이트하도록 구성되는,
    시스템.
  18. 제17항에 있어서,
    상기 업데이트하는 것은 상기 어설션의 정보 중 적어도 일부를 철회하는 것을 포함하는,
    시스템.
  19. 제17항에 있어서,
    상기 신원 제공자는 업데이트된 어설션이 이용 가능하다는 메시지를 상기 서비스 제공자에게 게시하도록 구성되는,
    시스템.
  20. 제1항에 있어서,
    상기 어설션은 상기 서비스 제공자가 상기 고객에 대한 정보를 외부 시스템으로 보고하는 것을 용이하게 하도록 구성된 보고 정보를 포함하는,
    시스템.
  21. 제20항에 있어서,
    상기 보고 정보는 하나 이상의 인증 토큰 및/또는 상기 정보를 보고하기 위한 하나 이상의 위치를 식별하는 정보를 포함하는,
    시스템.
  22. 제1항에 있어서,
    상기 어설션은 만료 날짜를 포함하는,
    시스템.
  23. 제1항에 있어서,
    상기 고객 정보는 비(non) 신원 데이터를 포함하는,
    시스템.
  24. 제1항에 있어서,
    상기 고객 신원 관리자는 상기 고객과 연관된 디지털 지갑과 통합되는,
    시스템.
  25. 제1항에 있어서,
    상기 어설션의 암호화된 부분은 영지식 증명을 구현하는,
    시스템.
  26. 제1항에 있어서,
    상기 어설션은 암호화되지 않은 부분을 포함하는,
    시스템.
  27. 제26항에 있어서,
    상기 암호화된 부분은 상기 암호화되지 않은 부분 중 적어도 일부에 대해 계산된 암호화 인증 데이터를 포함하는,
    시스템.
KR1020237032717A 2021-02-23 2022-02-23 신원 전달 시스템 KR20230153412A (ko)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US202163152655P 2021-02-23 2021-02-23
US63/152,655 2021-02-23
PCT/US2022/017445 WO2022182706A1 (en) 2021-02-23 2022-02-23 Identity conveyance systems

Publications (1)

Publication Number Publication Date
KR20230153412A true KR20230153412A (ko) 2023-11-06

Family

ID=83049651

Family Applications (1)

Application Number Title Priority Date Filing Date
KR1020237032717A KR20230153412A (ko) 2021-02-23 2022-02-23 신원 전달 시스템

Country Status (5)

Country Link
EP (1) EP4298581A1 (ko)
JP (1) JP2024507376A (ko)
KR (1) KR20230153412A (ko)
CA (1) CA3211491A1 (ko)
WO (1) WO2022182706A1 (ko)

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7133846B1 (en) * 1995-02-13 2006-11-07 Intertrust Technologies Corp. Digital certificate support system, methods and techniques for secure electronic commerce transaction and rights management
US8479272B2 (en) * 2007-06-04 2013-07-02 Avaya Inc. Identity assertion
US9672336B1 (en) * 2014-08-29 2017-06-06 ProfileCorrect LLC Security system for verification of user credentials
US10764752B1 (en) * 2018-08-21 2020-09-01 HYPR Corp. Secure mobile initiated authentication
US20210358054A1 (en) * 2020-05-15 2021-11-18 Adp, Llc Online information validation

Also Published As

Publication number Publication date
CA3211491A1 (en) 2022-09-01
JP2024507376A (ja) 2024-02-19
WO2022182706A1 (en) 2022-09-01
EP4298581A1 (en) 2024-01-03

Similar Documents

Publication Publication Date Title
US11438173B2 (en) Methods and apparatus for providing blockchain participant identity binding
US11025435B2 (en) System and method for blockchain-based cross-entity authentication
US11533164B2 (en) System and method for blockchain-based cross-entity authentication
US11082221B2 (en) Methods and systems for creating and recovering accounts using dynamic passwords
Lesavre et al. A taxonomic approach to understanding emerging blockchain identity management systems
US10116445B2 (en) Method and system for protected exchange of data
AU2017225928A1 (en) Systems and methods for distributed data sharing with asynchronous third-party attestation
US20050114666A1 (en) Blocked tree authorization and status systems
US20050044369A1 (en) Electronic document management system
US10341353B1 (en) System and method for issuing, authenticating, storing, retrieving, and verifying documents
WO2018088475A1 (ja) 電子認証方法及びプログラム
Dumas et al. LocalPKI: An interoperable and IoT friendly PKI
US20210250359A1 (en) System and method for authenticating, storing, retrieving, and verifying documents
KR20230153412A (ko) 신원 전달 시스템
US20240135380A1 (en) Identity conveyance systems
Hardjono et al. 13. Exchange Networks for Virtual Assets
US20230298015A1 (en) Systems and methods for verification of protected private information
Jevans et al. Travel Rule Information Sharing Architecture for Virtual Asset Service Providers (TRISA) Version 7 June 23, 2020
Gerdes Jr et al. Multi-dimensional credentialing using veiled certificates: Protecting privacy in the face of regulatory reporting requirements
Naessens et al. Extending the Scope of eID Technology: Threats and Opportunities in a Commercial Setting
RUSSO ANONYMITY, PRIVACY, AND ACCOUNTABILITY: CHALLENGES AND NEW SOLUTIONS IN VARIOUS APPLICATION CONTEXTS
Cordova Morales et al. Enhancing the Acme Protocol to Automate the Management of All X. 509 Web Certificates (Extended Version)
Hardjono et al. and Alex Pentland