※ URI(Uniform Resource Identifiers)
웹에서 리소스를 위해 사용되며, 브라우저에서 보는 각 웹페이지는 전역적으로 유일한 URL(Uniform Resource Locator)를 갖는다.
DID(Decentralized Identifiers)
Diversity of DID systems
DID method는 연합 혹은 중앙집중식 ID 관리 시스템에 등록된 식별자를 위해 개발될 수 있다. 실제로 거의 모든 유형의 식별자 시스템이 DID 지원을 추가할 수 있다. 이로 인해 중앙집중식, 연합식 및 탈 중앙집중식 세계간의 상호 운용 가능성이 생성된다.
Example 1: A Simple Example
did:example:123456789abcdefghi
- URL scheme identifier(did)
- DID method를 위한 identifier(example)
- DID method에 특화된 identifier(123456789abcdefghi)
Example 2: Minimal self-managed DID document
{
"@context": "https://www.w3.org/ns/did/v1",
"id": "did:example:123456789abcdefghi",
"authentication": [{
// did:example:123456789abcdefghi로 인증되기 위해 사용됨
"id": "did:example:123456789abcdefghi#keys-1",
"type": "Ed25519VerificationKey2018",
"controller": "did:example:123456789abcdefghi",
"publicKeyBase58": "H3C2AVvLMv6gmMNam3uVAjZpfkcJCwDwnZn6z3wXmqPV"
}],
"service": [{
// DID와 관련된 VC를 찾기 위해 사용됨
"id":"did:example:123456789abcdefghi#vcs",
"type": "VerifiableCredentialService",
"serviceEndpoint": "https://example.com/vc/"
}]
}
위 예제의 DID는 DID Document로 해석된다. DID Document는 DID에 관련된 정보를 포함되며, 이러한 정보에는 DID controller를 암호학적으로 인증하는 방법 및 DID subject와 상호작용하기 위해 사용될 수 있는 service가 있다.
DID 설계 목표(Design Goals)
Decentralization
전역적으로 유일한 식별자, 공개 검증 키, 서비스 엔드포인트 및 기타 메타데이터의 등록과 같은 식별자 관리에서의 중앙 기관 또는 단일 지점 실패에 대한 요구사항을 제거한다.
Control
entity(사람과 비사람 모두)에게 외부 기관에의 의존성 없이 자신의 전자 식별자를 직접적으로 통제할 수 있도록 한다.
Privacy
entity가 그들의 정보의 프라이버시를 통제할 수 있도록 하며, 이는 속성 및 다른 데이터의 최소, 선택적, 그리고 점진적 공개를 포함한다.
Security
DID Document에 의존하는 신뢰 당사자(relying parties)가 그들이 요구하는 수준의 보장을 위해 충분한 보안성 제공
Proof-based
DID controller가 다른 entity와 상호작용할 때, 암호학적 증명을 제공할 수 있도록 한다.
Discoverability
entity가 다른 entity에 대한 DID를 검색하고 해당 entity에 대해 자세히 알아보거나 상호작용할 수 있도록 한다.
Interoperability
DID 인프라가 상호 운용성을 위해 설계된 기존 도구와 소프트웨어 라이브러리를 사용할 수 있도록 상호 운용 가능한 표준을 사용한다.
Portability
시스템 및 네트워크에 독립적이며, entity가 DID와 DID method를 제공하는 어떠한 시스템에서도 자신의 전자 식별자를 사용할 수 있도록 한다.
Simplicity
축소된 간단한 기능을 선호하여 기술이 더 쉽게 이해되고 구현되며 배포될 수 있도록 한다.
Extensibility
가능한 경우, 상호 운용성(interoperability), 이식성(portability), 또는 단순성(simplicity)을 크게 방해하지 않는 경우 확장성을 활성화한다.
DID Architecture
DIDs and DID URLs
DID는 앞서 살펴 본 것과 같이 세 부분으로 구성된 URI이며, DID Document로 해석될 수 있다. DID URL은 특정한 리소스를 찾기 위해 기초적인 DID의 구문(syntax)를 다른 표준 URI 요소(path, query, fragment)를 통합하도록 확장하며, 이러한 특정한 리소스에는 DID 문서 내부의 공개 키나 DID 문서 외부에서 사용 가능한 리소스 등이 있다.
DID Subjects
DID의 대상(subject)는 DID에 의해 식별되는 entity로 정의된다. 또한 DID Controller일 수도 있다. 사람, 그룹, 기관, 물리적인 것, 논리적인 것 등을 포함한 모든 것이 DID의 대상이 될 수 있다.
DID Controllers
DID Controller는 DID method에서 정의된, DID 문서를 변경할 수 있는 기능을 가진 entity(사람, 기관 혹은 자율 소프트웨어)다. 이러한 기능은 다른 메커니즘을 통해서도 주장될 수 있지만, 일반적으로 controller 대신에 동작하는 소프트웨어에 의해 사용되는 암호학적 키 집합의 제어에 의해 주장된다. DID는 하나 이상의 controller를 가질 수 있으며, controller는 DID subject를 포함할 수 있다.
Verifiable Data Registries
DID 문서를 확인할 수 있도록 하기 위해서, DID는 일반적으로 어떤 종류의 기본 시스템이나 네트워크에 기록된다. 사용된 특정 기술에 상관없이, DID의 기록을 지원하고 DID 문서를 생성하는데 필요한 데이터를 반환하는 시스템을 검증 가능한 데이터 레지스트리(Verifiable Data Registries)라고 한다. 분산 원장, 분산 파일 시스템, 모든 종류의 데이터베이스, P2P 네트워크 및 기타 형태의 신뢰할 수 있는 저장소 모두가 Verifiable Data Registries 가 될 수 있다.
DID Documents
DID Document는 DID와 관련된 메타데이터를 포함한다. 일반적으로 공개 키와 같은 검증 방법과 DID subject와 상호작용에 관련된 서비스를 나타내고, 특정 구문(syntax)를 통해 직렬화 된다.
DID 그 자체는 DID 문서의 id 속성이다.
DID Methods
DID method는 특정 유형의 DID 및 관련 DID 문서를 특정 verifiable data registry를 이용하여 생성, 검색, 업데이트, 그리고 비활성화하는 메커니즘이다. DID method는 별도의 DID method 사양을 이용하여 정의된다.
DID resolvers and resolution
DID resolver는 DID를 입력 받아 적합한 DID document(및 관련된 메타데이터)를 출력하는 소프트웨어 혹은 하드웨어 요소를 뜻하며, 이러한 처리를 DID resolution이라고 부른다.
DID URL dereferencers and DID URL dereferencing
DID URL dereferencer는 DID URL(및 관련된 옵션)을 입력 받아 리소스(및 관련된 메타데이터)를 출력 하는 소프트웨어 혹은 하드웨어 요소를 뜻하며 이러한 처리를 DID URL dereferencing이라고 부른다.