Allen Dev Blog

탈중앙화 신원증명 DID
(3) Verifiable Credential

탈중앙화 신원증명 DID<br> (3) Verifiable Credential

이번 포스트에서는 검증 가능한 크리덴셜(Verifiable Credential) 에 대하여 알아보고, DID 를 활용하여 Verifiable Credential 을 발급 및 인증하는 방법에 대해 살펴볼 것입니다.

먼저 Credential 의 의미부터 알아볼까요? Credential 은 우리말로 신용증명서 또는 자격을 의미합니다. 우리는 일상 생활에서 Credential 을 제출해야 할 일이 생각보다 많이 있습니다. 대표적으로 술이나 담배를 사기 위해서는 만 19세 이상임을 증명하기 위하여 주민등록증 또는 운전면허증이라는 “신분증” (다르게 말하면 술 또는 담배를 구매할 수 있다는 “자격증”) 을 보여줘야 합니다. 이 “신분증” 도 하나의 Credential 이라고 할 수 있습니다.

우리는 이렇게 현실 세계에서 어떤 행위를 하기 위하여 “자격증” 이 필요한 경우가 많이 있습니다.

필요한 자격 자격 증명 방법
운전 운전면허증
술, 담배 구매 만 19세 이상 신분증
학생 인증 학생증

현실 세계에서는 이렇게 자격증을 제출함으로써 간단하게 자신의 행위에 대한 권한을 증명할 수 있지만 온라인 세계에서는 어떨까요? 물론 온라인 세계에서도 가능하지만 현실 세계보다 자격 증명을 하기가 굉장히 까다롭습니다. 예를 들어 웹에서 내가 A 학교를 졸업했다는 것을 증명하기 위해서는 어떻게 해야할까요?

결국에는 웹(온라인)에서 자격 증명을 하기위해서는 자격을 증명해줄 수 있는, 신뢰할 수 있는 인증 기관이 필요하게 됩니다. 하지만 인증 기관이 존재하더라도 우리는 온라인에서 자격 증명을 하는데 많은 어려움을 겪습니다.

우선 현실 세계에서 존재하는 자격증이 많이 있는만큼 각 자격 증명마다 인증 기관이 별도로 존재하게 됩니다. 따라서 우리가 온라인 상에서 복수의 자격 증명을 위해서는 각 인증 기관마다 따로 인증을 받아야 합니다.

또한 각 인증 기관마다 개개인의 자격 증명을 해주기 위하여 개개인의 개인 정보를 가지고 있을 것이고, 이는 그 기관이 해킹을 당했을 때 개인정보 유출이 될 수 있음을 의미합니다.

이 외에 단일 실패점(Single Point of Failure) 이 발생할 수 있습니다. 인증 기관이 어떤 이유로 오류가 나서 서비스 제공을 못하는 경우에는 자격 증명을 하지 못하게 됩니다. 만약 제가 온라인 상으로 복수의 자격 증명을 제출해야하는데 그 중 하나의 인증 기관에서 디도스 공격을 당하여 인증 서비스를 제공하지 못할 경우 저는 결국 자격 증명을 하지 못하게 됩니다.

이런 문제점을 해결하기 위해서 Verifiable Credential Ecosystem 이라는 개념이 탄생하게 되었으며, Verifiable Credential 은

  1. Credential 은 개개인이 소유하고 있어서 Issuer 랑 분리되어 있어 인증 기관의 부주의로 인한 개인정보 유출이나 단일 실패점이 발생하지 않음. (관리의 목적으로 인증 기관이 Credential 을 이중으로 가지고 있는 경우도 있음. 이 경우에는 개인정보 유출에서 자유롭지는 못함)
  2. 개개인이 Credential 을 가지고 있고, 자격 증명이 필요할 때 개개인이 Credential 을 가지고 제출하면 되므로 인증 과정에서 인증 기관을 거칠 필요가 없음.
  3. 각 개별의 Credential 이 표준에 의해 동일한 형태 및 구조를 가지고 있으므로 인증 과정의 간편화.

위와 같은 특징을 가지고 있습니다.

VC Ecosystem

W3C 에서는 Verifiable Credential Ecosystem 을 아래 그림과 같이 정의하고 있습니다.

Ecosystem 내에서는 Issuer, Holder, Verifier 가 존재하며, 데이터 저장소의 식별자 및 인증을 위한 스키마를 저장하는 Verifiable Data Registry 가 있습니다. 이전 포스트에서 설명했듯이 Data Registry 는 신뢰할 수만 있다면 어떤 형태로든 상관없지만 블록체인을 쓰는 경우가 많습니다.

Ecosystem 내에 존재하는 Issuer, Holder, Verifier 들이 각각 어떤 역할을 하는지 살펴보겠습니다.

Holder

Verifiable Credential 을 소유하고 관리하는 주체(Entity) 입니다. 현실 세계에서 우리는 술, 담배를 구매하기 위해 신분증을 제시하는데 이 신분증을 가지고 있는 개개인이 Holder 라고 할 수 있습니다.

Holder 는 Credential 을 발급받기 위해 인증 기관으로부터 Credential 을 달라고 요청할 수 있습니다. 이를 Claim 이라고 합니다.

기존의 인증 과정에서 온라인 상의 인증 과정에서 인증 정보를 인증 기관이 가지고 있던 것과 달리 Credential 정보를 개인(또는 단체)이 가지고 있으며(다만, 관리의 목적으로 인증 정보를 인증 기관이 개인과 별개로 이중으로 가지고 있는 경우도 있습니다) 개인은 이를 가지고 언제든지 인증 기관을 거치지않고, 자신의 자격을 증명할 수 있습니다.

Issuer

Verifiable Credential 을 발급(Issue) 하는 주체입니다. 즉, 기존의 개개인에게 자격 증명을 부여하는 인증기관에 해당합니다.

Issuer 는 Holder 로부터 Claim 을 받아서 Holder 에게 Credential 을 발급하여 Holder 에게 이를 건내줍니다. 이 Credential 에는 자격 증명에 대한 정보 및 Credential 유효 기간 등의 정보 등이 담겨있으며 이후에는 인증 과정에서 Holder 가 Issuer 를 거칠 필요가 없습니다.

Verifier

Verifier 는 Holder 가 자격이 있는지 확인하는 주체입니다. 사용자는 특정 서비스를 이용하기 위해서 그 서비스를 이용할 수 있는 권한이 있는지 여부를 판단하기 위해 서비스는 사용자에게 자격 증명을 요청할 수 있습니다. 이 자격 증명을 요청하고 자격 증명을 검증하는 주체가 Verifier 라고 할 수 있습니다.

Verifier 는 Holder 에게 자격 증명을 요청하게 되면 Holder 는 가지고 있는 Verifiable Credential 중에서 요청한 Credential 들을 모아서 Verifiable Presentation을 생성하여 Verifier 에게 제출합니다.

Verifier 는 그 Verifiable Presentation 을 Verifiable Data Registry 를 통해 검증합니다.

Claim

Holder 는 자격 증명을 받기 위해서 Issuer 에게 Claim 을 한다고 앞서 이야기하였습니다. 즉 자격 증명 요청이라고 보면 될 것 같습니다. 그럼 요청을 하기 위해 Claim 에는 어떤 데이터가 담겨있을까요?

Claim 은 위와 같이 Subject-Property-Value 관계를 가지고 있으며, Subject-Property-Value 자체도 값(Value) 가 될 수 있어서, Subject-Property-(Subject'-Property'-Value') 등의 값을 가질 수 있습니다.

위와 같은 경우에는 “Pat(Subject) 는 Example University(Value) 를 졸업(Property) 했고, Pat(Subject) 는 {Sam (Subject) 이 Professor(Value) 의 jobtitle(Property) 를 가지고 있다} (Value)를 알고(Property) 있다” 라는 데이터가 담긴 Claim 입니다.

VC (Verifiable Credential)

Holder 는 Issuer 에게 자격 증명을 부여받기 위해 Claim 을 요청하고, Issuer 는 Holder 에게 Verifiable Credential 을 건내준다고 앞에서 이야기하였습니다. 즉, Verifiable Credential 자체가 자격 증명이 담긴 데이터라고 볼 수 있습니다. 그럼 Verifiable Credential 안에는 어떤 데이터가 담겨 있으며 어떻게 자격 증명 데이터가 될 수 있는지에 대해 알아보겠습니다.

우선 Issuer 는 Holder 로부터 Claim 이 들어오면 그 Claim 안에 담긴 데이터를 검증합니다. 예를 들어, 위 Claim 예제에서 Pat 이 Example University 를 졸업하지 않았는데 Claim 이 들어오면 VC 를 발급하면 안될 것입니다.

Claim 정보가 이상이 없으면 Issuer 는 Verifiable Credential 을 발급하여 Holder 에게 제공합니다.

Verifiable Credential 은 위와 같은 구조를 가지고 있는데 우선 Claim 의 경우 Holder 가 요청한 Claim 정보 그대로 담기게 됩니다. Credential Metadata 에는 issuer 정보, Credential 만료 기간 등이 담기게 됩니다. 마지막으로 Proof 에는 이 Verifiable Credential 을 검증하기 위한 Signature 값 등이 담기게 됩니다.

Verifiable Credential 의 데이터는 JSON 형태로 표현할 수 있으며, 어떤 값이 담겨있는지 예제를 통해서 살펴보겠습니다.

{
  "@context": [
    "https://www.w3.org/2018/credentials/v1",
    "https://www.w3.org/2018/credentials/examples/v1"
  ],
  "id": "http://example.edu/credentials/1872",
  "type": ["VerifiableCredential", "AlumniCredential"],
  "issuer": "https://example.edu/issuers/565049",
  "issuanceDate": "2010-01-01T19:73:24Z",
  "credentialSubject": {
    "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
    "alumniOf": {
      "id": "did:example:c276e12ec21ebfeb1f712ebc6f1",
      "name": [{
        "value": "Example University",
        "lang": "en"
      }, {
        "value": "Exemple d'Université",
        "lang": "fr"
      }]
    }
  },
  "credentialStatus": {
      "id": "https://example.edu/status/24",
      "type": "CredentialStatusList2017"
  },
  "proof": {
    "type": "RsaSignature2018",
    "created": "2017-06-18T21:19:10Z",
    "proofPurpose": "assertionMethod",
    "verificationMethod": "https://example.edu/issuers/keys/1",   
    "jws": "eyJhbGciOiJSUzI1NiIsImI2NCI6ZmFsc2UsImNyaXQiOlsiYjY0Il19..TCYt5X
      sITJX1CxPCT8yAV-TVkIEq_PbChOMqsLfRoPsnsgw5WEuts01mq-pQy7UJiN5mgRxD-WUc
      X16dUEMGlv50aqzpqh4Qktb3rk-BuQy72IFLOqV0G_zS245-kronKb78cPN25DGlcTwLtj
      PAYuNzVBAh4vGHSrQyHUdBBPM"
  }
}

Verifiable Credential 에는 다양한 속성들이 들어가 있는데 W3C 에서 정의한 중요한 속성들을 하나하나씩 살펴보겠습니다.

@context 는 Verifiable Credential 을 두 개 또는 그 이상의 시스템끼리 서로 교환(Exchange) 할 때 호환을 위해 Verifiable Credential 의 데이터의 형식, 의미 등이 담겨있는 Specification 을 정의한 파일의 URL 을 가르킵니다. 이 @context 는 VC 내에 반드시 존재해야 하고, 배열 형태로 담기며, 배열의 첫번째 값으로 무조건 https://www.w3.org/2018/credentials/v1 이 담겨야 합니다.

id 는 이 Credential 의 Identifier 가 담기며 필수로 요구하는 값은 아닙니다. DID 와는 별개로 Credential 을 식별할 수 있는 식별자가 URI 형태로 담겨야 합니다.

types 는 필수로 있어야 하는 값이며, 이 데이터가 어떤 데이터를 담고 있는지 타입을 배열 형태로 정의합니다. VC 의 경우 VerifiableCredential 이 필수적으로 담겨야 하며, VP 의 경우 VerifiablePresentation 이 담겨야 합니다. 그 외에 추가적인 type 정보가 담길 수 있습니다.

issuer발급자 정보가 담겨 있으며, URI 형태로 존재하거나 issuer 의 DID 정보 등이 담길 수 있습니다.

issuanceDate발급 시간RFC3339 형태로 담겨야 합니다. W3C Spec 에 의하면 issuanceDatedeprecated 될 것이고, issued 로 대체 될 것이라 합니다. 따라서 VC 를 발급할 때는 issuanceDateissued 를 둘 다 정의하는게 호환성 측면에서 좋을 것입니다.

expirationDate 는 이 Verifiable Credential 의 만료 시간을 의미합니다. W3C Spec 에 의하면 이것 역시 deprecated 될 것이고, 미래에 만료 시간을 나타내는 validUntil 및 유효 시작 시간을 나타내는 validFrom 이 두개로 대체될 것으로 보입니다. 따라서 VC 를 발급할 때 둘 다 값을 넣는게 호환성 측면에서 좋을 것입니다.

credentialSubject유저가 claim 한 정보가 담겨 있습니다. 즉 Verifiable Credential 의 실제 자격 정보는 여기에 담겨있을 것입니다. 예제에서는 사용자가 Example University 를 졸업했다는 자격 정보를 claim 했고, Issuer (Example University) 가 credentialSubject 에 claim 정보를 담아서 VC 를 발급했다는 것을 알 수 있습니다.

credentialStatus 는 이 Verifiable Credential 의 상태 정보를 확인할 수 있는 정보가 담겨있습니다. 현실에서는 Credential 을 발급한 이후에 Credential 정보를 무효화해야 하는 경우도 있을 수 있습니다. 따라서 현재 이 Verifiable Credential 이 유효한지 체크할 수 있는 방법 또는 정보가 담깁니다.

proof 는 VC 값이 조작되지 않고, 유효한 VC 인지 판별하기 위한 Signature 등의 값들이 존재하며, Signature 알고리즘에 따라 필요한 값들이 달라지기 때문에 정해진 규격은 없고, DID System 을 개발하는 사람이 proof 안에 들어갈 값들을 정의하면 됩니다.

VP (Verifiable Presentation)

Holder 는 앞서 말한 VC 를 모두 소유하고 있으며 온라인 상에서 자격 인증이 필요할 때 VC 를 제공함으로써 인증을 할 수 있습니다. Verifier 에게 자격 인증 데이터를 제공하는데 이 때 Holder 는 VC 데이터를 그대로 전달하는게 아니라 VP(Verifiable Presentation)을 생성해서 넘겨주게 됩니다. 즉, VP 는 자격 인증을 위해 실제로 자격 인증 요청자에게 보내는 데이터입니다.

왜 VC 를 그대로 전달하는게 아니라 VP 를 만들어서 전달하는 것일까요? 이에 대한 설명을 VP 의 구조와 함께 설명해보겠습니다.

형태가 VC 와 매우 비슷해보입니다. VC 에서 Claim 정보가 담겨있었다면 VP 에서는 1개 이상의 VC 가 담겨져 있습니다. VP 에서 다수의 VC 를 담을 수 있기 때문에 자격 증명 요구자(Verifier) 가 Holder 에게 여러 개의 자격 증명을 요청한 경우에는 VP 에 복수의 VC 를 담아서 하나의 VP 만 전달하면 됩니다.

Presentation Metadata 에는 VC 의 Metadata 와 거의 유사하게 VP 의 Type 등 VP 에 대한 메타데이터가 정의되어 있습니다.

Proof 에는 VC 의 Proof 와 마찬가지로 검증하기 위한 Signature 값 이 들어가 있습니다. 차이가 있다면 VC 의 경우 Public Key 가 Issuer 의 것이라면 VP 는 Public Key 가 Holder 의 것입니다. 왜냐하면 VC 는 Issuer 가 발급해주는 것이고, VP 는 Holder 가 생성하는 것이기 때문입니다.

VP(Verifiable Presentation) 는 VC 의 형태와 매우 유사하며, 어떤 값들이 담겨있는지 예제를 통해서 살펴보겠습니다.

{
  "@context": [
    "https://www.w3.org/2018/credentials/v1",
    "https://www.w3.org/2018/credentials/examples/v1"
  ],
  "type": "VerifiablePresentation",
  "verifiableCredential": [{
    "@context": [
      "https://www.w3.org/2018/credentials/v1",
      "https://www.w3.org/2018/credentials/examples/v1"
    ],
    "id": "http://example.edu/credentials/1872",
    "type": ["VerifiableCredential", "AlumniCredential"],
    "issuer": "https://example.edu/issuers/565049",
    "issuanceDate": "2010-01-01T19:73:24Z",
    "credentialSubject": {
      "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
      "alumniOf": {
        "id": "did:example:c276e12ec21ebfeb1f712ebc6f1",
        "name": [{
          "value": "Example University",
          "lang": "en"
        }, {
          "value": "Exemple d'Université",
          "lang": "fr"
        }]
      }
    },
    "proof": {
      "type": "RsaSignature2018",
      "created": "2017-06-18T21:19:10Z",
      "proofPurpose": "assertionMethod",
      "verificationMethod": "https://example.edu/issuers/keys/1",
      "jws": "eyJhbGciOiJSUzI1NiIsImI2NCI6ZmFsc2UsImNyaXQiOlsiYjY0Il19..TCYt5X
        sITJX1CxPCT8yAV-TVkIEq_PbChOMqsLfRoPsnsgw5WEuts01mq-pQy7UJiN5mgRxD-WUc
        X16dUEMGlv50aqzpqh4Qktb3rk-BuQy72IFLOqV0G_zS245-kronKb78cPN25DGlcTwLtj
        PAYuNzVBAh4vGHSrQyHUdBBPM"
    }
  }],
  "proof": {
    "type": "RsaSignature2018",
    "created": "2018-09-14T21:19:10Z",
    "proofPurpose": "authentication",
    "verificationMethod": "did:example:ebfeb1f712ebc6f1c276e12ec21#keys-1",
    "challenge": "1f44d55f-f161-4938-a659-f8026467f126",
    "domain": "4jt78h47fh47",
    "jws": "eyJhbGciOiJSUzI1NiIsImI2NCI6ZmFsc2UsImNyaXQiOlsiYjY0Il19..kTCYt5
      XsITJX1CxPCT8yAV-TVIw5WEuts01mq-pQy7UJiN5mgREEMGlv50aqzpqh4Qq_PbChOMqs
      LfRoPsnsgxD-WUcX16dUOqV0G_zS245-kronKb78cPktb3rk-BuQy72IFLN25DYuNzVBAh
      4vGHSrQyHUGlcTwLtjPAnKb78"
  }
}

대부분의 속성이 VC 와 비슷하며, 차이점이 있다면 VC 에는 credentialSubject 에 claim 정보가 담겨있었다면 VP 는 verifiableCredentialVC 가 배열 형태로 들어가 있습니다. (Verifier 가 여러 Credential 을 요청한 경우 한 VP 에 여러 VC 를 담아서 제출하면 됩니다)

또한 VP 의 경우 type 이 VerifiableCredential 이 아니라 VerifiablePresentation 이 반드시 들어가 있어야 합니다. VC 와 VP 는 형태가 거의 동일하기 때문에 이 데이터가 VC 인지 VP 를 판별하기 위하여 이 type 을 사용할 것입니다.

또한 proof 안에는 replay attack 을 막기 위한 정보가 추가적으로 들어가 있습니다. replay attack 이란 VP 를 생성한 후 이 VP 가 유출되면 누군가가 이 VP 를 가지고 다른 곳에서도 인증할 수도 있기 때문에 VP 를 발급 요청한 사람에게만 유효한, 즉 1회성으로만 사용할 수 있도록 하기 위해 추가적인 데이터가 담긴다는 차이점이 있습니다.

Ethereum 기반의 Verifiable Credential

DIF(Decentralized Identity Foundation) 은 DID 시스템을 활발하게 개발하고 있는 단체 중 하나이며, 이 단체에서 Ethereum 기반으로 Verifiable Credential Ecosystem 을 구축한 did-jwt-vc 오픈 라이브러리를 살펴보도록 하겠습니다.

did-jwt-vc 라이브러리를 사용하여 앞서 말한 ethr-did 에서 생성한 이더리움 기반의 DID 로 Verifiable Credential 및 Verifiable Presentation 을 JWT 토큰 형태로 생성할 수 있습니다. (다만 W3C 에서 정의한 표준하고는 살짝 안맞는 부분이 있는 것 같습니다)

예제를 들어서 설명해보겠습니다. 우선 사용자 A 는 Example University 의 학사 학위를 받았으며, 이를 증명하기 위한 Verifiable Credential 을 생성해보고자 합니다. 이 예시에서 각각 Issuer, Holder 는 어떻게 될까요?

Role Who
Issuer Example University
Holder 사용자 A

우선 앞선 포스트에서 봤듯이 ethr-did 라이브러리를 사용하여 DID 를 생성합니다. 이 DID 는 Issuer (Example University) 의 DID 입니다.

import * as EthrDID from 'ethr-did'
import { Issuer } from 'did-jwt-vc'

const issuer: Issuer = new EthrDID({
  // Example University Wallet Address
  identifier: '0xf1232f840f3ad7d23fcdaa84d6c66dac24efb198',
  // Private Key of Example University Wallet
  privateKey: 'd8b595680851765f38ea5405129244ba3cbad84467d190859f4c8b20c1ff6c75'
})

이 DID 를 가지고, Verifiable Credential 을 생성합니다. Verifiable Credential 안에 들어갈 데이터, 즉 Claim 을 정의합니다.

const claims = {
  degree: {
    type: 'BachelorDegree',
    name: 'Example University'
  }
}

위 Verifiable Credential 의 정보는 Example University 의 학사 학위를 받았다는 내용이 담겨져 있습니다.

다음으로는 Verifiable Credential 의 Payload 를 정의할 차례입니다. Verifiable Credential 안에는 Claim 뿐만 아니라 Credential Metadata, Proof 정보 등이 추가적으로 담겨야합니다.

import { JwtCredentialPayload, createVerifiableCredentialJwt } from 'did-jwt-vc'

const vcPayload: JwtCredentialPayload = {
  sub: 'did:ethr:0x435df3eda57154cf8cf7926079881f2912f54db4',
  nbf: 1562950282,
  vc: {
    '@context': ['https://www.w3.org/2018/credentials/v1'],
    type: ['VerifiableCredential'],
    credentialSubject: claims
  }
}

const vcJwt = await createVerifiableCredentialJwt(vcPayload, issuer)
console.log(vcJwt)

위와 같이 Verifiable Credential 형태로 데이터를 담은 다음 createVerifiableCredentialJwt 함수로 issuer (Example University) 의 Private Key 로 Signature 를 생성하여 Verifiable Credential 을 JWT 형태로 생성합니다.

이번에는 이 VC 를 가지고, Holder 가 VP 를 생성해볼까요? 앞서 생성된 vcJwt 자체가 Verifiable Credential 이므로, 이 vcJwt 가 담긴 VP 를 생성하면 될 것입니다.

import { JwtPresentationPayload, createVerifiablePresentationJwt } from 'did-jwt-vc'

const holder = issuer;

const vpPayload: JwtPresentationPayload = {
  vp: {
    '@context': ['https://www.w3.org/2018/credentials/v1'],
    type: ['VerifiablePresentation'],
    verifiableCredential: [vcJwt]
  }
}

const vpJwt = await createVerifiablePresentationJwt(vpPayload, holder)
console.log(vpJwt)

위의 예제에서 보면, VP 이기 때문에 typeVerifiablePresentation 을 넣었으며, verifiableCredential 안에 vcJwt 값을 넣었습니다. 이 VP Payload 를 가지고, createVerifiablePresentationJwt 함수를 호출하여 VP 를 생성하면 됩니다. createVerifiableCredentialJwt 와 다르게 VP 는 Issuer 가 아니라 Holder 의 Private Key 로 Signature 를 생성해야 합니다. 왜냐하면 VP 는 Issuer 가 아니라 Holder 가 생성하는 것이기 때문입니다. (위 예제에는 Issuer 와 Holder 가 동일하지만 일반적으로는 Issuer 와 Holder 는 다른 DID 객체입니다)

마지막으로 Verifier 는 이 VP 를 받아서 VP 가 유효한지 판별해야 합니다.

import { Resolver } from 'did-resolver'
import { getResolver } from 'ethr-did-resolver'
import { verifyPresentation } from 'did-jwt-vc'

// see also https://github.com/decentralized-identity/ethr-did-resolver#multi-network-configuration
const providerConfig = {
  rpcUrl: 'https://mainnet.infura.io/v3/<YOUR infura.io PROJECT ID>',
  registry: '0xdca7ef03e98e0dc2b855be647c39abe984fcf21b'
}
const resolver = new Resolver(getResolver(providerConfig))

const verifiedVP = await verifyPresentation(vpJwt, resolver)
console.log(verifiedVP)

DID Resolver 는 앞선 포스트에서 말했듯이 DID 로부터 DID Document 를 가져오는 역할을 합니다. 이 DID Resolver 와 함께 VP 를 넘기면 JWT 의 Payload 값이 반환됩니다.

Conclusion

이번 포스트에서는 DID 를 활용하여 Verifiable CredentialVerifiable Presentation 을 생성하는 방법에 대해서 설명하였습니다.

Issuer사용자(Holder)에게 자격 증명 정보가 담긴 Verifiable Credential 을 발급해주면 사용자는 그것을 자신이 가지고 있다가 나중에 어느 누군가(Verifier)에게 자격 증명을 해야한다면 사용자는 필요한 자격 증명(VC)만 뽑아서 VP 를 생성 및 제출하여 자격 증명을 할 수 있습니다.

Verifier 의 경우 이 VP 를 블록체인 등의 자격 증명이 유효한지 체크할 수 있는 데이터 저장소를 통해 이 유저를 자격 증명할 수 있습니다.

현재 DID 는 계속 발전하고 있는 기술이기 때문에 Specification 도 계속 업데이트되고 있으며, 문서 또한 방대합니다. 포스트에서는 그 중에서 중요한 부분만 다뤘으며, 더 자세한 Specification 을 확인하려면 W3C 사이트를 살펴보시기를 권장합니다.

References

탈중앙화 신원증명 DID<br> (3) Verifiable Credential
Prev post

탈중앙화 신원증명 DID
(2) W3C DIDs

Next post

Redis Sorted Set 을 이용한
실시간 랭킹 시스템 구축

탈중앙화 신원증명 DID<br> (3) Verifiable Credential

Get in touch