탈중앙화 식별자 확인(DID 확인) v0.3

비규범으로 표시된 절뿐 아니라, 이 사양의 모든 작성 지침, 다이어그램, 예시 및 참고는 비규범적입니다. 이 사양의 그 밖의 모든 내용은 규범적입니다.

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

준수 DID 확인자는 4. DID 확인의 관련 규범적 진술을 준수하는 소프트웨어 및/또는 하드웨어로 실현된 모든 알고리즘입니다.

준수 네트워크 기반 DID 확인자는 준수 DID 확인자이며, 추가로 12.1 HTTP(S) 바인딩의 규범적 진술을 준수하는 것입니다.

준수 DID URL 역참조자는 5. DID URL 역참조의 관련 규범적 진술을 준수하는 소프트웨어 및/또는 하드웨어로 실현된 모든 알고리즘입니다.

준수 네트워크 기반 DID URL 역참조자는 준수 DID URL 역참조자이며, 추가로 12.1 HTTP(S) 바인딩의 규범적 진술을 준수하는 것입니다.

이 사양의 모든 날짜시간 값은 ASCII 문자열이어야 MUST 하며, [VC-DATA-MODEL]의 검증 가능 자격 증명 데이터 모델 v2.0에서 정의한 유효한 XML 날짜시간 값이어야 합니다. 또한 DID 확인에서 사용되는 타임스탬프는 초 미만의 소수 정밀도 없이 UTC로 조정되어야 MUST 합니다. 예: 2020-12-20T19:17:47Z

DID URL 쿼리 문자열은 확인 파이프라인 전반의 여러 독립 구성요소, 예를 들어 클라이언트, 캐싱 프록시, 다운스트림 확인자, DID 메서드별 확인자에 의해 일상적으로 구성, 파싱, 기록, 캐싱 및 비교됩니다(8.2 확인자 아키텍처 참조). 이러한 구성요소 전반에서 DID URL 쿼리 문자열의 정규화가 일관되지 않으면 잘못된 확인 결과, 캐시 오염 또는 상호운용성 손상이 조용히 발생할 수 있습니다. 이 절은 구현자와 DID 메서드 사양 작성자가 명시적으로 다루도록 권장되는 경계 사례를 열거합니다.

이는 DID 확인 과정을 위한 입력 옵션을 포함하는 메타데이터 구조입니다.

이 구조 안의 가능한 속성과 그 가능한 값은 DID Resolution Extensions [DID-EXTENSIONS-RESOLUTION]에 등록되는 것이 SHOULD됩니다. 이 사양은 다음의 공통 입력 옵션을 정의합니다.

accept

호출자가 선호하는 DID 문서의 표현의 미디어 유형입니다. 값은 HTTP Semantics 제12.5.1절에 정의된 Accept 헤더 값에 따라 표현되어야 MUST 합니다. DID 확인자 구현은 그러한 표현이 지원되고 사용 가능한 경우, 반환되는 didDocument의 표현을 결정하기 위해 이 값을 사용해야 SHOULD 합니다. 이 속성은 OPTIONAL입니다.

expandRelativeUrls

DID 확인자에게 상대 DID URL을 DID URL 구문을 준수하는 절대 DID URL로 확장하도록 지시하는 불리언 플래그입니다. 이는 DID 문서 안에서 수행됩니다.

versionId

정의는 3. DID 매개변수를 참조하십시오.

versionTime

정의는 3. DID 매개변수를 참조하십시오.

이는 DID 확인 과정에 대한 메타데이터를 포함하는 메타데이터 구조입니다.

이 메타데이터는 확인 과정 자체에 대한 데이터를 나타내므로, 일반적으로 DID 확인 함수 호출 사이에 변경됩니다.

이 메타데이터의 출처는 DID 확인자입니다.

DID 확인 메타데이터의 예는 다음과 같습니다.

• 반환된 콘텐츠의 미디어 유형(contentType).
• 오류 객체(error) (11. 오류 절 참조).
• 신뢰된 확인을 수립하기 위해 DID 확인자가 생성한 증명 등(proof).
• DID 확인 과정의 지속 시간.
• 캐싱 정보(13.2 캐싱 절 참조).
• DID 확인 과정 중 사용된 검증 가능 데이터 레지스트리에 대한 URL, IP 주소 및/또는 기타 네트워킹 정보.

이 구조 안의 가능한 속성과 그 가능한 값은 DID Resolution Extensions [DID-EXTENSIONS-RESOLUTION]에 등록되는 것이 SHOULD됩니다. 이 사양은 다음의 공통 메타데이터 속성을 정의합니다.

contentType

반환된 didDocument의 미디어 유형입니다. 이 속성은 OPTIONAL입니다. 존재하는 경우, 이 속성의 값은 준수 표현의 미디어 유형인 ASCII 문자열이어야 MUST 합니다. 이 경우, resolve 함수의 호출자는 didDocument를 어떻게 파싱하고 처리할지 결정할 때 이 값을 사용해야 MUST 합니다.

error

오류 데이터 구조는 [RFC9457]에 정의되어 있습니다. 이 사양에서 정의하는 오류는 11. 오류 절에서 찾을 수 있습니다. 추가 오류는 DID Resolution Extensions [DID-EXTENSIONS-RESOLUTION]에 등록되는 것이 SHOULD됩니다.

proof

일부 DID 확인자와 DID URL 역참조자는 DID 확인 또는 DID URL 역참조 함수를 실행할 때 증명을 사용합니다. 자세한 내용은 8.2 확인자 아키텍처를 참조하십시오.

DID 확인 메타데이터는 proof 속성을 포함할 MAY 수 있습니다. 존재하는 경우, 값은 각 항목이 증명을 나타내는 맵인 집합이어야 MUST 합니다. 이 속성의 사용과 증명 유형은 DID 메서드와 독립적입니다.

이는 DID 확인 과정에 대한 메타데이터를 포함하는 메타데이터 구조입니다.

이 메타데이터는 DID 문서에 대한 데이터를 나타내므로, DID 문서가 변경되지 않는 한 일반적으로 DID 확인 함수 호출 사이에 변경되지 않습니다.

이 메타데이터의 출처는 DID 제어자 및/또는 DID 메서드입니다. DID 제어자가 증명한 DID 문서 메타데이터에는 정확성에 대한 본질적인 보장이 없습니다. 클라이언트는 DID 문서 메타데이터에 의존하여 비즈니스 로직을 판단할 때 주의해서 진행하는 것이 권고됩니다.

DID 문서 메타데이터의 예는 다음과 같습니다.

• DID 및 그 관련 DID 문서가 생성되거나 갱신된 시점의 타임스탬프(예: created, updated, nextUpdate).
• DID 문서에 대한 버전 관리 정보(예: versionId, nextVersionId).
• DID 제어자가 추가했거나 DID 메서드의 검증 가능 데이터 레지스트리가 생성한 증명. 이는 제어 권한을 수립하거나 검증 가능 확인을 가능하게 하는 데 사용될 수 있습니다 (예: proof).
• 제어자, 기능, 위임 등에 대한 메타데이터.
• 블록체인 또는 기타 검증 가능 데이터 레지스트리의 레코드에 대한 블록 번호, 인덱스, 트랜잭션 해시, 확인 수 등과 같은 메서드별 메타데이터.

이 구조 안의 가능한 속성과 그 가능한 값은 DID Document Properties Extensions [DID-EXTENSIONS-PROPERTIES]에 등록되는 것이 SHOULD됩니다. 이 사양은 다음의 공통 메타데이터 속성을 정의합니다.

created

DID 문서 메타데이터는 Create 작업의 타임스탬프를 나타내기 위해 created 속성을 포함하는 것이 SHOULD됩니다. 이 속성의 값은 3.1 날짜시간에 정의된 날짜시간 형식으로 표현되어야 MUST 합니다.

updated

DID 문서 메타데이터는 확인된 문서 버전에 대한 마지막 Update 작업의 타임스탬프를 나타내기 위해 updated 속성을 포함하는 것이 SHOULD됩니다. 이 속성의 값은 3.1 날짜시간에 정의된 날짜시간 형식으로 표현되어야 MUST 합니다. DID 문서에 대해 Update 작업이 수행된 적이 없는 경우 updated 속성은 생략됩니다. updated 속성이 존재하는 경우, 두 타임스탬프의 차이가 1초 미만이면 created 속성과 같은 값일 수 있습니다.

deactivated

DID가 비활성화된 경우, DID 문서 메타데이터는 이 속성을 불리언 값 true와 함께 포함해야 MUST 합니다. DID가 비활성화되지 않은 경우, 이 속성은 OPTIONAL이지만, 포함되는 경우 불리언 값 false를 가져야 MUST 합니다.

nextUpdate

확인된 문서 버전이 문서의 최신 버전이 아닌 경우, DID 문서 메타데이터는 nextUpdate 속성을 포함할 MAY 수 있습니다. 이는 다음 Update 작업의 타임스탬프를 나타냅니다. 이 속성의 값은 3.1 날짜시간에 정의된 날짜시간 형식으로 표현되어야 MUST 합니다.

versionId

DID 문서 메타데이터는 확인된 문서 버전에 대한 마지막 Update 작업의 버전을 나타내기 위해 versionId 속성을 포함하는 것이 SHOULD됩니다. 이 속성의 값은 ASCII 문자열이어야 MUST 합니다.

nextVersionId

확인된 문서 버전이 문서의 최신 버전이 아닌 경우, DID 문서 메타데이터는 nextVersionId 속성을 포함할 MAY 수 있습니다. 이는 다음 Update 작업의 버전을 나타냅니다. 이 속성의 값은 ASCII 문자열이어야 MUST 합니다.

equivalentId

DID 메서드는 논리적으로 동등한 DID의 서로 다른 형태를 정의할 수 있습니다. 예를 들어, DID가 검증 가능 데이터 레지스트리에 등록되기 전에는 한 형태를 취하고, 그러한 등록 후에는 다른 형태를 취하는 경우가 있습니다. 이 경우, DID 메서드 사양은 확인된 DID와 논리적으로 동등한 하나 이상의 DID를 DID 문서의 속성으로 표현해야 할 수 있습니다. 이것이 equivalentId 속성의 목적입니다.

DID 문서 메타데이터는 equivalentId 속성을 포함할 MAY 수 있습니다. 존재하는 경우, 값은 각 항목이 문자열이며 탈중앙화 식별자(DID) v1.0 절의 규칙을 준수하는 집합이어야 MUST 합니다. 이 관계는 각각의 equivalentId 값이 id 속성 값과 논리적으로 동등하므로 동일한 DID 주체를 참조한다는 진술입니다. 각 equivalentId DID 값은 id 속성 값과 동일한 DID 메서드에 의해 생성되어야 MUST 하며, 그 형태여야 합니다. (예: did:example:abc == did:example:ABC)

준수 DID 메서드 사양은 각 equivalentId 값이 id 속성 값과 논리적으로 동등함을 보장해야 MUST 합니다.

요청 당사자는 이후에 이들이 포함하는 어떤 값과 상호작용하더라도 논리적으로 동등하게 올바르게 처리되도록, id 및 equivalentId 속성의 값을 유지할 것으로 기대됩니다 (예: 데이터베이스에 모든 변형을 보존하여 그중 하나와의 상호작용이 동일한 기본 계정에 매핑되도록 함).

참고: 더 강한 동등성

equivalentId는 alsoKnownAs보다 훨씬 더 강한 형태의 동등성입니다. 이는 그 동등성이 지배하는 DID 메서드에 의해 보장되어야 MUST 하기 때문입니다. equivalentId의 사용은 동일한 DID 문서가 equivalentId DID와 id 속성 DID를 모두 설명한다는 것을 의미합니다.

요청 당사자가 id 및 equivalentId 속성의 값을 유지하지 않고, 이들이 포함하는 어떤 값과의 이후 상호작용도 논리적으로 동등하게 올바르게 처리되도록 보장하지 않는 경우, 부정적이거나 예상치 못한 문제가 발생할 수 있습니다. 구현자는 이 메타데이터 속성과 관련된 지시사항을 준수할 것을 강력히 권고받습니다.

canonicalId

canonicalId 속성은 다음을 제외하고 equivalentId 속성과 동일합니다. a) 집합이 아니라 단일 값과 연결되며, b) DID가 포함하는 DID 문서의 범위 내에서 DID 주체에 대한 정준 ID로 정의됩니다.

DID 문서 메타데이터는 canonicalId 속성을 포함할 MAY 수 있습니다. 존재하는 경우, 값은 문자열이어야 MUST 하며, 탈중앙화 식별자(DID) v1.0 절의 규칙을 준수해야 합니다. 이 관계는 canonicalId 값이 id 속성 값과 논리적으로 동등하며, 그 canonicalId 값이 DID 메서드에 의해, 포함하는 DID 문서의 범위 안에서 DID 주체의 정준 ID로 정의된다는 진술입니다. canonicalId 값은 id 속성 값과 동일한 DID 메서드에 의해 생성되어야 MUST 하며, 그 형태여야 합니다. (예: did:example:abc == did:example:ABC).

준수 DID 메서드 사양은 canonicalId 값이 id 속성 값과 논리적으로 동등함을 보장해야 MUST 합니다.

요청 당사자는 canonicalId 값을 DID 주체에 대한 기본 ID 값으로 사용하고, 다른 모든 동등한 값을 보조 별칭으로 취급할 것으로 기대됩니다(예: 시스템의 해당 기본 참조를 갱신하여 새 정준 ID 지시사항을 반영).

참고: 정준 동등성

canonicalId는 equivalentId와 동일한 동등성 진술이지만, DID 주체에 대해 DID 문서의 범위 안에서 정준으로 정의된 단일 값으로 제한된다는 점이 다릅니다. equivalentId와 마찬가지로, canonicalId의 사용은 동일한 DID 문서가 canonicalId DID와 id 속성 DID를 모두 설명한다는 것을 의미합니다.

확인 당사자가 canonicalId 값을 DID 주체에 대한 기본 ID 값으로 사용하고, 다른 모든 동등한 값을 보조 별칭으로 취급하지 않는 경우, 사용자 경험과 관련하여 부정적이거나 예상치 못한 문제가 발생할 수 있습니다. 구현자는 이 메타데이터 속성과 관련된 지시사항을 준수할 것을 강력히 권고받습니다.

proof

많은 DID 메서드는 메서드 작업을 실행할 때 증명을 사용합니다. 자세한 내용은 8.1 메서드 아키텍처를 참조하십시오.

DID 문서 메타데이터는 proof 속성을 포함할 MAY 수 있습니다. 존재하는 경우, 값은 각 항목이 증명을 나타내는 맵인 집합이어야 MUST 합니다. 이 속성의 사용과 증명 유형은 DID 메서드별입니다.

DID 확인자는 다음 DID 확인 알고리즘을 구현합니다.

1. 입력 DID가 DID 구문의 did 규칙을 준수하는지 검증합니다. 그렇지 않으면, DID 확인자는 다음 결과를 반환해야 MUST 합니다.
   1. didResolutionMetadata: type이 https://www.w3.org/ns/did#INVALID_DID로 설정된 오류 객체
   2. didDocument: null
   3. didDocumentMetadata: «[ ]»
2. 입력 DID의 DID 메서드가 이 알고리즘을 구현하는 DID 확인자에 의해 지원되는지 결정합니다. 그렇지 않으면, DID 확인자는 다음 결과를 반환해야 MUST 합니다.
   1. didResolutionMetadata: type이 https://www.w3.org/ns/did#METHOD_NOT_SUPPORTED로 설정된 오류 객체
   2. didDocument: null
   3. didDocumentMetadata: «[ ]»
3. 입력 DID 확인 옵션이 이 알고리즘을 구현하는 DID 확인자에 의해 지원되는지 결정합니다. 그렇지 않으면, DID 확인자는 다음 결과를 반환해야 MUST 합니다.
   1. didResolutionMetadata: type이 https://www.w3.org/ns/did#FEATURE_NOT_SUPPORTED로 설정된 오류 객체
   2. didDocument: null
   3. didDocumentMetadata: «[ ]»
4. 입력 DID 확인 옵션이 유효한지 결정합니다. 그렇지 않으면, DID 확인자는 다음 결과를 반환해야 MUST 합니다.
   1. didResolutionMetadata: type이 https://www.w3.org/ns/did#INVALID_OPTIONS로 설정된 오류 객체
   2. didDocument: null
   3. didDocumentMetadata: «[ ]»
5. 입력 DID에 대한 DID 문서를 입력 DID 메서드가 정의한 대로 Resolve 작업을 실행하여 얻습니다.
   1. 입력 DID가 존재하지 않는 경우, 다음 결과를 반환합니다.
      1. didResolutionMetadata: type이 https://www.w3.org/ns/did#NOT_FOUND로 설정된 오류 객체
      2. didDocument: null
      3. didDocumentMetadata: «[ ]»
   2. 입력 DID가 비활성화된 경우, 다음 결과를 반환합니다.
      1. didResolutionMetadata: «[ ... ]»
      2. didDocument: null
      3. didDocumentMetadata: «[ "deactivated" → true, ... ]»
   3. 그렇지 않으면, Resolve 작업의 결과를 출력 DID 문서라고 합니다. 이 결과는 준수 표현으로 표현되어야 MUST 합니다.
6. 입력 DID 확인 옵션이 값이 true인 expandRelativeUrls 옵션을 포함하는 경우:
   1. 출력 DID 문서의 모든 서비스, 검증 메서드, 검증 관계 및 확장 정의 속성을 순회합니다.
   2. 각 항목에 대해, 항목이 객체이고 id 속성의 값이 상대 DID URL이거나, 검증 관계가 상대 DID URL인 경우:
      1. 탈중앙화 식별자(DID) v1.0의 상대 DID URL 절의 규칙에 따라, 상대 DID URL을 DID URL 구문을 준수하는 절대 DID URL로 확인합니다.
   3. 상대 DID URL을 확인된 절대 DID URL로 대체하여 출력 DID 문서를 갱신합니다.
7. 다음 결과를 반환합니다.
   1. didResolutionMetadata: «[ ... ]»
   2. didDocument: 출력 DID 문서
   3. didDocumentMetadata: «[ "contentType" → 출력 DID 문서 미디어 유형, ... ]»

DID 확인자가 DID 확인 알고리즘 실행 중 예기치 않은 오류를 만난 경우, 다음 결과를 반환해야 MUST 합니다.

1. didResolutionMetadata: type이 https://www.w3.org/ns/did#INTERNAL_ERROR로 설정된 오류 객체
2. didDocument: null
3. didDocumentMetadata: «[ ]»

이는 DID URL 역참조 과정을 위한 입력 옵션을 포함하는 메타데이터 구조입니다.

이 구조 안의 가능한 속성과 그 가능한 값은 DID Resolution Extensions [DID-EXTENSIONS-RESOLUTION]에 등록되는 것이 SHOULD됩니다. 이 사양은 다음의 공통 입력 옵션을 정의합니다.

accept

호출자가 contentStream에 대해 선호하는 미디어 유형입니다. 값은 HTTP Semantics 제12.5.1절에 정의된 Accept 헤더 값에 따라 표현되어야 MUST 합니다. DID URL 역참조자 구현은 그러한 표현이 지원되고 사용 가능한 경우, 반환된 값에 포함된 표현의 contentType을 결정하기 위해 이 값을 사용해야 SHOULD 합니다.

verificationRelationship

호출자가 DID URL에서 역참조된 verificationMethod가 권한을 부여받았다고 기대하는 verificationRelationship입니다. 존재하는 경우, 관련 값은 ASCII 문자열이어야 MUST 합니다. DID URL이 verificationMethod로 역참조되지 않거나, DID 문서가 지정된 verificationRelationship에 대해 verificationMethod를 권한 부여하지 않는 경우, 오류가 발생해야 MUST 합니다.

이는 DID URL 역참조 과정에 대한 메타데이터를 포함하는 메타데이터 구조입니다.

이 메타데이터는 역참조 과정 자체에 대한 데이터를 나타내므로, 일반적으로 DID URL 역참조 함수 호출 사이에 변경됩니다.

이 메타데이터의 출처는 DID URL 역참조자입니다.

이 구조 안의 가능한 속성과 그 가능한 값은 DID Resolution Extensions [DID-EXTENSIONS-RESOLUTION]에 등록되는 것이 SHOULD됩니다. 이 사양은 다음의 공통 메타데이터 속성을 정의합니다.

contentType

역참조가 성공한 경우 반환된 contentStream의 미디어 유형은 이 속성을 사용하여 표현되는 것이 SHOULD됩니다. 미디어 유형 값은 ASCII 문자열로 표현되어야 MUST 합니다.

error

[RFC9457]에 정의된 오류 데이터 구조입니다. 이 속성은 역참조 과정에서 오류가 있는 경우 REQUIRED입니다. 이 사양에서 정의한 오류는 11. 오류 절에서 찾을 수 있습니다. 추가 오류는 DID Resolution Extensions [DID-EXTENSIONS-RESOLUTION]에 등록되는 것이 SHOULD됩니다.

proof

일부 DID 확인자 및 DID URL 역참조자는 DID 확인 또는 DID URL 역참조 함수를 실행할 때 증명을 사용합니다. 자세한 내용은 8.2 확인자 아키텍처를 참조하십시오.

DID URL 역참조 메타데이터는 proof 속성을 포함할 MAY 수 있습니다. 존재하는 경우, 값은 각 항목이 증명을 나타내는 맵인 집합이어야 MUST 합니다. 이 속성의 사용과 증명 유형은 DID 메서드와 독립적입니다.

이는 DID URL 역참조 과정에 대한 메타데이터를 포함하는 메타데이터 구조입니다.

이 메타데이터는 콘텐츠에 대한 데이터를 나타내므로, 콘텐츠가 변경되지 않는 한 일반적으로 DID URL 역참조 함수 호출 사이에 변경되지 않습니다.

이 메타데이터의 출처는 DID 제어자 및/또는 DID 메서드입니다.

이 구조 안의 가능한 속성과 그 가능한 값은 DID Resolution Extensions [DID-EXTENSIONS-RESOLUTION]에 등록되는 것이 SHOULD됩니다. 이 사양은 공통 속성을 정의하지 않습니다.

DID URL 역참조자는 다음 DID URL 역참조 알고리즘을 구현합니다. [RFC3986]에 따라, 이 알고리즘은 다음 세 단계로 구성됩니다. DID 확인, 리소스 역참조, 그리고 프래그먼트 역참조(단, 입력 DID URL에 DID 프래그먼트가 포함된 경우에만):

DID 확인 알고리즘은 DID에 대해 그 DID 메서드에 따라 Resolve 작업을 실행하는 것을 포함합니다 (4. DID 확인 참조).

모든 DID 메서드는 이 메서드 작업, 즉 DID 확인자가 DID에서 DID 문서를 얻을 수 있는 방법을 정의합니다. 기본 데이터 형식, 프로토콜, 기술 인프라 및 과정은 DID 메서드마다 상당히 다를 수 있습니다.

DID 메서드 고려사항의 예는 다음과 같습니다.

• DID 메서드는 불변 블록체인, 분산 원장, 분산 파일 시스템, 피어 투 피어 네트워크 또는 기타 탈중앙화 인프라를 그 검증 가능 데이터 레지스트리의 일부 또는 전체로 사용할 수 있습니다.
• DID 메서드는 DNS, HTTP 또는 웹 서버를 그 검증 가능 데이터 레지스트리의 일부 또는 전체로 사용할 수 있습니다.
• DID 메서드는 위 기술 인프라의 임의의 조합을 사용할 수 있습니다.
• DID 메서드는 실제 DID 문서를 평문 형태로 검증 가능 데이터 레지스트리에 저장하고, "Resolve" 작업 중 해당 문서를 단순히 검색할 수 있습니다.
• DID 메서드는 "Resolve" 작업을 더 복잡한 방식으로 정의할 수 있으며, 이는 중간적, 부분적 또는 임시적인 DID 문서를 포함하고, DID 문서를 "즉석에서" 구성하는 다단계 과정을 사용할 수 있습니다.
• DID 메서드는 "Resolve" 작업 실행 중 원격 서버나 네트워크와의 상호작용을 요구할 수 있습니다.
• DID 메서드는 원격 서버나 네트워크와의 상호작용을 전혀 요구하지 않는 완전히 로컬 방식으로 "Resolve" 작업을 실행할 수 있습니다. 예를 들어, [DID-KEY] 메서드에서는 DID 자체가 공개 키를 감싸며, "Resolve" 작업은 단순하고 사소한 로컬 변환 과정입니다.

위 고려사항과 DID 메서드의 "Resolve" 작업의 성격을 함께 고려하면, DID 확인자와 검증 가능 데이터 레지스트리 사이의 상호작용은 검증 가능 확인 또는 검증 불가능 확인으로 간주될 수 있습니다.

검증 가능 확인은 적용 가능한 DID 메서드 아래에서 가능한 범위까지 "Resolve" 작업 결과의 무결성과 정확성에 대한 신뢰를 극대화합니다. 이는 다음과 같은 여러 방법으로 달성될 수 있습니다.

• 검증 가능 확인은 검증 가능 데이터 레지스트리에 로컬의 신뢰할 수 있는 네트워크 환경에서 접근할 수 있는 경우 달성될 수 있습니다.
  • 예를 들어, 블록체인 기반 DID 메서드에서는 블록체인 풀 노드가 로컬 서버에 배포되어 있다면 검증 가능 확인이 달성될 수 있습니다.
• 검증 가능 데이터 레지스트리에 대한 접근이 원격 서버를 통해 이루어지는 경우에도, 해당 원격 서버가 신뢰할 수 있고 보안 채널을 통해 접근할 수 있다면 검증 가능 확인이 달성될 수 있습니다.
• 검증 가능 데이터 레지스트리에 대한 접근이 원격 서버를 통해 이루어지는 경우, 검증 가능 확인은 DID 확인자가 DID 메서드가 반환한 DID 문서와 DID 문서 메타데이터를 검증할 수 있는 방법을 가지고 있다면 달성될 수 있습니다.
  • 예를 들어, 블록체인 기반 DID 메서드에서는 블록체인 풀 노드에 직접 접근할 수 없더라도, 데이터를 검증하기 위해 메타데이터를 처리하는 라이트 클라이언트를 사용하면 검증 가능 확인이 여전히 가능할 수 있습니다.

검증 불가능 확인은 그러한 보장을 갖지 않으므로 덜 바람직합니다. 예를 들어 다음과 같습니다.

• 검증 불가능 확인은 검증 가능 데이터 레지스트리에 대한 접근이 원격의 신뢰할 수 없는 중개자를 통해 이루어지는 경우 발생합니다.
  • 예를 들어, 블록체인 기반 DID 메서드의 경우, 제3자가 운영하는 원격 블록체인 탐색기 API가 블록체인에서 데이터를 조회하는 데 사용될 수 있습니다.

검증 가능 확인을 가능하게 하기 위해 많은 DID 메서드는 디지털 서명, 상태 증명, Merkle 트리 포함 증명, 암호학적 이벤트 로그 또는 기타 유형의 증명을 사용합니다. DID 메서드가 그러한 증명을 사용하는 경우, 그 DID 메서드 사양에서 "Resolve" 작업 결과의 정확성을 검증하기 위해 증명이 어떻게 사용되는지 지정해야 MUST 합니다.

DID 메서드는 그러한 증명을 DID 문서 자체에 포함하거나, DID 문서 메타데이터의 proof 속성에 포함할 MAY 수도 있습니다. 이는 클라이언트가 DID 확인 과정의 결과를, DID 확인자를 신뢰하지 않더라도 독립적으로 검증할 수 있게 할 가능성이 있습니다.

DID 메서드에서 비롯된 증명은 DID 메서드별이며, 적용 가능한 DID 메서드의 기술 안에서 이해되어야 합니다. DID 문서 또는 DID 문서 메타데이터에 대한 단순한 서명이 반드시 DID의 제어를 증명하거나, DID 문서가 해당 DID에 대해 올바른 것임을 보장하지는 않습니다. 이러한 증명은 DID 확인 과정 결과의 무결성과 진정성을 DID 메서드 자체와 관련된 범위에서 검증하는 데 도움이 됩니다. 그러나 이는 클라이언트와 DID 확인자 사이의 바인딩이 안전하다는 것을 보장하지 않습니다. 8.2 확인자 아키텍처도 참조하십시오.

DID 확인과 DID URL 역참조 알고리즘은 추상 함수로 정의됩니다 (4. DID 확인 및 5. DID URL 역참조 참조).

이러한 알고리즘은 DID 확인자와 DID URL 역참조자에 의해 구현되며, 클라이언트가 바인딩을 통해 호출합니다. 바인딩은 구체적인 프로그래밍 또는 통신 인터페이스를 사용하여 추상 함수에 접근하는 방식을 정의합니다.

바인딩의 예는 다음과 같습니다.

• DID 확인자는 소프트웨어 라이브러리나 SDK를 호출함으로써 애플리케이션 안에서 호출될 수 있습니다.
• DID 확인자는 명령줄 도구로 호출될 수 있습니다.
• DID 확인자는 HTTP(S) API 또는 기타 네트워크 프로토콜을 통해 호출될 수 있습니다. 예: 12.1 HTTP(S) 바인딩 참조.

위 고려사항과 바인딩의 성격을 함께 고려하면, 클라이언트와 DID 확인자 또는 DID URL 역참조자 사이의 상호작용은 로컬 바인딩 또는 원격 바인딩으로 간주될 수 있습니다.

가능한 경우 로컬 바인딩이 선호됩니다. 이는 제3자와 중개자에 대한 의존성을 최소화하고, 보안 위험을 줄이며, DID 확인 및 DID URL 역참조 함수 결과의 무결성과 정확성에 대한 신뢰를 극대화하기 때문입니다.

어떤 경우에는 로컬 바인딩을 사용할 수 없을 수도 있습니다. 예를 들어, 제한된 IoT(사물 인터넷) 환경이거나, DID 메서드가 복잡한 인프라를 요구하거나, 다양한 DID 메서드를 지원해야 하는 경우가 그렇습니다.

클라이언트가 원격 바인딩을 사용하는 경우, 다음 고려사항이 적용됩니다.

• 원격 바인딩은 신뢰할 수 있는 DID 확인자 인스턴스를 사용하는 것이 SHOULD되며, 이상적으로는 클라이언트 자체의 제어 아래에 있어야 합니다(예: 자체 호스팅).
• 원격 바인딩은 VPN 및/또는 상호 인증을 사용하는 TLS 같은 보안 채널을 사용하는 것이 SHOULD됩니다.
• 클라이언트는 원격 바인딩을 통해 여러 DID 확인자에 질의하고 결과를 비교할 수 있습니다.

DID 확인자는 DID 확인 메타데이터의 proof 속성에 증명을 포함할 MAY 수도 있습니다.

DID 확인자에서 비롯된 증명은 DID 메서드와 독립적이며, 모든 DID 메서드 전반에서 DID 확인자에 의해 보편적으로 적용될 수 있습니다. 이러한 증명은 DID 확인 과정 결과의 무결성과 진정성을 DID 확인자 자체와 관련된 범위에서 검증하는 데 도움이 됩니다. 그러나 이는 적용 가능한 DID 메서드의 "Resolve" 작업 결과 자체가 올바르다는 것을 보장하지 않습니다. 8.1 메서드 아키텍처도 참조하십시오.

8.2.1 여러 메서드

DID 확인자는 여러 DID 메서드에 대해 DID 확인 알고리즘을 지원할 수 있습니다.

이 경우, 8.1 메서드 아키텍처의 검증 가능 확인 및 검증 불가능 확인 구현에 관한 위 고려사항은 지원되는 각 DID 메서드에 개별적으로 적용됩니다.

8.2.2 프록시된 확인

DID 확인자는 4. DID 확인에 정의된 DID 확인 알고리즘을 실행하는 프록시 역할을 하는 다른 DID 확인자를 호출할 MAY 수 있습니다.

그런 다음 첫 번째 DID 확인자는 클라이언트로 동작하며, 두 번째 DID 확인자를 호출하기 위한 적절한 바인딩을 선택합니다. 예를 들어, DID 확인자는 명령줄 도구 같은 로컬 바인딩을 통해 호출될 수 있고, 이어서 다른 DID 확인자를 원격 바인딩(예: HTTP(S) 바인딩)을 통해 호출할 수 있습니다.

프록시된 확인을 사용할 때, "다운스트림" 확인자는 "업스트림" 확인자로부터 온 모든 DID 확인 메타데이터와 DID 문서 메타데이터를 존재할 수 있는 증명을 포함하여 투명한 방식으로 보존하는 것이 SHOULD됩니다. 이 과정에서 "다운스트림" 확인자는 프록시된 확인 과정 자체에 대한 메타데이터를 포함하여 자신의 DID 확인 메타데이터를 추가할 MAY 수 있습니다.

참고: DNS와의 비교

이는 DNS 아키텍처에서 "스텁 확인자"가 "재귀 확인자"를 호출하는 것과 유사하지만, 개념이 완전히 비교 가능한 것은 아닙니다(DNS 확인은 하나의 구체적인 프로토콜을 사용하는 반면, DID 확인은 서로 다른 DID 메서드와 서로 다른 바인딩에 의해 실현되는 추상 함수입니다).

DID URL did:xyz:1234#keys-1이 주어졌을 때, DID 확인자는 리소스 역참조 (즉, DID 문서)를 위해 로컬 바인딩을 통해 호출될 수 있고, 클라이언트는 프래그먼트 역참조 (즉, DID 문서의 일부)를 통해 DID URL 역참조 알고리즘을 완료할 수 있습니다.

DID URL did:xyz:1234?service=agent&relativeRef=%2Fsome%2Fpath%3Fquery#frag이 주어졌을 때, DID 확인자는 리소스 역참조 (즉, DID 서비스 엔드포인트 URL)를 위해 호출될 수 있고, 클라이언트는 프래그먼트 역참조 (즉, 프래그먼트가 있는 DID 서비스 엔드포인트 URL)를 통해 DID URL 역참조 알고리즘을 완료할 수 있습니다.

DID URL did:xyz:1234#keys-1이 주어졌을 때, DID 확인자는 로컬 바인딩을 통해 호출될 수 있고, 이는 다시 리소스 역참조 (즉, DID 문서)를 위해 원격 바인딩을 통해 다른 DID 확인자를 호출하며, 클라이언트는 프래그먼트 역참조 (즉, DID 문서의 일부)를 통해 DID URL 역참조 알고리즘을 완료할 수 있습니다.

이 절은 DID 확인 및/또는 DID URL 역참조 함수 (모든 확인/역참조 옵션과 메타데이터 포함)를 HTTP(S) 엔드포인트를 통해 노출하는 DID 확인자 바인딩을 정의합니다. 8.2 확인자 아키텍처를 참조하십시오.

HTTP(S) 바인딩에는 DID 확인자를 호출할 수 있는 알려진 HTTP(S) URL이 필요합니다. 이 URL을 DID 확인자 HTTP(S) 엔드포인트라고 합니다.

이 바인딩은 일반적으로 원격 바인딩으로 간주되지만, HTTP(S) 엔드포인트가 localhost와 같은 로컬 환경에서 실행되는 경우 로컬 바인딩일 수도 있습니다.

모든 준수 네트워크 기반 DID 확인자는 HTTPS 바인딩의 GET 버전을 구현해야 MUST 하며, POST 버전을 구현할 MAY 수 있습니다. 모든 HTTPS 바인딩은 TLS를 사용해야 MUST 합니다. 인증서에서 DNS 이름을 사용하는 것은 NOT REQUIRED입니다. 확인자는 IP 주소용으로 발급된 TLS 인증서를 사용할 MAY 수 있습니다.

이 바인딩을 사용하면 4. DID 확인을 참조하는 DID 확인 함수 및/또는 5. DID URL 역참조를 참조하는 DID URL 역참조 함수는 다음과 같이 실행될 수 있습니다.

1. 요청 HTTP(S) URL을 DID 확인자 HTTP(S) 엔드포인트로 초기화합니다.
   예시 23

   https://resolver.example/1.0/identifiers/

2. DID 확인 함수의 경우:
   1. 입력 DID를 요청 HTTP(S) URL에 추가합니다.
      예시 24

      https://resolver.example/1.0/identifiers/did:example:1234

   2. 완전한 9. DID 확인 결과를 요청하려면 Accept HTTP 요청 헤더를 application/did-resolution으로 설정하거나, 또는
   3. 결과의 didDocument 값만 요청하려면 Accept HTTP 요청 헤더를 accept 확인 옵션의 값으로 설정합니다.
3. DID URL 역참조 함수의 경우:
   1. 입력 DID URL을 요청 HTTP(S) URL에 추가합니다.
      예시 25

      https://resolver.example/1.0/identifiers/did:example:1234?service=files&relativeRef=/resume.pdf

   2. 완전한 10. DID URL 역참조 결과를 요청하려면 Accept HTTP 요청 헤더를 application/did-url-dereferencing으로 설정하거나, 또는
   3. 결과의 contentStream 값만 요청하려면 Accept HTTP 요청 헤더를 accept 역참조 옵션의 값으로 설정합니다.
4. HTTP(S) GET 바인딩의 경우:
   1. accept 이외의 다른 확인 옵션 또는 역참조 옵션이 제공된 경우:
      1. 입력 DID는 (RFC3986 제2.1절에 지정된 대로) URL 인코딩되어야 MUST 합니다.
      2. accept를 제외한 모든 확인 옵션을 요청 HTTP(S) URL의 쿼리 매개변수로 인코딩합니다.
   2. 요청 HTTP(S) URL에 대해 HTTP GET 요청을 실행합니다. 이는 원격 DID 확인자에서 DID 확인 또는 DID URL 역참조 함수를 호출합니다.
      예시 26

      GET https://resolver.example/1.0/identifiers/did%3Aexample%3A1234?option1=value1&option2=value2 HTTP/1.1
      Accept: application/did-resolution

      예시 27

      GET https://resolver.example/1.0/identifiers/did%3Aexample%3A1234%3Fservice%3Dfiles%26relativeRef%3D%2Fresume.pdf?option1=value1&option2=value2 HTTP/1.1
      Accept: application/did-url-dereferencing

5. HTTP(S) POST 바인딩의 경우:
   1. accept 이외의 다른 확인 옵션 또는 역참조 옵션이 제공된 경우:
      1. accept를 제외한 모든 확인 옵션을 HTTP 요청의 POST 본문에 JSON 구조로 인코딩합니다.
   2. 요청 HTTP(S) URL에 대해 HTTP POST 요청을 실행합니다. 이는 원격 DID 확인자에서 DID 확인 또는 DID URL 역참조 함수를 호출합니다.
      예시 28

      POST https://resolver.example/1.0/identifiers/did:example:1234 HTTP/1.1
      Accept: application/did-resolution
      
      {
      "option1": "value1",
      "option2": "value2"
      }

      예시 29

      POST https://resolver.example/1.0/identifiers/did:example:1234?service=files&relativeRef=/resume.pdf HTTP/1.1
      Accept: application/did-url-dereferencing
      
      {
      "option1": "value1",
      "option2": "value2"
      }

6. DID 확인 또는 DID URL 역참조 함수가 didResolutionMetadata 또는 dereferencingMetadata 안에 error 메타데이터 속성을 반환하는 경우, HTTP 응답 상태 코드는 다음 표에 따라 error object의 type 속성에 대응해야 MUST 합니다.

   error type URI	HTTP 상태 코드
   https://www.w3.org/ns/did#INVALID_DID	400
   https://www.w3.org/ns/did#INVALID_DID_URL	400
   https://www.w3.org/ns/did#INVALID_OPTIONS	400
   https://www.w3.org/ns/did#NOT_FOUND	404
   https://www.w3.org/ns/did#REPRESENTATION_NOT_SUPPORTED	406
   https://www.w3.org/ns/did#INVALID_DID_DOCUMENT	500
   https://www.w3.org/ns/did#METHOD_NOT_SUPPORTED	501
   https://www.w3.org/ns/did#FEATURE_NOT_SUPPORTED	501
   https://www.w3.org/ns/did#INTERNAL_ERROR	500
   (기타 모든 오류 URI)	500

7. DID 확인 또는 DID URL 역참조 함수가 didDocumentMetadata 또는 contentMetadata 안에 값이 true인 deactivated 메타데이터 속성을 반환하는 경우:
   1. HTTP 응답 상태 코드는 410이어야 MUST 합니다.
8. DID 확인 함수의 경우:
   1. Content-Type HTTP 응답 헤더의 값이 application/did-resolution인 경우:
      1. HTTP 본문은 DID 확인 함수의 결과인 DID 확인 결과(9. DID 확인 결과 참조)를 포함해야 MUST 합니다.
   2. 함수가 성공하고 didDocument를 반환하는 경우:
      1. HTTP 응답 상태 코드는 200이어야 MUST 합니다.
      2. HTTP 응답은 Content-Type HTTP 응답 헤더를 포함해야 MUST 합니다. 그 값은 didResolutionMetadata 안의 contentType 메타데이터 속성 값이어야 MUST 합니다(4.2 DID 확인 메타데이터 참조).
      3. HTTP 응답 본문은 DID 확인 함수의 결과인 didDocument를 Content-Type HTTP 응답 헤더에 해당하는 표현으로 포함해야 MUST 합니다.
9. DID URL 역참조 함수의 경우:
   1. Content-Type HTTP 응답 헤더의 값이 application/did-url-dereferencing인 경우:
      1. HTTP 본문은 DID URL 역참조 함수의 결과인 DID URL 역참조 결과 (10. DID URL 역참조 결과 참조)를 포함해야 MUST 합니다.
   2. 함수가 성공하고, dereferencingMetadata 안에 값이 text/uri-list인 contentType 메타데이터 속성과 contentStream을 반환하는 경우:
      1. HTTP 응답 상태 코드는 303이어야 MUST 합니다.
      2. HTTP 응답은 Location 헤더를 포함해야 MUST 합니다. 이 헤더의 값은 선택된 DID 서비스 엔드포인트 URL이어야 MUST 합니다.
      3. HTTP 응답 본문은 비어 있어야 MUST 합니다.
   3. 함수가 성공하고 다른 contentType을 가진 contentStream을 반환하는 경우:
      1. HTTP 응답 상태 코드는 200이어야 MUST 합니다.
      2. HTTP 응답은 Content-Type HTTP 응답 헤더를 포함해야 MUST 합니다. 그 값은 dereferencingMetadata 안의 contentType 메타데이터 속성 값이어야 MUST 합니다(5.2 DID URL 역참조 메타데이터 참조).
      3. HTTP 응답 본문은 DID URL 역참조 함수의 결과인 contentStream을 Content-Type HTTP 응답 헤더에 해당하는 표현으로 포함해야 MUST 합니다.

다음 DID 확인자 HTTP(S) 엔드포인트가 주어졌다고 하겠습니다.

https://resolver.example/1.0/identifiers/

그리고 다음 입력 DID가 주어졌다고 하겠습니다.

did:example:123

그러면 요청 HTTP(S) URL은 다음과 같습니다.

https://resolver.example/1.0/identifiers/did:example:123

GET https://resolver.example/1.0/identifiers/did:example:123 HTTP/1.1
Accept: application/did-resolution

HTTP 200 OK
Content-Type: application/did-resolution

{
	"didDocument": {
		"@context": [ "https://www.w3.org/ns/did/v1.1" ],
		"id": "did:example:123",
		"verificationMethod": [{
			...
		}],
		"service": [{
			...
		}]
	},
	"didResolutionMetadata": {
		"contentType": "application/did"
	},
	"didDocumentMetadata": {
		...
	}
}

GET https://resolver.example/1.0/identifiers/did:example:123 HTTP/1.1
Accept: application/did

HTTP 200 OK
Content-Type: application/did

{
	"@context": [ "https://www.w3.org/ns/did/v1.1" ],
	"id": "did:example:123",
	"verificationMethod": [{
		...
	}],
	"service": [{
		...
	}]
}

DID 확인과 DID URL 역참조에는 어떠한 인증 또는 인가 기능도 포함되지 않습니다. DNS 확인과 유사하게, 누구나 자격 증명이나 비공개 지식을 요구받지 않고 이 과정을 수행할 수 있습니다.

DID 확인자는 DID 문서의 일반 캐시를 유지할 수 있습니다. 또한 특정 DID 메서드에 특화된 캐시를 유지할 수도 있습니다.

noCache 확인 옵션은 특정 종류의 캐싱 동작을 요청하는 데 사용할 수 있습니다.

이 확인 옵션은 OPTIONAL입니다.

이 속성의 가능한 값은 다음과 같습니다.

• "false" (기본값): DID 문서의 캐싱이 허용됩니다.
• "true": 캐싱을 비활성화하고 DID 문서를 검증 가능 데이터 레지스트리에서 새로 검색하도록 요청합니다.

캐싱 동작은 DID 확인자의 구성, noCache 확인 옵션, DID 문서의 내용(예: cacheMaxTtl 필드), 또는 이러한 속성들의 조합에 의해 제어될 수 있습니다.

noCache를 구현하는 확인자는 악의적인 클라이언트가 캐싱을 우회하여 비용이 큰 네트워크 요청과 리소스 소비를 강제할 수 있으므로 서비스 거부 공격에 더 취약할 수 있습니다. noCache를 사용하여 확인을 요청하는 클라이언트는 일부 확인자가 캐싱을 우회하는 확인 요청을 거부할 것이라고 예상합니다. 캐싱 없이 확인을 거부하는 확인자는 캐시 우회가 허용되지 않았음을 명확히 하는 FEATURE_NOT_SUPPORTED 오류로 응답해야 MUST 하며, 이를 통해 클라이언트가 noCache를 사용하지 않고 확인을 시도할 수 있도록 해야 합니다.

JSON-LD 컨텍스트 파일을 원격 위치에서 가져오는 경우, 공격자가 컨텍스트 파일을 변경할 수 있습니다 (예: 서버를 침해하거나 중간자 공격으로 요청을 가로채는 경우).

따라서 JSON-LD 컨텍스트 URL을 원격으로 검색하는 모든 DID 확인자는 종단 간 보안을 보장하는 데 도움이 되도록 컨텍스트 파일과 대응하는 해시의 레지스트리(또는 기능적으로 동등한 메커니즘)를 사용할 것을 강력히 권고받습니다. 구현은 리소스의 암호학적 해시 값이 예상 해시 값과 일치하지 않는 경우 오류를 발생시킬 것으로 기대됩니다.

versionId 또는 versionTime DID 매개변수가 제공된 경우, DID 확인 알고리즘은 DID 문서의 특정 버전을 반환합니다.

DID 매개변수 versionId와 versionTime은 상호 배타적입니다.

versionId DID 매개변수의 사용은 DID 메서드별입니다. 가능한 값에는 순차 번호, 무작위 UUID, 콘텐츠 해시 등이 포함될 수 있습니다.

DID 문서 메타데이터는 DID 문서에 대해 수행되는 각 Update 작업마다 변경되는 versionId 속성을 포함할 MAY 수 있습니다.

분산 원장과 같은 분산 시스템을 VDR(검증 가능 데이터 레지스트리)로 사용하는 DID 메서드는 네트워크 포크가 발생할 가능성을 관리해야 합니다. 따라서 분산 시스템을 VDR로 사용하는 DID 메서드의 사양은 사용 중인 VDR을 그러한 포크와 구별할 수 있는 수단을 지정하는 것이 SHOULD됩니다.

DID URL 역참조자 클라이언트가 DID 문서 안의 식별자와 연결된 리소스 — 특히 verificationMethod, controller, 또는 alsoKnownAs 같은 필드 — 를 역참조할 때, 역참조 순환을 만날 수 있습니다. 이러한 순환은 DID 문서가 다른 DID(또는 URL)를 참조하고, 그것이 결국 이전에 역참조된 식별자로 되돌아가 루프를 형성할 때 발생할 수 있습니다. 또한 DID 서비스 엔드포인트를 참조하는 DID URL을 역참조할 때도 DID URL 역참조자가 그러한 상황을 만날 수 있습니다.

did:example:alice
	└── verificationMethod.controller → did:example:bob
		└── verificationMethod.controller → did:example:alice

재귀적 역참조를 수행하는 DID URL 역참조자와 그 클라이언트는 그러한 순환을 예상하고, 감지하고, 처리할 것으로 기대됩니다.

보안 및 성능 위험: 순환이 감지되고 완화되지 않으면, 재귀적 역참조는 다음을 초래할 수 있습니다.

• 소프트웨어에서 무한 루프 또는 스택 오버플로.
• 리소스 고갈(예: 메모리, 네트워크 또는 CPU).
• 클라이언트 또는 중개자의 서비스 거부(DoS) 취약점.

완화 지침: 외부 DID 문서 참조를 재귀적으로 따라가는 구성요소는 이미 역참조된 식별자를 추적하고, 순환이 발생했을 때 이를 감지하여 적절한 조치를 취하는 것이 권장됩니다. 또한 개발자는 잠재적 공격 표면을 줄이기 위해 재귀 깊이나 폭을 제한하고자 할 수 있습니다.

DID 확인자와 DID URL 역참조자는 확인 및 역참조를 위해 자신의 서비스에 들어오는 요청을 기록할 수 있습니다. 시간이 지나면 이러한 로그는 이러한 서비스에 요청을 보내는 클라이언트를 추적하고 프로파일링하는 데 사용될 수 있습니다. 이 개인정보 위험을 완화하기 위해, 클라이언트는 기존 비즈니스 관계가 있거나 해당 서비스가 자신이 제어하는 인프라에서 실행되기 때문에 신뢰하는 서비스에 그러한 요청을 보내야 합니다.

클라이언트는 상관관계 분석과 프로파일링 가능성을 줄이기 위해 서비스에 대한 요청을 난독화하는 조치를 취할 수도 있습니다. 난독화 기법에는 Oblivious HTTP, 신뢰할 수 있는 프록시를 사용하여 확인 요청을 실행하는 방법, 신뢰할 수 있는 캐시 사용 등이 포함됩니다.

서로 다른 DID 메서드는 메서드의 설계 결정과 기반 VDR에 따라 서로 다른 추가 개인정보 영향과 고려사항을 가집니다. 구현자는 지원하려는 특정 DID 메서드의 개인정보 고려사항을 검토할 것을 권고받습니다. DID 메서드 설계자는 구현자가 메서드 설계의 개인정보 영향을 이해하는 데 도움이 되도록 위협 모델을 만들기 위해 W3C 위협 모델링 가이드를 따를 것을 권장합니다.