검수요청.png검수요청.png

DIDs

위키원
이동: 둘러보기, 검색

DIDs(Decentralized Identifiers) 또는 탈중앙 식별자는 검증가능하고 탈중앙화된 디지털 신원을 위한 새로운 형식의 식별자이다.[1]

개요

탈중앙 식별자는 DID 컨트롤러가 DID의 제어권을 증명하고, 중앙화된 레지스트리, 신원 제공자, 인증기관 등으로부터 독립적으로 구현할 수 있도록 설계되었다. DID는 DID 주체와 관련된 URL로써, DID 문서라는 방식을 통해 해당 주체와 신뢰할 수 있는 상호작용을 가능하게 하는 도구이다. DID 문서는 특정 DID를 어떻게 사용하는지에 대해 설명해 놓은 간단한 문서이다. 각 DID 문서는 암호학적 요소, 검증 메소드, 서비스 엔드포인트 등으로 표현될 수 있다. 해당 요소들은 DID 컨트롤러가 DID 통제권에 대한 증명을 가능하게 하는 메커니즘 집합을 제공한다. 서비스 엔드포인트는 DID 주체와의 믿을 수 있는 상호작용을 가능하게 한다. 또한 탈중앙 식별자는 새로운 개념은 아니다. 범용고유식별자(UUIDs)는 1980년대에 처음 개발되었고 향후 개방 소프트웨어재단의 분산 컴퓨팅 환경에서 표준 기능이 되었다. 범용고유식별자는 충돌 가능성이 무한히 작을 정도로 충분한 엔트로피를 가진 128bit 값을 생성하는 알고리즘을 통해 중앙화된 등록 서비스 없이도 글로벌 유일성을 가질 수 있다. 범용고유식별자는 [RFC4122]에서 URN(Unified Resource Name)의 특정 형식으로써 공식 명시되어있다.[2]

특징

개념

기존의 아이디 관리 시스템은 기업의 디렉터리 서비스, 인증기관, 또는 도메인 등록 기관과 같은 중앙 집중식 기관을 기반으로 한다. 암호학적 신뢰 검증의 관점에서 보면, 이들 중앙화된 각 기관은 각각의 신뢰점(root of trust)이 된다. 이러한 시스템들을 통해 아이디 관리를 수행하려면 연합 아이디 관리를 구축해야 한다. 블록체인이라고도 하는 분산원장 기술의 출현은 완전한 탈중앙 아이디 관리 기회를 제공한다. 탈중앙 신원 시스템에서 개체(개인, 조직 및 기타 사항과 같은 제한이 없는 개별 식별 가능 단위)는 공유된 신뢰점을 자유롭게 사용할 수 있다. 전 세계에 분산된 원장, 탈중앙 피투피 네트워크, 또는 유사한 기능을 가진 다른 시스템은 권한의 집중이나 단일 장애점을 도입하지 않고 신뢰점을 관리할 수 있는 수단을 제공한다. 분산원장기술들과 탈중앙 아이디 관리를 결합한 시스템에서는 누구나 분산되고, 신뢰점과 독립적인 자신의 식별자들을 생성하고 관리할 수 있다. 개체들은 탈중앙 식별자에 의해 식별되며, 증명(예: 디지털 서명, 생체인식 기술 등)을 통해 인증할 수 있다. 탈중앙 식별자는 DID 문서들을 참조한다. DID 문서는 DID 식별자와 주체가 상호 작용을 하기 위한 서비스 엔드포인트들을 포함한다. 프라이버시 디자인 가이드라인에 따라, 개체들은 신원, 페르소나, 그리고 문맥들에 따라 구분하고 싶은 바람을 따라 자신이 원하는 만큼 많은 탈중앙 식별자(DID 문서와 서비스 엔드포인트들이 포함된)를 가질 수 있다. DID 메소드는 특정 분산 원장 또는 네트워크에서 DID와 관련된 DID 문서들을 생성, 읽기, 갱신, 그리고 비활성화 하는 메커니즘이다. DID 메소드들은 별도의 DID 메소드 규격을 사용하여 정의한다. 잉 설계는 중앙 집중식 레지스트리와 공개키 기반구조(PKI, public key infrastructure)의 중앙 집중식 인증 기관에 대한 식별자의 의존성을 제거한다. DID 레지스트리가 분산 원장인 경우, 각 개체는 자체 인증 기관의 역할을 할 수 있으며, 이것을 분권화된 PKI-DPKI라고 한다. 참고로 DID 메소드들은 연합, 또는 중앙집중식 아이디 관리 시스템에 등록된 식별자로도 사용될 수 있다. 이것을 위해, 모든 유형의 식별자 시스템에 탈중앙 식별자 지원을 추가할 수 있다. 이로 인해 중앙집중, 연합 및 탈중앙 식별자들 사이의 상호 운용성이 형성 된다. 이 규격의 첫 번째 목적은 일반적인 DID 스키마와 일반적인 DID 문서들에서 동작하는 명령어 집합을 모든 DID 레지스트리에 구현될 수 있도록 정의하는 것이다. 이 규격의 두 번째 목적은 DID 메소드를 위한 적합 요구 조건(특정 DID 레지스트리를 위한 특정 DID 스키마와 특정 DID 문서에서 동작하는 명령어 세트를 정의하는 별도의 규격)을 정의하기 위함이다. 개념적으로, 이 규격(Decentralized Identifiers)과 DID 메소드 규격의 관계는 IETF 일반 URI 규격([RFC3986])과 특정 URI 체계([IANA-URI-SCHEMES])([RFC7230]에 명시된 http:와 https: 체계)의 관계와 유사하다. IETF 일반 URN 규격([RFC8141]) 및 특정 URN 네임스페이스 정의([RFC4122]에 정의된 UUID URN 네임스페이스 등과 같은)의 관계와도 역시 유사하다. 차이점은 DID 메소드 규격은 특정 DID 스키마를 정의하는 것 외에도, 적절한 DID 레지스트리에서 탈중앙 식별자의 구별방법을 제공하거나, 비활성화하거나, DID 문서를 작성하는 방법을 명시한다는 것이다. 특정 DID 메소드 규격을 가진 일반 DID 규격의 계층적 설계는 URI 규격과 동일한 개념의 일부를 도입한다.

  • 다른 URI 체계의 URIs가 상호운용되지 않는 것처럼, 다른 DID 메소드의 탈중앙 식별자는 상호운용되지 않을 수 있다.
  • 일부 브라우저가 특정 URI 체계만 지원하는 경우와 같이, 특정한 DID 메소드만을 지원하는 관계의 지원을 받기 위해 복수의 탈중앙 식별자가 필요할 수 있다.
  • 모든 브라우저가 동일한 URI체계를 지원하지 않는 것과 같이, 모든 DID 메소드가 동일한 암호 체계를 지원하지는 않기 때문에, 다른 암호화 체계를 지원하기 위해 복수의 탈중앙 식별자가 필요할 수 있다.
  • 복수의 탈중앙 식별자의 관리 및 그리고 어떤 DID가 어떤 관계에 속하는지 추적하는 것은, 어떤 웹주소가 어떤 웹사이트에 속하는지 추적하거나 어떤 이메일 주소가 어떤 관계에 속하는지 추적하는 것과 유사한 문제를 야기한다.
* 예시 1 : A simple example of a decentralized identifier (DID)
did:example:123456789abcdefghi

위의 예제 DID는 DID 문서로 해석될 수 있다. DID 문서에는 DID를 제어하여 개체를 암호학적으로 인증하는 방법 및 개체와 상호 작용하는 데 사용할 수 있는 서비스와 같이 DID와 관련된 정보가 포함되어 있다.

* 예시 2 : Minimal self-managed DID document
{
  "@context": "https://www.w3.org/ns/did/v1",
  "id": "did:example:123456789abcdefghi",
  "authentication": [{
   //  used to authenticate as did:...fghi
    "id": "did:example:123456789abcdefghi#keys-1",
    "type": "Ed25519VerificationKey2018",
    "controller": "did:example:123456789abcdefghi",
    "publicKeyBase58": "H3C2AVvLMv6gmMNam3uVAjZpfkcJCwDwnZn6z3wXmqPV"
  }],
  "service": [{
    //  used to retrieve Verifiable Credentials associated with the DID
    "id":"did:example:123456789abcdefghi#vcs",
    "type": "VerifiableCredentialService",
    "serviceEndpoint": "https://example.com/vc/"
  }]
}

관련 용어

  • 블록체인(blockchain) : 특정한 방식의 분산원장기술로 암호화된 체인에 원장의 항목들을 묶고 해시해서 저장한다. 이러한 타입의 분산원장이 비트코인에 의해 처음 소개되었기 때문에 블록체인이라는 단어는 가끔 구체적으로 비트코인 원장을 의미하기도 한다.
  • 분산아이디(decentralized identifier, DID) : 분산원장기술이나 다른 형태의 분산 네트워크에 등록되었기 때문에 중앙화된 등록기관이 필요하지 않은 전역적으로 고유한 식별자이다. 분산아이디의 일반적인 형식은 이 문서에 정의되어 있다. 특정한 DID 체계는 DID 메소드 규격에 정의되어 있다.
  • 탈중앙 신원관리(decentralized identity management) : 탈중앙 식별자를 관리하는 신원 관리 방법이다. 탈중앙 신원 관리는 기존에 전통적인 신뢰의 주체였던 X.500 direcotry services, Domain Name System, 그리고 대부분의 국가 아이디 시스템보다 생성 권한을 확장한다.
  • 탈중앙 공개키 인프라(Decentralized Public Key Infrastructure, DPKI) : 탈중앙 식별자와 신원 기록(예를 들어 DID 문서) 등 검증 가능한 공개키 정보들을 포함한 공개키 기반 인프라를 말한다.
  • DID 컨트롤러(DID controller) : DID 또는 DID 문서를 제어하는 주체 또는 그룹이다. 참고로 DID 컨트롤러는 DID 대상을 포함할 수 있다.
  • DID 문서(DID document) : DID 대상을 설명하는 데이터들의 모음이다. DID 대상이 자기 자신을 인증하고 DID와의 연관성을 입증하는데 사용할 수 있는 공개키나 유사 생체 인식과 같은 데이터를 포함한다. DID 문서는 DID 대상에 대한 다른 속성 또는 주장을 포함 할 수 있다. 이 문서들은 그래프 기반 데이터 구조이며 주로[JSON-LD] 형식으로 작성되어 있지만, 다른 그래프 기반 데이터 포맷으로도 나타낼 수 있다.
  • DID 프래그먼트(DID fragment) : DID URL 중 첫 번째 해시 기호 문자 (#) 다음에 오는 부분이다. DID 조각 구문은 URI 조각 구문과 같다.
  • DID 메소드(DID method) : 특정 DID 체계가 특정 분산원장이나 네트워크에서 구현할 수 있는지 정확한 방법을 정의한 것이다. 어떻게 DID들이 해결되고 비활성화 되는지, 어떻게 DID 문서들이 작성되고 업데이트 되는지 등을 포함한다.
  • DID 경로(DID path) : DID URL 중 첫 번째 슬래시 문자 (/ 포함)하는 부분이다. DID 경로 구문은 URI 경로 구문과 같다.
  • DID 쿼리(DID query) : DID URL 중 첫 번째 물음표 문자 (?) 다음에 오는 부분이다. DID 쿼리 구문은 URI 쿼리 구문과 같다.
  • DID 레지스트리(DID registry) : 탈중앙 식별자의 생성, 확인, 업데이트 및 비활성화를 중재하는 역할을 하는 시스템으로, DID 레지스트리는 검증 가능한 데이터 레지스트리 유형이다.
  • DID 변환기(DID resolver) : 주어진 DID에 대한 DID 문서를 검색할 수 있는 시스템이다. 이러한 시스템들의 규격은 DID Resolution 문서에 있다.
  • DID 체계(DID scheme) : 탈중앙 식별자의 공식적인 구문이다. 전반적인 DID 체계는 이 문서에 포함되어 있다.
  • DID 주체(DID subject) : DID로 구분되고 DID 문서로 설명되는 주체이다.
  • DID URL : DID와 선택적인 DID 경로(? 문자열 뒤에 DID 쿼리와 # 문자열 뒤 DID 프래그먼트를 포함)의 집합이다.
  • 분산원장(distributed ledger, DLT) : 여러 노드합의 알고리즘을 사용해 공유하는 원장인 분산 데이터베이스다. 원장의 각 트랜잭션들이 암호화로 서명하고 이전 트랜잭션에 연결되어 있다.
  • 확장 가능한 데이터 교환(extensible data interchange, XDI) : OASIS XDI Technical Committee에 의해 정의된 시맨틱 그래프 형식 및 시맨틱 데이터 교환 프로토콜이다.
  • JSON 포인터(JSON Pointer) : JSON 포인터는 [RFC6901]에 정의된 JavaScript Object Notation (JSON) 문서에서 특정 값을 식별하기 위한 문자열 구문을 정의한다.
  • 공개키 설명(public key description) : DID 문서 안에 공개키나 인증키를 사용하기 위한 모든 메타데이터를 담은 JSON 객체이다.
  • 서비스 엔드포인트(service endpoint) : DID 주체가 운영하는 서비스 네트워크의 주소이다. 이런 서비스들의 예시로는 검색 서비스, 소셜 네트워크, 파일 스토리지 서비스 및 verifiable claim 저장소 서비스 등이 있다. 서비스 엔드포인트는 확장 가능한 데이터 교환 프로토콜 같은 일반적인 데이터 교환 프로토콜에 의해서 제공 될 수도 있다.
  • Uniform Resource Identifier(URI) : [RFC3986]에 정의되어 있는 식별자이다.
  • 범용고유식별자(Universally Unique Identifier, UUID) : [RFC4122]에 정의되어 있는 식별자이다.

상호운용성

탈중앙 식별자와 DID 문서의 구현 상호운용성(interoperability)은 규격에 부합하는 탈중앙 식별자 및 DID 문서를 작성하고 분석할 수 있는 구현 능력을 평가하여 시험한다. DID 메소드의 상호운용성은 최소한 다음과 같이 최소 규격을 평가함으로써 결정된다.

  • DID 메소드 이름은 겹치지 않고 유일해야 하며, DID 메소드의 기존 용례와 모순된 사용은 하지 못한다.
  • 요구되는 기능들이 지원돼야 한다.
  • 설명이 필요한 작업에 대해 설명되어야 한다.
  • 규격은 독립적 구현을 위해 충분히 구체적이고 상세하고 완전해야 한다.
  • 규격은 보안 및 프라이버시 고려사항을 기술하는 섹션을 포함해야 한다.

탈중앙 식별자 및 DID 문서의 생산자와 소비자를 위한 상호운용성은 탈중앙 식별자 및 DID 문서가 일치하는지 확인함으로써 보장된다. DID 메소드 규격에 대한 상호운용성은 각 DID 메소드 규격에 있는 세부사항에 의해 보장된다. 웹브라우저가 알려진 모든 URIs 스키마를 구현할 필요가 없는 것처럼, 탈중앙 식별자와 함께 작동하는 호환 소프트웨어는 알려진 모든 DID 메소드를 구현할 필요가 없음을 이해해야한다. 그러나 지정된 DID 메소드의 모든 구현은 해당 메소드에 대해 상호운용성이 보장해야한다.

데이터 모델

식별자

데이터 모델에서 식별자는 일반적으로 사람, 조직, 장치, 키, 서비스 및 사물의 특정 인스턴스를 식별하기 위해 사용된다. 식별자는 대부분 URLs이며, 좀 더 일반적으로는 URIs이다. 비 URI 기반 식별자는 데이터 모델이 이를 지원하기는 하지만, 다른 인터넷 기반 식별자와 함께 사용하기 쉽지 않기 때문에 권장되지 않는다.

DID 문서

DID 문서는 decentralized identifier(DID)와 관련된 리소스다. DID 문서는 일반적으로 검증 메소드(public key 등) 및 DID 컨트롤러와 상호 작용하는데 사용할 수 있는 서비스를 포함한다. 또한, 특정 구문에 따라 일련화된다. DID 자체는 id 속성에 포함되어 있다. DID 문서는 DID 주체 또는 관련된 것들과의 상호작용을 인증하거나 승인하는 데 사용할 수 있는 암호화 키 및 기타 검증 메소드를 나타낼 수 있다. 표현된 정보에는 디지털 서명을 확인하는 데 전역적으로 사용할 수 있는 명확한 식별자와 공개키 자료가 포함된다. 키의 상태 정보(예: 정지 또는 취소된 경우)나 하드웨어 기반 암호화 키인지 여부를 결정할 수 있는 속성 등 기타 정보를 표시할 수 있다. 암호화 키 자료와 관련하여, 공개키는 사용할 대상에 따라 publicKey 또는 authentication 속성을 사용하는 DID 문서에 포함될 수 있다. 각 공개키는 고유한 식별자(id), type, 그리고 controller 뿐만아니라 키 유형에 따라 다른 속성을 갖는다. 이 규격은 DID 문서에서 공개키 자료를 표현하기 위한 형식의 수를 가능한 적게 제한하여 상호 운용성을 높이려고 노력한다. 구현자가 구현해야 하는 형식이 적을수록 모든 형식을 지원할 가능성이 높다. 이 접근 방식은 구현의 용이성과 역사적으로 광범위하게 배포된 지원 형식간에 미묘한 균형을 유지한다.

DID 메소드

DID 메소드 규격은 정확하게 메소드별 DID 체계마다 식별이 가능한 정확한 하나의 메소드 이름이 반드시 정의해야 한다. (method-name 규칙은 일반 DID 구문에 따른다) 메소드 이름은 DID의 일부이므로, 짧은 메소드 이름이 선호된다. 메소드 이름은 5자 이하여야 한다. 메소드 이름은 DID 메소드 규격이 적용되는 DID 레지스트리의 이름을 반영할 수 있다. (고유한 DID 메소드 이름 (Unique DID Method Names))메소드별 DID 체계를 위한 DID 메소드 규격에는 DID의 구성요소인 method-specific-id를 어떻게 생성하는지 반드시 명시가 되어있어야 한다. method-specific-id는 반드시 중앙화 된 레지스트리 서비스를 이용하지 않고 생성할 수 있어야 한다. method-specific-id는 범용(범세계)적으로 고유해야 한다. did 규칙은 일반 DID 구문에 정의되어 있으며, 반드시 전 세계적으로 고유해야 한다. 필요하다면, 메소드별 DID 체계는 다수의 method-specific-id 형식을 정의할 수 있다. (하지만) 가능한 소수의 method-specific-id 형식을 정의하는 것을 권장한다.

서비스

서비스 엔드포인트는 DID 주체 또는 관련 개체와 통신할 수 있는 방법을 나타내기 위해 DID 문서에서 사용된다. DID 문서에 나열된 서비스에는 개인 정보 보호 메시징 서비스에 대한 정보 또는 소셜 미디어 계정, 개인 웹사이트, 이메일 주소와 같은 공개 정보가 포함될 수 있다. 서비스와 관련된 메타 데이터는 보통 서비스마다 다르다. 예를 들어, 암호화된 메시징 서비스와 관련된 메타 데이터는 메시지를 보내기 전에 암호화된 링크를 시작하는 방법을 나타낼 수 있다. 서비스에 대한 포인터는 service 속성을 사용하여 표현한다. 각 서비스에는 고유한 id와 type뿐만 아니라, URI 또는 서비스를 설명하는 추가적 특성이 있는 serviceEndpoint가 있다.[2]

각주

  1. Adam Powers , 〈Understanding Decentralized IDs (DIDs)〉, 《medium》, 2018-07-02
  2. 2.0 2.1 W3C, 〈Decentralized Identifiers (DIDs) v1.0〉, 《W3C》, 2020-07-31

참고자료

같이 보기


  검수요청.png검수요청.png 이 DIDs 문서는 블록체인 기술에 관한 글로서 검토가 필요합니다. 위키 문서는 누구든지 자유롭게 편집할 수 있습니다. [편집]을 눌러 문서 내용을 검토·수정해 주세요.