Conformance

이 문서에는 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 역참조자는 의 관련 규범적 진술에 부합하는 소프트웨어 및/또는 하드웨어로 구현된 알고리즘이다.

규범에 부합하는 DID 메소드는 의 관련 규범적 진술에 부합하는 모든 사양이다.

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 컨트롤러가 (검증 가능한 데이터 레지스트리 자체 이외의) 제3자 모니터링 서비스에 의존하기로 선택하면 다른 공격 벡터가 도입된다.

키 및 서명 만료

탈중앙 식별자 아키텍처에서는 암호화 자료나 암호화된 디지털 서명 만료 정책을 시행할 중앙 집중식 기관이 없을 수 있다. 따라서 요청 당사자는 DID 변환기 및 검증 라이브러리와 같은 지원 소프트웨어를 사용하여 암호화 자료가 사용될 당시에 만료되지 않았는지 검증한다. 요청 당사자는 검증 프로세스에 대한 입력 외에도 자체 만료 정책을 사용할 수 있다. 예를 들어, 일부 요청 당사자는 5분 전의 인증을 수락할 수 있는 반면, 고정밀 시간 소스에 액세스할 수 있는 다른 요청 당사자는 인증에 지난 500밀리초 이내의 타임스탬프가 찍혀야 할 수 있다.

레거시 암호화된 디지털 서명을 검증하는 것과 같이 이미 만료된 암호화 자료의 사용을 확장해야 하는 정당한 필요성이 있는 요청 당사자도 있다. 이러한 시나리오에서 요청 당사자는 검증 소프트웨어에 암호화 키 자료 만료를 무시하도록 지시하거나 암호화 키 자료가 사용될 당시에 만료되었는지 확인할 수 있다.

검증 방법 교체

교체는 새로운 검증 방법가 DID 문서에 추가되면 기존 검증 방법와 연결된 비밀 암호화 자료를 비활성화하거나 파기할 수 있게 해주는 관리 프로세스이다. 앞으로 컨트롤러가 이전 비밀 암호화 자료를 사용하여 생성했을 새로운 증명은 이제 새로운 암호화 자료를 사용하여 생성될 수 있으며 새로운 검증 방법를 사용하여 검증될 수 있다.

교체는 컨트롤러에 의한 검증 방법의 빈번한 교체가 공격자에게 단일 손상된 검증 방법의 가치를 줄이기 때문에 검증 방법 손상으로부터 보호하는 데 유용한 메커니즘이다. 교체 직후 즉시 폐기하는 것은 메시지 암호화 및 인증과 관련된 것과 같이 컨트롤러가 단기 검증을 위해 지정한 검증 방법에 유용하다.

검증 방법 교체 사용을 고려할 때 다음 사항이 유용할 수 있다:

• 검증 방법 교체는 선제적인 보안 조치이다.
• 일반적으로 검증 방법 교체를 정기적으로 수행하는 것이 좋은 방법으로 간주된다.
• 보안이 더 높은 환경에서는 검증 방법 교체를 더 자주 수행하는 경향이 있다.
• 검증 방법 교체는 DID 문서의 현재 또는 최신 버전에 대한 변경으로만 나타난다.
• 검증 방법이 오랫동안 활성화되었거나 많은 작업에 사용된 경우, 컨트롤러는 교체를 수행하기를 원할 수 있다.
• 검증 방법의 빈번한 교체는 관련 자격 증명을 지속적으로 갱신하거나 새로 고쳐야 하는 당사자에게 불편을 줄 수 있다.
• DID 문서의 최신 버전에 없는 검증 방법에 의존하는 증명이나 서명은 교체의 영향을 받지 않는다. 이러한 경우 검증 소프트웨어는 특정 검증 방법이 유효할 것으로 예상되는 시기와 증명 또는 서명의 유효성을 결정하기 위한 기록 기록을 포함하는 검증 가능한 데이터 레지스트리에 대한 액세스와 같은 추가 정보가 필요할 수 있다. 이 옵션은 모든 DID 메소드에서 사용할 수 없을 수 있다.
• DID 메소드 작업에 대한 섹션은 검증 방법 교체를 수행하는 데 사용될 것으로 예상되는 update를 포함하여 DID 메소드 규격에서 지원해야 하는 DID 작업을 지정한다.
• 컨트롤러는 일정 시간 후 기존 검증 방법를 대체하기 위한 새로운 검증 방법를 추가할 때 교체를 수행한다.
• 모든 DID 메소드가 검증 방법 교체를 지원하는 것은 아니다.

검증 방법 폐기

폐기는 기존 검증 방법와 연결된 비밀 암호화 자료를 비활성화하여 새로운 디지털 서명 증명을 생성하는 유효한 형식이 되지 않도록 하는 관리 프로세스이다.

폐기는 검증 방법 손상에 대응하는 유용한 메커니즘이다. 교체 직후 즉시 폐기하는 것은 메시지 암호화 및 인증과 관련된 것과 같이 컨트롤러가 단기 검증을 위해 지정한 검증 방법에 유용하다.

검증 방법와 연결된 비밀의 손상은 공격자가 DID 문서에서 컨트롤러에 의해 표현된 검증 관계에 따라 예를 들어 인증을 위해 이를 사용할 수 있게 한다. 공격자의 비밀 사용은 검증 방법가 등록된 시점부터 폐기된 시점까지 합법적인 컨트롤러의 사용과 구별할 수 없을 수 있다.

검증 방법 폐기 사용을 고려할 때 다음 사항이 유용할 수 있다:

• 검증 방법 폐기는 반응적인 보안 조치이다.
• 키 폐기를 지원하는 것이 좋은 방법으로 간주된다.
• 컨트롤러는 손상된 것으로 알려진 모든 검증 방법를 즉시 폐기할 것으로 예상된다.
• 검증 방법 폐기는 DID 문서의 최신 버전에 대한 변경으로만 구현될 수 있다. 이전 버전을 소급하여 조정할 수는 없다.
• 에 설명된 대로, 검증 방법의 부재는 폐기를 지원하는 모든 DID 메소드에 적용되는 유일한 형태의 폐기이다.
• 검증 방법가 더 이상 컨트롤러 또는 컨트롤러를 대신하여 작업하도록 신뢰된 당사자에게 독점적으로 액세스할 수 없는 경우, 사칭, 도난 및 사기와 같은 손상의 위험을 줄이기 위해 즉시 폐기될 것으로 예상된다.
• 폐기는 컨트롤러가 폐기 후 생성된 폐기된 검증 방법와 관련된 증명 또는 서명을 무효로 처리해야 한다는 것으로 이해될 것으로 예상된다. 또한 기존 증명 또는 서명이 공격자에 의해 생성되었을 수 있다는 우려를 암시할 수 있지만, 반드시 그런 것은 아니다. 그러나 검증자는 여전히 그러한 증명이나 서명을 자신의 재량에 따라 수락하거나 거부하도록 선택할 수 있다.
• DID 메소드 작업에 대한 섹션은 검증 방법를 DID 문서에서 제거하는 데 사용될 수 있는 update 및 deactivate를 포함하여 DID 메소드 규격에서 지원해야 하는 DID 작업을 지정한다.
• 모든 DID 메소드가 검증 방법 폐기를 지원하는 것은 아니다.
• 검증 방법가 DID 문서에 존재하더라도 공개 키 폐기 인증서 또는 외부 허용 또는 거부 목록과 같은 추가 정보를 사용하여 검증 방법가 폐기되었는지 확인할 수 있다.
• 개인의 운영 체제, 백신 프로그램 또는 엔드포인트 보호 소프트웨어와 같이 손상된 검증 방법에 의존하는 모든 소프트웨어의 일상적인 운영은 검증 방법가 공개적으로 폐기될 때 영향을 받을 수 있다.

DID 복구

복구는 장치 분실 등으로 인해 DID 작업을 수행할 수 있는 능력을 상실한 컨트롤러가 DID 작업을 수행할 수 있는 능력을 회복할 수 있는 반응적인 보안 조치이다.

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

• 자주 하지는 않지만 정기적으로 사전에 복구를 수행하면 제어 능력을 상실하지 않았는지 확인하는 데 도움이 될 수 있다.
• 복구와 관련된 암호화 자료를 다른 목적으로 재사용하지 않는 것이 좋은 방법으로 간주된다.
• 복구는 일반적으로 검증 방법 교체 및 검증 방법 폐기와 함께 수행된다.
• 컨트롤러 또는 그들을 대신하여 행동하도록 신뢰받는 서비스가 더 이상 에 설명된 대로 DID 작업을 수행할 수 있는 독점적인 능력을 가지고 있지 않을 때 복구가 권장된다.
• DID 메소드 규격은 복구를 용이하게 하기 위해 신뢰받는 당사자의 정족수를 지원하도록 선택할 수 있다. 이를 위한 일부 기능은 에서 제안된다.
• 모든 DID 메소드 규격이 다른 DID 메소드를 사용하여 등록된 DID의 제어를 인식하는 것은 아니며, 제3자 제어를 동일한 메소드를 사용하는 DID로 제한할 수 있다.
• DID 메소드 규격의 접근 제어 및 복구에는 복구를 위한 제어의 두 번째 경로를 유지함으로써 키 손상으로부터 보호하기 위한 시간 잠금 기능도 포함될 수 있다.
• 현재 모든 DID 메소드에 적용되는 공통 복구 메커니즘은 없다.

사람이 알아보기 쉬운 식별자의 역할

DID는 중앙 등록 기관의 필요 없이 전 세계적인 고유성을 달성한다. 이는 사람이 기억하기 어려운 대가로 온다. 전 세계적으로 모호하지 않은 식별자를 생성할 수 있는 알고리즘은 사람에게 의미가 없는 무작위 문자열을 생성한다. 이러한 상충 관계는 종종 주코의 삼각형이라고 한다.

사람이 알아보기 쉬운 식별자에서 시작하여 DID를 발견하는 것이 바람직한 사용 사례가 있다. 예를 들어 자연어 이름, 도메인 이름 또는 DID 컨트롤러의 기존 주소(예: 휴대전화 번호, 이메일 주소, 소셜 미디어 사용자 이름 또는 블로그 URL)가 있다. 그러나 사람이 알아보기 쉬운 식별자를 DID에 매핑하고 검증 및 신뢰할 수 있는 방식으로 이를 수행하는 문제는 이 규격의 범위를 벗어난다.

이 문제에 대한 해결책은 이 규격을 참조하는 [[?DNS-DID]]와 같은 별도의 규격에 정의되어 있다. 이러한 규격에서는 다음 사항을 신중하게 고려하는 것이 좋다:

• 대상 엔티티의 진정한 사람이 알아보기 쉬운 식별자에 대해 사용자를 속이는 것을 기반으로 하는 수많은 보안 공격.
• 특히 전 세계적으로 고유한 경우 본질적으로 상호 연관성이 있는 사람이 알아보기 쉬운 식별자를 사용하는 것의 개인 정보 보호 결과.

향상된 URN으로서의 DID

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

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

• DID 컨트롤러는 컨트롤러의 영속성 요구사항을 지원하는 DID 메소드를 선택해야 한다. 분산형 특성 루브릭[[?DID-RUBRIC]]은 구현자가 가장 적합한 DID 메소드를 결정하는 데 사용할 수 있는 도구 중 하나이다.
• DID 컨트롤러는 요청 당사자가 해당 DID 컨트롤러가 제어하는 DID의 영속성에 의존할 수 있는 정도를 결정할 수 있도록 운영 정책을 게시해야 한다. 이러한 정책이 없는 경우 요청 당사자는 DID가 동일한 DID 주체에 대한 영구 식별자인지 여부에 대해 어떠한 가정도 하지 않아야 한다.

불변성

많은 사이버 보안 침해는 현실과 합리적이고 선의의 행위자의 가정 사이의 격차를 악용하는 데 달려 있다. DID 문서의 불변성은 일부 보안 이점을 제공할 수 있다. 개별 DID 메소드는 필요하지 않은 행동이나 의미론을 제거할 수 있는 제약 조건을 고려해야 한다. DID 메소드가 동일한 기능 집합을 제공하면서 더 잠겨 있을수록 악의적인 행위자에 의해 조작될 가능성이 줄어든다.

예를 들어 DID 문서를 한 번만 편집해도 문서의 루트 id 속성을 제외한 모든 것을 변경할 수 있다. 그러나 서비스가 정의된 후 type을 변경하는 것이 실제로 바람직한가? 또는 키가 그 값을 변경하는 것이 바람직한가? 아니면 객체의 특정 기본 속성이 변경될 때 새로운 id를 요구하는 것이 더 좋을까? 웹사이트의 악의적인 탈취는 종종 사이트가 호스트 이름 식별자를 유지하지만 그 아래에서 미묘하게 변경되는 결과를 목표로 한다. 사이트의 특정 속성(예: IP 주소와 연결된 ASN)이 규격에 의해 불변해야 하는 경우, 이상 감지가 더 쉬워지고 공격이 훨씬 더 어려워지고 비용이 많이 들 것이다.

전 세계적인 진실의 원천과 연결된 DID 메소드의 경우 DID 문서의 최신 버전에 대한 직접적이고 적시적인 검색이 항상 가능하다. 그러나 DID 변환기와 해당 진실의 원천 사이에 캐시 계층이 결국 위치할 가능성이 있어 보인다. 만약 그렇다면 DID 문서의 객체 속성이 실제로는 미묘하게 다른데 주어진 상태를 가지고 있다고 믿는 것은 악용을 초래할 수 있다. 이는 일부 검색이 전체 DID 문서에 대한 것이고 다른 검색은 더 큰 맥락이 가정되는 부분 데이터에 대한 것인 경우에 특히 그러하다.

DID 문서의 암호화된 데이터

암호화 알고리즘은 암호학과 컴퓨팅 능력의 발전으로 인해 실패하는 것으로 알려져 있다. 구현자는 DID 문서에 배치된 암호화된 데이터가 결국 암호화된 데이터를 사용할 수 있는 동일한 대상에게 일반 텍스트로 제공될 수 있다고 가정하는 것이 좋다. 이는 DID 문서가 공개된 경우 특히 적절하다.

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

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

Equivalence Properties

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 컨텍스트와 연관된 것으로 알려진 암호화 해시에 대해 외부 컨텍스트의 무결성을 검증하는 것이 좋다.

Persistence

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

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

불행히도 암호화 자체만으로는 주어진 검증 방법와 관련된 비밀 암호화 자료가 손상되었는지 여부를 판단할 수 없다. 예상되는 컨트롤러가 여전히 비밀 암호화 자료에 액세스할 수 있으며, 이에 따라 검증 프로세스의 일부로 제어 증명을 실행할 수 있는 반면, 동시에 악의적인 행위자도 동일한 키 또는 그 사본에 액세스할 수 있을 수 있다.

따라서 암호화 제어 증명은 고위험 시나리오에 필요한 신원 보증 수준을 평가하는 데 하나의 요소로만 사용될 것으로 예상된다. DID 기반 인증은 시스템 간에 해당 비밀을 전송하지 않고도 암호화 비밀에 대한 제어를 결정할 수 있는 기능 덕분에 사용자 이름과 암호보다 훨씬 더 큰 보증을 제공한다. 그러나 무오류는 아니다. 민감하거나 고가치 또는 생명에 중요한 작업과 관련된 시나리오에서는 적절한 추가 요소를 사용할 것으로 예상된다.

서로 다른 컨트롤러에 의한 사용으로 인한 잠재적 모호성 외에도, 일반적으로 주어진 DID가 특정 시점에 동일한 주체를 참조하여 사용되고 있음을 보장할 수 없다. 컨트롤러가 서로 다른 주체에 대해 DID를 재사용하는 것은 기술적으로 가능하며, 더 미묘하게는 주체의 정확한 정의가 시간이 지남에 따라 변경되거나 오해될 수 있다.

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

이러한 잠재적 모호성으로 인해 DID는 절대적이라기보다는 문맥적으로 유효한 것으로 간주되어야 한다. 그것들의 지속성은 그것들이 정확히 동일한 주체를 지칭한다거나 동일한 컨트롤러의 제어 하에 있음을 의미하지 않는다. 대신 DID가 생성된 맥락, 어떻게 사용되는지, 그 의미의 변화 가능성을 이해하고 잠재적이고 불가피한 의미론적 변화를 해결하기 위한 절차와 정책을 채택해야 한다.

Level of Assurance

규정된 금융 및 공공 부문과 같은 영역에서는 특히 규정 준수를 위해 인증 이벤트의 보안 컨텍스트에 대한 추가 정보가 종종 필요하다. 이 정보는 종종 보증 수준(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 문서가 공개될 수 있는 공개 대상 검증 가능한 데이터 레지스트리에 대해 작성된 경우, 해당 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 문서에 추가하는 것은 위험하다.

이러한 속성은 DID 문서에 개인 데이터( 참조) 또는 상호 연관 가능한 데이터( 및 참조)가 존재하게 할 뿐만 아니라, 특정 DID를 그룹화하여 특정 작업이나 기능에 포함시키거나 제외시키는 데 사용될 수 있다.

DID 문서에 유형 정보를 포함하면 IoT 장치와 같이 사람이 아닌 엔티티인 DID 주체에 대해서도 개인정보 보호 피해가 발생할 수 있다. DID 컨트롤러 주변의 이러한 정보 집계는 일종의 디지털 지문 역할을 할 수 있으므로 피하는 것이 가장 좋다.

이러한 위험을 최소화하기 위해 DID 문서의 모든 속성은 DID 사용과 관련된 암호화 자료, 엔드포인트 또는 검증 방법를 표현하기 위한 것이어야 한다.

군중 개인정보 보호

DID 주체가 군중 속에서 구별할 수 없을 때 개인정보 보호를 이용할 수 있다. 다른 당사자와 사적으로 관여하는 행위 자체가 인식 가능한 신호일 때 개인정보 보호는 크게 감소한다.

DID와 DID 메소드는 특히 합법적으로 가장 필요로 하는 사람들을 위해 군중 개인정보 보호를 개선하기 위해 노력해야 한다. 익명성과 가명성을 보존하는 것을 기본으로 하는 기술과 사용자 인터페이스를 선택하라. 디지털 지문을 줄이기 위해 요청 당사자 구현에서 공통 설정을 공유하고, 유선 프로토콜에서 협상된 옵션을 최소한으로 유지하고, 암호화된 전송 계층을 사용하고, 메시지를 표준 길이로 채워라.

서비스 개인정보 보호

컨트롤러가 DID 문서에서 선택적으로 하나 이상의 서비스 엔드포인트를 표현할 수 있는 능력은 그들의 제어와 주체성을 증가시킨다. DID 문서의 각 추가 엔드포인트는 엔드포인트 설명에 걸친 상관관계로 인해 개인정보 보호 위험을 증가시키거나 서비스가 인증 메커니즘에 의해 보호되지 않기 때문에 또는 둘 다로 인해 개인정보 보호 위험을 증가시킨다.

DID 문서는 종종 공개적이며 표준화되어 있기 때문에 표준 기반 특성에 따라 효율적으로 저장되고 색인화된다. 이 위험은 DID 문서가 불변의 검증 가능한 데이터 레지스트리에 게시되는 경우 더 심각하다. DID에 의해 참조되는 DID 문서 기록에 대한 액세스는 표준 사용을 통해 더 효율적으로 이루어지는 일종의 트래픽 분석 형태를 나타낸다.

하나의 DID 문서에서 여러 서비스 엔드포인트를 사용하여 발생하는 추가적인 개인정보 보호 위험의 정도는 추정하기 어려울 수 있다. 개인정보 보호 피해는 일반적으로 의도하지 않은 결과이다. DID는 개인, 가구, 클럽, 고용주와 관련될 수 있는 문서, 서비스, 스키마 및 기타 사항을 지칭할 수 있으며, 이들의 서비스 엔드포인트 상관관계는 강력한 감시 및 추론 도구가 될 수 있다. 이러한 잠재적 피해의 예는 https://example.co.uk와 같은 여러 공통 국가 수준 최상위 도메인을 사용하여 더 높은 확률로 DID 주체의 대략적인 위치를 추론할 수 있을 때 확인할 수 있다.