DID는 어떻게 자기를 증명할 수 있을까?

DID

DID(Decentralized Identifiers)는 블록체인 생태계에서 입지가 점점 늘어나고 있는 기술입니다. 탈중앙성을 외치는 블록체인은 개인의 신원정보 또한 탈중앙화할 수 있다 말합니다. 지갑에 주민등록증을 보관하고 필요할 때 꺼내서 나를 증명하는 것 처럼, 사용자가 디지털 월렛에 개인정보를 담아 필요할 때 개인키를 이용해 자신을 증명하는 방식입니다. 중앙화된 등록 기관에 등록이 필요하지 않고 내 개인정보는 내가 소유하게 되는 것이지요. 

 

여기다 더해 DID는 VC(Verifiable Credentials)과 VP(Verifiable presentation)을 이용해 자신의 개인정보중 보여주고 싶은 특정한 정보만 골라서 보여줄 수 있습니다. 신분 검사로 인해 주민등록증을 보여줘야할 때 숨기고 싶은 내 증명사진을 굳이 안보여줄 수 있다는 것이죠.

 

DID의 특징을 정리하면 이렇습니다

 

• 개인 블록체인 월렛에 개인 정보를 담는다.
• 필요할 때, 필요한 만큼만 자기 자신을 증명한다.
• 개인정보 소유자인 개인 스스로 정보를 관리하고 통제한다.

 

DID는 자기주권 신원인증(SSI, Self sovereign identity)으로부터 나왔습니다.

 

 

SSI

자기주권 신원인증이란 자신을 증명할 수단을 스스로 결정하고 관리하는 것을 말합니다. 기존에는 통신 3사와 같은 기관이 나의 개인정보를 관리했다면, 이제는 '나' 스스로가 직접 관리로 전환이 된 것이죠. 디지털 세계에서 SSI를 형성하기 위해 두 가지 요소가 필요합니다.

• 식별자(Identifier) : 디지털 세상에서 내가 '나'임을 증명하기 위한 이름
• 아이덴티티 데이터(Identity data) : '나'라는 개체가 어떤 정보/속성을 가지고 있는지를 제시하고 증명하는 정보

자기주권 신원인증은 DID를 통해 현실화되고 있습니다.

 

 

---

 

1.1 DID 

 

DID는 3부분으로 구성되는 간단한 문자열입니다.

 

 

• URL scheme identifier : 여기에는 http, https를 포함한 다양한 프로토콜이 들어가는데 did가 들어갈 경우 did scheme이 정의한 자원 접근 방식에 따라 자원을 찾아갑니다.
• Identifier for the DID method: DID document가 어떤 저장소에 저장되어 있는지 보여줍니다. DID 플랫폼마다 부여된 고유의 심볼값입니다.(i.e., sov, upot, ethr, btcr 등)
• DID method-specific identifier: DID method가 가리키는 저장소 내 DID document가 저장된 정확한 위치를 검색할 수 있게 해주는 주소입니다. 해당 DID 플랫폼에서 부여한 고유의 식별 값입니다.

즉, DID는 DID document의 주소를 알려주는 URI이자 고유한 식별자가 됩니다. 대부분의 DID 플랫폼은 DID와 DID document 생성 시 비대칭키를 함꼐 생성합니다. 생성한 비대칭키의 private key는 사용자가 안전하게 보관하고, public key는 DID document에 넣어 저장합니다. 

 

 

1.2 DID document

 

DID document는 무엇일까요?

 

DID document는 DID controller를 암호화 방식으로 인증하는 방법과 같이 DID와 관련된 정보가 포함되어 있습니다. DID의 소유권을 증명할 수 있으며 사용자가 검증기관에게 DID를 주장할시에 DID document를 확인하여 그 사용자의 것임이 증명이 됩니다. 

 

다음은 W3C에 올라와 있는 DID document 예제입니다.

EXAMPLE 1: A simple DID document
{
  "@context": [
    "https://www.w3.org/ns/did/v1",
    "https://w3id.org/security/suites/ed25519-2020/v1"
  ],
  "id": "did:example:123456789abcdefghi",
  "publicKey": [{
    "id": "did:example:123456789abcdefghi#keys-1",
    "type": "RsaVerificationKey2018",
    "controller": "did:example:123456789abcdefghi",
    "publicKeyPem": "-----BEGIN PUBLIC KEY...END PUBLIC KEY-----\r\n"
  }],
  "authentication": [{
    "id": "did:example:123456789abcdefghi#keys-1",
    "type": "Ed25519VerificationKey2020",
    "controller": "did:example:123456789abcdefghi",
    "publicKeyMultibase": "zH3C2AVvLMv6gmMNam3uVAjZpfkcJCwDwnZn6z3wXmqPV"
  }],
  "controller": "did:example:bcehfew7h32f32h7af3",
  "service": [{
    
    "type": "VerifiableCredentialService",
    "serviceEndpoint": "https://example.com/vc/"
  }]
}

 

DID document에는 @context, id, publicKEy, authentication, controller, service 등의 항목이 있습니다. 각각의 항목에 어떤 데이터가 들어가는지 알아보겠습니다.

 

@context

서로 간의 정확한 통신을 위해 데이터가 어떤 값을 가지는지 정의를 내리는 역할을 수행합니다. @context 속성의 값은 반드시 하나 이상의 URIs 여야 하며, 여기서 첫 번째 URI의 값은 https://www.w3.org/ns/did/v1 입니다. 둘 이상의 URI가 제공될 경우, URIs는 반드시 순서있는 배열로 작성되어야 합니다. URIs를 역 참조하여 컨텍스트에 대한 판독 가능한 정보가 포함된 문서를 생성 하는 것이 좋습니다. 

EXAMPLE 2
{
"@context": "https://www.w3.org/ns/did/v1"
}

 

id

 

id에는 id를 통해 식별되는 객체의 DID가 들어갑니다. 이는 해당 DID document의 대상인 DID subject에 대한 DID 식별값입니다. 

 

public key

 

상대방과 상호작용 과정에서 암호학적으로 증명이 필요한 경우에 사용됩니다. 반드시 공개키 객체들의 배열이어야 하며, type, controller 속성 및 각 공개키에 특화된 속성을 반드시 포함해야 합니다. id의 경우 중복되지 않아야 하고, 값은 URI가 되야 합니다. 공개키는 여러 개가 될 수 있으므로 폐기가 된 키가 포함될 수도 있습니다. 이 때는 그 키에 대한 폐기 정보를 포함하거나 참조하고 있어야 합니다. 

 

모든 공개키의 형식은 반드시 publicKeyJwk 속성을 사용한 JWK(Json Web KEy) 포맷이거나, 아래 표에 설명한 포맷 중에 하나여야 합니다. 

Key Type	Support
RSA	RSA 공개키 값은 반드시 JWK로 인코딩하거나 publicKeyPem 속성을 사용하여 PEM(Privacy Enhanced Mail) 포맷으로 인코딩해야 한다.
ed25519	Ed25519 공개키 값은 반드시 JWK로 인코딩하거나 publicKeyBase58 속성을 사용하여 원시형태(raw)의 32 바이트 공개키 값을 Base58 비트코인 포맷으로 인코딩해야 한다.
secp256k1-koblitz	Secp256k1 Koblitz 공개키 값은 반드시 JWK로 인코딩하거나 publicKeyBase58 속성을 사용하여 원시형태의 33바이트 공개키 값을 Base58 비트코인 포맷으로 인코딩해야 한다.
secp256r1	Secp256r1 공개키 값은 반드시 JWK로 인코딩하거나 publicKeyBase58 속성을 사용하여 원시형태의 32바이트 공개키 값을 Base58 비트코인 포멧으로 인코딩해야 한다.
Curve25519	(X25519로도 알려진) Curve25519 공개키 값은 반드시 JWK로 인코딩하거나 publicKeyBase58 속성을 사용하여 원시형태의 32바이트 공개키 값을 Base58 비트코인 포맷으로 인코딩해야 한다.

 

authentication

 

인증 방식에 대한 정보들을 포함하고 있습니다. 권한 부여와 별개입니다. authentication의 속성 값은 검증 메소드의 배열이어야 합니다. 각각의 검증 방법은 포함되거나 참조될 수 있습니다. 검증 방법의 예로는 공개키 방식이 있습니다.

"authentication": [
    
    "did:example:123456789abcdefghi#keys-1",
    //이 키는 문서에 포함되어 있으며, 오직 인증 목적으로만 사용할 수 있습니다.
    {
      "id": "did:example:123456789abcdefghi#keys-2",
      "type": "Ed25519VerificationKey2018",
      "controller": "did:example:123456789abcdefghi",
      "publicKeyBase58": "H3C2AVvLMv6gmMNam3uVAjZpfkcJCwDwnZn6z3wXmqPV"
    }
  ],

 

controller

 

DID Document를 수정할 수 있는 주체입니다. DID Subject와 동일할 수도 있고, 동일하지 않은 경우도 있습니다.

 

Service

 

DID subject와의 인터렉션을 위한 Service-Endpoint 정보를 확인하는데 사용됩니다. Service-Endpoint는 DID subject가 운영하는 서비스 네트워크의 주소입니다. DID subject 또는 관련 개체와 통신할 수 있는 방법을 나타내기 위해 사용됩니다. 예시로는 검색 서비스, 소셜 네트워크, 파일 스토리지 서비스 및 verfiable claim 저장소 서비스 등이 있습니다. 서비스와 관련된 메타 데이터는 서비스마다 다릅니다. 

 

서비스에 대한 포인터는 service 속성을 사용하여 표현합니다. 각 서비스에는 고유한 id와 type뿐만 아니라 URI, 서비스를 설명하는 추가적인 특성이 있는 Service-Endpoint가 포함됩니다. 

 

1.3 생태계

 

이제 DID와 DID document가 어떻게 해서 자기를 증명하는지 알아보겠습니다.

 

 

아래 그림은 DID 생태계에서 핵심 행위자들의 역할과 관계에 대해 나온 그림입니다.

각 행위자별로 살펴보겠습니다. 

 

Holder

엔티티가 하나 이상의 검증 가능한 자격 증명을 보유하고 검증 가능한 프레젠테이션을 생성하여 수행할 수 있는 역할입니다. 홀더의 예에는 학생, 직원 및 고객이 포함됩니다.

 

Issuer

엔터티가 하나 이상의 주제에 대한 클레임을 주장하고, 이러한 클레임에서 검증 가능한 자격 증명을 만들고, 보유자에게 검증 가능한 자격 증명을 전송하여 수행하는 역할입니다. 발행자의 예로는 기업, 비영리 조직, 무역 협회, 정부 및 개인이 있습니다.

 

Subject

클레임이 제기되는 엔터티입니다. 예시 주제에는 인간, 동물 및 사물이 포함됩니다. 많은 경우 검증 가능한 자격 증명의 소유자가 주체이지만 그렇지 않은 경우도 있습니다. 예를 들어, 부모(보유자)는 어린이(주체)의 검증 가능한 자격 증명을 보유할 수 있고, 애완 동물 소유자(보유자)는 애완 동물(주체)의 검증 가능한 자격 증명을 보유할 수 있습니다. 

 

Verifier

엔터티가 처리를 위해 선택적으로 검증 가능한 프레젠테이션 내부에서 하나 이상의 검증 가능한 자격 증명을 수신하여 수행하는 역할입니다. 검증인의 예로는 고용주, ​​보안 요원 및 웹사이트가 있습니다.

 

Verifiable data registry

확인 가능한 자격 증명을 사용하는 데 필요할 수 있는 확인 가능한  verifiable credential 스키마, 해지 레지스트리, 발급자 공개 키 등과 같은 식별자, 키 및 기타 관련 데이터의 생성 및 확인을 중재하여 시스템이 수행할 수 있는 역할입니다. 일부 구성에는 주제에 대한 관련 식별자가 필요할 수 있습니다. 검증 가능한 데이터 레지스트리의 예에는 신뢰할 수 있는 데이터베이스, 분산 데이터베이스, 정부 ID 데이터베이스 및 분산 원장이 포함됩니다. 종종 생태계에서 활용되는 검증 가능한 데이터 레지스트리 유형이 두 가지 이상 있습니다.

 

 

DID 발급과정

 

 

(1) 먼저 Holder와 Issuer는 DID와 DID document를 생성하고 등록해야 합니다.

(2) Holder는 DID 소유권 증명을 위해서 비대칭키를 생성하고, private key는 안전한 지갑에 보관하고, public key는 DID document를 생성하는데 사용됩니다. 

(3) DID와 DID document를 생성한 후에 DID document는 블록체인에 등록됩니다. Holder와 마찬가지로 Issuer도 DID를 생성한 후에 DID document를 블록체인에 등록합니다. 

 

 

다음 포스트에는 이어서 VC와 VP에 대한 내용으로 찾아뵙겠습니다. 감사합니다 !

 

 

 

 

 

참고 링크

https://www.w3.org/TR/did-core/