블로그 · 2026년 7월 28일

W3C 분산 식별자(DID) 사양 이해하기 (KO)

W3C DID 코어 사양에 대한 기술적 설명: 식별자 및 DID URL 구문, 주체, 컨트롤러, DID 문서, 메서드, 해석, 검증 관계, 서비스, 개인 정보 보호, 그리고 검증 가능한 자격 증명에 대해 알아봅니다.

작성자: Didit2026년 7월 28일업데이트됨 2026년 7월 28일

W3C 분산 식별자(DID) 사양은 URI 구문, 공통 데이터 모델, DID 문서, 핵심 속성, 표현, 메서드 요구 사항, 그리고 해석 및 DID URL 역참조를 위한 추상 인터페이스를 정의합니다. DID 코어 1.0은 2022년 7월 19일 W3C 권고안이 되었습니다. DID 코어 1.1은 2026년 3월 5일 후보 권고 스냅샷으로 발행되었으며, 이는 다른 표준 단계의 새로운 작업입니다.

DID 코어는 블록체인을 요구하지 않으며, 개인의 법적 신원을 증명하거나, 모든 DID 문서 내에 자격 증명을 저장하거나, 모든 해석된 엔드포인트를 신뢰할 수 있도록 만들지 않습니다. 이는 식별자 및 문서 아키텍처를 표준화합니다. 별도의 DID 메서드는 특정 DID가 선택된 인프라에서 생성, 읽기, 업데이트 및 비활성화되는 방법을 정의합니다.

주요 내용

DID는 자격 증명이 아닌 URI입니다. 일반적인 형식은 did:<method-name>:<method-specific-id>입니다.
주체와 컨트롤러는 다른 역할입니다. 주체는 DID가 식별하는 대상이며, 컨트롤러는 메서드에 의해 DID 문서를 변경할 권한을 부여받습니다.
키에는 명시적인 목적이 필요합니다. 검증 메서드는 해당 검증 관계를 통해서만 인증, 주장, 키 합의, 기능 호출 또는 위임에 사용될 수 있습니다.
메서드는 운영 규칙을 제공합니다. DID 코어는 기술 중립적이며, 메서드는 레지스트리 상호 작용, 권한 부여, 업데이트, 비활성화 및 메서드별 해석을 정의합니다.
해석 자체만으로는 신뢰를 생성하지 않습니다. 구현자는 메서드 결과를 인증하고, 증명 목적을 강제하며, 키와 기록을 관리하고, 개인 정보를 보호하며, 애플리케이션 정책을 적용해야 합니다.

분산 식별자란 무엇인가요?

분산 식별자는 하나의 중앙 신원 제공자나 인증 기관이 모든 식별자를 발행하고 유지할 필요 없이 제어를 설정할 수 있도록 설계된 식별자입니다. “분산형”이라는 단어는 단일 중앙 발행자로부터 식별자 제어를 분리할 수 있는 아키텍처의 능력을 설명합니다. 이는 모든 구현이 익명, 공개, 변경 불가능하거나 분산 원장에 저장된다는 것을 의미하지 않습니다.

DID는 다음을 식별할 수 있습니다:

사람;
조직 또는 그룹;
장치 또는 물리적 객체;
디지털 자원;
데이터 모델;
추상적 개념.

식별되는 엔터티는 DID 주체입니다. 문자열만으로는 주체 유형을 알 수 없습니다.

DID 구문

일반적인 구문은 다음과 같습니다:

did:<method-name>:<method-specific-id>

예시:

did:example:123456789abcdefghi

did는 URI 스키마입니다. example은 DID 메서드 이름입니다. 나머지 문자열은 메서드별 식별자입니다. 메서드 사양은 해당 값의 의미와 소프트웨어가 이를 처리하는 방법을 정의합니다.

유효해 보이는 DID가 반드시 사용 가능한 것은 아닙니다. 메서드가 존재해야 하며 해석기가 이를 지원해야 합니다.

DID URL: 경로, 쿼리 및 프래그먼트

DID URL은 DID로 시작하며 경로, 쿼리 또는 프래그먼트를 추가할 수 있습니다:

did:example:123456789abcdefghi/path?service=messages#key-1

이러한 구성 요소는 다음을 식별하거나 선택하는 데 도움이 될 수 있습니다:

DID 문서 내의 검증 메서드;
서비스 항목;
다른 DID 문서 프래그먼트;
서비스를 통해 접근하는 리소스;
버전 또는 메서드 정의 옵션.

프래그먼트 #key-1은 일반적으로 검증 메서드를 식별합니다. 이는 개인 키가 문서에 있다는 의미가 아닙니다. DID 문서는 공개 검증 자료 또는 참조를 게시합니다. 비밀 자료는 다른 곳에 보호되어야 합니다.

DID 아키텍처

주요 개념은 관련되어 있지만 상호 교환될 수는 없습니다:

개념	역할
DID	DID 구문을 준수하는 전역 고유 식별자
DID 주체	식별되는 사람, 조직, 사물, 리소스 또는 개념
DID 컨트롤러	DID 메서드에 따라 DID 문서를 변경할 권한이 있는 엔터티
DID 문서	허용된 검증 메서드 및 서비스를 포함하여 주체와 연결된 데이터
DID 메서드	메서드별 구문 및 작업에 대한 별도의 사양
검증 가능한 데이터 레지스트리	메서드가 DID 상태를 생성, 읽기, 업데이트 또는 비활성화하는 데 사용하는 인프라
DID 해석기	지원되는 메서드에 대해 DID 해석을 수행하는 소프트웨어 또는 하드웨어
DID URL 역참조기	DID URL로 식별된 리소스를 얻는 소프트웨어 또는 하드웨어

주체 대 컨트롤러

주체와 컨트롤러는 동일한 엔터티일 수 있지만, 반드시 그래야 하는 것은 아닙니다. 부모가 자녀를 위한 DID를 제어하거나, 조직이 장치를 위한 DID를 제어하거나, 여러 신탁 관리자가 복구 약정을 제어할 수 있습니다.

최상위 controller는 하나 이상의 DID 컨트롤러를 식별합니다. 검증 메서드에 필요한 controller는 해당 메서드를 제어하는 주체를 식별합니다. 이는 자동으로 최상위 DID 컨트롤러가 아닙니다. 이들을 혼동하면 의도치 않은 권한을 부여할 수 있습니다.

DID 문서란 무엇인가요?

DID 문서는 DID 코어 데이터 모델에 따라 DID 주체와 연결된 데이터입니다. 루트 id는 DID입니다. 선택적 핵심 속성은 컨트롤러, 대체 식별자, 검증 메서드, 검증 관계 및 서비스를 설명할 수 있습니다.

이 간소화된 예시는 사양의 예시 공간에서 가져온 공개 자료를 사용합니다:

{
  "@context": [
    "https://www.w3.org/ns/did/v1",
    "https://w3id.org/security/suites/jws-2020/v1"
  ],
  "id": "did:example:123",
  "verificationMethod": [
    {
      "id": "did:example:123#key-1",
      "type": "JsonWebKey2020",
      "controller": "did:example:123",
      "publicKeyJwk": {
        "kty": "OKP",
        "crv": "Ed25519",
        "x": "VCpo2LMLhn6iWku8MKvSLg2ZAoC-nlOyPVQaO3FxVeQ"
      }
    }
  ],
  "authentication": [
    "did:example:123#key-1"
  ],
  "assertionMethod": [
    "did:example:123#key-1"
  ]
}

did:example은 예시용으로 예약되어 있습니다. 실제 시스템은 실제 메서드와 현재 검증 메서드 스위트 요구 사항을 사용해야 합니다. 위의 JSON은 의도적으로 유효한 JSON입니다. 기술 사양 내에 인쇄된 많은 예시에는 가독성을 위한 주석이나 생략 기호가 포함되어 있으며 파서에 직접 복사해서는 안 됩니다.

핵심 속성

id: 주체에 대한 DID; 문서 루트에서 필수입니다.
controller: 메서드에 따라 변경할 권한이 있는 하나 이상의 DID.
alsoKnownAs: 동일한 주체를 식별한다고 주장되는 다른 URI.
verificationMethod: 명시적 관계에 의해 참조될 수 있는 공개 검증 메커니즘.
authentication: 주체로서 인증에 권한이 부여된 메서드.
assertionMethod: 자격 증명 발행과 같은 주장을 표현할 권한이 부여된 메서드.
keyAgreement: 공유 비밀 자료를 파생시키기 위한 메서드.
capabilityInvocation: 기능 호출에 권한이 부여된 메서드.
capabilityDelegation: 기능 위임에 권한이 부여된 메서드.
service: 주체와 연결된 엔드포인트 또는 상호 작용 메커니즘.

alsoKnownAs는 두 식별자가 동등하다는 암호화 증명이 아닌 주장입니다. 애플리케이션은 신뢰 모델이 요구하는 관계를 독립적으로 확인해야 합니다.

데이터 모델 및 표현

DID 코어는 추상 데이터 모델과 표현을 생성하고 소비하는 규칙을 정의합니다. 데이터 모델은 하나의 JSON 직렬화와 동일하지 않습니다.

표현 요구 사항은 버전별로 다릅니다:

2022년 DID 코어 1.0 권고안은 application/did+json 및 application/did+ld+json을 정의합니다. JSON-LD 표현은 기본 컨텍스트 https://www.w3.org/ns/did/v1로 시작합니다.
DID 코어 1.1 후보 권고안은 핵심 미디어 유형을 application/did로 통합합니다. JSON-LD 표현은 https://www.w3.org/ns/did/v1.1로 시작합니다.

한 버전의 미디어 유형 또는 기본 컨텍스트를 다른 버전의 준수 주장과 혼합하지 마십시오. 생산자와 소비자가 구현하는 사양 버전을 고정하십시오.

구현자는 표현을 명시적으로 협상하고 검증해야 합니다. 정의된 정규화 및 보안 메커니즘 없이 임의의 직렬화된 JSON 바이트에 서명하는 것은 DID 데이터 모델을 올바르게 처리하는 것과 동일하지 않습니다.

검증 메서드 및 검증 관계

검증 메서드는 증명 확인 방법을 설명합니다. 다음을 요구합니다:

DID URL로 표현된 id;
type;
controller;
해당 유형에 적합한 검증 자료.

공개 자료는 publicKeyJwk와 같은 정의된 속성 또는 검증 메서드 스위트에서 허용하는 다른 형식을 통해 표현될 수 있습니다. DID 문서의 JWK에는 개인 키 자료가 포함되어서는 안 됩니다. 동일한 검증 자료가 하나의 메서드 내에서 여러 자료 속성으로 중복되어서는 안 됩니다.

검증 메서드를 정의한다고 해서 모든 목적에 대해 권한을 부여하는 것은 아닙니다. 권한 부여는 다섯 가지 명시적인 검증 관계에서 비롯됩니다.

관계	의도된 증명 목적
`authentication`	챌린지-응답 또는 다른 허용된 메커니즘을 통해 DID 주체로 인증
`assertionMethod`	선택된 보안 메커니즘이 이를 사용하는 검증 가능한 자격 증명 서명을 포함하여 주장 표현
`keyAgreement`	종종 암호화를 위한 공유 암호화 자료 설정
`capabilityInvocation`	객체 기능 호출
`capabilityDelegation`	객체 기능 위임

검증자는 증명에 필요한 관계를 확인해야 합니다. authentication 아래에만 나열된 키는 자동으로 자격 증명 주장 또는 키 합의에 권한이 부여되지 않습니다.

관계는 완전한 검증 메서드를 포함하거나 DID URL로 참조할 수 있습니다. 참조는 재사용성을 향상시키지만 올바른 역참조 및 정확한 식별자 비교가 필요합니다.

서비스 및 서비스 엔드포인트

선택적 service 속성은 DID 주체와 통신하거나 상호 작용하는 방법을 광고할 수 있습니다. 모든 서비스 항목에는 다음이 있습니다:

고유한 id;
type;
serviceEndpoint.

엔드포인트는 URI 또는 다른 허용된 구조일 수 있습니다. 서비스 정의는 확장 가능하므로 애플리케이션은 선택된 유형을 이해해야 합니다.

엔드포인트를 게시한다고 해서 해당 서버, 운영자, 전송, 콘텐츠 또는 대상이 신뢰할 수 있다는 것을 증명하는 것은 아닙니다.

애플리케이션은 메서드를 통해 해석된 DID 상태를 인증하고, 서비스 유형을 검증하며, URL 및 네트워크 보안 제어를 적용하고, 자체 보안 속성을 가진 애플리케이션 프로토콜을 사용해야 합니다.

공개 서비스 엔드포인트는 또한 상관 관계를 생성할 수 있습니다. 쌍별 DID에 걸쳐 하나의 엔드포인트를 재사용하면 별도의 식별자의 개인 정보 보호 이점을 상실할 수 있습니다.

DID 메서드가 정의하는 것

DID 코어는 공통 아키텍처를 제공합니다. 규격 DID 메서드는 다음을 포함하여 이를 구현하는 데 필요한 메서드별 규칙을 정의합니다:

메서드 이름 및 메서드별 식별자 구문;
DID 및 초기 DID 문서가 생성되는 방법;
현재 상태가 읽혀지는 방법;
권한 있는 업데이트가 제출되고 확인되는 방법;
DID가 비활성화되는 방법;
해석이 레지스트리와 통신하는 방법;
결과의 진정성과 무결성이 확립되는 방법;
키 로테이션, 복구, 버전 관리 및 기록이 작동하는 방법;
메서드별 보안 및 개인 정보 보호 고려 사항.

검증 가능한 데이터 레지스트리는 분산 원장, 분산 파일 시스템, P2P 네트워크, 데이터베이스 또는 다른 시스템일 수 있습니다. 아키텍처는 “분산형”이라는 단어보다는 거버넌스, 가용성, 권한 부여, 개인 정보 보호, 비용, 기록 및 공격 저항성을 기준으로 평가되어야 합니다.

메서드 선택 기준

메서드를 선택하기 전에 다음을 테스트하십시오:

사양 성숙도 및 거버넌스;
해석기 및 라이브러리 상호 운용성;
업데이트 및 비활성화 권한 부여;
키 로테이션 및 복구;
과거 상태 지원;
개인 정보 보호 및 메타데이터 유출;
레지스트리 가용성 및 검열 위험;
거래 또는 운영 비용;
암호화 민첩성;
마이그레이션 및 메서드 실패.

메서드를 변경하는 것은 일반적으로 새로운 식별자와 신뢰할 수 있는 마이그레이션 경로를 도입하는 것을 의미합니다.

DID 해석 대 DID URL 역참조

DID 해석은 DID 및 해석 옵션을 가져와 다음을 반환합니다:

DID 해석 메타데이터;
DID 문서, 문서 스트림 또는 문서 없음;
DID 문서 메타데이터.

해석기는 메서드에 의해 정의된 “읽기” 작업을 사용합니다. DID 코어는 추상 인터페이스와 공통 결과 개념을 정의합니다. 메서드별 통신 및 인증은 메서드에 남아 있습니다.

DID URL 역참조는 완전한 DID URL을 가져와 다음을 반환합니다:

역참조 메타데이터;
식별된 리소스(사용 가능한 경우);
콘텐츠 메타데이터.

역참조는 먼저 기본 DID를 해석한 다음 프래그먼트, 서비스 또는 외부 리소스를 선택할 수 있습니다. 이는 해석의 동의어가 아닙니다.

별도의 W3C DID 해석 사양은 상세한 해석 및 역참조 알고리즘을 개발합니다. 최신 발행물은 2026년 7월 24일자 W3C 작업 초안이며, DID URL 역참조는 위험 기능으로 표시되어 있습니다. 이는 2022년 DID 코어 1.0 권고안의 일부가 아닌 표준 트랙 작업으로 남아 있으므로, 준수를 주장하기 전에 초안을 고정하십시오.

해석기 신뢰 및 캐싱

해석기는 보안 및 개인 정보 보호 경계입니다. 요청된 식별자를 보고 오래되거나 조작된 상태를 반환할 수 있습니다. 다음을 평가하십시오:

메서드 결과 검증;
전송 및 해석기 인증;
캐시 신선도 및 무효화;
버전 및 시간 옵션;
오류 처리 및 다운그레이드 동작;
조회를 통한 개인 정보 유출;
레지스트리 또는 네트워크 실패 시 동작.

DID와 검증 가능한 자격 증명

DID와 검증 가능한 자격 증명은 상호 보완적인 사양이며, 동일한 객체가 아닙니다.

기본 DID는 다음을 식별할 수 있습니다:

자격 증명 발행자;
자격 증명 주체;
소지자.

보안 메커니즘에서 사용되는 검증 메서드는 DID URL(일반적으로 DID 뒤에 #key-1과 같은 프래그먼트가 오는 형태)로 식별됩니다.

W3C 검증 가능한 자격 증명 데이터 모델 2.0은 자격 증명, 프레젠테이션, 발행자, 소지자, 주체, 유효성, 상태, 스키마 및 보안 메커니즘을 정의합니다. 모든 식별자가 DID여야 한다고 요구하지는 않습니다.

DID가 발행자에 사용될 때, 검증자는 발행자의 DID를 해석하고, 증명의 검증 메서드를 찾고, 해당 메서드가 assertionMethod에 따라 권한이 부여되었는지 확인할 수 있습니다. 이러한 암호화 검증은 여전히 다음을 설정하지 않습니다:

모든 자격 증명 주장이 사실이라는 것;
발행자가 해당 주장에 대해 신뢰할 수 있다는 것;
자격 증명이 현재 유효하거나 수용 가능하다는 것;
상태, 스키마 또는 증거가 정책을 충족한다는 것;
자격 증명 주체가 이를 제시하는 사람이라는 것.

이러한 확인은 보안 메커니즘, 상태 시스템, 신뢰 프레임워크, 프레젠테이션 바인딩 및 검증자 정책에 속합니다.

개인 정보 보호 및 보안 고려 사항

공개 문서에 개인 데이터 사용 방지

DID 문서는 널리 복제될 수 있습니다. 모델이 확장 가능하다는 이유만으로 이름, 정부 식별자, 생체 인식, 자격 증명 또는 기타 개인 데이터를 게시하지 마십시오. 암호화는 영구적으로 공개된 암호문에 대한 지속적인 해결책이 아닙니다.

상관 관계 방지

쌍별 또는 컨텍스트별 DID는 다른 데이터도 분리되어 있는 경우에만 상관 관계를 줄일 수 있습니다. 재사용된 키, 서비스 엔드포인트, 네트워크 식별자, 자격 증명 속성, 타이밍 및 레지스트리 활동은 개별적으로 보이는 DID를 연결할 수 있습니다.

키 로테이션 및 복구

출시 전에 침해를 계획하십시오. 업데이트 권한 부여, 복구 컨트롤러, 임계값 규칙, 로테이션, 이전 키 처리 및 비활성화를 정의하십시오. 복구 권한은 분리 및 감사가 필요합니다.

증명 목적 검증

서명이 검증되는지뿐만 아니라, 해당 검증 메서드가 관련 시점에 필요한 관계에 대해 권한이 부여되었는지 확인하십시오. 인증, 주장, 합의 및 기능 사용 간의 대체 방지하십시오.

기록 신중하게 처리

현재 DID 문서에는 더 이상 이전 키가 포함되어 있지 않을 수 있습니다. 과거 증명을 검증하려면 메서드에서 지원하는 과거 버전과 증명 시간의 신뢰할 수 있는 증거가 필요할 수 있습니다. “현재 키가 없음”과 “증명이 유효한 적이 없음”은 동일한 결론이 아닙니다.

일반적인 DID 구현 실수

DID 코어를 블록체인 사양이라고 부르는 것

DID 코어는 기술 중립적입니다. 블록체인은 가능한 레지스트리 아키텍처 중 하나입니다.

DID를 법적 신원의 증명으로 취급하는 것

DID는 식별자 제어 및 암호화 검증을 지원합니다. 실제 신원 바인딩에는 별도의 증거, 발행자 주장 또는 신뢰 프레임워크가 필요합니다.

나열된 모든 키를 어떤 목적으로든 사용하는 것

명시적인 검증 관계와 증명 목적을 강제하십시오.

서비스 엔드포인트를 자동으로 신뢰하는 것

메서드 상태를 검증하고 애플리케이션, 전송, URL 및 콘텐츠 보안을 적용하십시오.

모든 DID가 비공개 또는 익명이라고 가정하는 것

레지스트리 활동, 해석, 재사용된 자료 및 서비스는 지속적인 상관 관계를 노출할 수 있습니다.

구현 체크리스트

생산 전에 다음을 확인하십시오:

선택한 DID 코어 버전 및 DID 메서드 사양이 고정되어 있는지;
식별자 및 DID URL 구문 분석이 표준 준수 URI 처리를 사용하는지;
허용된 표현 및 미디어 유형이 명시적인지;
모든 증명이 의도된 검증 관계를 강제하는지;
메서드 결과가 어떤 해석기로부터든 신뢰되는 것이 아니라 인증되는지;
캐싱, 버전 관리, 과거 검증 및 비활성화가 테스트되었는지;
업데이트, 로테이션, 침해, 복구 및 마이그레이션 절차가 예행 연습되었는지;
공개 문서에 불필요한 개인 또는 상관 관계 데이터가 포함되어 있지 않은지;
서비스 엔드포인트가 별도의 애플리케이션 계층 보안 검토를 받는지;
검증 가능한 자격 증명 신뢰, 상태, 스키마 및 프레젠테이션 확인이 분리되어 유지되는지.

DID가 신원 확인과 만나는 지점

DID는 주체와 검증 자료를 식별할 수 있지만, 신원 증명을 수행하지는 않습니다. 재사용 가능한 신원 시스템은 여전히 주장을 발행하거나 수락하기 전에 신뢰할 수 있는 증거와 통제된 결정을 필요로 합니다. Didit의 신분증 확인은 그러한 결정에 대한 신원 증거를 제공할 수 있으며, 재사용 가능 KYC는 참여 서비스 전반에 걸쳐 이전 검증을 재사용하는 것을 지원하며 무료로 제공됩니다.

이러한 제품 인접성이 모든 Didit 검증이 DID이거나 DID 해석이 KYC를 대체한다는 것을 의미하지는 않습니다. 현재 모듈 요금은 가격 책정 페이지에서 확인할 수 있습니다. 아키텍처는 식별자 제어, 신원 증거, 자격 증명 발행, 프레젠테이션 및 의존 당사자 정책을 별도의 신뢰 경계로 유지해야 합니다.

자주 묻는 질문

W3C DID 사양은 무엇을 정의하나요?

DID 및 DID URL 구문, 공통 데이터 모델, 핵심 DID 문서 속성, 표현, 메서드 요구 사항, 그리고 추상 해석 및 역참조 인터페이스를 정의합니다.

모든 DID는 블록체인을 사용하나요?

아니요. DID 메서드는 원장, 데이터베이스, P2P 시스템, 분산 파일 시스템 또는 다른 레지스트리 아키텍처를 사용할 수 있습니다.

DID와 DID 문서의 차이점은 무엇인가요?

DID는 식별자입니다. DID 문서는 컨트롤러, 검증 메서드 및 그 목적, 서비스 및 기타 정의된 속성을 설명할 수 있는 관련 데이터입니다.

해석과 역참조의 차이점은 무엇인가요?

해석은 DID에 대한 DID 문서 및 메타데이터를 얻습니다. 역참조는 완전한 DID URL로 식별된 리소스를 얻으며, 기본 DID를 해석한 후 발생할 수 있습니다.

DID는 검증 가능한 자격 증명과 동일한가요?

아니요. DID는 식별자입니다. 검증 가능한 자격 증명은 VC 데이터 모델 및 보안 메커니즘에 따른 변조 방지, 기계 검증 가능한 주장 세트입니다. VC는 DID를 사용할 수 있지만 보편적으로 요구하지는 않습니다.

DID를 제어하는 것이 개인의 신원을 증명하나요?

아니요. 이는 DID와 관련된 암호화 또는 메서드별 권한 제어를 증명할 수 있습니다. 해당 제어를 법적 또는 실제 신원에 바인딩하려면 추가 증거 또는 신뢰할 수 있는 주장이 필요합니다.

DID 문서에 개인 키가 포함될 수 있나요?

아니요. DID 문서에는 공개 검증 자료 또는 참조가 포함됩니다. 개인 키 자료는 나타나서는 안 되며 컨트롤러의 키 관리 시스템에 의해 보호되어야 합니다.

주요 참고 자료

DID 코어는 주장이 정확할 때 가장 유용합니다. 이는 식별자, 문서, 검증 목적, 서비스 및 메서드 인터페이스를 표준화합니다. 신뢰는 여전히 메서드의 거버넌스, 인증된 해석, 보호된 키, 명시적인 증명 목적, 개인 정보 보호를 고려한 설계, 그리고 애플리케이션이 어떤 증거를 수락할지에 대한 결정에서 비롯됩니다.

계속 읽기