.gif&blockId=11b00c82-b138-8050-a58b-dcbceda2ef8f)
DID
DID (Decentralized IDentifier)
사용하는 사람 스스로 생성하고 제어할 수 있는 분산형 식별자(혹은 탈중앙화된 식별자)
분산형 식별자
•
통신에서 객체들을 식별하기 위해 UUID(Universally Unique IDentifiers)라는 분산형 식별자가 많이 사용중
UUID
32개의 16진수와 4개의 하이픈(’-’)으로 구성 8-4-4-4-8
•
동일한 식별자가 생성되지 않는 구조
충돌에 안전한 랜덤함수 사용
충돌 : 동일한 식별자가 생성되는 것
DID와 UUID
DID | UUID |
객체에 대한 식별자로 사용될 뿐만 아니라 인증 수단인 DID document를 참조할 수 있는 URI 역할까지 동시에 수행 | 객체를 식별하는 식별자로만 사용할 수 있고, 해당 객체를 인증하기 위해서는 별도의 인증 수단이 필요 |
URI(Uniform Resource Identifier) : 인터넷 존재 자원을 나타내는 유일 주소
DID 구성
•
DID scheme
URI가 어떤 프로토콜을 사용해서 자원에 접근하는지 명시
•
DID method
DID document가 어떤 저장소에 저장되어 있는지 명시
•
Method-specific identifier
DID method가 가리키는 저장소 내 DID document가 저장된 정확한 위치 검색
DID와 DID document 생성 및 사용 과정
1.
사용자 1이 DID와 DID document 생성 후, DID document는 DID method에 명시된 저장소에 저장 (DID document에는 ID인증 수단에 사용되는 데이터 포함
2.
사용자 2가 사용자 1의 DID 주소를 알고 있다면, DID에 명시된 저장소와 저장소 내 Method-specific identifier가 가리키는 위치에 저장된 사용자 1의 DID document를 획득할 수 있음.
DID resolver 혹은 DID registrar 프로그램을 사용하면 좀 더 수월하게 다양한 저장소에 저장된 DID document를 가져오거나 DID document를 등록할 수 있다. DID resolver/registrar는 사용자 단말 혹은 외부 서버에서 개발되어 사용될 수 있다.
•
DID 생성
대부분의 DID 플랫폼은 DID와 DID document 생성 시 비대칭키를 함께 생성
◦
비대칭키의 비밀키는 본인이 안전하게 보관
◦
공개키는 DID document에 넣어 블록체인에 저장
•
DID의 생성 구조
◦
Sovrin 블록체인의 DID는 비대칭키 생성 시 공개키의 일부분이 Method-specific identifier이 됨 — did:sov:공개키
◦
이더리움의 DID method : ethr, 이더리움 어카운트 주소가 Method-specific identifier이 됨 — did:ethr:어카운트
DID Document
DID의 소유권을 증명할 수 있는 인증 수단이 포함
1.
사용자가 검증기관에게 did:ethr:1234가 본인의 DID라고 주장
2.
검증기관은 사용자의 DID를 통해 사용자 DID document가 저장된 위치를 확인하여 DID document를 획득
3.
이후 검증기관은 획득한 DID document를 이용하여 해당 DID가 당신이 생성한 DID라는 것을 인증해 보라는 Challenge 전송
4.
Challenge를 받은 사용자는 인증을 위해 Challenge에 해당하는 Response를 전송
5.
Response를 받은 검증기관은 사용자의 DID Document에 포함된 공개키를 이용하여 사용자 Response 검증
(1) ID
•
DID 생성 및 요청 과정
1.
사용자가 DID를 생성
2.
DID document를 생성
3.
DID document의 id 값에는 생성했던 DID 외 향후 소유권 인증(DID Auth)에 필요한 값들을 입력
4.
DID document 생성을 완료하면 DID method에 정의된 저장소에 DID document를 등록
•
DID document 반환
1.
DID document 생성 후 사용자가 검증기관에게 자신의 DID 알림
2.
검증기관은 사용자의 DID method에 명시된 블록체인에 DID document를 반환해 줄 것을 요청
3.
DID document 반환 요청을 받은 블록체인은 저장된 DID document 중 id 항목이 검증기관이 요청한 DID와 동일한 DID document를 찾아서 검증기관에게 반환
(2) publicKey & authentication
publicKey : DID 소유권 인증에 필요한 다양한 종류의 데이터
4 "publicKey": [{
5 "id": "did:ethr:1234#keys-l",
히대칭키 인증（RSA]
7 "controller": "did: thr:1234", //비대칭키 인증(RSA)
8 "「） 匕ハ二1（二ト〈6丫!3 ［n"： "-------- BEGIN PUBLIC KEY.. .END PUBLIC KEY---------\r\n”
9 }, （
10 "id": "did:ethr:1234#keys-2",
11 "type": "Ieee241OVerificationKey2018”，//생체인증
12 "controller11: "did:ethr: 1234",
13 "pubVicKeyPem": "-------- BEGIN PUBLIC KEY... END PUBLIC KEY---------\r\n"
14 }, {
15 "id": "did:ethr:1234#keys-3",
16 "type": "RsaVeri ficationKey2018",
17 "controller": "did:sov:ABCD", //Authonzation key
18 "publicKeyPem": "-------- BEGIN PUBLIC KEY...END PUBLIC KEY-------- \r\n"
19 }],
C
복사
1.
id
•
5 : publicKey 내 사용할 수 있는 인증키의 위치
•
10 : did를 통해 소유권 인증 과정 시작
2.
type
•
6 : 비대키 인증(RSA)을 사용
•
생체 인증, 타원곡선 비대칭키 인증 등 다양한 인증 방식
3.
controller
•
7 : publicKeyPem에 대한 인증 권한을 가진 사람이 누구인지 표시
8번 줄 공개키와 쌍을 이루는 비밀키를 가진 사람의 DID 표시
4.
publicKeyPem
•
8 : 비대칭키 인증 방식에 사용되는 공개키 저장
authentication : 해당 DID document가 제공하는 소유권 인증 방식
다음과 같은 3가지 방법 중 하나를 선택하여 DID 소유권에 대한 인증을 수행할 수 있다.
20 "authentication":[
21 "did:ethr:1234#keys-l", // publicKey 5번째 줄 id 값
22 "did: thr:1234#keys-2", // publicKey 10번째 줄 id 값
23 "did:ethr:1234#keys-3" // publicKey 15번째 줄 DID 값
24 ],
C
복사
사용자가 앞서 설명한 DID document와 동일한 DID document를 사용한다고 가정하고, 검증기관 역시 이미 사용자의 DID를 획득했다고 가정했을 경우
1.
사용자 DID document를 획득한 검증기관 : authentication 항목 확인 → 사용자가 소유권 주장할 수 있는 방식 3가지 인거 확인 → 사용자에게 인증방식 물어봄
2.
사용자가 publicKey 데이터를 사용하여 인증 요청을 보냄
3.
검증기관에서 소유권 인증 방식(비대칭키 암호화 방식) 확인 = 공개키
소유권 인증의 담당자 확인
4.
명시된 암호화 방식대로 publicKeyPem에 있는 공개키를 이용해 검증기관만 알고 있는 데이터를 암호화해 사용자에게 전송
5.
사용자는 비밀키를 사용하여 검증기관의 데이터를 해독 후 결괏값을 전송.
검증기관은 암호화에 사용된 데이터 값과 사용자로부터 수신한 해독 값을 비교 후 동일하면 사용자 인증 완료
DID를 생성하고 DID Document를 등록한 사람의 DID가 들어가지 않는 경우
•
DID로 식별되는 사람과 DID Auth의 권한을 가진 사람이 다른 경우
controller 세부 항목을 잘 활용하는 경우 다양한 서비스 구현 가능
•
DID로 식별되는 사람 포함 DID Auth 권한을 두 명 이상 가진 경우
(3) service
serviceEndpoint라는 세부 항목을 이용한 다양한 서비스 개발 가능
(1)과정에서 공개키 변경 요청과 함께 service 항목과 같이 알려준다.
블록체인은 service = keyRocation이 가리키는 service항목을 찾아서 발급 기관에 DID Auth를 요청할 수 있다.
17 "service": [{
18 "id": "did:bcl:1234#keyRotation",
19 "type": "RotatellserKey",
20 "serviceEndpoint": "https://example.com/keyrotation/"
C
복사
위 예제 또한 마찬가지로 (1)과정에서 service항목을 알려줘 검증기관에서 항목을 찾고 요청을 보낸다.
(4) @context
직관적으로 개발하다가 생기는 실수를 방지하기 위한 역할
•
DID document에 들어가는 id, publicKey, service, controller 등의 항목이 어떤 의미를 가지는 데이터인지, 어떤 종류의 데이터가 들어가야 하는지 명확하게 정의해 주는 역할을 수행.
•
JSON-LD 문법에 따라 정의.
•
@context에서 정의한 대로 key 값과 value 값을 사용
◦
양이 적은 경우 : 직접 정의
◦
양이 많은 경우 : @context가 정의된 IRI 주소로 입력
•
key값에 대한 정의
◦
DID Auth 권한을 가진 사람인 controller key의 경우
"controller": {"@id": "sec:controller", "@type": "@id"}
"@id": "sec:controller" : controller는 sec:controller에 정의된 양식의 데이터가 value값으로 간다는 의미
"@type": "@id" : sec:controller에 정의된 양식 중 URI 값을 value로 사용한다는 의미
이때 sec는 https://w3id.org/security#의 줄임말"이고, sec:controller
는 https://w3id.Org/security#controller를 의미
◦
더 많은 정의 : w3.org/ns/did/v1
JSON-LD(JavaScript Object Notation for Linked Data)
1 {
2 "©context"： {
3 "name": "http://schema.org/name",
4 "image": {
5 "@id": "http://schema.org/image", // key 값
6 "@type": "@id" // value 값
7 },
8 "homepage": {
9 "@id": "http://schema.org/url",
10 "@type": "@id"
11 }
12 },
13 "name": "YOON DAEGEUN",
14 "image": "https://www.example.com/myImage",
15 "homepage": "https://www.example.com"
16 }
C
복사
•
@context
key-value 구조의 kay 값에 어떤 데이터를 삽입할 것인지 정의하는 역할
http://schema.org/name 은 key값에 많이 쓰이는 value값에 어떤 값들이 들어가는지 제공해주는 웹사이트
•
@id
◦
key 값으로 사용될 때
@id에 IRI(Internationalized Resource Identifier)가 들어가야 함
IRI : URI보다 조금 개선된 식별자
URI가 표현하는 문자열보다 다양한 인코딩이 가능
◦
value 값으로 사용될 때
위 같은 단어에 파일이 위치한 IRI 주소값을 입력해야 함
•
@type
◦
다음과 같이 파일이 여러 방식으로 입력될 수 있다고 명시되었을 때 이 중 어떤 방식으로 파일을 입력할지 명시하는 역할
DID dereference
•
DID document의 특정 항목만 선택해서 호출 가능
•
DID URL == web URL
◦
사용자의 DID 뒤에 세미콜론(’;’)으로 구분하여 원하는 항목 호출 가능
◦
URL에 물음표를 이용하여 질의(query) 기능 사용 가능
◦
URL에 샵(#)을 이용하여 특정 ID가 있는 곳으로 이동하는 프래그먼트 기능 사용 가능
DID Auth
상대방에게 DID에 대한 소유권을 증명하는 과정
== 사용자와 검증자 간 Challenge와 Response를 교환하고 검증하는 과정
•
Challenge-Response 인증 방식
3.
DID document에 포함된 인증 관련 데이터를 사용하여 Challenge를 생성한 후 사용자에게 전송
4.
Challenge를 받은 사용자는 자신의 DID document에 명시했던 publicKey와 authentication 항목을 사용하여 Response를 생성한 후 검증자에게 전송
DID deactivation
DID 폐기 혹은 비활성화
•
Sovrin 플랫폼에서 사용하는 Hyperledger Indy 블록체인 노드가 DID deactivation을 수행하는 방식
◦
사용자가 더 이상 사용하지 않을 DID가 가르키는 DID document의 공개키 값을 모두 0으로 변경
◦
해당 DID에 대한 DID Auth를 수행하기 위해선 키 값이 모두 0인 공개키와 쌍인 비밀키를 알아야 함
◦
하지만 해당 공개키에 대한 비밀키를 아무도 모르기에 해당 DID를 더 이상 쓸 수 없음.
◦
Hyperledger Indy에선 완전히 삭제가 불가능 하기에 누구도 사용하지 못하도록 업데이트하는 방식을 사용
DID resolver
저장된 DID document를 가져오기 위해 사용
•
사용자 디바이스용
◦
사용자 PC, 모바일 단말 등에서 사용
장점 | 사용자가 직접 DID document를 저장하고 불러오기 때문에 CA와 같은 제 3의 기관 없이 신뢰성 있는 결과 수신 가능 |
단점 | 다양한 종류의 DID document를 저장하지 않기 때문에, 원활한 DID Auth를 수행하려면 다수가 사용하는 대표적인 저장소에 대한 DID resolver driver 필수 설치 필요 |
•
외부 디바이스용
◦
서버와 같은 외부 디바이스에서 사용
◦
사용자는 외부에 설치된 DID resolver에게 REST API 등을 이용해 DID document를 요청하는 메시지만 보낼 수 있으면 됨.
◦
요청을 받은 외부 DID resolver가 실제 블록체인에게 DID document를 요청하고 수신 받은 후 사용자에게 전달
장점 | 사용자 디바이스 부담 감소
고사양 외부 DID resolver를 통한 원활한 서비스 사용 가능 |
단점 | 제 3자가 DID resolver를 통해 다수의 사용자에게 DID document를 제공하는 경우 잠재적인 해킹 위협 발생 가능 |
DID resolution
•
document를 저장하는 방식이 각각의 저장소마다 다를 경우
◦
저장소가 DID document를 JSON 형태 그대로 저장할 경우
저장소는 DID document를 JSON 형태 그대로 반환 가능하므로 DID resolver 는 별다른 작업 없이 저장소로부터 수신한 값을 그대로 사용자에게 반환한다.
◦
DID document 항목들이 개별적으로 저장돼 있는 경우
DID resolver는 개별적으로 수신되는 데이터들을 취합하여 JSON 등의 적절한 형태로 데이터를 가공해야 함.
(1) Veres One
•
가장 단순한 DID resolution 방식
•
Veres One 노드가 제공하는 REST API 등을 이용하여 JSON 양식의 데이터를 호출하듯 DID document를 호출할 수 있다.
•
DID resolution 과정
1.
사용자는 DID resolver에 DID document를 요청
2.
요청을 받은 DID resolver는 Veres One driver를 통해 Veres One 블록체인에 맞는 DID document 요청 메시지를 생성하여 Veres One 블록체인 노드에 전송
3.
Veres One 블록체인 노드는 수신 요청에 따라 DID를 검색
4.
DID document를 DID resolver에게 반환
5.
DID resolver는 사용자 디바이스가 전달받은 DID document를 그대로 반환
(2) Hyperledger indy
•
Sovrin 플랫폼의 DID resolution 방식
•
DID resolution 과정
1.
사용자가 DID resolver에 DID document를 요청
2.
요청을 받은 DID resolver는 Sovrin driver를 통해 Sovrin 블록체인 플랫폼에 맞는 DID
document 요청 메시지를 생성하여 Sovrin 노드에 전송
Sovrin 노드에는 Veres One과 달리 JSON 형식 그대로 DID document가 저장되지 않고 공개키 값, service 항목 값 등이 여러 종류의 트랜잭션에 나뉘어서 저장 Sovrin 플랫폼에서는 DID 관리, 노드 관리, 네트워크 관리 등 사용하려는 기능에 따라 다양한 종류의 트랜잭션이 사용, DID 관리를 위해서는 NYM, ATTRIB라는 트랜잭션이 사용됨.
3.
요청을 받은 Sovrin 노드는 사용자 DID의 Methodspecific identifier를 사용하여 블록체인에저장된 NYM 트랜잭션에서는 공개키 값을 검색하고 ATTRIB 트랜잭션에서는 service 항목 값을 검색
4.
검색을 마친 Sovrin 노드는 DID resolver의 요청에 따라 공개키 값인 verkey와 service 항목 값인 service를 DID resolver에게 반환합니다.
5.
verkey와 service 값을 수신한 DID resolver는 수신받은 값을 JSON 양식의 DID document로 변환한 후 사용자에게 반환
(3) Bitcoin
•
DID resolution 과정
1.
DID resolver에게 DID document를 요청
2.
DID resolver는 TxRef를 참조하여 TxRef가 가리키는 트랜잭션을 획득
3.
DID resolver가 TX를 참고하여 DID document를 생성
a.
TXIN 값을 참조하여 DID document 내 public 항목의 데이터를 구함
b.
TXOUT의 OP_RETURN 값을 참조하여 service 항목에 대한 데이터를 가진 외부 서버 URL을 획득
OP_RETURN에는 40바이트의 제한적인 데이터만 들어갈 수 있기 때문에 OP_RETURN에는 데이터가 위치한 URL만 입력하고, OP_RETURN의 URL을 참고하여 service 항목 등 publicKey 항목을 제외한 실제 DID document에 들어가는 데이터를 가져오게 함.
4.
DID resolver는 TX를 참조하여 획득한 값을 취합한 후, 사용자가 필요한 포멧으로 DID document를 생성하여 사용자에게 반환
DID registrar
•
DID document를 등록할 수 있게 도와주는 도구
•
사용자의 DID document 등록 요청을 받은 DID registrar는 사용자의 요구에 따라 DID document를 등록할 플랫폼에 맞게 트랜젝션, API 등을 생성하여 DID document를 등록
DID registrar도 현재 DIF(decentralized Identity Foundation)에서 개발한 universial registrar
라는 오픈소스 프로젝트에서 다양한 종류의 DID registrar driver를 제공 중
https://github.com/decentralized-identity/universal-registrar
개념 정리
•
DID : 식별자
•
VC/VP : 실제 신분증 용도
•
DID Auth : 해당 DID가 식별하고 있는 것이 본인 소유라는 것을 증명하는 것(DID에 대한 소유권 주장)
