본문으로 이동
Financial Context Wiki

탈중앙화 신원(DID)

탈중앙화 식별자와 검증 가능한 자격 증명 실무 안내서: 무엇을 증명하는지, 발급과 제시가 어떻게 작동하는지, 신뢰·개인정보·복구 위험이 어디에 남는지 설명합니다.

업데이트

교육 목적으로만 제공되며 투자 조언이 아닙니다. 투자로 손실이 발생할 수 있습니다.

직접 답변

탈중앙화 신원은 하나의 플랫폼 계정을 보편적인 신원 출처로 만들지 않고, 주체가 여러 서비스에서 식별자와 암호학적으로 보호된 자격 증명을 쓰는 아키텍처입니다. 주요 구성 요소는 탈중앙화 식별자(DID), 검증 가능한 자격 증명(VC), 지갑 같은 보유자 소프트웨어, 검증자가 어떤 발급자·증거·보증 수준을 수용할지 정하는 규칙입니다.

DID는 did:example:123 같은 URI입니다. DID 메서드가 생성, 해석, 갱신, 비활성화 방식을 정합니다. 해석 결과는 검증 방법, authentication 또는 assertionMethod 같은 관계, 선택적 서비스 엔드포인트를 담은 DID 문서일 수 있습니다. 대응 키 제어는 해당 메서드에서 DID 제어권을 증명하지만, 법적 이름, 나이, 유일성, 고용, 외부 계정 소유권을 그 자체로 증명하지 않습니다.

검증 가능한 자격 증명은 발급자가 하나 이상의 주체에 대해 한 주장을 담습니다. 보유자는 이를 저장하고 검증자용 검증 가능한 제시를 만들 수 있습니다. 암호 검증 성공은 선택한 증명 방식 아래 보호 데이터의 무결성과 작성자를 확인합니다. 검증자는 발급자를 신뢰할지, 주장이 정책을 충족하는지, 자격 증명이 현재 유효한지, 제시자가 사용할 권리가 있는지를 별도로 판단해야 합니다.

따라서 “탈중앙화”는 무신뢰, 익명, 블록체인 기반, 중개자 부재를 뜻하지 않습니다. 식별자, 자격 증명, 레지스트리, 지갑, 검증 정책을 분리해 단일 로그인 사업자가 모든 관계를 관찰하고 통제하지 않아도 된다는 뜻입니다. 실제 탈중앙화 정도는 발급자, DID 메서드 운영자, 상태 서비스, 지갑 공급자, 복구 관리자, 거버넌스 키, 검증자 정책에 달려 있습니다.

작동 방식

  1. 주장과 신뢰 체계를 정의합니다. 주체, 요청 속성, 허용 발급자, 증명 절차, 보증 수준, 보존 정책, 관할, 이의 절차를 명시합니다. 암호 형식은 대학, 정부, 고용주, 공동체 중 누가 적절한 권위인지 결정하지 않습니다.
  2. 식별자와 키를 만들거나 얻습니다. 발급자와 보유자는 DID, HTTPS URL 또는 지원 식별자를 쓸 수 있습니다. DID라면 메서드가 레지스트리와 수명 주기를 정합니다. 컨트롤러는 개인 키를 보호하고, 해석 문서는 필요한 검증 자료와 엔드포인트만 노출합니다.
  3. 주체를 확인하고 결속합니다. 발급자는 정책에 따라 증거를 확인하고 주장을 자격 증명 주체에 결속합니다. 보유자 키, 계정, 다른 식별자를 참조할 수 있습니다. 사람에 관한 증거와 현재 제시자가 키를 제어한다는 증거를 구분해야 합니다.
  4. 자격 증명을 발급합니다. 발급자는 주장, 유효 기간, 스키마나 유형, 상태 참조를 만들고 지원 증명으로 보호합니다. Data Integrity에서는 cryptosuite, verificationMethod, proofPurpose, proofValue가 검증 방식을 나타냅니다.
  5. 저장하고 선택합니다. 보유자는 로컬 또는 호스팅 지갑에 저장합니다. 지갑은 요청을 설명하고 형식이 허용하면 필요한 데이터만 공개하며, 무관한 맥락에서 안정 식별자를 몰래 재사용하지 않아야 합니다.
  6. 신선도와 대상 결속으로 제시합니다. 검증자는 자신의 신원, 목적, nonce 또는 challenge, 만료를 보냅니다. 보유자는 요청에 결속된 자격 증명이나 파생 제시를 반환합니다. 도메인과 challenge 검사는 다른 검증자나 세션에 대한 재사용을 막습니다.
  7. 암호와 정책을 검증합니다. 인증된 출처에서 발급자 검증 자료를 해석하고, 스위트, 목적, challenge, 도메인, 날짜, 스키마, 상태를 검증한 뒤 업무 규칙을 적용합니다. verified: true는 인가 입력이지 접근 허용 명령이 아닙니다.
  8. 수명 주기를 운영합니다. 침해 키 교체, 자격 증명 중지·폐기, 상태 갱신, 복구·이의 제기, 감사 증거 보존, 이전·종료 계획이 필요합니다. 과거 검증에는 이전 키, 문서, 제시 시점에 대한 명확한 규칙이 필요합니다.

세 가지 주요 역할은 발급자, 보유자, 검증자이며 자격 증명 주체는 보유자와 다를 수 있습니다. 부모가 자녀에 관한 자격 증명을 보유하거나 회사 대리인이 조직의 자격 증명을 제시할 수 있습니다. 자격 증명과 프로토콜이 결속을 세우지 않으면 제시자를 주체로 추정해서는 안 됩니다.

DID와 VC는 독립적입니다. VC는 DID가 아닌 발급자 식별자를 쓸 수 있고 DID는 VC 없이도 쓸 수 있습니다. DID 메서드는 블록체인, 분산 데이터베이스, 웹 도메인, P2P 교환을 이용할 수 있습니다. 보안과 거버넌스는 did: 접두사로 추정하지 말고 직접 평가해야 합니다.

실무 예시

서비스가 생년월일을 수집하지 않고 고객이 18세 이상인지 확인해야 한다고 가정합니다. 인정된 기관이 고객을 확인하고 지갑에 나이 자격 증명을 발급합니다. 자격 증명은 생년월일을 담거나 ageOver18 주장만 담을 수 있으며 공개와 재사용 특성이 달라집니다.

가입 시 서비스는 merchant.example용 18세 이상 제시, challenge n-7f3a, 5분 유효 창을 요청합니다. 지갑은 요청을 보여주고 자격 증명과 증명 스위트가 지원하면 필요한 술어만 공개하는 제시를 파생합니다. 서비스는 기관의 검증 방법, 증명, challenge, 도메인, 시간 창, 상태를 확인한 뒤 감사에 필요한 최소 결과만 기록합니다.

이 흐름은 문서 이미지나 전체 생년월일 보관을 줄이지만 신뢰와 위험을 없애지 않습니다. 기관이 다른 사람을 등록하거나, 지갑·기기가 침해되거나, 안정 식별자·상태 조회가 사용을 연계하거나, 서비스가 과도한 데이터를 요구하거나, 잘못된 중지가 접근을 막을 수 있습니다. 선택적 공개는 제시 데이터만 줄이며 발급자, 지갑, 네트워크, 검증자가 보는 모든 메타데이터를 숨기지는 않습니다.

키 교체는 또 다른 경계를 보여줍니다. 발급자가 침해 키를 바꾸면 새 자격 증명은 새 검증 방법을 써야 합니다. 이전 자격 증명 검증 가능성은 DID 메서드 이력, 증명 시각, 검증자 정책, 상태에 달립니다. 현재 DID 문서에서 이전 키를 지우기만 하면 정당한 과거 검증이 실패하거나 생성 당시 허용 키가 무엇인지 숨길 수 있습니다.

위험과 통제

  • 거짓이거나 지나치게 넓은 주장: 유효한 서명은 발급자의 말을 보존할 뿐 정확하게 만들지 않습니다. 증거, 책임, 보증, 감사, 만료, 정정 절차를 정합니다.
  • 약한 보유자 결속: 제시가 의도한 키나 인증자 제어를 증명하지 않으면 복사본을 타인이 쓸 수 있습니다. 필요한 경우 소유 증명을 검증자, challenge, 목적, 세션에 결속합니다.
  • 키와 지갑 침해: 악성코드, 피싱, 클라우드 지갑 탈취, 불안전한 백업이 자격 증명과 키를 노출합니다. 피싱 저항 인증, 적절한 하드웨어 보호, 침해 신고, 제한적 복구를 씁니다.
  • 복구 중앙화: 한 관리자가 실질적 신원 컨트롤러가 될 수 있습니다. 키 교체 권한, 필요한 증거, 악용 탐지, 이의 제기와 이전 방법을 문서화합니다.
  • 연계: DID, 검증 방법, 서명 패턴, 엔드포인트, 상태 경로 재사용은 서비스 간 활동을 잇습니다. 쌍별 식별자, 도메인 분리 키·증명, 개인정보 보호 상태, 메타데이터 시험을 씁니다.
  • 공개 개인정보: DID 문서와 원장 이력은 공개 색인되고 삭제가 어렵습니다. 이름, 문서 번호, 생체 정보, 개인 주장을 공개 DID 문서와 불변 레지스트리에 두지 않습니다.
  • 상태 개인정보와 가용성: 매번 발급자에게 조회하면 사용처가 드러나고 장애는 정상 사용자를 막습니다. 캐시 가능한 개인정보 보호 상태, 신선도 한계, 인증 갱신, 명확한 실패 동작을 택합니다.
  • 폐기 악용: 발급자나 관리자가 중지나 상태 변경으로 보유자를 검열할 수 있습니다. 권한을 제한하고 변경을 기록하며 이유·구제를 공개하고 가능하면 교체나 대체 발급자를 지원합니다.
  • 해석과 메서드 위험: 리졸버는 오래되거나 악성인 문서를 반환하고 메서드는 중앙 기반에 의존할 수 있습니다. 결과를 인증하고 최종성, 갱신 권한, 가용성, 거버넌스, 버전을 평가합니다.
  • 의미 불일치: 같은 필드도 주장, 단위, 관할, 보증을 다르게 해석할 수 있습니다. 안정적 스키마·어휘, 문맥·유형 검증, 정책 의미 버전을 씁니다.
  • 재전송과 검증자 혼동: nonce, 대상, 도메인, 동작, 만료에 결속되지 않은 제시는 재사용·전송될 수 있습니다. 프로토콜이 요구하는 모든 결속을 검증합니다.
  • 과도한 공개: 선택적 공개를 지원해도 검증자가 전체 자격 증명을 요구할 수 있습니다. 정책·화면에서 최소화를 강제하고 목적을 기록하며 선택 필드를 관행상 필수로 만들지 않습니다.
  • 생태계 종속: 독점 지갑, 증명, 레지스트리, 복구는 이동성을 해칩니다. 표준 준수, 내보내기, 여러 지갑, 암호 민첩성, 이전을 배포 전에 시험합니다.
  • 거버넌스 장악: 한 공급자가 발급자, 갱신, 스키마, 상태를 정하면 다중서명이나 원장도 광범위한 통제를 보장하지 않습니다. 구성 요소별 권한과 변경 통제를 공개합니다.

흔한 오해

  • “DID는 사람이 누구인지 증명한다.” DID는 주체를 식별하고 검증 방법을 보여줄 수 있지만 속성에는 추가 주장, 증거, 신뢰 판단이 필요합니다.
  • “유효한 자격 증명은 주장이 참이라는 뜻이다.” 검증은 예상 증명과 비변조를 보일 뿐 발급자의 원래 조사나 판단을 확인하지 않습니다.
  • “보유자는 항상 자격 증명 주체다.” 역할이 다를 수 있으므로 필요하면 주체와 제시자의 명시적 결속이 필요합니다.
  • “모든 것을 온체인에 둬야 한다.” 공개 불변 저장은 개인정보, 연계, 삭제, 거버넌스 위험을 키웁니다. 많은 시스템은 자격 증명을 오프체인에 둡니다.
  • “선택적 공개는 익명성을 보장한다.” 공개 속성, 안정 식별자, 증명 지문, 상태 조회, 시간, IP, 발급자 로그가 여전히 제시를 연계할 수 있습니다.
  • “탈중앙화는 신뢰할 발급자나 관리자가 없다는 뜻이다.” 신뢰는 분산되고 명시될 뿐 제거되지 않습니다. 발급, 확인, 지갑 배포, 복구, 상태, 수용은 계속 통제됩니다.
  • “DID 하나는 사람 한 명이다.” 한 사람이 여러 DID를 제어할 수 있고 DID는 조직, 기기, 데이터, 역할 등도 식별합니다. 유일성과 인간성은 별도 메커니즘입니다.
  • “지갑 서명만으로 인증은 충분하다.” 정해진 조건에서 키 제어만 증명합니다. 피싱 저항, 신선도, 대상 결속, 인가, 계정 복구도 필요합니다.

관련 주제

출처

탐색

위키 검색...