SSI & Decentralized Identity Manangement
Digital identity
디지털 정체성 필요성: 오프라인 및 온라인 서비스를 이용하기 위해 디지털 정체성이 필요하다.
정체성 유형
가명 정체성 (Pseudonymous Identity):
이메일과 같은 단순한 형태의 정체성.
예: 소셜 미디어 계정은 보통 이메일 주소만 요구.
실명 정체성 (Natural Identity):
규제 준수를 위해 본인의 신원이 확인되어야 하는 경우.
예: 은행 업무는 자연적 정체성 검증 필요.
다중 정체성
사람들은 여러 개의 정체성을 가지고 있다.
예: 업무용 정체성과 개인용 정체성을 구분하여 사용.
정체성은 특정 식별자에 대한 주장(claims)의 모음으로 볼 수 있다. ???: 접니다
Identity Paradigms
정체성 패러다임:정체성 패러다임은 정체성이 관리되고 사용되는 방식을 규정한다.
아래 내용은 디지털 환경에서 정체성 관리와 사용 방식을 이해하기 위한 기초를 제공한다.
중앙 집중화: 특정 매개가 서비스를 빌미로 인증을 요구함
섞여있는: 다양한 소셜 로그인에 있는 ID 칸
탈 중앙화: 모두가 각자의 인증 데이터를 갖고 나타낼 수 있음: 보안에 집중적으로 되어 있음
오늘날의 디지털 인증 문제점:
1. 사용자 데이터가 중앙화되어있음: 기업이 모든 사람들의 데이터를 가지고 있다. 나쁜놈들
2. vendor lock-in: id같은 거 만들어서 사용자의 결정과 주권을 제한함.
3. 빅테크 기업= 문지기: 검열과 계정 정지를 시킬 수 있음. 진짜 나쁘네
탈중앙화 IDM(identity management)가 필요한 시대
예시) Diplomas: 스마트폰 앱에서 지갑(wallet)을 만들 수 있음. 3자에게 신분증 보여줄 수 있다.
SSI
SSI(Self-Sovereign Identity)의 동기
기존 신원 제공자의 문제점
오늘날의 신원 제공자들은 우리에 대한 막대한 권력과 메타데이터를 보유하고 있음.
오프라인 신원 인증 방식의 특징
사용자 주도: 신분증을 언제, 누구에게 제시할지 결정.
보편적 신뢰: 신분증이 모두에게 인정됨.
강제성 없음: 신분증 제시는 물리적으로 누구도 막을 수 없음.
추적 불가: 물리적 신분증 제시는 제3자가 추적할 수 없음.
디지털 신원의 개선 방향
온라인 신원은 종이 기반 신원보다 더 나은 시스템이 되어야 함.
디지털화는 단순히 과정을 빠르게 하는 것에 그치지 않고, 기존 프로세스의 중요한 속성을 보존해야 함.
SSI란
Self-Sovereign Identity(SSI)는 사용자가 자신의 디지털 신원을 완전하게 제어할 수 있도록 설계된 시스템이다.
사용자는 스스로 계정을 생성할 수 있다.
계정은 오직 사용자에 의해 통제되며, 삭제되거나 탈취될 수 없다.
이 계정은 모든 온라인 서비스에서 인정된다.
기존 모델(Current Model) vs. SSI 모델
기존 모델(Current Model):
신원 제공자(Issuer)와 검증자(Verifier) 사이에서 사용자는 제한적인 통제권만 가진다.
사용자의 신원 증명은 제3자(Issuer와 Verifier)에 의존한다.
SSI 모델:
사용자가 중심적인 제어권(Focus of Control)을 가진다.
Issuer는 신원 증명을 발행(issue)하며, Registry를 통해 신원이 관리되고 Verifier가 이를 검증(prove)한다.
블록체인 기술의 역할
블록체인은 SSI를 관리하고 발행하기 위한 신뢰 기반 인프라로 적합하다.
분산화된 시스템으로 데이터를 안전하게 저장.
투명성과 검증 가능성을 보장.
SSI의 간단한 정의
SSI는 디지털 신원으로 실체(Entity)를 표현하며, 각 실체가 자신의 신원 데이터에 대한 전적인 통제권(Sole Ownership)을 가지는 모델이다.
디지털 신원(Digital Identities)을 통해 실체(Entity)를 나타낸다.
사용자는 자신의 신원 데이터를 스스로 관리하며, 제3자의 개입 없이 이를 통제할 수 있다.
익명성과 속성:
신원은 가명 식별자(Pseudonymous Identifier)와 확인 가능한 속성(Attributes)의 조합으로 구성될 수 있다.
이러한 속성은 특정 증명자(Witness)에 의해 확인된다.
프라이버시 중심 설계:
SSI는 프라이버시를 우선시하는 디자인 철학에 기반한다.
실체(Entity)는 누구에게 어떤 속성을 공개할지 스스로 결정할 수 있다.
SSI 원칙
- 포괄성 (Inclusion)
누구나 디지털 아이덴티티를 가질 수 있어야 하며, 어떤 제약도 없어야 한다. - 통제권 (Control)
사용자는 자신의 아이덴티티와 데이터에 대한 완전한 통제권을 가져야 한다. - 접근성 (Access)
사용자는 자신의 데이터를 언제든지 접근하고 사용할 수 있어야 한다. - 투명성 (Transparency)
시스템 및 관리 구조는 사용자에게 투명하게 공개되어야 한다. - 지속성 (Persistence)
아이덴티티는 긴 수명을 가져야 하며, 사용자 통제하에 계속 유지될 수 있어야 한다. - 이식성 (Portability)
아이덴티티 정보는 사용자가 원하는 플랫폼이나 서비스로 이동 가능해야 한다. - 상호운용성 (Interoperability)
아이덴티티는 다양한 시스템에서 광범위하게 사용될 수 있도록 설계되어야 한다. - 동의 (Consent)
사용자는 자신의 아이덴티티와 데이터를 사용할 때 반드시 동의를 제공해야 한다. - 최소화 (Minimization)
사용자의 아이덴티티 정보는 필요 최소한만 공개되어야 한다. - 보호 (Protection)
사용자의 프라이버시는 반드시 보호되어야 하며, 악의적이거나 비승인된 접근으로부터 안전해야 한다.
DID (Decentralized Identifiers: 탈중앙화 식별자)
1. DID란 무엇인가?
DID의 정의:
DID는 중앙 기관의 통제를 받지 않고 개인, 조직, 디바이스가 스스로 발급하고 제어할 수 있는 식별자입니다.
블록체인과 같은 분산 시스템 상에서 생성되어 신뢰성과 보안성을 제공합니다.
중앙화된 ID(이메일, 소셜 미디어 계정)와 달리, 사용자가 DID를 완전히 통제할 수 있습니다.
2. DID의 주요 특징
탈중앙화:
DID는 특정 중앙 기관의 승인 없이 생성 가능.
데이터 소유권과 통제권이 사용자에게 있음.
유연성:
DID 문서를 통해 키를 갱신하거나 메타 데이터를 업데이트할 수 있음.
DID 문서에는 사용 조건, 키 정보, 추가 메타 정보 등이 포함됩니다.
프라이버시 보호:
사용자는 필요한 정보만 선택적으로 제공 가능(Selective Disclosure).
블록체인 상에 저장되는 정보는 최소화.
3. DID 구조
DID는 문자열로 표현되며, 다음과 같은 구조를 가집니다:
ruby
코드 복사
did:<method>:<method-specific-identifier>
Scheme:
항상 "did"로 시작.
이는 DID를 사용하는 것을 명시.
Method:
특정 DID 방식을 정의.
예:
ethr: 이더리움 블록체인 기반 DID 방식.
web: 기존 웹 도메인을 사용하는 방식.
Method-Specific Identifier:
각 방식에 따라 고유한 식별자를 제공.
예: 이더리움 계정 주소, 도메인 주소 등.
예시:
이더리움 기반 DID:
makefile
코드 복사
did:ethr:0xb9c5714089478a327f09197987f16f9e5d936e8a
이더리움 계정 주소를 식별자로 사용.
웹 기반 DID:
makefile
코드 복사
did:web:gcu.ac.kr
도메인(gcu.ac.kr)을 통해 DID 문서를 검색 가능.
4. DID의 핵심 구성 요소
DID Resolver (DID 해석기):
DID를 DID 문서로 변환하는 소프트웨어.
DID 방법(Method)에 따라 정의된 알고리즘을 사용하여 데이터를 조회.
예: 블록체인 데이터 사용.
DID Document (DID 문서):
DID와 관련된 정보를 포함하는 문서.
주요 내용:
공개 키: DID의 인증 및 서명을 위한 정보.
사용 조건: DID 사용 목적 및 범위.
서비스 정보: DID가 제공하는 기능 및 메타 데이터.
5. DID의 장점
중앙화 계정 대비 장점:
독립성: 사용자 본인이 DID를 소유하고 관리.
보안성: 분산 시스템(예: 블록체인) 상에서 운영되어 신뢰도와 내구성 강화.
프라이버시 강화: 제3자 추적 불가능한 신원 제공.
기존 블록체인 계정과 비교한 장점:
DID는 블록체인 계정보다 더 많은 유연성을 제공.
키 교체 가능, DID 문서에 추가 메타 정보 저장.
6. DID 사용 예시
졸업장 인증:
대학에서 발급한 DID 기반 졸업장을 모바일 지갑에 저장.
고용주가 DID 문서를 통해 졸업장 검증.
웹 기반 DID:
조직(예: 학교, 기업)이 자신의 도메인을 사용해 신원을 증명.
이더리움 기반 DID:
블록체인 네트워크를 통해 신원 관리.
7. DID의 한계와 문제점
방식의 다양성:
약 170개 이상의 DID 방식이 존재하며, 기술적 선택이 어렵고 표준화 부족.
기술적 과제:
DID 문서의 데이터 업데이트 및 관리 복잡성.
해석기(DID Resolver)의 구현 및 상호운용성 문제.
VC (Verifiable Credentials: 검증 가능한 자격증명)
1. VC란 무엇인가?
정의:
Verifiable Credential(VC)은 디지털 형식으로 표현된 자격 증명(예: 졸업장, 신분증)으로, 제3자가 이를 검증할 수 있습니다.
블록체인 및 암호학 기술을 활용하여 신뢰성을 보장하며, 중간 기관 없이 발급자와 검증자 간에 안전하게 사용됩니다.
2. VC의 주요 구성 요소
VC는 세 가지 주요 요소로 구성됩니다:
Credential Metadata (메타데이터):
발급자, 발급 일자, 만료 일자(선택 사항) 등 증명서에 대한 정보를 포함합니다.
VC의 형식 및 목적에 대한 정보도 메타데이터에 포함됩니다.
Credential Claims (주장):
증명 주체(예: 사용자의 신원)에 대한 정보.
예: 이름, 생년월일, 학위명 등.
Credential Proof (증명):
디지털 서명 형태로 발급자가 제공하며, 이를 통해 VC의 진위 여부를 검증합니다.
검증자는 이 서명을 확인하여 VC가 발급자로부터 온 것인지 확인.
3. VC의 주요 특성
검증 가능성:
제3자는 VC의 디지털 서명을 통해 증명서가 신뢰할 수 있는 발급자에 의해 발급되었는지 확인.
신뢰할 수 있는 데이터 레지스트리를 통해 발급자의 신뢰성을 검증.
선택적 공개 (Selective Disclosure):
VC는 필요한 정보만 선택적으로 제공할 수 있습니다.
예: 졸업장 정보에서 이름과 학위명만 공개하고 나머지 정보는 숨김.
상호운용성:
블록체인이나 DID와 함께 사용되며, 다양한 시스템에서 통합 및 상호작용 가능.
4. VC의 동작 방식
발급 (Issuance):
**발급자(Issuer)**가 증명서를 생성하고, 디지털 서명을 통해 발급.
예: 대학이 학생에게 졸업장을 발급.
저장 (Storage):
**소유자(Holder)**는 모바일 지갑 같은 개인 디지털 공간에 VC를 저장.
지갑은 사용자의 VC를 안전하게 관리.
검증 (Verification):
**검증자(Verifier)**가 VC를 확인.
검증자는 발급자의 디지털 서명과 블록체인 데이터를 사용해 VC가 유효한지 검증.
5. VC의 활용 예시
졸업장:
대학이 학생에게 디지털 졸업장을 발급.
학생은 모바일 지갑을 통해 고용주에게 졸업장을 제출.
고용주는 디지털 서명을 확인하여 졸업장의 유효성을 검증.
신분증:
정부가 디지털 ID를 발급.
사용자가 온라인에서 신분 증명이 필요할 때 필요한 정보만 선택적으로 제공.
출입증:
회사가 직원에게 디지털 출입증 발급.
출입 관리 시스템에서 이를 스캔하고 인증.
6. VC와 블록체인의 관계
블록체인의 역할:
VC가 발급되고 검증되는 과정에서 중앙화된 서버 대신 블록체인 사용.
블록체인은 다음과 같은 기능을 수행:
시간 기록: VC 발급/검증 시점의 타임스탬프 제공.
투명성: 발급자 및 검증 과정의 신뢰성을 보장.
데이터 무결성: VC의 상태 변경(예: 폐지)이 블록체인에 기록.
블록체인에 저장되는 데이터:
개인 정보를 저장하지 않음.
VC의 해시 값, 상태 정보(활성화/폐지 여부)만 기록.
7. VC의 장점
보안성:
디지털 서명을 통해 위조 불가능.
블록체인 기반으로 신뢰성과 무결성 보장.
사용자 제어:
사용자가 자신의 VC를 직접 관리.
중앙화된 데이터베이스 의존 없음.
프라이버시 보호:
필요한 정보만 선택적으로 제공 가능.
불필요한 데이터 노출 방지.
8. VC의 한계와 도전 과제
표준 부족:
다양한 VC 관련 기능들이 아직 표준화되지 않음.
예: 상태 목록(Status List)의 표준화 문제.
지갑 소프트웨어 초기 단계:
사용자 경험(UX) 개선 필요.
지갑 분실 시 대체 방안 미흡.
프라이버시와 사용성 간 균형:
클라우드 기반 지갑 사용 시 프라이버시와 사용성이 충돌.
프라이빗 키 관리 문제:
키 분실 시 복구가 불가능한 경우가 많음.
SSI 비판(Challenges and Criticism)
Self-Sovereign Identity(SSI)에 대한 비판과 도전 과제는 기술적, 운영적, 환경적 관점에서 다양합니다. 아래는 SSI 비판 부분에 대한 세부 설명입니다.
1. W3C DID 1.0 표준에 대한 주요 반대
2021년 9월, 구글, 애플, 모질라가 W3C의 DID 1.0 표준 승인에 공식적으로 반대 의견을 제출했습니다.
주요 반대 이유:
DID 방식의 표준화 부족:
DID 1.0 표준은 DID의 일반적인 구조를 정의했지만, 특정 DID 방식(method)을 표준화하지 않음.
다양한 방식(method)이 혼재하면서 상호운용성이 제한될 가능성.
DID 방식의 과도한 다양성:
표준은 여러 방식의 사용을 장려하지만, 이는 호환성을 저하시킬 수 있음.
중앙화된 DID 방식 허용:
탈중앙화 목표와 상반되게 중앙화된 방식도 허용.
블록체인 사용에 따른 환경 문제:
블록체인의 높은 에너지 소비가 환경에 미치는 영향을 우려.
대응 논리:
다양성은 기존 시스템에 SSI를 통합하기 쉽게 만들어줍니다. "플러그 앤 플레이" 접근법을 통해 상호운용성과 채택 가능성을 높임.
반대 기업들은 연합형(Federated) ID 제공자로서 SSI 도입이 자신들의 기존 모델에 부정적 영향을 미칠 것을 우려.
2. SSI 자체에 대한 일반적인 비판
기술적 비판:
일부 기술 전문가들은 대부분의 SSI 사용 사례가 기존의 중앙화된 데이터베이스 시스템으로도 해결 가능하다고 주장.
예를 들어, 신분 확인이나 자격 증명은 이미 신뢰할 수 있는 중앙 기관에서 효율적으로 처리되고 있음.
반론:
SSI는 불필요한 중앙화를 피하면서 사용자 통제권을 보장하는 새로운 접근 방식을 제공.
특히, 데이터 프라이버시와 독립성 측면에서 중앙화 시스템보다 뛰어난 잠재력을 가짐.
3. 구현상의 도전 과제
초기 기술의 미성숙:
SSI 관련 기술(지갑 소프트웨어, VC, DID 등)은 여전히 초기 개발 단계에 있음.
예: 상태 목록(Status List)의 표준화가 미흡하며, 이를 지원하는 라이브러리가 충분하지 않음.
프라이빗 키 분실 문제:
사용자가 프라이빗 키를 잃어버릴 경우 복구가 불가능.
키 관리와 백업에 대한 사용자 친화적인 솔루션 부족.
사용성 부족:
SSI 시스템은 복잡한 설정과 이해를 요구, 일반 사용자가 쉽게 접근하기 어려움.
클라우드 기반 지갑 사용 시 프라이버시와 사용성 간의 균형 문제 발생.
DID 방식 선택의 어려움:
약 170개 이상의 DID 방식이 존재.
각 방식은 비용, 기능, 보안 수준에서 큰 차이를 보이며, 기술 전문가조차 적절한 방식을 선택하기 어려움.
4. 거버넌스(Governance) 문제
발급자 신뢰 문제:
신뢰할 수 없는 발급자(예: 졸업장을 발급한 기관)의 DID를 검증하는 메커니즘이 부족.
예: "이 DID가 실제로 대학인가? 신뢰할 수 있는 발급자인가?"
해결책:
신뢰할 수 있는 발급자 레지스트리(Trusted Issuer Registry)를 구축하여 신뢰성을 관리.
그러나, 이는 중앙화 문제와 충돌 가능.
글로벌 신뢰 관리의 어려움:
한 국가의 정부가 신뢰할 수 있는 대학 목록을 제공할 수는 있지만, 모든 국가나 조직에서 신뢰받기는 어려움.
예: 국제적으로 수용 가능한 단일 기관 설립의 어려움.
5. 환경 문제
SSI는 블록체인 기술에 크게 의존하며, 이로 인해 높은 에너지 소비와 환경적 영향 문제가 제기됨.
그러나 DID 1.0 표준은 블록체인을 반드시 요구하지 않으며, 대안 기술 탐색이 가능.
6. 기타 문제
탈중앙화와 규제의 균형:
완전히 탈중앙화된 시스템은 정부와 규제 기관이 원하는 투명성과 충돌 가능.
보안 문제:
블록체인에 저장된 데이터가 해킹당하거나 잘못 사용될 가능성.
사용자의 책임 증가:
모든 데이터와 키 관리가 사용자에게 의존하여, 비기술적 사용자에게는 부담이 될 수 있음.
