Ch 1 - DID & DID document

DID study

Ch 1 - DID & DID document

Sila 2022. 8. 12. 14:35

1.1 DID (decentralized identifier)

1.1.1 DID의 개념

기존 주민 등록번호같은 중앙화된 식별자는 중앙 기관을 통해 발급되는 구조이다.

반면 DID (Decentralized Identifier)는 사용자 스스로 생성, 제어할 수 있는 분산형/탈중앙화형 식별자이다.

DID는 DID를 사용하는 subject에 대한 식별자로 사용되는 것에 더해

인증 수단인 DID document를 참조할 수 있는 uri역할까지 수행한다.

DID는 다음과 같은 구조를 가진다.

1. scheme : uri가 어떤 프로토콜을 사용해 자원에 접근하는지 명시 (did의 경우 항상 did를 값으로 가진다 http, https등과 같은 범주)

2. method : DID doument가 어떤 저장소 (보통 블록체인의 종류)에 저장되어 있는지 명시한다.

(btcr이면 비트코인 블록체인에, eth면 이더리움에..)

3. Method-specific identifier : 블록체인 상에서 DID document의 정확한 위치를 명시한다.

1.1.2 DID 생성 메커니즘

DID, DID document는 사용자(holder)가 생성하는데

우선 DID를 생성하고, DID document를 생성한 후, DID document를

DID method, method-specific identifier에 대응하는 곳에 저장한다.

다른 사용자가 (신원 인증을 요구하는 = verifier) 내 DID 주소를 안다면 이에 접근할 수 있다.

동시에 비대칭키 (공개키, 개인키 한 쌍)을 함께 생성하는데,

개인키는 본인이 잘 보관하고 (다른 사람은 모르게), 공개키는 did document에 넣어 블록체인에 저장한다.

( did에 특화된 sovrin 블록체인의 경우, 공개키의 일부를 가져와 이를 method-specific identifier로 사용)

1.2 DID document

DID document는 블록체인에 저장되는 특정 DID의 소유권을 증명(DID Auth)하는데 사용되는 인증 수단에 포함되어 있다.

holder한테 did:ethr:1234라는 DID가 있는데, 이를 검증기관(verifier)에게 증명하고 싶으면 다음과 같은 단계를 따르면 된다.

i) verifier에게 DID를 알려주면 verifier가 DID document를 가져온다.

ii) verifier가 가져온 did document를 가지고 holder에게 DID가 정말 holder의 것인지 인증을 요구한다. ( Challenge )

> DID document가 있어야 인증이 진짜인지 아닌지 알 수 있으므로..

iii) holder는 challenge에 해당하는 response를 전송한다.

iv) verifier는 did document를 이용해 holder가 보낸 response를 분석한 후, 정말 본인이 맞는지 판단한다.

우리가 지문인식으로 본인 인증을 하겠다고 did document에 등록을 해둔 상태라면, challenge는 지문인증 요구,

response는 내 지문에 해당한다고 보면 된다.

{
  "@context": "https://www.w3.org/ns/did/v1",
  
  "id": "did:ethr:qwer1234",

  "publicKey": [{
    "id": "did:ethr:qwer1234#keys-1",
    "type": "RsaVerificationKey2018",
    "controller": "did:ethr:qwer1234",
    "publicKeyPem": "-----BEGIN PUBLIC KEY...END PUBLIC KEY-----\r\n"
  }, {
    "id": "did:ethr:qwer1234#keys-2",
    "type": "Ieee2410VerificationKey2018",
    "controller": "did:ethr:qwer1234",
    "publicKeyPem": "-----BEGIN PUBLIC KEY...END PUBLIC KEY-----\r\n"
  }],

  "authentication": [
    "did:example:123456789abcdefghi#keys-1",
    "did:example:123456789abcdefghi#keys-2",
  ],

  "service": [{
    "id": "did:example:123456789abcdefghi#oidc",
    "type": "OpenIdConnectVersion1.0Service",
    "serviceEndpoint": "https://openid.example.com/"
  }]
}

DID document는 다음과 같은 구조를 갖는다.

context, id, publicKey, authentication, service 5가지의 요소가 있는데 각각 하나씩 공부해보자.

1.2.1 Id

id는 식별되는 객체(subject)의 did가 들어간다. 이는 verifier가 holder에게 본인 인증을 요구하면서 did document를 블록체인 상에서

찾을 때 이용되는데, verifier가 id를 이용해 블록체인 상에 해당 id를 가진 did document를 요청해 did document를 획득할 수 있다.

1.2.2 publicKey, authentication

publicKey, authentication은 did 소유권 인증에 사용된다.

우선 publicKey를 보면 소유권 인증에 사용할 수 있는 데이터가 배열 형태로 모여있다.

{
    "id": "did:ethr:qwer1234#keys-1",
    "type": "RsaVerificationKey2018",
    "controller": "did:ethr:qwer1234",
    "publicKeyPem": "-----BEGIN PUBLIC KEY...END PUBLIC KEY-----\r\n"
}

그 중 하나를 가져와서 각각이 의미하는 바를 생각해보자.

- id : 해당 '인증 방식의 id'라고 볼수 있다. 만약 위의 인증방식으로 본인 인증을 진행하겠다면

이 인증방식의 id값인 "did:ethr:qwer1234#keys-1" 를 verifier에게 정해서 알려주면 된다.

- type : 인증 방식이 무엇인지 알려준다. 공개키를 이용한 인증, 지문을 이용한 인증등이 가능하다.

- publicKey : 소유권 인증에 사용될 데이터가 있다. 공개키를 이용한 인증이라면 공개키 값이, 지문인증이라면 지문 데이터가 있다.

- controller : 인증 권한을 가진 사람이 누구인지 알려준다. 공개키를 이용한 인증이라면 개인키를 가진 사람이 controller가 된다.

이는 반드시 holder 본인이 아닐 수도 있다. 발급 기관(issuer)를 이용한 대리 인증일 수도 있기 때문.

authentication은 해당 did document가 제공하는 소유권 인증 방식의 id가 배열로 저장되어 있다.

did document 전체를 보면 인증 방식이 총 두가지 있는데, 이 둘의 id를 배열로 담고 있는 것을 확인할 수 있다.

i) 본인 인증은 우선 verifier가 did document에서 authentication을 보고 인증 방식 목록을 확인한 후,

이 중 어떤 인증 방식을 사용할 것인지 holder에게 물어본다.

ii) 사용할 인증 방식을 holder가 정한다.

iii) verifier는 지정한 방식의 id를 publicKey에서 찾아 그 데이터로 검증을 시작한다.

1.2.2.1 controller와 holder가 다른 경우

holder가 어떤 조직 (이하 aaaa) 소속이라는 것을 증명하고 싶을 경우, aaaa가 관련된 인증을 해주는 경우가 있다.

이 경우, controller 항목은 aaaa의 did를 가지게 된다.

검증 방식을 정하고 검증을 시작할 때, verifier는 controller에게 인증 요청을 보내는데,

만약 aaaa의 did가 did:ethr:aaaa라면 이 did로 DID auth를 요청한다.

aaaa는 회사 내부 시스템을 확인해 holder에게 did를 발급한 기록이 있는지 확인하고,

기록이 있다면 해당 did를 생성할 때 같이 만든 비대칭키의 개인키로 did auth를 진행한다.

1.2.2.2 did holder를 포함해 다른 사람도 인증 권한을 가질 수 있는 경우

holder가 did의 개인키를 잃어버렸을 때, issuer등 함께 인증 권한을 가진 주체가 있을 경우 새로운 인증키를 바꿀 수 있다.

만약 did:ethr:qwer1234#keys-1를 잃어버렸다고 하면 holder는 해당 데이터의 publicKeyPem 값의 변경을 '블록체인에' 요청한다.

이 때, 다른 인증 수단을 이용해 본인 인증을 수행해야 해야하는데,

블록체인은 사용자의 did:ethr:qwer1234#keys-2의 controller did(보통 issuer)에게 did auth를 요청한다.

did:ethr:qwer1234#keys-2의 controller는 holder에게 본인 인증을 받은 후, 블록체인에 holder 본인이 맞다고 인증을 해준다.

블록체인은 이를 확인 후, 변경을 요청한 publicKey의 값을 변경한다.

1.2.2.3 did holder를 제외하고 다른 사람만 인증 권한을 가질 수 있는 경우

did auth 권한을 이용하는데 다른 did만이 인증을 해줄 수 있도록 정할 수도 있다.

이 경우 did document에는 publicKey가 없으며 controller를 찾기 위한 serviceEndPoint 항목이 대신 존재한다.

또한 controller는 publicKey 내부가 아닌, did document 가장 상위에 존재하게 된다.

1.2.3 service

service 항목은did를 활용한 서비스들을 의미한다. 방금 공부한 공개 키를 바꾼다던가 하는 기능도 이에 포함된다

앞에서 holder와 별개의 controller가 있을 때, 이 controller에게 인증 요청을 보내는 것도 사실 이 service 항목을 확인해서

이루어진다.

did에는 인증 요청을 받는 것은 없기 때문에 controller에게 요청을 보내려면 추가적으로 이 항목이 필요한 것이다.

이를 구체적으로 어떻게 사용하는지에 관해선 ch3에서 좀 더 자세히 알아본다.

1.2.4 @context

어떤 두 주체가 상호작용할 때는 주고 받는 데이터가 명확하게 정의되어야 한다.

내가 한 데이터를 전송할때 이 데이터 타입이 number라고 생각을 했는데, 저 쪽에서는 string으로 받도록 정해두었으면

상호작용 과정에서 문제가 생길 가능성이 다분하다.

나한테는 이 항목이 있는데 저 쪽에는 그 항목 자체가 없는 경우도 있고..

@context는 이런 문제가 발생하는 것을 막기 위해 did document에 들어가는 나머지 항목들 (id, publicKey, service 등)이

어떤 의미를 갖는 데이터인지, 거기에 어떤 종류의 데이터가 들어가야 하는지 혹은 어디를 참조하는지 명시해 지정한다.

@context는 JSON-LD 문법에 따라 정의된다. (JS object notation for linked data)

JSON-LD엔 다양한 문법이 있지만 지금은 @context, @id, @type 정도만 알면 충분하다.

/* JSON-LS의 @context 사용 예제  */

{
    "@context" : {
        "name" : "http://schema.org/name",
        "image" : {
            "@id" : "http://schema.org/image",
            "@type" : "@id"
        },
        
        "homepage" : {
            "@id" : "http://schema.org/url",
            "@type" : "@id"
        }
    },
    "name" : "LSJ",
    "image" : "https://www.example.com/myImg",
    "homepage" : "https://www.example.com"
}

1.2.4.1 @context

@context는 key-value구조의 key값에 어떤 데이터가 들어가는지 정의하는 역할을 한다.

위의 예시를 보면 name 값에는 uri (string)이 들어가 있는데, 이 uri 에서 정의한 양식대로 데이터가 들어간다는 의미이다.

실제로 uri에 접속해보면 다음과 같이 name을 규정해준다. name이란 key엔 text가 들어가야 한다.

그래서 아래의 name 항목에는 text로 "lsj"라는 값을 주었다.

이렇게 써도 되고, key값을 저 uri로 넣어주는 것도 가능하다.

{ "http://schema.org/name" : "LSJ" }

1.2.4.2 @id

@id는 key로 사용될 때와 value로 사용될때의 기능이 좀 다르다.

    // ...중략
        "image" : {
            "@id" : "http://schema.org/image",
            "@type" : "@id"
        },

i) key로 사용될 경우

@id에는 uri가 들어가야 한다. 해당 uri에 정의된대로 데이터 타입을 정해준다.

정확히는 타입을 지정해주는 장소를 value로 가진다.

해당 uri로 들어가보면 다음과 같이 두 가지 방식으로 이미지 파일을 입력할 수 있다고 지정해주고 있다.

imageObject는 이미지 파일을 그대로 업로드 하는것, URL은 해당 이미지가 있는 urI를 입력하는 것을 의미한다.

ii) value로 사용될 경우

이는 @type과 함께 봐야 하는데, i) 경우에서 uri가 지정하는 두 가지 방법 중 어떤 방식을 선택할 것인지를 명시한다.

여기서 value로서의 @id는 그림 파일이 위치한 uri값을 입력하겠다는 것을 의미한다.

최하단 image 항목을 보면 그 value로 uri를 value로 가진 것을 알 수 있다.

1.2.4.3 @context 활용

방금처럼 직접 하나하나를 정의해줄 수도 있지만 이 양이 너무 많을 경우 (속성값이 너무 많을 경우) @context 형식 자체를

위의 name처럼 uri를 이용해 정의할 수도 있다.

{
    "@context" : "https://www.w3.org/ns/did/v1"
    // uri에서 정한 @context 형식을 사용한다.
}

1.3 DID dereference

DID document에서 특정 항목만을 호출하는 DID dereference라는 기능이 있다.

우리가 웹 사이트를 만들때도 하위 페이지를 뒤에 붙여 세분화하는 것과 비슷하다.

did:ethr:1234 에서 service항목만을 불러오고 싶은 경우 뒤쪽에 세미콜론을 붙여 이를 지정할 수 있다.

did:ethr:1234;service=EmployeeAuth 와 같이 입력하면 service 항목을 뒤져서 (보통 id) EmployeeAuth라는 값과

관련이 있는 데이터를 취사 선택해 호출, 사용할 수 있다.

비슷한 방식으로 ?를 붙여 질의 기능을, #을 붙여 특정 id가 있는 곳으로 이동할 수 있는 fragment 기능을 사용할 수도 있다.

이 fragment기능은 원하는 인증 방식을 선택할 때 사용된다.

1.4 DID auth

DID의 소유권 인증 과정인 DID auth에 대해 좀 더 자세히 알아보자.

DID auth는 상대방(verifier)에게 DID의 소유권을 증명하는 과정이다.

이는 Challenge-response 인증 방식을 사용하는데,

verifier는 did document를 보고 그 안의 인증 관련 데이터를 사용해 Challenge를 생성 후, holder(or controller)에게 전달한다.

holder는 did document에 명시했던 publicKey, authentication을 이용해 Response를 생성해 verifier에게 돌려준다.

이렇게 verifier, holder간 Challenge와 response를 교환, 검증하는 과정이 DID auth이다.

1.5 DID deactivation

DID를 폐기 혹은 비활성화할 수도 있다.

블록체인 상에서는 이게 중앙화된 신원 인증 방식보다 약간 절차가 복잡하다.

일단 블록체인에 한 번 올라간 did document를 아예 제거하는 것은 불가능하다.

그 대신 아무도 사용할 수 없게 만드는 방식을 사용하는데, (개인키가 없거나 모르는 지갑으로 코인을 보내는 코인 소각과 비슷하다)

하이퍼렛져 인디의 경우, 더 이상 사용하지 않을 did의 did document의 공개키 값을 모두 0으로 변경한다.

이러면 이 공개키에 대한 개인키를 알아야 하는데, 이를 아는 사람이 없으므로 이를 이용해 본인 인증을 할 수 있는 사람이 없게 된다.

뭘 가지고 공개키를 만들어야 00000...0000 이 되는지는 그 누구도 모르고, 밝혀질 가능성도 매우 낮다.

1.6 DID resolver, registrar

did document를 블록체인에 등록하는 작업이 did registrar이고,

이 did document를 어떤 방식으로든 불러오는 과정이 did resolution이다.

이런 did document를 등록, 접근하는 과정을 조금 더 편하게 해주는 어플리케이션들도 존재하는데,

한 가지 방법으로 사용자의 디바이스에 설치해 직접 did document를 저장하고 불러오기 때문에 신뢰할만한 중간자가 필요없이

did를 사용할 수 있다는 장점이 있지만 이럴 경우 did document의 수가 많아질 경우 이를 일일히 직접 설정해주어야 한다.

반대로 외부 디바이스를 통해 did document를 요청해 받아오는 방식도 있는데,

이 경우 did document가 많아져도 일일히 이를 설정해줄 필요성은 없어지지만

외부 디바이스가 공격받거나 할 경우 문제가 생길 수 있다.

'DID study' 카테고리의 다른 글

Ch 2 - VC & VP (0)	2022.08.15

현재글Ch 1 - DID & DID document

Torch for new way

채굴, TypeScript, ethersjs, Blockchain, solidity, telethon, Ethereum, docker, React, styled-components, Abstract Factory, Go, error, cryptozombie, googlelogin, oauth login, Googling, hardhat, Design Pattern, remote-ssh,

Today :
Yesterday :

Torch for new way