검증가능한 자격증명

검증가능한 자격증명(Verifiable credentials)은 정보가 변경되었는지 쉽게 확인할 수 있는 아이디(ID) 데이터 혹은 클레임들과 누가 발행하였는지를 암호학적으로 확인할 수 있는 메타데이터의 집합이다. 검증 자격은 물리적인 것과 같은 모든 정보를 나타낼 수 있는 자격증명을 나타낸다. 디지털 서명과 같은 기술이 추가됨에 따라 검증가능한 자격증명이 물리적 자격증명보다 변조 방지 및 신뢰성이 높아졌다.

개요

검증가능한 자격증명은 디지털 세계에서 물리 세계의 증명서와 동일한 역할을 하는 것으로 사진, 이름, 식별번호 등 증명할 주제와 관련된 정보, 발행 기관과 관련된 정보, 증명이 어떻게 도출되었는가에 대한 증거, 그리고 만료일 정보를 포함한다. 검증가능한 자격증명 모델은 자격증명 공급자(Identity provider, IDP)를 아이덴티티 생태계의 중심에 배치하여 개인이 자신의 아이덴티티 속성을 제어할 수 있도록 한다. 이것은 아이디 공급자를 배치하는 SAML 및 OpenID Connect에서 채택한 FIM(Federated Identity Management) 모델과 대조된다. 자격증명 공급자는 아이디 속성의 분배자 및 이를 제공할 서비스 공급자의 결정자 역할을 한다. 통합 모델에서는 자격증명 공급자가 방문하는 모든 서비스 공급자를 알고 있기 때문에 사용자의 개인정보가 침해된다. 반면에, W3C VC 모델은 오늘날 우리가 신분증을 사용하는 방식과 유사하다. 사용자는 지갑에 플라스틱 카드를 넣고 카드 발급사의 허가 없이 언제든지 누구에게나 제시할 수 있다. 이러한 모델은 분산되어 있으며 참가자에게 훨씬 더 많은 자율성과 유연성을 제공한다.

특징

생태계

검증가능한 자격증명의 생태계는 다음과 같이 구성된다.

• 보유자(Holder) : 하나 또는 그 이상의 검증가능한 자격증명을 소유하고 있는 개체(entity)로, 검증가능한 자격증명에서 제공하는 아이디 프레젠테이션(Presentations)을 생성한다.
• 발급자(Issuer) : 검증가능한 자격증명을 생성하는 개체로 특정 주체(subject)와 검증가능한 자격증명을 연결하고 이를 소유자에게 전달하는 역할을 담당한다.
• 대상(Subject) : 소유자와 같은 학생들, 고객들 그리고 직원일 수도 있으며, 애완동물을 기르는 주인 등일 수도 있다. 하나 또는 그 이상의 검증가능한 자격증명의 대상으로 많은 경우 (소유자 = 주체)가 되기도 하지만, 항상 그렇지는 않다.
• 검증인(Verifier) : 고용주, 보안 요원 그리고 웹사이트 등이 될 수 있다. 소유자에게 검증 가능한 검증가능한 프레젠테이션을 전달받아 소유자가 소유한 검증가능한 자격증명에 특정한 특성을 가지고 있는지 확인하는 개체이다.
• 검증가능한 데이터 저장소(Verifiable data registry) : 신뢰가능한 데이터베이스, 분산형 데이터베이스, 정부 아이디 데이터 등이 포함된다. 식별자(identifiers), 키(keys) 그리고 관련 데이터를 생성하고 검증하는 중재 시스템이다.

자기주권신원(SSI, Self-sovereign Identity) 체계는 아래의 도식과 같이 표현될 수 있다. 이 데이터의 흐름을 설명해 주는 것이 검증가능한 자격증명 데이터 모델이다.

이 생태계 안에서 주체와 역할을 나누어보자면, 발급자(Issuer)는 특정 대상(subject)에 대한 검증가능한 자격증명(verifiable credentials)을 생성하고 그것을 보유자(holder)에게 전달한다(예: 정부, 회사, 기관, 단체, 개인 등). 보유자는 하나 또는 그 이상의 자격증명을 소유하고 있고, 그것을 통해 프레젠테이션(presentations)을 생성한다(예: 학생, 직원, 고객 등). 대상(subject)은 검증의 대상이 되는 주체이다. 보유자가 대상이 될 수도 있지만 다른 경우도 있다. 예를 들면 부모(holder)가 아이(subject)를 증명하는 경우나 건물주가 부동산을 증명하는 경우 등의 예외도 있다(예 : 사람, 동물, 사물). 검증인(verifier)은 보유자로부터 검증가능한 프레젠테이션(verifiable presentaton)을 요청함으로써 보유자가 적절한 검증가능한 자격증명을 보유하고 있는지 확인한다(예: 고용주, 보안 담당자, 웹 사이트 등). 검증가능한 데이터 저장소(verifiable data registry)는 발급자, 키 및 관련 데이터를 생성 또는 검증하는 중재 시스템이다. 보통 하나 이상의 시스템이 활용된다(예: 분산원장, 탈중앙 DB, 정부 ID DB 등).

보유자가 인증을 해야 할 상황이 발생하면, 해당 내용을 인증할 수 있는 자격증명을 발행할 수 있는 발급자에 검증가능한 자격증명 발행을 요청한다. 발급자는 보유자가 적법한 권한을 가지고 있는지 확인 후 보유자에게 자격증명을 발행하고 발행과 관련된 사항을 데이터 저장소에 등록 및 내용에 대해 서명을 수행한다. 보유자는 자격증명을 취득하고 발급자가 서명한 내용에 대해 서명한다. 보유자는 인증을 필요로 하는 대상인 검증인이 요구하는 수준의 정보를 정의한 검증가능한 프레젠테이션을 생성하여 검증인에게 전달한다. 검증인은 검증가능한 데이터 저장소에 해당 내용을 확인하고 내용에 문제가 없을 경우 검증을 완료한다.

데이터 모델

클레임

간단히 말하면, 아이디 데이터 혹은 클레임(Claims)은 대상에 대한 설명이라고 할 수 있다. 아이디 데이터 혹은 클레임은 대상(subject) - 특성(property) - 정보(value) 간의 관계로 표현된다. 대상에 대한 특성을 정보로 표현하는 것이다.

클레임에 대한 데이터 모델은 위의 (그림2)와 같이 표현된다. 예를 들어, 어느 대학생(subject)이 특정 대학(value)을 졸업했다. 와 같이 다양한 설명을 표현할 수 있다.

더 나아가, 개별적인 아이디 데이터 혹은 클레임들은 결합하여 대상에 대해 더 많은 내용을 설명할 수 있는 정보 그래프를 만들 수도 있다. 정보 그래프는 대상과 대상들 간의 혹은 데이터와의 관계를 도식화 한 정보 네트워크를 의미한다. 아래의 예를 살펴보면 (그림3)에서 확대되어 '팻(Pat)'은 'OO대학'의 동문이면서 '샘(Sam)'이 교수라는 사실을 알고 있다는 것을 나타내고 있다.

자격증명

자격증명(credentials)은 하나의 개체(entity)에 의해 만들어진 하나 또는 그 이상의 아이디 데이터 혹은 클레임(claim)의 집합이다. 여기에는 식별자(identifier)와 발급자, 만료 날짜와 시간, 대표 이미지와 검증을 위한 공개키(public key) 그리고 파기 방법 등 자격증명을 설명하는 메타데이터(metadata) 등을 포함한다. 첫 번째 그래프는 자격증명(credential) 자체를 나타내고 있다. 아이디 데이터 또는 혹은 클레임(claim)은 노란색 박스로 설명되어 있고 이 자격증명의 내용은 핑크색으로 표현되어 있다. 초록색으로 강조되어 있는 두 번째 그래프는 전자적인 증명을 나타내고 있으며, 일반적으로 전자서명을 통해 이루어진다.

검증가능한 프레젠테이션

프라이버시라고도 종종 표현되는 개인정보보호는 데이터를 다룰 때 매우 중요하다. 이에 따라 사용자는 상황에 따라 꼭 필요한 데이터만을 제공하고 서비스 제공자는 활용해야한다. 검증가능한 자격증명의 데이터 모델에서는 주어진 상황에서 사용자가 적절한 데이터만을 제공할 수 있는 방안을 제시한다. 예를 들어 설명한다면, 알콜이 들어간 음료를 사는 사람은 자신이 미성년자인지 아닌지만을 증명하면 되고 주소나 이름에 대한 정보를 제공할 필요가 없도록 하는 것이다. 이렇게 누군가 혹은 무엇인가를 설명하는 정보에 대한 일부분의 조합을 검증 가능한 '검증가능한 프레젠테이션'(verifiable presentation)이라고 한다. 검증 가능한 검증가능한 프레젠테이션은 하나 또는 그 이상의 검증가능한 자격증명의 데이터들로 표현되며 누가 이 검증 가능한 검증가능한 프레젠테이션을 만든 소유자(holder)를 검증할 수 있는 방식으로 구성된다. 제공하는 아이디 프레젠테이션의 데이터는 대개 동일한 대상(subject)에 대해 여러 발행자(Issuer)에 의해 발행된 내용들로 이루어져 있다. 조금 더 간단히 설명하자면, 만약 자격증명(credentials)이 직접적으로 제공된다면, 이 역시 제공하는 아이디 프레젠테이션이 된다. 다음 도표는 보통 최소 4개의 정보 그래프로 구성된 검증 가능한 검증가능한 프레젠테이션의 예를 보여주고 있다. 가장 상단의 보라색으로 표현된 그래프에서는 제공하는 아이디 프레젠테이션을 보여주고 있는데, 이는 제공하는 아이디 프레젠테이션의 메타데이터를 포함하고 있다. 검증 가능한 검증가능한 프레젠테이션은 하나 또는 그 이상의 검증가능한 자격증명을 참조하고 있는데, 참조하고 있는 자격증명 그래프에는 노란색 박스로 설명되어 있는 아이디 데이터 또는 혹은 클레임과 핑크색 박스로 표기되어 있는 자격증명 그리고 메타데이터가 포함되어 있다. 세 번째, 녹색으로 표현되어 있는 부분은 자격증명 그래프에 대한 증명이 설명되어 있으며 이는 일반적으로 전자서명을 통해 이루어진다. 그리고 가장 마지막에 파란색으로 표현되어 있는 제공하는 아이디 집합 증명 그래프는 일반적으로 전자서명으로 이루어지는 제공하는 아이디 프레젠테이션을 누가 발행하였는지 정보의 변화가 있었는지를 암호학적으로 확인할 수 있는 방안을 제공한다.

수명주기

앞 부분에서 그래픽 개념을 사용하여 클레임, 검증가능한 자격증명 및 검증가능한 프레젠테이션 등의 개념을 설명했다. 자격증명 및 검증가능한 프레젠테이션의 수명주기는 종종 다음과 같은 공통 경로를 취한다. 1) 하나 이상의 검증가능한 자격증명 발급, 2) 자격증명 저장소에 검증가능한 자격증명 저장, 3) 검증자를 위해 검증가능한 자격증명을 검증가능한 데이터 지합으로 구성, 4) 검증자에 의한 검증가능한 프레젠테이션의 검증이다. 이 수명주기를 설명하기 위해 대학에서 동문 할인을 사용하는 예를 사용한다. 아래 예에서 팻(Pat)은 대학교로부터 동문임을 검증가능한 자격증명을 받고, 검증가능한 자격증명을 디지털 지갑에 저장한다.

예시 1: 검증 가능한 크리덴셜의 간단한 예
{
   // set the context, which establishes the special terms we will be using
   // such as 'issuer' and 'alumniOF'.
   "@context": [
    "https://www.w3.org/2018/credentials/v1",
    "https://www.w3.org/2018/credentials/examples/v1"
  ],
  // specify the identfier for the crendential
  "id": "http://example.edu/credentials/1872",
  // the credential types, which declare what data to expect in the credential
  "type": ["VerifiableCredential", "AlumniCredential"],
  // the entity that issued the credential
  "issuer": "https://example.edu/issuers/565049",
  // when the credential was issued
  "issuanceDate": "2010-01-01T19:73:24Z",
  // claims about the subjects of the credential
  "credentialSubject": {
    // identifier for the only subject of the credential
    "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
    
    "alumniOf": {
      "id": "did:example:c276e12ec21ebfeb1f712ebc6f1",
      "name": [{
        "value": "Example University",
        "lang": "en"
      }, {
        "value": "Exemple d'Université",
        "lang": "fr"
      }]
    }
  },
  // digital proof that makes the credential tamper-evident
  // see the NOTE at end of this section for more detail
  "proof": {
    // the cryptographic signature suite that was used to generate the signature
    "type": "RsaSignature2018",
    // the date the signature was created
    "created": "2017-06-18T21:19:10Z",
    // purpose of this proof
    "proofPurpose": "assertionMethod",
    // the identifier of the public key that can verify the signature
    "verificationMethod": "https://example.edu/issuers/keys/1",
    // the digital signature value
    "jws": "eyJhbGciOiJSUzI1NiIsImI2NCI6ZmFsc2UsImNyaXQiOlsiYjY0Il19..TCYt5X
      sITJX1CxPCT8yAV-TVkIEq_PbChOMqsLfRoPsnsgw5WEuts01mq-pQy7UJiN5mgRxD-WUc
      X16dUEMGlv50aqzpqh4Qktb3rk-BuQy72IFLOqV0G_zS245-kronKb78cPN25DGlcTwLtj
      PAYuNzVBAh4vGHSrQyHUdBBPM"
   }
}

팻은 동문 할인을 받으려 한다. 판매 시스템인 검증자는 "OO 대학"의 모든 동창생이 스포츠 행사에 대한 시즌 티켓 할인을 받는다. 팻은 모바일 장치를 사용하여 시즌 티켓 구매 프로세스를 시작한다. 이 프로세스의 단계는 동문 검증가능한 자격증명을 요청하며 이 요청은 팻의 디지털 지갑으로 라우팅된다. 디지털 지갑은 팻에게 이전에 발급된 검증가능한 자격증명을 제공할 것인지 묻는다. 팻은 동문 검증가능한 자격증명을 선택하여 검증가능한 프레젠테이션으로 구성한다. 검증가능한 프레젠테이션이 검증자에게 전송되고 검증된다.

예시 2: 검증 가능한 프레젠테이션의 간단한 예
{
  "@context": [
    "https://www.w3.org/2018/credentials/v1",
    "https://www.w3.org/2018/credentials/examples/v1"
  ],
  "type": "VerifiablePresentation",
  // the verifiable credential issued in the previous example
  "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"
    }
  }],
  // digital signature by Pat on the presentation
  // protects against replay attacks
  "proof": {
    "type": "RsaSignature2018",
    "created": "2018-09-14T21:19:10Z",
    "proofPurpose": "authentication",
    "verificationMethod": "did:example:ebfeb1f712ebc6f1c276e12ec21#keys-1",
    // 'challenge' and 'domain' protect against replay attacks
    "challenge": "1f44d55f-f161-4938-a659-f8026467f126",
    "domain": "4jt78h47fh47",
    "jws": "eyJhbGciOiJSUzI1NiIsImI2NCI6ZmFsc2UsImNyaXQiOlsiYjY0Il19..kTCYt5
      XsITJX1CxPCT8yAV-TVIw5WEuts01mq-pQy7UJiN5mgREEMGlv50aqzpqh4Qq_PbChOMqs
      LfRoPsnsgxD-WUcX16dUOqV0G_zS245-kronKb78cPktb3rk-BuQy72IFLN25DYuNzVBAh
      4vGHSrQyHUGlcTwLtjPAnKb78"
   }
}

관련 개념

컨텍스트

두 소프트웨어 시스템이 데이터를 교환해야 하는 경우 두 시스템이 이해하는 용어를 사용해야 한다. 비유하자면 두 사람이 어떻게 의사소통을 하는지 고려해보자. 두 사람 모두 같은 언어를 사용해야하며 그들이 사용하는 단어는 서로 같은 것을 의미해야 한다. 이것을 대화의 맥락 즉, 컨텍스트라고 할 수 있다. 검증가능한 자격증명 및 검증가능한 프레젠테이션에는 URIs로 식별되는 많은 속성과 값이 있다. 그러나 이러한 URIs는 길고 사람에게 친숙하지 않을 수 있다. 이러한 경우, 짧은 형태의 인간 친화적인 별칭이 더 도움이 될 수 있다. 이 사양에서는 @context 속성을 사용하여 이러한 짧은 별칭을 특정 검증가능한 자격증명 및 검증가능한 프레젠테이션에 필요한 URI에 매핑한다. 검증가능한 자격증명 및 검증가능한 프레젠테이션에는 반드시 @context 속성이 포함되어야 한다. @context의 속성 값은 첫 번째 항목이 https://www.w3.org/2018/credentials/v1 값을 갖는 URI인 순서 집합이어야 한다. 배열의 후속 항목은 반드시 컨텍스트 정보를 표현해야하며 URIs 또는 객체의 조합으로 구성되어야 한다. @context의 각 URI는 역참조되는 경우 @context에 대한 기계 판독 가능 정보를 포함하는 문서를 생성하는 URI 이어야 한다. 이 사양에서는 @context 속성이 있어야 하지만 @context 속성의 값을 JSON-LD를 사용하여 처리할 필요는 없다. 이는 검증가능한 크리덴셜이 JWT로 인코딩될 때 사용되는 것처럼 일반 JSON 라이브러리를 사용한 처리를 지원하기 위한 것이다. 모든 라이브러리 또는 프로세서는 @context 속성의 값 순서가 특정 응용 프로그램에 예상되는 순서여야한다. JSON-LD를 지원하는 라이브러리 또는 프로세서는 예상대로 전체 JSON-LD 처리를 사용하여 @context 속성을 처리할 수 있다.

예시 3: @context 속성의 사용법
{
  "@context": [
    "https://www.w3.org/2018/credentials/v1",
    "https://www.w3.org/2018/credentials/examples/v1"
  ],
  "id": "http://example.edu/credentials/58473",
  "type": ["VerifiableCredential", "AlumniCredential"],
  "credentialSubject": {
    "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
    "alumniOf": {
      "id": "did:example:c276e12ec21ebfeb1f712ebc6f1",
      "name": [{
        "value": "Example University",
        "lang": "en"
      }, {
        "value": "Exemple d'Université",
        "lang": "fr"
      }]
    }
  },
  "proof": {  }
}

위의 예는 기본 컨텍스트 URI(https://www.w3.org/2018/credentials/v1)를 사용하여 대화가 검증가능한 자격증명에 관한 것임을 설정한다. 두 번째 URI (https://www.w3.org/2018/credentials/examples/v1)는 대화가 예제에 관한 것임을 설정한다.

식별자

사람, 제품 또는 조직과 같은 특정한 것에 대해 표현할때, 다른 사람들이 동일한 것을 표현할 수 있도록 식별자를 사용하는 것이 유용하다. 이 규격에서는 이러한 식별자들에 대한 선택적 id 속성을 정의한다. id 속성은 사람, 제품 또는 조직과 같은 객체를 명확하게 참조하기 위한 것이다. id 속성을 사용하면 검증가능한 자격증명을 통해 특정한 사물을 표현할 수 있게 된다. 만약 id 속성이 존재한다면, id 속성을 표현할 때 반드시 다른 사용자들이 특정 사물을 표현할 때 사용할 것으로 예상되는 식별자로 표현해야 한다. 그리고 id 속성은 반드시 하나의 값만 가져야 하며 id 속성의 값은 반드시 URI 이어야 한다. id 속성 값은 반드시 단일 URI여야 한다. 역참조되는 경우 URI는 id에 대한 기계판독가능정보를 포함한 문서를 생성하는 것이 권장된다.

예시 4: Usage of the id property
{
  "@context": [
    "https://www.w3.org/2018/credentials/v1",
    "https://www.w3.org/2018/credentials/examples/v1"
  ],
  "id": "http://example.edu/credentials/3732",
  "type": ["VerifiableCredential", "UniversityDegreeCredential"],
  "credentialSubject": {
    "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
    "degree": {
      "type": "BachelorDegree",
      "name": "Bachelor of Science and Arts"
    }
  },
  "proof": {  }
}

위의 예는 두 가지 유형의 식별자를 사용한다. 첫 번째는 검증가능한 자격증명을 위한 것이며 HTTP 기반 URL을 사용한다. 두 번째는 검증가능한 자격증명의 주체(클레임이 관련된 것)를 위한 것이며 분산아이디(DID)라고도하는 탈중앙식별자를 사용한다.

타입

이 문서에 지정된 객체들을 처리하는 소프트웨어 시스템은 제공된 검증가능한 자격증명 또는 검증가능한 프레젠테이션이 적절한지 여부를 결정하기 위해 type 정보를 사용한다. 이 규격은 타입 정보 표현에 대한 type 속성을 정의한다. 검증가능한 자격증명과 검증가능한 프레젠테이션에는 반드시 type 속성이 있어야 한다. 따라서 type 속성이 없는 자격증명 또는 프레젠테이션은 검증을 할 수 없으므로 검증가능한 자격증명이나 검증가능한 프레젠테이션이 아니다. type 속성의 값은 반드시 맵핑된(@context 속성의 해석을 통해), 하나 또는 이상의 URIs다. 만약 복수의 URI들이 제공되었다면, URIs는 순서가 없는 집합으로 해석해야 한다. 개발편의를 위해 문법적 편의성을 반드시 사용해야 한다. 이러한 편의성에는 JSON-LD 용어가 포함될 수 있다. type의 각 URI가 역참조되는 경우 type에 대한 기계판독가능정보가 포함된 문서를 생성하는 것이 권장된다.

예시 5: Usage of the type property
{
  "@context": [
    "https://www.w3.org/2018/credentials/v1",
    "https://www.w3.org/2018/credentials/examples/v1"
  ],
  "id": "http://example.edu/credentials/3732",
  "type": ["VerifiableCredential", "UniversityDegreeCredential"],
  "credentialSubject": {
    "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
    "degree": {
      "type": "BachelorDegree",
      "name": "Bachelor of Science and Arts"
    }
  },
  "proof": {  }
}

규격준수와 관련하여, 다음 표에는 객체들이 반드시 가져야 하는 타입이 명시되어 있다.

Object	Type
Verifiable credential object(a subclass of a credential object)	VerifiableCredential and, optionally, a more specific verifiable credential type. For example, "type": ["VerifiableCredential", UniversityDegreeCredential"]
Credential object	VerifiableCredential and, optionally, a more specific verifiable credential type. For example, "type": ["VerifiableCredential", UniversityDegreeCredential"]
Verifiable presentation object(a subclass of a presentation object)	VerifiablePresentation and, optionally, a more specific verifiable presentation type. For example,"type": ["VerifiablePresentation", CredentialManagerPresentation"]
Presentation object	VerifiablePresentation and, optionally, a more specific verifiable presentation type. For example, "type": ["VerifiablePresentation", CredentialManagerPresentation"]
Proof object	A valid proof type. For example, "type": "RsaSignature2018"
credentialStatus object	A valid credential status type. For example, "type": "CredentialStatusList2017"
termsOfUse object	A valid terms of use type. For example, "type": "OdrlPolicy2017")
evidence object	A valid evidence type. For example, "type": "DocumentVerification2018"

모든 자격증명, 프레젠테이션, 그리고 캡슐화된 객채들은 추가정보를 처리할 수 있도록, 더욱 제한된 타입들(예를 들어 UniversityDegreeCredential과 같은)을 반드시 명시하거나 연관시켜야 한다. 이 규격에 정의된 캡슐화된 객체 (예를 들어 credentialSubject객체와 관련되거나 깊이 중첩된 객체들)들을 처리할 때, 소프트웨어 시스템은 객체를 캡슐화할 때 사용된 상위 계층의타입 정보를 사용해야 한다. 구체적으로 자격증명과 같은 캡슐화된 객체들은 연관된 객체 타입을 전달하여, 검증자가 캡슐화 객체의 타입에 기초하여 관련 객체의 내용을 신속하게 파악할 수 있어야 한다.

자격 주체

검증가능한 자격증명에는 하나 이상의 주체들에 대한 클레임이 포함된다. 이 규격은 하나 이상의 주체들에 대한 클레임을 표현하기 위한 항목인 credentialSubject 속성을 정의한다. 검증가능한 자격증명에는 무조건 credentialSubject 속성이 있어야 한다. 속성의 값은 검증가능한 자격증명의 주체와 각각 관련된 하나 이상의 특성을 포함하는 객체 세트로 정의된다. 각 객체에는 id가 포함될 수도 있다.

예시 6: credentialSubject 속성 사용
{
  "@context": [
    "https://www.w3.org/2018/credentials/v1",
    "https://www.w3.org/2018/credentials/examples/v1"
  ],
  "id": "http://example.edu/credentials/3732",
  "type": ["VerifiableCredential", "UniversityDegreeCredential"],
  "credentialSubject": {
    "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
    "degree": {
      "type": "BachelorDegree",
      "name": "Bachelor of Science and Arts"
    }
  },
  "proof": {  }
}

검증가능한 자격증명으로 여러 주체와 관련된 정보를 표현할 수 있다. 아래의 예는 배우자 관계인 두 주체를 지정한다. 여러 주체를 credentialSubject 특성과 연관시키기 위해 배열 표기법을 사용한다.

예시 7: 검증가능한 크리덴셜로 여러 주체 지정
{
  "@context": [
    "https://www.w3.org/2018/credentials/v1",
    "https://www.w3.org/2018/credentials/examples/v1"
  ],
  "id": "http://example.edu/credentials/3732",
  "type": ["VerifiableCredential", "RelationshipCredential"],
  "credentialSubject": [{
    "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
    "name": "Jayden Doe",
    "spouse": "did:example:c276e12ec21ebfeb1f712ebc6f1"
  }, {
    "id": "did:example:c276e12ec21ebfeb1f712ebc6f1",
    "name": "Morgan Doe",
    "spouse": "did:example:ebfeb1f712ebc6f1c276e12ec21"
  }],
  "proof": {  }
}

발급자

이 규격은 검증가능한 자격증명의 발급자를 표현하기 위한 속성을 정의한다. 검증가능한 자격증명은 무조건 issuer 속성이 있어야 한다. issuer 속성 값은 무조건 URI이거나 id 속성을 포함하는 객체여야한다. issuer 또는 해당 id의 URI는 역참조 된 경우 크리덴셜에 표시된 정보를 검증하는 데 사용할 수 있는 issuer에 대한 기계판독 가능한 정보를 포함하는 문서를 생성하는 URI 여야 한다.

예시 8: 발급자 특성의 사용
{
  "@context": [
    "https://www.w3.org/2018/credentials/v1",
    "https://www.w3.org/2018/credentials/examples/v1"
  ],
  "id": "http://example.edu/credentials/3732",
  "type": ["VerifiableCredential", "UniversityDegreeCredential"],
  "issuer": "https://example.edu/issuers/14",
  "issuanceDate": "2010-01-01T19:23:24Z",
  "credentialSubject": {
    "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
    "degree": {
      "type": "BachelorDegree",
      "name": "Bachelor of Science and Arts"
    }
  },
  "proof": {  }
} 

객체를 발급자 특성과 연관시켜 발급자에 대한 추가 정보를 표현할 수도 있다.

예시 9: 발급자 확장형 특성 사용
{
  "@context": [
    "https://www.w3.org/2018/credentials/v1",
    "https://www.w3.org/2018/credentials/examples/v1"
  ],
  "id": "http://example.edu/credentials/3732",
  "type": ["VerifiableCredential", "UniversityDegreeCredential"],
  "issuer": {
    "id": "did:example:76e12ec712ebc6f1c221ebfeb1f",
    "name": "Example University"
  },
  "issuanceDate": "2010-01-01T19:23:24Z",
  "credentialSubject": {
    "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
    "degree": {
      "type": "BachelorDegree",
      "name": "Bachelor of Science and Arts"
    }
  },
  "proof": {  }
}

발급 날짜

이 규격은 자격증명이 유효한 날짜 및 시간을 표현하기 위한 issuanceDate 속성을 정의한다. 자격증명은 무조건 issuanceDate 속성을 가져야 한다. issuanceDate 속성의 값은 자격증명이 유효한 날짜와 시간을 나타내는 [RFC3339] 결합 날짜 및 시간 문자열의 문자열 값이어야하며 이는 미래의 날짜와 시간일 수 있다. 이 값은 credentialSubject 속성과 연관된 정보가 유효해지는 가장 빠른 시점을 나타낸다.

예시 10: issuanceDate 속성 사용
{
  "@context": [
    "https://www.w3.org/2018/credentials/v1",
    "https://www.w3.org/2018/credentials/examples/v1"
  ],
  "id": "http://example.edu/credentials/3732",
  "type": ["VerifiableCredential", "UniversityDegreeCredential"],
  "issuer": "https://example.edu/issuers/14",
  "issuanceDate": "2010-01-01T19:23:24Z",
  "credentialSubject": {
    "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
    "degree": {
      "type": "BachelorDegree",
      "name": "Bachelor of Science and Arts"
    }
  },
  "proof": {  }
}

증명

자격증명 또는 프레젠테이션이 검증가능한 자격증명 또는 검증가능한 프레젠테이션이 되도록 최소한 하나의 증명 메커니즘과 그 증거를 평가하는데 필요한 세부 사항을 표현해야 한다. 즉, 검증 할 수 있어야 한다. 이 규격은 두가지 종류의 메커니즘을 식별한다: 외부 증명과 내장된 증명. 외부 증명은 JSON 웹 토큰과 같은 데이터 모델의 표현을 감싸는 것이다. 내장된 증명은 linked data signature와 같은 데이터에 증명이 포함되는 메커니즘이다. 또한 변조를 감지하고 자격증명 또는 프레젠테이션의 소유권을 확인하는 데 사용할 수 있는 하나 이상의 암호화 증명이다. 내장된 증명에 사용되는 특정 방법은 무조건 type 속성을 사용하여 포함해야한다. 수학적 증명에 사용되는 방법은 표현 언어와 사용 된 기술에 따라 다르므로 proof 속성의 값으로 예상되는 이름-값 쌍 세트는 그에 따라 달라진다. 예를 들어, 증명 메커니즘에 디지털 서명이 사용되는 경우 proof 속성에는 서명, 서명 엔터티에 대한 참조 및 서명 날짜 표시가 포함된 이름-값 쌍이 있어야 한다. 아래 예는 RSA 디지털 서명을 사용한다. 증명을 포함할 때는 proof 속성을 무조건 사용해야 한다.

예시 11: 검증가능한 크리덴셜에 프루프 속성 사용
{
  "@context": [
    "https://www.w3.org/2018/credentials/v1",
    "https://www.w3.org/2018/credentials/examples/v1"
  ],
  "id": "http://example.gov/credentials/3732",
  "type": ["VerifiableCredential", "UniversityDegreeCredential"],
  "issuer": "https://example.edu",
  "issuanceDate": "2010-01-01T19:73:24Z",
  "credentialSubject": {
    "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
    "degree": {
      "type": "BachelorDegree",
      "name": "Bachelor of Science and Arts"
    }
  },
  "proof": {
    "type": "RsaSignature2018",
    "created": "2018-06-18T21:19:10Z",
    "proofPurpose": "assertionMethod",
    "verificationMethod": "https://example.com/jdoe/keys/1",
    "jws": "eyJhbGciOiJQUzI1NiIsImI2NCI6ZmFsc2UsImNyaXQiOlsiYjY0Il19
      ..DJBMvvFAIC00nSGB6Tn0XKbbF9XrsaJZREWvR2aONYTQQxnyXirtXnlewJMB
      Bn2h9hfcGZrvnC1b6PgWmukzFJ1IiH1dWgnDIS81BH-IxXnPkbuYDeySorc4
      QU9MJxdVkY5EL4HYbcIfwKj6X4LBQ2_ZHZIu1jdqLcRZqHcsDF5KKylKc1TH
      n5VRWy5WhYg_gBnyWny8E6Qkrze53MR7OuAmmNJ1m1nN8SxDrG6a08L78J0-
      Fbas5OjAQz3c17GY8mVuDPOBIOVjMEghBlgl3nOi1ysxbRGhHLEK4s0KKbeR
      ogZdgt1DkQxDFxxn41QWDw_mmMCjs9qxg0zcZzqEJw"
  }
}

만료

이 사양에서는 크리덴셜 만료 정보 표현을위한 expirationDate 속성을 정의한다. 존재하는 경우, expirationDate 속성의 값은 무조건 자격증명이 유효하지 않은 날짜와 시간을 나타내는 [RFC3339] 결합 날짜 및 시간 문자열의 문자열 값이어야 한다.

예시 12: expirationDate 속성의 이용
{
  "@context": [
    "https://www.w3.org/2018/credentials/v1",
    "https://www.w3.org/2018/credentials/examples/v1"
  ],
  "id": "http://example.edu/credentials/3732",
  "type": ["VerifiableCredential", "UniversityDegreeCredential"],
  "issuer": "https://example.edu/issuers/14",
  "issuanceDate": "2010-01-01T19:23:24Z",
  "expirationDate": "2020-01-01T19:23:24Z",
  "credentialSubject": {
    "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
    "degree": {
      "type": "BachelorDegree",
      "name": "Bachelor of Science and Arts"
    }
  },
  "proof": {  }
}

상태

이 규격은 검증가능한 자격증명의 현재 상태(예를들어 일시중지 또는 취소)에 대한 정보를 검색하기 위해 다음 credentialStatus속성을 정의한다. credentialStatus 속성의 값은 무조건 다음 사항들을 포함해야 한다. 1) id 속성은 무조건 URL이여야 한다, 2) type 속성은 자격증명 상태 유형(자격증명 상태 메소드라고도 함)을 나타낸다. 이 값은 자격증명의 현재 상태를 판별하기에 충분한 정보를 제공해야 한다. 예를 들어, 자격증명의 일시 중지 여부에 대한 외부 문서 링크가 포함될 수 있다. 자격증명 상태 정보의 정확한 내용은 특정 credentialStatus유형 정의에 의해 결정되며 구현이 간단한지 또는 개인정보 보안강화 여부와 같은 요소에 따라 다르다.

예시 13: 상태 속성 사용예시
{
  "@context": [
    "https://www.w3.org/2018/credentials/v1",
    "https://www.w3.org/2018/credentials/examples/v1"
  ],
  "id": "http://example.edu/credentials/3732",
  "type": ["VerifiableCredential", "UniversityDegreeCredential"],
  "issuer": "https://example.edu/issuers/14",
  "issuanceDate": "2010-01-01T19:23:24Z",
  "credentialSubject": {
    "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
    "degree": {
      "type": "BachelorDegree",
      "name": "Bachelor of Science and Arts"
    }
  },
  "credentialStatus": {
    "id": "https://example.edu/status/24",
    "type": "CredentialStatusList2017"
  },
  "proof": {  }
}

상태 체계에 대한 데이터 모델, 형식 및 프로토콜 정의는 이 사양에서 다루지 않는다. 검증가능한 자격증명 상태 확인의 구현을 원하는 개발자가 사용할 수 있는 상태 스키마를 포함하는 Verifiable Credentials Extension Registry [VC-EXTENSION-REGISTRY]가 존재한다.

프레젠테이션

프레젠테이션들은 자격증명을 결합하고 제시하는데 사용될 수 있다. 이들은 데이터의 소유권을 검증가능한 방식으로 결합할 수 있다. 프레젠테이션의 데이터는 대부분 동일한 주체에 관한 것이지만, 데이터의 주체나 발급자 수에는 제한이 없다. 여러 검증가능한 자격증명에서 정보를 합치는 것은 일반적인 검증가능한 프레젠테이션의 사용법이다. 검증가능한 프레젠테이션은 보통 다음과 같은 속성들로 구성되어있다.

• id : id속성은 선택적이고 프레젠테이션의 고유한 식별자로 사용될 수 있다.
• type : type속성은 필수적이고 VerifiablePresentation 같이 프레젠테이션의 유형을 표현한다.
• verifiableCredential : 만약 verifiableCredential속성이 존재한다면, 최소 한 개 이상의 검증가능한 프레젠테이션이나 암호학적으로 검증가능한 형태의 검증가능한 크리덴셜의 데이터로 무조건 구성되어야 한다.
• holder : 만약 holder속성이 존재한다면, 이 프레젠테이션을 생성하는 엔터티의 URI여야 한다.
• proof: 만약 proof속성이 존재한다면, proof의 값이 프레젠테이션이 검증가능한 것 임을 보장한다.

아래 예제는 검증가능한 자격증명을 포함하고 있는 검증가능한 프레젠테이션을 보여준다.

예시 14: 프레젠테이션의 기본 구조
{
  "@context": [
    "https://www.w3.org/2018/credentials/v1",
    "https://www.w3.org/2018/credentials/examples/v1"
  ],
  "id": "urn:uuid:3978344f-8596-4c3a-a978-8fcaba3903c5",
  "type": ["VerifiablePresentation", "CredentialManagerPresentation"],
  "verifiableCredential": [{  }],
  "proof": [{  }]
}

위에 표시된 verifiableCredential 속성의 내용은 이 사양에 설명된 대로 검증가능한 자격증명이다. proof속성의 내용은 Linked Data Proofs [LD-PROOFS] 사양에 설명 된 증명방법이다.

• 파생된 자격증명으로 만드는 프레젠테이션

일부 영지식증명 체계는 보유자가 검증가능한 자격증명 자체를 밝히지 않고 검증가능한 자격증명으로부터 클레임들을 보유하고 있음을 간접적으로 입증 할 수 있도록 해준다. 이러한 방식에서, 검증가능한 자격증명의 클레임들은 제시된 값을 도출하는데 사용될 수 있으며, 이는 검증자가 발급자를 신뢰하는 경우, 암호학적으로 그 값을 보장할 수 있다. 예를 들어, 생년월일 클레임이 포함된 검증가능한 자격증명을 사용하여 15세 이상의 제시된 값을 암호학적으로 검증 가능한 방식으로 도출할 수 있다. 즉, 검증자는 발급자를 신뢰하는 경우 파생된 값을 계속 신뢰할 수 있다.

영지식증명을 사용하는 선택적 공개 체계에서는 이 모델에 표현된 클레임들을 사용하여 해당 클레임에 대한 추가적인 주장들을 만들어낼 수 있다. 예를 들어, 어떤 주체의 생년월일을 나타내는 클레임은 해당 주체의 나이가 주어진 범위 안에 있음을 증명하는데 사용될 수 있고, 따라서 대상이 나이 관련 할인을 받을 수 있음을 실제로 주체의 생년월일을 밝히지 않고 증명할 수 있다. 보유자는 원하는 검증가능한 프레젠테이션에 적용할 수 있는 방식으로 클레임을 사용할 수 있는 유연성을 가지게 된다.

참고자료

• Sovrin white paper - https://sovrin.org/wp-content/uploads/2018/03/Sovrin-Protocol-and-Token-White-Paper.pdf
• IT위키 - http://itwiki.kr/w/%EB%B6%84%EC%82%B0_ID
• 유서웅, 〈Verifiable Credential Model의 개념〉, 《미디엄》, 2019-02-16
• 유서웅, 〈Verifiable Credential의 Data참조 흐름 및 검증〉, 《미디엄》, 2019-02-28
• metadium, 〈검증가능한 자격증명과 제공하는 ID 데이터 집합 가이드〉, 《브런치》, 2019-07-18
• W3C, 〈Verifiable Credentials Data Model 1.0〉, 《W3C》, 2019-11-19
• 권동승, 이현, 박종대, 〈디지털 신뢰 사회 실현을 위한 디지털 아이덴티티 동향〉, 《ERTI》, 2019-09-16
• 최형주 기자, 〈(기고) 2020, 블록체인 기술 전망〉, 《씨씨티브이뉴스》, 2020-01-31
• W3C, 〈Linked Data Proofs 1.0〉, 《W3C》, 2020-03-03
• Wikipedia, 〈Verifiable credentials〉, 《Wikipedia》, 2020-06-01

같이 보기

• 분산아이디
• 영지식증명
• W3C

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

블록체인 : 블록체인 기술 □■⊕, 합의 알고리즘, 암호 알고리즘, 알고리즘, 블록체인 플랫폼, 블록체인 솔루션, 블록체인 서비스 블록체인 기술 Bech32 • BTP • DRC-20 • EIP • IPFS • KRC-20 • NFT 마켓플레이스 • P2P • P2PKH • P2SH • PFP • PUF • SPV • TPS • TRC-20 • UTXO • 가나슈 • 가명성 • 가스 • 가십 • 가십 프로토콜 • 개념증명(PoC) • 검증가능지연함수(VDF) • 게스 • 고스트 프로토콜 • 공공예산 • 글로벌신뢰인공지능 • 대체가능토큰 • 대체불가토큰(NFT) • 도지더리움 브릿지 • 디지털 자산 • 디지털 희소성 • 라운드 • 라운드 로빈 • 라이트하우스 • 랜덤 • 레그테크 • 레이든 • 리카르디안 계약 • 린스타트업 • 마스터키 • 마스트 • 메인넷 • 멜팅 • 믹싱 • 민팅 • 밈블윔블 • 반감기 • 베타넷 • 변경불가성 • 브릿지 • 블록체인 생태계 • 블록체인 클라우드 서비스(BaaS) • 블룸필터 • 비블록체인 • 비앱 • 비콘체인 • 비트코인코어 • 빤통경제 • 수정 고스트 프로토콜 • 스냅샷 • 스마트 계약 • 스마트 브리지 • 스웜프로토콜 • 스크립트퍼브키 • 스테이킹 • 스텔스 주소 • 스핀오프코인 • 슬래싱 • 시크릿 컨트랙트 • 심플 컨트랙트 • 아토믹스왑 • 암호경제(크립토 이코노미) • 앤드어스체인인공지능 • 앵커링 • 언스테이킹 • 에어드랍 • 에폭 • 오프체인 오더락 • 오피리턴 • 옵코드 • 원토큰 문제 • 웨이 • 위스퍼 프로토콜 • 위임 • 유니스왑 • 유동성 • 이더리움 가상머신(EVM) • 이더리움 클라이언트 • 이중지불 • 익명성 • 인증된 익명 아이디 • 인터레저 프로토콜(ILP) • 자산화 • 잠금 스크립트 • 최소기능제품(MVP) • 컨소시엄 블록체인 • 컬러드코인 • 코인셔플 • 코인소각 • 코인에이지 • 코인조인 • 코인토싱 • 크립토노트 • 키스토어 • 타임락 • 테스트넷 • 토다 • 토큰 이코노미 • 토큰화 • 튜링완전 • 튜링불완전 • 트랜잭션 아이디(TxID) • 트러스트 컨트랙트 • 트루빗 • 트릴레마 • 파워 • 파티셔닝 • 퍼블릭 블록체인 • 페널티 • 프라이버시 • 프라이빗 블록체인 • 플랫폼 • 플러딩 • 피어 • 피투피(P2P) • 하이브리드 블록체인 • 합의 • 해시락 • 해시타임락(HTLC) • 해제 스크립트 • 확장성 해시 레인보우 테이블 • 매핑 • 머클경로 • 머클루트 • 머클트리 • 분산해시테이블(DHT) • 블록해시 • 스큐드 머클트리 • 온라인툴즈 • 이전블록해시 • 카뎀리아 • 해시 • 해시레이트 • 해시맵 • 해시충돌 • 해시테이블 • 해시파워 • 해시함수 • 해싱 블록 고아블록 • 그래핀 • 논스 • 마이크로블록 • 베이킹 • 북키퍼 • 브랜치블록 • 브로드캐스팅 • 블록 • 블록높이 • 블록바디 • 블록생성자 • 블록정보 • 블록타임 • 블록헤더 • 비츠 • 세그윗 • 엉클블록 • 완결성 • 제네시스블록 • 타임스탬프 • 프룻 • 프룻체인 체인 더블체인 • 라이트닝 네트워크 • 라이트닝 루프 • 루트체인 • 루프체인 • 메인체인 • 방향성 비순환 그래프(DAG) • 베리파이어블 프루닝 • 블록격자 • 블록체인 • 사용자 활성화 소프트포크(UASF) • 사용자 활성화 하드포크(UAHF) • 사이드체인 • 서브체인 • 소프트포크 • 오페라체인 • 오프체인 • 온체인 • 인터체인 • 차일드체인 • 체인 • 탱글 • 테스트체인 • 토카막 네트워크 • 포크 • 포크체인 • 퓨어체인 • 프로덕트체인 • 프루닝 • 프리포크 • 플라즈마 알고리즘 • 플라즈마캐시 • 플래시 계층 • 하드포크 • 해시그래프 • 홀로체인 노드 검증인(밸리데이터) • 기본노드 • 노드 • 라이트노드 • 랜덤노드 • 마스터노드 • 베이킹노드 • 보조노드 • 보증노드 • 슈퍼노드(슈퍼대표, 대표노드) • 슬롯 • 슬롯리더 • 엔드포인트노드(레인저노드) • 의회 네트워크 • 작업노드 • 종단노드 • 종자노드(시드노드) • 중계노드 • 지갑노드 • 채굴노드(마이닝노드) • 쿼럼 • 풀노드 • 합의노드 샤딩 네트워크 샤딩 • 데이터베이스 샤딩 • 동적샤딩 • 샤드 • 샤딩 • 스테이트 샤딩 • 알고리즘 샤딩 • 적응형 상태 샤딩 • 체인샤딩 • 트랜잭션 샤딩 채굴 병합채굴 • 사전채굴 • 에이식(ASIC) • 에이식부스트 • 에이식 저항 • 일드파밍 • 채굴 • 채굴 난이도 • 채굴량 • 탄소감축채굴 • 페어런치 탈중앙화 TVL • 거버넌스 • 게임파이 • 다오(DAO) • 다이코(DAICO) • 닥(DAC) • 닥스(DAX) • 덱스(DEX) • 디앱(DApp) • 디지오(DGO) • 디튜브 • 디파이(DeFi) • 분산경제 • 분산원장(DLT) • 분산 클라우드 • 소셜파이 • 씨파이(C-Fi) • 오프체인 거버넌스 • 온체인 거버넌스 • 원장 • 준중앙화 • 중앙화 • 탈중앙화 • 탈중앙화 TPS • 탈중앙화 조직(DO) • 탈중앙화 지수(DQ) 분산아이디 DIDs • IETF • ToIP • 검증가능한 자격증명 • 검증인 • 디지털아이덴티티재단 • 발급자 • 보유자 • 분산아이디(DID) • 분산아이디 기관 • 분산아이디 인증(DID Auth) • 아이온 • 자기주권 • 자기주권신원 • 최소화된 자격증명 데이터 • 탈중앙화 키관리시스템 • 통합해석기 오라클 상호인증 블록체인 • 오라클 • 오라클 머신 • 오라클 문제 • 오라클 서비스 • 중간자 BIP BIP • BIP9 • BIP16 • BIP32 • BIP39 • BIP43 • BIP44 • BIP47 • BIP49 • BIP63 • BIP70 • BIP84 • BIP141 • BIP148 ERC ERC • ERC-20 • ERC-165 • ERC-223 • ERC-621 • ERC-721 • ERC-777 • ERC-827 • ERC-884 • ERC-998 • ERC-1155 • ERC-1404 위키 : 자동차, 교통, 지역, 지도, 산업, 기업, 단체, 업무, 생활, 쇼핑, 블록체인, 암호화폐, 인공지능, 개발, 인물, 행사, 일반