탈중앙화 식별자(DID) v1.1

핵심 아키텍처, 데이터 모델 및 표현

W3C 후보 권고안 스냅샷

이 문서에 대한 자세한 정보
이 버전:
https://www.w3.org/TR/2026/CR-did-1.1-20260305/
최신 공개 버전:
https://www.w3.org/TR/did-1.1/
최신 편집자 초안:
https://w3c.github.io/did/
이력:
https://www.w3.org/standards/history/did-1.1/
커밋 이력
테스트 스위트:
https://github.com/w3c/did-test-suite/
구현 보고서:
https://w3c.github.io/did-test-suite/
편집자:
Manu Sporny (Digital Bazaar) (v1.0, v1.1)
Dmitri Zagidulin (초청 전문가) (v1.1)
이전 편집자:
Amy Guy (Digital Bazaar) (v1.0)
Markus Sabadello (Danube Tech) (v1.0)
Drummond Reed (Evernym/Avast) (v1.0)
저자:
Manu Sporny (Digital Bazaar)
Dave Longley (Digital Bazaar)
Markus Sabadello (Danube Tech)
Drummond Reed (Evernym/Avast)
Orie Steele (Transmute)
Christopher Allen (Blockchain Commons)
피드백:
GitHub w3c/did (풀 리퀘스트, 새 이슈, 열린 이슈)
public-did-wg@w3.org 제목 줄에 [did-1.1] … 메시지 주제 …를 포함하십시오 (아카이브)
관련 문서
DID 사용 사례 및 요구사항
DID 확장
DID Core 구현 보고서

초록

탈중앙화 식별자(DID)는 검증 가능하고 탈중앙화된 디지털 신원을 가능하게 하는 새로운 유형의 식별자입니다. DID는 DID의 컨트롤러가 결정한 모든 주체(예: 사람, 조직, 사물, 데이터 모델, 추상 엔터티 등)를 가리킵니다. 일반적인 연합 식별자와 달리, DID는 중앙화된 레지스트리, 신원 제공자 및 인증 기관으로부터 분리될 수 있도록 설계되었습니다. 구체적으로, 다른 당사자가 DID와 관련된 정보의 발견을 가능하게 하는 데 사용될 수도 있지만, 이 설계는 DID의 컨트롤러가 다른 어떤 당사자의 허가도 필요로 하지 않고 그에 대한 제어권을 증명할 수 있게 합니다. DIDURI이며, DID 주체DID 문서와 연결하여 그 주체와 관련된 신뢰할 수 있는 상호작용을 가능하게 합니다.

DID 문서는 암호화 자료, 검증 방법 또는 서비스를 표현할 수 있으며, 이는 DID 컨트롤러DID에 대한 제어권을 증명할 수 있게 하는 일련의 메커니즘을 제공합니다. 서비스DID 주체와 관련된 신뢰할 수 있는 상호작용을 가능하게 합니다. DIDDID 주체가 데이터 모델과 같은 정보 리소스인 경우, DID 주체 자체를 반환하는 수단을 제공할 수도 있습니다.

이 문서는 DID 구문, 공통 데이터 모델, 핵심 속성, 직렬화된 표현, DID 작업, 그리고 DID를 그것이 나타내는 리소스로 해석하는 과정에 대한 설명을 명시합니다.

이 문서의 상태

이 절은 이 문서가 공개된 시점의 상태를 설명합니다. 현재 W3C 간행물 목록과 이 기술 보고서의 최신 개정판은 W3C 표준 및 초안 색인에서 확인할 수 있습니다.

W3C 탈중앙화 식별자 워킹 그룹은 이 문서를 W3C 후보 권고안으로 공개했으며, 소프트웨어 개발자와 DID 메서드 명세 작성자에게 이 문서의 모든 기능의 구현 가능성을 시험하도록 설계된 실험적 구현을 제공할 것을 요청합니다.

구현자는 이슈 트래커에 class 1, 2 또는 3 공개 이슈가 나열되어 있는 경우, 해당 이슈가 명세 변경으로 이어질 수 있음을 유의해야 합니다.

W3C 후보 권고안 단계를 종료하기 위해, W3C DID 워킹 그룹은 다음을 요구합니다.

  1. 기계로 테스트할 수 있는 규범 문장의 경우, 기능별로 최소 두 개의 적합한 구현이 있어야 합니다. 즉, 적합한 생산자가 기능을 구현할 때, 최소 두 개의 적합한 소비자가 그 기능을 소비할 수 있어야 하며, 소비되는 모든 기능마다 해당 기능을 생산하는 최소 두 개의 적합한 생산자가 있어야 합니다.
  2. 기계로 테스트할 수 없는 규범 문장의 경우, 기능별로 최소 두 개의 구현 시연이 있어야 합니다.
  3. 탈중앙화 식별자 해석(DID Resolution) v0.3 명세가 W3C 후보 권고안 단계의 종료 기준을 충족해야 합니다.

기능은 명세의 하나 이상의 기능적으로 관련된 규범 문장으로 정의됩니다. 이 명세에서 상호운용성은 데이터 모델 속성과 그 값에 관한 것과 같은 규범 문장이 서로 다른 두 DID 메서드 사이에서 같은 방식으로 해석되는 것으로 정의됩니다.

특정 DID 메서드의 해석은 이 명세의 범위를 벗어나며, 탈중앙화 식별자 해석(DID Resolution) v0.3 명세에서 다룹니다.

이 문서는 탈중앙화 식별자 워킹 그룹권고안 트랙을 사용하여 후보 권고안 스냅샷으로 공개했습니다.

후보 권고안으로 공개되었다고 해서 W3C 및 그 회원의 승인을 의미하지는 않습니다. 후보 권고안 스냅샷은 광범위한 검토를 받았고, 구현 경험을 수집하기 위한 것이며, 워킹 그룹 회원으로부터 구현에 대한 로열티 없는 라이선스 약속을 받았습니다.

이 후보 권고안은 2026년 4월 5일보다 이른 시점에 권고안으로 진행될 것으로 예상되지 않습니다.

이 문서는 W3C 특허 정책에 따라 운영되는 그룹에서 작성되었습니다. W3C는 그룹의 산출물과 관련하여 이루어진 모든 특허 공개의 공개 목록을 유지관리하며, 해당 페이지에는 특허 공개 방법에 대한 지침도 포함되어 있습니다. 자신이 알고 있는 특허가 필수 청구항을 포함한다고 믿는 실제 지식을 가진 개인은 W3C 특허 정책 제6절에 따라 해당 정보를 공개해야 합니다.

이 문서는 2025년 8월 18일 W3C 절차 문서의 적용을 받습니다.

1. 소개

이 절은 비규범적입니다.

개인과 조직으로서, 우리 중 많은 사람은 매우 다양한 맥락에서 전역적으로 고유한 식별자를 사용합니다. 이러한 식별자는 통신 주소(전화 번호, 이메일 주소, 소셜 미디어 사용자 이름), ID 번호(여권, 운전면허증, 세금 ID, 건강 보험), 그리고 제품 식별자(일련 번호, 바코드, RFID)로 쓰입니다. URI(Uniform Resource Identifiers)는 웹의 리소스에 사용되며, 브라우저에서 보는 각 웹 페이지에는 전역적으로 고유한 URL(Uniform Resource Locator)이 있습니다.

이러한 전역적으로 고유한 식별자의 대부분은 우리의 통제 아래 있지 않습니다. 이들은 외부 기관이 발급하며, 해당 기관이 누구 또는 무엇을 가리키는지와 언제 폐기될 수 있는지를 결정합니다. 이들은 특정 맥락에서만 유용하고, 우리가 선택하지 않은 특정 주체에 의해서만 인식됩니다. 조직의 실패와 함께 사라지거나 더 이상 유효하지 않게 될 수 있습니다. 또한 불필요하게 개인 정보를 드러낼 수도 있습니다. 많은 경우, 이들은 악의적인 제3자에 의해 부정하게 복제되고 주장될 수 있으며, 이는 일반적으로 "신원 도용"으로 알려져 있습니다.

이 명세에서 정의하는 탈중앙화 식별자(DID)는 새로운 유형의 전역적으로 고유한 식별자입니다. 이는 개인과 조직이 신뢰하는 시스템을 사용하여 자체 식별자를 생성할 수 있도록 설계되었습니다. 이러한 새로운 식별자는 엔터티가 디지털 서명과 같은 암호학적 증명을 사용해 인증함으로써 그 식별자에 대한 제어권을 증명할 수 있게 합니다.

탈중앙화 식별자의 생성과 주장은 엔터티가 제어하므로, 각 엔터티는 자신이 원하는 신원, 페르소나 및 상호작용의 분리를 유지하는 데 필요한 만큼 많은 DID를 가질 수 있습니다. 이러한 식별자의 사용은 서로 다른 맥락에 맞게 적절히 범위가 지정될 수 있습니다. 이는 엔터티가 자신 또는 자신이 제어하는 사물을 식별해야 하는 다른 사람, 기관 또는 시스템과의 상호작용을 지원하면서, 개인 데이터 또는 사적 데이터가 얼마나 공개되어야 하는지를 제어할 수 있게 하며, 이 모든 것은 식별자의 지속적인 존재를 보장하기 위해 중앙 기관에 의존하지 않고 이루어집니다. 이러한 아이디어는 DID 사용 사례 문서 [DID-USE-CASES]에서 살펴봅니다.

이 명세는 DID의 생성, 지속성, 해석 또는 해석 결과의 의미 부여를 뒷받침하기 위해 특정 기술이나 암호 방식을 전제로 하지 않습니다. 예를 들어, 구현자는 연합 또는 중앙화된 신원 관리 시스템에 등록된 식별자를 기반으로 탈중앙화 식별자를 만들 수 있습니다. 실제로 거의 모든 유형의 식별자 시스템은 DID 지원을 추가할 수 있습니다. 이는 중앙화, 연합, 탈중앙화 식별자의 세계 사이에 상호운용성 다리를 만듭니다. 또한 구현자가 분산 원장, 탈중앙화 파일 시스템, 분산 데이터베이스 및 피어 투 피어 네트워크와 같이 자신이 신뢰하는 컴퓨팅 인프라와 함께 작동하도록 특정 유형의 DID를 설계할 수 있게 합니다.

이 명세는 다음을 위한 것입니다.

이 명세에 더해, 독자는 탈중앙화 식별자의 사용 사례 및 요구사항 [DID-USE-CASES] 문서도 유용하다고 느낄 수 있습니다.

1.1 간단한 예

이 절은 비규범적입니다.

DID는 세 부분으로 구성된 단순한 텍스트 문자열입니다. 1) did URI 스킴 식별자, 2) DID 메서드의 식별자, 그리고 3) DID 메서드별 식별자입니다.


DID의 구성 요소를 보여 주는 다이어그램. 가장 왼쪽 글자는 파란색으로 'did'를 나타내며,
위쪽의 수평 괄호와 괄호 위의 'scheme'이라는 레이블로 둘러싸여 있다.
'did' 글자 뒤에는 회색 콜론이 온다. 가운데 글자는 자홍색으로
'example'을 나타내며, 아래쪽의 수평 괄호와 괄호 아래의
'DID Method'라는 레이블로 둘러싸여 있다. DID Method 뒤에는 회색 콜론이 온다.
마지막으로 끝부분의 글자는 초록색으로 '123456789abcdefghi'를 나타내며,
아래쪽의 수평 괄호와 괄호 아래의
'DID Method Specific String'이라는 레이블로 둘러싸여 있다.
그림 1 탈중앙화 식별자(DID)의 간단한 예

위의 예시 DIDDID 문서로 해석됩니다. DID 문서DID와 관련된 정보를 포함합니다. 예를 들면 인증을 통해 DID 컨트롤러를 암호학적으로 인증하는 방법이 있습니다.

예제 1: 간단한 DID 문서
{
  "@context": "https://www.w3.org/ns/did/v1.1",
  "id": "did:example:123456789abcdefghi",
  "authentication": [{
    // did:...fghi로 인증하는 데 사용됨
    "id": "did:example:123456789abcdefghi#keys-1",
    "type": "Multikey",
    "controller": "did:example:123456789abcdefghi",
    "publicKeyMultibase": "z6MkmM42vxfqZQsv4ehtTjFFxQ4sQKS2w6WR7emozFAn5cxu"
  }]
}

1.2 설계 목표

이 절은 비규범적입니다.

탈중앙화 식별자는 검증 가능 자격 증명 생태계 [VC-DATA-MODEL]와 같은 더 큰 시스템의 구성 요소이며, 이는 이 명세의 설계 목표에 영향을 주었습니다. 탈중앙화 식별자의 설계 목표는 여기에 요약되어 있습니다.

목표 설명
탈중앙화 전역적으로 고유한 식별자, 공개 검증 키, 서비스 및 기타 정보의 등록을 포함하여, 식별자 관리에서 중앙 기관 또는 단일 장애 지점에 대한 요구를 제거합니다.
제어 인간 및 비인간 엔터티 모두에게 외부 기관에 의존할 필요 없이 자신의 디지털 식별자를 직접 제어할 권한을 부여합니다.
개인정보 보호 속성 또는 기타 데이터의 최소, 선택적, 점진적 공개를 포함하여 엔터티가 자신의 정보의 개인정보 보호를 제어할 수 있게 합니다.
보안 요청 당사자가 요구하는 보증 수준에 대해 DID 문서에 의존할 수 있도록 충분한 보안을 가능하게 합니다.
증명 기반 DID 컨트롤러가 다른 엔터티와 상호작용할 때 암호학적 증명을 제공할 수 있게 합니다.
발견 가능성 엔터티가 다른 엔터티에 대해 더 알아보거나 상호작용하기 위해 다른 엔터티의 DID를 발견할 수 있게 합니다.
상호운용성 상호운용 가능한 표준을 사용하여 DID 인프라가 상호운용성을 위해 설계된 기존 도구와 소프트웨어 라이브러리를 사용할 수 있게 합니다.
이식성 시스템 및 네트워크에 독립적이고, 엔터티가 DIDDID 메서드를 지원하는 모든 시스템에서 자신의 디지털 식별자를 사용할 수 있게 합니다.
단순성 기술을 더 쉽게 이해하고, 구현하고, 배포할 수 있도록 단순한 기능의 축소된 집합을 선호합니다.
확장성 가능한 경우, 상호운용성, 이식성 또는 단순성을 크게 저해하지 않는 한 확장성을 가능하게 합니다.

1.3 아키텍처 개요

이 절은 비규범적입니다.

이 절은 탈중앙화 식별자 아키텍처의 주요 구성 요소에 대한 기본 개요를 제공합니다.


DID와 DID 문서는 검증 가능 데이터 레지스트리에 기록된다. DID는
DID 문서로 해석된다. DID는 DID 주체를 가리킨다. DID 컨트롤러는 DID
문서를 제어한다. DID URL은 DID를 포함한다. DID URL은 DID 문서
프래그먼트 또는 외부 리소스로 역참조된다.
그림 2 DID 아키텍처와 기본 구성 요소 사이의 관계 개요. 함께 보기: 서술형 설명.

내부 레이블이 붙은 여섯 개의 도형이 다이어그램에 나타나며, 그 사이에 레이블이 붙은 화살표가 다음과 같이 표시됩니다. 다이어그램 중앙에는 DID URL이라고 표시된 직사각형이 있으며, 작은 타자체 텍스트 "did:example:123/path/to/rsrc"가 들어 있습니다. 다이어그램의 상단 중앙에는 "DID"라고 표시된 직사각형이 있고, 작은 타자체 텍스트 "did:example:123"이 들어 있습니다. 왼쪽 상단에는 "DID Subject"라고 표시된 타원이 있습니다. 하단 중앙에는 "DID document"라고 표시된 직사각형이 있습니다. 왼쪽 하단에는 "DID Controller"라고 표시된 타원이 있습니다. 중앙 오른쪽에는 "Verifiable Data Registry"라고 표시된 원기둥의 2차원 렌더링이 있습니다.

"DID URL" 직사각형의 위쪽에서 "contains"라는 레이블이 붙은 화살표가 위로 뻗어 "DID" 직사각형을 가리킵니다. "DID URL" 직사각형의 아래쪽에서 "refers, and dereferences, to"라는 레이블이 붙은 화살표가 아래로 뻗어 "DID document" 직사각형을 가리킵니다. "DID" 직사각형에서 "resolves to"라는 레이블이 붙은 화살표는 아래의 "DID document" 직사각형을 가리킵니다. "DID" 직사각형에서 "refers to"라는 레이블이 붙은 화살표는 왼쪽의 "DID subject" 타원을 가리킵니다. "DID controller" 타원에서 "controls"라는 레이블이 붙은 화살표는 오른쪽의 "DID document" 직사각형을 가리킵니다. "DID" 직사각형에서 "recorded on"이라는 레이블이 붙은 화살표는 오른쪽 아래의 "Verifiable Data Registry" 원기둥을 가리킵니다. "DID document" 직사각형에서 "recorded on"이라는 레이블이 붙은 화살표는 오른쪽 위의 "Verifiable Data Registry" 원기둥을 가리킵니다.

DID와 DID URL
탈중앙화 식별자 또는 DID는 세 부분으로 구성된 URI입니다. 이 세 부분은 did: 스킴, 메서드 식별자, 그리고 DID 메서드가 지정하는 고유한 메서드별 식별자입니다. DIDDID 문서로 해석될 수 있습니다. DID URL은 기본 DID의 구문을 확장하여 경로, 쿼리, 프래그먼트와 같은 표준 URI 구성 요소를 포함함으로써 특정 리소스를 찾습니다. 예를 들어 DID 문서 내부의 암호학적 공개 키 또는 리소스DID 문서 외부에 있을 수 있습니다. 이러한 개념은 3.1 DID 구문3.2 DID URL 구문에서 자세히 설명합니다.
DID 주체
DID의 주체는 정의상 DID에 의해 식별되는 엔터티입니다. DID 주체DID 컨트롤러일 수도 있습니다. 무엇이든 DID의 주체가 될 수 있습니다. 사람, 그룹, 조직, 사물 또는 개념이 이에 해당합니다. 이는 5.1.1 DID 주체에서 더 자세히 정의됩니다.
DID 컨트롤러
컨트롤러 of a DIDDID 메서드가 정의하는 바에 따라 DID 문서를 변경할 수 있는 능력을 가진 엔터티(사람, 조직 또는 자율 소프트웨어)입니다. 이 능력은 일반적으로 컨트롤러를 대신하여 동작하는 소프트웨어가 사용하는 암호학적 키 집합의 제어를 통해 주장되지만, 다른 메커니즘을 통해 주장될 수도 있습니다. DID는 둘 이상의 컨트롤러를 가질 수 있으며, DID 주체DID 컨트롤러이거나 그중 하나일 수 있음에 유의하십시오. 이 개념은 5.1.2 DID 컨트롤러에 문서화되어 있습니다.
검증 가능 데이터 레지스트리
DID 문서로 해석될 수 있으려면, DID는 일반적으로 어떤 종류의 기반 시스템 또는 네트워크에 기록됩니다. 사용되는 특정 기술과 무관하게, DID를 기록하고 DID 문서를 생성하는 데 필요한 데이터를 반환하는 것을 지원하는 모든 시스템을 검증 가능 데이터 레지스트리라고 합니다. 예로는 분산 원장, 탈중앙화 파일 시스템, 모든 종류의 데이터베이스, 피어 투 피어 네트워크 및 기타 형태의 신뢰할 수 있는 데이터 저장소가 있습니다. 이 개념은 7. 메서드에서 더 자세히 설명합니다.
DID 문서
DID 문서DID와 관련된 정보를 포함합니다. 이는 일반적으로 암호학적 공개 키와 같은 검증 방법서비스를 표현하며, 이는 DID 주체와의 상호작용과 관련됩니다. DID 문서에서 지원되는 일반 속성은 5. 핵심 속성에 명시되어 있습니다. DID 문서는 바이트 스트림으로 직렬화될 수 있습니다( 6. 표현 참조). DID 문서에 존재하는 속성은 7. 메서드에 제시된 적용 가능한 작업에 따라 업데이트될 수 있습니다.
DID 메서드
DID 메서드는 특정 유형의 DID와 그 관련 DID 문서를 생성, 해석, 업데이트 및 비활성화하는 메커니즘입니다. DID 메서드7. 메서드에서 정의된 것처럼 별도의 DID 메서드 명세를 사용하여 정의됩니다.
DID 리졸버와 DID 해석
DID 리졸버DID를 입력으로 받아 적합한 DID 문서를 출력으로 생성하는 시스템 구성 요소입니다. 이 과정은 DID 해석이라고 합니다. 특정 유형의 DID를 해석하는 단계는 관련 DID 메서드 명세에서 정의됩니다. DID 해석 과정은 [DID-RESOLUTION]에서 자세히 설명합니다.
DID URL 역참조기와 DID URL 역참조
DID URL 역참조기DID URL을 입력으로 받아 리소스를 출력으로 생성하는 시스템 구성 요소입니다. 이 과정은 DID URL 역참조라고 합니다. DID URL 역참조 과정은 [DID-RESOLUTION]에서 자세히 설명합니다.

1.4 적합성

비규범적이라고 표시된 절과 마찬가지로, 이 명세의 모든 작성 지침, 다이어그램, 예제 및 참고 사항은 비규범적입니다. 이 명세의 그 밖의 모든 내용은 규범적입니다.

이 문서의 핵심 단어 MAY, MUST, MUST NOT, RECOMMENDED, SHOULD, 그리고 SHOULD NOT는 여기에 표시된 것처럼 모두 대문자로 나타날 때, 그리고 그때에만 BCP 14 [RFC2119] [RFC8174]에 설명된 대로 해석되어야 합니다.

이 문서는 JSON 및 JSON-LD 콘텐츠를 포함하는 예제를 포함합니다. 이러한 예제 중 일부는 인라인 주석(//)과 예제에 거의 가치를 더하지 않는 정보를 나타내기 위한 생략 부호(...) 사용과 같은 유효하지 않은 문자를 포함합니다. 구현자는 이 정보를 유효한 JSON 또는 JSON-LD로 사용하고자 할 경우 이러한 콘텐츠를 제거해야 함을 유의해야 합니다.

일부 예제는 이 명세에서 정의되지 않은 용어, 즉 속성 이름과 값을 모두 포함합니다. 이러한 용어는 주석(// external (property name|value))으로 표시됩니다. 이러한 용어가 DID 문서에서 사용될 때, 해당 용어는 공식 정의와 JSON-LD 컨텍스트 모두에 대한 링크와 함께 DID Extensions 저장소 [DID-EXTENSIONS]에 등록될 것으로 기대됩니다.

DIDDID 문서에 대한 구현의 상호운용성은 구현이 이 명세에 적합한 DIDDID 문서를 만들고 파싱하는 능력을 평가하여 테스트합니다. DIDDID 문서의 생산자와 소비자에 대한 상호운용성은 DIDDID 문서가 적합함을 보장함으로써 제공됩니다. DID 메서드 명세에 대한 상호운용성은 각 DID 메서드 명세의 세부 사항에 의해 제공됩니다. 웹 브라우저가 알려진 모든 URI 스킴을 구현할 필요가 없는 것과 마찬가지로, DID와 함께 작동하는 적합한 소프트웨어도 알려진 모든 DID 메서드를 구현할 필요는 없다고 이해됩니다. 그러나 주어진 DID 메서드의 모든 구현은 그 메서드에 대해 상호운용될 것으로 기대됩니다.

적합한 DID3. 식별자에 명시된 규칙의 구체적 표현 중 해당 절의 관련 규범 문장을 준수하는 모든 것입니다.

적합한 DID 문서는 이 명세에 설명된 데이터 모델의 구체적 표현 중 4. 데이터 모델5. 핵심 속성의 관련 규범 문장을 준수하는 모든 것입니다. 적합한 문서를 위한 직렬화 형식은 6. 표현에 설명된 것처럼 결정적이고, 양방향이며, 무손실입니다.

적합한 생산자적합한 DID 또는 적합한 DID 문서를 생성하고 6. 표현의 관련 규범 문장을 준수하는, 소프트웨어 및/또는 하드웨어로 실현된 모든 알고리즘입니다.

적합한 소비자적합한 DID 또는 적합한 DID 문서를 소비하고 6. 표현의 관련 규범 문장을 준수하는, 소프트웨어 및/또는 하드웨어로 실현된 모든 알고리즘입니다.

적합한 DID 메서드7. 메서드의 관련 규범 문장을 준수하는 모든 명세입니다.

1.5 대상 독자

이 절은 비규범적입니다.

이 명세에는 두 가지 주요 대상 독자가 있습니다. 적합한 DID 메서드의 구현자와, DID와 상호작용하고 인터페이스하려는 시스템 및 서비스의 구현자입니다. 의도된 대상 독자는 소프트웨어 아키텍트, 데이터 모델러, 애플리케이션 개발자, 서비스 개발자, 테스터, 운영자, 사용자 경험(UX) 전문가를 포함하지만 이에 국한되지는 않습니다. 탈중앙화 신원, 검증 가능 자격 증명, 보안 저장소와 관련된 광범위한 표준화 작업에 참여하는 다른 사람들도 이 명세를 읽는 데 관심이 있을 수 있습니다.

2. 용어

이 절은 비규범적입니다.

이 절은 이 명세와 탈중앙화 식별자 인프라 전반에서 사용되는 용어를 정의합니다. 이러한 용어가 이 명세에 나타날 때마다 해당 용어에 대한 링크가 포함됩니다.

증폭 공격
공격자가 작은 유효 입력을 시스템에 제공하여 대상 시스템의 CPU, 스토리지, 네트워크 또는 기타 리소스를 고갈시키려는 공격 유형입니다. 이러한 입력은 입력 자체보다 처리 비용이 기하급수적으로 더 큰 피해 효과를 초래합니다.
탈중앙화 식별자 (DID)
중앙화된 등록 기관을 필요로 하지 않으며, 종종 암호학적으로 생성 및/또는 등록되는 전역적으로 고유한 영속 식별자입니다. DID의 일반 형식은 3.1 DID 구문에 정의되어 있습니다. 특정 DID 스킴DID 메서드 명세에 정의됩니다. 많은 DID 메서드가 — 전부는 아니지만 — 분산 원장 기술(DLT) 또는 기타 형태의 탈중앙화 네트워크를 사용합니다.
DID 컨트롤러
DID 문서를 변경할 수 있는 능력을 가진 엔터티입니다. DID에는 둘 이상의 DID 컨트롤러가 있을 수 있습니다. DID 컨트롤러는 DID 문서의 최상위 수준에 있는 선택적 controller 속성으로 표시될 수 있습니다. DID 컨트롤러가 DID 주체일 수도 있음에 유의하십시오.
DID 대리자
DID 컨트롤러DID 문서를 통해 DID와 관련된 검증 방법을 사용할 권한을 부여한 엔터티입니다. 예를 들어, 자녀의 DID 문서를 제어하는 부모가 자녀에게 개인 기기를 사용하여 인증하도록 허용할 수 있습니다. 이 경우 자녀는 DID 대리자입니다. 자녀의 개인 기기는 자녀가 DID를 사용해 인증할 수 있도록 하는 비공개 암호학적 자료를 포함할 것입니다. 그러나 자녀는 부모의 허가 없이 다른 개인 기기를 추가하는 것이 허용되지 않을 수 있습니다.
DID 문서
DID 주체와의 암호학적으로 검증 가능한 상호작용을 가능하게 하는 데이터 집합입니다. 여기에는 암호학적 공개 키와 같은 메커니즘이 포함되며, DID 주체 또는 DID 대리자가 자신을 인증하고 DID와의 연관성을 증명하는 데 사용할 수 있습니다. DID 문서는 표현을 하나 이상 가질 수 있으며, 이는 6. 표현 또는 W3C 탈중앙화 식별자 확장에 정의되어 있습니다.
DID 프래그먼트
DID URL에서 첫 번째 # 문자 (U+0023 NUMBER SIGN) 뒤에 오는 부분입니다. DID 프래그먼트 구문은 URI 프래그먼트 구문과 동일합니다.
DID 메서드
특정 DID 메서드 스킴이 어떻게 구현되는지를 정의한 것입니다. DID 메서드는 DID 메서드 명세에 의해 정의되며, 그 명세는 DIDDID 문서가 생성, 해석, 업데이트 및 비활성화되는 정확한 작업을 지정합니다. 7. 메서드를 참조하십시오.
DID 경로
DID URL에서 첫 번째 / 문자 (U+002F SOLIDUS)로 시작하여 그 문자를 포함하고, ? 문자 (U+003F QUESTION MARK), # 문자 (U+0023 NUMBER SIGN), 또는 DID URL의 끝까지 중 먼저 나오는 지점에서 끝나되, 그 지점은 포함하지 않는 부분입니다. DID 경로 구문은 URI 경로 구문과 동일합니다. 경로를 참조하십시오.
DID 쿼리
DID URL에서 첫 번째 ? 문자 (U+003F QUESTION MARK) 뒤에 오며 그 문자를 포함하는 부분입니다. DID 쿼리 구문은 URI 쿼리 구문과 동일합니다. 쿼리를 참조하십시오.
DID 해석
DID와 해석 옵션 집합을 입력으로 받아, 적합한 표현DID 문서와 추가 메타데이터를 반환하는 과정입니다. 이 과정은 적용 가능한 DID 메서드의 "Read" 작업에 의존합니다. 이 과정의 입력과 출력은 [DID-RESOLUTION]에 정의되어 있습니다.
DID 리졸버
DID 리졸버DID를 입력으로 받아 적합한 DID 문서를 출력으로 생성함으로써 DID 해석 기능을 수행하는 소프트웨어 및/또는 하드웨어 구성 요소입니다.
DID 스킴
탈중앙화 식별자의 공식 구문입니다. 일반 DID 스킴은 3.1 DID 구문에 정의된 것처럼 접두사 did:로 시작합니다. 각 DID 메서드 명세는 해당 특정 DID 메서드와 함께 작동하는 특정 DID 메서드 스킴을 정의합니다. 특정 DID 메서드 스킴에서 DID 메서드 이름은 첫 번째 콜론 뒤에 오며 두 번째 콜론에서 끝납니다. 예: did:example:
DID 주체
DID로 식별되고 DID 문서에 의해 설명되는 엔터티입니다. 무엇이든 DID 주체가 될 수 있습니다. 사람, 그룹, 조직, 물리적 사물, 디지털 사물, 논리적 사물 등이 이에 해당합니다.
DID URL
DID3.2 DID URL 구문의 정의에 적합한 추가 구문 구성 요소입니다. 여기에는 선행 / 문자 (U+002F SOLIDUS)가 있는 선택적 DID 경로, 선행 ? 문자 (U+003F QUESTION MARK)가 있는 선택적 DID 쿼리, 그리고 선행 # 문자 (U+0023 NUMBER SIGN)가 있는 선택적 DID 프래그먼트가 포함됩니다.
DID URL 역참조
DID URL과 입력 메타데이터 집합을 입력으로 받아 리소스를 반환하는 과정입니다. 이 리소스는 추가 메타데이터가 있는 DID 문서, DID 문서 안에 포함된 보조 리소스, 또는 DID 문서 외부에 완전히 존재하는 리소스일 수 있습니다. 이 과정은 DID 해석을 사용하여 DID URL에 포함된 DID가 가리키는 DID 문서를 가져옵니다. 그런 다음 역참조 과정은 DID 문서에 대해 추가 처리를 수행하여 DID URL이 가리키는 역참조된 리소스를 반환할 수 있습니다. 이 과정의 입력과 출력은 [DID-RESOLUTION]에 정의되어 있습니다.
DID URL 역참조기
주어진 DID URL 또는 DID 문서에 대해 DID URL 역참조 기능을 수행하는 소프트웨어 및/또는 하드웨어 시스템입니다.
분산 원장 (DLT)
사건을 기록하기 위한 비중앙화 시스템입니다. 이러한 시스템은 참여자가 다른 사람이 기록한 데이터에 의존하여 운영 결정을 내릴 수 있을 만큼 충분한 신뢰를 형성합니다. 일반적으로 서로 다른 노드가 합의 프로토콜을 사용하여 암호학적으로 서명된 트랜잭션의 순서를 확인하는 분산 데이터베이스를 사용합니다. 시간이 지남에 따라 디지털 서명된 트랜잭션이 연결되면 원장의 이력이 사실상 불변이 되는 경우가 많습니다.
리소스
[RFC3986]에 정의된 것처럼 URI로 식별되는 대상입니다. 마찬가지로, 모든 리소스는 DID로 식별되는 DID 주체 역할을 할 수 있습니다.
표현
[RFC9110]에서 정의한 것처럼 리소스의 구체적 표현입니다. "주어진 리소스의 과거, 현재 또는 원하는 상태를 반영하도록 의도된 정보로서, 프로토콜을 통해 쉽게 전달될 수 있는 형식의 것입니다. 표현은 표현 메타데이터 집합과 잠재적으로 무한한 표현 데이터 스트림으로 구성됩니다." DID 문서DID 주체와의 암호학적으로 검증 가능한 상호작용을 가능하게 하는 정보의 표현입니다. 6. 표현을 참조하십시오.
표현별 항목
특정 표현에 고유한 의미를 가지는 DID 문서 안의 항목입니다. 4. 데이터 모델6. 표현에 정의되어 있습니다.
서비스
하나 이상의 서비스 엔드포인트를 통해 DID 주체 또는 관련 엔터티와 통신하거나 상호작용하는 수단입니다. 예로는 발견 서비스, 에이전트 서비스, 소셜 네트워킹 서비스, 파일 저장 서비스, 검증 가능 자격 증명 저장소 서비스가 있습니다.
DID 서비스 엔드포인트
서비스DID 주체를 대신하여 작동하는 HTTP URL과 같은 네트워크 주소입니다.
Uniform Resource Identifier (URI)
[RFC3986]에 정의된 월드 와이드 웹의 모든 리소스를 위한 표준 식별자 형식입니다. DID는 URI 스킴의 한 유형입니다.
검증 가능 데이터 레지스트리
탈중앙화 식별자DID 문서의 생성, 검증, 업데이트 및/또는 비활성화를 용이하게 하는 시스템입니다. 검증 가능 데이터 레지스트리는 검증 가능 자격 증명과 같은 기타 암호학적으로 검증 가능한 데이터 구조에도 사용될 수 있습니다. 자세한 내용은 W3C 검증 가능 자격 증명 명세 [VC-DATA-MODEL]를 참조하십시오.
검증 가능 타임스탬프
검증 가능 타임스탬프는 데이터 객체가 특정 시점에 존재했으며 그 시점 이후로 수정되거나 손상되지 않았음을 제3자가 검증할 수 있게 합니다. 데이터 무결성이 그 시점 이후로 합리적으로 수정되었거나 손상되었을 수 있다면, 해당 타임스탬프는 검증 가능하지 않습니다.

위의 용어 외에도, 이 명세는 데이터 모델을 공식적으로 정의하기 위해 [INFRA] 명세의 용어도 사용합니다. [INFRA] 용어가 사용될 때, 예를 들어 문자열, 집합, 그리고 과 같은 용어는 해당 명세로 직접 링크됩니다.

3. 식별자

이 절은 DIDDID URL의 공식 구문을 설명합니다. 여기에서 정의된 구문을 각자의 명세에서 특정 DID 메서드가 정의하는 구문과 구별하기 위해 "generic"이라는 용어를 사용합니다. DIDDID URL의 생성 과정과 그 시점은 7.2 메서드 작업B.2 DID 생성에 설명되어 있습니다.

3.1 DID 구문

일반 DID 스킴은 [RFC3986]에 적합한 URI 스킴입니다. ABNF 정의는 아래에서 찾을 수 있으며, 이는 [RFC5234]의 구문과 ALPHADIGIT에 대한 해당 정의를 사용합니다. 아래 ABNF에 정의되지 않은 다른 모든 규칙 이름은 [RFC3986]에 정의되어 있습니다. 모든 DID는 DID 구문 ABNF 규칙을 MUST 준수해야 합니다.

DID 구문 ABNF 규칙
did                = "did:" method-name ":" method-specific-id
method-name        = 1*method-char
method-char        = %x61-7A / DIGIT
method-specific-id = *( *idchar ":" ) 1*idchar
idchar             = ALPHA / DIGIT / "." / "-" / "_" / pct-encoded
pct-encoded        = "%" HEXDIG HEXDIG

DID 구문과 관련된 DID 메서드에 대한 요구사항은 7.1 메서드 구문 절을 참조하십시오.

3.2 DID URL 구문

DID URL은 특정 리소스에 대한 네트워크 위치 식별자입니다. 이는 DID 주체의 표현, 검증 방법, 서비스, DID 문서의 특정 부분 또는 기타 리소스와 같은 것을 검색하는 데 사용할 수 있습니다.

다음은 [RFC5234]의 구문을 사용하는 ABNF 정의입니다. 이는 3.1 DID 구문에 정의된 did 스킴을 기반으로 합니다. path-abempty, query, 그리고 fragment 구성 요소는 [RFC3986]에 정의되어 있습니다. 모든 DID URL은 DID URL 구문 ABNF 규칙을 MUST 준수해야 합니다. DID 메서드7.1 메서드 구문에 설명된 것처럼 이 규칙을 더 제한할 수 있습니다.

DID URL 구문 ABNF 규칙
did-url = did path-abempty [ "?" query ] [ "#" fragment ]
참고: 세미콜론 문자는 향후 사용을 위해 예약되어 있습니다

세미콜론(;) 문자는 DID URL 구문 규칙에 따라 사용할 수 있지만, 이 명세의 향후 버전에서는 [MATRIX-URIS]에 설명된 것처럼 매개변수의 하위 구분자로 사용할 수 있습니다. 향후 충돌을 피하기 위해 개발자는 이를 사용하지 않는 것이 좋습니다.

경로

DID 경로는 일반 URI 경로와 동일하며 RFC 3986, section 3.3path-abempty ABNF 규칙을 준수합니다. URI와 마찬가지로, 경로 의미론은 DID 메서드에 의해 지정될 수 있으며, 이는 다시 DID 컨트롤러가 그 의미론을 추가로 특수화할 수 있게 할 수 있습니다.

did:example:123456/path

쿼리

DID 쿼리는 일반 URI 쿼리와 동일하며 RFC 3986, section 3.4query ABNF 규칙을 준수합니다.

did:example:123456?versionId=1
참고: 여러 쿼리 매개변수를 포함하는 DID URL의 비교를 피하십시오

구현자는 그 목적을 위해 특별히 설계된 명세가 없는 경우, 둘 이상의 쿼리 매개변수를 가진 DID URL을 동등성 기준으로 비교하지 않는 것이 강력히 권장됩니다. 이 명세는 쿼리 매개변수에 대한 정규화 규칙을 정의하지 않으며, DID 메서드 명세 또는 애플리케이션 계층에서 정의된 쿼리 매개변수 정규화 규칙도 보편적으로 인식되는 규칙이 아닙니다.

프래그먼트

DID 프래그먼트 구문과 의미론은 일반 URI 프래그먼트와 동일하며, RFC 3986, section 3.5fragment ABNF 규칙을 준수합니다.

DID 프래그먼트DID 문서 또는 외부 리소스에 대한 메서드 독립적 참조로 사용됩니다. DID 프래그먼트 식별자의 몇 가지 예가 아래에 나와 있습니다.

예제 4: DID 문서의 고유한 검증 방법
did:example:123#public-key-1
예제 5: DID 문서의 고유한 서비스
did:example:123#service-5
참고: 표현 간 프래그먼트 의미론

상호운용성을 극대화하기 위해, 구현자는 DID 프래그먼트표현 전반에서 동일한 방식으로 해석되도록 보장할 것이 권장됩니다 (6. 표현 참조). 예를 들어, JSON Pointer [RFC6901]는 DID 프래그먼트에서 사용할 수 있지만, 비 JSON 표현 전반에서 동일한 방식으로 해석되지는 않습니다.

이 절의 의미론과 호환되며 그 위에 계층화되는 프래그먼트 식별자에 대한 추가 의미론은 미디어 유형 설명에 지정되어 있습니다(섹션 E.1 application/did 참조). DID 프래그먼트를 역참조하는 방법에 대한 정보는 탈중앙화 식별자 해석(DID Resolution) v0.3 명세를 참조하십시오.

3.2.1 상대 DID URL

상대 DID URLDID 문서 안의 URL 값 중 did:<method-name>:<method-specific-id>로 시작하지 않는 모든 URL 값입니다. 더 구체적으로 말하면, 3.1 DID 구문에 정의된 ABNF로 시작하지 않는 모든 URL 값입니다. 해당 URL은 동일한 DID 문서 안의 리소스를 참조할 것으로 예상됩니다. 상대 DID URL은 상대 경로 구성 요소, 쿼리 매개변수 및 프래그먼트 식별자를 포함할 MAY 있습니다.

상대 DID URL 참조를 해석할 때는 RFC3986 Section 5: Reference Resolution에 지정된 알고리즘을 MUST 사용해야 합니다. base URI 값은 DID 주체와 관련된 DID입니다. 5.1.1 DID 주체를 참조하십시오. schemedid입니다. authority<method-name>:<method-specific-id>의 조합이며, path, query, 그리고 fragment 값은 각각 경로, 쿼리, 그리고 프래그먼트에 정의된 값입니다.

상대 DID URL은 절대 URL을 사용하지 않고 검증 방법서비스DID 문서 안에서 참조하는 데 자주 사용됩니다. 저장 크기가 고려사항인 DID 메서드는 상대 URL을 사용하여 DID 문서의 저장 크기를 줄일 수 있습니다.

예제 6: 상대 DID URL의 예
{
  "@context": "https://www.w3.org/ns/did/v1.1",
  "id": "did:example:123456789abcdefghi",
  "verificationMethod": [{
    "id": "did:example:123456789abcdefghi#key-1",
    "type": "Multikey", // external (property value)
    "controller": "did:example:123456789abcdefghi",
    "publicKeyMultibase": "z6MkmM42vxfqZQsv4ehtTjFFxQ4sQKS2w6WR7emozFAn5cxu"
  }, ...],
  "authentication": [
    // 위의 검증 방법을 참조하는 데 사용되는 상대 DID URL
    "#key-1"
  ]
}

위 예제에서 상대 DID URL 값은 did:example:123456789abcdefghi#key-1라는 절대 DID URL 값으로 변환됩니다.

4. 데이터 모델

이 명세는 DID 문서와 그 내부 데이터 구조를 표현하는 데 사용할 수 있는 데이터 모델을 정의하며, 이는 이후 구체적 표현으로 직렬화될 수 있습니다. 이 절은 데이터 모델에 대한 상위 수준의 설명, 서로 다른 유형의 속성이 데이터 모델에서 표현되는 방식에 대한 설명, 그리고 데이터 모델을 확장하기 위한 지침을 제공합니다.

DID 문서mapentry들로 구성되며, 각 entry는 키/값 쌍으로 이루어집니다. DID 문서 데이터 모델은 5. 핵심 속성 절에 지정된 속성을 포함합니다.

DID 문서 데이터 모델의 모든 entry 키는 string입니다. 모든 entry 값은 아래 표의 데이터 유형 중 하나를 사용해 표현되며, 각 표현은 각 데이터 유형의 구체적 직렬화 형식을 지정합니다.

데이터 유형 고려사항
map Infra Standard에 지정된 것처럼, 동일한 키가 두 번 나타나지 않는 키/값 쌍의 유한한 순서 있는 시퀀스입니다. map은 Infra Standard에서 때때로 ordered map이라고도 합니다.
list Infra Standard에 지정된 항목의 유한한 순서 있는 시퀀스입니다.
set Infra Standard에 지정된 것처럼, 동일한 항목을 두 번 포함하지 않는 항목의 유한한 순서 있는 시퀀스입니다. set은 Infra Standard에서 때때로 ordered set이라고도 합니다.
datetime [XMLSCHEMA11-2]에 지정된 dateTime으로 표현할 수 있는 모든 값을 손실 없이 표현할 수 있는 날짜 및 시간 값입니다.
string Infra Standard에 지정된 것처럼, 사람이 읽을 수 있는 언어를 표현하는 데 자주 사용되는 코드 단위의 시퀀스입니다.
integer [XMLSCHEMA11-2]에 지정된 소수부가 없는 실수입니다. 상호운용성을 극대화하기 위해, 구현자는 RFC8259, Section 6: Numbers의 integer 관련 조언에 유의하는 것이 권장됩니다.
double [XMLSCHEMA11-2]에 지정된, 임의의 실수를 근사하는 데 자주 사용되는 소수부가 있는 실수입니다. 상호운용성을 극대화하기 위해, 구현자는 RFC8259, Section 6: Numbers의 double 관련 조언에 유의하는 것이 권장됩니다.
boolean Infra Standard에 정의된 것처럼 true 또는 false 중 하나인 값입니다.
null Infra Standard에 정의된 것처럼 값의 부재를 나타내는 데 사용되는 값입니다.

데이터 모델Infra Standard의 용어를 사용하여 정의된 결과로, list, map, set과 같이 하나 이상의 항목을 포함할 수 있는 속성 값은 명시적으로 순서가 있습니다. Infra Standard의 모든 list 유사 값 구조는 그 순서가 중요한지 여부와 관계없이 순서가 있습니다. 이 명세의 목적상, 달리 명시되지 않는 한, map 또는 set의 순서는 중요하지 않으며, 구현이 결정적으로 순서가 지정된 값을 생산하거나 소비할 것으로 기대되지는 않습니다.

4.1 확장성

데이터 모델은 두 가지 유형의 확장성을 지원합니다.

  1. 최대한의 상호운용성을 위해, 확장은 탈중앙화 식별자 확장 저장소를 사용하는 것이 RECOMMENDED됩니다. 새 속성 또는 기타 확장을 위해 이 메커니즘을 사용하는 것은 서로 다른 두 표현이 함께 작동할 수 있음을 보장하는 유일하게 지정된 메커니즘입니다.
  2. 표현탈중앙화 식별자 확장 저장소 사용을 요구하지 않는 메커니즘을 포함하여, 다른 확장 메커니즘을 정의할 MAY 있습니다. 이러한 확장 메커니즘은 다른 모든 적합한 표현으로의 무손실 변환을 지원해야 SHOULD 합니다. 표현을 위한 확장 메커니즘은 모든 속성과 표현 구문을 DID 문서 데이터 모델 및 그 유형 시스템으로 매핑하는 방법을 정의해야 SHOULD 합니다.
참고: 등록되지 않은 확장은 신뢰성이 더 낮습니다

두 특정 구현이 대역 외에서 합의하여 탈중앙화 식별자 확장 저장소에 기록되지 않은 상호 이해된 확장 또는 표현을 사용하는 것은 언제나 가능합니다. 그러나 그러한 구현과 더 큰 생태계 사이의 상호운용성은 덜 신뢰할 수 있습니다.

5. 핵심 속성

DIDDID 문서와 연결되며, 이는 Controlled Identifiers v1.0에 정의된 controlled identifier document의 확장입니다. DID 문서데이터 모델을 사용해 표현되며 표현으로 직렬화될 수 있습니다. 다음 절에서는 DID 문서의 속성을 정의하며, 이러한 속성이 필수인지 선택 사항인지도 포함합니다. 이러한 속성은 DID 주체와 해당 속성 값 사이의 관계를 설명합니다.

다음 표는 이 명세가 정의하는 핵심 속성에 대한 정보적 참조, 예상 값, 그리고 필수 여부를 포함합니다. 표의 속성 이름은 각 속성의 규범적 정의와 더 자세한 설명으로 링크됩니다.

참고: 서로 다른 유형의 map에서 사용되는 속성 이름

속성 이름 id, type, 그리고 controller는 서로 다른 유형의 map에 존재할 수 있으며 제약 조건이 다를 수 있습니다. 예를 들어, DID 문서의 최상위 수준에 있는 id는 DID여야 하지만, service mapid는 URL일 수 있습니다.

속성 필수? 값 제약 조건 정의
id string이며, 3.1 DID 구문 절에 정의된 규칙을 준수합니다. 5.1.1 DID 주체 절.
controller 아니요 string 또는 set of string이며, 각각 3.1 DID 구문 절에 정의된 규칙을 준수합니다. 5.1.2 DID 컨트롤러 절.
alsoKnownAs 아니요 set of string이며, 각각 URL 구문 또는 3.1 DID 구문 절을 준수합니다. Controlled Identifiers v1.0 명세의 Section 2.1.3: Also Known As.
service 아니요 set of service map입니다. Controlled Identifiers v1.0 명세의 Section 2.1.4: Services.
verificationMethod 아니요 set of verification method map입니다. 5.2 검증 방법 절.
authentication 아니요 데이터의 set이며, 각 요소는 3.1 DID 구문 절에 정의된 규칙을 준수하는 string이거나, 5.2 검증 방법 절에 정의된 verification method 규칙을 준수하는 map입니다. Controlled Identifiers v1.0 명세의 Section 2.3.1: Authentication5.2 검증 방법 절.
assertionMethod 아니요 데이터의 set이며, 각 요소는 3.1 DID 구문 절에 정의된 규칙을 준수하는 string이거나, 5.2 검증 방법 절에 정의된 verification method 규칙을 준수하는 map입니다. Controlled Identifiers v1.0 명세의 Section 2.3.2: Assertion5.2 검증 방법 절.
keyAgreement 아니요 데이터의 set이며, 각 요소는 3.1 DID 구문 절에 정의된 규칙을 준수하는 string이거나, 5.2 검증 방법 절에 정의된 verification method 규칙을 준수하는 map입니다. Controlled Identifiers v1.0 명세의 Section 2.3.3: Key Agreement5.2 검증 방법 절.
capabilityInvocation 아니요 데이터의 set이며, 각 요소는 3.1 DID 구문 절에 정의된 규칙을 준수하는 string이거나, 5.2 검증 방법 절에 정의된 verification method 규칙을 준수하는 map입니다. Controlled Identifiers v1.0 명세의 Section 2.3.4: Capability Invocation5.2 검증 방법 절.
capabilityDelegation 아니요 데이터의 set이며, 각 요소는 3.1 DID 구문 절에 정의된 규칙을 준수하는 string이거나, 5.2 검증 방법 절에 정의된 verification method 규칙을 준수하는 map입니다. Controlled Identifiers v1.0 명세의 Section 2.3.5: Capability Delegation5.2 검증 방법 절.

검증 방법 속성

속성 필수? 값 제약 조건 정의
id string이며, 3.2 DID URL 구문의 규칙을 준수합니다. Controlled Identifiers v1.0 명세의 Section 2.1.1: Subjects5.1 식별자 절.
type string입니다. Controlled Identifiers v1.0 명세의 Section 2.2: Verification Methods.
controller string이며, 3.1 DID 구문의 규칙을 준수합니다. Controlled Identifiers v1.0 명세의 Section 2.2: Verification Methods.
publicKeyMultibase 아니요 Multibase로 인코딩된 공개 키를 준수하는 string입니다. Controlled Identifiers v1.0 명세의 Section 2.2.2: Multikey.
publicKeyJwk 아니요 JSON Web Key를 나타내는 map입니다. Controlled Identifiers v1.0 명세의 Section 2.2.3: JsonWebKey.

서비스 속성

속성 필수? 값 제약 조건 정의
id URL Standard 표준 또는 3.1 DID 구문 절의 규칙을 준수하는 string입니다. Controlled Identifiers v1.0 명세의 Section 2.1.1: Subjects.
type string 또는 set of string입니다. Controlled Identifiers v1.0 명세의 Section 2.1.4: Services.
serviceEndpoint 단일 string, 단일 map, 또는 하나 이상의 string 및/또는 map으로 구성된 set입니다. 각 string 값은 URL Standard에 적합한 유효한 URL이어야 MUST 합니다. Controlled Identifiers v1.0 명세의 Section 2.1.4: Services.

5.1 식별자

이 절은 DID 문서DID 주체DID 컨트롤러의 식별자를 포함하는 메커니즘을 설명합니다.

5.1.1 DID 주체

특정 DID 주체에 대한 DIDDID 문서id 속성을 사용해 표현됩니다. 이 속성은 Controlled Identifiers v1.0 명세의 Section 2.1.1: Subjects에 정의되어 있으며, 이 명세에서 3.1 DID 구문 절에 정의된 탈중앙화 식별자를 포함하도록 확장됩니다.

{
  "id": "did:example:123456789abcdefghijk"
}
참고: 중간 표현

DID 메서드 명세는 탈중앙화 식별자검증 가능 데이터 레지스트리에 등록되는 경우 또는 DID 리졸버DID 해석을 수행하는 경우와 같이, DID 문서의 중간 표현을 만들 수 있습니다. 이러한 중간 표현은 id 값을 포함하지 않을 수도 있고, 특정 id 속성에 대한 임시 값을 포함할 수도 있습니다. DID 문서가 완전히 해석되면, 최종 id 값이 결정되어 DID 문서 전체의 임시 값 대신 배치됩니다.

5.1.2 DID 컨트롤러

DID 컨트롤러DID 문서를 변경할 권한이 있는 엔터티입니다. 이 속성은 Controlled Identifiers v1.0 명세의 Section 2.1.2: Controllers에 정의되어 있으며, 이 명세에서 3.1 DID 구문 절에 정의된 DID를 포함하도록 확장됩니다. DID 컨트롤러를 승인하는 과정은 DID 메서드에 의해 정의됩니다.

예제 8: controller 속성이 있는 DID 문서
{
  "@context": "https://www.w3.org/ns/did/v1.1",
  "id": "did:example:123456789abcdefghi",
  "controller": "did:example:bcehfew7h32f32h7af3"
}

5.1.3 식별자 제한

DID 문서에서 DID 주체 또는 DID 컨트롤러를 식별하는 데 사용되는 식별자는 쿼리 매개변수나 프래그먼트 식별자를 사용할 수 없습니다. 구현자는 이 요구사항을 명확히 하는 3.1 DID 구문 절의 허용 문자 목록에 특히 주의를 기울이는 것이 권장됩니다. 해당 구문은 ? 문자나 # 문자를 포함하지 않습니다. 이는 DID 문서에서 verification method 또는 service를 식별하는 데 사용되는 식별자와 대조적입니다. 이들은 쿼리 매개변수와 프래그먼트 식별자의 사용을 허용하는 3.2 DID URL 구문 절의 구문 규칙을 따릅니다. 그럼에도, DID 생태계를 위해 만들어진 장기적인 정식 식별자에서 쿼리 매개변수를 사용하는 것은 DID 해석 소프트웨어의 복잡성을 증가시키고 잠재적으로 더 큰 보안 공격 표면으로 이어질 수 있으므로 권장되지 않습니다. 프래그먼트 식별자 또한 특정 DID 문서 내에서 고유할 것으로 기대되며, 구현자는 같은 DID 문서 내의 서로 다른 두 verification method와 같이, 시간이 지나면서 서로 다른 리소스를 가리키도록 재사용하지 않는 것이 권장됩니다.

5.2 검증 방법

DID 문서Controlled Identifiers v1.02.2: Verification Methods 절에 정의된 verification method를 표현할 수 있습니다. 단, (a) id 값은 3.2 DID URL 구문 절 또는 3.2.1 상대 DID URL 절을 준수해야 MUST 하며, (b) controller 값은 3.1 DID 구문 절을 준수해야 MUST 한다는 추가 제한이 있습니다. verification method에 대한 설명은 Controlled Identifiers v1.0 명세의 Section 2.2: Verification Methods를 참조하십시오.

5.3 검증 관계

DID 문서Controlled Identifiers v1.0 명세의 Section 2.3: Verification Relationships에 정의된 verification relationship를 표현할 수 있습니다. verification method에 대한 설명은 Controlled Identifiers v1.0 명세의 Section 2.3: Verification Relationships를 참조하십시오.

5.4 서비스

DID 문서Controlled Identifiers v1.0 명세의 Section 2.1.4: Services에 정의된 service를 표현할 수 있습니다. service에서 사용되는 식별자는 3.1 DID 구문 절 또는 3.2 DID URL 구문 절에 따라 표현될 수 있습니다. service에 대한 설명은 Controlled Identifiers v1.0 명세의 Section 2.1.4: Services를 참조하십시오.

6. 표현

이 명세에서 DID 문서의 구체적 직렬화를 표현이라고 합니다. 표현생산이라고 하는 과정을 통해 데이터 모델을 직렬화하여 생성됩니다. 표현소비라고 하는 과정을 통해 데이터 모델로 변환됩니다. 생산소비 과정은 정보를 하나의 표현에서 다른 표현으로 변환할 수 있게 합니다. 이 명세는 JSON을 위한 단일 표현을 정의하며, 이는 JSON-LD 처리를 수행하는 처리기와도 호환됩니다. 다음 절에서는 생산소비에 대한 일반 규칙과 JSON 표현을 정의합니다.

6.1 생산과 소비

이 명세에서 정의된 표현 외에도, 구현자는 각각의 표현이 적절히 명시되어 있다면(여기에는 DID Extensions 저장소 [DID-EXTENSIONS]에 나열되지 않은 속성의 상호운용 가능한 처리 규칙 포함), 다른 표현을 사용할 수 있습니다. 자세한 내용은 4.1 확장성을 참조하십시오.

모든 표현에 대한 요구사항은 다음과 같습니다.

  1. 표현4. 데이터 모델에 지정된 모든 데이터 유형에 대해 결정적인 생산 및 소비 규칙을 정의해야 MUST 합니다.
  2. 표현은 IANA에 등록된 미디어 유형과 고유하게 연결되어야 MUST 합니다.
  3. 표현프래그먼트에 정의된 프래그먼트 처리 규칙에 적합한, 해당 미디어 유형의 프래그먼트 처리 규칙을 정의해야 MUST 합니다.
  4. 표현데이터 모델 데이터 유형의 어휘적 표현을 사용하는 것이 SHOULD 됩니다. 예를 들어, JSON과 JSON-LD는 datetime을 표현하기 위해 XML Schema dateTime 어휘 직렬화를 사용합니다. 표현소비 과정이 다시 데이터 모델로 손실 없이 변환되는 한, 다른 어휘 직렬화를 사용하여 데이터 모델 데이터 유형을 직렬화하도록 선택할 MAY 있습니다. 예를 들어, 일부 CBOR 기반 표현은 Unix epoch 이후의 초 수를 나타내는 정수를 사용하여 datetime 값을 표현합니다.
  5. 표현생산소비 과정 중 사용하기 위해 표현별 항목 map에 저장되는 표현별 항목을 정의할 MAY 있습니다. 이러한 항목은 소비하거나 생산할 때 손실 없는 변환을 보장하는 데 도움을 주기 위해 사용됩니다.
  6. 상호운용성을 극대화하기 위해, 표현 명세 작성자는 자신의 표현을 DID Extensions 저장소 [DID-EXTENSIONS]에 등록하는 것이 SHOULD 됩니다.

모든 적합한 생산자에 대한 요구사항은 다음과 같습니다.

  1. 적합한 생산자생산 과정의 입력으로 DID 문서 데이터 모델표현별 항목 map을 받아야 MUST 합니다. 적합한 생산자생산 과정의 입력으로 추가 옵션을 받을 MAY 있습니다.
  2. 적합한 생산자는 생산되는 표현에 대해 명시적 처리 규칙이 없는 DID 문서 데이터 모델의 모든 항목과 표현별 항목 map을, 오직 해당 표현의 데이터 유형 처리 규칙만 사용하여 직렬화하고, 생산 과정이 완료된 후 직렬화를 반환해야 MUST 합니다.
  3. 적합한 생산자생산 과정이 완료된 후 해당 표현과 연결된 미디어 유형 string을 반환해야 MUST 합니다.
  4. 적합한 생산자는 부적합한 DID 또는 DID 문서를 생산해서는 MUST NOT 안 됩니다.

모든 적합한 소비자에 대한 요구사항은 다음과 같습니다.

  1. 적합한 소비자소비 과정의 입력으로 표현과 미디어 유형 string을 받아야 MUST 합니다. 적합한 소비자소비 과정의 입력으로 추가 옵션을 받을 MAY 있습니다.
  2. 적합한 소비자는 미디어 유형 입력 string을 사용하여 DID 문서표현을 결정해야 MUST 합니다.
  3. 적합한 소비자는 알려진 모든 표현 전반의 표현별 항목을 감지하고, 소비 과정이 완료된 후 반환되는 표현별 항목 map에 해당 항목을 넣어야 MUST 합니다. 알려진 모든 표현별 항목 목록은 DID Extensions 저장소 [DID-EXTENSIONS]에서 확인할 수 있습니다.
  4. 적합한 소비자는 소비되는 표현에 대해 명시적 처리 규칙이 없는 모든 비표현별 항목을, 오직 해당 표현의 데이터 유형 처리 규칙만 사용하여 DID 문서 데이터 모델에 추가하고, 소비 과정이 완료된 후 DID 문서 데이터 모델을 반환해야 MUST 합니다.
  5. 적합한 소비자는 부적합한 DID 또는 DID 문서를 소비할 때 오류를 발생시켜야 MUST 합니다.

JSON 및 JSON-LD를 포함하여 데이터 모델의 표현이 어떻게 생산되고
소비되는지를 보여 주는 다이어그램.
그림 3 표현의 생산과 소비. 함께 보기: 서술형 설명.

다이어그램의 왼쪽 위 사분면에는 회색 점선 윤곽의 직사각형이 있으며, 그 안에는 파란색 윤곽의 직사각형 두 개가 위아래로 들어 있습니다. 위쪽의 더 큰 직사각형에는 파란색으로 "Core Properties"라는 레이블이 있고, 다음 INFRA 표기법이 포함됩니다.

«[
  "id""example:123",
  "verificationMethod" → « «[
    "id": "did:example:123#keys-1",
    "controller": "did:example:123",
    "type": "Multikey",
    "publicKeyMultibase": "z6MkmM42vxfqZQsv4ehtTjFFxQ4sQKS2w6WR7emozFAn5cxu"
    ]» »,
  "authentication" → «
    "did:example:123#keys-1"
  »
]»
아래쪽의 더 작은 직사각형에는 파란색으로 "Core Representation-specific Entries (JSON-LD)"라는 레이블이 있으며, 다음 고정폭 INFRA 표기법이 포함됩니다.
«[ "@context""https://www.w3.org/ns/did/v1.1" ]»

회색 윤곽의 직사각형에서 세 쌍의 화살표가 서로 다른 세 개의 검은색 윤곽 직사각형으로 뻗어 있습니다. 하나는 다이어그램의 오른쪽 위, 하나는 오른쪽 아래, 하나는 왼쪽 아래에 있습니다. 각 화살표 쌍은 회색 윤곽 직사각형에서 해당 검은색 윤곽 직사각형으로 향하는 "produce"라는 레이블의 파란색 화살표 하나와, 반대 방향을 가리키는 "consume"이라는 레이블의 빨간색 화살표 하나로 구성됩니다. 오른쪽 위의 검은색 윤곽 직사각형에는 "application/did+cbor"라는 레이블이 있고 16진수 데이터가 들어 있습니다. 오른쪽 아래의 직사각형에는 "application/did"라는 레이블이 있으며, 다음 JSON 데이터가 포함됩니다.

{
  "id": "did:example:123",
  "verificationMethod": [{
    "id": "did:example:123#keys-1",
    "controller": "did:example:123",
    "type": "Multikey",
    "publicKeyMultibase": "z6MkmM42vxfqZQsv4ehtTjFFxQ4sQKS2w6WR7emozFAn5cxu"
  }],
  "authentication": [
    "did:example:123#keys-1"
  ]
}

왼쪽 아래의 직사각형에는 "application/did"라는 레이블이 있으며, 다음 JSON-LD 데이터가 포함됩니다.

{
  "@context": "https://www.w3.org/ns/did/v1.1",
  "id": "did:example:123",
  "verificationMethod": [{
    "id": "did:example:123#keys-1",
    "controller": "did:example:123",
    "type": "Multikey",
    "publicKeyMultibase": "z6MkmM42vxfqZQsv4ehtTjFFxQ4sQKS2w6WR7emozFAn5cxu"
  }],
  "authentication": [
    "did:example:123#keys-1"
  ]
}
참고: 표현 간 변환

구현은 원본 표현에 소비 규칙을 적용하여 데이터 모델을 얻은 다음 생산 규칙을 사용하여 데이터 모델을 대상 표현으로 직렬화하거나, 동일한 대상 표현을 결과로 만드는 다른 메커니즘을 사용함으로써 표현 간에 변환할 것으로 기대됩니다.

6.2 JSON

이 절은 JSON 표현에 대한 생산소비 규칙을 정의합니다.

6.2.1 생산

DID 문서, DID 문서 데이터 구조 및 표현별 항목 map은 다음 생산 규칙에 따라 JSON 표현으로 직렬화되어야 MUST 합니다.

데이터 유형 JSON 표현 유형
map JSON Object입니다. 각 entry는 entry 키를 JSON String 멤버 이름으로 사용하고, entry 값은 이 표에 정의된 대로 그 유형에 따라 JSON Object의 멤버로 직렬화됩니다.
list JSON Array입니다. list의 각 요소는 이 표에 정의된 대로 그 유형에 따라, 순서대로 배열의 값으로 직렬화됩니다.
set JSON Array입니다. set의 각 요소는 이 표에 정의된 대로 그 유형에 따라, 순서대로 배열의 값으로 추가됩니다.
datetime UTC 00:00:00으로 정규화되고 초 미만 소수 정밀도 없이 XML Datetime으로 직렬화된 JSON String입니다. 예: 2020-12-20T19:17:47Z.
string JSON String입니다.
integer 소수점 또는 소수부가 없는 JSON Number입니다.
double 소수점과 소수부가 있는 JSON Number입니다.
boolean JSON Boolean입니다.
null JSON null literal입니다.

JSON 표현을 생산하는 적합한 생산자를 만드는 모든 구현자는 자신의 알고리즘이 [INFRA] 명세의 JSON 직렬화 규칙 및 JSON [RFC8259] 명세의 숫자에 관한 정밀도 권고사항과 정렬되도록 보장하는 것이 권고됩니다.

DID 문서의 모든 entry는 루트 JSON Object에 포함되어야 MUST 합니다. entry는 위 목록의 값 표현 규칙에 따르는 추가 데이터 하위 구조를 포함할 MAY 있습니다. DID 문서를 직렬화할 때, 적합한 생산자는 하위 애플리케이션에 application/did의 미디어 유형을 지정해야 MUST 합니다.

예제 9: JSON 표현의 DID 문서 예
{
  "@context": "https://www.w3.org/ns/did/v1.1",
  "id": "did:example:123456789abcdefghi",
  "authentication": [{
    "id": "did:example:123456789abcdefghi#keys-1",
    "type": "Multikey",
    "controller": "did:example:123456789abcdefghi",
    "publicKeyMultibase": "z6MkmM42vxfqZQsv4ehtTjFFxQ4sQKS2w6WR7emozFAn5cxu"
  }]
}

6.2.2 소비

DID 문서 및 DID 문서 데이터 구조의 JSON 표현은 다음 소비 규칙에 따라 데이터 모델로 역직렬화되어야 MUST 합니다.

JSON 표현 유형 데이터 유형
JSON Object map입니다. JSON Object의 각 멤버는 map에 entry로 추가됩니다. 각 entry 키는 JSON Object 멤버 이름으로 설정됩니다. 각 entry 값은 이 표에 정의된 JSON 표현 유형에 따라 JSON Object 멤버 값을 변환하여 설정됩니다. JSON Object는 순서를 지정하지 않으므로, 삽입 순서는 보장되지 않습니다.
JSON Array이며 데이터 모델 entry 값이 list이거나 알려지지 않은 경우 list입니다. JSON Array의 각 값은 이 표에 정의된 대로 배열 값의 JSON 표현 유형을 기반으로 변환되어 순서대로 list에 추가됩니다.
JSON Array이며 데이터 모델 entry 값이 set인 경우 set입니다. JSON Array의 각 값은 이 표에 정의된 대로 배열 값의 JSON 표현 유형을 기반으로 변환되어 순서대로 set에 추가됩니다.
JSON String이며 데이터 모델 entry 값이 datetime인 경우 datetime입니다.
JSON String이며, 데이터 모델 entry 값 유형이 string이거나 알려지지 않은 경우 string입니다.
소수점 또는 소수부가 없는 JSON Number integer입니다.
소수점과 소수부가 있는 JSON Number, 또는 소수부 포함 여부와 관계없이 entry 값이 double인 경우 double입니다.
JSON Boolean boolean입니다.
JSON null literal null 값입니다.

적합한 생산자 또는 적합한 소비자를 만드는 모든 구현자는 자신의 알고리즘이 [INFRA] 명세의 JSON 변환 규칙 및 JSON [RFC8259] 명세의 숫자에 관한 정밀도 권고사항과 정렬되도록 보장하는 것이 권고됩니다.

적합한 소비자에게 미디어 유형 정보가 제공되고 미디어 유형 값이 application/did인 경우, 소비되는 데이터 구조는 DID 문서이며, 루트 요소는 객체의 모든 멤버가 DID 문서의 entry인 JSON Object여야 MUST 합니다. 루트 요소가 JSON Object가 아닌 DID 문서를 소비하는 JSON 표현적합한 소비자는 오류를 보고해야 MUST 합니다.

6.2.3 JSON-LD 처리기

JSON-LDLinked Data를 직렬화하는 데 사용되는 JSON 기반 형식입니다. 일부 구현은 표준 JSON-LD 처리 알고리즘을 사용하여 DID 문서를 처리할 것으로 기대됩니다. 상호운용성을 극대화하기 위해, 구현자는 표준을 준수하는 라이브러리를 사용한 JSON-LD 처리가 방해받지 않도록 보장하는 것이 강력히 권고됩니다. 표준을 준수하는 라이브러리를 사용한 JSON-LD 처리가 수행되든 수행되지 않든 DID 문서의 의미론은 동일합니다. 의미론의 차이는 구현 또는 DID 메서드 명세의 오류입니다.

JSON-LD 처리가 발생하려면, @context 속성이 JSON-LD 1.1 명세에 지정된 규칙에 따라 지정되어야 MUST 합니다.

@context
JSON-LD Contextstring이거나, string 및/또는 ordered map의 임의 조합을 포함하는 list입니다.

DID 문서, DID 문서 데이터 구조 및 표현별 항목 map6.2 JSON에 정의된 JSON 표현 생산 규칙에 따라 JSON 표현으로 직렬화되어야 MUST 합니다.

JSON 표현 생산 규칙을 사용하는 것에 더해, 생산은 @context entry를 포함해야 MUST 합니다. @context의 직렬화된 값은 JSON String https://www.w3.org/ns/did/v1.1이거나, 첫 번째 항목이 JSON String https://www.w3.org/ns/did/v1.1이고 이후 항목들이 JSON 생산 규칙에 따라 직렬화되는 JSON Array여야 MUST 합니다.

예제 10: 단순 @context entry의 유효한 직렬화
{
  "@context": "https://www.w3.org/ns/did/v1.1",
  ...
}
예제 11: 계층화된 @context entry의 유효한 직렬화
{
  "@context": [
    "https://www.w3.org/ns/did/v1.1",
    "https://did-method-extension.example/v1"
  ],
  ...
}

JSON-LD로 처리되도록 의도된 표현을 생산하거나 소비하는 적합한 소비자를 만드는 모든 구현자는 자신의 알고리즘이 유효한 JSON-LD 문서를 생산하도록 보장하는 것이 권고됩니다. 유효하지 않은 JSON-LD 문서는 JSON-LD 처리기가 중단하고 오류를 보고하게 합니다.

서로 다른 표현 간의 상호운용성을 달성하기 위해, 모든 JSON-LD Context와 그 용어는 탈중앙화 식별자 확장 저장소에 등록되는 것이 SHOULD 됩니다.

JSON-LD 표현을 생성하는 적합한 생산자는, 적합한 소비자가 알 수 없는 용어를 제거할 것으로 기대되므로, @context를 통해 정의되지 않은 용어를 포함하는 DID 문서를 생산해서는 SHOULD NOT 안 됩니다. DID 문서의 JSON-LD 표현을 직렬화할 때, 적합한 생산자는 하위 애플리케이션에 application/did의 미디어 유형을 지정해야 MUST 합니다.

JSON-LD 표현을 처리하는 적합한 소비자@context를 통해 정의되지 않은 모든 용어를 DID 문서에서 제거하는 것이 SHOULD 됩니다.

6.2.4 원격 리소스 무결성

구현은 https://www.w3.org/ns/did/v1.1에 위치한 기본 컨텍스트 값이 이미 검색된 것으로 처리해야 MUST 합니다. 다음 값은 기본 컨텍스트 파일의 16진수로 인코딩된 SHA2-256 다이제스트 값입니다. ea216ecc1cb02cd39b693dba2250141e270ba0bf95890be107dd9a9e8e43de85. 최신 Unix 명령줄 인터페이스에서 다음 명령을 실행하여 위의 암호학적 다이제스트를 확인할 수 있습니다. curl -s https://www.w3.org/ns/did/v1.1 | openssl dgst -sha256.

구현자는 URL을 통해 링크된 리소스와 같이 DID 문서 내부에서 참조되는 다른 데이터가 기본적으로 암호학적으로 보호되지 않는다는 점을 경고받습니다. 영구적으로 캐시된 파일 및/또는 암호학적 해시를 사용하여 DID 문서의 보안에 중요한 모든 URL에 동일한 종류의 보호가 제공되도록 보장하는 것이 모범 사례로 간주됩니다. 궁극적으로 링크된 외부 콘텐츠의 암호학적 다이제스트를 알면, 애플리케이션은 해당 콘텐츠가 DID 컨트롤러가 의도한 것과 동일한지 확인할 수 있습니다.

참고: 해시 값 변경이 감지되면 정오표를 참조하십시오

이 명세에서 관련 암호학적 해시 값을 가진 파일이 변경될 가능성은 극히 낮습니다. 그러나 명세에서 중대한 정오가 발견되고 생태계 안정성을 보장하기 위해 수정이 필요한 경우, 암호학적 해시 값이 변경될 수 있습니다. 따라서 해당 파일의 HTTP 캐시 시간은 무한대로 설정되지 않으며, 구현자는 암호학적 해시 값의 변경이 감지되면 정오표를 확인하는 것이 권고됩니다.

6.3 미디어 유형

[RFC6838]에 정의된 미디어 유형은 DID 문서를 표현하는 데 사용되는 구문과 기타 유용한 처리 지침을 식별합니다.

이 명세의 데이터 모델을 표현하는 데 사용되는 구문은 미디어 유형으로 식별되는 것이 SHOULD 되며, DID 문서와 함께 미디어 유형을 정의하거나 사용할 때는 이 절에 설명된 관례를 따르는 것이 SHOULD 됩니다.

핵심 데이터 모델과 관련된 미디어 유형은 하나이며, 이는 E. IANA 고려사항 절에 나열되어 있습니다. application/did.

6.3.1 미디어 유형 정밀도

이 절은 비규범적입니다.

때때로 개발자나 시스템은 정밀도가 낮은 미디어 유형을 사용하여 DID 문서를 전달할 수 있습니다. 정밀도가 낮은 미디어 유형을 사용하는 이유 중 일부는 다음과 같습니다.

  • 웹 서버가 파일 확장자를 사용할 수 없고 미디어 유형을 확인할 수 없을 때 text/plain 또는 application/octet-stream을 기본값으로 사용합니다.
  • 개발자가 파일의 콘텐츠보다 덜 구체적인 미디어 유형으로 이어지는 파일 확장자를 추가합니다. 예를 들어, .jsonapplication/json 미디어 유형이 될 수 있고, .jsonldapplication/ld+json 미디어 유형이 될 수 있습니다.
  • 프로토콜이 특정 트랜잭션에 대해 덜 정밀한 미디어 유형을 요구합니다. 예를 들어, application/did 대신 application/json이 사용됩니다.

사용된 미디어 유형이 주어진 프로토콜에서 허용되는 경우, 페이로드에서 의도된 미디어 유형을 확인할 수 있다면 구현자는 오류를 발생시키지 않는 것이 권장됩니다. 예를 들어, 애플리케이션이 application/did 미디어 유형과 관련된 규칙을 준수하는 페이로드만 허용하지만, 페이로드에 정밀도가 낮은 application/json 또는 application/ld+json 태그가 붙어 있다면, 애플리케이션은 해당 페이로드가 더 높은 정밀도의 미디어 유형에도 적합한지 확인하기 위해 다음 단계를 수행할 수 있습니다.

  1. 페이로드를 JSON 문서로 파싱합니다.
  2. @context 속성의 첫 번째 요소가 https://www.w3.org/ns/did/v1.1과 일치하는지 확인합니다.
  3. JSON 문서에 3.1 DID 구문 절의 규칙을 준수하는 식별자를 포함하는 최상위 id 속성이 있으면 application/did 미디어 유형으로 가정합니다.

가능하면 구현자는 이 명세가 정의하는 모든 페이로드에 대해 가장 정밀한(가장 높은 정밀도의) 미디어 유형을 사용하는 것이 권고됩니다. 또한 구현자는 낮은 정밀도의 미디어 유형으로 태그가 붙은 페이로드가 더 높은 정밀도 유형으로 태그를 붙이는 데 필요한 규칙을 충족하지 않는다는 의미가 아님을 인식하는 것이 권고됩니다. 마찬가지로, 더 높은 정밀도의 미디어 유형으로 태그가 붙은 페이로드가 해당 미디어 유형과 관련된 요구사항을 충족한다는 의미도 아닙니다. 페이로드의 수신자는 관련된 미디어 유형과 관계없이, 주어진 시스템에서 사용하는 데 필요한 요구사항에 페이로드가 적합한지 보장하기 위해 적절한 검사를 수행할 것으로 기대됩니다.

HTTP 클라이언트와 서버는 Accept: 헤더와 콘텐츠 유형을 나타낼 때 DID 문서와 관련된 미디어 유형을 사용합니다. 구현자는 HTTP 서버가 Accept: 헤더를 무시하고 다른 콘텐츠 유형을 반환하거나, 415 Unsupported Media Type과 같은 오류 코드를 반환할 수 있음을 경고받습니다.

7. 메서드

적합한 DID 메서드는 구현자가 이 명세에서 설명하는 기능을 어떻게 실현할 수 있는지를 정의합니다. DID 메서드는 종종 특정 검증 가능 데이터 레지스트리와 연결됩니다. 새로운 DID 메서드는 동일한 DID 메서드의 서로 다른 구현 간 상호운용성을 가능하게 하기 위해 자체 명세에서 정의됩니다.

개념적으로, 이 명세와 DID 메서드 명세 사이의 관계는 IETF의 일반 URI 명세 [RFC3986]와 http 스킴 [RFC9110]과 같은 특정 URI 스킴 [IANA-URI-SCHEMES] 사이의 관계와 유사합니다. 특정 DID 스킴을 정의하는 것 외에도, DID 메서드 명세는 특정 유형의 검증 가능 데이터 레지스트리를 사용하여 DIDDID 문서를 생성, 해석, 업데이트 및 비활성화하는 메커니즘도 정의합니다. 또한 DID와 관련된 모든 구현 고려사항뿐 아니라 보안 및 개인정보 보호 고려사항도 문서화합니다.

이 절은 DID 메서드 명세를 작성하기 위한 요구사항을 지정합니다.

7.1 메서드 구문

메서드별 DID 구문을 정의할 때 모든 DID 메서드 명세에 대한 요구사항은 다음과 같습니다.

  1. DID 메서드 명세는 3.1 DID 구문method-name 규칙에 지정된 것처럼 정확히 하나의 메서드 이름으로 식별되는 정확히 하나의 메서드별 DID 스킴을 정의해야 MUST 합니다.
  2. DID 메서드 명세는 DIDmethod-specific-id 구성 요소를 생성하는 방법을 지정해야 MUST 합니다.
  3. DID 메서드 명세는 method-specific-id 값의 대소문자 민감성과 정규화를 정의해야 MUST 합니다.
  4. method-specific-id 값은 DID 메서드 내에서 고유해야 MUST 합니다. method-specific-id 값 자체는 전역적으로 고유할 수 있습니다.
  5. DID 메서드가 생성한 모든 DID는 전역적으로 고유해야 MUST 합니다.
  6. method-name 충돌 가능성을 줄이기 위해, DID 메서드 명세는 DID Extensions 저장소 [DID-EXTENSIONS]에 등록되는 것이 SHOULD 됩니다.
  7. DID 메서드는 여러 method-specific-id 형식을 정의할 MAY 있습니다.
  8. method-specific-id 형식은 콜론을 포함할 MAY 있습니다. 콜론의 사용은 method-specific-id ABNF 규칙을 구문적으로 준수해야 MUST 합니다.
  9. DID 메서드 명세는 경로의 일반 규칙보다 더 제한적인 DID 경로에 대한 ABNF 규칙을 지정할 MAY 있습니다.
  10. DID 메서드 명세는 이 절의 일반 규칙보다 더 제한적인 DID 쿼리에 대한 ABNF 규칙을 지정할 MAY 있습니다.
  11. DID 메서드 명세는 이 절의 일반 규칙보다 더 제한적인 DID 프래그먼트에 대한 ABNF 규칙을 지정할 MAY 있습니다.
참고: method-specific-id의 콜론

method-specific-id에서 콜론의 의미는 전적으로 메서드별입니다. 콜론은 DID 메서드에서 계층적으로 분할된 이름공간을 설정하거나, 검증 가능 데이터 레지스트리의 특정 인스턴스 또는 부분을 식별하거나, 기타 목적을 위해 사용될 수 있습니다. 구현자는 모든 DID 메서드에 일반적으로 적용되는 콜론과 관련된 의미나 동작을 가정하지 않는 것이 권고됩니다.

7.2 메서드 작업

메서드 작업을 정의할 때 모든 DID 메서드 명세에 대한 요구사항은 다음과 같습니다.

  1. DID 메서드 명세는 필요한 모든 암호학적 과정을 포함하여 모든 작업을 실행하기 위한 권한 부여가 어떻게 수행되는지를 정의해야 MUST 합니다.
  2. DID 메서드 명세는 DID 컨트롤러DID와 그 관련 DID 문서를 생성하는 방법을 지정해야 MUST 합니다.
  3. DID 메서드 명세는 DID 리졸버DID를 사용해 DID 문서를 해석하는 방법을 지정해야 MUST 하며, 여기에는 DID 리졸버가 응답의 진위를 검증할 수 있는 방법도 포함됩니다.
  4. DID 메서드 명세는 DID 문서에 대한 업데이트가 무엇으로 구성되는지와 DID 컨트롤러DID 문서를 업데이트할 수 있는 방법을 지정하거나, 업데이트가 불가능하다고 명시해야 MUST 합니다.
  5. DID 메서드 명세는 DID 컨트롤러DID를 비활성화할 수 있는 방법을 지정하거나, 비활성화가 불가능하다고 명시해야 MUST 합니다.

작업을 수행하기 위해 권한 부여를 수행하는 당사자의 권한은 DID 메서드에 따라 다릅니다. 예를 들어, DID 메서드는 다음을 할 수 있습니다 —

메서드 작업을 실행할 때, DID 메서드는 필요한 모든 데이터 구조를 사용할 수 있습니다. 여기에는 중간, 부분 또는 임시 DID 문서가 포함될 수 있습니다. 단, 이들은 DID 메서드 내부에 유지되어야 하며, 메서드 작업이 반환하는 DID 문서는 1.4 적합성에 정의된 대로 완전히 적합해야 합니다.

7.3 보안 요구사항

보안 고려사항 절을 작성할 때 모든 DID 메서드 명세에 대한 요구사항은 다음과 같습니다.

  1. DID 메서드 명세는 DID 작업에 대해 RFC3552: Writing Security Considerations Sections에 제공된 모든 지침과 규범적 문구를 따라야 MUST 합니다.
  2. 보안 고려사항 절은 DID 메서드 명세에 정의된 DID 작업에 대해 다음 형태의 공격을 문서화해야 MUST 합니다. 도청, 재전송, 메시지 삽입, 삭제, 수정, 서비스 거부, 증폭, 그리고 중간자 공격입니다. 알려진 다른 공격 형태도 문서화하는 것이 SHOULD 됩니다.
  3. 보안 고려사항 절은 관련 프로토콜의 손상, 잘못된 구현, 또는 위협 완화가 배포된 후의 암호로부터 발생하는 위험과 같은 잔여 위험을 논의해야 MUST 합니다.
  4. 보안 고려사항 절은 7.2 메서드 작업에서 요구하는 모든 작업에 대해 무결성 보호와 업데이트 인증을 제공해야 MUST 합니다.
  5. 인증이 관련되는 경우, 특히 사용자-호스트 인증의 경우, 인증 방법의 보안 특성이 명확히 문서화되어야 MUST 합니다.
  6. 보안 고려사항 절은 DID가 고유하게 할당되었음을 증명하는 정책 메커니즘을 논의해야 MUST 합니다.
  7. 메서드별 엔드포인트 인증은 논의되어야 MUST 합니다. DID 메서드가 다양한 네트워크 토폴로지를 가진 DLT를 사용하며, 필요한 컴퓨팅 리소스를 줄이기 위해 때때로 light node 또는 thin client 구현으로 제공되는 경우, DID 메서드 구현에 사용할 수 있는 토폴로지의 보안 가정이 논의되어야 MUST 합니다.
  8. 프로토콜이 암호학적 보호 메커니즘을 포함하는 경우, DID 메서드 명세는 데이터의 어느 부분이 어떤 보호로 보호되는지를 명확히 나타내야 MUST 하며, 암호학적 보호가 취약할 수 있는 공격 유형의 예를 제시하는 것이 SHOULD 됩니다. 예로는 무결성만, 기밀성, 엔드포인트 인증이 있습니다.
  9. 비밀로 유지되어야 하는 데이터(키 자료, 난수 시드 등)는 명확히 표시되는 것이 SHOULD 됩니다.
  10. DID 메서드 명세는 적용 가능한 경우 DID 문서에 대한 서명 구현을 설명하고 지정하는 것이 SHOULD 됩니다.
  11. 알려진 모든 DLT와 같이 DID 메서드가 피어 투 피어 컴퓨팅 리소스를 사용하는 경우, 서비스 거부와 관련하여 해당 리소스의 예상 부담이 논의되는 것이 SHOULD 됩니다.
  12. 5.4 서비스에 설명된 것처럼 새로운 인증 서비스 유형을 도입하는 DID 메서드는 지원되는 인증 프로토콜의 보안 요구사항을 고려하는 것이 SHOULD 됩니다.

7.4 개인정보 보호 요구사항

개인정보 보호 고려사항 절을 작성할 때 모든 DID 메서드 명세에 대한 요구사항은 다음과 같습니다.

  1. DID 메서드 명세의 개인정보 보호 고려사항 절은 메서드별 방식으로 적용될 수 있는 [RFC6973] 제5절의 모든 하위 절을 논의해야 MUST 합니다. 고려할 하위 절은 감시, 저장된 데이터 손상, 원치 않는 트래픽, 오귀속, 상관관계, 식별, 2차 사용, 공개, 그리고 배제입니다.

8. 보안 고려사항

이 절은 비규범적입니다.

이 절에는 탈중앙화 식별자를 사용하는 사람들이 이 기술을 프로덕션 환경에 배포하기 전에 고려하도록 권고되는 다양한 보안 고려사항이 포함되어 있습니다. 독자는 이 절을 읽기 전에 Controlled Identifiers v1.0 명세의 보안 고려사항 절을 읽는 것이 권장됩니다. DID는 많은 IETF 표준에서 사용되고 [RFC3552]에 문서화된 위협 모델 아래에서 동작하도록 설계되었습니다. 이 절은 [RFC3552]의 여러 고려사항뿐 아니라 DID 아키텍처에 고유한 다른 고려사항도 자세히 설명합니다.

8.1 DID 리졸버 선택

DID Extensions 저장소 [DID-EXTENSIONS]에는 DID 메서드 이름과 그에 해당하는 DID 메서드 명세의 정보적 목록이 포함되어 있습니다. 구현자는 특정 DID 메서드 이름에 어떤 DID 메서드 명세를 사용해야 하는지를 지시하는 중앙 기관이 없다는 점을 명심해야 합니다. 특정 DID 리졸버DID 메서드를 올바르게 구현하는지 의심스러운 경우, DID Specification Registries를 사용하여 등록된 명세를 조회하고 어떤 DID 리졸버 구현을 사용할지에 대해 정보에 기반한 결정을 내릴 수 있습니다.

8.2 부인 방지

DIDDID 문서 업데이트의 부인 방지는 다음과 같은 경우 지원됩니다.

8.3 신뢰 없는 시스템에서의 폐기

신뢰 없는 시스템은 모든 신뢰가 암호학적으로 증명 가능한 주장으로부터 도출되는 시스템이며, 더 구체적으로는 암호학적 시스템 외부의 메타데이터가 시스템 내 신뢰 판단에 반영되지 않는 시스템입니다. 신뢰 없는 시스템에서 폐기된 검증 방법에 대한 증명 또는 서명을 검증하려면, DID 메서드versionId 또는 versionTime 중 하나 또는 둘 다와, updatednextUpdateDID 문서 메타데이터 속성을 지원해야 합니다. 검증자는 다음 조건이 모두 참일 때, 그리고 그때에만 폐기된 키의 서명 또는 증명을 검증할 수 있습니다.

암호학적 입력을 구성하는 것 이상의 메타데이터를 기꺼이 수용하는 시스템에서도 유사한 신뢰를 달성할 수 있습니다. 그러나 이는 항상 서명 이벤트가 발생한 순간에 DID 문서의 내용이 예상한 내용을 포함했는지에 대한 신중한 판단을 요구합니다.

8.4 DID 복구

복구는 기기 분실 등을 통해 DID 작업을 수행할 능력을 잃은 컨트롤러가 DID 작업을 수행할 능력을 되찾을 수 있게 하는 반응형 보안 조치입니다.

DID 복구 사용을 고려할 때 다음 고려사항이 유용할 수 있습니다.

8.5 사람에게 친숙한 식별자의 역할

DID는 중앙 등록 기관을 필요로 하지 않고 전역적 고유성을 달성합니다. 이는 사람이 기억하기 어렵다는 대가를 수반합니다. 전역적으로 모호하지 않은 식별자를 생성할 수 있는 알고리즘은 인간에게 의미가 없는 무작위 문자 문자열을 생성합니다. 이러한 절충은 흔히 Zooko의 삼각형이라고 불립니다.

사람에게 친숙한 식별자에서 시작하여 DID를 발견하는 것이 바람직한 사용 사례가 있습니다. 예를 들어 자연어 이름, 도메인 이름, 또는 휴대전화 번호, 이메일 주소, 소셜 미디어 사용자 이름, 블로그 URL과 같은 DID 컨트롤러의 관례적 주소가 있습니다. 그러나 사람에게 친숙한 식별자를 DID에 매핑하고, 이를 검증되고 신뢰될 수 있는 방식으로 수행하는 문제는 이 명세의 범위를 벗어납니다.

이 문제에 대한 해결책은 이 명세를 참조하는 [DNS-DID]와 같은 별도의 명세에서 정의됩니다. 그러한 명세는 다음을 신중히 고려하는 것이 강력히 권장됩니다.

8.6 향상된 URN으로서의 DID

DID 컨트롤러가 원한다면, DID 또는 DID URL은 영속적이고 위치 독립적인 리소스 식별자로 작동할 수 있습니다. 이러한 종류의 식별자는 Uniform Resource Names(URN)로 분류되며 [RFC8141]에 정의되어 있습니다. DID는 디지털 리소스를 위한 암호학적으로 안전하고 위치 독립적인 식별자를 제공하는 향상된 형태의 URN이며, 동시에 검색을 가능하게 하는 메타데이터도 제공합니다. DID 문서DID 자체 사이의 간접 참조로 인해, DID 컨트롤러DID를 조정하지 않고도 리소스의 실제 위치를 조정하거나 리소스를 직접 제공할 수도 있습니다. 이러한 유형의 DID는 검색된 리소스가 실제로 식별된 리소스임을 확정적으로 검증할 수 있습니다.

이러한 목적으로 DID를 사용하려는 DID 컨트롤러는 [RFC8141]의 보안 고려사항을 따르는 것이 권고됩니다. 특히 다음 사항입니다.

8.7 불변성

많은 사이버보안 남용은 현실과 합리적이고 선의의 행위자가 가진 가정 사이의 틈을 악용하는 데 달려 있습니다. DID 문서의 불변성은 일부 보안 이점을 제공할 수 있습니다. 개별 DID 메서드는 필요하지 않은 동작이나 의미론을 제거할 제약을 고려해야 합니다. 동일한 기능 집합을 제공하면서도 DID 메서드가 더 잠겨 있을수록, 악의적인 행위자가 이를 조작할 수 있는 가능성은 더 낮아집니다.

예를 들어, DID 문서에 대한 한 번의 편집으로 문서의 루트 id 속성을 제외한 무엇이든 변경할 수 있다고 가정해 보십시오. 그러나 서비스가 정의된 후 그 type을 변경하는 것이 실제로 바람직할까요? 또는 키가 값을 변경하는 것은 어떨까요? 아니면 객체의 특정 근본 속성이 변경될 때 새로운 id를 요구하는 것이 더 나을까요? 웹사이트에 대한 악의적인 탈취는 종종 사이트가 호스트 이름 식별자를 유지하되, 그 아래가 미묘하게 변경되는 결과를 목표로 합니다. 사이트의 특정 속성, 예를 들어 IP 주소와 연결된 ASN이 명세에 의해 불변이어야 한다면, 이상 탐지가 더 쉬워지고 공격을 수행하는 것은 훨씬 더 어렵고 비용이 많이 들 것입니다.

전역 진실 소스에 연결된 DID 메서드의 경우, 최신 버전의 DID 문서를 직접 즉시 조회하는 것이 항상 가능합니다. 그러나 결국 DID 리졸버와 그 진실 소스 사이에 캐시 계층이 놓일 가능성이 있습니다. 그렇다면 DID 문서 안의 객체 속성이 실제로는 미묘하게 다른데도 특정 상태를 가진다고 믿는 것은 악용을 초래할 수 있습니다. 이는 일부 조회가 전체 DID 문서에 대한 것이고, 다른 조회는 더 큰 맥락이 가정된 부분 데이터에 대한 것일 때 특히 그렇습니다.

8.8 DID 문서의 암호화된 데이터

암호화 알고리즘은 암호학과 컴퓨팅 능력의 발전으로 인해 실패하는 것으로 알려져 왔습니다. 구현자는 DID 문서에 배치된 모든 암호화된 데이터가 결국 해당 암호화된 데이터를 사용할 수 있는 동일한 대상에게 평문으로 제공될 수 있다고 가정하는 것이 권고됩니다. 이는 DID 문서가 공개된 경우 특히 관련이 있습니다.

DID 문서의 전부 또는 일부를 암호화하는 것은 장기적으로 데이터를 보호하기 위한 적절한 수단이 아닙니다. 마찬가지로, 암호화된 데이터를 DID 문서에 배치하는 것은 개인 데이터를 보호하기 위한 적절한 수단이 아닙니다.

위의 주의사항을 고려할 때, 암호화된 데이터가 DID 문서에 포함되는 경우, 구현자는 암호화된 데이터와 관련 당사자 사이의 관계를 추론하는 데 사용될 수 있는 상관 가능한 정보를 연결하지 않는 것이 권고됩니다. 상관 가능한 정보의 예로는 수신 당사자의 공개 키, 수신 당사자의 제어 아래 있는 것으로 알려진 디지털 자산의 식별자, 또는 수신 당사자에 대한 사람이 읽을 수 있는 설명이 있습니다.

8.9 동등성 속성

equivalentIdcanonicalId 속성은 DID 메서드 자체에 의해 생성되므로, DID 문서id 필드에 존재하는 해석된 DID에 적용되는 동일한 보안 및 정확성 보장이 이러한 속성에도 적용됩니다. alsoKnownAs 속성은 정확한 동등성 진술이라고 보장되지 않으며, DID 문서의 해석을 넘어서는 검증 단계를 수행하지 않고는 의존해서는 안 됩니다.

equivalentIdcanonicalId 속성은 동일한 DID 메서드에 의해 생성된 단일 DID의 변형에 대한 동등성 주장을 표현하며, 요청 당사자가 DID 메서드와 적합한 생산자 및 리졸버를 신뢰하는 정도까지 신뢰할 수 있습니다.

alsoKnownAs 속성은 동일한 DID 메서드에 의해 관리되지 않는 URI에 대한 동등성 주장을 허용하며, 관리하는 DID 메서드 외부의 검증 단계를 수행하지 않고는 신뢰할 수 없습니다. 추가 지침은 Controlled Identifiers v1.0 명세의 Section 2.1.3: Also Known As를 참조하십시오.

DID 문서의 다른 보안 관련 속성과 마찬가지로, DID 문서의 동등성 진술에 의존하는 당사자는 적절한 검증이 수행된 후 공격자가 이러한 속성의 값을 대체하는 것을 방지해야 합니다. 검증이 수행된 후 메모리 또는 디스크에 저장된 DID 문서에 대한 모든 쓰기 접근은 DID 문서가 다시 검증되지 않는 한 검증을 우회할 수 있는 공격 벡터입니다.

8.10 지속성

DID컨트롤러가 자신의 식별자를 유지하기 위해 하나의 신뢰된 제3자 또는 관리자에 의존할 필요가 없도록 영속적으로 설계되었습니다. 이상적인 경우, 어떤 관리자도 컨트롤러로부터 제어권을 빼앗을 수 없으며, 인증, 권한 부여, 증명과 같은 특정 목적을 위한 식별자 사용을 막을 수도 없습니다. 어떤 제3자도 컨트롤러의 동의 없이 컨트롤러를 대신하여 엔터티의 식별자를 제거하거나 작동 불능으로 만들 수 없습니다.

그러나 암호학적 제어 증명을 가능하게 하는 모든 DID 메서드에서는 비밀 암호학적 자료를 이전함으로써 제어를 증명하는 수단이 항상 다른 당사자에게 이전될 수 있다는 점에 유의하는 것이 중요합니다. 따라서 시간이 지남에 따라 식별자의 지속성에 의존하는 시스템은 해당 식별자가 실제로 의도한 당사자의 제어 아래 있는지 정기적으로 확인하는 것이 중요합니다.

안타깝게도 주어진 검증 방법과 관련된 비밀 암호학적 자료가 손상되었는지 여부를 암호학만으로 판단하는 것은 불가능합니다. 예상된 컨트롤러가 여전히 비밀 암호학적 자료에 접근할 수 있어서 검증 과정의 일부로 제어 증명을 실행할 수 있는 동시에, 악의적인 행위자도 동일한 키 또는 그 사본에 접근할 수 있을 수 있습니다.

따라서 암호학적 제어 증명은 고위험 시나리오에 필요한 신원 보증 수준을 평가하는 하나의 요소로만 사용될 것으로 기대됩니다. DID 기반 인증은 시스템 사이에 암호학적 비밀을 전송하지 않고도 해당 비밀에 대한 제어를 확인할 수 있기 때문에 사용자 이름과 비밀번호보다 훨씬 더 큰 보증을 제공합니다. 그러나 완전무결하지는 않습니다. 민감하거나, 가치가 높거나, 생명에 중대한 작업이 포함된 시나리오는 적절한 추가 요소를 사용할 것으로 기대됩니다.

서로 다른 컨트롤러에 의한 사용에서 생길 수 있는 모호성 외에도, 일반적으로 주어진 DID가 어느 특정 시점에 동일한 주체를 가리키는 데 사용되고 있음을 보장하는 것은 불가능합니다. 기술적으로 컨트롤러가 서로 다른 주체에 대해 DID를 재사용하는 것이 가능하며, 더 미묘하게는 주체의 정확한 정의가 시간이 지나며 변하거나 오해될 수도 있습니다.

예를 들어, 금융 거래에 사용되는 다양한 자격 증명을 받는 개인사업자에 사용되는 DID를 생각해 보십시오. 컨트롤러에게 그 식별자는 사업을 가리켰습니다. 사업이 성장하면서 결국 유한책임회사로 법인화됩니다. 컨트롤러는 동일한 DID를 계속 사용합니다. 왜냐하면 그들에게DID는 사업을 가리키기 때문입니다. 그러나 주 정부, 세무 당국, 지방자치단체에게 그 DID는 더 이상 동일한 엔터티를 가리키지 않습니다. 의미의 미묘한 변화가 신용 제공자나 공급자에게 중요한지 여부는 반드시 그들이 결정해야 합니다. 많은 경우 청구서가 지불되고 추심이 집행될 수 있는 한, 그 변화는 중요하지 않습니다.

이러한 잠재적 모호성 때문에, DID는 절대적으로가 아니라 맥락적으로 유효한 것으로 간주되어야 합니다. 그 지속성은 정확히 동일한 주체를 가리킨다거나 동일한 컨트롤러의 제어 아래 있다는 것을 의미하지 않습니다. 대신, DID가 생성된 맥락, 사용 방식, 그리고 그 의미의 가능한 변화를 이해하고, 잠재적 및 필연적인 의미론적 드리프트를 모두 다루기 위한 절차와 정책을 채택해야 합니다.

8.11 경쟁하는 고려사항 평가

이 절은 비규범적입니다.

이 명세는 특정 유형의 검증 가능 데이터 레지스트리 사용을 요구하거나 제안하지 않습니다. 서로 다른 사용 사례는 서로 다른 요구사항으로 이어질 수 있습니다. 서로 다른 요구사항은 서로 다른 절충을 가진 서로 다른 고려사항을 시사할 수 있습니다. 예를 들어, 계산(에너지 사용), 신뢰(권위에 대한 의존), 조정(네트워크 대역폭), 또는 메모리(물리적 저장소) 간의 절충은 주어진 사용 사례에 적절할 수도 있고 적절하지 않을 수도 있습니다. 다른 사용 사례는 동일한 절충을 하지 않을 수 있습니다. 자신의 사용 사례에 대해 다른 기준을 고려해야 하는 경우, 의사결정자가 특정 DID 메서드가 그 사용 사례에 적절한지 여부를 판단하는 데 도움이 되는 평가 기준을 제공하는 DID Method Rubric을 참조하십시오.

9. 개인정보 보호 고려사항

이 절은 비규범적입니다.

DIDDID 문서DID 컨트롤러가 직접 관리하도록 설계되었으므로, 탈중앙화 식별자 아키텍처의 모든 측면에 프라이버시 중심 설계 [PRIVACY-BY-DESIGN] 원칙을 적용하는 것이 매우 중요합니다. 이 일곱 가지 원칙은 모두 이 명세의 개발 전반에 적용되었습니다. 이 명세에서 사용되는 설계는 추가 개인정보 보호 장치를 권고하거나 적용할 등록 기관, 호스팅 회사 또는 기타 중간 서비스 제공자가 있다고 가정하지 않습니다. 이 명세에서 개인정보 보호는 사후적이 아니라 예방적이며, 기본값으로 내장되어 있습니다. 이 절을 읽기 전에, 독자는 Controlled Identifiers v1.0 명세의 개인정보 보호 고려사항 절을 읽는 것이 권장됩니다. 그 절에는 DID에도 적용되는 더 일반적인 개인정보 보호 고려사항이 포함되어 있습니다. 이 절의 나머지는 탈중앙화 식별자에 특화된 개인정보 보호 고려사항을 다루며, Controlled Identifiers v1.0 명세에서 제공하는 지침에 추가됩니다.

9.1 그룹 개인정보 보호

DID 주체가 그룹 안의 다른 사람들과 구별되지 않을 때 개인정보 보호가 가능합니다. 다른 당사자와 사적으로 교류한다는 행위 자체가 인식 가능한 표식이 되는 경우, 개인정보 보호는 크게 줄어듭니다.

DIDDID 메서드는 그룹 개인정보 보호를 개선하기 위해 노력해야 하며, 특히 이를 정당하게 가장 필요로 하는 사람들을 위해 그러해야 합니다. 익명성과 가명성을 기본적으로 보존하는 기술과 인간 인터페이스를 선택하십시오. 디지털 지문을 줄이기 위해, 요청 당사자 구현 전반에서 공통 설정을 공유하고, 전송 프로토콜에서 협상되는 옵션을 최소화하며, 암호화된 전송 계층을 사용하고, 메시지를 표준 길이로 패딩하십시오.

A.

이 절은 비규범적입니다.

A.1 DID 문서

이 절은 비규범적입니다.

선택적 확장 및 기타 검증 방법 유형은 검증 방법 유형 [DID-EXTENSIONS]을 참조하십시오.

참고

이 예들은 정보 제공 목적으로만 제공되며, 동일한 검증 방법을 여러 목적으로 사용하는 것을 피하는 것이 모범 사례로 간주됩니다.

예제 12: 검증 방법 유형 1개가 있는 DID 문서
  {
    "@context": "https://www.w3.org/ns/did/v1.1",
    "id": "did:example:123",
    "authentication": [
      {
        "id": "did:example:123#z6MkmM42vxfqZQsv4ehtTjFFxQ4sQKS2w6WR7emozFAn5cxu",
        "type": "Multikey", // external (property value)
        "controller": "did:example:123",
        "publicKeyMultibase": "z6MkmM42vxfqZQsv4ehtTjFFxQ4sQKS2w6WR7emozFAn5cxu"
      }
    ],
    "capabilityInvocation": [
      {
        "id": "did:example:123#z6Mkvtac9bidSz9bBttzn7Yg3oCDHvMY2FtkFLs6SXRQGdQR",
        "type": "Multikey", // external (property value)
        "controller": "did:example:123",
        "publicKeyMultibase": "z6Mkvtac9bidSz9bBttzn7Yg3oCDHvMY2FtkFLs6SXRQGdQR"
      }
    ],
    "capabilityDelegation": [
      {
        "id": "did:example:123#z6MknxsdF4CGVxhRNsx6TvXPFczaHEkajKBBwu75uwBmgpom",
        "type": "Multikey", // external (property value)
        "controller": "did:example:123",
        "publicKeyMultibase": "z6MknxsdF4CGVxhRNsx6TvXPFczaHEkajKBBwu75uwBmgpom"
      }
    ],
    "assertionMethod": [
      {
        "id": "did:example:123#z6MkgYhVuWq4hyc7ZKBGhsY7pb5Bc8V6VPXGPG3EPja8JBFR",
        "type": "Multikey", // external (property value)
        "controller": "did:example:123",
        "publicKeyMultibase": "z6MkgYhVuWq4hyc7ZKBGhsY7pb5Bc8V6VPXGPG3EPja8JBFR"
      }
    ]
}
예제 13: 여러 다른 키 유형이 있는 DID 문서
{
  "@context": "https://www.w3.org/ns/did/v1.1",
  "id": "did:example:123",
  "verificationMethod": [
    {
      "id": "did:example:123#key-0",
      "type": "JsonWebKey",
      "controller": "did:example:123",
      "publicKeyJwk": {
        "kty": "OKP", // external (property name)
        "crv": "Ed25519", // external (property name)
        "x": "VCpo2LMLhn6iWku8MKvSLg2ZAoC-nlOyPVQaO3FxVeQ" // external (property name)
      }
    },
    {
      "id": "did:example:123#key-1",
      "type": "JsonWebKey",
      "controller": "did:example:123",
      "publicKeyJwk": {
        "kty": "OKP", // external (property name)
        "crv": "X25519", // external (property name)
        "x": "pE_mG098rdQjY3MKK2D5SUQ6ZOEW3a6Z6T7Z4SgnzCE" // external (property name)
      }
    },
    {
      "id": "did:example:123#key-2",
      "type": "JsonWebKey",
      "controller": "did:example:123",
      "publicKeyJwk": {
        "kty": "EC", // external (property name)
        "crv": "secp256k1", // external (property name)
        "x": "Z4Y3NNOxv0J6tCgqOBFnHnaZhJF6LdulT7z8A-2D5_8", // external (property name)
        "y": "i5a2NtJoUKXkLm6q8nOEu9WOkso1Ag6FTUT6k_LMnGk" // external (property name)
      }
    },
    {
      "id": "did:example:123#key-3",
      "type": "JsonWebKey",
      "controller": "did:example:123",
      "publicKeyJwk": {
        "kty": "EC", // external (property name)
        "crv": "secp256k1", // external (property name)
        "x": "U1V4TVZVMUpUa0ZVU1NBcU9CRm5IbmFaaEpGNkxkdWx", // external (property name)
        "y": "i5a2NtJoUKXkLm6q8nOEu9WOkso1Ag6FTUT6k_LMnGk" // external (property name)
      }
    },
    {
      "id": "did:example:123#key-4",
      "type": "JsonWebKey",
      "controller": "did:example:123",
      "publicKeyJwk": {
        "kty": "EC", // external (property name)
        "crv": "P-256", // external (property name)
        "x": "Ums5WVgwRkRTVVFnU3k5c2xvZllMbEcwM3NPRW91ZzN", // external (property name)
        "y": "nDQW6XZ7b_u2Sy9slofYLlG03sOEoug3I0aAPQ0exs4" // external (property name)
      }
    },
    {
      "id": "did:example:123#key-5",
      "type": "JsonWebKey",
      "controller": "did:example:123",
      "publicKeyJwk": {
        "kty": "EC", // external (property name)
        "crv": "P-384", // external (property name)
        "x": "VUZKSlUwMGdpSXplekRwODhzX2N4U1BYdHVYWUZsaXVDR25kZ1U0UXA4bDkxeHpE", // external (property name)
        "y": "jq4QoAHKiIzezDp88s_cxSPXtuXYFliuCGndgU4Qp8l91xzD1spCmFIzQgVjqvcP" // external (property name)
      }
    },
    {
      "id": "did:example:123#key-6",
      "type": "JsonWebKey",
      "controller": "did:example:123",
      "publicKeyJwk": {
        "kty": "EC", // external (property name)
        "crv": "P-521", // external (property name)
        "x": "VTI5c1lYSmZWMmx1WkhNZ0dQTXhaYkhtSnBEU3UtSXZwdUtpZ0VOMnB6Z1d0U28tLVJ3ZC1uNzhuclduWnplRGMx", // external (property name)
        "y": "UW5WNVgwSnBkR052YVc0Z1VqY1B6LVpoZWNaRnliT3FMSUpqVk9sTEVUSDd1UGx5RzBnRW9NV25JWlhoUVZ5cFB5" // external (property name)
      }
    },
    {
      "id": "did:example:123#key-7",
      "type": "JsonWebKey",
      "controller": "did:example:123",
      "publicKeyJwk": {
        "kty": "RSA", // external (property name)
        "e": "AQAB", // external (property name)
        "n": "UkhWaGJGOUZRMTlFVWtKSElBdENGV2hlU1F2djFNRXh1NVJMQ01UNGpWazlraEpLdjhKZU1YV2UzYldIYXRqUHNrZGYyZGxhR2tXNVFqdE9uVUtMNzQybXZyNHRDbGRLUzNVTElhVDFoSkluTUhIeGoyZ2N1Yk82ZUVlZ0FDUTRRU3U5TE8wSC1MTV9MM0RzUkFCQjdRamE4SGVjcHl1c3BXMVR1X0RicXhjU253ZW5kYW13TDUyVjE3ZUtobE80dVh3djJIRmx4dWZGSE0wS21DSnVqSUt5QXhqRF9tM3FfX0lpSFVWSEQxdERJRXZMUGhHOUF6c24zajk1ZC1zYU" // external (property name)
      }
    }
  ]
}
예제 14: 서로 다른 검증 방법 유형이 있는 DID 문서
{
  "@context": "https://www.w3.org/ns/did/v1.1",
  "id": "did:example:123",
  "verificationMethod": [{
    "id": "did:example:123#key-0",
    "type": "Multikey",
    "controller": "did:example:123",
    "publicKeyMultibase": "z6MkmM42vxfqZQsv4ehtTjFFxQ4sQKS2w6WR7emozFAn5cxu"
  }, {
    "id": "did:example:123#key-1",
    "type": "Multikey",
    "controller": "did:example:123",
    "publicKeyMultibase": "z6MtTjFFxQ4sQKS2wmozFAn5cxukmM46WR7e2vxfqZQsv4eh"
  }, {
    "id": "did:example:123#key-2",
    "type": "EcdsaSecp256k1VerificationKey2019",
    "controller": "did:example:123",
    "publicKeyMultibase": "zns2aFDq25fEV1NUd3wZ65sgtht4j5QjFW8JCAHdUJfLwfodt"
  }, {
    "id": "did:example:123#key-3",
    "type": "JsonWebKey",
    "controller": "did:example:123",
    "publicKeyJwk": {
      "kty": "EC", // external (property name)
      "crv": "P-256", // external (property name)
      "x": "Er6KSSnAjI70ObRWhlaMgqyIOQYrDJTE94ej5hybQ2M",
      "y": "pPVzCOTJwgikPjuUE6UebfZySqEJ0ZtsWFpj7YSPGEk"
    }
  }]
}
예제 15: 상대 DID URL을 사용하는 DID 문서
  {
    "@context": "https://www.w3.org/ns/did/v1.1",
    "id": "did:example:123",
    "verificationMethod": [
      {
        // 절대 DID URL 값 did:example:123#key-1로 변환될 상대 DID URL
        "id": "#key-1",
        "type": "Ed25519VerificationKey2020",
        "controller": "did:example:123",
        "publicKeyMultibase": "z6MkmM42vxfqZQsv4ehtTjFFxQ4sQKS2w6WR7emozFAn5cxu"
      }
    ],
    "authentication": [
      "#key-1"
    ],
    "capabilityInvocation": [
      "#key-1"
    ],
    "capabilityDelegation": [
      "#key-1"
    ],
    "assertionMethod": [
      // 상대 DID URL #key-1을 사용하는 것은 절대 DID URL 값 did:example:123#key-1을 사용하는 것과 동일함
      "did:example:123#key-1"
    ]
}

A.2 증명

이 절은 비규범적입니다.

참고

이 예들은 정보 제공 목적으로만 제공됩니다. 추가 예는 검증 가능 자격 증명 데이터 모델 v2.0을 참조하십시오.

예제 16: Multikey 유형의 검증 방법에 연결된 검증 가능 자격 증명
{
  // external (all terms in this example)
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://w3id.org/citizenship/v4rc1"
  ],
  "type": [
    "VerifiableCredential",
    "PermanentResidentCardCredential"
  ],
  "issuer": {
    "id": "did:key:zDnaeYGXycLmAn5m9akGtdL6rqBspGQPM7QZXW2CvJ3k9c2Bz",
    "image": "data:image/png;base64,iVBORw0KGgo...5CYII="
  },
  "name": "Permanent Resident Card",
  "description": "Government of Utopia Permanent Resident Card.",
  "credentialSubject": {
    "type": [
      "PermanentResident",
      "Person"
    ],
    "givenName": "JANE",
    "familyName": "SMITH",
    "gender": "Female",
    "image": "data:image/png;base64,iVBORw0KGgoAA...kJggg==",
    "residentSince": "2015-01-01",
    "commuterClassification": "C1",
    "birthCountry": "Arcadia",
    "birthDate": "1978-07-17",
    "permanentResidentCard": {
      "type": "PermanentResidentCard",
      "identifier": "83627465",
      "lprCategory": "C09",
      "lprNumber": "999-999-999"
    }
  },
  "validFrom": "2025-01-04T00:00:00Z",
  "validUntil": "2026-01-04T23:59:59Z",
  "proof": {
    "type": "DataIntegrityProof",
    "created": "2025-01-04T15:02:36Z",
    "verificationMethod": "did:key:zDnaeYGXycLmAn5m9akGtdL6rqBspGQPM7QZXW2CvJ3k9c2Bz#zDnaeYGXycLmAn5m9akGtdL6rqBspGQPM7QZXW2CvJ3k9c2Bz",
    "cryptosuite": "ecdsa-rdfc-2019",
    "proofPurpose": "assertionMethod",
    "proofValue": "z5CK4DPN7...Jpqwp"
  }
}
예제 17: JsonWebKey 유형의 검증 방법에 연결된 검증 가능 자격 증명
{  // external (all terms in this example)
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://w3id.org/citizenship/v4rc1"
  ],
  "type": [
    "VerifiableCredential",
    "PermanentResidentCardCredential"
  ],
  "issuer": {
    "id": "did:example:123#key-1",
    "image": "data:image/png;base64,iVBORw0KGgo...5CYII="
  },
  "name": "Permanent Resident Card",
  "description": "Government of Utopia Permanent Resident Card.",
  "credentialSubject": {
    "type": [
      "PermanentResident",
      "Person"
    ],
    "givenName": "JANE",
    "familyName": "SMITH",
    "gender": "Female",
    "image": "data:image/png;base64,iVBORw0KGgoAA...kJggg==",
    "residentSince": "2015-01-01",
    "commuterClassification": "C1",
    "birthCountry": "Arcadia",
    "birthDate": "1978-07-17",
    "permanentResidentCard": {
      "type": "PermanentResidentCard",
      "identifier": "83627465",
      "lprCategory": "C09",
      "lprNumber": "999-999-999"
    }
  },
  "validFrom": "2025-01-04T00:00:00Z",
  "validUntil": "2026-01-04T23:59:59Z",
  "proof": {
    "type": "DataIntegrityProof",
    "created": "2025-01-04T15:02:36Z",
    "verificationMethod": "did:example:123#key-1",
    "cryptosuite": "ecdsa-jcs-2019",
    "proofPurpose": "assertionMethod",
    "proofValue": "z5m9akGtdL...6rqBspGQP"
  }
}
예제 18: bls12381 검증 방법에 연결된 검증 가능 자격 증명
{  // external (all terms in this example)
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://w3id.org/citizenship/v4rc1"
  ],
  "type": [
    "VerifiableCredential",
    "PermanentResidentCardCredential"
  ],
  "issuer": {
    "id": "did:key:zUC7DojAAkoD8WpSS87KG6iuMSBd4wH1fZzmcwmakx4JfaXN7RLSES4wNCfWboHvULxGxRwiSsj6UYSgq1dWGusdwrrJsjUQQEb1oid3igF4hbSFzFjf9aWTJSphhu63vHGoAVE",
    "image": "data:image/png;base64,iVBORw0KGgoAA...CYII="
  },
  "name": "Permanent Resident Card",
  "description": "Government of Utopia Permanent Resident Card.",
  "credentialSubject": {
    "type": [
      "PermanentResident",
      "Person"
    ],
    "givenName": "JANE",
    "familyName": "SMITH",
    "gender": "Female",
    "image": "data:image/png;base64,iVBORw0KGgoAAA...3dgg==",
    "residentSince": "2015-01-01",
    "commuterClassification": "C1",
    "birthCountry": "Arcadia",
    "birthDate": "1978-07-17",
    "permanentResidentCard": {
      "type": "PermanentResidentCard",
      "identifier": "83627465",
      "lprCategory": "C09",
      "lprNumber": "999-999-999"
    }
  },
  "validFrom": "2025-01-04T00:00:00Z",
  "validUntil": "2026-01-04T23:59:59Z",
  "proof": {
    "type": "DataIntegrityProof",
    "verificationMethod": "did:key:zUC7DojAAkoD8WpSS87KG6iuMSBd4wH1fZzmcwmakx4JfaXN7RLSES4wNCfWboHvULxGxRwiSsj6UYSgq1dWGusdwrrJsjUQQEb1oid3igF4hbSFzFjf9aWTJSphhu63vHGoAVE#zUC7DojAAkoD8WpSS87KG6iuMSBd4wH1fZzmcwmakx4JfaXN7RLSES4wNCfWboHvULxGxRwiSsj6UYSgq1dWGusdwrrJsjUQQEb1oid3igF4hbSFzFjf9aWTJSphhu63vHGoAVE",
    "cryptosuite": "bbs-2023",
    "proofPurpose": "assertionMethod",
    "proofValue": "u2V0ChVhQik2d4...pc3N1ZXI"
  }
}
예제 19: bls12381 검증 방법에 연결된 검증 가능 자격 증명 선택적 공개 영지식 증명
{
  // external (all terms in this example)
  "@context": "https://www.w3.org/ns/credentials/v2",
  "type": "VerifiablePresentation",
  // holder did:key는 상관관계를 피하기 위해 도메인과 쌍별임
  "holder": "did:key:z6MkveKdpgkQ1pwNktQ5Lc19epBrzFjMUeNMUZGFvezFF2dX",
  "verifiableCredential": {
    "@context": [
      "https://www.w3.org/ns/credentials/v2",
      "https://w3id.org/citizenship/v4rc1"
    ],
    "type": [
      "VerifiableCredential",
      "PermanentResidentCardCredential"
    ],
    "issuer": {
      "id": "did:web:unlinkable.example",
      "image": "data:image/png;base64,iVBORw0KGgoAA...CYII="
    },
    "credentialSubject": {
      "type": ["PermanentResident", "Person"],
      // country만 선택적으로 공개됨
      "birthCountry": "Arcadia"
    },
    "proof": {
      "type": "DataIntegrityProof",
      "verificationMethod": "did:web:vcplayground.org#zUC7EwMqo9vCjFmj7ArU2SivcbeccAY6hd4nw5fVD6xD4W2vm9eVy6VqVnciAZRmPLXnuxuka5JTJVmgz66CxDno6eqZmvUViCckCcKg8A4s1R4i2JjyzrdTQs5zrfY4jJCHFCp",
      "cryptosuite": "bbs-2023",
      "proofPurpose": "assertionMethod",
      "proofValue": "u2V0DhV...3JnIn0"
    }
  },
  "proof": {
    "type": "DataIntegrityProof",
    "created": "2025-01-04T15:10:39Z",
    "verificationMethod": "did:key:z6MkveKdpgkQ1pwNktQ5Lc19epBrzFjMUeNMUZGFvezFF2dX#z6MkveKdpgkQ1pwNktQ5Lc19epBrzFjMUeNMUZGFvezFF2dX",
    "proofPurpose": "authentication",
    "challenge": "QZVVFcXlMPStFmpXTSktv",
    "domain": "https://unlinkable.example",
    "proofValue": "z5tXmHk...x2GvTt3bF"
  }
}
예제 20: 디코딩된 JWT로서의 검증 가능 자격 증명
{ // external (all terms in this example)
  "protected": {
    "kid": "did:example:123#_Qq0UL2Fq651Q0Fjd6TvnYE-faHiOpRlPVQcY_-tA4A",
    "alg": "EdDSA"
  },
  "payload": {
    "@context": [
      "https://www.w3.org/ns/credentials/v2",
      "https://w3id.org/citizenship/v4rc1"
    ],
    "type": [
      "VerifiableCredential",
      "PermanentResidentCardCredential"
    ],
    "issuer": {
      "id": "did:key:zUC7Do...oAVE",
      "image": "data:image/png;base64,iVBORw0KGgoAA...CYII="
    },
    "name": "Permanent Resident Card",
    "description": "Government of Utopia Permanent Resident Card.",
    "credentialSubject": {
      "type": [
        "PermanentResident",
        "Person"
      ],
      "givenName": "JANE",
      "familyName": "SMITH",
      "gender": "Female",
      "image": "data:image/png;base64,iVBORw0KGgoAAA...3dgg==",
      "residentSince": "2015-01-01",
      "commuterClassification": "C1",
      "birthCountry": "Arcadia",
      "birthDate": "1978-07-17",
      "permanentResidentCard": {
        "type": "PermanentResidentCard",
        "identifier": "83627465",
        "lprCategory": "C09",
        "lprNumber": "999-999-999"
      }
    },
    "validFrom": "2025-01-04T00:00:00Z",
    "validUntil": "2026-01-04T23:59:59Z",
  },
  "signature": "qSv6d...bJRAw"
}

A.3 암호화

이 절은 비규범적입니다.

참고

이 예들은 정보 제공 목적으로만 제공되며, JWE 헤더에서 불필요한 정보를 공개하지 않는 것이 모범 사례로 간주됩니다.

예제 21: kid를 통해 검증 방법에 연결된 JWE
{ // external (all terms in this example)
  "ciphertext": "3SHQQJajNH6q0fyAHmw...",
  "iv": "QldSPLVnFf2-VXcNLza6mbylYwphW57Q",
  "protected": "eyJlbmMiOiJYQzIwUCJ9",
  "recipients": [
    {
      "encrypted_key": "BMJ19zK12YHftJ4sr6Pz1rX1HtYni_L9DZvO1cEZfRWDN2vXeOYlwA",
      "header": {
        "alg": "ECDH-ES+A256KW",
        "apu": "Tx9qG69ZfodhRos-8qfhTPc6ZFnNUcgNDVdHqX1UR3s",
        "apv": "ZGlkOmVsZW06cm9wc3RlbjpFa...",
        "epk": {
          "crv": "X25519",
          "kty": "OKP",
          "x": "Tx9qG69ZfodhRos-8qfhTPc6ZFnNUcgNDVdHqX1UR3s"
        },
        "kid": "did:example:123#zC1Rnuvw9rVa6E5TKF4uQVRuQuaCpVgB81Um2u17Fu7UK"
      }
    }
  ],
  "tag": "xbfwwDkzOAJfSVem0jr1bA"
}

B. 아키텍처 고려사항

이 절은 비규범적입니다.

B.1 상세 아키텍처 다이어그램

이 절은 비규범적입니다.

다음은 4. 데이터 모델, 5. 핵심 속성, 7. 메서드 및 [DID-RESOLUTION] 사이의 관계를 보여 주는 다이어그램입니다.


  DID와 DID 문서는 검증 가능 데이터 레지스트리에 기록됩니다. DID는
  DID 문서로 해석됩니다. DID는 DID 주체를 참조합니다. DID 컨트롤러는 DID
  문서를 제어합니다. DID URL은 DID를 포함합니다. DID URL은 DID 문서
  프래그먼트 또는 외부 리소스로 역참조됩니다. DID 리졸버는 resolve 함수를 구현합니다. DID
  URL 역참조기는 dereferencing 함수를 구현합니다. DID 메서드는
  검증 가능 데이터 레지스트리를 운영합니다. DID 리졸버와 DID URL 역참조기는 DID
  메서드에 지시합니다.
그림 4 DID 아키텍처와 기본 구성 요소 간 관계의 상세 개요.

B.2 DID 생성

이 절은 비규범적입니다.

DID의 생성은 각 DID 메서드가 정의하는 과정입니다. did:key와 같은 일부 DID 메서드는 순수하게 생성적이며, 단일 암호학적 자료를 적합한 표현으로 변환하여 DIDDID 문서를 생성합니다. 다른 DID 메서드검증 가능 데이터 레지스트리 사용을 요구할 수 있으며, 이 경우 DIDDID 문서는 해당 DID 메서드가 정의한 등록이 완료된 후에만 제3자에게 존재하는 것으로 인식됩니다. 다른 과정도 해당 DID 메서드에 의해 정의될 수 있습니다.

B.3 DID 주체 결정

이 절은 비규범적입니다.

DID는 특정 유형의 URI(Uniform Resource Identifier)이므로, DID는 어떤 리소스든 참조할 수 있습니다. [RFC3986]에 따르면:

"resource"라는 용어는 URI로 식별될 수 있는 무엇이든 가리키는 일반적인 의미로 사용됩니다. [...] 리소스는 반드시 인터넷을 통해 접근 가능해야 하는 것은 아닙니다.

리소스는 디지털 또는 물리적일 수 있고, 추상적이거나 구체적일 수 있습니다. URI를 할당할 수 있는 모든 리소스에는 DID도 할당할 수 있습니다. DID가 참조하는 리소스가 DID 주체입니다.

DID 컨트롤러DID 주체를 결정합니다. DID 자체를 보는 것만으로 DID 주체를 결정할 수 있을 것으로 기대되지는 않습니다. DID는 일반적으로 사람이 아니라 기계에만 의미가 있기 때문입니다. DIDDID 주체에 관한 정보를 포함할 가능성이 낮으므로, DID 주체에 관한 추가 정보는 DIDDID 문서로 해석하거나, 해당 DID에 대한 검증 가능 자격 증명을 얻거나, 또는 DID에 관한 다른 설명을 통해서만 발견할 수 있습니다.

검색된 DID 문서id 속성 값은 항상 해석 중인 DID와 일치해야 하지만, DID가 참조하는 실제 리소스가 시간이 지남에 따라 변경될 수 있는지 여부는 DID 메서드에 따라 달라집니다. 예를 들어, DID 메서드DID 주체의 변경을 허용한다면, 회사의 CEO와 같은 특정 역할의 현재 담당자에 대한 DID를 생성하는 데 사용될 수 있으며, 이 경우 그 역할을 맡은 실제 사람은 DID가 해석되는 시점에 따라 달라질 수 있습니다.

B.4 DID 문서 참조

이 절은 비규범적입니다.

DIDDID 주체를 참조하고, DID 메서드가 지정한 프로토콜을 따라 DID 문서해석됩니다. DID 문서DID 주체와 별개의 리소스가 아니며, DID와 별개의 URI를 갖지 않습니다. 오히려 DID 문서DID 해석의 산물이며, DID 컨트롤러DID 주체와 암호학적으로 검증 가능한 상호작용을 가능하게 하기 위해 제어합니다.

이 구분은 아래에 표시된 그래프 모델로 설명됩니다.


DID 컨트롤러가 DID 주체를 참조하도록 DID를 할당하고,
DID 주체를 설명하는 DID 문서로 해석하는 방식을 보여 주는 그래프 모델 다이어그램.
그림 5 DIDDID 컨트롤러DID 주체를 참조하도록 할당한 식별자이며, DID 문서로 해석되어 DID 주체를 설명합니다. DID 문서DID 해석의 산물이며, DID 주체와 구별되는 별개의 리소스가 아닙니다. 함께 보기: 서술형 설명.
다이어그램 상단에는 채워진 검은색 원 두 개가 있으며, 왼쪽 원에는 "DID Controller"라는 레이블이, 오른쪽 원에는 "DID Subject"라는 레이블이 있습니다. 아래에는 오른쪽 아래 모서리가 안쪽으로 접혀 작은 삼각형을 이룬 직사각형이 있으며, 그 안에는 "DID Document"라는 레이블이 들어 있습니다. 이 세 항목 사이에는 다음과 같이 화살표가 이어집니다. 실선 빨간색 화살표는 DID Controller 원에서 오른쪽의 DID Subject 원을 직접 가리키며, 위에는 큰 글꼴로 "DID", 아래에는 작은 기울임꼴 글꼴로 "Identifies"라는 레이블이 있습니다. 다른 화살표 레이블도 작은 기울임꼴 글꼴입니다. "Resolves to"라는 레이블의 점선 빨간색 화살표는 DID Controller에서 시작하여 첫 번째 화살표와 같은 선에서 아래로 휘어 DID Document 직사각형을 가리킵니다. 초록색 화살표는 "Controls"라는 레이블로 DID Controller에서 DID Document를 직접 가리킵니다. "Controller"라는 레이블의 초록색 화살표는 반대 방향, 즉 DID Document에서 DID Controller로, 다이어그램 왼쪽 바깥쪽으로 호를 그리며 가리킵니다. "Describes"라는 레이블의 파란색 화살표는 DID Document에서 DID Subject를 직접 가리킵니다.

B.5 DID 문서의 진술

이 절은 비규범적입니다.

DID 문서의 각 속성은 DID 컨트롤러가 다음을 설명하기 위해 하는 진술입니다:

DID 문서에서 유일하게 필수인 속성은 id이므로, 이것이 DID 문서에 포함된다고 보장되는 유일한 진술입니다. 그 진술은 그림 5에서 DIDDID 주체 사이의 직접 링크로 설명됩니다.

B.6 DID 주체에 관한 추가 정보 발견

이 절은 비규범적입니다.

DID 주체에 관한 추가 정보를 발견하기 위한 선택지는 DID 문서에 존재하는 속성에 따라 달라집니다. service 속성이 존재하는 경우, 서비스 엔드포인트에서 추가 정보를 요청할 수 있습니다. 예를 들어, 서비스 엔드포인트DID 주체를 설명하는 하나 이상의 주장(속성)에 대해 검증 가능 자격 증명을 지원하는 경우 이를 질의할 수 있습니다.

또 다른 선택지는 DID 문서에 존재하는 경우 alsoKnownAs 속성을 사용하는 것입니다. DID 컨트롤러는 이를 사용해 같은 DID 주체를 참조하는 다른 URI(다른 DID 포함) 목록을 제공할 수 있습니다. 이러한 URI를 해석하거나 역참조하면 아래 그림에 설명된 것처럼 DID 주체에 대한 다른 설명이나 표현을 얻을 수 있습니다.


          그래프 모델을 보여 주는 다이어그램으로, alsoKnownAs 속성이
          DID 주체에 대한 다른 설명으로 역참조되는 서로 다른 리소스를
          나타내는 다른 노드로 향하는 호를 가지고 있습니다.
그림 6 DID 문서는 alsoKnownAs 속성을 사용하여 다른 URI(반드시 그렇지는 않지만 다른 DID 포함)가 같은 DID 주체를 참조한다고 주장할 수 있습니다. 함께 보기: 서술형 설명.
다이어그램에는 작은 검은색 채워진 원 세 개, 모서리가 접힌 직사각형 두 개, 이들 사이의 화살표와 레이블이 다음과 같이 포함되어 있습니다. 왼쪽 위에는 "DID Controller"라고 레이블이 붙은 원이 있습니다. 오른쪽 위에는 "DID Subject"라고 레이블이 붙은 원이 있습니다. 오른쪽 아래 중앙에는 레이블이 없는 원이 있습니다. 오른쪽 아래에는 "Description"이라고 레이블이 붙은 직사각형이 있습니다. 다이어그램 중앙에는 "DID Document"라고 레이블이 붙은 직사각형이 있습니다. DID Document 직사각형 안에는 그 레이블 아래에 두 줄의 코드, 즉 "alsoKnownAs: ["와 "URI]"가 있습니다. 검은색 화살표가 두 번째 줄에서 오른쪽으로 뻗어 직사각형 경계를 가로질러 다이어그램 오른쪽의 레이블 없는 원을 가리킵니다. 이 화살표 위에는 큰 글꼴로 "URI", 아래에는 기울임꼴로 "Identifies"라는 레이블이 있습니다. 검은색 화살표는 레이블 없는 원에서 아래쪽의 Description 직사각형을 가리키며 "Dereferences to"라고 레이블이 붙어 있습니다. "Describes"라는 레이블의 파란색 화살표는 Description에서 오른쪽으로 호를 그리며 DID Subject를 위쪽으로 가리킵니다. 또 다른 "Describes"라는 레이블의 파란색 화살표는 중앙의 "DID Document"라고 레이블이 붙은 직사각형에서 오른쪽 위의 DID Subject 원을 직접 가리킵니다. "alsoKnownAs"라는 레이블의 빨간색 화살표는 DID Subject에서 레이블 없는 원으로 아래쪽을 가리킵니다. 큰 글꼴로 "DID", 아래 기울임꼴로 "Identifies"라고 레이블이 붙은 빨간색 화살표는 이미지 상단에 있으며 DID Controller에서 DID Subject를 가리킵니다. 점선 빨간색 선은 같은 위치에서 시작하지만 갈라져 아래쪽으로 휘어 이미지 중앙의 DID Document 직사각형을 가리킵니다. "Controls"라는 레이블의 초록색 화살표는 DID Controller에서 DID Document를 직접 가리킵니다. 또 다른 초록색 화살표는 반대 방향을 가리키며 "Controller"라고 레이블이 붙어 있고, 이미지 왼쪽 바깥쪽으로 휘어 DID Document에서 DID Controller로 이어집니다.

B.7 DID 주체의 표현 제공

이 절은 비규범적입니다.

DID 주체가 인터넷에서 검색할 수 있는 디지털 리소스인 경우, DID 메서드DID URL을 구성하여 DID 주체 자체의 표현을 반환하도록 선택할 수 있습니다. 예를 들어, 지속적이고 암호학적으로 검증 가능한 식별자가 필요한 데이터 스키마에 DID를 할당할 수 있으며, 지정된 경로 또는 쿼리를 전달하는 것을 그 스키마의 표현을 검색하기 위한 표준 방식으로 사용할 수 있습니다.

마찬가지로, DID는 적용 가능한 DID 메서드가 해당 기능을 지원하는 경우, 검증 가능 데이터 레지스트리에서 직접 반환될 수 있는 디지털 리소스(예: 이미지)를 참조하는 데 사용될 수 있습니다.

B.8 기존 웹 리소스에 DID 할당

이 절은 비규범적입니다.

웹 페이지나 다른 웹 리소스의 컨트롤러가 그것에 지속적이고 암호학적으로 검증 가능한 식별자를 할당하려는 경우, 컨트롤러는 그것에 DID를 부여할 수 있습니다. 예를 들어, 블로그 호스팅 회사의 도메인 아래에 있는 블로그의 작성자는 해당 블로그에 대한 DID를 만들 수 있습니다. DID 문서에서 작성자는 블로그의 현재 URL을 가리키는 alsoKnownAs 속성을 포함할 수 있습니다. 예:

"alsoKnownAs": ["https://myblog.blogging-host.example/home"]

이후 작성자가 블로그를 다른 호스팅 회사(또는 작성자 자신의 도메인)로 옮기면, 작성자는 DID 문서를 업데이트하여 블로그의 새 URL을 가리키게 할 수 있습니다. 예:

"alsoKnownAs": ["https://myblog.example/"]

DID는 블로그 URL에 간접 참조 계층을 사실상 추가합니다. 이 간접 참조 계층은 블로그 호스팅 회사와 같은 외부 관리 기관의 제어 아래가 아니라 작성자의 제어 아래에 있습니다. 이것이 DID가 시간이 지나면서 네트워크 위치가 변경될 수 있는 정보 리소스에 대한 지속적 식별자인 향상된 URN(Uniform Resource Name)으로 사실상 기능할 수 있는 방식입니다.

B.9 DID 컨트롤러와 DID 주체의 관계

이 절은 비규범적입니다.

혼동을 피하기 위해, DID 주체DID 컨트롤러와의 관계에 따라 서로 겹치지 않는 두 집합으로 분류하는 것이 유용합니다.

B.9.1 집합 #1: DID 주체가 DID 컨트롤러이다

이 절은 비규범적입니다.

그림 7에 표시된 첫 번째 경우는 DID 주체가 동시에 DID 컨트롤러인 일반적인 시나리오입니다. 이는 개인이나 조직이 자기 식별을 위해 DID를 생성하는 경우입니다.


DID 주체에서 DID 컨트롤러로 향하는 동등성 호가 있는 그래프 모델을 보여 주는 다이어그램.
그림 7 DID 주체DID 컨트롤러와 동일한 엔터티입니다. 함께 보기: 서술형 설명.
다이어그램에는 작은 검은색 원 두 개가 있으며, 왼쪽 위 원에는 "DID Controller"라는 레이블이, 오른쪽 위 원에는 "DID Subject"라는 레이블이 있습니다. 실선 빨간색 화살표가 DID Controller 원에서 DID Subject 원으로 뻗어 있으며, 화살표 위에는 큰 굵은 글씨로 "DID", 아래에는 작은 기울임꼴로 "Identifies"라고 표시되어 있습니다. "Equivalence"라는 레이블의 양방향 점선 빨간색 화살표는 두 원 사이와 위쪽 공간에 호를 그리며 이어져 있습니다. 다이어그램 아래쪽에는 검은색 윤곽의 접힌 모서리 직사각형이 있으며 "DID Document"라는 레이블이 들어 있습니다. 이 DID Document 직사각형과 DID Controller 및 DID Subject의 작은 검은색 원 사이에는 다음과 같은 기울임꼴 레이블의 화살표가 있습니다. 파란색 화살표는 DID Document에서 DID Subject를 가리키며 "Describes"라고 레이블이 붙어 있습니다. 초록색 화살표는 DID Controller에서 DID Document를 가리키며 "Controls"라고 레이블이 붙어 있습니다. 초록색 화살표는 DID Document에서 DID Controller로 바깥쪽 호를 그리며 가리키고 "Controller"라고 레이블이 붙어 있습니다. "Resolves to"라는 레이블의 점선 빨간색 화살표는 DID 컨트롤러에서 오른쪽으로 시작해 DID Subject로 향하는 화살표에서 갈라져 아래로 휘어 DID Document를 가리킵니다.

그래프 모델 관점에서 보면, DID 컨트롤러DID 주체로 식별된 노드가 그림 7에서 서로 구별되더라도, 의미론적 동등성 관계를 표현하기 위해 이들을 연결하는 논리적 호가 있습니다.

B.9.2 집합 #2: DID 주체가 DID 컨트롤러가 아니다

이 절은 비규범적입니다.

두 번째 경우는 DID 주체DID 컨트롤러와 별개의 엔터티인 경우입니다. 예를 들어, 부모가 자녀를 위한 DID를 만들고 제어를 유지하는 경우, 법인이 자회사를 위한 DID를 만들고 제어를 유지하는 경우, 또는 제조사가 제품, IoT 장치, 또는 디지털 파일을 위한 DID를 만들고 제어를 유지하는 경우입니다.

그래프 모델 관점에서 Set 1과의 유일한 차이는 DID 주체DID 컨트롤러 노드 사이에 동등성 호 관계가 없다는 점입니다.

B.10 여러 DID 컨트롤러

이 절은 비규범적입니다.

DID 문서는 둘 이상의 DID 컨트롤러를 가질 수 있습니다. 이는 두 가지 방식 중 하나로 발생할 수 있습니다.

B.10.1 독립 제어

이 절은 비규범적입니다.

이 경우, 각 DID 컨트롤러는 스스로 행동할 수 있습니다. 즉, 각 컨트롤러는 DID 문서를 독립적으로 업데이트할 완전한 권한을 가집니다. 그래프 모델 관점에서 이 구성에서는:

  • 추가되는 각 DID 컨트롤러는 또 하나의 별도 그래프 노드입니다 (자신의 DID로 식별될 수 있음).
  • DID 컨트롤러DID 문서 사이에는 동일한 호("controls" 및 "controller")가 존재합니다.

            각각 DID 문서와 독립적인 제어 관계를 가진 세 DID 컨트롤러를
            보여 주는 다이어그램
그림 8 각각 독립적으로 행동할 수 있는 여러 독립 DID 컨트롤러. 함께 보기: 텍스트 설명
왼쪽에는 세 개의 검은색 원이 세로로 나타나며, 각각 "DID Controller"라는 레이블이 있습니다. 이 각 원에서 한 쌍의 초록색 화살표가 다이어그램 중앙의 "DID Document"라고 레이블이 붙은 하나의 직사각형을 향해 뻗어 있습니다. 직사각형은 오른쪽 아래 모서리가 잘려 안쪽으로 접힌 작은 삼각형을 이루며, 말린 모서리가 있는 물리적 종이를 나타내는 것처럼 보입니다. 각 초록색 화살표 쌍은 검은색 원에서 직사각형을 가리키는 "Controls"라는 레이블의 화살표 하나와, 반대 방향인 직사각형에서 검은색 원을 가리키는 "Controller"라는 레이블의 화살표 하나로 구성됩니다. 직사각형 오른쪽에서는 "Describes"라는 레이블의 파란색 화살표가 "DID Subject"라고 레이블이 붙은 검은색 원을 가리킵니다.

B.10.2 그룹 제어

이 절은 비규범적입니다.

그룹 제어의 경우, DID 컨트롤러들은 여러 디지털 서명("multi-sig") 또는 임계 수의 디지털 서명("m-of-n")을 요구하는 암호학적 알고리즘을 사용하는 경우처럼, 어떤 방식으로든 함께 행동할 것으로 기대됩니다. 증명을 검증하기 위한 이러한 추가 임계값은 검증 방법에서, 5.2 검증 방법 절에 설명된 대로 표현될 수 있거나, 검증 방법의 검증 자료 자체에 내재할 수 있습니다. 이 경우 특정 디지털 서명 생성에 참여한 DID 컨트롤러의 수는 개인정보 보호상의 이유로 숨겨집니다. 그룹 구성원이 수행하는 암호학적 작업의 조합으로 증명을 생성해야 하는 검증 방법은 DID 문서의 내용을 제어하는 데 사용될 수 있으며, 이것이 정확히 어떻게 실현되는지는 개별 DID 메서드 명세에 따라 달라집니다.

기능적 관점에서 이 선택지는 단일 DID 컨트롤러와 유사합니다. DID 컨트롤러 그룹의 각 DID 컨트롤러가 자체 그래프 노드를 가지더라도, 실제 제어는 그림 9에 표시된 것처럼 DID 컨트롤러 그룹을 나타내는 단일 논리 그래프 노드로 축약되기 때문입니다.


DID 문서를 제어하기 위해 단일 DID 컨트롤러 그룹으로 함께 있는 세 DID 컨트롤러를
보여 주는 다이어그램
그림 9 DID 컨트롤러 그룹으로 함께 행동할 것으로 기대되는 여러 DID 컨트롤러. 함께 보기: 서술형 설명.
왼쪽에는 세 개의 검은색 채워진 원이 있으며, 왼쪽의 중괄호로 "DID Controller Group"이라고 레이블이 붙어 있습니다. 이 세 원 각각에서 초록색 화살표가 오른쪽 중앙으로 뻗어 있습니다. 이 세 화살표는 하나의 채워진 흰색 원을 향해 모입니다. 이 흰색 원의 오른쪽에는 수평 초록색 화살표 한 쌍이 연결되어 있으며, 이는 접힌 모서리가 있는 페이지 모양의 직사각형인 "DID Document"에 이어집니다. 위쪽 화살표는 흰색 원에서 직사각형으로 오른쪽을 가리키며 "Controls"라고 레이블이 붙어 있습니다. 아래쪽 화살표는 직사각형에서 흰색 원으로 왼쪽을 가리키며 "Controller"라고 레이블이 붙어 있습니다. 직사각형 오른쪽에서는 "Describes"라는 레이블의 파란색 화살표가 "DID Subject"라고 레이블이 붙은 검은색 원을 가리킵니다.

이 구성은 DID 주체가 단일 개인이 제어하지 않는 조직, 법인, 정부 기관, 커뮤니티 또는 기타 그룹인 경우에 자주 적용됩니다.

B.11 DID 주체 변경

이 절은 비규범적입니다.

DID 문서DID 주체를 참조하는 정확히 하나의 DID를 가집니다. DIDid 속성 값으로 표현됩니다. 이 속성 값은 DID 문서의 수명 동안 불변입니다.

그러나 DID식별하는 리소스, 즉 DID 주체는 시간이 지남에 따라 변경될 수 있습니다. 이는 DID 컨트롤러의 독점 권한 아래 있습니다. 자세한 내용은 8.10 지속성 절을 참조하십시오.

B.12 DID 컨트롤러 변경

이 절은 비규범적입니다.

DID 문서DID 컨트롤러는 시간이 지남에 따라 변경될 수 있습니다. 그러나 구현 방식에 따라 DID 컨트롤러의 변경이 DID 문서 자체의 변경으로 드러나지 않을 수 있습니다. 예를 들어, 변경이 DID 문서의 하나 이상의 검증 방법에 사용되는 기본 암호학적 키나 다른 제어 수단의 소유권 이동을 통해 구현되는 경우, 표준 키 회전과 구별하기 어려울 수 있습니다.

반면 변경이 controller 속성 값을 변경하여 구현되는 경우, 이는 투명하게 드러납니다.

DID 컨트롤러 변경을 검증하는 것이 중요한 경우, 구현자는 개정된 DID 문서검증 방법에 대해 새로운 DID 컨트롤러인증하는 것이 권고됩니다.

C. 개정 이력

이 절은 비규범적입니다.

이 절은 이 명세가 W3C 최초 공개 작업 초안으로 공개된 이후 이루어진 변경 사항을 포함합니다.

DID v1.0 권고안 이후의 변경 사항은 다음을 포함합니다:

DID v1.0 두 번째 후보 권고안 이후의 변경 사항은 다음을 포함합니다:

DID v1.0 첫 번째 후보 권고안 이후의 변경 사항은 다음을 포함합니다:

DID v1.0 최초 공개 작업 초안 이후의 변경 사항은 다음을 포함합니다:

D. 감사의 말

이 절은 비규범적입니다.

워킹 그룹은 생산적인 방향으로 워킹 그룹을 이끌고 표준화 절차의 깊고 위험한 물길을 헤쳐 나가도록 지칠 줄 모르고 노력해 준 의장 Brent Zundel 및 Dan Burnett, 그리고 W3C Staff Contact인 Ivan Herman에게 깊은 감사와 진심 어린 사의를 표합니다.

워킹 그룹은 이 명세의 작성으로 이어진 작업을 감사히 인정하며, 우리의 작업에 깊은 영향을 준 기술과 명세에 기여한 개인들에게 진심 어린 감사를 전합니다. 특히 여기에는 1990년대와 2000년대에 Pretty Good Privacy (PGP)에 대해 Phil Zimmerman, Jon Callas, Lutz Donnerhacke, Hal Finney, David Shaw, Rodney Thayer가 수행한 작업이 포함됩니다.

2010년대 중반, 이후 Decentralized Identifiers가 될 것의 초기 구현은 Jeremie Miller의 Telehash 프로젝트와 Dave Longley 및 Manu Sporny가 이끈 W3C Web Payments Community Group의 작업과 협력하여 만들어졌습니다. 약 1년 뒤, XDI.org Registry Working Group은 기존 식별자 레지스트리를 대체하기 위한 탈중앙화 기술 탐색을 시작했습니다. Decentralized Identifiers 개념을 탐구한 최초의 문서화된 논문들 중 일부는 Christopher Allen이 소집한 첫 여러 Rebooting the Web of Trust 워크숍으로 거슬러 올라갈 수 있습니다. 그 작업은 Christopher Allen, Drummond Reed, Les Chasen, Manu Sporny, Anil John 사이의 핵심 협업으로 이어졌습니다. Anil은 이 기술의 가능성을 보았고 이 영역을 탐색하기 위한 초기 정부 자금 세트를 배정했습니다. Anil John의 지원과 수년간의 안내가 없었다면, Decentralized Identifiers가 오늘날의 위치에 있기 어려웠을 것입니다. Rebooting the Web of Trust 워크숍에서의 추가 개선은 Drummond Reed, Les Chasen, Christopher Allen, Ryan Grant가 편집한 최초의 구현자 문서로 이어졌습니다. 기여자로는 Manu Sporny, Dave Longley, Jason Law, Daniel Hardman, Markus Sabadello, Christian Lundkvist, Jonathan Endersby가 포함되었습니다. 이 초기 작업은 이후 W3C Credentials Community Group으로 병합되어 추가로 인큐베이션되었고, 그 뒤 전 세계 표준화를 위해 W3C Decentralized Identifiers Working Group으로 이전되었습니다.

이 명세 작업의 일부는 United States Department of Homeland Security(US DHS) Science and Technology Directorate가 계약 HSHQDC-16-R00012-H-SB2016-1-002 및 HSHQDC-17-C-00019에 따라 자금을 지원했으며, US DHS Silicon Valley Innovation Program도 계약 70RSAT20T00000010, 70RSAT20T00000029, 70RSAT20T00000030, 70RSAT20T00000045, 70RSAT20T00000003, 70RSAT20T00000033에 따라 자금을 지원했습니다. 이 명세의 내용은 반드시 미국 정부의 입장이나 정책을 반영하는 것은 아니며, 공식적인 승인을 의미하는 것으로 추론해서는 안 됩니다.

이 명세 작업의 일부는 또한 European Union의 StandICT.eu 프로그램이 하위 보조금 계약 번호 CALL05/19에 따라 자금을 지원했습니다. 이 명세의 내용은 반드시 유럽연합의 입장이나 정책을 반영하는 것은 아니며, 공식적인 승인을 의미하는 것으로 추론해서는 안 됩니다.

이 명세 작업은 Christopher Allen, Shannon Appelcline, Kiara Robles, Brian Weller, Betty Dhamers, Kaliya Young, Kim Hamilton Duffy, Manu Sporny, Drummond Reed, Joe Andrieu, Heather Vescent가 촉진한 Rebooting the Web of Trust 커뮤니티의 지원도 받았습니다. 이 명세의 개발은 Kim Hamilton Duffy, Joe Andrieu, Christopher Allen, Heather Vescent, Wayne Chang이 의장을 맡아 온 W3C Credentials Community Group의 지원도 받았습니다. Phil Windley, Kaliya Young, Doc Searls, Heidi Nobantu Saul이 촉진한 Internet Identity Workshop 참가자들도 이 명세에 대해 토론하고, 개선하고, 참가자들을 교육하기 위해 설계된 수많은 작업 세션을 통해 이 작업을 지원했습니다.

워킹 그룹은 이 명세에 기여한 다음 개인들에게 감사를 표합니다(알파벳순, Github 핸들은 @로 시작하며 성 기준으로 정렬됨): Denis Ah-Kang, Nacho Alamillo, Christopher Allen, Joe Andrieu, Antonio, Phil Archer, George Aristy, Baha, Juan Benet, BigBlueHat, Dan Bolser, Chris Boscolo, Pelle Braendgaard, Daniel Buchner, Daniel Burnett, Juan Caballero, @cabo, Tim Cappalli, Melvin Carvalho, David Chadwick, Wayne Chang, Sam Curren, Hai Dang, Tim Daubenschütz, Oskar van Deventer, Kim Hamilton Duffy, Arnaud Durand, Ken Ebert, Veikko Eeva, @ewagner70, Carson Farmer, Nikos Fotiou, Gabe, Gayan, @gimly-jack, @gjgd, Ryan Grant, Peter Grassberger, Adrian Gropper, Amy Guy, Daniel Hardman, Kyle Den Hartog, Philippe Le Hegaret, Ivan Herman, Michael Herman, Alen Horvat, Dave Huseby, Marcel Jackisch, Mike Jones, Andrew Jones, Tom Jones, jonnycrunch, Gregg Kellogg, Michael Klein, @kdenhartog-sybil1, Paul Knowles, @ktobich, David I. Lehn, Charles E. Lehner, Michael Lodder, @mooreT1881, Dave Longley, Tobias Looker, Wolf McNally, Robert Mitwicki, Mircea Nistor, Grant Noble, Mark Nottingham, @oare, Darrell O'Donnell, Vinod Panicker, Dirk Porsche, Praveen, Mike Prorock, @pukkamustard, Drummond Reed, Julian Reschke, Yancy Ribbens, Justin Richer, Rieks, @rknobloch, Mikeal Rogers, Evstifeev Roman, Troy Ronda, Leonard Rosenthol, Michael Ruminer, Markus Sabadello, Cihan Saglam, Samu, Rob Sanderson, Wendy Seltzer, Mehran Shakeri, Jaehoon (Ace) Shim, Samuel Smith, James M Snell, SondreB, Manu Sporny, @ssstolk, Orie Steele, Shigeya Suzuki, Sammotic Switchyarn, @tahpot, Oliver Terbu, Ted Thibodeau Jr., Joel Thorstensson, Tralcan, Henry Tsai, Rod Vagg, Mike Varley, Kaliya "Identity Woman" Young, Eric Welton, Fuqiao Xue, @Yue, Dmitri Zagidulin, @zhanb, and Brent Zundel.

E. IANA 고려사항

이 절은 이 명세가 W3C 제안 권고안이 될 때 검토, 승인 및 IANA 등록을 위해 Internet Engineering Steering Group (IESG)에 제출될 것입니다.

E.1 application/did

유형 이름:
application
하위 유형 이름:
did
필수 매개변수:
없음
선택적 매개변수:
없음
인코딩 고려사항:
RFC 8259, section 11을 참조하십시오.
보안 고려사항:
DID Core v1.1, 보안 고려사항을 참조하십시오.
상호운용성 고려사항:
해당 없음
공개된 명세:
https://www.w3.org/TR/did/
이 미디어 유형을 사용하는 애플리케이션:
탈중앙화되고, 지속적이며, 암호학적으로 검증 가능하고, 해석 가능한 식별자가 필요한 모든 애플리케이션. 애플리케이션은 일반적으로 암호학적 신원 시스템, 장치들의 탈중앙화 네트워크, 그리고 검증 가능 자격 증명을 발급하거나 검증하는 웹사이트로 구성됩니다.
추가 정보:
매직 넘버:
해당 없음
파일 확장자:
.did
Macintosh 파일 유형 코드:
TEXT
추가 정보를 위한 연락 이메일 주소:
W3C Decentralized Identifiers Working Group public-did-wg@w3.org
의도된 사용:
일반
사용 제한:
없음
저자:
Drummond Reed, Manu Sporny, Markus Sabadello, Dave Longley, Christopher Allen
변경 관리자:
W3C

JSON-LD 환경에서 사용되는 프래그먼트 식별자는 JSON-LD 1.1: application/ld+json 미디어 유형 [JSON-LD11]과 관련된 규칙에 따라 처리됩니다. JSON 환경에서 사용되는 프래그먼트 식별자는 JSON-LD 환경의 프래그먼트 식별자와 동일한 의미론적 해석을 가집니다. 프래그먼트 해석을 수행하기 위한 알고리즘은 Controlled Identifiers v1.0 명세의 Section 3.4: Fragment Resolution에 제공되며, 이는 Decentralized Identifiers (DIDs) v1.1 명세에 의해 확장됩니다.

F. 참고문헌

F.1 규범 참고문헌

[CID]
Controlled Identifiers v1.0. Michael Jones; Manu Sporny. W3C. 2025년 5월 15일. W3C 권고안. URL: https://www.w3.org/TR/cid-1.0/
[DID-CORE]
Decentralized Identifiers (DIDs) v1.0. Manu Sporny; Amy Guy; Markus Sabadello; Drummond Reed. W3C. 2022년 7월 19일. W3C 권고안. URL: https://www.w3.org/TR/did-core/
[INFRA]
Infra Standard. Anne van Kesteren; Domenic Denicola. WHATWG. Living Standard. URL: https://infra.spec.whatwg.org/
[JSON-LD11]
JSON-LD 1.1. Gregg Kellogg; Pierre-Antoine Champin; Dave Longley. W3C. 2020년 7월 16일. W3C 권고안. URL: https://www.w3.org/TR/json-ld11/
[RFC2119]
RFC에서 요구 수준을 나타내기 위해 사용하는 핵심 단어. S. Bradner. IETF. 1997년 3월. Best Current Practice. URL: https://www.rfc-editor.org/rfc/rfc2119
[RFC3552]
보안 고려사항에 관한 RFC 텍스트 작성 지침. E. Rescorla; B. Korver. IETF. 2003년 7월. Best Current Practice. URL: https://www.rfc-editor.org/rfc/rfc3552
[RFC3986]
Uniform Resource Identifier (URI): Generic Syntax. T. Berners-Lee; R. Fielding; L. Masinter. IETF. 2005년 1월. Internet Standard. URL: https://www.rfc-editor.org/rfc/rfc3986
[RFC5234]
문법 명세를 위한 Augmented BNF: ABNF. D. Crocker, Ed.; P. Overell. IETF. 2008년 1월. Internet Standard. URL: https://www.rfc-editor.org/rfc/rfc5234
[RFC6838]
미디어 유형 명세 및 등록 절차. N. Freed; J. Klensin; T. Hansen. IETF. 2013년 1월. Best Current Practice. URL: https://www.rfc-editor.org/rfc/rfc6838
[RFC8174]
RFC 2119 핵심 단어의 대문자와 소문자 모호성. B. Leiba. IETF. 2017년 5월. Best Current Practice. URL: https://www.rfc-editor.org/rfc/rfc8174
[RFC8259]
JavaScript Object Notation (JSON) Data Interchange Format. T. Bray, Ed. IETF. 2017년 12월. Internet Standard. URL: https://www.rfc-editor.org/rfc/rfc8259
[URL]
URL Standard. Anne van Kesteren. WHATWG. Living Standard. URL: https://url.spec.whatwg.org/
[XMLSCHEMA11-2]
W3C XML Schema Definition Language (XSD) 1.1 Part 2: Datatypes. David Peterson; Sandy Gao; Ashok Malhotra; Michael Sperberg-McQueen; Henry Thompson; Paul V. Biron et al. W3C. 2012년 4월 5일. W3C 권고안. URL: https://www.w3.org/TR/xmlschema11-2/

F.2 정보 참고문헌

[DID-1.1]
Decentralized Identifiers (DIDs) v1.1. Manu Sporny; Dmitri Zagidulin. W3C. 2026년 2월 21일. W3C 작업 초안. URL: https://www.w3.org/TR/did-1.1/
[DID-EXTENSIONS]
Decentralized Identifier Extensions. Manu Sporny; Markus Sabadello. W3C. 2025년 12월 11일. W3C Working Group Note. URL: https://www.w3.org/TR/did-extensions/
[DID-RESOLUTION]
Decentralized Identifier Resolution (DID Resolution) v0.3. Markus Sabadello; Dmitri Zagidulin. W3C. 2026년 2월 8일. W3C 작업 초안. URL: https://www.w3.org/TR/did-resolution/
[DID-RUBRIC]
DID Method Rubric v1.0. Joe Andrieu; Daniel Hardman. W3C. 2021년 11월 19일. W3C Working Group Note. URL: https://www.w3.org/TR/did-rubric/
[DID-USE-CASES]
탈중앙화 식별자를 위한 사용 사례 및 요구사항. Joe Andrieu; Phil Archer; Kim Duffy; Ryan Grant; Adrian Gropper. W3C. 2021년 3월 17일. W3C Working Group Note. URL: https://www.w3.org/TR/did-use-cases/
[DNS-DID]
DNS에서의 탈중앙화 식별자(DID). Alexander Mayrhofer; Dimitrij Klesev; Markus Sabadello. 2019년 2월. Internet-Draft. URL: https://datatracker.ietf.org/doc/draft-mayrhofer-did-dns/
[IANA-URI-SCHEMES]
Uniform Resource Identifier (URI) Schemes. IANA. URL: https://www.iana.org/assignments/uri-schemes/uri-schemes.xhtml
[MATRIX-URIS]
Matrix URIs - 웹 아키텍처에 관한 아이디어. Tim Berners-Lee. 1996년 12월. 개인 견해. URL: https://www.w3.org/DesignIssues/MatrixURIs.html
[PRIVACY-BY-DESIGN]
Privacy by Design. Ann Cavoukian. Information and Privacy Commissioner. 2011. URL: https://iapp.org/media/pdf/resource_center/pbd_implement_7found_principles.pdf
[RFC6901]
JavaScript Object Notation (JSON) Pointer. P. Bryan, Ed.; K. Zyp; M. Nottingham, Ed. IETF. 2013년 4월. Proposed Standard. URL: https://www.rfc-editor.org/rfc/rfc6901
[RFC6973]
인터넷 프로토콜을 위한 개인정보 보호 고려사항. A. Cooper; H. Tschofenig; B. Aboba; J. Peterson; J. Morris; M. Hansen; R. Smith. IETF. 2013년 7월. Informational. URL: https://www.rfc-editor.org/rfc/rfc6973
[RFC8141]
Uniform Resource Names (URNs). P. Saint-Andre; J. Klensin. IETF. 2017년 4월. Proposed Standard. URL: https://www.rfc-editor.org/rfc/rfc8141
[RFC9110]
HTTP Semantics. R. Fielding, Ed.; M. Nottingham, Ed.; J. Reschke, Ed. IETF. 2022년 6월. Internet Standard. URL: https://httpwg.org/specs/rfc9110.html
[VC-DATA-MODEL]
Verifiable Credentials Data Model v2.0. Ivan Herman; Michael Jones; Manu Sporny; Ted Thibodeau Jr; Gabe Cohen. W3C. 2025년 5월 15일. W3C 권고안. URL: https://www.w3.org/TR/vc-data-model-2.0/