DID ::: Sevity Blog

DID

2025. 6. 1. 18:23

기존 인증서의 분산버전

DID는 “내 신원 검증을 중앙 CA한테 의존하지 않겠다”는 목표로 만들어졌다.

X.509 인증서
1. 중앙 CA가 서명 → “이 도메인(Subject)과 이 공개키가 진짜로 연결되어 있다”를 보증
2. 인증서 내부에 Subject(도메인/회사)와 Issuer(CA 이름) 필드가 있고, 클라이언트는 미리 신뢰하는 루트 CA 목록으로 서명 체인을 확인
3. “controller” 개념이 필요 없음 (필요 없는 이유: CA가 이미 “공개키는 Subject 소유”라는 점을 대신 검증해 주니까)
DID 문서
1. 중앙 CA가 없다 → “DID를 가진 주체(사람/조직)가 직접 공개키를 만들어서 문서에 올려야 한다”
2. 여러 개의 공개키가 들어갈 수 있고, 키 위임/회전 등을 선언해야 하므로,
  - 각 공개키 옆에 "controller": "어떤 DID 소유자가 사용하는 키인지"를 명시
3. 검증자는
  1. “did:example:alice” 같은 DID를 레지스트리에서 조회 → DID 문서(JSON-LD) 획득
  2. 문서 안의 verificationMethod 리스트를 살펴보면서 “어떤 공개키는 누구 컨트롤러의 키인가”를 확인
  3. 사용자가 서명(Signature)을 보냈다면, 해당 키의 publicKey… 값을 꺼내와 “controller”로 적힌 DID(=Alice)의 공개키인지 확인한 뒤, 서명을 검증

“스캐머가 만든 DID”를 걸러내려면

VC(Verifiable Credential, 전자서명된 백신접종확인문서) 발급 단계
1. KDCA 서버에서 VC JSON 생성 (issuer: did:kr:kdca, subject: did:kr:0xAlice, 접종 정보 포함)
2. KDCA 개인 키로 VC 전체에 디지털 서명 → VC 안의 proof 필드에 JWS 삽입
3. 완성된 VC를 Alice의 COOV 앱으로 전달
VC 검증 단계
1. Alice가 제시한 VC JSON을 Verifier 앱(말하자면 Alice가 식당에가서 설치된 접종확인용 기계를 뜻하고, 여기 QR스캐너에 Alice COOV앱을 켜서 QR화면으로 진입해서 VC정보를 이 기계에 스캔시킨다)이 수신
2. Verifier 앱은 VC 안의 issuer: did:kr:kdca 보고 KDCA DID 문서 조회 → KDCA 공개 키 획득
3. KDCA 공개 키로 VC의 디지털 서명(proof.jws) 검증 → 서명 유효 여부 판단
4. VC 안의 credentialSubject.id: did:kr:0xAlice 확인 → 실제 Alice의 DID인지 추가 검증(옵션)
5. 검증 모두 통과 시 “Alice가 KDCA가 서명한 백신 증명서를 소지했다”로 인정 → 출입 허가

이렇게 정부의 서명 절차(Proof 생성 → VC에 포함)와 그 검증 과정을 포함해 VC 발급·제시·검증 흐름을 완성할 수 있습니다.

COOV 구현의 한계

COOV는 “정부만 백신증명 VC를 발급할 권한이 있다”는 원칙 하에 설계됐기 때문에,
1. 최초 가입 시점에 반드시 본인 인증(휴대폰 인증, 공인인증서)이 들어가야 하고,
2. 그 본인 인증 토큰 ↔ 새로 생성된 DID(예: did:kr:0xAlice) 간 매핑 정보가 COOV 서버(혹은 KDCA 서버)에 기록됩니다.
다시 말해,
- “did:kr:0xAlice ↔ 주민등록번호·휴대폰 번호” 라는 관계는
- 탈중앙화된 블록체인에 직접 올라가지 않고,
- 중앙 집중형 데이터베이스(앱 서버)에만 남게 됩니다.
→ 따라서 COOV는 기술적으로 “하이브리드(Hybrid)” 분산ID 모델입니다.
- “발급 단계”(본인인증 → DID 생성 ↔ VC 발급)에서는 중앙 서버가 결정을 하고,
- “검증 단계”(VC 제시 → DID 문서 조회 → 서명 검증)는 블록체인 기반 분산 검증을 활용하지만,
- “가입 시점조차 완전히 중앙을 배제”한 것은 아닙니다.