혼공 | 마스터링 자기주권신원 - SSI 아키텍처의 핵심(2/2), DID

개념

1. DID 정의

리소스를 식별하는 문자열, 글로벌 고유 식별자
https://www.w3.org/TR/did-core

Decentralized Identifiers (DIDs) v1.0

 

2. WWW의 URI와 비교 

URI : 모든 웹 식별자 - WWW에서 문자열을 전역적으로 고유하게 만드는 특정형식의 문자열
URL : 네트워크 위치 - Web에서 해당 이곳의 표현 위치를 찾는데 사용할 수 있는 URI
URN : 영구적 이름

DID는, URL 또는 URN 중 어느 하나가 될 수 있고 DID로 식별되는 리소스에 대한 표준화된 정보(메타데이터) 집합을 얻기 위해 리졸브할 수 있는 URI. +암호화에 의존( 암호화 검증과 분산).

 

3. DID 4가지 핵심 속성.

1) 영구(permanent, persistent) 식별자를 변경할 필요가 없다.
2) 리졸브 가능한 식별자(resolvable identifier) 메타데이터를 찾기 위해 검색할 수 있다.
3) 암호로 검증할 수 있는 식별자 암호화를 사용하여 제어를 증명할 수 있다.
     - DID를 생성하는 데 사용
     - DID는 정확히 하나의 공개키/개인키 쌍과 연결되므로 개인키의 컨트롤러 = DID의 컨트롤러임이 증명 가능
4) 분산 식별자 중앙형 등록 권한이 필요하지 않다.
     - 중앙형 레지스트리는 특정 식별자가 고유한지 아닌지를 판단하고 고유한 경우에만 등록

4. DID 형식

1) The DID Syntax ABNF Rules

did                = "did : method-name : method-specific-id" 
method-name        = 1*method-char
method-char        = %x61-7A / DIGIT
method-specific-id = *( *idchar ":" ) 1*idchar
idchar             = ALPHA / DIGIT / "." / "-" / "_" / pct-encoded
pct-encoded        = "%" HEXDIG HEXDIG

(1)스키마, (2)메서드 - 블록체인 및 기타 분산원장기반, 생성 또는 업뎃 시 해당 원장에 트랜잭션 작성, 다양한 구현 기술 중 특정 사례에 적합한 기술 선정, (3)메서드의 하위 문자열 식별자( did 메서드 네임스페이스 내에서는 항상 고유한 보장, 전역 적으로도 고유할 것 권장)

*요구 사항을 얼마나 잘 충족하는지 채택자가 평가 지표 [ 표제 rubric  https://w3c.github.io/did-rubric ]

DID Method Rubric v1.0

2) The DID URL Syntax ABNF Rules

did-url = did path-abempty [ "?" query ] [ "#" fragment ]

3) WWW와 SSI의 url 규칙 비교 

https://host.domain-name.com:8080/file-path/file-name?key=value&key=value#index-name (1-protocol) (2-domain) (3-path) (4-port) (5-parameter=매개변수) (6-fragment=앵커=인덱스)	도메인이름 (DNS)
did : method-name : method-specific-id#index-name did : method-name : method-specific-id?query-name did : method-name : method-specific-id/file-path?query-name#index-name did : method-name : method-specific-id?query-name=/file-path?query-name#index-name (1-did) (2-did url :  path parameter=매개변수 fragment=앵커=인덱스 )	분산 ID (DID)

비교 01 : www에서 운용되는 서비스의 경우, 보통 port 주소를 생략한다. DID의 경우 port와 유사한 포지션인 method-specific-id를 생략하지 않는다.  
비교 02 : www에서 다수의 파라미터를 사용하는 경우, & 로 이어가는데, DID는 ? 로 이어간다 
비교 03 : 파라미터에 사용되는 매개변수 네이밍에 대한 권고안들을 W3C에서 관리하고 있다. 확장성을 고려하면서도 상호 운용성을 최대화하기 위해 권고 규격을 운영하고 있다. 이를 통해 동일한 DID 매개변수를 사용하는 경우 다른 의미 체계로 운영되는 경우에도 상호 충돌이 일어나지 않도록 하고 있다. 

 

 

 

 

 

작동 방식

 

 

1. DID 리졸버 resolver

- DID 도큐먼트라는 표준화된 데이터 구조를 검색
- DNS 리졸버(도메인 이름url을 ip주소로 확인하기 위한 프로토콜)가 웹 브라우저 및 기타 응용 프로그램에서 호스트 이름(www.example.com)을 수신하여 해당 호스트 이름에 대한 IP 주소를 추적하는 것과 마찬가지로 DID에 대한 DID 도큐먼트를 해주는 서비스 혹은 서버를 의미
*HTTP, 웹서버에서 리소스 표현url을 검색하기 위한 프로토콜
- 구체적인 프로토콜로 생각하기보다는 DID(추가 매개변수 포함)를 입력으로 사용하고 DID 도큐먼트(추 가 메타데이터 포함)를 결과로 반환하는 추상 기능 또는 알고리즘으로 간주해야 한다.

 

2. DID 도큐먼트 샘플

{
	"@context": "[<https://www.w3.org/ns/did/vl>](<https://www.w3.org/ns/did/vl>)",
	"id": "did:example:123456789abcdefghi",
	"authentication":[{
		"id": "did:example:123456789abcdefghi#keys-1", 
		"type": "Ed25519VerificationKey2018",
		"controller": "did:example:123456789abcdefghi", 
		"publicKeyBase58" : "H3C2AVvLMv6gmMNam3uVAjZpfkcJCwDwnZn6z3wXmqPV"
	}],
	"service": [{
		"id": "did:example:123456789abcdefghi#vcs", 
		"type": "VerifiableCredentialService",
		"serviceEndpoint": "[<https://example.com/vc/>](<https://example.com/vc/>)"
	}]
}

 

 

 

 

 

---

https://www.aladin.co.kr/shop/wproduct.aspx?ItemId=290964757 

마스터링 자기주권신원