이 문서는 W3C Decentralized Identifiers (DIDs) v1.0의 한국어 번역본입니다.
이 문서에 오역 및 오타를 포함할 수 있습니다.
영어 원문만이 공식적이고 규범적인 효력을 가지고 있습니다.
문의나 개선사항은
깃헙 링크나
[email protected]로
연락주시기 바랍니다.
원문작성일: 2024-03-17
최초번역일: 2024-03-17
최종수정일: 2024-04-25
탈중앙 식별자 (DID)는 검증가능하고 탈중앙화된 디지털 신원을 위한 새로운 형식의 식별자이다. DID는 DID의 컨트롤러가 결정한 모든 주체(예: 사람, 조직, 사물, 데이터 모델, 추상 개체 등)를 나타낸다. 전형적인 중앙 식별자와 다르게, DID는 중앙화된 레지스트리, ID 제공업체, 인증 기관과 분리될 수 있도록 설계되었다. 다른 당사자들이 DID와 관련된 정보를 찾는 데 도움을 줄 수 있지만, 이 설계는 DID의 컨트롤러가 다른 당사자의 허가 없이도 그것을 통제하는 것을 증명할 수 있도록 한다. DID는 DID 주체를 DID 문서와 연결하여 해당 주제와 관련된 신뢰할 수 있는 상호 작용을 허용하는 URI이다.
각 DID 문서는 DID 컨트롤러가 DID를 통제하는 것을 증명하는 데 필요한 메커니즘의 집합을 제공하는데 필요한 암호화 자료, 검증 방법, 또는 서비스를 표현할 수 있다. 서비스는 DID 주체와 관련된 신뢰할 수 있는 상호 작용을 가능하게 한다. DID는 데이터 모델과 DID 주체가 같은 정보 리소스인 경우 DID 주체 자체를 반환하는 수단을 제공할 수 있다.
이 문서는 DID 구문, 공통 데이터 모델, 핵심 속성, 직렬화된 표현, DID 작업 및 DID가 나타내는 리소스를 확인하는 프로세스에 대한 설명을 명시한다.
The W3C Decentralized Identifier Working Group은 이 문서를 W3C 제안 권장 사항으로 게시했으며 이해 관계자가 2021년 8월 26일까지 이 명세를 검토하록 요청하고 있습니다.
문서 발행 시점에, 실험적인 DID 방법 명세가 103개가 있었으며, 실험적인 DID 방법 드라이버 구현이 32개 있었고, 이 명세와 일치하는지 여부를 결정하는 테스트 모음 및 이 명세에 준하는 46개의 구현이 제출되었다. 독자들은 DID Core 이슈와 DID Core 테스트 스위트 이슈에 주의를 기울이는 것이 권장되며, 각 이슈에는 이 명세에 변경을 일으킬 수 있는 최신 고려 사항 및 제안된 변경 사항이 포함되어 있다. 문서 작성 시점에서는 추가적인 실질적인 이슈, 변경 또는 수정이 예상되지 않는다.
이 문서에 대한 의견은 환영합니다. 의견은 직접 GitHub에 제출하거나, [email protected]로 보내주세요 ( 구독, 아카이브).
개인 및 조직으로서 우리 중 많은 사람들은 다양한 맥락 속에서 전세계적으로 고유한 식별자를 사용한다. 그들은 통신주소 (전화번호, 이메일 주소, 소셜 미디어의 사용자 이름), ID 번호 (여권, 운전면허증, 세금 ID, 건강보험을 위한) 그리고 상품 식별자 (시리얼 번호, 바코드, RFID)의 역할을 한다. URI (Uniform Resource Identifier)는 웹 상의 리소스를 위해 사용되며, 브라우저에서 보는 각 웹 페이지는 전세계적으로 고유한 URL (Uniform Resource Locator)을 가진다.
이러한 전세계적으로 고유한 식별자들 중 대부분은 우리의 통제안에 있지 않는다. 그들은 누구 또는 무엇을 참조하는지, 언제 철회할 수 있는지를 결정하는 외부의 기관에 의해 발행된다. 그것들은 특정 상황에서만 유용하며 우리가 선택하지 않은 특정 기관에서만 인식된다. 그것들은 기관이 존속하는데 실패하면 사라지거나 유효하지 않게 될 수 있다. 그들은 불필요하게 개인 정보를 공개할 수도 있다. 대부분의 경우 악의적인 제3자에 의해 사기적으로 복제되고 주장될 수 있다. 이는 일반적으로 "신원도용"으로 알려져 있다.
이 명세에 정의된 The Decentralized Identifiers (DID)는 새로운 유형의 전세계적으로 고유한 식별자이다. 그들은 개인과 기관이 신뢰하는 시스템을 사용하여 자신의 식별자를 생성할 수 있도록 설계되었다. 이러한 새로운 식별자를 사용하면 디지털 서명과 같은 암호화 증명을 사용하여 인증함으로써 식별자에 대한 제어를 증명할 수 있다.
Decentralized Identifiers의 생성 및 주장은 엔티티에 의해 제어되므로 각 엔티티는 원하는 ID, 페르소나 및 상호 작용의 분리를 유지하는데 필요한 만큼의 DID를 가질 수 있다. 이러한 식별자의 사용은 다른 맥락에 적절하게 범위가 지정될 수 있다. 이들은 개체가 자신이나 자신이 통제하는 사물을 식별하도록 요구하는 다른 사람, 기관 또는 시스템과의 상호 작용을 지원하는 동시에 개인 또는 개인 데이터의 지속적인 존재를 보장하기 위해 중앙 기관에 의존하지 않고 얼마나 많은 개인 또는 개인 데이터가 공개되어야 하는지에 대한 제어를 제공한다. 이러한 아이디어는 DID 사용 사례 문서 [[DID-USE-CASES]]에서 살펴본다.
이 명세는 DID의 생성, 지속성, 해결 또는 해석을 뒷받침하는 특정 기술이나 암호화를 전제로 하지 않는다. 예를 들어, 구현자는 연합 또는 중앙 집중식 ID 관리 시스템에 등록된 식별자를 기반으로 DID를 생성할 수 있다. 실제로 거의 모든 유형의 식별자 시스템은 DID를 지원할 수 있다. 이는 중앙 집중식, 연합, 탈중앙식 식별자의 세계를 연결하는 상호 운용성의 다리를 만든다. 이는 구현자가 신뢰하는 컴퓨팅 인프라와 함께 작동하는 특정 유형의 DID를 설계할 수 있도록 한다. 예를들어, 분산 원장, 탈중앙화 파일 시스템, 분산 데이터베이스 및 P2P 네트워크와 같다.
본 명세서는 다음을 위한 것이다:
이 사양 외에도, 독자들은 탈중앙 식별자에 대한 사용 사례 및 요구 사항 [[DID-USE-CASES]] 문서를 유용하게 찾을 수 있을 것이다.
DID는 세 부분으로 구성된 간단한 텍스트 문자열이다: 1)
did
URI 체계 식별자, 2) DID 메소드에 대한 식별자,
그리고 3) DID 메소드별 특정 식별자.
위의 예시 DID는 DID 문서로 해석된다. DID 문서는 DID와 관련된 정보를 포함하며, 예를 들어 DID 컨트롤러를 암호학적으로 인증하는 방법과 같은 내용이 포함된다.
{
"@context": [
"https://www.w3.org/ns/did/v1",
"https://w3id.org/security/suites/ed25519-2020/v1"
]
"id": "did:example:123456789abcdefghi",
"authentication": [{
// used to authenticate as did:...fghi
"id": "did:example:123456789abcdefghi#keys-1",
"type": "Ed25519VerificationKey2020",
"controller": "did:example:123456789abcdefghi",
"publicKeyMultibase": "zH3C2AVvLMv6gmMNam3uVAjZpfkcJCwDwnZn6z3wXmqPV"
}]
}
탈중앙 식별자는 검증 가능한 크리덴셜 생태계 [[VC-DATA-MODEL]]와 같은 더 큰 시스템의 구성 요소로, 이 사양의 설계 목표에 영향을 미쳤다. 탈중앙 식별자에 대한 설계 목표는 여기에 요약되어 있다.
Goal | Description |
---|---|
분산화 | 식별자 관리에서 중앙 집중식 권한 또는 단일 실패 지점의 요구 사항을 제거하며, 이는 전 세계적으로 고유한 식별자, 공개 검증 키, 서비스, 그리고 기타 정보의 등록을 포함한다. |
제어 | 외부 권한에 의존할 필요 없이 인간 및 비인간 개체에게 그들의 디지털 식별자를 직접 제어할 수 있는 권한을 부여한다. |
프라이버시 | 개체가 정보의 프라이버시를 제어할 수 있도록 하며, 이는 최소한, 선택적 및 단계적인 속성 또는 기타 데이터의 공개를 포함한다. |
보안 | 요청하는 당사자가 필요한 수준의 보증에 대해 DID 문서에 의존할 수 있을 만큼 충분한 보안을 제공한다. |
증명 기반 | DID 컨트롤러가 다른 개체와 상호 작용할 때 암호학적 증명을 제공할 수 있도록 한다. |
발견 가능성 | 개체가 다른 개체의 DID를 발견하여 그 개체에 대해 더 많이 알아보거나 상호 작용할 수 있도록 한다. |
상호 운용성 | 상호 운용 가능한 표준을 사용하여 DID 인프라가 상호 운용성을 위해 설계된 기존 도구 및 소프트웨어 라이브러리를 활용할 수 있도록 한다. |
휴대성 | 시스템 및 네트워크에 독립적이며 DID 및 DID 메소드를 지원하는 모든 시스템에서 디지털 식별자를 사용할 수 있도록 한다. |
단순성 | 기술을 더 쉽게 이해하고 구현하며 배포할 수 있도록 간단한 기능 세트를 선호한다. |
확장성 | 가능한 경우, 상호 운용성, 휴대성 또는 단순성을 크게 방해하지 않는 한 확장성을 제공한다. |
이 섹션은 탈중앙 식별자 구조의 주요 구성 요소에 대한 기본 개요를 제공한다.
다이어그램에는 내부적으로 레이블이 붙은 여섯 개의 도형이 있으며, 이들 사이에는 레이블이 붙은 화살표가 다음과 같이 표시되어 있다. 다이어그램의 중앙에는 "DID URL"이라고 레이블이 붙은 사각형이 있으며, 그 안에는 "did:example:123/path/to/rsrc"라고 작은 타자기 글씨가 적혀 있다. 다이어그램의 상단 중앙에는 "did:example:123"이라고 작은 타자기 글씨가 적힌 "DID"라고 레이블이 붙은 사각형이 있다. 다이어그램의 왼쪽 상단에는 "DID 주체"라고 레이블이 붙은 타원형이 있다. 다이어그램의 하단 중앙에는 "DID 문서"라고 레이블이 붙은 사각형이 있다. 왼쪽 하단에는 "DID 컨트롤러"라고 레이블이 붙은 타원형이 있다. 다이어그램의 오른쪽 중앙에는 "검증 가능한 데이터 레지스트리"라고 레이블이 붙은 원통형의 입체적인 렌더링이 있다.
"DID URL" 사각형의 상단에서 "포함함"이라고 레이블이 붙은 화살표가 위로 향하며 "DID" 사각형을 가리킨다. "DID URL" 사각형의 하단에서 "참조하며, 역참조함"이라고 레이블이 붙은 화살표가 아래로 향하며 "DID 문서" 사각형을 가리킨다. "DID" 사각형에서 "해석됨으로" 레이블이 붙은 화살표가 아래로 향해 "DID 문서" 사각형을 가리킨다. "DID" 사각형에서 "참조함으로" 레이블이 붙은 화살표가 왼쪽으로 향해 "DID 주체" 타원을 가리킨다. "DID 컨트롤러" 타원에서 "제어함"이라고 레이블이 붙은 화살표가 오른쪽으로 향해 "DID 문서" 사각형을 가리킵니다. "DID" 사각형에서 "기록됨으로" 레이블이 붙은 화살표가 오른쪽 아래로 향해 "검증 가능한 데이터 레지스트리" 원통을 가리킨다. "DID 문서" 사각형에서 "기록됨으로" 레이블이 붙은 화살표가 오른쪽 위로 향해 "검증 가능한 데이터 레지스트리" 원통을 가리킨다.
did:
, 메소드 식별자, 그리고 DID 메소드에
의해 지정된 독특한 메소드별 식별자. DID는 DID 문서로
해석된다. DID URL은 기본 DID의 구문을 확장하여 경로,
쿼리, 프래그먼트와 같은 다른 표준 URI 구성 요소를 포함하여
특정 리소스를 찾는다. 예를 들어, DID 문서 내의
암호화된 공개 키 또는 DID 문서 외부의 리소스. 이
개념들은 및
에서 자세히 설명된다.
이 문서에는 JSON 및 JSON-LD 콘텐츠가 포함된 예시가 있다. 이러한 예시
중 일부에는 잘못된 문자가 포함되어 있으며, 이에는 인라인
주석(//
)과 예시에 큰 가치를 더하지 않는 정보를 나타내기
위한 줄임표(...
)가 포함된다. 구현자들은 유효한 JSON 또는
JSON-LD로 정보를 사용하고자 할 경우 이 콘텐츠를 제거해야 한다는 점에
유의해야 한다.
일부 예시에는 이 사양에 정의되지 않은 용어들이 포함되어 있으며, 이들은
속성 이름과 값 모두에 해당한다. 이러한 용어들은 주석(// external (property name|value)
)으로 표시된다. DID 문서에서 사용될 때 이러한 용어들은 DID
사양 레지스트리 [[?DID-SPEC-REGISTRIES]]에 공식 정의 및 JSON-LD
컨텍스트와 함께 등록되어 있을 것으로 예상된다.
DID 및 DID 문서에 대한 구현의 상호 운용성은 이 사양에 부합하는 DID 및 DID 문서를 생성하고 구문 분석하는 구현의 능력을 평가함으로써 테스트된다. DID 및 DID 문서의 생산자와 소비자에 대한 상호 운용성은 DID와 DID 문서가 규범에 부합하도록 보장함으로써 제공된다. DID 메소드 사양에 대한 상호 운용성은 각 DID 메소드 사양의 세부 사항에 의해 제공된다. 웹 브라우저가 모든 알려진 URI 체계를 구현할 필요가 없는 것과 마찬가지로, DID와 작동하는 규범에 부합하는 소프트웨어가 모든 알려진 DID 메소드를 구현할 필요는 없다. 그러나 특정 DID 메소드의 모든 구현은 해당 메소드에 대해 상호 운용 가능할 것으로 예상된다.
규범에 부합하는 DID는 에서 명시된 규칙의 구체적인 표현으로, 해당 섹션의 관련 규범적 진술에 부합하는 것이다.
규범에 부합하는 DID 문서는 이 사양에서 설명된 데이터 모델의 구체적인 표현으로, 및 의 관련 규범적 진술에 부합하는 것이다. 규범에 부합하는 문서의 직렬화 형식은 에 설명된 대로 결정적이고, 양방향이며, 손실이 없다.
규범에 부합하는 생산자는 규범에 부합하는 DID 또는 규범에 부합하는 DID 문서를 생성하고 의 관련 규범적 진술에 부합하는 소프트웨어 및/또는 하드웨어로 구현된 알고리즘이다.
규범에 부합하는 소비자는 규범에 부합하는 DID 또는 규범에 부합하는 DID 문서를 소비하고 의 관련 규범적 진술에 부합하는 소프트웨어 및/또는 하드웨어로 구현된 알고리즘이다.
규범에 부합하는 DID 변환기는 의 관련 규범적 진술에 부합하는 소프트웨어 및/또는 하드웨어로 구현된 알고리즘이다.
규범에 부합하는 DID URL 역참조자는 의 관련 규범적 진술에 부합하는 소프트웨어 및/또는 하드웨어로 구현된 알고리즘이다.
이 규격은 위의 용어뿐만 아니라, 데이터 모델을 공식적으로 정의하기 위해 [[INFRA]] 규격의 용어를 사용한다. [[INFRA]] 용어가 사용될 때, 예를 들어 문자열(string), 집합(set), 맵(map)과 같은 경우, 그것은 해당 규격에 직접 연결된다.
이 섹션에서는 DID 및 DID URL의 공식 구문을 설명한다. "일반"이라는 용어는 여기에 정의된 구문을 해당 사양의 특정 DID 메소드에 의해 정의된 구문과 구별하는 데 사용된다. DID 및 DID URL의 생성 프로세스와 타이밍은 및 에 설명되어 있다.
일반 DID 체계는 [RFC3986]을 준수하는 URI 체계이다. ABNF
정의는 [RFC5234]의 구문과 ALPHA
및 DIGIT
에
대한 해당 정의를 사용하는 아래에서 찾을 수 있다. 아래 ABNF에 정의되지
않은 다른 모든 규칙 이름은 [RFC3986]에 정의되어 있다. 모든
DID는 DID 구문 ABNF 규칙을 준수해야 한다.
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 메소드 요구 사항은 섹션 을 참조하세요.
DID URL은 특정 리소스에 대한 네트워크 위치 식별자이다. 이는 DID 주체, 검증 방법, 서비스, DID 문서의 특정 부분 또는 기타 리소스와 같은 항목을 검색하는 데 사용될 수 있다.
다음은 [[!RFC5234]]의 문법을 사용하는 ABNF 정의이다. 이것은
에 정의된 did
체계에 기반을
두고 있다.
path-abempty
, query
, 그리고
fragment
구성
요소들은 [[!RFC3986]]에 정의되어 있다. 모든 DID URL은 DID URL
문법 ABNF 규칙을 준수해야 한다. DID 메소드는
에 설명된 대로 이 규칙들을 추가로 제한할
수 있다.
DID URL 구문 ABNF 규칙 |
---|
did-url = did path-abempty [ "?" query ] [ "#" fragment ] |
세미콜론(;
) 문자는 DID URL 문법의 규칙에 따라
사용될 수 있지만, 이 규격의 미래 버전에서는 [[?MATRIX-URIS]]에 설명된
대로 매개변수의 하위 구분자로 사용될 수 있다. 미래의 충돌을 피하기
위해 개발자들은 이를 사용하지 않는 것이 좋다.
DID 경로는 일반 URI 경로와 동일하며
RFC 3986, 섹션 3.3의
path-abempty
ABNF 규칙을 준수한다. URI와
마찬가지로, 경로 의미론은 DID 메소드에 의해 지정될 수 있으며,
이는 다시 DID 컨트롤러가 해당 의미론을 더욱 특화할 수 있게 할
수 있다.
did:example:123456/path
DID 쿼리는 일반 URI 쿼리와 동일하며
RFC 3986, 섹션 3.4의
query
ABNF 규칙을 준수한다. 이 문법 기능은
에서 자세히 설명되어 있다.
did:example:123456?versionId=1
DID 프레그먼트의 문법과 의미론은 일반 URI 프레그먼트와
동일하며
RFC 3986, 섹션 3.5의
fragment
ABNF 규칙을 준수한다.
DID 프레그먼트는 DID 문서나 외부 리소스로의 방법에 독립적인 참조로 사용한다. 아래에는 DID 프레그먼트 식별자의 몇 가지 예시가 나와 있다.
did:example:123#public-key-0
did:example:123#agent
did:example:123?service=agent&relativeRef=/credentials#degree
상호 운용성을 극대화하기 위해, 구현자들은 DID 프레그먼트가 표현간에 동일하게 해석되도록 보장하는 데 주의를 기울여야 한다(참조 ). 예를 들어, JSON Pointer [[?RFC6901]]가 DID 프레그먼트에서 사용될 수 있지만, 비-JSON 표현에서는 동일한 방식으로 해석되지 않을 것이다.
이 섹션의 의미론과 호환되며 그 위에 덧붙여진 프레그먼트 식별자에 대한 추가적인 의미론은 에서 JSON-LD 표현에 대해 설명되어 있다. DID 프레그먼트를 어떻게 역참조하는지에 대한 정보는 에서 확인할 수 있다.
DID URL 문법은 에서 설명된
query
구성 요소를 기반으로 한 매개변수에 대한 간단한
형식을 지원한다. DID URL에 DID 매개변수를 추가하는 것은 그
매개변수가 리소스에 대한 식별자의 일부가 된다는 것을
의미한다.
did:example:123?versionTime=2021-05-10T17:00:00Z
did:example:123?service=files&relativeRef=/resume.pdf
일부 DID 매개변수는 특정 DID 메소드와 완전히 독립적이며, 모든 DID에 대해 동일하게 작동한다. 다른 DID 매개변수는 모든 DID 메소드에서 지원되지 않다. 선택적 매개변수가 지원되는 경우, 지원하는 DID 메소드 전반에 걸쳐 균일하게 작동할 것으로 예상된다. 다음 표는 모든 DID 메소드에서 동일하게 작동하는 일반적인 DID 매개변수를 제공한다. 모든 DID 매개변수에 대한 지원은 선택적이다.
일반적으로 DID URL 역참조 구현체는 추가 구현 세부사항에 대해 [[?DID-RESOLUTION]]을 참조할 것으로 예상된다. 이 사양의 범위는 가장 일반적인 쿼리 매개변수의 계약만을 정의한다.
Parameter Name | Description |
---|---|
service
|
서비스 ID를 통해 DID 문서에서 서비스를 식별한다. 존재하는 경우, 관련 값은 반드시 ASCII 문자열이어야 한다. |
relativeRef
|
RFC3986 섹션 4.2에 따른
상대적인 URI 참조로, service 매개변수를
사용하여 DID 문서에서 선택된 서비스 엔드포인트에
위치한 리소스를 식별한다. 존재하는 경우, 관련 값은
반드시 ASCII 문자열이어야 하며
RFC3986 섹션 2.1에
명시된 대로 특정 문자에 대해 퍼센트 인코딩을 사용해야 한다.
|
versionId
|
해석될 DID 문서의 특정 버전을 식별한다(버전 ID는 순차적이거나, UUID이거나, 메소드별 특성을 가질 수 있다). 존재하는 경우, 관련 값은 반드시 ASCII 문자열이어야 한다. |
versionTime
|
해석될 DID 문서의 특정 버전 타임스탬프를 식별한다. 즉,
특정 시간에 DID에 유효했던 DID 문서이다.
존재하는 경우, 관련 값은
W3C XML 스키마 정의 언어 (XSD) 1.1 파트 2: 데이터 타입
[[XMLSCHEMA11-2]]의 섹션 3.3.7에 정의된 유효한 XML 날짜/시간
값인 ASCII 문자열이어야 한다. 이 날짜/시간 값은 UTC
00:00:00으로 정규화되어야 하며, 초 단위의 소수점 이하 정밀도는
포함하지 않아야 한다. 예를 들어:
2020-12-20T19:17:47Z .
|
hl
|
[[?HASHLINK]]에 명시된 대로 무결성 보호를 추가하기 위한 DID 문서의 리소스 해시이다. 이 매개변수는 규범적이지 않다. 존재하는 경우, 관련 값은 반드시 ASCII 문자열이어야 한다. |
구현자들과 DID 메소드 사양 저자들은 여기에 나열되지 않은 추가적인 DID 매개변수를 사용할 수 있다. 최대한의 상호 운용성을 위해, DID 매개변수가 다른 의미를 가진 동일한 DID 매개변수와의 충돌을 피하기 위해 DID 사양 레지스트리 메커니즘 [[?DID-SPEC-REGISTRIES]]을 사용하는 것이 권장된다.
DID 매개변수는 URL이 DID만을 사용하는 것보다 더 정밀하게 리소스를 참조할 필요가 있는 명확한 사용 사례가 있을 때 사용될 수 있다. DID 매개변수는 동일한 기능이 DID 변환기에 입력 메타데이터를 전달함으로써 표현될 수 있을 때 사용되지 않을 것으로 예상된다. 이러한 매개변수를 처리하는 추가적인 고려사항은 [[?DID-RESOLUTION]]에서 논의된다.
DID 해석 및 DID URL 역참조 기능은 DID URL의 일부가 아닌 입력 메타데이터를 DID 변환기에 전달함으로써 영향을 받을 수 있다(참조 ). 이는 HTTP와 비슷한데, 특정 매개변수가 HTTP URL에 포함되거나, 또는 역참조 과정 중에 HTTP 헤더로 전달될 수 있다. 중요한 구별점은 DID URL의 일부인 DID 매개변수는 어떤 리소스가 식별되는지를 명시하는 데 사용되어야 하며, DID URL의 일부가 아닌 입력 메타데이터는 그 리소스가 어떻게 해석되거나 역참조되는지를 제어하는 데 사용되어야 한다.
상대적인 DID URL은 DID 문서 내에서
did:<method-name>:<method-specific-id>
로 시작하지
않는 모든 URL 값을 의미한다. 보다 구체적으로,
에서 정의된 ABNF로 시작하지 않는 모든 URL
값을 말한다. 이 URL은 동일한 DID 문서 내의 리소스를
참조할 것으로 예상된다. 상대적인 DID URL은 상대 경로 구성
요소, 쿼리 매개변수 및 프래그먼트 식별자를 포함할 수 있다.
상대적인 DID URL 참조를 해결할 때,
RFC3986 섹션 5: 참조 해결에
명시된 알고리즘을 사용해야 한다. 기본 URI 값은
DID 주체와 연관된 DID이며, 참조
. 스키마는
did
이고, 권한은
<method-name>:<method-specific-id>
의 조합이며,
경로, 쿼리 및
프래그먼트 값은 각각 ,
및 에서 정의된 것이다.
상대적인 DID URL은 절대 URL을 사용하지 않고 DID 문서에서 검증 방법 및 서비스를 참조하는 데 종종 사용된다. 저장 공간 크기가 고려 사항인 DID 메소드는 DID 문서의 저장 크기를 줄이기 위해 상대 URL을 사용할 수 있다.
{ "@context": [ "https://www.w3.org/ns/did/v1", "https://w3id.org/security/suites/ed25519-2020/v1" ] "id": "did:example:123456789abcdefghi", "verificationMethod": [{ "id": "did:example:123456789abcdefghi#key-1", "type": "Ed25519VerificationKey2020", // external (property value) "controller": "did:example:123456789abcdefghi", "publicKeyMultibase": "zH3C2AVvLMv6gmMNam3uVAjZpfkcJCwDwnZn6z3wXmqPV" }, ...], "authentication": [ // a relative DID URL used to reference a verification method above "#key-1" ] }
In the example above, the relative DID URL value will be
transformed to an absolute DID URL value of
did:example:123456789abcdefghi#key-1
.
이 사양은 DID 문서와 DID 문서 데이터 구조를 표현하는 데 사용될 수 있는 데이터 모델을 정의한다. 이 데이터 모델은 여러 구체적인 표현으로 직렬화될 수 있다. 이 섹션은 데이터 모델의 고수준 설명, 데이터 모델에서 다양한 유형의 속성이 표현되는 방법에 대한 설명, 그리고 데이터 모델 확장 지침을 제공한다.
DID 문서는 map의 엔트리들로 구성되며, 각 엔트리는 키/값 쌍으로 구성된다. DID 문서 데이터 모델은 적어도 두 가지 다른 클래스의 엔트리를 포함한다. 첫 번째 클래스의 엔트리는 속성이라고 하며, 섹션에서 명시된다. 두 번째 클래스는 표현별 항목으로 구성되며, 섹션에서 명시된다.
DID 문서 데이터 모델의 모든 엔트리 키는 문자열이다. 모든 엔트리 값은 아래 표에 있는 추상 데이터 타입 중 하나를 사용하여 표현되며, 각 표현은 각 데이터 타입의 구체적인 직렬화 형식을 명시한다.
Data Type | Considerations |
---|---|
map | 키/값 쌍의 유한한 순서 있는 시퀀스로, [INFRA]에 명시된 대로 같은 키가 두 번 나타나지 않는다. map은 때때로 [INFRA]에서 ordered map으로 언급된다. |
list | [INFRA]에 명시된 대로 항목들의 유한한 순서 있는 시퀀스이다. |
set | 같은 항목이 두 번 포함되지 않는, [INFRA]에 명시된 대로 항목들의 유한한 순서 있는 시퀀스이다. 세트는 때때로 [INFRA]에서 ordered set로 언급된다. |
datetime |
[XMLSCHEMA11-2]에 명시된
대로 dateTime 에 의해 표현될 수 있는 모든 값을 손실
없이 표현할 수 있는 날짜 및 시간 값이다.
|
string | [INFRA]에 명시된 대로 주로 인간이 읽을 수 있는 언어를 표현하는 데 사용되는 코드 단위의 시퀀스이다. |
integer | 분수 구성 요소가 없는 실수로 [XMLSCHEMA11-2]에 명시되어 있다. 상호 운용성을 극대화하기 위해, 구현자는 RFC8259, Section 6: Numbers 숫자에 대한 정수 관련 조언을 주의 깊게 따를 것을 권장한다. |
double | [XMLSCHEMA11-2]에 명시된 대로 임의의 실수를 근사하는 데 종종 사용되는 값이다. 상호 운용성을 극대화하기 위해, 구현자는 RFC8259, Section 6: Numbers에 대한 더블 관련 조언을 주의 깊게 따를 것을 권장한다. |
boolean | [INFRA]에서 정의된 대로 참 또는 거짓인 값이다. |
null | 값이 없음을 나타내는 데 사용되는 값으로 [INFRA]에서 정의되어 있다. |
데이터 모델이 [INFRA]에서 사용하는 용어를 사용하여 정의된 결과로, 리스트, maps and sets와 같이 하나 이상의 항목을 포함할 수 있는 속성 값은 명시적으로 순서가 지정된다. [INFRA]의 모든 리스트와 유사한 값 구조는 순서가 있으며, 그 순서가 중요한지 여부와 관계없이 순서가 있다. 이 규격의 목적상, 다르게 명시되지 않는 한, map과 set의 순서는 중요하지 않으며, 구현이 결정적으로 순서 있는 값을 생성하거나 소비할 것으로 기대되지 않는다.
데이터 모델은 두 가지 유형의 확장성을 지원한다.
등록되지 않은 확장은 신뢰도가 낮다. 항상 DID 규격 레지스트리 [[?DID-SPEC-REGISTRIES]]에 기록되지 않은 상호 이해하는 확장이나 표현을 사용하기로 두 특정 구현이 사전에 합의할 가능성이 있으며, 이러한 구현과 더 큰 생태계 사이의 상호 운용성은 신뢰도가 낮다.
DID는 DID 문서와 연관된다. DID 문서는 데이터 모델을 사용하여 표현되며, 표현으로 직렬화될 수 있다. 다음 섹션은 DID 문서의 속성을 정의하며, 이러한 속성이 필수인지 선택적인지를 포함한다. 이러한 속성은 DID 주체와 속성의 값 사이의 관계를 설명한다.
다음 표에는 이 규격에 의해 정의된 핵심 속성에 대한 정보 참조가 포함되어 있으며, 예상되는 값과 필수 여부를 포함한다. 표의 속성 이름은 각 속성의 규범적 정의와 더 자세한 설명으로 연결된다.
다른 유형의 map에서 사용되는 속성 이름 id
,
type
, 및 controller
속성 이름은 가능한 제약
사항에서 차이가 있을 수 있는 다양한 유형의 map에 존재할 수 있다.
Property | Required? | Value constraints |
---|---|---|
id
|
yes | 의 규칙을 준수하는 문자열이다. |
alsoKnownAs
|
no | [[RFC3986]]에 대한 URIs의 규칙을 준수하는 문자열의 set이다. |
controller
|
no | 의 규칙을 준수하는 문자열 또는 문자열의 set이다. |
verificationMethod
|
no | 을 준수하는 Verification Method maps의 set이다. |
authentication
|
no | 을 준수하는 Verification Method maps의 set) 또는 의 규칙을 준수하는 문자열의 set이다. |
assertionMethod
|
no | |
keyAgreement
|
no | |
capabilityInvocation
|
no | |
capabilityDelegation
|
no | |
service
|
no | 의 규칙을 준수하는 Service Endpoint maps의 set이다. |
Property | Required? | Value constraints |
---|---|---|
id |
yes | 의 규칙을 준수하는 문자열이다. |
controller
|
yes | 의 규칙을 준수하는 문자열이다. |
type |
yes | 문자열이다. |
publicKeyJwk
|
no | [[RFC7517]]을 준수하는 JSON Web Key를 나타내는 map이다. 추가 제약사항은 publicKeyJwk의 정의를 참조. |
publicKeyMultibase
|
no | [[?MULTIBASE]]로 인코딩된 공개키를 준수하는 문자열이다. |
Property | Required? | Value constraints |
---|---|---|
id |
yes | [[RFC3986]]에 대한 URIs의 규칙을 준수하는 문자열이다. |
type |
yes | 문자열 또는 문자열의 set이다. |
serviceEndpoint
|
yes | [[RFC3986]]에 대한 URIs의 규칙을 준수하는 문자열, map, 또는 [[RFC3986]]에 대한 URIs의 규칙을 준수하는 하나 이상의 문자열과 또는 map으로 구성된 set이다. |
이 섹션은 DID 문서가 DID 주체와 DID 컨트롤러를 위한 식별자를 포함하는 메커니즘을 설명한다.
특정 DID 주체에 대한 DID는 DID 문서의
id
속성을 사용하여 표현된다.
id
의 값은 의 규칙을
준수하는 문자열이어야 하며
DID 문서의 데이터 모델의 루트
map에 반드시 존재해야 한다.
{ "id": "did:example:123456789abcdefghijk" }
id
속성은 DID 문서의 최상위
map에 존재할 때만
DID 주체의 DID를 나타낸다.
DID 메소드 규격은 DID 문서의
id
속성이 포함되지 않는 중간 표현을 생성할 수
있다. 예를 들어 DID 변환기가 DID 해석을 수행할 때와
같은 경우이다. 그러나 완전히 해석된 DID 문서는 항상 유효한
id
속성을 포함한다.
DID 컨트롤러는 DID 문서 변경 권한을 부여받은 개체이다. DID 컨트롤러를 승인하는 과정은 DID 메소드에 의해 정의된다.
controller
의 속성은 선택 사항이다. 존재하는 경우,
값은 의 규칙을 준수하는
문자열 또는
문자열의
set여야 한다. 해당하는 DID
문서(들)은 특정 검증 방법을 특정 목적으로 사용할 수 있도록
명시적으로 허용하는 검증 관계를 포함해야 한다.
DID 문서에 controller
속성이 존재하는
경우, 그 값은 하나 이상의 DID를 표현한다. 그 DID들의
DID 문서에 포함된 모든 검증 방법은 권위 있는 것으로
받아들여져야 하며, 그 검증 방법을 만족하는 증명은
DID 주체가 제공한 증명과 동등하게 간주되어야 한다.
{ "@context": "https://www.w3.org/ns/did/v1", "id": "did:example:123456789abcdefghi", "controller": "did:example:bcehfew7h32f32h7af3", }
controller
의 값에 의해 제공되는 승인은
에서 설명하는 인증과 별개이다. 이는
특히 암호화 키 손실의 경우 키 복구에 중요하다. 여기서
DID 주체는 더 이상 자신의 키에 접근할 수 없거나, 키 타협의
경우, DID 컨트롤러의 신뢰할 수 있는 제3자가 공격자에 의한
악의적인 활동을 무효화할 필요가 있다. 위협 모델 및 공격 벡터와
관련된 정보는 을 참조.
DID 주체는 다양한 목적을 위해서나 서로 다른 시간에 대해 여러
식별자를 가질 수 있다. 두 개 이상의 DID(또는 다른 유형의
URI)가 동일한 DID 주체를 참조한다는 주장은
alsoKnownAs
속성을 사용하여 제기될 수 있다.
alsoKnownAs
속성은 선택 사항이다. 속성이 존재하는
경우, 값은 [[RFC3986]]에 따른 URI를 준수하는
set의 각 항목이어야 한다.
응용 프로그램은 alsoKnownAs
관계가 역방향으로
상호 작용할 경우 두 식별자를 등가로 간주할 수 있다. 이 역 관계가
없는 경우에는 등가로 간주하지 않는 것이 최선이다. 즉,
alsoKnownAs
주장의 존재가 이 주장이 참임을
증명하지는 않는다. 따라서 요청하는 당사자가
alsoKnownAs
주장의 독립적인 검증을 받는 것이 강력히
권장된다.
DID 주체가 다양한 목적을 위해 다른 식별자를 사용할 수 있기 때문에, 두 식별자 간의 강력한 등가성 기대나 해당하는 두 DID 문서의 정보를 병합하는 것은 상호 관계가 있더라도 반드시 적절하지는 않다.
DID 문서는 암호화 공개 키와 같은 검증 방법을 표현할 수 있으며, 이는 DID 주체 또는 관련 당사자와의 상호 작용을 인증하거나 인가하는 데 사용될 수 있다. 예를 들어, 암호화 공개 키는 디지털 서명과 관련하여 검증 방법으로 사용될 수 있으며, 이 경우 서명자가 관련 암호화 개인 키를 사용할 수 있음을 검증한다. 검증 방법은 많은 매개변수를 가질 수 있다. 이의 예는 암호화 임계값 서명에 기여해야 하는 다섯 개의 암호화 키 중에서 어느 세 개가 필요한 세트이다.
verificationMethod
속성은 선택 사항이다. 속성이
존재하는 경우, 값은 map을
사용하여 표현된 검증 방법의
set여야 한다. 검증 방법
map에는 id
,
type
, controller
및 type
의
값에 따라 결정되고 에서
정의된 특정 검증 재료 속성이 포함되어야 한다. 검증 방법에는
추가 속성이 포함될 수 있다. 검증 방법은 DID 규격 레지스트리
[[DID-SPEC-REGISTRIES]]에 등록되어야 한다.
{ "@context": [ "https://www.w3.org/ns/did/v1", "https://w3id.org/security/suites/jws-2020/v1" "https://w3id.org/security/suites/ed25519-2020/v1" ] "id": "did:example:123456789abcdefghi", ... "verificationMethod": [{ "id": ..., "type": ..., "controller": ..., "publicKeyJwk": ... }, { "id": ..., "type": ..., "controller": ..., "publicKeyMultibase": ... }] }
controller
속성의 의미는 관계의 주체가 DID 문서일
때와 암호화 공개 키와 같은 검증 방법일 때 동일한다. 키가 자기 자신을
제어할 수 없고 키의 컨트롤러가 DID 문서에서 유추될 수 없기
때문에, 키 컨트롤러의 정체성을 명시적으로 표현할 필요가 있다. 차이점은
검증 방법에 대한 컨트롤러의 값이 반드시 DID 컨트롤러일 필요는
없다는 것이다. DID 컨트롤러는 DID 문서의 최상위 수준(데이터 모델의 최상위 map)에서 컨트롤러
속성을 사용하여 표현됩니다; 를 참조.
검증 자료는 검증 방법을 적용하는 프로세스에서 사용되는 모든
정보를 말한다. 검증 방법의 type
은 해당
프로세스와의 호환성을 결정하는 데 사용될 것으로 예상된다. 검증 자료
속성의 예로는 publicKeyJwk
나 publicKeyMultibase
가 있다. 암호화 스위트 규격은 검증 방법의
type
과 관련 검증 자료를 지정할 책임이 있다. 예를 들어,
JSON Web Signature 2020과
Ed25519 Signature 2020을 참조하라. DID에 사용 가능한 모든 등록된
검증 방법 유형과 관련 검증 자료는 DID 규격 레지스트리
[[?DID-SPEC-REGISTRIES]]를 참조하라.
상호 운용 가능한 구현의 가능성을 높이기 위해, 이 규격은 DID 문서에서 검증 자료를 표현하기 위한 형식의 수를 제한한다. 구현자들이 구현해야 할 형식이 적을수록 모든 형식을 지원할 가능성이 높아진다. 이 접근 방식은 구현의 용이성과 역사적으로 널리 배포되어 온 형식을 지원하는 것 사이에서 미묘한 균형을 맞추려고 시도한다. 지원되는 두 가지 검증 자료 속성은 다음과 같다:
publicKeyJwk
속성은 선택
사항이다. 존재하는 경우, 그 값은 [[RFC7517]]을 준수하는 JSON Web
Key를 나타내는 map이어야
한다. 이 map은 "d"나
등록 템플릿에 설명된 비공개 정보 클래스의 다른 멤버를 포함해서는 안 된다.
JWK [[RFC7517]]를 사용하여 공개 키를 표현하는 검증 방법은
kid
의 값을
프래그먼트 식별자로 사용하는 것이
권장된다. JWK kid
값은 공개 키 지문 [[RFC7638]]으로
설정하는 것이 권장된다. 복합 키 식별자를 가진 공개 키의 예시는
의 첫
번째 키를 참조하라.
publicKeyMultibase
속성은 선택 사항이다. 이 기능은
비규범적이다. 존재하는 경우, 그 값은 [[?MULTIBASE]]로 인코딩된
공개 키의 문자열 표현이어야
한다.
[[?MULTIBASE]] 규격은 아직 표준이 아니며 변경될 수 있다는 점에
유의하라. 공개 키를 표현할 수 있도록
publicKeyMultibase
가 정의되지만, 비밀 키의
우발적 누출을 방지하기 위해
privateKeyMultibase
는 정의되지 않는 경우와
같이 이 데이터 형식에 대한 일부 사용 사례가 있을 수 있다.
검증 방법은 동일한 자료에 대해 여러 검증 자료 속성을
포함해서는 안 된다. 예를 들어, 검증 방법에서
publicKeyJwk
와 publicKeyMultibase
를 동시에
사용하여 키 자료를 표현하는 것은 금지된다.
위의 두 속성을 모두 사용하는 검증 방법을 포함하는 DID 문서의 예는 아래와 같다.
{ "@context": [ "https://www.w3.org/ns/did/v1", "https://w3id.org/security/suites/jws-2020/v1", "https://w3id.org/security/suites/ed25519-2020/v1" ] "id": "did:example:123456789abcdefghi", ... "verificationMethod": [{ "id": "did:example:123#_Qq0UL2Fq651Q0Fjd6TvnYE-faHiOpRlPVQcY_-tA4A", "type": "JsonWebKey2020", // external (property value) "controller": "did:example:123", "publicKeyJwk": { "crv": "Ed25519", // external (property name) "x": "VCpo2LMLhn6iWku8MKvSLg2ZAoC-nlOyPVQaO3FxVeQ", // external (property name) "kty": "OKP", // external (property name) "kid": "_Qq0UL2Fq651Q0Fjd6TvnYE-faHiOpRlPVQcY_-tA4A" // external (property name) } }, { "id": "did:example:123456789abcdefghi#keys-1", "type": "Ed25519VerificationKey2020", // external (property value) "controller": "did:example:pqrstuvwxyz0987654321", "publicKeyMultibase": "zH3C2AVvLMv6gmMNam3uVAjZpfkcJCwDwnZn6z3wXmqPV" }], ... }
검증 방법은 에 설명된 대로 다양한 검증 관계와 관련된 속성에 내장되거나 참조될 수 있다. 검증 방법을 참조하면 둘 이상의 검증 관계에서 사용될 수 있다.
검증 방법 속성의 값이
map인 경우, 검증 방법은
내장된 것이며 해당 속성에 직접 액세스할 수 있다. 그러나 값이 URL
문자열인 경우, 검증 방법은
참조에 의해 포함된 것이며 해당 속성은 DID 문서의 다른 곳이나
다른 DID 문서에서 검색되어야 한다. 이는 URL을 역참조하고 결과
리소스에서 값이 URL과 일치하는 id
속성을 가진
검증 방법 map을 검색하여
수행된다.
{ ... "authentication": [ // this key is referenced and might be used by // more than one verification relationship "did:example:123456789abcdefghi#keys-1", // this key is embedded and may *only* be used for authentication { "id": "did:example:123456789abcdefghi#keys-2", "type": "Ed25519VerificationKey2020", // external (property value) "controller": "did:example:123456789abcdefghi", "publicKeyMultibase": "zH3C2AVvLMv6gmMNam3uVAjZpfkcJCwDwnZn6z3wXmqPV" } ], ... }
검증 관계는 DID 주체와 검증 방법 사이의 관계를 표현한다.
서로 다른 검증 관계는 관련된 검증 방법이 다른 목적으로 사용될 수 있게 한다. 사용된 검증 방법이 DID 문서의 적절한 검증 관계 속성에 포함되어 있는지 확인함으로써 검증 시도의 유효성을 확인하는 것은 검증자의 몫이다.
DID 주체와 검증 방법 사이의 검증 관계는
DID 문서에 명시되어 있다. 특정 검증 관계와 관련되지 않은
검증 방법은 해당 검증 관계에 사용될 수 없다. 예를 들어,
authentication
속성의 값에 있는 검증 방법은
DID 주체와 키 교환 프로토콜에 참여하는 데 사용될 수 없다. 이를
위해서는 keyAgreement
속성의 값이 사용되어야 한다.
DID 문서는 검증 관계를 사용하여 폐기된 키를 표현하지 않는다. 참조된 검증 방법이 역참조에 사용된 최신 DID 문서에 없는 경우, 해당 검증 방법은 유효하지 않거나 폐기된 것으로 간주된다. 각 DID 메소드 규격은 폐기가 어떻게 수행되고 추적되는지 상세히 설명해야 한다.
다음 섹션에서는 몇 가지 유용한 검증 관계를 정의한다. DID 문서는 특정 검증 관계를 표현하기 위해 이들 중 어느 것이든 또는 다른 속성들을 포함할 수 있다. 전 세계적인 상호 운용성을 극대화하기 위해, 사용되는 그러한 모든 속성은 DID 규격 레지스트리 [[?DID-SPEC-REGISTRIES]]에 등록되어야 한다.
authentication
검증 관계는 웹사이트 로그인이나
모든 종류의 챌린지-응답 프로토콜 참여와 같은 목적으로
DID 주체가 어떻게 인증될 것으로 예상되는지 명시하는 데
사용된다.
authentication
속성은 선택 사항이다. 존재하는 경우,
관련된 값은 하나 이상의 검증 방법의
set이어야 한다. 각
검증 방법은 내장되거나 참조될 수 있다.
{ "@context": [ "https://www.w3.org/ns/did/v1", "https://w3id.org/security/suites/ed25519-2020/v1" ], "id": "did:example:123456789abcdefghi", ... "authentication": [ // this method can be used to authenticate as did:...fghi "did:example:123456789abcdefghi#keys-1", // this method is *only* approved for authentication, it may not // be used for any other proof purpose, so its full description is // embedded here rather than using only a reference { "id": "did:example:123456789abcdefghi#keys-2", "type": "Ed25519VerificationKey2020", "controller": "did:example:123456789abcdefghi", "publicKeyMultibase": "zH3C2AVvLMv6gmMNam3uVAjZpfkcJCwDwnZn6z3wXmqPV" } ], ... }
인증이 확립되면, 해당 정보를 어떻게 처리할 것인지는 DID 메소드 또는 다른 애플리케이션에 달려 있다. 특정 DID 메소드는 DID 컨트롤러로 인증하는 것이 예를 들어 DID 문서를 업데이트하거나 삭제하기에 충분하다고 결정할 수 있다. 다른 DID 메소드는 DID 문서를 업데이트하거나 삭제하기 위해 인증에 사용된 것과는 다른 키 또는 완전히 다른 검증 방법이 제시되어야 할 수 있다. 즉, 인증 확인 이후에 수행되는 작업은 데이터 모델의 범위를 벗어난다; DID 메소드와 애플리케이션은 이를 스스로 정의해야 한다.
이는 인증을 시도하는 엔티티가 실제로 유효한 인증 증명을
제시하고 있는지 확인할 필요가 있는 모든 인증 검증자에게
유용하다. 검증자가 "인증"의 목적으로 만들어진 증명을
포함하고 엔티티가 DID에 의해 식별된다고 말하는 (일부
프로토콜별 형식의) 일부 데이터를 수신하면, 해당 검증자는
DID 문서의 authentication
아래에 나열된
검증 방법(예: 공개 키)을 사용하여 증명을 검증할 수 있는지
확인한다.
DID 문서의 authentication
속성에 의해
표시된 검증 방법은 DID 주체를 인증하는 데만
사용될 수 있음에 유의하라. 다른 DID 컨트롤러를
인증하려면 에 정의된 대로
controller
값과 관련된 엔티티가 자신의
DID 문서 및 관련 authentication
검증 관계로 인증해야 한다.
assertionMethod
검증 관계는 검증 가능한 크리덴셜
[[?VC-DATA-MODEL]]을 발행하는 목적과 같이 DID 주체가 어떻게
클레임을 표현할 것으로 예상되는지 명시하는 데 사용된다.
assertionMethod
속성은 선택 사항이다. 존재하는 경우,
관련된 값은 하나 이상의 검증 방법의
set이어야 한다. 각
검증 방법은 내장되거나 참조될 수 있다.
이 속성은 예를 들어, 검증자가 검증 가능한 크리덴셜을 처리하는
동안 유용하다. 검증 중에 검증자는 검증 가능한 크리덴셜에
증명을 어설션하는 데 사용된 검증 방법이 해당
DID 문서의 assertionMethod
속성과
연결되어 있는지 확인함으로써 DID 주체가 생성한 증명이
포함되어 있는지 확인한다.
{ "@context": [ "https://www.w3.org/ns/did/v1", "https://w3id.org/security/suites/ed25519-2020/v1" ], "id": "did:example:123456789abcdefghi", ... "assertionMethod": [ // this method can be used to assert statements as did:...fghi "did:example:123456789abcdefghi#keys-1", // this method is *only* approved for assertion of statements, it is not // used for any other verification relationship, so its full description is // embedded here rather than using a reference { "id": "did:example:123456789abcdefghi#keys-2", "type": "Ed25519VerificationKey2020", // external (property value) "controller": "did:example:123456789abcdefghi", "publicKeyMultibase": "zH3C2AVvLMv6gmMNam3uVAjZpfkcJCwDwnZn6z3wXmqPV" } ], ... }
keyAgreement
검증 관계는 수신자와 안전한 통신
채널을 설정하기 위한 목적과 같이 DID 주체에게 전달되는 기밀
정보를 전송하기 위해 엔티티가 암호화 자료를 생성하는 방법을 지정하는
데 사용된다.
keyAgreement
속성은 선택 사항이다. 존재하는 경우,
관련된 값은 하나 이상의 검증 방법의
set이어야 한다. 각
검증 방법은 내장되거나 참조될 수 있다.
이 속성이 유용한 예는 DID 주체에게 전달하려는 메시지를 암호화할 때이다. 이 경우, 상대방은 검증 방법의 암호화 공개 키 정보를 사용하여 수신자를 위한 복호화 키를 래핑한다.
{ "@context": "https://www.w3.org/ns/did/v1", "id": "did:example:123456789abcdefghi", ... "keyAgreement": [ // this method can be used to perform key agreement as did:...fghi "did:example:123456789abcdefghi#keys-1", // this method is *only* approved for key agreement usage, it will not // be used for any other verification relationship, so its full description is // embedded here rather than using only a reference { "id": "did:example:123#zC9ByQ8aJs8vrNXyDhPHHNNMSHPcaSgNpjjsBYpMMjsTdS", "type": "X25519KeyAgreementKey2019", // external (property value) "controller": "did:example:123", "publicKeyMultibase": "z9hFgmPVfmBZwRvFEyniQDBkz9LmV7gDEqytWyGZLmDXE" } ], ... }
capabilityInvocation
검증 관계는
DID 문서를 업데이트할 권한과 같은 암호화 기능을 호출하기 위해
DID 주체가 사용할 수 있는 검증 방법을 지정하는 데
사용된다.
capabilityInvocation
속성은 선택 사항이다. 존재하는
경우, 관련된 값은 하나 이상의 검증 방법의
set이어야 한다. 각
검증 방법은 내장되거나 참조될 수 있다.
이 속성이 유용한 예는 DID 주체가 사용하기 위해 인증이 필요한 보호된 HTTP API에 액세스해야 할 때이다. HTTP API를 사용할 때 인증하기 위해, DID 주체는 HTTP API를 통해 노출되는 특정 URL과 연결된 기능을 사용한다. 기능의 호출은 예를 들어 HTTP 헤더에 배치되는 디지털 서명된 메시지와 같이 여러 가지 방법으로 표현될 수 있다.
HTTP API를 제공하는 서버는 기능의 검증자이며, 호출된
기능에서 참조하는 검증 방법이 DID 문서의
capabilityInvocation
속성에 존재하는지 검증해야
한다. 검증자는 또한 수행되는 작업이 유효하고 기능이 액세스되는
리소스에 적절한지 확인한다. 검증이 성공하면, 서버는 호출자가 보호된
리소스에 액세스할 권한이 있음을 암호학적으로 결정한다.
{ "@context": [ "https://www.w3.org/ns/did/v1", "https://w3id.org/security/suites/ed25519-2020/v1" ], "id": "did:example:123456789abcdefghi", ... "capabilityInvocation": [ // this method can be used to invoke capabilities as did:...fghi "did:example:123456789abcdefghi#keys-1", // this method is *only* approved for capability invocation usage, it will not // be used for any other verification relationship, so its full description is // embedded here rather than using only a reference { "id": "did:example:123456789abcdefghi#keys-2", "type": "Ed25519VerificationKey2020", // external (property value) "controller": "did:example:123456789abcdefghi", "publicKeyMultibase": "zH3C2AVvLMv6gmMNam3uVAjZpfkcJCwDwnZn6z3wXmqPV" } ], ... }
capabilityDelegation
검증 관계는
DID 주체가 특정 HTTP API에 대한 액세스 권한을 하위 주체에
위임하는 것과 같이 암호화 기능을 다른 당사자에게 위임하는 데 사용할
수 있는 메커니즘을 지정하는 데 사용된다.
capabilityDelegation
속성은 선택 사항이다. 존재하는
경우, 관련된 값은 하나 이상의 검증 방법의
set이어야 한다. 각
검증 방법은 내장되거나 참조될 수 있다.
이 속성이 유용한 예는 DID 컨트롤러가 보호된 HTTP API에
액세스할 수 있는 자신의 능력을 자신 이외의 당사자에게 위임하기로
선택할 때이다. 능력을 위임하기 위해, DID 주체는
capabilityDelegation
검증 관계와 연결된
검증 방법을 사용하여 다른 DID 주체에게 능력을
암호학적으로 서명할 것이다. 그러면 대리인은
에 설명된 예와 유사한 방식으로
그 능력을 사용할 것이다.
{ "@context": [ "https://www.w3.org/ns/did/v1", "https://w3id.org/security/suites/ed25519-2020/v1" ], "id": "did:example:123456789abcdefghi", ... "capabilityDelegation": [ // this method can be used to perform capability delegation as did:...fghi "did:example:123456789abcdefghi#keys-1", // this method is *only* approved for granting capabilities; it will not // be used for any other verification relationship, so its full description is // embedded here rather than using only a reference { "id": "did:example:123456789abcdefghi#keys-2", "type": "Ed25519VerificationKey2020", // external (property value) "controller": "did:example:123456789abcdefghi", "publicKeyMultibase": "zH3C2AVvLMv6gmMNam3uVAjZpfkcJCwDwnZn6z3wXmqPV" } ], ... }
서비스는 DID 문서에서 DID 주체 또는 관련 엔티티와 통신하는 방법을 표현하는 데 사용된다. 서비스는 DID 주체가 추가 탐색, 인증, 권한 부여 또는 상호 작용을 위한 탈중앙 신원 관리 서비스를 포함하여 광고하고자 하는 모든 유형의 서비스일 수 있다.
개인 정보 보호 문제로 인해, 소셜 미디어 계정, 개인 웹사이트, 이메일 주소와 같은 서비스를 통해 공개 정보를 공개하는 것은 권장되지 않는다. 개인 정보 보호 문제에 대한 추가 탐색은 와 에서 찾을 수 있다. 서비스와 관련된 정보는 종종 서비스에 특화되어 있다. 예를 들어, 암호화된 메시징 서비스와 관련된 정보는 메시징이 시작되기 전에 암호화된 링크를 시작하는 방법을 표현할 수 있다.
서비스는 아래에 설명된 service
속성을
사용하여 표현된다:
service
속성은 선택 사항이다. 존재하는 경우, 관련된
값은 각 서비스가 map으로
설명되는 서비스의
set이어야 한다. 각
서비스 map은
id
, type
, serviceEndpoint
속성을
포함해야 한다. 각 서비스 확장은 추가 속성을 포함할 수 있으며
확장과 관련된 속성을 더 제한할 수 있다.
id
속성의 값은 [[RFC3986]]을 준수하는
URI여야 한다. 규범에 부합하는 생산자는 동일한
id
를 가진 여러 개의 service
항목을
생성해서는 안 된다. 규범에 부합하는 소비자는 동일한
id
를 가진 여러 개의 service
항목이
감지되면 오류를 생성해야 한다.
type
속성의 값은
문자열 또는
문자열의
set이어야 한다. 상호
운용성을 최대화하기 위해 service 유형과 관련 속성은 DID
규격 레지스트리 [[?DID-SPEC-REGISTRIES]]에 등록되어야 한다.
serviceEndpoint
속성의 값은
문자열,
map, 또는 하나 이상의
문자열 및/또는
map으로 구성된
set이어야 한다. 모든
문자열 값은 [[RFC3986]]을
준수하는 유효한 URI여야 하며
RFC3986의 정규화 및 비교 규칙과 해당 URI 체계 규격의 모든 정규화 규칙에 따라
정규화되어야 한다.
For more information regarding privacy and security considerations related to services see , , , and .
{
"service": [{
"id":"did:example:123#linked-domain",
"type": "LinkedDomains", // external (property value)
"serviceEndpoint": "https://bar.example.com"
}]
}
이 규격에서 DID 문서의 구체적인 직렬화를 표현이라고 한다. 표현은 생산이라고 하는 프로세스를 통해 데이터 모델을 직렬화하여 생성된다. 표현은 소비라고 하는 프로세스를 통해 데이터 모델로 변환된다. 생산 및 소비 프로세스를 통해 정보를 한 표현에서 다른 표현으로 변환할 수 있다. 이 규격은 JSON과 JSON-LD에 대한 표현을 정의하며, 개발자는 데이터 모델을 표현할 수 있는 XML이나 YAML과 같은 다른 표현을 사용할 수 있다. 다음 섹션에서는 JSON 및 JSON-LD 표현뿐만 아니라 생산 및 소비에 대한 일반적인 규칙을 정의한다.
이 규격에 정의된 표현 외에도, 구현자는 각 표현이 적절하게 지정되어 있는 경우(DID 규격 레지스트리 [[?DID-SPEC-REGISTRIES]]에 나열되지 않은 속성의 상호 운용 가능한 처리를 위한 규칙 포함) 다른 표현을 사용할 수 있다. 자세한 내용은 를 참조하라.
모든 표현에 대한 요구사항은 다음과 같다:
dateTime
어휘 직렬화를 사용한다. 표현은
데이터 모델로 다시 소비하는
과정에서 손실이 없는 한 다른 어휘 직렬화를 사용하여
데이터 모델 데이터 유형을 직렬화하도록
선택할 수 있다. 예를 들어, 일부 CBOR 기반 표현은 Unix 시대
이후의 초 수를 나타내는 정수를 사용하여 datetime 값을
표현한다.
모든 규범에 부합하는 생산자에 대한 요구사항은 다음과 같다:
모든 규범에 부합하는 소비자에 대한 요구사항은 다음과 같다:
The upper left quadrant of the diagram contains a rectangle with dashed grey outline, containing two blue-outlined rectangles, one above the other. The upper, larger rectangle is labeled, in blue, "Core Properties", and contains the following INFRA notation:
«[ "id" → "example:123", "verificationMethod" → « «[ "id": "did:example:123#keys-1", "controller": "did:example:123", "type": "Ed25519VerificationKey2018", "publicKeyBase58": "H3C2AVvLMv6gmMNam3uVA" ]» », "authentication" → « "did:example:123#keys-1" » ]»The lower, smaller rectangle is labeled, in blue, "Core Representation-specific Entries (JSON-LD)", and contains the following monospaced INFRA notation:
«[ "@context" → "https://www.w3.org/ns/did/v1" ]»
From the grey-outlined rectangle, three pairs of arrows extend to three different black-outlined rectangles, one on the upper right of the diagram, one in the lower right, and one in the lower left. Each pair of arrows consists of one blue arrow pointing from the grey-outlined rectangle to the respective black-outlined rectangle, labeled "produce", and one red arrow pointing in the reverse direction, labeled "consume". The black-outlined rectangle in the upper right is labeled "application/did+cbor", and contains hexadecimal data. The rectangle in the lower right is labeled "application/did+json", and contains the following JSON data:
{ "id": "did:example:123", "verificationMethod": [{ "id": "did:example:123#keys-1", "controller": "did:example:123", "type": "Ed25519VerificationKey2018", "publicKeyBase58": "H3C2AVvLMv6gmMNam3uVA" }], "authentication": [ "did:example:123#keys-1" ] }
The rectangle in the lower left is labeled "application/did+ld+json", and contains the following JSON-LD data:
{ "@context": ["https://www.w3.org/ns/did/v1"], "id": "did:example:123", "verificationMethod": [{ "id": "did:example:123#keys-1", "controller": "did:example:123", "type": "Ed25519VerificationKey2018", "publicKeyBase58": "H3C2AVvLMv6gmMNam3uVA" }], "authentication": [ "did:example:123#keys-1" ] }
An implementation is expected to convert between representations by using the consumption rules on the source representation resulting in the data model and then using the production rules to serialize data model to the target representation, or any other mechanism that results in the same target representation.
이 섹션에서는 JSON 표현에 대한 생산 및 소비 규칙을 정의한다.
DID 문서, DID 문서 데이터 구조 및 representation-specific entries map은 다음 생산 규칙에 따라 JSON 표현으로 직렬화되어야 한다:
데이터 유형 | JSON 표현 유형 |
---|---|
map | 각 항목이 JSON 객체의 멤버로 직렬화되며, 항목 키는 JSON 문자열 멤버 이름으로, 항목 값은 이 표에 정의된 대로 해당 유형에 따라 직렬화되는 JSON 객체. |
list | 목록의 각 요소가 순서대로 이 표에 정의된 대로 해당 유형에 따라 배열의 값으로 직렬화되는 JSON 배열. |
set | 집합의 각 요소가 순서대로 이 표에 정의된 대로 해당 유형에 따라 배열의 값으로 추가되는 JSON 배열. |
datetime |
UTC 00:00:00으로 정규화되고 초 미만의 소수 자릿수 정밀도 없이
XML Datetime으로
직렬화된 JSON 문자열. 예:
2020-12-20T19:17:47Z .
|
string | JSON 문자열. |
integer | 소수 또는 분수 성분이 없는 JSON 숫자. |
double | 소수와 분수 성분이 있는 JSON 숫자. |
boolean | JSON 불리언. |
Null | JSON null 리터럴. |
JSON 표현을 생성하는 규범에 부합하는 생산자를 만드는 모든 구현자는 자신의 알고리즘이 [[INFRA]] 규격의 JSON 직렬화 규칙과 JSON [[RFC8259]] 규격의 숫자에 대한 정밀도 권고사항에 맞춰져 있는지 확인하는 것이 좋다.
DID 문서의 모든 항목은 루트
JSON 객체에 포함되어야 한다.
항목은 위 목록의 값 표현 규칙에 따라 추가 데이터 하위 구조를 포함할
수 있다. DID 문서를 직렬화할 때,
규범에 부합하는 생산자는
에 설명된 것과 같이 하위
애플리케이션에 application/did+json
의 미디어 유형을
지정해야 한다.
{ "id": "did:example:123456789abcdefghi", "authentication": [{ "id": "did:example:123456789abcdefghi#keys-1", "type": "Ed25519VerificationKey2018", "controller": "did:example:123456789abcdefghi", "publicKeyBase58": "H3C2AVvLMv6gmMNam3uVAjZpfkcJCwDwnZn6z3wXmqPV" }] }
DID 문서와 DID 문서 데이터 구조 JSON 표현은 다음과 같은 소비 규칙에 따라 데이터 모델로 역직렬화되어야 한다:
JSON Representation Type | Data Type |
---|---|
JSON Object | map이며, JSON 객체의 각 멤버는 map에 항목으로 추가된다. 각 항목 키는 JSON 객체 멤버 이름으로 설정된다. 각 항목 값은 이 표에 정의된 JSON 표현 타입에 따라 JSON 객체 멤버 값을 변환하여 설정된다. JSON 객체에서 순서가 지정되지 않으므로, 삽입 순서가 보장되지 않는다. |
JSON 배열이며, 데이터 모델 항목 값이 리스트 또는 미정인 경우에 해당한다. | list이며, JSON 배열의 각 값은 순서에 따라 리스트에 추가된다. 배열 값의 JSON 표현 유형에 따라 변환되며, 이는 본 표에 정의되어 있다. |
데이터 모델 항목 값이 set인 JSON 배열 | JSON 배열의 각 값이 이 표에 정의된 대로 배열 값의 JSON 표현 유형에 따라 변환되어 순서대로 추가되는 set. |
데이터 모델 항목 값이 datetime인 JSON 문자열 | datetime. |
데이터 모델 항목 값 유형이 string 또는 알 수 없는 JSON 문자열 | string. |
소수 또는 분수 성분이 없는 JSON 숫자 | integer. |
소수와 분수 성분이 있는 JSON 숫자 또는 분수 성분 포함 여부에 관계없이 항목 값이 double일 때 | double. |
JSON 불리언 | boolean. |
JSON null 리터럴 | null 값. |
JSON 표현을 생성하는 규범에 부합하는 소비자를 만드는 모든 구현자는 자신의 알고리즘이 [[INFRA]] 규격의 JSON 변환 규칙과 JSON [[RFC8259]] 규격의 숫자에 대한 정밀도 조언에 부합하도록 해야 한다.
미디어 유형 정보를 규범에 부합하는 소비자가 사용할 수 있고
미디어 유형 값이 application/did+json
인 경우, 소비되는
데이터 구조는 DID 문서이며, 루트 요소는 객체의 모든 멤버가
DID 문서의 항목인
JSON 객체여야 한다. 루트 요소가
JSON 객체가 아닌
DID 문서를 소비하는 JSON 표현에 대한
규범에 부합하는 소비자는 오류를 보고해야 한다.
JSON-LD [[JSON-LD11]]는 연결된 데이터를 직렬화하는 데 사용되는 JSON 기반 형식이다. 이 섹션에서는 JSON-LD 표현에 대한 생산 및 소비 규칙을 정의한다.
JSON-LD 표현은 다음과 같은 표현별 항목을 정의한다:
DID 문서, DID 문서 데이터 구조 및 representation-specific entries map은 에 정의된 JSON 표현 생산 규칙에 따라 JSON-LD 표현으로 직렬화되어야 한다.
JSON 표현 생산 규칙을 사용하는 것 외에도, JSON-LD
생산은 표현별
@context
항목을 포함해야 한다.
@context
의 직렬화된 값은
JSON 문자열
https://www.w3.org/ns/did/v1
이거나, 첫 번째 항목이
JSON 문자열
https://www.w3.org/ns/did/v1
이고 후속 항목이 JSON
표현 생산 규칙에 따라 직렬화된
JSON 배열이어야 한다.
{ "@context": "https://www.w3.org/ns/did/v1", ... }
{ "@context": [ "https://www.w3.org/ns/did/v1", "https://did-method-extension.example/v1" ], ... }
JSON-LD 표현을 생성하는 규범에 부합하는 생산자를 만드는 모든 구현자는 자신의 알고리즘이 유효한 JSON-LD [[JSON-LD11]] 문서를 생성하도록 해야 한다. 유효하지 않은 JSON-LD 문서는 JSON-LD 프로세서가 중지되고 오류를 보고하도록 할 것이다.
서로 다른 표현 간의 상호 운용성을 달성하기 위해, 모든 JSON-LD 컨텍스트와 해당 용어는 DID 규격 레지스트리 [[?DID-SPEC-REGISTRIES]]에 등록되어야 한다.
JSON-LD 표현을 생성하는 규범에 부합하는 생산자는
규범에 부합하는 소비자가 알 수 없는 용어를 제거할 것으로
예상되므로 @context
를 통해 정의되지 않은 용어가 포함된
DID 문서를 생성하지 말아야 한다. DID 문서의 JSON-LD
표현을 직렬화할 때, 규범에 부합하는 생산자는
에 설명된 것과 같이 하위
애플리케이션에 application/did+ld+json
의 미디어 유형을
지정해야 한다.
JSON-LD 표현으로 표현된 DID 문서 및 모든 DID 문서 데이터 구조는 에 정의된 JSON 표현 소비 규칙에 따라 데이터 모델로 역직렬화되어야 한다.
JSON-LD 표현을 소비하는 규범에 부합하는 소비자를 만드는 모든 구현자는 자신의 알고리즘이 유효한 JSON-LD [[JSON-LD11]] 문서만 수용하도록 해야 한다. 유효하지 않은 JSON-LD 문서는 JSON-LD 프로세서가 중지되고 오류를 보고하도록 할 것이다.
JSON-LD 표현을 처리하는 규범에 부합하는 소비자는
@context
를 통해 정의되지 않은 DID 문서의 모든
용어를 삭제해야 한다.
이 섹션에서는 DID 해석과 DID URL 역참조의 입력과 출력을 정의한다. 이들의 정확한 구현은 이 규격의 범위를 벗어나지만, 구현자를 위한 몇 가지 고려사항은 [[?DID-RESOLUTION]]에서 논의된다.
규범을 준수하는 모든 DID 변환기는 최소한 하나의 DID 메소드에 대한 DID 해석 기능을 구현해야 하며, 최소한 하나의 규범을 준수하는 표현으로 DID 문서를 반환할 수 있어야 한다.
DID 해석 기능은 에 설명된 대로 적용 가능한 DID 메소드의 "읽기" 연산을 사용하여 DID를 DID 문서로 해석한다. 이 프로세스가 어떻게 수행되는지에 대한 자세한 내용은 이 규격의 범위를 벗어나지만, 규범을 준수하는 모든 DID 변환기는 다음과 같은 추상적 형태를 가진 아래의 함수를 구현한다:
resolve(did, resolutionOptions) → « didResolutionMetadata, didDocument, didDocumentMetadata » resolveRepresentation(did, resolutionOptions) → « didResolutionMetadata, didDocumentStream, didDocumentMetadata »
resolve
함수는 추상적 형태(a
map)로 DID 문서를 반환한다.
resolveRepresentation
함수는 해당 표현으로 포맷된
DID 문서의 바이트 스트림을 반환한다.
다이어그램의 상단 중간 부분에는 점선으로 된 회색 윤곽선이 있는 사각형이 포함되어 있으며, 그 안에는 파란색 윤곽선이 있는 두 개의 사각형이 위아래로 배치되어 있다. 위쪽의 더 큰 사각형에는 파란색으로 "Core Properties"라는 레이블이 붙어 있으며, 다음과 같은 INFRA 표기법을 포함하고 있다:
«[ "id" → "example:123", "verificationMethod" → « «[ "id": "did:example:123#keys-1", "controller": "did:example:123", "type": "Ed25519VerificationKey2018", "publicKeyBase58": "H3C2AVvLMv6gmMNam3uVA" ]» », "authentication" → « "did:example:123#keys-1" » ]»
하단의 작은 사각형에는 파란색으로 "Core Representation-specific Entries (JSON-LD)"라는 레이블이 붙어 있으며, 다음과 같은 모노스페이스 INFRA 표기법을 포함하고 있다:
«[ "@context" → "https://www.w3.org/ns/did/v1" ]»
회색 윤곽선 사각형에서 다이어그램 하단에 나란히 정렬된 세 개의 검은색 윤곽선 사각형으로 세 쌍의 화살표가 뻗어 있다. 각 화살표 쌍은 회색 윤곽선 사각형에서 각각의 검은색 윤곽선 사각형으로 "produce"라는 레이블이 붙은 파란색 화살표 하나와 반대 방향으로 "consume"이라는 레이블이 붙은 빨간색 화살표 하나로 구성됩니다. 첫 번째 검은색 윤곽선 사각형에는 "application/did+ld+json"이라는 레이블이 붙어 있으며, 다음과 같은 JSON-LD 데이터를 포함하고 있다:
{ "@context": ["https://www.w3.org/ns/did/v1"], "id": "did:example:123", "verificationMethod": [{ "id": "did:example:123#keys-1", "controller": "did:example:123", "type": "Ed25519VerificationKey2018", "publicKeyBase58": "H3C2AVvLMv6gmMNam3uVA" }], "authentication": [ "did:example:123#keys-1" ] }
두 번째 사각형에는 "application/did+json"이라는 레이블이 붙어 있으며, 다음과 같은 JSON 데이터를 포함하고 있다:
{ "id": "did:example:123", "verificationMethod": [{ "id": "did:example:123#keys-1", "controller": "did:example:123", "type": "Ed25519VerificationKey2018", "publicKeyBase58": "H3C2AVvLMv6gmMNam3uVA" }], "authentication": [ "did:example:123#keys-1" ] }
세 번째 사각형에는 "application/did+cbor"라는 레이블이 붙어 있으며, 16진수 데이터를 포함하고 있다.
다이어그램 왼쪽 중간에는 검은색 윤곽선과 연한 회색 배경의 상자가 있다. 이 상자에는 "VERIFIABLE DATA REGISTRY"라는 레이블이 붙어 있으며, 노드와 호로 구성된 그래프를 나타내는 기호를 포함하고 있다. 이 상자에서 "resolve()"이라는 레이블이 붙은 화살표 하나가 위쪽으로 뻗어 회색 윤곽선 사각형이 있는 다이어그램 상단을 가리킵니다. "resolveRepresentation()"이라는 레이블이 붙은 또 다른 화살표는 아래쪽으로 뻗어 세 개의 검은색 윤곽선 사각형이 있는 다이어그램 하단을 가리킵니다.
resolve
와 resolveRepresentation
함수의 입력
변수는 다음과 같다:
이 함수들은 각각 여러 값을 반환하며, 이러한 값들이 함께 반환되는
방식에는 제한이 없다. resolve
의 반환 값은
didResolutionMetadata, didDocument,
didDocumentMetadata이다. resolveRepresentation
의
반환 값은 didResolutionMetadata, didDocumentStream,
didDocumentMetadata이다. 이 값들은 아래에 설명되어 있다:
resolve
와 resolveRepresentation
함수를
호출할 때마다 변경되며, 해석 프로세스 자체에 대한 데이터를 나타낸다.
이 구조는 필수이며, 해석 프로세스에서 오류가 발생한 경우 이 구조는
비어 있어서는 안 된다. 이 메타데이터는
에 의해 정의된다.
resolveRepresentation
이 호출된 경우, 이 구조는
didDocumentStream
에서 발견된 표현의 미디어 유형을
포함하는 contentType
속성을 포함해야 한다. 해석이
성공하지 않은 경우, 이 구조는 오류를 설명하는
error
속성을 포함해야 한다.
resolve
함수가 호출된 경우, 이는
에 설명된 DID 문서 추상 데이터
모델(map)이어야 하며, 표현에 의해
지정된 생산 규칙을 사용하여 규범에 부합하는 DID 문서 (표현)로
변환될 수 있어야 한다. 해석된 DID 문서에서
id
의 값은 해석된 DID와 일치해야 한다. 해석이 성공하지 않은
경우, 이 값은 비어 있어야 한다.
resolveRepresentation
함수가 호출된
경우, 이는 규격을 준수하는 표현 중
하나로 해석된 DID 문서의 바이트 스트림이어야 한다. 그런 다음
resolveRepresentation
함수의 호출자가 바이트 스트림을
데이터 모델로 파싱하여 유효성을 검사하고
처리할 수 있다. 해석이 성공하지 않은 경우, 이 값은 빈 스트림이어야
한다.
didDocument
속성에 포함된 DID 문서에 대한
메타데이터를 포함한다. 이 메타데이터는 일반적으로 DID 문서가
변경되지 않는 한 resolve
와
resolveRepresentation
함수를 호출할 때마다 변경되지
않으며, DID 문서에 대한 메타데이터를 나타낸다. 해석이
성공하지 않은 경우, 이 출력은 빈
메타데이터 구조여야 한다. 이
규격에 의해 정의된 속성은 에
있다.
규격을 준수하는 DID 변환기 구현은 이러한 함수의 시그니처를 어떤
식으로든 변경하지 않는다. DID 변환기 구현은 실제
DID 해석 프로세스를 수행하기 위해 resolve
와
resolveRepresentation
함수를 메소드별 내부 함수에 매핑할
수 있다. DID 변환기 구현은 여기에 지정된 resolve
와
resolveRepresentation
함수 외에 다른 시그니처를 가진 추가
함수를 구현하고 노출할 수 있다.
이 구조 내의 가능한 속성과 그 가능한 값은 DID 규격 레지스트리 [[?DID-SPEC-REGISTRIES]]에 등록되어 있다. 이 규격은 다음과 같은 공통 속성을 정의한다.
didDocumentStream
에 포함된 표현을 결정해야
한다. 이 속성은 resolveRepresentation
함수에 대해서는
선택 사항이며 resolve
함수와 함께 사용해서는 안 된다.
이 구조 내의 가능한 속성과 그 가능한 값은 DID 규격 레지스트리 [[?DID-SPEC-REGISTRIES]]에 등록되어 있다. 이 규격은 다음과 같은 DID 해석 메타데이터 속성을 정의한다:
didDocumentStream
의 미디어 유형. 이 속성은
해석이 성공하고 resolveRepresentation
함수가 호출된
경우 필수이다. 이 속성은 resolve
함수가 호출된 경우
존재해서는 안 된다. 이 속성의 값은 규격을 준수하는 표현의
미디어 유형인 ASCII 문자열이어야
한다. resolveRepresentation
함수의 호출자는 이 값을
사용하여 이 함수에 의해 반환된 didDocumentStream
을
데이터 모델로 파싱하고 처리하는 방법을
결정해야 한다.
accept
입력 메타데이터 속성을 통해 요청된
표현이 DID 메소드 및/또는
DID 변환기 구현에서 지원되지 않는 경우 이 오류 코드가
반환된다.
이 구조 내의 가능한 속성과 그 가능한 값은 DID 규격 레지스트리 [[?DID-SPEC-REGISTRIES]]에 등록되어야 한다. 이 규격은 다음과 같은 공통 속성을 정의한다.
created
속성이 포함되어야 한다. 속성 값은 UTC
00:00:00으로 정규화되고 초 미만의 소수 정밀도 없이
XML Datetime으로 포맷된
문자열이어야 한다. 예:
2020-12-20T19:17:47Z
.
updated
속성이 포함되어야 한다. 속성
값은 created
속성과 동일한 포맷 규칙을 따라야 한다.
DID 문서에 대해 업데이트 작업이 수행된 적이 없는 경우
updated
속성은 생략된다. updated
속성이
존재하는 경우, 두 타임스탬프 간의 차이가 1초 미만일 때
created
속성과 동일한 값일 수 있다.
true
를 가져야 한다. DID가 비활성화되지 않은 경우, 이
속성은 선택 사항이지만 포함된 경우 불리언 값 false
를
가져야 한다.
nextUpdate
속성이
포함될 수 있다. 이는 다음
업데이트 작업의 타임스탬프를
나타낸다. 속성 값은 created
속성과 동일한 포맷 규칙을
따라야 한다.
versionId
속성이 포함되어야 한다. 속성 값은
ASCII 문자열이어야 한다.
nextVersionId
속성이
포함될 수 있다. 이는 다음
업데이트 작업의 버전을 나타낸다.
속성 값은 ASCII 문자열이어야 한다.
DID 메소드는 논리적으로 동등한 DID의 다양한 형식을
정의할 수 있다. 예를 들어, DID가
검증 가능한 데이터 레지스트리에 등록되기 전에 한 가지
형식을 취하고 등록 후에 다른 형식을 취하는 경우가 있다. 이 경우,
DID 메소드 규격은 해석된 DID와 논리적으로 동등한
하나 이상의 DID를 DID 문서의 속성으로 표현해야 할
수 있다. 이것이 equivalentId
속성의
목적이다.
DID 문서 메타데이터에는 equivalentId
속성이
포함될 수 있다. 존재하는 경우, 값은 각 항목이
의 규칙을 준수하는
문자열인
set이어야 한다. 이 관계는
각 equivalentId
값이 id
속성
값과 논리적으로 동등하며 따라서 동일한 DID 주체를
참조한다는 진술이다. 각 equivalentId
DID
값은 id
속성 값과 동일한 DID 메소드에 의해
생성되고 해당 메소드의 한 형식이어야 한다. (예:
did:example:abc
== did:example:ABC
)
규격을 준수하는 DID 메소드 규격은 각
equivalentId
값이 id
속성 값과
논리적으로 동등함을 보장해야 한다.
요청 당사자는 id
및
equivalentId
속성의 값을 유지하여 이들이
포함하는 값 중 하나와의 후속 상호 작용이 논리적으로 동등한
것으로 올바르게 처리되도록 해야 한다(예: 데이터베이스에 모든
변형을 유지하여 하나와의 모든 상호 작용이 동일한 기본 계정에
매핑되도록 함).
동등성은 관리 중인 DID 메소드에 의해 보장되어야 하므로
equivalentId
는 alsoKnownAs
보다 훨씬 더 강력한 형태의 동등성이다.
equivalentId
는 동일한 DID 문서가 equivalentId
DID와 id
속성 DID를 모두 설명하기
때문에 완전한 그래프 병합을 나타낸다.
요청 당사자가 id
및
equivalentId
속성의 값을 유지하고 포함된 값
중 하나와의 후속 상호 작용이 논리적으로 동등하게 올바르게
처리되도록 하지 않으면 부정적이거나 예기치 않은 문제가 발생할 수
있다. 구현자는 이 메타데이터 속성과 관련된 지침을 준수하는 것이
좋다.
canonicalId
속성은
equivalentId
속성과 동일하지만 다음 두 가지
측면에서 다르다: a) set이 아닌 단일 값과 연관되며, b)
DID는 포함하는 DID 문서의 범위 내에서
DID 주체에 대한 표준 ID로 정의된다.
DID 문서 메타데이터에는 canonicalId
속성이
포함될 수 있다. 존재하는 경우, 값은 의
규칙을 준수하는 문자열이어야
한다. 이 관계는 canonicalId
값이
id
속성 값과 논리적으로 동등하며
canonicalId
값이 포함하는 DID 문서의
범위 내에서 DID 주체에 대한 표준 ID로 DID 메소드에
의해 정의된다는 진술이다. canonicalId
값은
id
속성 값과 동일한 DID 메소드에 의해
생성되고 해당 메소드의 한 형식이어야 한다. (예:
did:example:abc
== did:example:ABC
).
규격을 준수하는 DID 메소드 규격은
canonicalId
값이 id
속성 값과
논리적으로 동등함을 보장해야 한다.
요청 당사자는 canonicalId
값을
DID 주체에 대한 기본 ID 값으로 사용하고 다른 모든 동등한
값을 보조 별칭으로 처리해야 한다(예: 새로운 표준 ID 지시를
반영하기 위해 시스템에서 해당 기본 참조를 업데이트).
canonicalId
는 equivalentId
와 동일한 동등성 진술이지만, DID 문서의 범위 내에서
DID 주체에 대해 표준으로 정의된 단일 값으로 제한된다.
equivalentId
와 마찬가지로 canonicalId
는 동일한 DID 문서가
canonicalId
DID와 id
속성
DID를 모두 설명하기 때문에 완전한 그래프 병합을 나타낸다.
해석 당사자가 canonicalId
값을 DID 주체에
대한 기본 ID 값으로 사용하지 않고 다른 모든 동등한 값을 보조
별칭으로 처리하지 않으면 사용자 경험과 관련하여 부정적이거나
예기치 않은 문제가 발생할 수 있다. 구현자는 이 메타데이터 속성과
관련된 지시 사항을 준수하는 것이 좋다.
DID URL 역참조 함수는 DID URL을 DID 메소드, 메소드별 식별자, 경로, 쿼리 및 프래그먼트를 포함한 DID URL의 구성 요소에 따라 내용이 달라지는 리소스로 역참조한다. 이 프로세스는 DID URL에 포함된 DID의 DID 해석에 의존한다. DID URL 역참조는 여러 단계를 포함할 수 있으며(예: 역참조되는 DID URL에 프래그먼트가 포함된 경우), 이 함수는 모든 단계가 완료된 후 최종 리소스를 반환하도록 정의된다. 이 프로세스가 수행되는 방식에 대한 세부 사항은 이 규격의 범위를 벗어난다. 다음 그림은 위에서 설명한 관계를 나타낸다.
다이어그램의 왼쪽 상단에는 "DID"라는 레이블이 붙은 검은색 윤곽선의 사각형이 포함되어 있다.
다이어그램의 왼쪽 하단에는 "DID URL"이라는 레이블이 붙은 검은색 윤곽선의 사각형이 포함되어 있다. 이 사각형에는 서로 인접한 수평 행으로 정렬된 4개의 더 작은 검은색 윤곽선 사각형이 포함되어 있다. 이 더 작은 사각형은 순서대로 "DID", "path", "query", "fragment"로 레이블이 붙어 있다.
다이어그램의 오른쪽 상단에는 "DID document"라는 레이블이 붙은 검은색 윤곽선의 사각형이 포함되어 있다. 이 사각형에는 세 개의 더 작은 검은색 윤곽선 사각형이 포함되어 있다. 이 더 작은 사각형은 "id", "(property X)", "(property Y)"로 레이블이 붙어 있고 여러 줄의 점 세 개(줄임표)로 둘러싸여 있다. "DID document - relative fragment dereference"라는 레이블이 붙은 검은색 곡선 화살표가 "(property X)"라는 레이블이 붙은 사각형에서 "(property Y)"라는 레이블이 붙은 사각형을 가리킨다.
다이어그램의 오른쪽 하단에는 "Resource"라는 레이블이 붙은 검은색 윤곽선의 타원형이 포함되어 있다.
"resolves to a DID document"라는 레이블이 붙은 검은색 화살표가 다이어그램의 왼쪽 상단에 있는 "DID"라는 레이블이 붙은 사각형에서 다이어그램의 오른쪽 상단에 있는 "DID document"라는 레이블이 붙은 사각형을 가리킨다.
"refers to"라는 레이블이 붙은 검은색 화살표가 다이어그램의 오른쪽 상단에 있는 "DID document"라는 레이블이 붙은 사각형에서 다이어그램의 오른쪽 하단에 있는 "Resource"라는 레이블이 붙은 타원형을 가리킨다.
"contains"라는 레이블이 붙은 검은색 화살표가 다이어그램의 왼쪽 하단에 있는 "DID URL"이라는 레이블이 붙은 사각형 내부의 "DID"라는 레이블이 붙은 작은 사각형에서 다이어그램의 왼쪽 상단에 있는 "DID"라는 레이블이 붙은 사각형을 가리킨다.
"dereferences to a DID document"라는 레이블이 붙은 검은색 화살표가 다이어그램의 왼쪽 하단에 있는 "DID URL"이라는 레이블이 붙은 사각형에서 다이어그램의 오른쪽 상단에 있는 "DID document"라는 레이블이 붙은 사각형을 가리킨다.
"dereferences to a resource"라는 레이블이 붙은 검은색 화살표가 다이어그램의 왼쪽 하단에 있는 "DID URL"이라는 레이블이 붙은 사각형에서 다이어그램의 오른쪽 하단에 있는 "Resource"라는 레이블이 붙은 타원형을 가리킨다.
All conforming DID resolvers implement the following function which has the following abstract form:
dereference(didUrl, dereferenceOptions) → « dereferencingMetadata, contentStream, contentMetadata »
dereference
함수의 입력 변수는 다음과 같다:
모든 didUrl
을 DID URL 역참조자에 전달하는 것이
유효하지만, 구현자는 DID URL이 어떻게 역참조될 것으로
예상되는지에 대한 일반적인 패턴을 더 잘 이해하기 위해
[[?DID-RESOLUTION]]을 참조할 것으로 예상된다.
didUrl
자체 외에 dereference
함수에 대한
입력 옵션으로 구성된
메타데이터 구조이다. 이 규격에서
정의한 속성은 에 있다.
이 입력은 필수이지만 구조는 비어 있을 수 있다.
이 함수는 여러 값을 반환하며, 이러한 값들이 함께 반환되는 방식에는
제한이 없다. dereference
의 반환 값에는
dereferencingMetadata
, contentStream
,
contentMetadata
가 포함된다:
error
속성을
포함해야 한다.
dereferencing
함수가 호출되어 성공한 경우, 이는
DID URL에 해당하는 리소스를 포함해야 한다.
contentStream
은 규격을 준수하는 표현 중 하나로
직렬화 가능한 DID 문서,
검증 방법,
서비스 또는 미디어 유형을 통해 식별되고 해석
프로세스를 통해 얻을 수 있는 기타 리소스 형식과 같은 리소스일
수 있다. 역참조가 성공하지 않으면 이 값은 비어 있어야 한다.
contentStream
에 대한
메타데이터를 포함한다. contentStream
이
DID 문서인 경우, 이는 DID 해석에 설명된 대로
didDocumentMetadata 구조여야 한다. 역참조가 성공하지 않으면
이 출력은 빈 메타데이터 구조여야
한다.
규격을 준수하는 DID URL 역참조 구현은 이러한 함수의 시그니처를
어떤 식으로든 변경하지 않는다. DID URL 역참조 구현은 실제
DID URL 역참조 프로세스를 수행하기 위해
dereference
함수를 메소드별 내부 함수에 매핑할 수 있다.
DID URL 역참조 구현은 여기에 지정된
dereference
함수 외에 다른 시그니처를 가진 추가 함수를
구현하고 노출할 수 있다.
이 구조 내의 가능한 속성과 그 가능한 값은 DID 규격 레지스트리 [[?DID-SPEC-REGISTRIES]]에 등록되어야 한다. 이 규격은 역참조 옵션에 대해 다음과 같은 공통 속성을 정의한다:
contentStream
에 대해 선호하는 미디어
유형이다. 미디어 유형은
ASCII 문자열로 표현되어야 한다. 해당
표현이 지원되고 사용 가능한 경우
DID URL 역참조 구현은 이 값을 사용하여 반환된 값에 포함된
표현의 contentType
을 결정해야 한다.
이 구조 내의 가능한 속성과 그 가능한 값은 DID 규격 레지스트리 [[?DID-SPEC-REGISTRIES]]에 등록되어 있다. 이 규격은 다음과 같은 공통 속성을 정의한다.
contentStream
의 미디어
유형은 이 속성을 사용하여 표현되어야 한다. 미디어 유형 값은
ASCII 문자열로 표현되어야 한다.
contentStream
을 찾을 수 없다.
입력 및 출력 메타데이터는 종종 DID 해석, DID URL 역참조 및 기타 DID 관련 프로세스 중에 관련된다. 이 메타데이터를 전달하는 데 사용되는 구조는 속성의 map이어야 한다. 각 속성 이름은 문자열이어야 한다. 각 속성 값은 문자열, map, 목록, set, 불리언 또는 널이어야 한다. map과 목록과 같은 복잡한 데이터 구조 내의 값도 이러한 데이터 유형 중 하나여야 한다. DID 규격 레지스트리 [[?DID-SPEC-REGISTRIES]]에 등록된 모든 메타데이터 속성 정의는 해당 값에 대한 추가 형식이나 제한을 포함하여 값 유형을 정의해야 한다(예: 날짜 또는 10진 정수로 포맷된 문자열). 속성 정의에서 값에 문자열을 사용하는 것이 권장된다. 전체 메타데이터 구조는 [[INFRA]] 규격의 JSON 직렬화 규칙에 따라 직렬화할 수 있어야 한다. 구현은 메타데이터 구조를 다른 데이터 형식으로 직렬화할 수 있다.
메타데이터 구조를 입력이나 출력으로 사용하는 함수의 모든 구현은 여기에 설명된 모든 데이터 유형을 결정적인 방식으로 완전히 표현할 수 있다. 메타데이터 구조를 사용하는 입력과 출력은 직렬화가 아닌 데이터 유형의 관점에서 정의되므로, 표현을 위한 방법은 함수의 구현 내부에 있으며 이 규격의 범위를 벗어난다.
다음 예제는 DID 해석 입력 메타데이터로 사용될 수 있는 JSON 인코딩된 메타데이터 구조를 보여준다.
{ "accept": "application/did+ld+json" }
이 예제는 다음 형식의 메타데이터 구조에 해당한다:
«[ "accept" → "application/did+ld+json" ]»
다음 예제는 DID를 찾을 수 없는 경우 DID 해석 메타데이터로 사용될 수 있는 JSON 인코딩된 메타데이터 구조를 보여준다.
{ "error": "notFound" }
이 예제는 다음 형식의 메타데이터 구조에 해당한다:
«[ "error" → "notFound" ]»
다음 예제는 DID 문서와 관련된 타임스탬프를 설명하기 위해 DID 문서 메타데이터로 사용될 수 있는 JSON 인코딩된 메타데이터 구조를 보여준다.
{ "created": "2019-03-23T06:35:22Z", "updated": "2023-08-10T13:40:06Z" }
이 예제는 다음 형식의 메타데이터 구조에 해당한다:
«[ "created" → "2019-03-23T06:35:22Z", "updated" → "2023-08-10T13:40:06Z" ]»
DID 메소드는 구현자가 이 규격에서 설명하는 기능을 어떻게 구현할 수 있는지 정의한다. DID 메소드는 종종 특정 검증 가능한 데이터 레지스트리와 연관된다. 새로운 DID 메소드는 동일한 DID 메소드의 서로 다른 구현 간의 상호 운용성을 가능하게 하기 위해 자체 규격에 정의된다.
개념적으로, 이 규격과 DID 메소드 규격 간의 관계는 IETF 일반
URI 규격 [[?RFC3986]]과 http
체계 [[?RFC7230]]와
같은 특정 URI 체계 [[?IANA-URI-SCHEMES]] 간의 관계와 유사하다.
DID 메소드 규격은 특정 DID 체계를 정의하는 것 외에도 특정
유형의 검증 가능한 데이터 레지스트리를 사용하여 DID와
DID 문서를 생성, 해석, 갱신 및 비활성화하는 메커니즘을 정의한다.
또한 DID와 관련된 모든 구현 고려사항과 보안 및 개인정보 보호
고려사항을 문서화한다.
이 섹션에서는 DID 메소드 규격 작성을 위한 요구사항을 명시한다.
메소드별 DID 구문을 정의할 때 모든 DID 메소드 규격에 대한 요구사항은 다음과 같다:
method-name
규칙에 명시된 대로 정확히 하나의 메소드
이름으로 식별되는 정확히 하나의 메소드별 DID 체계를 정의해야
한다.
method-specific-id
구성 요소를 생성하는 방법을 명시해야
한다.
method-specific-id
값의
민감도와 정규화를 정의해야 한다.
method-specific-id
값은 DID 메소드 내에서
고유해야 한다. method-specific-id
값 자체는 전
세계적으로 고유할 수 있다.
method-name
충돌 가능성을 줄이기 위해
DID 메소드 규격은 DID 규격 레지스트리
[[?DID-SPEC-REGISTRIES]]에 등록되어야 한다.
method-specific-id
형식을
정의할 수 있다.
method-specific-id
형식은 콜론을 포함할 수 있다. 콜론의
사용은 method-specific-id
ABNF 규칙과 구문적으로
일치해야 한다.
method-specific-id
의 콜론의 의미는 전적으로 메소드별로
다르다. 콜론은 DID 메소드에서 계층적으로 분할된 네임스페이스를
설정하거나, 검증 가능한 데이터 레지스트리의 특정 인스턴스 또는
부분을 식별하거나, 기타 목적으로 사용될 수 있다. 구현자는 모든
DID 메소드에 일반적으로 적용되는 콜론과 관련된 의미나 동작을
가정하지 않는 것이 좋다.
메소드 작업을 정의할 때 모든 DID 메소드 규격에 대한 요구사항은 다음과 같다:
작업 수행을 위한 인증을 수행하는 당사자의 권한은 DID 메소드에 따라 다릅니다. 예를 들어, DID 메소드는 —
controller
속성을 사용할 수 있다.
authentication
아래에 나열된 검증 방법를
사용할 수 있다.
capabilityInvocation
검증 관계를 통해
지정된 검증 방법와 같은 DID 문서의 다른 구성을 사용할
수 있다.
보안 고려사항 섹션을 작성할 때 모든 DID 메소드 규격에 대한 요구사항은 다음과 같다:
개인정보 보호 고려사항 섹션을 작성할 때 모든 DID 메소드 규격에 대한 요구사항은 다음과 같다:
이 섹션에는 탈중앙 식별자를 사용하는 사람들이 이 기술을 프로덕션 환경에 배포하기 전에 고려할 것을 권장하는 다양한 보안 고려사항이 포함되어 있다. DID는 많은 IETF 표준에서 사용되고 [[?RFC3552]]에 문서화된 위협 모델에서 작동하도록 설계되었다. 이 섹션에서는 [[?RFC3552]]의 여러 고려사항과 DID 아키텍처에 고유한 기타 고려사항에 대해 자세히 설명한다.
DID 규격 레지스트리 [[?DID-SPEC-REGISTRIES]]에는 DID 메소드 이름과 해당 DID 메소드 규격의 정보 목록이 포함되어 있다. 구현자는 어떤 특정한 DID 메소드 이름과 사용해야 할 DID 메소드 규격을 지시할 중앙 권한이 없다는 점을 염두에 두어야 한다. 특정 DID 변환기가 DID 메소드를 올바르게 구현하는지 여부에 의심이 있는 경우, DID 규격 레지스트리를 사용하여 등록된 규격을 조회하고 사용할 DID 변환기 구현에 대한 정보에 입각한 결정을 내릴 수 있다.
디지털 세계 또는 물리적 세계의 엔티티를 DID, DID 문서 또는 암호화 자료에 바인딩하려면 이 규격에서 고려하는 보안 프로토콜을 사용해야 한다. 다음 섹션에서는 몇 가지 가능한 시나리오와 인증 또는 권한 부여를 목적으로 엔티티가 DID 또는 DID 문서에 대한 제어를 증명할 수 있는 방법을 설명한다.
DID 및/또는 DID 문서에 대한 제어를 증명하는 것은 검증 가능한 데이터 레지스트리에서 업데이트하거나 원격 시스템에서 인증할 때 유용하다. 암호화된 디지털 서명과 검증 가능한 타임스탬프를 통해 DID 문서와 관련된 특정 보안 프로토콜을 암호학적으로 검증할 수 있다. 이를 위해 이 규격은 과 에서 유용한 검증 관계를 정의한다. 검증 방법와 연결된 비밀 암호화 자료는 인증 또는 권한 부여 보안 프로토콜의 일부로 암호화된 디지털 서명을 생성하는 데 사용할 수 있다.
일부 DID 메소드는 디지털 서명과 기타 증명을 DID 문서 또는 에 포함시킬 수 있다. 그러나 그러한 증명 자체만으로는 반드시 DID에 대한 제어를 증명하거나 DID 문서가 DID에 대해 올바른 것임을 보장하지는 않는다. 올바른 DID 문서를 얻고 DID에 대한 제어를 검증하려면 DID 메소드에서 정의한 대로 DID 해석 프로세스를 수행해야 한다.
DID와 DID 문서는 본질적으로 개인 데이터를 포함하지 않으며, 비공개 엔티티가 DID 문서에 개인 데이터를 게시하지 않는 것이 강력히 권고된다.
DID를 정부와 같은 신뢰할 수 있는 기관에 의해 증명될 수 있는 방식으로 개인 또는 조직의 물리적 신원에 바인딩하는 것이 유용할 수 있다. 이 규격은 이러한 목적으로 검증 관계를 제공한다. 이 기능은 사적이며 하나 이상의 관할 구역에서 법적 강제력이 있는 것으로 간주될 수 있는 상호 작용을 가능하게 할 수 있다. 그러한 바인딩을 설정하는 것은 개인 정보 보호 고려사항과 신중하게 균형을 이루어야 한다( 참조).
DID를 사람이나 조직과 같은 물리적 세계의 무언가에 바인딩하는 프로세스(예: 해당 DID와 동일한 주체를 가진 검증 가능한 크리덴셜 사용)는 이 규격에서 고려되며 검증 가능한 크리덴셜 데이터 모델 [[VC-DATA-MODEL]]에서 추가로 정의된다.
DID 문서가 DID 주체의 인증 또는 권한 부여를 위한 서비스를 게시하는 경우( 참조), 서비스 엔드포인트 제공자, 주체 또는 요청 당사자는 해당 서비스 엔드포인트에서 지원되는 인증 프로토콜의 요구사항을 준수할 책임이 있다.
DID 및 DID 문서 업데이트의 부인 방지는 다음과 같은 경우 지원된다:
DID 문서에 대한 무단 변경을 완화하는 한 가지 방법은 변경 사항이 있을 때 DID 주체를 모니터링하고 적극적으로 알리는 것이다. 이는 기존의 사용자 이름/암호 계정에서 파일의 이메일 주소로 암호 재설정 알림을 보내 계정 탈취를 방지하는 데 도움이 되는 것과 유사하다.
DID의 경우, 그러한 알림을 생성할 중개 등록 기관이나 계정 제공자가 없다. 그러나 DID가 등록된 검증 가능한 데이터 레지스트리가 변경 알림을 직접 지원하는 경우, DID 컨트롤러에게 구독 서비스를 제공할 수 있다. 알림은 기존 DID에 나열된 관련 서비스 엔드포인트로 직접 전송될 수 있다.
DID 컨트롤러가 (검증 가능한 데이터 레지스트리 자체 이외의) 제3자 모니터링 서비스에 의존하기로 선택하면 다른 공격 벡터가 도입된다.
탈중앙 식별자 아키텍처에서는 암호화 자료나 암호화된 디지털 서명 만료 정책을 시행할 중앙 집중식 기관이 없을 수 있다. 따라서 요청 당사자는 DID 변환기 및 검증 라이브러리와 같은 지원 소프트웨어를 사용하여 암호화 자료가 사용될 당시에 만료되지 않았는지 검증한다. 요청 당사자는 검증 프로세스에 대한 입력 외에도 자체 만료 정책을 사용할 수 있다. 예를 들어, 일부 요청 당사자는 5분 전의 인증을 수락할 수 있는 반면, 고정밀 시간 소스에 액세스할 수 있는 다른 요청 당사자는 인증에 지난 500밀리초 이내의 타임스탬프가 찍혀야 할 수 있다.
레거시 암호화된 디지털 서명을 검증하는 것과 같이 이미 만료된 암호화 자료의 사용을 확장해야 하는 정당한 필요성이 있는 요청 당사자도 있다. 이러한 시나리오에서 요청 당사자는 검증 소프트웨어에 암호화 키 자료 만료를 무시하도록 지시하거나 암호화 키 자료가 사용될 당시에 만료되었는지 확인할 수 있다.
교체는 새로운 검증 방법가 DID 문서에 추가되면 기존 검증 방법와 연결된 비밀 암호화 자료를 비활성화하거나 파기할 수 있게 해주는 관리 프로세스이다. 앞으로 컨트롤러가 이전 비밀 암호화 자료를 사용하여 생성했을 새로운 증명은 이제 새로운 암호화 자료를 사용하여 생성될 수 있으며 새로운 검증 방법를 사용하여 검증될 수 있다.
교체는 컨트롤러에 의한 검증 방법의 빈번한 교체가 공격자에게 단일 손상된 검증 방법의 가치를 줄이기 때문에 검증 방법 손상으로부터 보호하는 데 유용한 메커니즘이다. 교체 직후 즉시 폐기하는 것은 메시지 암호화 및 인증과 관련된 것과 같이 컨트롤러가 단기 검증을 위해 지정한 검증 방법에 유용하다.
검증 방법 교체 사용을 고려할 때 다음 사항이 유용할 수 있다:
폐기는 기존 검증 방법와 연결된 비밀 암호화 자료를 비활성화하여 새로운 디지털 서명 증명을 생성하는 유효한 형식이 되지 않도록 하는 관리 프로세스이다.
폐기는 검증 방법 손상에 대응하는 유용한 메커니즘이다. 교체 직후 즉시 폐기하는 것은 메시지 암호화 및 인증과 관련된 것과 같이 컨트롤러가 단기 검증을 위해 지정한 검증 방법에 유용하다.
검증 방법와 연결된 비밀의 손상은 공격자가 DID 문서에서 컨트롤러에 의해 표현된 검증 관계에 따라 예를 들어 인증을 위해 이를 사용할 수 있게 한다. 공격자의 비밀 사용은 검증 방법가 등록된 시점부터 폐기된 시점까지 합법적인 컨트롤러의 사용과 구별할 수 없을 수 있다.
검증 방법 폐기 사용을 고려할 때 다음 사항이 유용할 수 있다:
검증자가 폐기된 검증 방법의 증명이나 서명을 수락하지 않기로 선택할 수 있지만, 검증이 폐기된 검증 방법로 이루어졌는지 아는 것은 보이는 것보다 까다롭다. 일부 DID 메소드는 특정 시점 또는 DID 문서의 특정 버전에서 DID의 상태를 되돌아볼 수 있는 기능을 제공한다. 이러한 기능이 암호화로 검증 가능한 명세가 만들어진 시점 또는 DID 버전을 신뢰할 수 있는 방식으로 결정하는 기능과 결합되면 폐기가 해당 명세를 취소하지 않는다. 이는 DID를 사용하여 예를 들어 담보 대출에 서명하는 것과 같은 구속력 있는 약정을 하기 위한 기반이 될 수 있다.
이러한 조건이 충족되면 폐기는 소급 적용되지 않으며 향후 메소드 사용만 무효화한다.
그러나 이러한 의미론이 안전하려면 두 번째 조건인 주장이 이루어진 시점에 DID 문서의 상태가 어떠했는지 알 수 있는 능력이 적용되어야 한다. 그 보장 없이는 누군가가 폐기된 키를 발견하고 과거의 모의 날짜로 암호화로 검증 가능한 명세를 만드는 데 사용할 수 있다.
일부 DID 메소드는 DID의 현재 상태만 검색할 수 있다. 이것이 사실이거나 암호화로 검증 가능한 명세가 이루어진 시점의 DID 상태를 신뢰할 수 있게 결정할 수 없는 경우, 현재 순간을 제외하고 시간과 관련하여 DID 상태를 고려하는 것을 허용하지 않는 것이 유일한 안전한 방법이다. 이 접근 방식을 취하는 DID 생태계는 본질적으로 DID 컨트롤러에 의해 언제든지 무효화될 수 있는 일시적인 토큰으로 암호화로 검증 가능한 명세를 제공한다.
신뢰할 수 없는 시스템은 모든 신뢰가 암호학적으로 증명 가능한 주장에서 파생되고, 더 구체적으로는 암호화 시스템 외부의 메타데이터가 시스템에 대한 신뢰 결정에 고려되지 않는 시스템이다. 신뢰할 수 없는 시스템에서 폐기된 검증 방법에 대한 서명 또는 증명을 검증하려면 DID 메소드가 `versionId` 또는 `versionTime` 중 하나 또는 둘 다와 `updated` 및 `nextUpdate`라는 DID 문서 메타데이터 속성 모두를 지원해야 한다. 검증자는 다음이 모두 사실인 경우에만 폐기된 키의 서명 또는 증명을 검증할 수 있다:
암호화 입력을 구성하는 메타데이터 이외의 메타데이터를 인정하려는 시스템에서는 유사한 신뢰를 달성할 수 있지만, 항상 서명 이벤트 시점의 DID 문서 내용이 예상 내용을 포함했는지에 대한 신중한 판단을 기반으로 한다.
복구는 장치 분실 등으로 인해 DID 작업을 수행할 수 있는 능력을 상실한 컨트롤러가 DID 작업을 수행할 수 있는 능력을 회복할 수 있는 반응적인 보안 조치이다.
DID 복구 사용을 고려할 때 다음 사항이 유용할 수 있다:
DID는 중앙 등록 기관의 필요 없이 전 세계적인 고유성을 달성한다. 이는 사람이 기억하기 어려운 대가로 온다. 전 세계적으로 모호하지 않은 식별자를 생성할 수 있는 알고리즘은 사람에게 의미가 없는 무작위 문자열을 생성한다. 이러한 상충 관계는 종종 주코의 삼각형이라고 한다.
사람이 알아보기 쉬운 식별자에서 시작하여 DID를 발견하는 것이 바람직한 사용 사례가 있다. 예를 들어 자연어 이름, 도메인 이름 또는 DID 컨트롤러의 기존 주소(예: 휴대전화 번호, 이메일 주소, 소셜 미디어 사용자 이름 또는 블로그 URL)가 있다. 그러나 사람이 알아보기 쉬운 식별자를 DID에 매핑하고 검증 및 신뢰할 수 있는 방식으로 이를 수행하는 문제는 이 규격의 범위를 벗어난다.
이 문제에 대한 해결책은 이 규격을 참조하는 [[?DNS-DID]]와 같은 별도의 규격에 정의되어 있다. 이러한 규격에서는 다음 사항을 신중하게 고려하는 것이 좋다:
DID 컨트롤러가 원하는 경우 DID 또는 DID URL은 영구적이고 위치에 독립적인 리소스 식별자 역할을 할 수 있다. 이러한 유형의 식별자는 Uniform Resource Name(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 메소드 외부에서 검증 단계를 수행하지 않고는 신뢰할 수 없다.
의 추가 지침을 참조하라.
DID 문서의 다른 보안 관련 속성과 마찬가지로, DID 문서의 동등성 진술에 의존하는 당사자는 적절한 검증이 수행된 후 이러한 속성의 값이 공격자에 의해 대체되는 것을 방지해야 한다. 검증이 수행된 후 메모리 또는 디스크에 저장된 DID 문서에 대한 모든 쓰기 액세스는 DID 문서가 재검증되지 않는 한 검증을 우회할 수 있는 공격 벡터이다.
이미지, 웹 페이지 또는 스키마와 같은 외부 기계 판독 가능 콘텐츠에 대한 링크를 포함하는 DID 문서는 변조에 취약하다. 해시링크 [[?HASHLINK]]와 같은 솔루션을 사용하여 외부 링크의 무결성을 보호하는 것이 강력히 권장된다. 외부 링크의 무결성을 보호할 수 없고 DID 문서의 무결성이 외부 링크에 의존하는 경우 외부 링크는 피해야 한다.
DID 문서 자체의 무결성에 영향을 줄 수 있는 외부 링크의 한 예는 JSON-LD 컨텍스트 [[JSON-LD11]]이다. 손상으로부터 보호하기 위해 DID 문서 소비자는 JSON-LD 컨텍스트의 로컬 정적 사본을 캐시하거나 안전한 버전의 외부 JSON-LD 컨텍스트와 연관된 것으로 알려진 암호화 해시에 대해 외부 컨텍스트의 무결성을 검증하는 것이 좋다.
DID는 컨트롤러가 자신의 식별자를 유지하기 위해 단일 신뢰할 수 있는 제3자 또는 관리자에 의존할 필요가 없도록 지속적으로 설계되었다. 이상적인 경우 어떤 관리자도 컨트롤러로부터 제어권을 빼앗을 수 없으며 인증, 권한 부여 및 증명과 같은 특정 목적으로 식별자 사용을 막을 수 없다. 제3자는 컨트롤러의 동의 없이 엔티티의 식별자를 제거하거나 작동하지 않게 만들기 위해 컨트롤러를 대신하여 행동할 수 없다.
그러나 암호화 제어 증명을 가능하게 하는 모든 DID 메소드에서 제어를 증명하는 수단은 항상 비밀 암호화 자료를 다른 당사자에게 전송함으로써 전송될 수 있다는 점에 유의하는 것이 중요하다. 따라서 시간이 지남에 따라 식별자의 지속성에 의존하는 시스템은 식별자가 실제로 여전히 의도한 당사자의 제어 하에 있는지 정기적으로 확인해야 한다.
불행히도 암호화 자체만으로는 주어진 검증 방법와 관련된 비밀 암호화 자료가 손상되었는지 여부를 판단할 수 없다. 예상되는 컨트롤러가 여전히 비밀 암호화 자료에 액세스할 수 있으며, 이에 따라 검증 프로세스의 일부로 제어 증명을 실행할 수 있는 반면, 동시에 악의적인 행위자도 동일한 키 또는 그 사본에 액세스할 수 있을 수 있다.
따라서 암호화 제어 증명은 고위험 시나리오에 필요한 신원 보증 수준을 평가하는 데 하나의 요소로만 사용될 것으로 예상된다. DID 기반 인증은 시스템 간에 해당 비밀을 전송하지 않고도 암호화 비밀에 대한 제어를 결정할 수 있는 기능 덕분에 사용자 이름과 암호보다 훨씬 더 큰 보증을 제공한다. 그러나 무오류는 아니다. 민감하거나 고가치 또는 생명에 중요한 작업과 관련된 시나리오에서는 적절한 추가 요소를 사용할 것으로 예상된다.
서로 다른 컨트롤러에 의한 사용으로 인한 잠재적 모호성 외에도, 일반적으로 주어진 DID가 특정 시점에 동일한 주체를 참조하여 사용되고 있음을 보장할 수 없다. 컨트롤러가 서로 다른 주체에 대해 DID를 재사용하는 것은 기술적으로 가능하며, 더 미묘하게는 주체의 정확한 정의가 시간이 지남에 따라 변경되거나 오해될 수 있다.
예를 들어, 금융 거래에 사용되는 다양한 자격 증명을 받는 개인 기업에 사용되는 DID를 고려해 보자. 컨트롤러에게 해당 식별자는 사업을 지칭했다. 사업이 성장함에 따라 결국 유한책임회사로 법인화된다. 컨트롤러는 DID가 사업을 지칭하기 때문에 동일한 DID를 계속 사용한다. 그러나 주, 세무 당국 및 지방 자치 단체에 대해서는 DID가 더 이상 동일한 엔티티를 지칭하지 않는다. 의미의 미묘한 변화가 신용 제공자나 공급자에게 중요한지 여부는 반드시 그들이 결정해야 한다. 많은 경우 청구서가 지불되고 추심이 시행될 수 있는 한 변화는 중요하지 않다.
이러한 잠재적 모호성으로 인해 DID는 절대적이라기보다는 문맥적으로 유효한 것으로 간주되어야 한다. 그것들의 지속성은 그것들이 정확히 동일한 주체를 지칭한다거나 동일한 컨트롤러의 제어 하에 있음을 의미하지 않는다. 대신 DID가 생성된 맥락, 어떻게 사용되는지, 그 의미의 변화 가능성을 이해하고 잠재적이고 불가피한 의미론적 변화를 해결하기 위한 절차와 정책을 채택해야 한다.
규정된 금융 및 공공 부문과 같은 영역에서는 특히 규정 준수를 위해 인증 이벤트의 보안 컨텍스트에 대한 추가 정보가 종종 필요하다. 이 정보는 종종 보증 수준(LOA)이라고 한다. 예로는 비밀 암호화 자료의 보호, 신원 증명 프로세스, 인증자의 형태 등이 있다.
Payment services (PSD 2) and eIDAS introduce such requirements to the security context. Level of assurance frameworks are classified and defined by regulations and standards such as eIDAS, NIST 800-63-3 and ISO/IEC 29115:2013, including their requirements for the security context, and making recommendations on how to achieve them. This might include strong user authentication where FIDO2/WebAuthn can fulfill the requirement.
일부 규제되는 시나리오에서는 특정 수준의 보증을 구현해야 한다.
assertionMethod
와 authentication
과 같은 검증 관계가 이러한 상황 중 일부에서 사용될 수 있으므로
적용된 보안 컨텍스트에 대한 정보를 표현하고 검증자에게
제공해야 할 수 있다. 이 정보를 DID 문서 데이터 모델에 인코딩할
것인지 여부와 방법은 이 규격의 범위를 벗어난다. 관심 있는 독자는 1)
정보가 검증 가능한 크리덴셜 [[?VC-DATA-MODEL]]을 사용하여 전송될 수
있고, 2) DID 문서 데이터 모델은 에
설명된 대로 이 정보를 통합하도록 확장될 수 있으며, 여기서
는 그러한 확장에 적용될 수
있다는 점에 유의할 수 있다.
DID와 DID 문서는 DID 컨트롤러에 의해 직접 관리되도록 설계되었기 때문에 탈중앙 식별자 아키텍처의 모든 측면에 Privacy by Design [[PRIVACY-BY-DESIGN]]의 원칙을 적용하는 것이 매우 중요하다. 이 규격을 개발하는 동안 이 일곱 가지 원칙이 모두 적용되었다. 이 규격에 사용된 설계는 추가적인 개인정보 보호 조치를 권장하거나 적용할 등록 기관, 호스팅 회사 또는 기타 중개 서비스 제공자가 있다고 가정하지 않는다. 이 규격의 개인정보 보호는 사후 대책이 아니라 예방적이며 기본으로 내장되어 있다. 다음 섹션에서는 탈중앙 식별자를 활용하는 시스템을 구축할 때 구현자가 유용하게 활용할 수 있는 개인정보 보호 고려사항을 다룬다.
DID 메소드 규격이 해당 DID와 DID 문서가 공개될 수 있는 공개 대상 검증 가능한 데이터 레지스트리에 대해 작성된 경우, 해당 DID 문서에 개인 데이터가 포함되지 않는 것이 매우 중요하다. 개인 데이터는 대신 1) 검증 가능한 크리덴셜 [[?VC-DATA-MODEL]] 또는 2) DID 주체 또는 DID 컨트롤러의 제어하에 있는 서비스 엔드포인트와 같은 다른 수단을 통해 전송될 수 있다.
서비스 엔드포인트의 URL에서 개인 데이터 유출 또는 서비스 엔드포인트의 URL 내 상관관계를 방지하기 위해 URL 사용과 관련하여 실사가 이루어져야 한다. 예를 들어 사용자 이름을 포함하는 URL은 DID 문서에 포함하기에 위험한데, 그 이유는 사용자 이름이 DID 주체가 공유하는 데 동의하지 않은 정보를 공개할 수 있는 방식으로 사람에게 의미 있을 가능성이 높기 때문이다. 이 규격에서 제안하는 개인정보 보호 아키텍처를 사용하면 DID 문서의 검증 방법로 식별되고 보호되는 통신 채널을 사용하여 개인 데이터를 비공개로 피어 간에 교환할 수 있다. 이를 통해 DID 주체와 요청 당사자가 GDPR의 잊힐 권리를 구현할 수 있는데, 그 이유는 개인 데이터가 불변의 분산 원장에 기록되지 않기 때문이다.
전 세계적으로 모호하지 않은 식별자와 마찬가지로 DID는 상관관계에 사용될 수 있다. DID 컨트롤러는 각 관계에 고유한 쌍별 DID를 사용하여 이러한 개인정보 보호 위험을 완화할 수 있다. 실제로 각 DID는 가명으로 작용한다. 쌍별 DID는 상관관계가 명시적으로 원하는 경우에만 둘 이상의 당사자와 공유할 필요가 있다. 쌍별 DID가 기본값인 경우 DID를 공개적으로 게시하거나 여러 당사자와 공유해야 할 유일한 필요성은 DID 컨트롤러 및/또는 DID 주체가 명시적으로 공개 식별 및 상관관계를 원할 때이다.
해당 DID 문서의 데이터를 상호 연관시킬 수 있는 경우 쌍별 DID의 반상관관계 보호가 쉽게 무력화된다. 예를 들어 여러 DID 문서에서 동일한 검증 방법 또는 맞춤형 서비스 엔드포인트를 사용하면 동일한 DID를 사용하는 것만큼 많은 상관관계 정보를 제공할 수 있다. 따라서 쌍별 DID에 대한 DID 문서도 검증 방법가 쌍별 관계에 고유한지 확인하는 것과 같은 쌍별 고유 정보를 사용해야 한다.
쌍별 DID에 대한 DID 문서에서 쌍별 고유 서비스 엔드포인트를 사용하는 것도 자연스러워 보일 수 있다. 그러나 고유한 엔드포인트를 사용하면 두 DID 사이의 모든 트래픽을 고유한 버킷으로 완벽하게 분리할 수 있으므로 타이밍 상관관계 및 유사한 분석이 쉬워진다. 따라서 엔드포인트 개인정보 보호를 위한 더 나은 전략은 많은 다른 주체가 제어하는 다수의 DID 간에 엔드포인트를 공유하는 것일 수 있다( 참조).
DID 주체가 무엇인지, 특히 DID 주체가 사람인 경우 명시적으로 또는 추론을 통해 유형 또는 성질을 나타내는 데 사용될 수 있는 속성을 DID 문서에 추가하는 것은 위험하다.
이러한 속성은 DID 문서에 개인 데이터( 참조) 또는 상호 연관 가능한 데이터( 및 참조)가 존재하게 할 뿐만 아니라, 특정 DID를 그룹화하여 특정 작업이나 기능에 포함시키거나 제외시키는 데 사용될 수 있다.
DID 문서에 유형 정보를 포함하면 IoT 장치와 같이 사람이 아닌 엔티티인 DID 주체에 대해서도 개인정보 보호 피해가 발생할 수 있다. DID 컨트롤러 주변의 이러한 정보 집계는 일종의 디지털 지문 역할을 할 수 있으므로 피하는 것이 가장 좋다.
이러한 위험을 최소화하기 위해 DID 문서의 모든 속성은 DID 사용과 관련된 암호화 자료, 엔드포인트 또는 검증 방법를 표현하기 위한 것이어야 한다.
DID 주체가 군중 속에서 구별할 수 없을 때 개인정보 보호를 이용할 수 있다. 다른 당사자와 사적으로 관여하는 행위 자체가 인식 가능한 신호일 때 개인정보 보호는 크게 감소한다.
DID와 DID 메소드는 특히 합법적으로 가장 필요로 하는 사람들을 위해 군중 개인정보 보호를 개선하기 위해 노력해야 한다. 익명성과 가명성을 보존하는 것을 기본으로 하는 기술과 사용자 인터페이스를 선택하라. 디지털 지문을 줄이기 위해 요청 당사자 구현에서 공통 설정을 공유하고, 유선 프로토콜에서 협상된 옵션을 최소한으로 유지하고, 암호화된 전송 계층을 사용하고, 메시지를 표준 길이로 채워라.
컨트롤러가 DID 문서에서 선택적으로 하나 이상의 서비스 엔드포인트를 표현할 수 있는 능력은 그들의 제어와 주체성을 증가시킨다. DID 문서의 각 추가 엔드포인트는 엔드포인트 설명에 걸친 상관관계로 인해 개인정보 보호 위험을 증가시키거나 서비스가 인증 메커니즘에 의해 보호되지 않기 때문에 또는 둘 다로 인해 개인정보 보호 위험을 증가시킨다.
DID 문서는 종종 공개적이며 표준화되어 있기 때문에 표준 기반 특성에 따라 효율적으로 저장되고 색인화된다. 이 위험은 DID 문서가 불변의 검증 가능한 데이터 레지스트리에 게시되는 경우 더 심각하다. DID에 의해 참조되는 DID 문서 기록에 대한 액세스는 표준 사용을 통해 더 효율적으로 이루어지는 일종의 트래픽 분석 형태를 나타낸다.
하나의 DID 문서에서 여러 서비스 엔드포인트를 사용하여
발생하는 추가적인 개인정보 보호 위험의 정도는 추정하기 어려울 수 있다.
개인정보 보호 피해는 일반적으로 의도하지 않은 결과이다. DID는
개인, 가구, 클럽, 고용주와 관련될 수 있는 문서, 서비스, 스키마
및 기타 사항을 지칭할 수 있으며, 이들의
서비스 엔드포인트 상관관계는 강력한 감시 및 추론 도구가 될 수
있다. 이러한 잠재적 피해의 예는 https://example.co.uk
와
같은 여러 공통 국가 수준 최상위 도메인을 사용하여 더 높은 확률로
DID 주체의 대략적인 위치를 추론할 수 있을 때 확인할 수 있다.
가능한 엔드포인트의 다양성으로 인해 DID 주체에 대한 정보가 유출되지 않는 군중 개인정보 보호를 유지하는 것이 특히 어려울 수 있다( 참조).
첫째, 서비스 엔드포인트가 URI로 지정될 수 있기 때문에 서비스
아키텍처로 인해 의도치 않게 개인 정보가 유출될 수 있다. 예를 들어
http://example.com/MyFirstName
이라는 서비스
엔드포인트는 DID 문서에 액세스할 수 있는 모든 사람에게
MyFirstName
이라는 용어를 유출하고 있다. 레거시 시스템과
연결할 때는 이러한 위험을 피할 수 없으며 이러한 경우 주의가
필요하다. 이 규격은 새로운 DID 인식 엔드포인트가 필요한 모든
식별을 위해 DID 자체 이상의 것을 사용하지 않도록 권장한다.
예를 들어 서비스 설명에
http://example.com/did%3Aexample%3Aabc123
이 포함되어
있더라도 did:example:abc123
이 이미 DID 문서에 노출되어
있기 때문에 추가 정보가 유출되지 않으므로 피해가 발생하지 않는다.
둘째, DID 문서에 여러 서비스 엔드포인트가 나열될 수 있기 때문에 다른 어떤 맥락에서도 연결되지 않은 서비스를 돌이킬 수 없게 연결할 수 있다. 이러한 상관관계 자체만으로도 사용된 URI가 민감한 정보를 포함하지 않았더라도 DID 주체에 대한 정보를 공개함으로써 개인정보 보호 피해로 이어질 수 있다.
셋째, 일부 유형의 DID 주체가 특정 엔드포인트를 나열할 가능성이 더 높거나 낮기 때문에 주어진 서비스의 나열 자체로 DID 주체에 대해 추론하는 데 사용될 수 있는 정보를 유출할 수 있다. 예를 들어 자동차용 DID에는 자동차국의 공공 소유권 기록에 대한 포인터가 포함될 수 있지만 개인용 DID에는 해당 정보가 포함되지 않을 수 있다.
군중 개인정보 보호의 목표는 특정 DID 주체의 특성이 전체 모집단에 의해 모호해지도록 하는 것이다. 군중 개인정보 보호를 극대화하기 위해 구현자는 이러한 연결을 보호하고 궁극적인 서비스에 대한 요청을 가리기 위해 컨트롤러가 기꺼이 의존할 프록시 또는 중재자 서비스를 제공하는 하나의 서비스 엔드포인트에만 의존해야 한다.
이전 섹션의 우려사항을 감안할 때 구현자는 다음과 같은 서비스 엔드포인트 접근 방식을 고려해야 한다:
이러한 서비스 엔드포인트 유형은 계속해서 혁신과 탐색의 영역이 되고 있다.
선택적 확장 및 기타 검증 방법 유형은 검증 방법 유형 [[?DID-SPEC-REGISTRIES]]을 참조하라.
이 예시들은 정보 제공 목적으로만 제공된 것이며, 동일한 검증 방법를 여러 목적으로 사용하는 것을 피하는 것이 좋은 방법으로 간주된다.
{ "@context": [ "https://www.w3.org/ns/did/v1", "https://w3id.org/security/suites/ed25519-2020/v1" ], "id": "did:example:123", "authentication": [ { "id": "did:example:123#z6MkecaLyHuYWkayBDLw5ihndj3T1m6zKTGqau3A51G7RBf3", "type": "Ed25519VerificationKey2020", // external (property value) "controller": "did:example:123", "publicKeyMultibase": "zAKJP3f7BD6W4iWEQ9jwndVTCBq8ua2Utt8EEjJ6Vxsf" } ], "capabilityInvocation": [ { "id": "did:example:123#z6MkhdmzFu659ZJ4XKj31vtEDmjvsi5yDZG5L7Caz63oP39k", "type": "Ed25519VerificationKey2020", // external (property value) "controller": "did:example:123", "publicKeyMultibase": "z4BWwfeqdp1obQptLLMvPNgBw48p7og1ie6Hf9p5nTpNN" } ], "capabilityDelegation": [ { "id": "did:example:123#z6Mkw94ByR26zMSkNdCUi6FNRsWnc2DFEeDXyBGJ5KTzSWyi", "type": "Ed25519VerificationKey2020", // external (property value) "controller": "did:example:123", "publicKeyMultibase": "zHgo9PAmfeoxHG8Mn2XHXamxnnSwPpkyBHAMNF3VyXJCL" } ], "assertionMethod": [ { "id": "did:example:123#z6MkiukuAuQAE8ozxvmahnQGzApvtW7KT5XXKfojjwbdEomY", "type": "Ed25519VerificationKey2020", // external (property value) "controller": "did:example:123", "publicKeyMultibase": "z5TVraf9itbKXrRvt2DSS95Gw4vqU3CHAdetoufdcKazA" } ] }
{ "@context": [ "https://www.w3.org/ns/did/v1", "https://w3id.org/security/suites/jws-2020/v1" ], "verificationMethod": [ { "id": "did:example:123#key-0", "type": "JsonWebKey2020", "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": "JsonWebKey2020", "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": "JsonWebKey2020", "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": "JsonWebKey2020", "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": "JsonWebKey2020", "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": "JsonWebKey2020", "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": "JsonWebKey2020", "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": "JsonWebKey2020", "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", "https://w3id.org/security/suites/ed25519-2018/v1", "https://w3id.org/security/suites/x25519-2019/v1", "https://w3id.org/security/suites/secp256k1-2019/v1", "https://w3id.org/security/suites/jws-2020/v1" ], "verificationMethod": [ { "id": "did:example:123#key-0", "type": "Ed25519VerificationKey2018", "controller": "did:example:123", "publicKeyBase58": "3M5RCDjPTWPkKSN3sxUmmMqHbmRPegYP1tjcKyrDbt9J" // external (property name) }, { "id": "did:example:123#key-1", "type": "X25519KeyAgreementKey2019", "controller": "did:example:123", "publicKeyBase58": "FbQWLPRhTH95MCkQUeFYdiSoQt8zMwetqfWoxqPgaq7x" // external (property name) }, { "id": "did:example:123#key-2", "type": "EcdsaSecp256k1VerificationKey2019", "controller": "did:example:123", "publicKeyBase58": "ns2aFDq25fEV1NUd3wZ65sgj5QjFW8JCAHdUJfLwfodt" // external (property name) }, { "id": "did:example:123#key-3", "type": "JsonWebKey2020", "controller": "did:example:123", "publicKeyJwk": { "kty": "EC", // external (property name) "crv": "P-256", // external (property name) "x": "Er6KSSnAjI70ObRWhlaMgqyIOQYrDJTE94ej5hybQ2M", // external (property name) "y": "pPVzCOTJwgikPjuUE6UebfZySqEJ0ZtsWFpj7YSPGEk" // external (property name) } } ] }
이 예제는 정보전달만을 목적으로 한다. 추가적인 예제 확인은 W3C Verifiable Credentials Data Model 를 참고하라.
{ // external (all terms in this example)
"@context": [
"https://www.w3.org/2018/credentials/v1",
"https://w3id.org/citizenship/v1"
],
"type": [
"VerifiableCredential",
"PermanentResidentCard"
],
"credentialSubject": {
"id": "did:example:123",
"type": [
"PermanentResident",
"Person"
],
"givenName": "JOHN",
"familyName": "SMITH",
"gender": "Male",
"image": "data:image/png;base64,iVBORw0KGgo...kJggg==",
"residentSince": "2015-01-01",
"lprCategory": "C09",
"lprNumber": "000-000-204",
"commuterClassification": "C1",
"birthCountry": "Bahamas",
"birthDate": "1958-08-17"
},
"issuer": "did:example:456",
"issuanceDate": "2020-04-22T10:37:22Z",
"identifier": "83627465",
"name": "Permanent Resident Card",
"description": "Government of Example Permanent Resident Card.",
"proof": {
"type": "Ed25519Signature2018",
"created": "2020-04-22T10:37:22Z",
"proofPurpose": "assertionMethod",
"verificationMethod": "did:example:456#key-1",
"jws": "eyJjcml0IjpbImI2NCJdLCJiNjQiOmZhbHNlLCJhbGciOiJFZERTQSJ9..BhWew0x-txcroGjgdtK-yBCqoetg9DD9SgV4245TmXJi-PmqFzux6Cwaph0r-mbqzlE17yLebjfqbRT275U1AA"
}
}
{ // external (all terms in this example)
"@context": [
"https://www.w3.org/2018/credentials/v1",
"https://www.w3.org/2018/credentials/examples/v1"
],
"id": "http://example.gov/credentials/3732",
"type": ["VerifiableCredential", "UniversityDegreeCredential"],
"issuer": { "id": "did:example:123" },
"issuanceDate": "2020-03-10T04:24:12.164Z",
"credentialSubject": {
"id": "did:example:456",
"degree": {
"type": "BachelorDegree",
"name": "Bachelor of Science and Arts"
}
},
"proof": {
"type": "JsonWebSignature2020",
"created": "2020-02-15T17:13:18Z",
"verificationMethod": "did:example:123#_Qq0UL2Fq651Q0Fjd6TvnYE-faHiOpRlPVQcY_-tA4A",
"proofPurpose": "assertionMethod",
"jws": "eyJiNjQiOmZhbHNlLCJjcml0IjpbImI2NCJdLCJhbGciOiJFZERTQSJ9..Y0KqovWCPAeeFhkJxfQ22pbVl43Z7UI-X-1JX32CA9MkFHkmNprcNj9Da4Q4QOl0cY3obF8cdDRdnKr0IwNrAw"
}
}
{ // external (all terms in this example)
"@context": [
"https://www.w3.org/2018/credentials/v1",
"https://w3id.org/security/bbs/v1",
{
"name": "https://schema.org/name",
"birthDate": "https://schema.org/birthDate"
}
],
"id": "urn:uuid:c499e122-3ba9-4e95-8d4d-c0ebfcf8c51a",
"type": ["VerifiableCredential"],
"issuanceDate": "2021-02-07T16:02:08.571Z",
"issuer": {
"id": "did:example:123"
},
"credentialSubject": {
"id": "did:example:456",
"name": "John Smith",
"birthDate": "2021-02-07"
},
"proof": {
"type": "BbsBlsSignature2020",
"created": "2021-02-07T16:02:10Z",
"proofPurpose": "assertionMethod",
"proofValue": "o7zD2eNTp657YzkJLub+IO4Zqy/R3Lv/AWmtSA/kUlEAOa73BNyP1vOeoow35jkABolx4kYMKkp/ZsFDweuKwe/p9vxv9wrMJ9GpiOZjHcpjelDRRJLBiccg9Yv7608mHgH0N1Qrj14PZ2saUlfhpQ==",
"verificationMethod": "did:example:123#bls12381-g2-key"
}
}
{ // external (all terms in this example)
"@context": [
"https://www.w3.org/2018/credentials/v1",
"https://w3id.org/security/bbs/v1",
{
"name": "https://schema.org/name",
"birthDate": "https://schema.org/birthDate"
}
],
"id": "urn:uuid:c499e122-3ba9-4e95-8d4d-c0ebfcf8c51a",
"type": "VerifiableCredential",
"issuanceDate": "2021-02-07T16:02:08.571Z",
"issuer": {
"id": "did:example:123"
},
"credentialSubject": {
"id": "did:example:456",
"birthDate": "2021-02-07"
},
"proof": {
"type": "BbsBlsSignatureProof2020",
"created": "2021-02-07T16:02:10Z",
"nonce": "OqZHsV/aunS34BhLaSoxiHWK+SUaG4iozM3V+1jO06zRRNcDWID+I0uwtPJJ767Yo8Q=",
"proofPurpose": "assertionMethod",
"proofValue": "AAsH34lcKsqaqPaLQWcnLMe3mDM+K7fZM0t4Iesfj7BhD//HBtuWCmZE946BqW7OHYU106MP8mLntutqB8FyGwS7AOyK+5/7iW6JwLNVCvh4Nt3IaF3AN47fqVs2VikD9DiCsaFAUU6ISj5pbad8O+6jiT9Yw6ug8t8vJn3XHvMUhCPnDZJeBEdKD1qo4Z0LOq3L8QAAAHSEgtC9BoZL2MLjz4QuPxpwbhTTRC08MIUjdJnP4JUtz6163Lsl3rpadGu2d3Te7loAAAACZBD4YWOgV0xpPoYZ5vywNA5/NTeDHDbX36gvoV5RDJtY1SLU2LN/IDPZGrfhEiASbD1/QXqj8dod6FbjBs9m/LchBcy7z4yDBv/8DnBzDJ9dEaM4bDjpwmqtgJqha2kwtlyNog67xG9tNjnp5rrbIgAAAANMVanwWmlkg5I/f1M2QJ5GRvQiBL4lyL5sttxwIOalbTZP8VqWtFJI54xMNjTiK71aFWWN8SlNEwfVIX34HO5zBIb6fvc+Or21ubYllT9eXv1epl2o2CojuieCZyxE8/Q=",
"verificationMethod": "did:example:123#bls12381-g2-key"
}
}
{ // external (all terms in this example)
"protected": {
"kid": "did:example:123#_Qq0UL2Fq651Q0Fjd6TvnYE-faHiOpRlPVQcY_-tA4A",
"alg": "EdDSA"
},
"payload": {
"iss": "did:example:123",
"sub": "did:example:456",
"vc": {
"@context": [
"https://www.w3.org/2018/credentials/v1",
"https://www.w3.org/2018/credentials/examples/v1"
],
"id": "http://example.gov/credentials/3732",
"type": [
"VerifiableCredential",
"UniversityDegreeCredential"
],
"issuer": {
"id": "did:example:123"
},
"issuanceDate": "2020-03-10T04:24:12.164Z",
"credentialSubject": {
"id": "did:example:456",
"degree": {
"type": "BachelorDegree",
"name": "Bachelor of Science and Arts"
}
}
},
"jti": "http://example.gov/credentials/3732",
"nbf": 1583814252
},
"signature": "qSv6dpZJGFybtcifLwGf4ujzlEu-fam_M7HPxinCbVhz9iIJCg70UMeQbPa1ex6BmQ2tnSS7F11FHnMB2bJRAw"
}
이러한 예는 정보 제공 목적으로만 제공되며, 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"
}
Following is a diagram showing the relationships among , , and , and .
DID의 생성은 각 DID 메소드에 의해 정의되는 프로세스이다.
did:key
와 같은 일부 DID 메소드는 순수하게
생성적이어서 단일 암호화 자료를 규격에 맞는 표현으로 변환하여
DID와 DID 문서를 생성한다. 다른 DID 메소드는
검증 가능한 데이터 레지스트리의 사용을 요구할 수 있으며, 여기서
DID와 DID 문서는 해당 DID 메소드에 의해 정의된
대로 등록이 완료되었을 때만 제3자에 의해 존재하는 것으로 인식된다.
다른 프로세스는 해당 DID 메소드에 의해 정의될 수 있다.
DID는 특정 유형의 URI(Uniform Resource Identifier)이므로 DID는 모든 리소스를 참조할 수 있다. [[RFC3986]]에 따르면:
"리소스"라는 용어는 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 해석의 결과물이다.
This distinction is illustrated by the graph model shown below.
DID 문서의 각 속성은 다음을 설명하는 DID 컨트롤러의 명세이다:
id
및 alsoKnownAs
속성)
verificationMethod
및
service
속성).
@context
속성).
DID 문서에서 필수 속성은 id
뿐이므로, 이것이 DID 문서에 보장되는 유일한 명세이다. 이
명세는 에서 DID와
DID 주체 사이의 직접 링크로 표시된다.
DID 주체에 대한 추가 정보를 발견하는 옵션은 DID 문서에
존재하는 속성에 따라 다르다. service
속성이 있는
경우 서비스 엔드포인트에서 추가 정보를 요청할 수 있다. 예를
들어 DID 주체를 설명하는 하나 이상의 클레임(속성)에 대해 검증
가능한 크리덴셜을 지원하는 서비스 엔드포인트를 쿼리하여 추가
정보를 얻을 수 있다.
또 다른 옵션은 DID 문서에
alsoKnownAs
속성이 있는 경우 이를 사용하는 것이다.
DID 컨트롤러는 이를 사용하여 동일한 DID 주체를 참조하는
다른 URI(다른 DID 포함) 목록을 제공할 수 있다. 아래 그림에
표시된 것처럼 이러한 URI를 해석하거나 역참조하면 DID 주체에
대한 다른 설명 또는 표현을 얻을 수 있다.
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 주체를 두 개의 서로 소 집합으로 분류하는 것이 도움이 된다.
에 표시된 첫 번째 경우는 DID 주체가 DID 컨트롤러이기도 한 일반적인 시나리오이다. 이것은 개인이나 조직이 자기 자신을 식별하기 위해 DID를 만드는 경우이다.
그래프 모델 관점에서 보면, 에서 DID 컨트롤러와 DID 주체로 식별되는 노드가 서로 구별되더라도 의미론적 동등성 관계를 표현하기 위해 이들을 연결하는 논리적 호가 있다.
두 번째 경우는 DID 주체가 DID 컨트롤러와 별개의 엔티티인 경우이다. 이는 예를 들어 부모가 자녀를 위한 DID를 생성하고 제어를 유지하는 경우, 기업이 자회사를 위한 DID를 생성하고 제어를 유지하는 경우, 또는 제조업체가 제품, IoT 장치 또는 디지털 파일을 위한 DID를 생성하고 제어를 유지하는 경우이다.
그래프 모델 관점에서 보면, 집합 1과의 유일한 차이점은 DID 주체와 DID 컨트롤러 노드 사이에 동등성 호 관계가 없다는 것이다.
DID 문서에는 둘 이상의 DID 컨트롤러가 있을 수 있다. 이는 두 가지 방식 중 하나로 발생할 수 있다.
이 경우 각 DID 컨트롤러는 독자적으로 행동할 수 있다. 즉, 각 컨트롤러는 DID 문서를 독립적으로 업데이트할 수 있는 완전한 권한을 가지고 있다. 그래프 모델 관점에서 이 구성에서는:
그룹 제어의 경우 DID 컨트롤러는 여러 디지털 서명("멀티 시그")이나 임계값 수의 디지털 서명("m-of-n")을 요구하는 암호화 알고리즘을 사용할 때와 같이 어떤 방식으로든 함께 행동할 것으로 예상된다. 기능적 관점에서 이 옵션은 단일 DID 컨트롤러와 유사한데, 비록 DID 컨트롤러 그룹의 각 DID 컨트롤러가 자체 그래프 노드를 가지고 있지만 에 표시된 것처럼 실제 제어는 DID 컨트롤러 그룹을 나타내는 단일 논리적 그래프 노드로 축소되기 때문이다.
이 구성은 DID 주체가 단일 개인이 제어하지 않는 조직, 기업, 정부 기관, 커뮤니티 또는 기타 그룹일 때 종종 적용될 것이다.
DID 문서에는 DID 주체를 참조하는 정확히 하나의
DID가 있다. DID는 id
속성의 값으로
표현된다. 이 속성 값은 DID 문서의 수명 동안 불변이다.
그러나 DID에 의해 식별된 리소스인 DID 주체가 시간이 지남에 따라 변경될 수 있다. 이는 DID 컨트롤러의 독점적 권한 하에 있다. 자세한 내용은 섹션을 참조하라.
DID 문서의 DID 컨트롤러는 시간이 지남에 따라 변경될 수 있다. 그러나 구현 방식에 따라 DID 컨트롤러의 변경은 DID 문서 자체의 변경으로 명확히 드러나지 않을 수 있다. 예를 들어 변경이 DID 문서의 하나 이상의 검증 방법에 사용되는 기본 암호화 키 또는 기타 제어의 소유권 이동을 통해 구현되는 경우 표준 키 교체와 구별할 수 없을 수 있다.
반면에 변경이 `controller` 속성의 값을 변경하여 구현되는 경우 투명할 것이다.
DID 컨트롤러의 변경을 검증하는 것이 중요한 경우 구현자는 수정된 DID 문서의 검증 방법에 대해 새로운 DID 컨트롤러를 인증하는 것이 좋다.
This section contains the changes that have been made since the publication of this specification as a W3C First Public Working Draft.
Changes since the Second Candidate Recommendation include:
publicKeyMultibase
.
Changes since the First Candidate Recommendation include:
Changes since the First Public Working Draft include:
The Working Group extends deep appreciation and heartfelt thanks to our Chairs Brent Zundel and Dan Burnett, as well as our W3C Staff Contact, Ivan Herman, for their tireless work in keeping the Working Group headed in a productive direction and navigating the deep and dangerous waters of the standards process.
The Working Group gratefully acknowledges the work that led to the creation of this specification, and extends sincere appreciation to those individuals that worked on technologies and specifications that deeply influenced our work. In particular, this includes the work of Phil Zimmerman, Jon Callas, Lutz Donnerhacke, Hal Finney, David Shaw, and Rodney Thayer on Pretty Good Privacy (PGP) in the 1990s and 2000s.
In the mid-2010s, preliminary implementations of what would become Decentralized Identifiers were built in collaboration with Jeremie Miller's Telehash project and the W3C Web Payments Community Group's work led by Dave Longley and Manu Sporny. Around a year later, the XDI.org Registry Working Group began exploring decentralized technologies for replacing its existing identifier registry. Some of the first written papers exploring the concept of Decentralized Identifiers can be traced back to the first several Rebooting the Web of Trust workshops convened by Christopher Allen. That work led to a key collaboration between Christopher Allen, Drummond Reed, Les Chasen, Manu Sporny, and Anil John. Anil saw promise in the technology and allocated the initial set of government funding to explore the space. Without the support of Anil John and his guidance through the years, it is unlikely that Decentralized Identifiers would be where they are today. Further refinement at the Rebooting the Web of Trust workshops led to the first implementers documentation, edited by Drummond Reed, Les Chasen, Christopher Allen, and Ryan Grant. Contributors included Manu Sporny, Dave Longley, Jason Law, Daniel Hardman, Markus Sabadello, Christian Lundkvist, and Jonathan Endersby. This initial work was then merged into the W3C Credentials Community Group, incubated further, and then transitioned to the W3C Decentralized Identifiers Working Group for global standardization.
Portions of the work on this specification have been funded by the United States Department of Homeland Security's (US DHS) Science and Technology Directorate under contracts HSHQDC-16-R00012-H-SB2016-1-002, and HSHQDC-17-C-00019, as well as the US DHS Silicon Valley Innovation Program under contracts 70RSAT20T00000010, 70RSAT20T00000029, 70RSAT20T00000030, 70RSAT20T00000045, 70RSAT20T00000003, and 70RSAT20T00000033. The content of this specification does not necessarily reflect the position or the policy of the U.S. Government and no official endorsement should be inferred.
Portions of the work on this specification have also been funded by the European Union's StandICT.eu program under sub-grantee contract number CALL05/19. The content of this specification does not necessarily reflect the position or the policy of the European Union and no official endorsement should be inferred.
Work on this specification has also been supported by the Rebooting the Web of Trust community facilitated by Christopher Allen, Shannon Appelcline, Kiara Robles, Brian Weller, Betty Dhamers, Kaliya Young, Kim Hamilton Duffy, Manu Sporny, Drummond Reed, Joe Andrieu, and Heather Vescent. Development of this specification has also been supported by the W3C Credentials Community Group, which has been Chaired by Kim Hamilton Duffy, Joe Andrieu, Christopher Allen, Heather Vescent, and Wayne Chang. The participants in the Internet Identity Workshop, facilitated by Phil Windley, Kaliya Young, Doc Searls, and Heidi Nobantu Saul, also supported this work through numerous working sessions designed to debate, improve, and educate participants about this specification.
The Working Group thanks the following individuals for their contributions to this specification (in alphabetical order, Github handles start with `@` and are sorted as last names): 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.
This section will be submitted to the Internet Engineering Steering Group (IESG) for review, approval, and registration with IANA when this specification becomes a W3C Proposed Recommendation.
Fragment identifiers used with application/did+json are treated according to the rules defined in .
The Candidate Recommendation phase for this specification received a
significant number of implementations for the
application/did+ld+json
media type. Registration of the
media type application/did+ld+json
at IANA is pending
resolution of the
Media Types with Multiple Suffixes
issue. Work is expected to continue in the
IETF Media Type Maintenance Working Group
with a registration of the application/did+ld+json
media
type by W3C following shortly after the publication of the
Media Types with Multiple Suffixes
RFC.
Fragment identifiers used with application/did+ld+json are treated according to the rules associated with the JSON-LD 1.1: application/ld+json media type [[JSON-LD11]].