Copyright © 2026 World Wide Web Consortium. W3C® liability, trademark and permissive document license rules apply.
탈중앙화 식별자(DID)는 검증 가능하고 탈중앙화된 디지털 신원을 가능하게 하는 새로운 유형의 식별자입니다. DID는 DID의 컨트롤러가 결정한 모든 주체(예: 사람, 조직, 사물, 데이터 모델, 추상 엔터티 등)를 가리킵니다. 일반적인 연합 식별자와 달리, DID는 중앙화된 레지스트리, 신원 제공자 및 인증 기관으로부터 분리될 수 있도록 설계되었습니다. 구체적으로, 다른 당사자가 DID와 관련된 정보의 발견을 가능하게 하는 데 사용될 수도 있지만, 이 설계는 DID의 컨트롤러가 다른 어떤 당사자의 허가도 필요로 하지 않고 그에 대한 제어권을 증명할 수 있게 합니다. DID는 URI이며, DID 주체를 DID 문서와 연결하여 그 주체와 관련된 신뢰할 수 있는 상호작용을 가능하게 합니다.
각 DID 문서는 암호화 자료, 검증 방법 또는 서비스를 표현할 수 있으며, 이는 DID 컨트롤러가 DID에 대한 제어권을 증명할 수 있게 하는 일련의 메커니즘을 제공합니다. 서비스는 DID 주체와 관련된 신뢰할 수 있는 상호작용을 가능하게 합니다. DID는 DID 주체가 데이터 모델과 같은 정보 리소스인 경우, DID 주체 자체를 반환하는 수단을 제공할 수도 있습니다.
이 문서는 DID 구문, 공통 데이터 모델, 핵심 속성, 직렬화된 표현, DID 작업, 그리고 DID를 그것이 나타내는 리소스로 해석하는 과정에 대한 설명을 명시합니다.
이 절은 이 문서가 공개된 시점의 상태를 설명합니다. 현재 W3C 간행물 목록과 이 기술 보고서의 최신 개정판은 W3C 표준 및 초안 색인에서 확인할 수 있습니다.
W3C 탈중앙화 식별자 워킹 그룹은 이 문서를 W3C 후보 권고안으로 공개했으며, 소프트웨어 개발자와 DID 메서드 명세 작성자에게 이 문서의 모든 기능의 구현 가능성을 시험하도록 설계된 실험적 구현을 제공할 것을 요청합니다.
구현자는 이슈 트래커에 class 1, 2 또는 3 공개 이슈가 나열되어 있는 경우, 해당 이슈가 명세 변경으로 이어질 수 있음을 유의해야 합니다.
W3C 후보 권고안 단계를 종료하기 위해, W3C DID 워킹 그룹은 다음을 요구합니다.
기능은 명세의 하나 이상의 기능적으로 관련된 규범 문장으로 정의됩니다. 이 명세에서 상호운용성은 데이터 모델 속성과 그 값에 관한 것과 같은 규범 문장이 서로 다른 두 DID 메서드 사이에서 같은 방식으로 해석되는 것으로 정의됩니다.
특정 DID 메서드의 해석은 이 명세의 범위를 벗어나며, 탈중앙화 식별자 해석(DID Resolution) v0.3 명세에서 다룹니다.
이 문서는 탈중앙화 식별자 워킹 그룹이 권고안 트랙을 사용하여 후보 권고안 스냅샷으로 공개했습니다.
후보 권고안으로 공개되었다고 해서 W3C 및 그 회원의 승인을 의미하지는 않습니다. 후보 권고안 스냅샷은 광범위한 검토를 받았고, 구현 경험을 수집하기 위한 것이며, 워킹 그룹 회원으로부터 구현에 대한 로열티 없는 라이선스 약속을 받았습니다.
이 후보 권고안은 2026년 4월 5일보다 이른 시점에 권고안으로 진행될 것으로 예상되지 않습니다.
이 문서는 W3C 특허 정책에 따라 운영되는 그룹에서 작성되었습니다. W3C는 그룹의 산출물과 관련하여 이루어진 모든 특허 공개의 공개 목록을 유지관리하며, 해당 페이지에는 특허 공개 방법에 대한 지침도 포함되어 있습니다. 자신이 알고 있는 특허가 필수 청구항을 포함한다고 믿는 실제 지식을 가진 개인은 W3C 특허 정책 제6절에 따라 해당 정보를 공개해야 합니다.
이 문서는 2025년 8월 18일 W3C 절차 문서의 적용을 받습니다.
이 절은 비규범적입니다.
개인과 조직으로서, 우리 중 많은 사람은 매우 다양한 맥락에서 전역적으로 고유한 식별자를 사용합니다. 이러한 식별자는 통신 주소(전화 번호, 이메일 주소, 소셜 미디어 사용자 이름), ID 번호(여권, 운전면허증, 세금 ID, 건강 보험), 그리고 제품 식별자(일련 번호, 바코드, RFID)로 쓰입니다. URI(Uniform Resource Identifiers)는 웹의 리소스에 사용되며, 브라우저에서 보는 각 웹 페이지에는 전역적으로 고유한 URL(Uniform Resource Locator)이 있습니다.
이러한 전역적으로 고유한 식별자의 대부분은 우리의 통제 아래 있지 않습니다. 이들은 외부 기관이 발급하며, 해당 기관이 누구 또는 무엇을 가리키는지와 언제 폐기될 수 있는지를 결정합니다. 이들은 특정 맥락에서만 유용하고, 우리가 선택하지 않은 특정 주체에 의해서만 인식됩니다. 조직의 실패와 함께 사라지거나 더 이상 유효하지 않게 될 수 있습니다. 또한 불필요하게 개인 정보를 드러낼 수도 있습니다. 많은 경우, 이들은 악의적인 제3자에 의해 부정하게 복제되고 주장될 수 있으며, 이는 일반적으로 "신원 도용"으로 알려져 있습니다.
이 명세에서 정의하는 탈중앙화 식별자(DID)는 새로운 유형의 전역적으로 고유한 식별자입니다. 이는 개인과 조직이 신뢰하는 시스템을 사용하여 자체 식별자를 생성할 수 있도록 설계되었습니다. 이러한 새로운 식별자는 엔터티가 디지털 서명과 같은 암호학적 증명을 사용해 인증함으로써 그 식별자에 대한 제어권을 증명할 수 있게 합니다.
탈중앙화 식별자의 생성과 주장은 엔터티가 제어하므로, 각 엔터티는 자신이 원하는 신원, 페르소나 및 상호작용의 분리를 유지하는 데 필요한 만큼 많은 DID를 가질 수 있습니다. 이러한 식별자의 사용은 서로 다른 맥락에 맞게 적절히 범위가 지정될 수 있습니다. 이는 엔터티가 자신 또는 자신이 제어하는 사물을 식별해야 하는 다른 사람, 기관 또는 시스템과의 상호작용을 지원하면서, 개인 데이터 또는 사적 데이터가 얼마나 공개되어야 하는지를 제어할 수 있게 하며, 이 모든 것은 식별자의 지속적인 존재를 보장하기 위해 중앙 기관에 의존하지 않고 이루어집니다. 이러한 아이디어는 DID 사용 사례 문서 [DID-USE-CASES]에서 살펴봅니다.
이 명세는 DID의 생성, 지속성, 해석 또는 해석 결과의 의미 부여를 뒷받침하기 위해 특정 기술이나 암호 방식을 전제로 하지 않습니다. 예를 들어, 구현자는 연합 또는 중앙화된 신원 관리 시스템에 등록된 식별자를 기반으로 탈중앙화 식별자를 만들 수 있습니다. 실제로 거의 모든 유형의 식별자 시스템은 DID 지원을 추가할 수 있습니다. 이는 중앙화, 연합, 탈중앙화 식별자의 세계 사이에 상호운용성 다리를 만듭니다. 또한 구현자가 분산 원장, 탈중앙화 파일 시스템, 분산 데이터베이스 및 피어 투 피어 네트워크와 같이 자신이 신뢰하는 컴퓨팅 인프라와 함께 작동하도록 특정 유형의 DID를 설계할 수 있게 합니다.
이 명세는 다음을 위한 것입니다.
이 명세에 더해, 독자는 탈중앙화 식별자의 사용 사례 및 요구사항 [DID-USE-CASES] 문서도 유용하다고 느낄 수 있습니다.
이 절은 비규범적입니다.
DID는 세
부분으로 구성된 단순한 텍스트 문자열입니다. 1)
did URI 스킴 식별자, 2) DID 메서드의 식별자, 그리고 3)
DID 메서드별 식별자입니다.
위의 예시 DID는 DID 문서로 해석됩니다. DID 문서는 DID와 관련된 정보를 포함합니다. 예를 들면 인증을 통해 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"
}]
}
이 절은 비규범적입니다.
탈중앙화 식별자는 검증 가능 자격 증명 생태계 [VC-DATA-MODEL]와 같은 더 큰 시스템의 구성 요소이며, 이는 이 명세의 설계 목표에 영향을 주었습니다. 탈중앙화 식별자의 설계 목표는 여기에 요약되어 있습니다.
| 목표 | 설명 |
|---|---|
| 탈중앙화 | 전역적으로 고유한 식별자, 공개 검증 키, 서비스 및 기타 정보의 등록을 포함하여, 식별자 관리에서 중앙 기관 또는 단일 장애 지점에 대한 요구를 제거합니다. |
| 제어 | 인간 및 비인간 엔터티 모두에게 외부 기관에 의존할 필요 없이 자신의 디지털 식별자를 직접 제어할 권한을 부여합니다. |
| 개인정보 보호 | 속성 또는 기타 데이터의 최소, 선택적, 점진적 공개를 포함하여 엔터티가 자신의 정보의 개인정보 보호를 제어할 수 있게 합니다. |
| 보안 | 요청 당사자가 요구하는 보증 수준에 대해 DID 문서에 의존할 수 있도록 충분한 보안을 가능하게 합니다. |
| 증명 기반 | DID 컨트롤러가 다른 엔터티와 상호작용할 때 암호학적 증명을 제공할 수 있게 합니다. |
| 발견 가능성 | 엔터티가 다른 엔터티에 대해 더 알아보거나 상호작용하기 위해 다른 엔터티의 DID를 발견할 수 있게 합니다. |
| 상호운용성 | 상호운용 가능한 표준을 사용하여 DID 인프라가 상호운용성을 위해 설계된 기존 도구와 소프트웨어 라이브러리를 사용할 수 있게 합니다. |
| 이식성 | 시스템 및 네트워크에 독립적이고, 엔터티가 DID와 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 메서드가 지정하는 고유한
메서드별 식별자입니다. DID는
DID 문서로 해석될 수 있습니다. DID URL은
기본 DID의 구문을 확장하여
경로, 쿼리, 프래그먼트와 같은 표준 URI 구성 요소를 포함함으로써 특정
리소스를 찾습니다. 예를 들어 DID 문서 내부의
암호학적 공개 키 또는
리소스가
DID 문서 외부에 있을 수 있습니다.
이러한 개념은 3.1 DID 구문 및
3.2 DID URL 구문에서 자세히 설명합니다.
비규범적이라고 표시된 절과 마찬가지로, 이 명세의 모든 작성 지침, 다이어그램, 예제 및 참고 사항은 비규범적입니다. 이 명세의 그 밖의 모든 내용은 규범적입니다.
이 문서의 핵심 단어 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]에 등록될 것으로 기대됩니다.
DID와 DID 문서에 대한 구현의 상호운용성은 구현이 이 명세에 적합한 DID와 DID 문서를 만들고 파싱하는 능력을 평가하여 테스트합니다. DID와 DID 문서의 생산자와 소비자에 대한 상호운용성은 DID와 DID 문서가 적합함을 보장함으로써 제공됩니다. DID 메서드 명세에 대한 상호운용성은 각 DID 메서드 명세의 세부 사항에 의해 제공됩니다. 웹 브라우저가 알려진 모든 URI 스킴을 구현할 필요가 없는 것과 마찬가지로, DID와 함께 작동하는 적합한 소프트웨어도 알려진 모든 DID 메서드를 구현할 필요는 없다고 이해됩니다. 그러나 주어진 DID 메서드의 모든 구현은 그 메서드에 대해 상호운용될 것으로 기대됩니다.
적합한 DID는 3. 식별자에 명시된 규칙의 구체적 표현 중 해당 절의 관련 규범 문장을 준수하는 모든 것입니다.
적합한 DID 문서는 이 명세에 설명된 데이터 모델의 구체적 표현 중 4. 데이터 모델 및 5. 핵심 속성의 관련 규범 문장을 준수하는 모든 것입니다. 적합한 문서를 위한 직렬화 형식은 6. 표현에 설명된 것처럼 결정적이고, 양방향이며, 무손실입니다.
적합한 생산자는 적합한 DID 또는 적합한 DID 문서를 생성하고 6. 표현의 관련 규범 문장을 준수하는, 소프트웨어 및/또는 하드웨어로 실현된 모든 알고리즘입니다.
적합한 소비자는 적합한 DID 또는 적합한 DID 문서를 소비하고 6. 표현의 관련 규범 문장을 준수하는, 소프트웨어 및/또는 하드웨어로 실현된 모든 알고리즘입니다.
적합한 DID 메서드는 7. 메서드의 관련 규범 문장을 준수하는 모든 명세입니다.
이 절은 비규범적입니다.
이 명세에는 두 가지 주요 대상 독자가 있습니다. 적합한 DID 메서드의 구현자와, DID와 상호작용하고 인터페이스하려는 시스템 및 서비스의 구현자입니다. 의도된 대상 독자는 소프트웨어 아키텍트, 데이터 모델러, 애플리케이션 개발자, 서비스 개발자, 테스터, 운영자, 사용자 경험(UX) 전문가를 포함하지만 이에 국한되지는 않습니다. 탈중앙화 신원, 검증 가능 자격 증명, 보안 저장소와 관련된 광범위한 표준화 작업에 참여하는 다른 사람들도 이 명세를 읽는 데 관심이 있을 수 있습니다.
이 절은 비규범적입니다.
이 절은 이 명세와 탈중앙화 식별자 인프라 전반에서 사용되는 용어를 정의합니다. 이러한 용어가 이 명세에 나타날 때마다 해당 용어에 대한 링크가 포함됩니다.
controller 속성으로 표시될 수 있습니다. DID 컨트롤러가 DID
주체일 수도 있음에 유의하십시오.
U+0023 NUMBER SIGN) 뒤에 오는 부분입니다. DID 프래그먼트 구문은
URI 프래그먼트 구문과 동일합니다.
U+002F SOLIDUS)로 시작하여 그 문자를 포함하고,
? 문자
(U+003F QUESTION MARK),
# 문자
(U+0023 NUMBER SIGN),
또는 DID URL의 끝까지 중 먼저 나오는 지점에서 끝나되,
그 지점은 포함하지 않는 부분입니다. DID 경로 구문은 URI 경로 구문과 동일합니다.
경로를 참조하십시오.
U+003F QUESTION MARK) 뒤에 오며 그 문자를 포함하는 부분입니다.
DID 쿼리 구문은 URI 쿼리
구문과 동일합니다. 쿼리를 참조하십시오.
did:로 시작합니다.
각 DID 메서드
명세는 해당 특정 DID 메서드와 함께 작동하는 특정
DID 메서드 스킴을 정의합니다. 특정 DID
메서드 스킴에서 DID 메서드 이름은 첫 번째 콜론 뒤에 오며
두 번째 콜론에서 끝납니다. 예: did:example:
U+002F SOLIDUS)가 있는 선택적 DID
경로,
선행
? 문자
(U+003F QUESTION MARK)가 있는 선택적 DID 쿼리,
그리고 선행
# 문자
(U+0023 NUMBER SIGN)가 있는 선택적 DID 프래그먼트가 포함됩니다.
위의 용어 외에도, 이 명세는 데이터 모델을 공식적으로 정의하기 위해 [INFRA] 명세의 용어도 사용합니다. [INFRA] 용어가 사용될 때, 예를 들어 문자열, 집합, 그리고 맵과 같은 용어는 해당 명세로 직접 링크됩니다.
이 절은 DID와 DID URL의 공식 구문을 설명합니다. 여기에서 정의된 구문을 각자의 명세에서 특정 DID 메서드가 정의하는 구문과 구별하기 위해 "generic"이라는 용어를 사용합니다. DID와 DID URL의 생성 과정과 그 시점은 7.2 메서드 작업 및 B.2 DID 생성에 설명되어 있습니다.
일반 DID 스킴은 [RFC3986]에 적합한
URI
스킴입니다. ABNF
정의는 아래에서 찾을 수 있으며, 이는
[RFC5234]의 구문과
ALPHA 및
DIGIT에 대한 해당 정의를 사용합니다. 아래 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 메서드 구문 절을 참조하십시오.
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.3의
path-abempty ABNF 규칙을 준수합니다.
URI와 마찬가지로, 경로 의미론은 DID 메서드에 의해 지정될
수 있으며, 이는
다시 DID 컨트롤러가 그 의미론을 추가로 특수화할 수 있게
할 수 있습니다.
did:example:123456/path
DID 쿼리는 일반 URI 쿼리와 동일하며
RFC 3986, section 3.4의
query ABNF 규칙을 준수합니다.
did:example:123456?versionId=1
구현자는 그 목적을 위해 특별히 설계된 명세가 없는 경우, 둘 이상의 쿼리 매개변수를 가진 DID URL을 동등성 기준으로 비교하지 않는 것이 강력히 권장됩니다. 이 명세는 쿼리 매개변수에 대한 정규화 규칙을 정의하지 않으며, DID 메서드 명세 또는 애플리케이션 계층에서 정의된 쿼리 매개변수 정규화 규칙도 보편적으로 인식되는 규칙이 아닙니다.
DID 프래그먼트 구문과 의미론은 일반
URI
프래그먼트와 동일하며,
RFC 3986, section 3.5의
fragment ABNF 규칙을 준수합니다.
DID 프래그먼트는 DID 문서 또는 외부 리소스에 대한 메서드 독립적 참조로 사용됩니다. DID 프래그먼트 식별자의 몇 가지 예가 아래에 나와 있습니다.
did:example:123#public-key-1
did:example:123#service-5
상호운용성을 극대화하기 위해, 구현자는 DID 프래그먼트가 표현 전반에서 동일한 방식으로 해석되도록 보장할 것이 권장됩니다 (6. 표현 참조). 예를 들어, JSON Pointer [RFC6901]는 DID 프래그먼트에서 사용할 수 있지만, 비 JSON 표현 전반에서 동일한 방식으로 해석되지는 않습니다.
이 절의 의미론과 호환되며 그 위에 계층화되는 프래그먼트 식별자에 대한 추가 의미론은 미디어 유형 설명에 지정되어 있습니다(섹션 E.1 application/did 참조). DID 프래그먼트를 역참조하는 방법에 대한 정보는 탈중앙화 식별자 해석(DID Resolution) v0.3 명세를 참조하십시오.
상대 DID URL은
DID 문서 안의 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
주체를 참조하십시오.
scheme은 did입니다. authority는
<method-name>:<method-specific-id>의 조합이며,
path, query, 그리고 fragment
값은 각각 경로, 쿼리, 그리고 프래그먼트에
정의된 값입니다.
상대 DID URL은 절대 URL을 사용하지 않고 검증 방법 및 서비스를 DID 문서 안에서 참조하는 데 자주 사용됩니다. 저장 크기가 고려사항인 DID 메서드는 상대 URL을 사용하여 DID 문서의 저장 크기를 줄일 수 있습니다.
{
"@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 값으로 변환됩니다.
이 명세는 DID 문서와 그 내부 데이터 구조를 표현하는 데 사용할 수 있는 데이터 모델을 정의하며, 이는 이후 구체적 표현으로 직렬화될 수 있습니다. 이 절은 데이터 모델에 대한 상위 수준의 설명, 서로 다른 유형의 속성이 데이터 모델에서 표현되는 방식에 대한 설명, 그리고 데이터 모델을 확장하기 위한 지침을 제공합니다.
DID 문서는 map의 entry들로 구성되며, 각 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의 순서는 중요하지 않으며, 구현이 결정적으로 순서가 지정된 값을 생산하거나 소비할 것으로 기대되지는 않습니다.
데이터 모델은 두 가지 유형의 확장성을 지원합니다.
두 특정 구현이 대역 외에서 합의하여 탈중앙화 식별자 확장 저장소에 기록되지 않은 상호 이해된 확장 또는 표현을 사용하는 것은 언제나 가능합니다. 그러나 그러한 구현과 더 큰 생태계 사이의 상호운용성은 덜 신뢰할 수 있습니다.
DID는 DID 문서와 연결되며, 이는 Controlled Identifiers v1.0에 정의된 controlled identifier document의 확장입니다. DID 문서는 데이터 모델을 사용해 표현되며 표현으로 직렬화될 수 있습니다. 다음 절에서는 DID 문서의 속성을 정의하며, 이러한 속성이 필수인지 선택 사항인지도 포함합니다. 이러한 속성은 DID 주체와 해당 속성 값 사이의 관계를 설명합니다.
다음 표는 이 명세가 정의하는 핵심 속성에 대한 정보적 참조, 예상 값, 그리고 필수 여부를 포함합니다. 표의 속성 이름은 각 속성의 규범적 정의와 더 자세한 설명으로 링크됩니다.
속성 이름 id, type, 그리고
controller는 서로 다른 유형의 map에 존재할 수 있으며
제약 조건이 다를 수 있습니다. 예를 들어,
DID 문서의 최상위 수준에 있는 id는 DID여야 하지만,
service map의
id는 URL일 수 있습니다.
| 속성 | 필수? | 값 제약 조건 | 정의 |
|---|---|---|---|
id |
예 | string이며, 3.2 DID URL 구문의 규칙을 준수합니다. | Controlled Identifiers v1.0 명세의 Section 2.1.1: Subjects 및 5.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. |
이 절은 DID 문서가 DID 주체와 DID 컨트롤러의 식별자를 포함하는 메커니즘을 설명합니다.
특정 DID 주체에 대한 DID는
DID 문서의
id 속성을 사용해 표현됩니다. 이 속성은
Controlled
Identifiers v1.0 명세의
Section 2.1.1: Subjects에 정의되어 있으며,
이 명세에서
3.1
DID 구문 절에 정의된
탈중앙화 식별자를 포함하도록 확장됩니다.
{
"id": "did:example:123456789abcdefghijk"
}
DID 컨트롤러는 DID 문서를 변경할 권한이 있는 엔터티입니다. 이 속성은 Controlled Identifiers v1.0 명세의 Section 2.1.2: Controllers에 정의되어 있으며, 이 명세에서 3.1 DID 구문 절에 정의된 DID를 포함하도록 확장됩니다. DID 컨트롤러를 승인하는 과정은 DID 메서드에 의해 정의됩니다.
{
"@context": "https://www.w3.org/ns/did/v1.1",
"id": "did:example:123456789abcdefghi",
"controller": "did:example:bcehfew7h32f32h7af3"
}
DID 문서에서
DID 주체 또는 DID
컨트롤러를 식별하는 데 사용되는 식별자는 쿼리 매개변수나 프래그먼트 식별자를 사용할 수 없습니다.
구현자는 이 요구사항을 명확히 하는
3.1
DID 구문 절의 허용 문자 목록에
특히 주의를 기울이는 것이 권장됩니다. 해당
구문은 ? 문자나 # 문자를 포함하지 않습니다. 이는
DID 문서에서
verification
method 또는 service를 식별하는 데 사용되는 식별자와 대조적입니다. 이들은
쿼리 매개변수와 프래그먼트 식별자의 사용을 허용하는
3.2 DID URL 구문 절의 구문 규칙을 따릅니다. 그럼에도,
DID 생태계를 위해 만들어진 장기적인 정식
식별자에서 쿼리 매개변수를 사용하는 것은
DID 해석 소프트웨어의 복잡성을 증가시키고
잠재적으로 더 큰 보안 공격 표면으로 이어질 수 있으므로 권장되지 않습니다.
프래그먼트 식별자 또한 특정 DID 문서 내에서 고유할 것으로 기대되며,
구현자는 같은 DID 문서 내의 서로 다른 두
verification
method와 같이,
시간이 지나면서 서로 다른 리소스를 가리키도록 재사용하지 않는 것이
권장됩니다.
DID 문서는
Controlled Identifiers
v1.0의
2.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를
참조하십시오.
DID 문서는 Controlled Identifiers v1.0 명세의 Section 2.3: Verification Relationships에 정의된 verification relationship를 표현할 수 있습니다. verification method에 대한 설명은 Controlled Identifiers v1.0 명세의 Section 2.3: Verification Relationships를 참조하십시오.
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를 참조하십시오.
이 명세에서 DID 문서의 구체적 직렬화를 표현이라고 합니다. 표현은 생산이라고 하는 과정을 통해 데이터 모델을 직렬화하여 생성됩니다. 표현은 소비라고 하는 과정을 통해 데이터 모델로 변환됩니다. 생산 및 소비 과정은 정보를 하나의 표현에서 다른 표현으로 변환할 수 있게 합니다. 이 명세는 JSON을 위한 단일 표현을 정의하며, 이는 JSON-LD 처리를 수행하는 처리기와도 호환됩니다. 다음 절에서는 생산 및 소비에 대한 일반 규칙과 JSON 표현을 정의합니다.
이 명세에서 정의된 표현 외에도, 구현자는 각각의 표현이 적절히 명시되어 있다면(여기에는 DID Extensions 저장소 [DID-EXTENSIONS]에 나열되지 않은 속성의 상호운용 가능한 처리 규칙 포함), 다른 표현을 사용할 수 있습니다. 자세한 내용은 4.1 확장성을 참조하십시오.
모든 표현에 대한 요구사항은 다음과 같습니다.
dateTime 어휘 직렬화를 사용합니다. 표현은
소비 과정이 다시 데이터 모델로 손실 없이 변환되는 한,
다른 어휘 직렬화를 사용하여 데이터 모델 데이터 유형을 직렬화하도록
선택할 MAY 있습니다. 예를 들어, 일부 CBOR 기반
표현은
Unix epoch 이후의 초 수를 나타내는 정수를 사용하여 datetime 값을 표현합니다.
모든 적합한 생산자에 대한 요구사항은 다음과 같습니다.
모든 적합한 소비자에 대한 요구사항은 다음과 같습니다.
다이어그램의 왼쪽 위 사분면에는 회색 점선 윤곽의 직사각형이 있으며, 그 안에는 파란색 윤곽의 직사각형 두 개가 위아래로 들어 있습니다. 위쪽의 더 큰 직사각형에는 파란색으로 "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"
]
}
이 절은 JSON 표현에 대한 생산 및 소비 규칙을 정의합니다.
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 합니다.
{
"@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"
}]
}
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 합니다.
JSON-LD는 Linked Data를 직렬화하는 데 사용되는 JSON 기반 형식입니다. 일부 구현은 표준 JSON-LD 처리 알고리즘을 사용하여 DID 문서를 처리할 것으로 기대됩니다. 상호운용성을 극대화하기 위해, 구현자는 표준을 준수하는 라이브러리를 사용한 JSON-LD 처리가 방해받지 않도록 보장하는 것이 강력히 권고됩니다. 표준을 준수하는 라이브러리를 사용한 JSON-LD 처리가 수행되든 수행되지 않든 DID 문서의 의미론은 동일합니다. 의미론의 차이는 구현 또는 DID 메서드 명세의 오류입니다.
JSON-LD 처리가 발생하려면, @context 속성이
JSON-LD
1.1 명세에 지정된 규칙에 따라
지정되어야 MUST 합니다.
DID 문서, DID 문서 데이터 구조 및 표현별 항목 map은 6.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 합니다.
{
"@context": "https://www.w3.org/ns/did/v1.1",
...
}
{
"@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 됩니다.
구현은 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 캐시 시간은 무한대로 설정되지 않으며, 구현자는 암호학적 해시 값의 변경이 감지되면 정오표를 확인하는 것이 권고됩니다.
[RFC6838]에 정의된 미디어 유형은 DID 문서를 표현하는 데 사용되는 구문과 기타 유용한 처리 지침을 식별합니다.
이 명세의 데이터 모델을 표현하는 데 사용되는 구문은 미디어 유형으로 식별되는 것이 SHOULD 되며, DID 문서와 함께 미디어 유형을 정의하거나 사용할 때는 이 절에 설명된 관례를 따르는 것이 SHOULD 됩니다.
핵심 데이터 모델과 관련된 미디어 유형은 하나이며,
이는 E. IANA 고려사항 절에 나열되어 있습니다.
application/did.
이 절은 비규범적입니다.
때때로 개발자나 시스템은 정밀도가 낮은 미디어 유형을 사용하여 DID 문서를 전달할 수 있습니다. 정밀도가 낮은 미디어 유형을 사용하는 이유 중 일부는 다음과 같습니다.
text/plain 또는 application/octet-stream을 기본값으로 사용합니다.
.json은
application/json 미디어 유형이 될 수 있고, .jsonld는
application/ld+json 미디어 유형이 될 수 있습니다.
application/did 대신 application/json이 사용됩니다.
사용된 미디어 유형이 주어진 프로토콜에서 허용되는 경우, 페이로드에서
의도된 미디어 유형을 확인할 수 있다면 구현자는 오류를 발생시키지 않는 것이
권장됩니다. 예를 들어, 애플리케이션이 application/did 미디어
유형과 관련된 규칙을 준수하는 페이로드만 허용하지만, 페이로드에
정밀도가 낮은 application/json 또는
application/ld+json 태그가 붙어 있다면, 애플리케이션은
해당 페이로드가 더 높은 정밀도의 미디어 유형에도 적합한지 확인하기 위해
다음 단계를 수행할 수 있습니다.
@context 속성의 첫 번째 요소가
https://www.w3.org/ns/did/v1.1과 일치하는지 확인합니다.
id 속성이 있으면
application/did 미디어 유형으로 가정합니다.
가능하면 구현자는 이 명세가 정의하는 모든 페이로드에 대해 가장 정밀한(가장 높은 정밀도의) 미디어 유형을 사용하는 것이 권고됩니다. 또한 구현자는 낮은 정밀도의 미디어 유형으로 태그가 붙은 페이로드가 더 높은 정밀도 유형으로 태그를 붙이는 데 필요한 규칙을 충족하지 않는다는 의미가 아님을 인식하는 것이 권고됩니다. 마찬가지로, 더 높은 정밀도의 미디어 유형으로 태그가 붙은 페이로드가 해당 미디어 유형과 관련된 요구사항을 충족한다는 의미도 아닙니다. 페이로드의 수신자는 관련된 미디어 유형과 관계없이, 주어진 시스템에서 사용하는 데 필요한 요구사항에 페이로드가 적합한지 보장하기 위해 적절한 검사를 수행할 것으로 기대됩니다.
HTTP 클라이언트와 서버는 Accept: 헤더와 콘텐츠 유형을 나타낼 때
DID
문서와 관련된 미디어 유형을 사용합니다.
구현자는 HTTP 서버가 Accept: 헤더를 무시하고 다른 콘텐츠 유형을 반환하거나,
415
Unsupported Media Type과 같은 오류 코드를 반환할 수 있음을 경고받습니다.
적합한 DID 메서드는 구현자가 이 명세에서 설명하는 기능을 어떻게 실현할 수 있는지를 정의합니다. DID 메서드는 종종 특정 검증 가능 데이터 레지스트리와 연결됩니다. 새로운 DID 메서드는 동일한 DID 메서드의 서로 다른 구현 간 상호운용성을 가능하게 하기 위해 자체 명세에서 정의됩니다.
개념적으로, 이 명세와 DID 메서드 명세 사이의
관계는 IETF의 일반
URI
명세 [RFC3986]와
http 스킴 [RFC9110]과 같은 특정 URI
스킴
[IANA-URI-SCHEMES] 사이의 관계와
유사합니다. 특정 DID 스킴을 정의하는 것 외에도, DID 메서드
명세는 특정 유형의
검증 가능 데이터 레지스트리를 사용하여
DID와 DID 문서를
생성, 해석, 업데이트 및 비활성화하는 메커니즘도 정의합니다. 또한
DID와 관련된 모든
구현 고려사항뿐 아니라 보안 및 개인정보 보호
고려사항도 문서화합니다.
이 절은 DID 메서드 명세를 작성하기 위한 요구사항을 지정합니다.
메서드별 DID 구문을 정의할 때 모든 DID 메서드 명세에 대한 요구사항은 다음과 같습니다.
method-name 규칙에 지정된 것처럼 정확히 하나의 메서드 이름으로 식별되는
정확히 하나의 메서드별 DID 스킴을 정의해야
MUST 합니다.
method-specific-id 구성 요소를 생성하는 방법을 지정해야
MUST 합니다.
method-specific-id 값의 대소문자 민감성과 정규화를 정의해야
MUST 합니다.
method-specific-id 값은 DID 메서드 내에서 고유해야
MUST 합니다. method-specific-id 값 자체는 전역적으로
고유할 수 있습니다.
method-name 충돌 가능성을 줄이기 위해, DID 메서드
명세는 DID Extensions 저장소
[DID-EXTENSIONS]에 등록되는 것이
SHOULD 됩니다.
method-specific-id 형식을 정의할 MAY 있습니다.
method-specific-id 형식은 콜론을 포함할 MAY 있습니다. 콜론의 사용은
method-specific-id ABNF
규칙을 구문적으로 준수해야 MUST 합니다.
method-specific-id에서 콜론의 의미는 전적으로
메서드별입니다. 콜론은 DID 메서드에서
계층적으로 분할된 이름공간을 설정하거나, 검증 가능 데이터 레지스트리의 특정 인스턴스 또는
부분을 식별하거나,
기타 목적을 위해 사용될 수 있습니다.
구현자는 모든 DID 메서드에
일반적으로 적용되는 콜론과 관련된 의미나
동작을 가정하지 않는 것이 권고됩니다.
메서드 작업을 정의할 때 모든 DID 메서드 명세에 대한 요구사항은 다음과 같습니다.
작업을 수행하기 위해 권한 부여를 수행하는 당사자의 권한은 DID 메서드에 따라 다릅니다. 예를 들어, DID 메서드는 다음을 할 수 있습니다 —
controller 속성을 사용할 수 있습니다.
authentication 아래에 나열된
검증 방법을 사용할
수 있습니다.
capabilityInvocation
검증
관계를 통해 지정된 검증
방법과 같은 DID 문서의 다른 구조를
사용할 수 있습니다.
메서드 작업을 실행할 때, DID 메서드는 필요한 모든 데이터 구조를 사용할 수 있습니다. 여기에는 중간, 부분 또는 임시 DID 문서가 포함될 수 있습니다. 단, 이들은 DID 메서드 내부에 유지되어야 하며, 메서드 작업이 반환하는 DID 문서는 1.4 적합성에 정의된 대로 완전히 적합해야 합니다.
보안 고려사항 절을 작성할 때 모든 DID 메서드 명세에 대한 요구사항은 다음과 같습니다.
개인정보 보호 고려사항 절을 작성할 때 모든 DID 메서드 명세에 대한 요구사항은 다음과 같습니다.
이 절은 비규범적입니다.
이 절에는 탈중앙화 식별자를 사용하는 사람들이 이 기술을 프로덕션 환경에 배포하기 전에 고려하도록 권고되는 다양한 보안 고려사항이 포함되어 있습니다. 독자는 이 절을 읽기 전에 Controlled Identifiers v1.0 명세의 보안 고려사항 절을 읽는 것이 권장됩니다. DID는 많은 IETF 표준에서 사용되고 [RFC3552]에 문서화된 위협 모델 아래에서 동작하도록 설계되었습니다. 이 절은 [RFC3552]의 여러 고려사항뿐 아니라 DID 아키텍처에 고유한 다른 고려사항도 자세히 설명합니다.
DID Extensions 저장소 [DID-EXTENSIONS]에는 DID 메서드 이름과 그에 해당하는 DID 메서드 명세의 정보적 목록이 포함되어 있습니다. 구현자는 특정 DID 메서드 이름에 어떤 DID 메서드 명세를 사용해야 하는지를 지시하는 중앙 기관이 없다는 점을 명심해야 합니다. 특정 DID 리졸버가 DID 메서드를 올바르게 구현하는지 의심스러운 경우, DID Specification Registries를 사용하여 등록된 명세를 조회하고 어떤 DID 리졸버 구현을 사용할지에 대해 정보에 기반한 결정을 내릴 수 있습니다.
DID와 DID 문서 업데이트의 부인 방지는 다음과 같은 경우 지원됩니다.
신뢰 없는 시스템은 모든 신뢰가 암호학적으로 증명 가능한 주장으로부터 도출되는 시스템이며,
더 구체적으로는 암호학적 시스템 외부의 메타데이터가 시스템 내 신뢰 판단에
반영되지 않는 시스템입니다.
신뢰 없는 시스템에서 폐기된 검증
방법에 대한 증명 또는 서명을
검증하려면, DID 메서드는
versionId 또는 versionTime 중 하나 또는 둘 다와,
updated 및 nextUpdate 두
DID 문서 메타데이터 속성을 지원해야 합니다. 검증자는
다음 조건이 모두 참일 때, 그리고 그때에만 폐기된 키의 서명 또는 증명을
검증할 수 있습니다.
versionId 또는
versionTime을 포함합니다.
updated 타임스탬프는
서명 또는 증명이 만들어진 시점보다 이전이고, nextUpdate 타임스탬프는
그 시점보다 이후입니다.
암호학적 입력을 구성하는 것 이상의 메타데이터를 기꺼이 수용하는 시스템에서도 유사한 신뢰를 달성할 수 있습니다. 그러나 이는 항상 서명 이벤트가 발생한 순간에 DID 문서의 내용이 예상한 내용을 포함했는지에 대한 신중한 판단을 요구합니다.
복구는 기기 분실 등을 통해 DID 작업을 수행할 능력을 잃은 컨트롤러가 DID 작업을 수행할 능력을 되찾을 수 있게 하는 반응형 보안 조치입니다.
DID 복구 사용을 고려할 때 다음 고려사항이 유용할 수 있습니다.
DID는 중앙 등록 기관을 필요로 하지 않고 전역적 고유성을 달성합니다. 이는 사람이 기억하기 어렵다는 대가를 수반합니다. 전역적으로 모호하지 않은 식별자를 생성할 수 있는 알고리즘은 인간에게 의미가 없는 무작위 문자 문자열을 생성합니다. 이러한 절충은 흔히 Zooko의 삼각형이라고 불립니다.
사람에게 친숙한 식별자에서 시작하여 DID를 발견하는 것이 바람직한 사용 사례가 있습니다. 예를 들어 자연어 이름, 도메인 이름, 또는 휴대전화 번호, 이메일 주소, 소셜 미디어 사용자 이름, 블로그 URL과 같은 DID 컨트롤러의 관례적 주소가 있습니다. 그러나 사람에게 친숙한 식별자를 DID에 매핑하고, 이를 검증되고 신뢰될 수 있는 방식으로 수행하는 문제는 이 명세의 범위를 벗어납니다.
이 문제에 대한 해결책은 이 명세를 참조하는 [DNS-DID]와 같은 별도의 명세에서 정의됩니다. 그러한 명세는 다음을 신중히 고려하는 것이 강력히 권장됩니다.
DID 컨트롤러가 원한다면, DID 또는 DID URL은 영속적이고 위치 독립적인 리소스 식별자로 작동할 수 있습니다. 이러한 종류의 식별자는 Uniform Resource Names(URN)로 분류되며 [RFC8141]에 정의되어 있습니다. DID는 디지털 리소스를 위한 암호학적으로 안전하고 위치 독립적인 식별자를 제공하는 향상된 형태의 URN이며, 동시에 검색을 가능하게 하는 메타데이터도 제공합니다. DID 문서와 DID 자체 사이의 간접 참조로 인해, DID 컨트롤러는 DID를 조정하지 않고도 리소스의 실제 위치를 조정하거나 리소스를 직접 제공할 수도 있습니다. 이러한 유형의 DID는 검색된 리소스가 실제로 식별된 리소스임을 확정적으로 검증할 수 있습니다.
이러한 목적으로 DID를 사용하려는 DID 컨트롤러는 [RFC8141]의 보안 고려사항을 따르는 것이 권고됩니다. 특히 다음 사항입니다.
많은 사이버보안 남용은 현실과 합리적이고 선의의 행위자가 가진 가정 사이의 틈을 악용하는 데 달려 있습니다. DID 문서의 불변성은 일부 보안 이점을 제공할 수 있습니다. 개별 DID 메서드는 필요하지 않은 동작이나 의미론을 제거할 제약을 고려해야 합니다. 동일한 기능 집합을 제공하면서도 DID 메서드가 더 잠겨 있을수록, 악의적인 행위자가 이를 조작할 수 있는 가능성은 더 낮아집니다.
예를 들어, DID 문서에 대한
한 번의 편집으로 문서의 루트 id 속성을 제외한
무엇이든 변경할 수 있다고 가정해 보십시오. 그러나 서비스가 정의된 후
그 type을 변경하는 것이 실제로 바람직할까요? 또는 키가 값을 변경하는 것은 어떨까요?
아니면 객체의 특정 근본 속성이 변경될 때 새로운 id를 요구하는 것이
더 나을까요? 웹사이트에 대한 악의적인 탈취는 종종 사이트가 호스트 이름 식별자를 유지하되,
그 아래가 미묘하게 변경되는 결과를 목표로 합니다. 사이트의 특정 속성,
예를 들어 IP 주소와 연결된 ASN이
명세에 의해 불변이어야 한다면, 이상 탐지가 더 쉬워지고 공격을 수행하는 것은
훨씬 더 어렵고 비용이 많이 들 것입니다.
전역 진실 소스에 연결된 DID 메서드의 경우, 최신 버전의 DID 문서를 직접 즉시 조회하는 것이 항상 가능합니다. 그러나 결국 DID 리졸버와 그 진실 소스 사이에 캐시 계층이 놓일 가능성이 있습니다. 그렇다면 DID 문서 안의 객체 속성이 실제로는 미묘하게 다른데도 특정 상태를 가진다고 믿는 것은 악용을 초래할 수 있습니다. 이는 일부 조회가 전체 DID 문서에 대한 것이고, 다른 조회는 더 큰 맥락이 가정된 부분 데이터에 대한 것일 때 특히 그렇습니다.
암호화 알고리즘은 암호학과 컴퓨팅 능력의 발전으로 인해 실패하는 것으로 알려져 왔습니다. 구현자는 DID 문서에 배치된 모든 암호화된 데이터가 결국 해당 암호화된 데이터를 사용할 수 있는 동일한 대상에게 평문으로 제공될 수 있다고 가정하는 것이 권고됩니다. 이는 DID 문서가 공개된 경우 특히 관련이 있습니다.
DID 문서의 전부 또는 일부를 암호화하는 것은 장기적으로 데이터를 보호하기 위한 적절한 수단이 아닙니다. 마찬가지로, 암호화된 데이터를 DID 문서에 배치하는 것은 개인 데이터를 보호하기 위한 적절한 수단이 아닙니다.
위의 주의사항을 고려할 때, 암호화된 데이터가 DID 문서에 포함되는 경우, 구현자는 암호화된 데이터와 관련 당사자 사이의 관계를 추론하는 데 사용될 수 있는 상관 가능한 정보를 연결하지 않는 것이 권고됩니다. 상관 가능한 정보의 예로는 수신 당사자의 공개 키, 수신 당사자의 제어 아래 있는 것으로 알려진 디지털 자산의 식별자, 또는 수신 당사자에 대한 사람이 읽을 수 있는 설명이 있습니다.
equivalentId 및 canonicalId
속성은 DID 메서드 자체에 의해 생성되므로,
DID 문서의
id 필드에 존재하는 해석된 DID에 적용되는 동일한 보안 및
정확성 보장이 이러한 속성에도 적용됩니다.
alsoKnownAs 속성은 정확한 동등성 진술이라고 보장되지 않으며,
DID 문서의 해석을
넘어서는 검증 단계를 수행하지 않고는 의존해서는 안 됩니다.
equivalentId 및 canonicalId
속성은 동일한 DID 메서드에 의해 생성된 단일 DID의 변형에 대한 동등성 주장을 표현하며,
요청 당사자가 DID 메서드와 적합한 생산자 및
리졸버를 신뢰하는 정도까지 신뢰할 수 있습니다.
alsoKnownAs 속성은 동일한 DID 메서드에 의해
관리되지 않는 URI에 대한
동등성 주장을 허용하며, 관리하는 DID 메서드 외부의 검증 단계를 수행하지 않고는
신뢰할 수 없습니다. 추가 지침은
Controlled Identifiers
v1.0 명세의
Section 2.1.3: Also Known As를 참조하십시오.
DID 문서의 다른 보안 관련 속성과 마찬가지로, DID 문서의 동등성 진술에 의존하는 당사자는 적절한 검증이 수행된 후 공격자가 이러한 속성의 값을 대체하는 것을 방지해야 합니다. 검증이 수행된 후 메모리 또는 디스크에 저장된 DID 문서에 대한 모든 쓰기 접근은 DID 문서가 다시 검증되지 않는 한 검증을 우회할 수 있는 공격 벡터입니다.
DID는 컨트롤러가 자신의 식별자를 유지하기 위해 하나의 신뢰된 제3자 또는 관리자에 의존할 필요가 없도록 영속적으로 설계되었습니다. 이상적인 경우, 어떤 관리자도 컨트롤러로부터 제어권을 빼앗을 수 없으며, 인증, 권한 부여, 증명과 같은 특정 목적을 위한 식별자 사용을 막을 수도 없습니다. 어떤 제3자도 컨트롤러의 동의 없이 컨트롤러를 대신하여 엔터티의 식별자를 제거하거나 작동 불능으로 만들 수 없습니다.
그러나 암호학적 제어 증명을 가능하게 하는 모든 DID 메서드에서는 비밀 암호학적 자료를 이전함으로써 제어를 증명하는 수단이 항상 다른 당사자에게 이전될 수 있다는 점에 유의하는 것이 중요합니다. 따라서 시간이 지남에 따라 식별자의 지속성에 의존하는 시스템은 해당 식별자가 실제로 의도한 당사자의 제어 아래 있는지 정기적으로 확인하는 것이 중요합니다.
안타깝게도 주어진 검증 방법과 관련된 비밀 암호학적 자료가 손상되었는지 여부를 암호학만으로 판단하는 것은 불가능합니다. 예상된 컨트롤러가 여전히 비밀 암호학적 자료에 접근할 수 있어서 검증 과정의 일부로 제어 증명을 실행할 수 있는 동시에, 악의적인 행위자도 동일한 키 또는 그 사본에 접근할 수 있을 수 있습니다.
따라서 암호학적 제어 증명은 고위험 시나리오에 필요한 신원 보증 수준을 평가하는 하나의 요소로만 사용될 것으로 기대됩니다. DID 기반 인증은 시스템 사이에 암호학적 비밀을 전송하지 않고도 해당 비밀에 대한 제어를 확인할 수 있기 때문에 사용자 이름과 비밀번호보다 훨씬 더 큰 보증을 제공합니다. 그러나 완전무결하지는 않습니다. 민감하거나, 가치가 높거나, 생명에 중대한 작업이 포함된 시나리오는 적절한 추가 요소를 사용할 것으로 기대됩니다.
서로 다른 컨트롤러에 의한 사용에서 생길 수 있는 모호성 외에도, 일반적으로 주어진 DID가 어느 특정 시점에 동일한 주체를 가리키는 데 사용되고 있음을 보장하는 것은 불가능합니다. 기술적으로 컨트롤러가 서로 다른 주체에 대해 DID를 재사용하는 것이 가능하며, 더 미묘하게는 주체의 정확한 정의가 시간이 지나며 변하거나 오해될 수도 있습니다.
예를 들어, 금융 거래에 사용되는 다양한 자격 증명을 받는 개인사업자에 사용되는 DID를 생각해 보십시오. 컨트롤러에게 그 식별자는 사업을 가리켰습니다. 사업이 성장하면서 결국 유한책임회사로 법인화됩니다. 컨트롤러는 동일한 DID를 계속 사용합니다. 왜냐하면 그들에게 그 DID는 사업을 가리키기 때문입니다. 그러나 주 정부, 세무 당국, 지방자치단체에게 그 DID는 더 이상 동일한 엔터티를 가리키지 않습니다. 의미의 미묘한 변화가 신용 제공자나 공급자에게 중요한지 여부는 반드시 그들이 결정해야 합니다. 많은 경우 청구서가 지불되고 추심이 집행될 수 있는 한, 그 변화는 중요하지 않습니다.
이러한 잠재적 모호성 때문에, DID는 절대적으로가 아니라 맥락적으로 유효한 것으로 간주되어야 합니다. 그 지속성은 정확히 동일한 주체를 가리킨다거나 동일한 컨트롤러의 제어 아래 있다는 것을 의미하지 않습니다. 대신, DID가 생성된 맥락, 사용 방식, 그리고 그 의미의 가능한 변화를 이해하고, 잠재적 및 필연적인 의미론적 드리프트를 모두 다루기 위한 절차와 정책을 채택해야 합니다.
이 절은 비규범적입니다.
이 명세는 특정 유형의 검증 가능 데이터 레지스트리 사용을 요구하거나 제안하지 않습니다. 서로 다른 사용 사례는 서로 다른 요구사항으로 이어질 수 있습니다. 서로 다른 요구사항은 서로 다른 절충을 가진 서로 다른 고려사항을 시사할 수 있습니다. 예를 들어, 계산(에너지 사용), 신뢰(권위에 대한 의존), 조정(네트워크 대역폭), 또는 메모리(물리적 저장소) 간의 절충은 주어진 사용 사례에 적절할 수도 있고 적절하지 않을 수도 있습니다. 다른 사용 사례는 동일한 절충을 하지 않을 수 있습니다. 자신의 사용 사례에 대해 다른 기준을 고려해야 하는 경우, 의사결정자가 특정 DID 메서드가 그 사용 사례에 적절한지 여부를 판단하는 데 도움이 되는 평가 기준을 제공하는 DID Method Rubric을 참조하십시오.
이 절은 비규범적입니다.
DID와 DID 문서는 DID 컨트롤러가 직접 관리하도록 설계되었으므로, 탈중앙화 식별자 아키텍처의 모든 측면에 프라이버시 중심 설계 [PRIVACY-BY-DESIGN] 원칙을 적용하는 것이 매우 중요합니다. 이 일곱 가지 원칙은 모두 이 명세의 개발 전반에 적용되었습니다. 이 명세에서 사용되는 설계는 추가 개인정보 보호 장치를 권고하거나 적용할 등록 기관, 호스팅 회사 또는 기타 중간 서비스 제공자가 있다고 가정하지 않습니다. 이 명세에서 개인정보 보호는 사후적이 아니라 예방적이며, 기본값으로 내장되어 있습니다. 이 절을 읽기 전에, 독자는 Controlled Identifiers v1.0 명세의 개인정보 보호 고려사항 절을 읽는 것이 권장됩니다. 그 절에는 DID에도 적용되는 더 일반적인 개인정보 보호 고려사항이 포함되어 있습니다. 이 절의 나머지는 탈중앙화 식별자에 특화된 개인정보 보호 고려사항을 다루며, Controlled Identifiers v1.0 명세에서 제공하는 지침에 추가됩니다.
DID 주체가 그룹 안의 다른 사람들과 구별되지 않을 때 개인정보 보호가 가능합니다. 다른 당사자와 사적으로 교류한다는 행위 자체가 인식 가능한 표식이 되는 경우, 개인정보 보호는 크게 줄어듭니다.
DID와 DID 메서드는 그룹 개인정보 보호를 개선하기 위해 노력해야 하며, 특히 이를 정당하게 가장 필요로 하는 사람들을 위해 그러해야 합니다. 익명성과 가명성을 기본적으로 보존하는 기술과 인간 인터페이스를 선택하십시오. 디지털 지문을 줄이기 위해, 요청 당사자 구현 전반에서 공통 설정을 공유하고, 전송 프로토콜에서 협상되는 옵션을 최소화하며, 암호화된 전송 계층을 사용하고, 메시지를 표준 길이로 패딩하십시오.
이 절은 비규범적입니다.
이 절은 비규범적입니다.
선택적 확장 및 기타 검증 방법 유형은 검증 방법 유형 [DID-EXTENSIONS]을 참조하십시오.
이 예들은 정보 제공 목적으로만 제공되며, 동일한 검증 방법을 여러 목적으로 사용하는 것을 피하는 것이 모범 사례로 간주됩니다.
{
"@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"
}
]
}
{
"@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)
}
}
]
}
{
"@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"
}
}]
}
{
"@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"
]
}
이 절은 비규범적입니다.
이 예들은 정보 제공 목적으로만 제공됩니다. 추가 예는 검증 가능 자격 증명 데이터 모델 v2.0을 참조하십시오.
{
// 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"
}
}
{ // 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"
}
}
{ // 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"
}
}
{
// 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"
}
}
{ // 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"
}
이 절은 비규범적입니다.
이 예들은 정보 제공 목적으로만 제공되며, 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"
}
이 절은 비규범적입니다.
이 절은 비규범적입니다.
다음은 4. 데이터 모델, 5. 핵심 속성, 7. 메서드 및 [DID-RESOLUTION] 사이의 관계를 보여 주는 다이어그램입니다.
이 절은 비규범적입니다.
DID의 생성은
각 DID 메서드가 정의하는 과정입니다. did:key와 같은
일부 DID 메서드는 순수하게
생성적이며, 단일 암호학적 자료를 적합한
표현으로 변환하여 DID와 DID 문서를 생성합니다.
다른 DID 메서드는
검증 가능 데이터 레지스트리 사용을 요구할 수 있으며, 이 경우
DID와 DID 문서는
해당 DID 메서드가 정의한 등록이
완료된 후에만 제3자에게 존재하는 것으로 인식됩니다. 다른 과정도
해당 DID 메서드에 의해 정의될 수 있습니다.
이 절은 비규범적입니다.
DID는 특정 유형의 URI(Uniform Resource Identifier)이므로, DID는 어떤 리소스든 참조할 수 있습니다. [RFC3986]에 따르면:
"resource"라는 용어는 URI로 식별될 수 있는 무엇이든 가리키는 일반적인 의미로 사용됩니다. [...] 리소스는 반드시 인터넷을 통해 접근 가능해야 하는 것은 아닙니다.
리소스는 디지털 또는 물리적일 수 있고, 추상적이거나 구체적일 수 있습니다. URI를 할당할 수 있는 모든 리소스에는 DID도 할당할 수 있습니다. DID가 참조하는 리소스가 DID 주체입니다.
DID 컨트롤러가 DID 주체를 결정합니다. DID 자체를 보는 것만으로 DID 주체를 결정할 수 있을 것으로 기대되지는 않습니다. DID는 일반적으로 사람이 아니라 기계에만 의미가 있기 때문입니다. DID는 DID 주체에 관한 정보를 포함할 가능성이 낮으므로, DID 주체에 관한 추가 정보는 DID를 DID 문서로 해석하거나, 해당 DID에 대한 검증 가능 자격 증명을 얻거나, 또는 DID에 관한 다른 설명을 통해서만 발견할 수 있습니다.
검색된 DID 문서의 id 속성 값은 항상 해석 중인
DID와 일치해야 하지만,
DID가 참조하는 실제 리소스가 시간이 지남에 따라
변경될 수 있는지 여부는 DID 메서드에 따라 달라집니다. 예를 들어,
DID 메서드가
DID 주체의 변경을 허용한다면, 회사의 CEO와 같은
특정 역할의 현재 담당자에 대한
DID를 생성하는 데 사용될 수 있으며,
이 경우 그 역할을 맡은 실제 사람은 DID가 해석되는 시점에 따라
달라질 수 있습니다.
이 절은 비규범적입니다.
DID는 DID 주체를 참조하고, DID 메서드가 지정한 프로토콜을 따라 DID 문서로 해석됩니다. DID 문서는 DID 주체와 별개의 리소스가 아니며, DID와 별개의 URI를 갖지 않습니다. 오히려 DID 문서는 DID 해석의 산물이며, DID 컨트롤러가 DID 주체와 암호학적으로 검증 가능한 상호작용을 가능하게 하기 위해 제어합니다.
이 구분은 아래에 표시된 그래프 모델로 설명됩니다.
이 절은 비규범적입니다.
DID 문서의 각 속성은 DID 컨트롤러가 다음을 설명하기 위해 하는 진술입니다:
id 및 alsoKnownAs
속성)
verificationMethod 및 service
속성).
@context 속성).
DID 문서에서 유일하게 필수인 속성은
id이므로, 이것이
DID 문서에
포함된다고 보장되는 유일한 진술입니다. 그 진술은 그림
5에서
DID와 DID 주체 사이의 직접 링크로
설명됩니다.
이 절은 비규범적입니다.
DID 주체에 관한
추가 정보를 발견하기 위한 선택지는 DID 문서에 존재하는 속성에 따라 달라집니다.
service 속성이 존재하는 경우, 서비스 엔드포인트에서
추가 정보를 요청할 수 있습니다. 예를 들어,
서비스 엔드포인트가
DID 주체를 설명하는 하나 이상의
주장(속성)에 대해 검증 가능 자격 증명을 지원하는 경우 이를 질의할 수 있습니다.
또 다른 선택지는 DID 문서에 존재하는 경우
alsoKnownAs 속성을 사용하는 것입니다. DID
컨트롤러는 이를 사용해 같은
DID 주체를 참조하는 다른 URI(다른
DID 포함) 목록을 제공할 수 있습니다.
이러한 URI를 해석하거나 역참조하면 아래 그림에 설명된 것처럼
DID 주체에 대한
다른 설명이나 표현을 얻을 수 있습니다.
이 절은 비규범적입니다.
DID 주체가 인터넷에서 검색할 수 있는 디지털 리소스인 경우, DID 메서드는 DID URL을 구성하여 DID 주체 자체의 표현을 반환하도록 선택할 수 있습니다. 예를 들어, 지속적이고 암호학적으로 검증 가능한 식별자가 필요한 데이터 스키마에 DID를 할당할 수 있으며, 지정된 경로 또는 쿼리를 전달하는 것을 그 스키마의 표현을 검색하기 위한 표준 방식으로 사용할 수 있습니다.
마찬가지로, DID는 적용 가능한 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)으로 사실상 기능할 수 있는 방식입니다.
이 절은 비규범적입니다.
혼동을 피하기 위해, DID 주체를 DID 컨트롤러와의 관계에 따라 서로 겹치지 않는 두 집합으로 분류하는 것이 유용합니다.
이 절은 비규범적입니다.
그림 7에 표시된 첫 번째 경우는 DID 주체가 동시에 DID 컨트롤러인 일반적인 시나리오입니다. 이는 개인이나 조직이 자기 식별을 위해 DID를 생성하는 경우입니다.
그래프 모델 관점에서 보면, DID 컨트롤러와 DID 주체로 식별된 노드가 그림 7에서 서로 구별되더라도, 의미론적 동등성 관계를 표현하기 위해 이들을 연결하는 논리적 호가 있습니다.
이 절은 비규범적입니다.
두 번째 경우는 DID 주체가 DID 컨트롤러와 별개의 엔터티인 경우입니다. 예를 들어, 부모가 자녀를 위한 DID를 만들고 제어를 유지하는 경우, 법인이 자회사를 위한 DID를 만들고 제어를 유지하는 경우, 또는 제조사가 제품, IoT 장치, 또는 디지털 파일을 위한 DID를 만들고 제어를 유지하는 경우입니다.
그래프 모델 관점에서 Set 1과의 유일한 차이는 DID 주체와 DID 컨트롤러 노드 사이에 동등성 호 관계가 없다는 점입니다.
이 절은 비규범적입니다.
DID 문서는 둘 이상의 DID 컨트롤러를 가질 수 있습니다. 이는 두 가지 방식 중 하나로 발생할 수 있습니다.
이 절은 비규범적입니다.
이 경우, 각 DID 컨트롤러는 스스로 행동할 수 있습니다. 즉, 각 컨트롤러는 DID 문서를 독립적으로 업데이트할 완전한 권한을 가집니다. 그래프 모델 관점에서 이 구성에서는:
이 절은 비규범적입니다.
그룹 제어의 경우, DID 컨트롤러들은 여러 디지털 서명("multi-sig") 또는 임계 수의 디지털 서명("m-of-n")을 요구하는 암호학적 알고리즘을 사용하는 경우처럼, 어떤 방식으로든 함께 행동할 것으로 기대됩니다. 증명을 검증하기 위한 이러한 추가 임계값은 검증 방법에서, 5.2 검증 방법 절에 설명된 대로 표현될 수 있거나, 검증 방법의 검증 자료 자체에 내재할 수 있습니다. 이 경우 특정 디지털 서명 생성에 참여한 DID 컨트롤러의 수는 개인정보 보호상의 이유로 숨겨집니다. 그룹 구성원이 수행하는 암호학적 작업의 조합으로 증명을 생성해야 하는 검증 방법은 DID 문서의 내용을 제어하는 데 사용될 수 있으며, 이것이 정확히 어떻게 실현되는지는 개별 DID 메서드 명세에 따라 달라집니다.
기능적 관점에서 이 선택지는 단일 DID 컨트롤러와 유사합니다. DID 컨트롤러 그룹의 각 DID 컨트롤러가 자체 그래프 노드를 가지더라도, 실제 제어는 그림 9에 표시된 것처럼 DID 컨트롤러 그룹을 나타내는 단일 논리 그래프 노드로 축약되기 때문입니다.
이 구성은 DID 주체가 단일 개인이 제어하지 않는 조직, 법인, 정부 기관, 커뮤니티 또는 기타 그룹인 경우에 자주 적용됩니다.
이 절은 비규범적입니다.
DID 문서는
DID 주체를 참조하는 정확히 하나의
DID를 가집니다. DID는
id 속성 값으로 표현됩니다. 이 속성 값은
DID 문서의 수명 동안 불변입니다.
그러나 DID가 식별하는 리소스, 즉 DID 주체는 시간이 지남에 따라 변경될 수 있습니다. 이는 DID 컨트롤러의 독점 권한 아래 있습니다. 자세한 내용은 8.10 지속성 절을 참조하십시오.
이 절은 비규범적입니다.
DID 문서의 DID 컨트롤러는 시간이 지남에 따라 변경될 수 있습니다. 그러나 구현 방식에 따라 DID 컨트롤러의 변경이 DID 문서 자체의 변경으로 드러나지 않을 수 있습니다. 예를 들어, 변경이 DID 문서의 하나 이상의 검증 방법에 사용되는 기본 암호학적 키나 다른 제어 수단의 소유권 이동을 통해 구현되는 경우, 표준 키 회전과 구별하기 어려울 수 있습니다.
반면 변경이
controller
속성 값을 변경하여 구현되는 경우, 이는 투명하게 드러납니다.
DID 컨트롤러 변경을 검증하는 것이 중요한 경우, 구현자는 개정된 DID 문서의 검증 방법에 대해 새로운 DID 컨트롤러를 인증하는 것이 권고됩니다.
이 절은 비규범적입니다.
이 절은 이 명세가 W3C 최초 공개 작업 초안으로 공개된 이후 이루어진 변경 사항을 포함합니다.
DID v1.0 권고안 이후의 변경 사항은 다음을 포함합니다:
application/did로 통합.
DID v1.0 두 번째 후보 권고안 이후의 변경 사항은 다음을 포함합니다:
publicKeyMultibase와 관련된 경고 추가 [CID].
DID v1.0 첫 번째 후보 권고안 이후의 변경 사항은 다음을 포함합니다:
method-specific-id ABNF 규칙과 nextUpdate 및 nextVersionId에 대한
위험 표시 이슈 마커 제거.
equivalentId 및 canonicalId가 선택 사항임을 명확히 함.
publicKeyBase58를 publicKeyMultibase로 대체.
DID v1.0 최초 공개 작업 초안 이후의 변경 사항은 다음을 포함합니다:
이 절은 비규범적입니다.
워킹 그룹은 생산적인 방향으로 워킹 그룹을 이끌고 표준화 절차의 깊고 위험한 물길을 헤쳐 나가도록 지칠 줄 모르고 노력해 준 의장 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.
이 절은 이 명세가 W3C 제안 권고안이 될 때 검토, 승인 및 IANA 등록을 위해 Internet Engineering Steering Group (IESG)에 제출될 것입니다.
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 명세에 의해 확장됩니다.
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in: