ToIP (The Trust Over IP)에 대하여
오늘은 최근 DID 분야에서 Interoperability와 관련된 이슈로 Linux Foundation에서 설립한 Trust Over IP Foundation에 대하여 알아보겠습니다.
개요
Hyperledger Aries 개념의 RFC는 비즈니스, 법률 및 사회 계층의 인간 신뢰를 통합하는 인터넷 수준에서의 디지털 신뢰를 위한 완벽한 아키텍처를 도입합니다.
Authors: Matthew Davie, Dan Gisolfi, Daniel Hardman, John Jordan, Darrell O’Donnell, Drummond Reed
Status: PROPOSED (이후 수정될 수 있음)
Start Date: 2019–01–01 / Since: 2019–11–04
Status Note: Initial Proposal
조직
Figure1. Governance and Working GroupsGovernance Stack Working Group의 범위는 Hyperledger Aries RFC 0289에 정의된 바와 같이 IP를 통한 트러스트 아키텍처 스택을 구현하는 주체간 비즈니스, 법적 및 사회적 신뢰를 가능하게 하는 거버넌스 프레임 워크에 대한 모델 및 상호 운용성 표준을 정의합니다. (ToIP 거버넌스에 대한 모델, 템플릿, 지침 및 모범 적용 사례.)
Technical Stack Working Group의 범위는 Hyperledger Aries RFC 0289에 정의 된대로 Trust over IP 아키텍처 스택에 대한 기술 표준, 테스트 및 상호 운용성 인증 표준을 정의합니다.(ToIP 기술에 대한 사양 및 상호 운용성 테스트 요구 사항)
Utility Foundry Working Group의 범위는 Layer 1 유틸리티에 대한 거버넌스 조직, 구현/운영자 및 서비스 제공 업체 간 커뮤니티를 구성하는 것입니다. Linux Foundation 또는 외부에서 호스팅하든지 새로운 Layer 1 유틸리티 프로젝트를 설정하고 모니터링하기위한 프로세스 지침을 제공합니다. 기타 활동으로는 서비스 제공업체를 위한 템플릿 RFP 작성, 관련 영역 및 서비스 제공업체 목록 유지, 관련 및/또는 상이한 유틸리티 간의 협업 및 조정 영역 확인, 그리고 가능한 경우 ToIP Layer 1 유틸리티의 역할에 대한 교육/홍보 역할을 수행합니다. (LF 프로젝트 또는 외부 거버넌스 조직으로 ToIP Layer 1 공용 유틸리티를 구현하는 거버넌스 조직을 위한 실무 커뮤니티)
Ecosystem Foundry 의 범위는 Trust over IP Layer 4 생태계의 거버넌스 조직, 구현/운영자 및 서비스 제공 업체 간 커뮤니티를 구성하는 것입니다. Linux Foundation 또는 외부에서 호스팅하든지 새로운 Layer 4 생태계 프로젝트를 설정하고 모니터링하기 위한 프로세스 지침을 제공합니다. 기타 활동에는 서비스 제공 업체를 위한 템플릿 RFP 생성, 제휴 파운드리 서비스 제공 업체 목록 유지, 관련 영역 및 서로 다른 생태계간의 협력 및 조정 영역 확인, 그리고 가능한 경우 Layer 4 생태계 역할에 대한 교육/홍보 역할을 수행합니다. (Layer 4 디지털 신뢰 생태계 구현에 대한 지침과 지원을 요청하는 거버넌스 조직을 위한 실무 커뮤니티)
미션
Trust over IP Foundation의 슬로건은 다음과 같습니다.
비즈니스/법적/사회적 계증에서의 인간의 신뢰를 결함한 암호화 신뢰를 결합한 인터넷 수준에서의 디지털 신뢰를 위해 완벽한 아키텍처를 정의하라.
이 미션은 ToIP 스택에 포함된 모든 표준 또는 구성 요소를 개발하는 것이 아니라 관리 및 기술 모두에 대해 스택의 4 개 계층 모든 요구 사항을 충족하기 위해 이러한 요소를 결합하는 방법을 지정하는 것입니다. 즉, ToIP Foundation은 다른 표준 개발 조직(SDO), 산업 기반 및 기타 컨소시엄과 긴밀히 협력하여 개방형 표준, 아키텍처 및 프로토콜을 인터넷 규모의 디지털 신뢰 인프라를위한 완벽하고 일관된 스택으로 결합합니다.
Figure2. The relation between ToIP Foundation and other standardization organizations상기에 언급된 조직은 해당 작업이 ToIP 스택의 일부에 의해 참조되거나 기여되는 조직입니다. 우리는 ToIP 스택에 대한 작업이 WG을 통해 발전함에 따라 이러한 조직은 더욱 커질 것으로 기대합니다.
참고로 ToIP Layer에 대해서 아래의 Figure 3: The ToIP stack을 참고하시기 바랍니다.
배경
정보 네트워크 아키텍처의 광범위한 채택을 위한 상호 운용성의 중요성은 인터넷의 지배력이 급격히 증가함에 따라 입증되었습니다 [1]. 인터넷의 지배력을 높이는 주요 원인은 UNIX의 BSD (Berkeley Software Distrbution) 버전 4.2에서 TCP / IP 스택의 오픈 소스 구현이었습니다 [2]. 이 광범위하게 채택된 TCP / IP 스택의 오픈 소스 구현은 두 피어 장치가 로컬 네트워크에 관계없이 연결을 형성하고 데이터 패킷을 교환 할 수있는 기능을 제공했습니다. 또한 SSL (Secure Sockets Layer) 및 최신 버전 인 TLS (Transport Layer Security)와 같은 보안 프로토콜 제품군은 1995 년부터 인터넷 트랜잭션을 보호해 왔습니다.
의심의 여지없이 TCP / IP 스택의 구현과 SSL / TLS의 구현은 지난 30 년 동안 엄청난 혁신을 이끌었습니다. 그러나 TLS와 같은 프로토콜은 세계적 수준의 보안을 제공하지만 프로토콜이 구축된 아키텍처는 널리 알려졌으며 이는 모든 피어가 이러한 디지털 연결을 신뢰하는 수단이 되었습니다. 예를 들어, TLS는 사용자가 자신이 올바른 웹 사이트에 접속하고 있다는 것을 신뢰하도록 허용하지만, 최소한 사용 가능한 방식으로 사용자가 웹 사이트에 로그인하거나 자신의 신원을 증명할 수있는 방법을 제공하지는 않습니다. 두 개의 격차를 종종 “인터넷의 신원 검증 레이어”라고 합니다 [3].
Hyperledger Aries Concept RFC의 목적은 개발자가 디지털 통신 네트워크를 통해 신뢰할 수있는 관계를 구축하기 위해 구현할 수 있는 표준 정보 네트워크 아키텍처를 정의하여 이 차이를 해결하는 것입니다.
ToIP Stack의 아키텍처 레이어
“ID Layer”의 궁극적인 목적은 실제로 엔티티를 식별하는 것이 아니라 상호 작용해야 하는 신뢰를 촉진하는 것이므로 공동 저자인 John Jordan은 이에 대하여 Trust over IP (ToIP)라는 용어를 사용했습니다. Figure 3은 4 개의 계층을 나타낸 다이어그램입니다.
Figure 3: The ToIP stack실제로는 “이중 스택”입니다. 기술과 거버넌스를 모두 포함하는 두 개의 병렬 스택입니다. 이는 기술만으로는 디지털 트러스트를 달성할 수 없고 사람과 기술이 함께 노력하여 디지털 신뢰를 달성할 수 있다는 사실을 반영합니다.
중요한 점: ToIP 스택은 특정 거버넌스 프레임 워크를 정의하지 않습니다. 오히려 온라인 신뢰를 용이하게 하기 위해 보편적으로 참조, 이해 및 소비될 수 있는 디지털 거버넌스 프레임 워크를 설계하고 구현하는 방법에 대한 메타 모델입니다. 거버넌스를 정의하는 이러한 접근 방식을 통해 인간 (및 Layer 2에서 우리를 대표하는 소프트웨어 에이전트)은 신뢰 범위 내에서 그 경계를 쉽게 결정할 수 있습니다.
ToIP 거버넌스 스택은 ToIP 아키텍처에서 특별한 역할을 합니다. 각 계층의 별 거버넌스 프레임 워크에 대한 설명과 Scaling Digital Trust의 특별 섹션을 참조하십시오.
Layer 1: 분산 식별자를 위한 퍼블릭 유틸리티(DID 메소드 작동 시스템)
ToIP 스택은 블록체인 및 분산 원장을 포함한 암호화 및 분산 시스템의 새로운 발전으로 가능하게 되었습니다. 이러한 기술들의 높은 활용성 및 암호화 검증은 강력하게 분산된 신뢰를 가능하게 하므로, 단일 장애 지점으로 사용되지 않습니다.
분산 식별자
이러한 분산 시스템을 ToIP 스택의 기본 계층으로 채택하려면 분산 식별자 (DID)라는 새로운 유형의 글로벌 고유 식별자가 필요했습니다. 2017 년 6 월 미국 국토 안보 과학 기술 부서의 연구 보조금을 지원받아 DID 사양 [4] 및 DID 입문서 [5]가 W3C Credentials Community Group에 기여했습니다. 2019 년 9 월W3C는 DID를 완전한 W3C 표준으로 전환하게 하는 DID Working Group을 발족하였습니다 [6].
DID는 다음의 4 가지 핵심 속성을 제공하도록 설계된 RFC 3986 호환 URI 체계로 정의합니다.
영구적. DID는 효과적으로 URI (Uniform Resource Name) [7]의 역할을한다. 한번 엔티티에 할당되면 (DID 주체라고 함), DID는 다른 엔티티에 재 할당되지 않아야 하는 해당 엔티티의 영구 식별자이다.
분석 가능. DID는 DID 주제와 신뢰할 수있는 상호 작용에 관여하는 데 필요한 공개 키 및 서비스 엔드 포인트를 설명하는 데이터 구조 (JSON 또는 다른 구문으로 인코딩된)로 DID 문서를 분석합니다.
암호화 검증. DID 주체가 DID의 암호화 제어를 증명할 수있는 DID 문서의 암호화 자료.
분산. DID는 암호화 방식으로 생성 및 확인되므로 오늘날 전화 번호, IP 주소 또는 도메인 이름에 필요한 것과 같은 중앙 집중식 등록 기관이 필요하지 않습니다.
Figure 3은 DID 구문과 URN 구문 (RFC 8141)의 유사성을 보여줍니다.
Figure 3: How DID syntax resembles URN syntaxDID 메소드
URN 사양과 마찬가지로 DID 사양은 다른 특정 URI 체계를 정의하는 데 사용되는 일반 URI 체계도 정의합니다. DID에서는 이를 DID 메소드라고 합니다. 각 DID 메소드는 아래의 내용을 포함해야 하는 자체 DID 메소드 스펙에 의해 정의됩니다.
DID 메소드가 작동하는 시스템 (기술적으로 검증 가능한 데이터 레지스트리)
ToIP 스택에서는 이를 유틸리티라고합니다. 유틸리티는 블록체인 또는 분산 원장으로 제한되지 않습니다. DID 메소드는 모든 유형의 분산 데이터베이스, 파일 시스템 또는 암호화 신뢰 루트를 고정할 수있는 기타 시스템에서 작동하도록 설계 될 수 있습니다.
DID 메소드명
DID 메소드별 문자열의 구문
사양을 준수하는 DID 및 DID 문서에 대한 CRUD (생성, 읽기, 업데이트, 삭제) 작업.
DID는 이미 분산 PKI (공개 키 인프라)에서 대중적인 솔루션인 것으로 입증되었습니다 [8]. W3C Credentials Community Group이 주최하는 비공식 DID 메소드 레지스트리에 이미 40 개가 넘는 DID 베소드가 등록되어 있습니다. 여기에는 다음과 같은 메소드가 포함됩니다.
Permissionless blockchains such as Bitcoin (three methods), Ethereum (six methods), Veres One, IOTA, RChain, Ontology, etc.
Permissioned ledgers such as the Sovrin ledger
Distributed file systems such as IPFS.
Ledgerless P2P networks such as git, JLINC, and peer DIDs.
유틸리티 거버넌스 프레임워크
Layer 1 퍼블릭 유틸리티는 비즈니스 모델, 법률 모델 및 기술 아키텍처의 제약 조건에 적합한 거버넌스 모델을 선택할 수 있습니다. 퍼블릭 유틸리티가 블록체인, 분산 원장 또는 분산 파일 저장소로 운영되는지, 또는 권한이 있는지, 권한이 없는지 또는 하이브리드인지에 관계없이 마찬가지입니다. (비허가형 블록체인 네트워크조차도 코드를 업데이트 할 수있는 규칙은 퍼블릭또는 프라이빗이 있습니다.)
모든 ToIP 아키텍처는 거버넌스 모델이 상호 운용성 및 신뢰를 모두 지원하기 위해 ToIP 거버넌스 스택의 요구 사항을 준수해야 합니다. 여기에는 거버넌스 권한, 거버넌스 프레임 워크 및 참가자 노드 또는 운영자에 대한 투명한 식별이 포함됩니다. 노드 또는 서비스 엔드 포인트의 투명한 관찰; 투명한 보안, 개인 정보 보호, 데이터 보호 및 기타 운영 정책이 포함됩니다. 아래의 거버넌스 부분을 참조하세요.
ToIP 거버넌스 스택 유틸리티 거버넌스 프레임 워크 모델은 다음을 포함하여 Hyperledger Indy 기반 유틸리티와 같은 퍼블릭 허가형 유틸리티의 표준을 지원합니다:
Transaction Authors: 트랜잭션 게시자
Transaction Endorsers: 트랜잭션 작성자를 위한 권한 트랜잭션
Stewards: 원장의 노드를 운영
Layer 1는 상위 Layer를 지원한다
DID와 DID Document는 단지 상위 Layer를 지원하기 위한 암호화된 데이터 구조가 아니다. 다른 것들도 포함한다:
스키마는 검증 가능한 자격 증명 (Layer 3)에 포함될 수 있는 클레임 (속성)을 정의합니다.
자격 증명 정의는 검증 가능한 자격 증명 발급자 (계층 3)에 필요한 클레임 및 관련 메타 데이터를 정의합니다.
해지 레지스트리는 자격 증명 발급자가 자격 증명을 취소하면서 자격 증명 보유자의 개인 정보를 보호할 수있는 암호화 누산기입니다 (Layer 3).
에이전트 인증 정책도 자격 증명 보유자가 자신을 대신하여 운영하는 에이전트를 Layer 2에서 활성화 및 비활성화 할 수있는 암호화 누산기입니다. (자세한 내용은 DKMS 디자인 및 아키텍처의 5.1 단원을 참조하십시오.)
요약하면, Layer 1의 상호 운용성은 위에 나열된 다른 암호화 데이터 구조에 대한 W3C DID 사양 및 Aries RFC에 의해 정의됩니다. 이러한 모든 데이터 구조를 지원하는 모든 DID 레지스트리는 Layer 2에서 작동하는 모든 에이전트, 월렛 및 허브에서 작동할 수 있습니다.
Layer 2: DIDComm 프로토콜
IP를 통한 트러스트 스택의 두 번째 계층은 DIDComm 보안 메시징 표준 [10]에 의해 정의됩니다. Decentralized Identity Foundation의 DIDComm Working Group에서 현재 정의되고 있는 이 사양은 두 소프트웨어 에이전트 (피어)가 직접 에지 또는 중간 클라우드 에이전트를 통해 안전하게 통신할 수있는 암호화 수단을 설정합니다. (Figure 4 참조)
Figure 4: At Layer Two, agents communicate peer-to-peer using DIDComm standards피어 DIDs and DID-to-DID 연결
DIDComm의 기본 기능은 기본적으로 모든 DID-to-DID 연결이 Peer DID 매소드 사양 [11]에 정의된대로 익명의 Peer DID를 사용하여 설정되고 보호된다는 것입니다. 이러한 DID는 각 에이전트가 유지 관리하는 로컬 암호화 키 관리 시스템 (KMS, 일명 “월렛”)에 의해 생성 및 저장되는 키 페어를 기반으로합니다. 그런 다음 에이전트는 DID 교환 프로토콜을 사용하여 Peer DID와 DID Document를 교환하여 신뢰할 수있는 관계가 지속되는 동안 필요에 따라 키 교체 또는 해지를 포함하여 서로 간의 개인 연결을 설정하고 유지합니다.
Peer DID 및 DID-DID 연결의 모든 구성 요소가 Layer 2에서 작성, 저장 및 관리되므로 Layer 1 퍼블릭 유틸리티에 등록할 필요가 없습니다. 실제로 개인 정보 보호 및 보안상의 이슈가 없어야 합니다. 이러한 구성 요소는 피어의 개인 정보를 완전히 유지할 수 있습니다. 일반적으로 Layer 1에서 Public DID가 필요한 유일한 ToIP 참여자는 아래 Layer 3에 설명된 자격 증명 발급자입니다.
즉, DID-DID 연결이 구성되면 피어 간의 모든 유형의 보안 통신에 사용될 수 있습니다. 또한 이러한 연결은 문자 그대로 영원히 지속될 수 있습니다. 관련된 어떠한 종류의 중개 서비스 제공자도 없습니다. DID-to-DID 연결을 종료해야하는 유일한 이유는 피어 중 하나 또는 둘 다 더 이상 원하지 않기 때문입니다.
에이전트와 월렛
Layer 2에서 모든 상담원은 디지털 지갑과 짝을 이루거나보다 정확하게 KMS (키 관리 시스템)와 쌍을 이룹니다. 이런 KMS는 임베디드 장치의 매우 간단한 정적 파일부터 매우 정교한 엔터프라이즈 급 키 서버에 이르기까지 다양합니다. 복잡함에 관계없이 KMS의 역할은 중요한 데이터 (키 페어, 영지식 증명 비밀, 검증 가능한 자격 증명 및 기술 신뢰를 설정하고 유지하는 데 필요한 기타 암호화 자료)를 보호하는 것입니다.
이 작업에는 장치를 분실 또는 도난 당했거나 KMS가 해킹 또는 손상된 후 복구하기 어려운 문제가 포함됩니다. 이것은 분산 키 관리의 영역입니다. 자세한 내용은 DKMS (Decentralized Key Management System) 설계 및 아키텍처 문서 [12] 및 KERI (Key Event Receipt Infrastructure)에 대한 Sam Smith 박사의 논문 [13]을 참조하십시오.
암호화된 데이터 저장
에이전트는 암호화된 데이터 저장소 — 3 가지 특별한 속성이 있는 데이터베이스와 쌍을 이룰 수 있습니다.
DID 컨트롤러 (개인, 조직 또는 사물)에 의해 독점적으로 제어되며 중개자 또는 제 3자가 아닙니다.
모든 데이터는 KMS에서 개인 키로 암호화됩니다.
DID 컨트롤러에 둘 이상의 암호화 된 데이터 저장소가 있는 경우 소유자의 환경 설정에 따라 저장소 세트가 자동으로 동기화 될 수 있습니다.
암호화된 데이터 저장소를 표준화하는 작업은 Hyperledger Aries와 더불어 여러 프로젝트에서 진행되고 있으며 주로 주로 DIF (Decentralized Identity Foundation) 및 W3C Credentials Community Group에서 진행됩니다. 현재 DIF에서 SDS (Secure Data Store) Working Group을 구성하기위한 작업이 진행 중입니다.
디지털 후견인 및 후견인의 에이전트와 월렛
인터넷 액세스, 스마트폰 또는 ToIP 지원 디지털 에이전트, 지갑 및 암호화된 데이터 저장소을 사용할 수있는 물리적, 정신적 또는 경제적 능력이 없는 세계 인구의 3 분의 1을 무시하면 ToIP 스택은 디지털 신뢰의 범용 계층이 될 수 없습니다. 이는 ToIP 계층이 디지털 후견인의 개념을 강력하게 지원할 필요성을 강조합니다 .호스트 클라우드 에이전트 / 지갑 서비스와 개인을 대신하여 해당 클라우드 에이전트 / 지갑을 관리할 의지가 있는 개인 또는 조직의 결합 하여 디지털 후견인이라 칭합니다.
디지털 후견인의 모든 측면에 대한 자세한 내용은 자기주권신원에서의 Sovrin Foundation 백서에서 디지털 후견인에 관한 정보 [14]를 참조하십시오.
거버넌스 프레임워크 제공자
Layer 2의 관리 항목은 다음과 같이 보안, 개인 정보 보호, 데이터 보호 및 상호 운용 가능한 테스트 및 인증 요구 사항입니다.
하드웨어 개발자: ToIP 호환 하드웨어 (예 : 보안 구역, 신뢰 가능한 실행 환경, HSM)를 제공합니다.
소프트웨어 개발자: ToIP 호환 에이전트, 지갑, 암호화된 데이터 저장소 등을 제공합니다.
에이전시: 개인, 조직 및 보호자를위한 ToIP 호환 클라우드 에이전트 호스팅
Layer 2는 상위 Layer를 지원한다
The purpose of Layer Two is to enable peers to form secure DID-to-DID connections so they can:계층 2의 목적은 피어가 다음을 수행 할 수 있도록 보안 DID-DID 연결을 형성 할 수 있도록하는 것입니다.
Layer 3의 데이터 교환 프로토콜을 사용하여 이러한 연결을 통해 자격 증명을 발급, 교환 및 확인합니다.
발급자가 사용하는 공용 유틸리티에 관계없이 이러한 자격 증명을 발급하고 확인하는 데 필요한 Layer 1암호화 데이터 구조에 접근하십시오.
에이전트, 월렛 및 암호화 된 데이터 저장소간에 ToIP 데이터를 제한없이 마이그레이션하고 이식하십시오. 이 데이터 이식성은 ToIP의 광범위한 채택 및 상호 운용성에 매우 중요합니다.
Layer Three: 데이터 교환 프로토콜
Layer 1과 Layer 2를 함께 사용하면 피어간에 암호화 트러스트 (기술적 트러스트라고도 함)를 설정할 수 있습니다. 대조적으로, Layer 3과 Layer 4의 목적은 실제 개인과 조직 사이의 동료 간의 신뢰와 상호 작용하는 것 (장치, 센서, 기기, 차량, 건물, 도시 등) 간의 인간 신뢰를 구축하는 것입니다.
Layer 2에서 DIDComm 프로토콜의 강력한 기능 중 하나는 이제 수많은 데이터 교환 프로토콜을 “말할 수있는” 안전한 개인 에이전트 대 에이전트 연결을위한 토대를 마련한다는 것입니다. ToIP 스택의 관점에서 가장 중요한 것은 검증 가능한 자격 증명의 교환을 지원하는 프로토콜입니다.
검증 가능 자격증명 데이터 모델
Manu Sporny, David Longley 및 W3C Credentials Community Group의 다른 구성원이 이끄는 수년간의 작업 후, 2017 년에 W3C VCWG (Verifiable Claims Claims Working Group)가 구성되어 2019 년 9 월에 검증 가능한 자격 증명 데이터 모델 1.0이 생성되었습니다. [15].
Figure 5는 검증 가능한 자격 증명 교환에서 종종 “신뢰 삼각형”이라고 하는 세 가지 핵심 역할을 나타낸 다이어그램입니다. 자세한 내용은 검증 가능한 자격 증명 입문서 [16]를 참조하십시오.
Figure 5: The three primary roles in the W3C Verifiable Credentials Data Model검증 가능한 자격 증명 표준의 핵심 목표는 우리가 물리적 지갑에 저장하는 물리적 자격 증명과 동등한 디지털 자격 증명을 최종적으로 보유하여 매일 신원 및 권한 증명을 제공할 수 있도록하는 것입니다. 검증된 자격 증명을 제시하는 것이 증명이라고 부르는 이유입니다. 이것은 암호화 증명이며 검증자가 신뢰 결정을 내리는 데 필요한 일련의 속성 또는 관계에 대한 증거입니다.
자격 증명 검증 유형
The Verifiable Credentials Data Model 1.0 supports several different cryptographic proof types:검증 가능한 자격 증명 데이터 모델 1.0은 다음과 같은 여러 가지 암호화 증명 유형을 지원합니다.
JSON 웹 토큰(JWT)은 JSON 웹 서명을 사용하여 보호됩니다.
JSON-LD를 사용하여 연결된 데이터 서명
Camenisch-Lysyanskaya 서명을 사용한 영지식증명
세 가지 모든 증명 유형은 모두 시장의 특정 요구를 해결합니다.
JWT는 JOSE 스택 및 연합형 ID 인프라에서 널리 사용됩니다.
링크된 데이터 서명은 광역 데이터 통합 및 기타 시맨틱 웹 애플리케이션에서 사용됩니다.
ZKP 기반 자격 증명을 사용하면 자격 증명 보유자가 의도하지 않은 상관 관계없이 검증 자에게 클레임을 선택적으로 공개 할 수 있습니다.-EU 일반 데이터 보호 규정 (GDPR), 캘리포니아 소비자 개인 정보 보호법 (CCPA) 및 유사한 데이터 보호 규정 등을 간단하게 준수하는 디자인 아키텍처의 개인 정보 보호 기능이 크게 향상되었습니다.
ToIP 스택에서이 세 가지 신임 증명 유형을 모두 지원한다는 것은 다음을 의미합니다.
Layer 1은 각 증명 유형을 발급하고 확인하는 데 필요한 데이터 구조를 지원해야 합니다.
Layer 2 에이전트, 지갑 및 암호화 된 데이터 저장소는 각 증명 유형에 필요한 암호화 자료의 저장 및 내보내기를 지원해야 합니다.
Layer 3은 각 증명 유형에 대한 자격 증명 교환 프로토콜을 지원해야 합니다.
자격 증명 교환 프로토콜
Layer 3에서는 검증 가능한 자격 증명 교환이 DIDComm 프로토콜을 통해 계층화 된 데이터 교환 프로토콜을 사용하여 에이전트에 의해 수행됩니다. 이러한 데이터 교환 프로토콜 사양은 DIDComm 제품군의 일부로 게시되고 있습니다 [10]. 자격 증명 교환 프로토콜은 요청 및 응답 형식이 다르기 때문에 각 자격 증명 증명 유형마다 고유합니다. ToIP 스택의 목표는 모든 ToIP 호환 에이전트, 월렛 및 암호화 된 데이터 저장소가 다른 에이전트, 월렛 및 암호화 된 데이터 저장소와 작동할 수 있도록 지원되는 모든 자격 증명 교환 프로토콜을 표준화하는 것입니다.
완벽하게 상호 운용 가능한 확인 가능한 자격 증명을 사용하면 모든 발급자는 모든 클레임 집합을 모든 보유자에게 발급한 다음 이를 검증자에게 증명할 수 있습니다. 이것은 오늘날 우리의 실제 지갑에서 가지고있는 실제 자격 증명과 동일한 신뢰 삼각형을 사용하는 완전히 분산된 시스템입니다. 이 단순하고 보편적 인 신뢰 모델은 모든 신뢰 커뮤니티의 모든 요구 사항에 맞출 수 있습니다. 또한 대부분의 경우 새로운 트러스트 관계나 정책이 필요하지 않고 기존 물리적 자격 증명을보다 유연하고 유용한 디지털 형식으로 변환하기만하면됩니다.
자격 증명 거버너스 프레임워크
Layer 3은 ToIP 스택이 기술적인 신뢰에서 인간의 신뢰로 넘어가는 곳이기 때문에이 구조는 거버넌스 프레임 워크가 디지털 신뢰 생태계의 상호 운용성과 확장 성을 위한 중요한 구성 요소가되는 계층입니다. 자격 증명 관리 프레임 워크는 자격 증명의 권한을 가진 발급자가 될 수있는 목록 또는 정책과 함께 하나 이상의 자격 증명 정의를 지정합니다. 또한 발급자가 해당 자격 증명을 발급 및 취소하기 위해 따라야 하는 정책을 지정하고 비즈니스 모델, 책임 프레임 워크 및 보험 모델을 포함할 수도 있습니다.
ToIP 거버넌스 스택 모델에 정의 될 자격 증명 거버넌스 프레임 워크의 표준은 다음과 같습니다.
권한있는 발급자: 특정 수준에서 특정 유형의 자격 증명을 발급할 수 있도록 관리 기관에서 권한을 부여한 발급자
신임 정보 레지스트리: 대체 권한있는 신임 정보 보유자 (일반적으로 공용 검색 가능 디렉토리 지원)
보험사: 거버넌스 프레임 워크의 조건에 따라 운영하는 발행자에게 보험을 제공합니다
Layer 3은 상위 Layer를 지원한다
Layer 3은 엔티티, 속성 및 관계에 대한 검증 가능한 주장의 형태로 인간의 신뢰를 Layer 1과 2에서 제공하는 암호화 신뢰에 계층화 할 수있게합니다. Layer 4는 고유한 디지털 신뢰 생태계의 특정 신뢰 모델 및 정책을 지원하기 위해 이러한 검증 가능한 신임 정보를 요청하고 사용하는 애플리케이션 생태계입니다.
Layer Four: Application Ecosystems 응용 생태계
Layer 4는 특정 비즈니스, 법률 또는 사회적 목적을 수행하는 신뢰할 수있는 상호 작용에 참여하기 위해 인간이 응용 프로그램과 상호 작용하는 계층입니다. 응용 프로그램이 인터넷을 통해 통신하기 위해 TCP / IP 스택을 호출하는 것처럼 응용 프로그램은 ToIP 스택을 호출하여 DID를 등록하고, 연결을 형성하고, 확인 가능한 자격 증명을 가져오고 교환하며, Layer 1, 2 및 3의 프로토콜을 사용하여 신뢰할 수있는 데이터 교환을 수행합니다.
ToIP 스택은 TCP / IP 스택보다 인터넷에 구축 될 수있는 애플리케이션을 제한하는 것 이상으로 구축할 수있는 애플리케이션을 제한하지 않습니다. ToIP 스택은 단순히 애플리케이션이 구성원이 기대하는 보안, 개인 정보 보호 및 데이터 보호를 제공하는 디지털 신뢰 에코 시스템 내에서 상호 운용 될 수 있도록 “도구 및 규칙”기술 및 거버넌스 defines를 정의합니다. ToIP 스택은 또한 자동차 운전 제어 (스티어링 휠, 가스 페달, 브레이크, 회전 신호)에 대한 일관된 사용자 경험과 마찬가지로, 온라인에서 광범위한 신뢰를 얻는 데 중요한 애플리케이션 및 생태계 전반에 걸쳐 일관된 신뢰 결정의 사용자 경험을 가능하게합니다. 전 세계 운전자 안전에 중요합니다.
생태계 거버넌스 프레임워크
Layer 4는 인간이 ToIP 거버넌스 스택을 직접 경험할 수있는 곳으로, 구체적으로 생태계 거버넌스 프레임 워크의 신뢰 마크와 정책 준수입니다. 여기에는 ToIP 스택의 4 가지 레벨 모두에서 해당 생태계 내에서 운영되는 모든 거버넌스 기구 및 거버넌스 프레임 워크에 적용되는 목적, 원칙 및 정책이 지정됩니다.
ToIP 거버넌스 스택은 다음을 포함하여 생태계 거버넌스 프레임 워크 (EGF)에 대한 표준 역할을 지정합니다.
회원 디렉토리: EGF 참가자의 공개 DID 및 기타 검색 가능한 속성을 나열합니다.
감사인: EGF 정책 준수를 위한 감사 참여자
공인감사인: EGF의 공인 감사인
생태계 거버넌스 프레임 워크의 범위와 권한을 완전히 이해하기 위해 ToIP 거버넌스 스택의 특별한 역할에 대해 자세히 살펴 보겠습니다.
Scaling Digital Trust
Figure 6의 위쪽 절반은 확인 가능한 자격 증명에 사용되는 기본 트러스트 삼각형 아키텍처를 보여줍니다. 아래쪽 절반에는 검증 가능한 자격 증명 및 ToIP 스택의 실제 채택 및 확장성과 관련된 여러 가지 문제를 해결할 수있는 두 번째 신뢰 삼각형 (거버넌스 삼각형)이 표시됩니다.
Figure 6: The special role of governance frameworks거버넌스 기구
Figure 6의 거버넌스 신뢰 삼각형은 여권, 운전 면허증, 신용 카드, 건강 보험 카드 등과 같이 우리가 매일 사용하는 가장 성공적인 물리적 자격 증명에 대해 존재하는 동일한 거버넌스 모델을 나타냅니다.
이러한 자격 증명은 많은 경우에 수십 년 동안 발전해 온 규칙과 정책에 의해 뒷받침됩니다. 이러한 규칙과 정책은 여러 유형의 기존 거버넌스 기구의 민간 기업, 산업 컨소시엄, 금융 네트워크 및 물론 정부에 의해 개발, 게시 및 시행되었습니다.
동일한 거버넌스 기구 또는 ToIP 거버넌스 공개 디지털 거버넌스 프레임 워크를 위해 명시적으로 구성된 새로운 모델을 갖춤으로써 동일한 모델을 검증 가능한 자격 증명에 적용할 수 있습니다. 제공하는 자격 증명을 표준화, 강화 및 확장하려는 모든 발행자 그룹은 후원 기관의 후원하에 함께 관리 프레임 워크를 만들 수 있습니다. 조직, 정부, 컨소시엄, 협회, 협동 조합의 형태와 상관없이 목적은 동일합니다. 회원들이 신뢰를 얻기 위해 운영하기로 합의하는 비즈니스, 법률 및 기술 규칙을 정의하십시오.
물론 이것은 세계 최대의 트러스트 네트워크 중 하나인 Mastercard와 Visa가 어떻게 확장 되었는가 입니다. 모든 은행이나 가맹점은 다른 은행이나 가맹점이 네트워크의 구성원임을 확인하고 규칙에 준수할 수 있습니다.
ToIP 스택을 사용하면이 거버넌스 아키텍처를 모든 규모의 관할 지역의 모든 트러스트 커뮤니티에 대한 모든 역할 또는 자격 증명에 적용할 수 있습니다.
역사적으로 ToIP 거버넌스 스택의 일부 측면은 Sovrin Governance Framework(SGF) [17]에서 2017 년부터 Sovrin Public Ledger for self-sovereign identity의 거버넌스 기구인 Sovrin Foundation에 의해 개발되었습니다.
거버넌스 프레임워크 정의
모든 메타 모델 외에도 ToIP 거버넌스 스택은 모든 수준의 개별 거버넌스 프레임 워크에 대한 아키텍처 모델을 제공합니다. 이를 통해 거버넌스 프레임 워크의 구성 요소를 표준 모듈형으로 표현할 수 있으므로 다른 거버넌스 프레임 워크에서 내부 및 외부 적으로 쉽게 색인을 작성하고 참조할 수 있습니다.
Figure 7은이 기본 아키텍처 모델을 보여줍니다.
Figure 7: Anatomy of a governance framework권한있는 발급자의 관찰과 검증
검증자는 종종 권한있는 발급자가 자격 증명을 발급했는지 확인해야 합니다. ToIP 스택은 거버넌스 기구에 권한있는 발급자 집합을 지정하기위한 여러 가지 메커니즘을 제공합니다 (이러한 옵션은 비독점적입니다-각각 독립적으로 또는 조합하여 사용할 수 있음).
DID 문서. 관리 권한 기관은 선택한 하나 이상의 공용 유틸리티에 대한 DID 문서에 DID 목록을 게시할 수 있습니다.
회원 디렉토리. 거버넌스 기구는 거버넌스 기구의 자체 DID 문서에 게시 된 표준 서비스 엔드 포인트에서 제공되는 화이트 리스팅 서비스를 통해 DID의 “화이트리스트”를 게시할 수 있습니다.
자격 증명 레지스트리. 권한있는 발급자의 검색 및 검색이 필요한 경우, 관리 기관은 자격 증명 레지스트리에 각 권한있는 발급자의 DID 및 추가 속성이 모두 포함된 확인 가능한 자격 증명을 게시할 수 있습니다. 이 경우 자격 증명 레지스트리는 자격 증명의 대상이 아니지만 자격 증명의 유효성을 독립적으로 증명할 수있는 자격 증명을 보유한 자격 증명을 보유한 별도의 암호로 자격 증명 보유자 역할을 합니다.
검증 가능한 자격 증명. Figure 6에서 볼 수 있듯이 거버넌스 기구(또는 지정된 감사 인)은 권한있는 발급자에게 검증 가능한 자격 증명을 발급 할 수 있으며, 자격 증명 발급자에게 직/간접적으로 검증자에게 자격 증명을 제출할 수 있습니다.
권한있는 검증자의 관찰과 검증
DID 보유자는 종종 권한있는 검증자에 의해 요구받은 자격증명을 검증할 필요로 합니다. 예를 들면 ‘기계 판독 거버넌스 프레임워크’의 한 부분 같은 것이다. ToIP 스택은 거버넌스 기관에 권위있는 검증자를 지정하기 위한 여러 가지 메커니즘을 제공합니다. (이 옵션은 비독점적입니다 — 독립적으로 또는 조합하여 사용할 수 있습니다):
DID 문서. 거버넌스 기관은 선택한 하나 이상의 검증 가능한 데이터 레지스트리의 DID 문서에 해당 DID 목록을 게시할 수 있습니다.
회원 디렉토리. 거버넌스 기관은 거버넌스 기관 자체의 DID 문서에 게시된 표준 서비스 엔드 포인트에서 제공되는 화이트 리스팅 서비스를 통해 DID의 “화이트리스트”를 게시 할 수 있습니다.
자격 증명 레지스트리. 신뢰할 수있는 검증자의 관찰 및 검증이 필요한 경우, 거버넌스 기관은 자격 증명 레지스트리의 각 권한 부여 검증 자에 대한 DID 및 추가 속성을 모두 포함하는 검증 가능한 자격 증명을 공개 할 수 있습니다. 이 경우 자격 증명 레지스트리는 별도의 역할을 하는데 이는 자격 증명의 암호로 검증 가능한 보유자-자격 증명의 대상이 아니지만 자격 증명의 유효성을 독립적으로 증명할 수있는 보유자가 됩니다.
검증 가능한 자격 증명. Figure 6와 마찬가지로 거버넌스 기관 (또는 지정된 감사인)은 거버넌스 프레임 워크에서 권한있는 발급자에게 검증 가능한 자격 증명을 발급할 수 있습니다. 해당 발행자는 차례로 보유자 또는 검증 자에게 직접적으로 중명을 제출할 수 있습니다.
강압 대책
“자기 주권”신원의 개념은 당사자들이 거래에 자유롭게 참여하고, 개인 및 기밀 정보를 공유하며, 상대방의 요청이 부당하거나 불법이라고 간주 될 때 참여하지 않게되는 것을 가정합니다. 그러나 실제로 이것은 때로는 그렇지 않습니다 : “800 파운드 고릴라(거대한 힘을 가진 기업)에게 무엇을 주나요?”, 대답 : “무엇이든 요구하는 것”. 800 파운드 고릴라의 예로는 법 집행을 대표한다고 주장하는 일부 대기업 웹 사이트, 이민국 및 제복을 입은 사람들이 있습니다 [20]. 또한 웹 트랜잭션의 전형적인 클라이언트-서버 특성은 이러한 강력한 불균형을 강화하며, 클라이언트 에이전트 뒤에 있는 사람은 개인 데이터를 포기할 때 제품, 서비스 또는 위치에 대한 액세스가 거부되는 것처럼 강요된 느낌을받습니다. 핵심은 “모든 쿠키를 허용하거나 출구없이 미로에 들어가기”중에서 웹 사이트 방문자가 선택할 수 있는 악명 높은 쿠키 월 사례와 같습니다.
거버넌스 프레임 워크는 서로 다른 유형의 강제에 대한 하나 이상의 잠재적 대책을 구현하도록 인증할 수 있습니다. 기계 판독 가능 거버넌스 프레임 워크의 경우, 이러한 대책 중 일부는 자동으로 시행되어 사용자가 자신의 이익에 반하여 행동하지 않도록 보호할 수 있습니다. 다른 거버넌스 프레임 워크는 적용되는 법률뿐만 아니라 현재의 이익에 따라 완전한 자기 주권과 긴밀한 통제 사이에 다른 균형을 선택할 수 있습니다.
다음은 강제에 대한 잠재적 대책의 예입니다. 거버넌스 프레임 워크는 보유자 에이전트가 일부 요구 사항이 충족되었다고 판단할 때 일부 확인 가능한 자격 증명이 제시되도록 자극하거나 시행할 수 있습니다. 요구 사항이 충족되지 않으면 사용자에게 위반에 대한 경고가 표시되고 보유자 에이전트는 요청된 확인 가능한 자격 증명의 제시를 거부할 수 있습니다.
권위있는 검증자를 요구하라. 검증자는 해당 거버넌스 프레임 워크 내에서 인증을 받아야합니다.“권한있는 검증 자의 관찰 및 검증”섹션도 참조하십시오.
증거 수집이 필요합니다. 요청의 전자 서명이 거부할 수없는 방식으로 검증 자와 연결되는 경우, 검증 가능한 자격 증명 제시 요청은 법원에서 증거로 확보될 수 있습니다.
익명의 불만을 제기해야 합니다. 보유자가 수집된 증거에서 고유하게 식별될 수있는 경우 위의 증거 수집이 손 될 수 있습니다. 따라서 거버넌스 프레임 워크는 증거 자체에 대한 실체 식별 정보뿐만 아니라 보유자 정보를 가리도록 할 수 있습니다.
원격 / 대리 검증을 요구합니다. 검증자는 검증자가 긍정적인 결정을 내릴 경우 보유자에게만 가치가 있습니다. 따라서 보유자는 긍정적인 결정이 필요한 경우에만 개인 데이터를 포기해야 합니다. 요청된 결정이 물리적 시설에 대한 액세스라면 이동을 줄일 수 있습니다. 어떠한 경우에도 개인 데이터의 불필요한 공개를 막을 수 있습니다. 일부 검증자는 결정 기준을 기밀로 간주할 수 있습니다. 따라서, 상이한 거버넌스 프레임 워크는 보유자 프라이버시와 검증 자 기밀성간에 다른 균형을 선택할 수 있습니다.
적합한 보유자 에이전트가 필요합니다. 일부 불량 보유자 에이전트는 해당 데이터와 관련된 거버넌스 프레임 워크의 정책에 따라 개인 데이터를 양도 할 수 있습니다. 그러한 데이터의 발행자는 발행하기 전에 보유자 대리인의 준수 확인을 요구할 수 있습니다.
인증이 필요합니다. 보유자는 일부 관할 지역 뿐만 아니라 불량 검증자에 의해 생체 인증을 포기해야 할 수도 있습니다. 이것은 많은 은행 앱이 생체인식적으로나 장치 기반의 이미 저장된 사용자의 인증을 요구하는 이유입니다.일부 거대한 힘을 가진 기업은 어깨 너머로 보고 있기 때문에 전자 프리젠테이션이 없이 사용자가 앱에서 자신의 개인 데이터를 볼 때에도 필요할 수 있습니다.
다른 거버넌스 프레임워크간 상호 운용성
ToIP 거버넌스 스택은 Digital Identity and Authentication Council과의 공공 / 민간 부문 협력을 통해 개발되고있는 Pan-Canadian Trust Framework (PCTF)와 같은 국제 거버넌스 프레임 워크를 위한 구현 수단 및 구현 수단과 호환되도록 설계되었습니다. 또한 모든 종류의 지역 및 지방 거버넌스 프레임 워크와 상호 운영되어야 합니다. 예를 들어 BC 주는 OrgBook BC라는 ToIP 호환 검증 자격 증명 레지스트리 서비스를 구현했습니다. OrgBook은 BC주의 합법적으로 등록 된 법인을위한 보유자 / 제공자 서비스이며 Indy Catalyst 및 Hyperledger Aries Cloud Agent-Python을 사용하여 구축되었습니다. 캐나다 연방 정부뿐만 아니라 온타리오 주와 앨버타 주와 같은 다른 주에서는 비즈니스 자격 증명을위한 이러한 서비스를 실험하기 시작하여 신뢰가 우위에있는 새로운 종류의 네트워크를 구축했습니다. 자세한 내용은 VON (Verifiable Organization Network) [19]을 참조하십시오.
상호 운용이 가능한 디지털 신뢰 생태계의 세계를 구축하기
인터넷은 네트워크 네트워크이며 각 네트워크 간의 상호 연결은 TCP / IP 스택을 통해 촉진됩니다. ToIP 가능 인터넷은 디지털 신뢰 에코 시스템의 디지털 신뢰 에코 시스템으로, 각 디지털 신뢰 에코 시스템 사이의 상호 연결은 ToIP 스택을 통해 촉진됩니다. 각 디지털 신뢰 생태계의 경계는 구성원이 운영하는 거버넌스 프레임 워크에 따라 결정됩니다.
이를 통해 ToIP 지원 인터넷은 오늘날의 다양성과 풍요 로움을 반영 할 수 있지만, 모든 종류의 개인, 비즈니스, 사회, 학계, 정치 등의 신뢰 관계를 형성하고 유지할 수있는 새로운 기능을 제공합니다. 이러한 트러스트 관계는 오늘날 IP 패킷이 네트워크 경계를 넘을 수있는 것처럼 쉽게 트러스트 경계를 넘을 수 있습니다.
결론: 인터넷을 위한 신뢰 계층
ToIP 스택의 목적은 인터넷에 대해 강력하고 분산된 개인 정보 보호 신뢰 계층을 정의하는 것입니다. 암호화, 분산 시스템, 클라우드 컴퓨팅, 모바일 컴퓨팅 및 디지털 거버넌스의 블록 체인 기술 및 기타 새로운 개발을 활용하여 디지털 신뢰 구축 및 유지 관리에있어 오랜 문제를 해결합니다.
이 RFC는 Hyperledger Aries와 Linux Foundation의 다른 프로젝트를 통해 추가로 개발 될 때 ToIP 스택의 발전을 추적하도록 업데이트됩니다. 의견과 기여를 환영합니다.
출처
Petros Kavassalis, Richard Jay Solomon, Pierre-Jean Benghozi, The Internet: a Paradigmatic Rupture in Cumulative Telecom Evolution, Industrial and Corporate Change , 1996; accessed September 5 2019.
FreeBSD, What, a real UNIX®?, accessed September 5, 2019.
Kim Cameron, The Laws of Identity, May 2005; accessed November 2, 2019.
Drummond Reed, Manu Sporny, Markus Sabadello, David Longley, Christopher Allen, Ryan Grant, Decentralized Identifiers (DIDs) v1.0, December 2019; accessed January 24, 2020.
W3C Credentials Community Group, DID Primer, January 2019; accessed July 6, 2019.
W3C DID Working Group, Home Page, September 2019; accessed November 2, 2019.
Uniform Resource Names (URNs), RFC 8141, April 2017; accessed November 2, 2019.
Greg Slepak, Christopher Allen, et al, Decentralized Public Key Infrastructure, December 2015, accessed January 24, 2020.
W3C Credentials Community Group, DID Method Registry, June 2019; accessed July 6, 2019.
Daniel Hardman, DID Communication, January 2019; accessed July 6, 2019.
Daniel Hardman et al, Peer DID Method 1.0 Specification, July 2019; accessed July 6, 2019.
Drummond Reed, Jason Law, Daniel Hardman, Mike Lodder, DKMS Design and Architecture V4
, March 2019; accessed November 2, 2019.
Samuel M. Smith, Key Event Receipt Infrastructure (KERI), July 2019, accessed February 4, 2020.
Sovrin Governance Framework Working Group, On Guardianship in Self-Sovereign Identity, December 2019, accessed April 10, 2020.
Manu Sporny, Grant Noble, Dave Longley, Daniel C. Burnett, Brent Zundel, Verifiable Credentials Data Model 1.0, September 2019; accessed November 2, 2019.
Manu Sporny, Verifiable Credentials Primer, February 2019; accessed July 6, 2019.
Sovrin Foundation, Sovrin Governance Framework V2, March 2019; accessed December 21, 2019.
DIACC, Pan-Canadian Trust Framework, May 2019; accessed July 6, 2019.
Governments of British Columbia, Ontario, and Canada, Verifiable Organizations Network (VON)
,June 2019; accessed July 6, 2019.
Oskar van Deventer et al, TNO, Netherlands, Self-Sovereign Identity — The Good, The Bad And The Ugly,May 2019.
구현
다음은 이 RFC의 구현 (있는 경우)을 항목입니다. 이 구현을 추가하려면 풀 리퀘스트를을 수행하십시오. 구현이 오픈 소스 인 경우 저장소 또는 저장소내의 구현에 대한 링크를 포함하십시오. RFC의 기계적 처리가 Aries 구현에서 지원하는 모든 RFC 목록을 생성 할 수 있도록 “이름” 필드에서 일관성을 유지하십시오.
구현 노트에는 테스트 결과에 대한 링크가 포함될 수 있습니다.
