길리랩blog

W3C DID와 Verifiable Presentation으로 설계하는 분산 신원 검증

W3C DID, VC·VP, DID Auth를 중심으로 DID 문서 해석, 상태 검증, OIDC 연계와 분산 신원 인증 설계 기준을 정리한다.

2026-08-14 · 최초 발행 2025-11-09

중앙 IdP 밖에서 신원을 검증하는 방법

분산 ID(Decentralized Identity)는 중앙 집중식 신원 공급자 없이도 신뢰 가능한 인증과 검증을 수행하려는 메커니즘이다. 이 구조에서 핵심은 식별자 자체보다 발행자, 보유자, 검증자가 어떤 증명을 주고받고 어떤 정책으로 검증하는지에 있다.

DID(Decentralized Identifier)는 중앙 기관 없이 생성하고 관리할 수 있는 식별자다. did:ion:…, did:ethr:…, did:web:… 등이 있으며, DID Document에는 공개키, 서비스 엔드포인트, 컨트롤러 정보가 담긴다.

DID Method는 특정 레지스트리에서 DID를 생성·해결·갱신·폐기하는 규칙 집합이다. 블록체인이나 검증 가능한 데이터 레지스트리를 기반으로 하며, 온체인·오프체인 방식과 레이어2 앵커링 등 구현 방식이 나뉜다.

VC(Verifiable Credential)는 발행자(issuer)가 주체(subject)의 속성이나 자격에 서명한 증명이다. JSON-LD 기반 Linked Data Proofs 또는 JWT 기반 JWS 서명 포맷으로 표현할 수 있다. 보유자(holder)는 하나 이상의 VC를 선택·가공·집합해 검증자(verifier)에게 VP(Verifiable Presentation)로 제시한다. 이 과정에는 선택적 공개와 프라이버시 보존 메커니즘을 적용할 수 있다.

DID Auth는 DID를 이용한 도메인 바인딩 챌린지-리스폰스 인증 절차다. OIDC SIOP v2, OIDC4VP 같은 표준과 결합하면 웹과 모바일 인증 흐름에 연결할 수 있다.

일부 명세·버전·상호운용성 영역은 최신 정보 확인이 필요하다.

DID 문서와 증명 모델이 맡는 역할

W3C DID Core는 DID 식별자 형식, DID Document 구조, 해석(Resolution)과 오퍼레이션 인터페이스를 정의한다. 키, 서비스, 컨트롤러의 관계를 문서에 명시하므로 권한 관리와 키 회전에 활용할 수 있다. 다만 DID Method마다 합의 방식, 최종성, 갱신 비용, 지연이 다르므로 운영 환경의 지연·비용·법규 요구사항에 맞춰 선택해야 한다.

VC와 VP 데이터 모델은 주체, 발행자, 유효기간, 상태, 증명 정보를 표준화한다. 증명 포맷으로는 JWT(JWS)와 JSON-LD(Linked Data Proofs, BBS+ 등)를 선택할 수 있다.

JWT는 성능과 툴링 성숙도 측면에서 장점이 있고, JSON-LD는 선택적 공개와 문맥 기반 상호운용성에 강점이 있다. 어떤 포맷이 적합한지는 제시해야 할 속성, 프라이버시 요구사항, 기존 인증 환경과의 연결 방식에 따라 달라진다.

상태 정보도 검증 흐름의 일부다. VC Status List(예: StatusList2021)나 Revocation Registry를 사용하면 폐기 또는 일시정지 여부를 확인할 수 있으며, 대량 상태 벡터(bitstring) 기반 구조는 효율을 제공한다. 최소 공개, pairwise DID, 프레젠테이션 컨텍스트 바인딩, nonce 기반 재전송 방지는 상관관계 위험을 줄이는 설계 요소다.

VP를 받았을 때 검증자가 확인하는 것

검증자는 VP를 수신한 뒤 서명 검증만 수행해서는 충분하지 않다. DID 해석으로 공개키를 얻고, 유효기간·청중(aud)·논스(nonce)를 확인하며, 폐기 상태까지 순차적으로 검사해야 한다.

Resolver는 Method별 드라이버를 통해 온체인·오프체인 소스에서 DID Document를 수집하고 정규화한다. 이 계층에서는 캐시, TTL, 최종성 파라미터 관리가 필요하다.

입력에는 VP(JWT/JSON-LD), 검증 요청 파라미터(nonce, aud, presentation_definition), 필요한 클레임과 스키마를 담은 정책이 포함된다. 처리 단계는 다음과 같이 구성할 수 있다.

  • Resolver로 DID를 해석해 공개키와 컨트롤러를 얻고, 키의 용도와 만료를 확인한다.
  • JWS 또는 LD-Proof를 검증하고 exp·nbf·iat 시간 제한을 확인한다.
  • 필드 존재 여부, 스키마·서명 체계, 발행자 신뢰도를 평가한 뒤 Status List 또는 Revocation 상태를 검사한다.
  • aud와 nonce를 비교해 도메인 바인딩과 재전송 방지를 처리하고 프라이버시 규칙을 적용한다.

출력은 승인·거절 결과, 트레이스와 정책 위반 항목 같은 근거 로그, 필요하다면 리스크 점수로 구성할 수 있다.

DID 해석이 네트워크 문제나 최종성 미달로 실패하면 지수 백오프 재시도와 캐시 무효화를 고려한다. 키 불일치나 허용하지 않은 알고리즘 때문에 서명 검증이 실패한 경우에는 거절하고 보안 알람을 남긴다. 상태 검증 결과가 폐기 또는 일시정지라면 거절하고 사용자 가이드를 제공한다.

⤢✕Resolver/VDRVerifierHolderIssuerResolver/VDRVerifierHolderIssuerVC 발행(서명, 상태 참조 포함)1VP 요청(presentation_definition, nonce, aud)2VC 선택·필드 최소화·VP 생성3발행자/본인 DID 해석(키/서비스 조회)4VP 전송(JWT/LD-Proof, nonce 포함)5DID 해석(키, 컨트롤러, 상태 레지스트리)6DID Document/상태 리소스7서명 검증, 만료/정책/상태 확인8결과 반환(승인/거절)9

온체인 DID 갱신은 블록 확정(finality) 이후 유효하다. 검증 정책에는 최소 확인 수(예: N confirmations)와 캐시 TTL을 포함할 수 있다. 상태 리스트 갱신 지연에는 시간 일관성 창(window)을 적용하고, 재시도 과정은 멱등성(idempotency)을 보장해야 한다.

증명 포맷별 운영 특성

항목 JWT(JWS) VC/VP JSON-LD LD-Proofs BBS+ ZKPs(Selective Disclosure)
성능 서명/검증 빠름, 라이브러리 풍부 정규화 비용 증가, 서명 느림 검증 중간, 증명 생성 비용 높음
확장성 CDN 캐시·게이트웨이 친화 컨텍스트 로딩 이슈 관리 필요 대량 생성 시 CPU 부담
일관성(상호운용) OIDC 연계 용이 스키마/어휘 상호운용 우수 도입 초기, 상호운용 성숙도 제한
안정성 툴링/배포 성숙 컨텍스트 관리 실패 시 리스크 라이브러리·HW 지원 제한
운영 편의 로깅/SIEM 통합 용이 컨텍스트 캐시·고정 버전 필요 파라미터 튜닝·키 관리 복잡

최신 구현과 상호운용성 현황은 최신 정보 확인이 필요하다.

VP-JWT 검증 코드

전제조건은 다음과 같다.

  • Node.js 18+
  • 라이브러리: did-jwt, did-resolver, ethr-did-resolver, web-did-resolver
  • 가정: VP는 JWS 기반 JWT, aud/nonce 포함, 발행자 DID는 did:ethr 또는 did:web
npm i did-jwt did-resolver ethr-did-resolver web-did-resolver
// file: verifyVP.js
// Node 18+, ESM 또는 CommonJS 가능
import { verifyJWT } from "did-jwt";
import { Resolver } from "did-resolver";
import { getResolver as ethrGetResolver } from "ethr-did-resolver";
import { getResolver as webGetResolver } from "web-did-resolver";

const resolver = new Resolver({
  ...ethrGetResolver({ infuraProjectId: process.env.INFURA_ID }),
  ...webGetResolver(),
});

async function checkRevocationStatus(vpPayload) {
  // 간단 예시: VC 내 status 필드 또는 외부 StatusList 엔드포인트 확인
  // 실제 구현은 StatusList2021 비트스트링 검증 필요
  const vcs = vpPayload?.vp?.verifiableCredential || [];
  for (const vc of vcs) {
    const status = vc.credentialStatus || vc.status;
    if (!status) continue;
    // TODO: status.type에 따라 검증 로직 분기
    // fetch(status.statusListCredential) 등으로 비트 인덱스 확인
  }
}

async function main() {
  const vpJwt = process.env.VP_JWT;
  const expectedNonce = process.env.EXPECTED_NONCE;
  const expectedAud = process.env.EXPECTED_AUD; // 예: did:web:verifier.example.com

  if (!vpJwt || !expectedNonce || !expectedAud) {
    throw new Error("환경 변수 VP_JWT/EXPECTED_NONCE/EXPECTED_AUD 필요");
  }

  const { payload, issuer, signer } = await verifyJWT(vpJwt, {
    resolver,
    audience: expectedAud,
    skewTime: 60, // 초 단위 시간 오차 허용
  });

  if (payload.nonce !== expectedNonce) {
    throw new Error("Nonce 불일치");
  }
  if (!payload.vp || !payload.vp.verifiableCredential) {
    throw new Error("VP 구조 누락");
  }

  await checkRevocationStatus(payload);

  console.log("검증 성공", {
    issuer: issuer,
    kid: signer.kid,
    vcCount: payload.vp.verifiableCredential.length,
  });
}

main().catch((e) => {
  console.error("검증 실패:", e.message);
  process.exit(1);
});

운영에서는 ES256K/EdDSA 등의 알고리즘 허용 리스트를 화이트리스트로 관리한다. DID 해석 캐시는 성공 결과 TTL과 네거티브 캐시를 분리해 운영하고, 감사 추적에는 aud·nonce·issuer·kid·정책 결과를 보존하되 개인 데이터는 저장하지 않는 원칙을 둔다.

OIDC와 연결되는 적용 장면

웹 로그인에서는 패스키와 지갑을 연결하고 DID Auth로 비밀번호를 제거하는 피싱 저항 인증을 구성할 수 있다. OIDC RP에는 SIOP v2 또는 OIDC4VP로 통합한다.

원격 근로자 접근 제어에는 역할과 만료 정보를 담은 고용 VC를 활용할 수 있다. 보유자가 VP를 제시하면 자산 접근 권한을 부여하고, 키 회전과 즉시 폐기 정보는 상태 리스트에 반영한다.

규제 준수(KYC/AML) 흐름에서는 금융기관이 발행한 KYC VC를 여러 서비스에서 재사용할 수 있다. 선택적 공개를 적용하면 과도한 PII 공유를 줄일 수 있다.

IoT 환경에서는 디바이스 DID와 하드웨어 바운드 키를 사용해 mTLS와 서명 검증을 수행한다. 오프라인 검증을 지원할 경우 최신 상태를 어떻게 동기화할지 정책이 필요하다.

지연·비용·보안에 미치는 변화

중앙 IdP 왕복을 제거하면 왕복 횟수를 12회 절감할 수 있고, 네트워크와 서명 알고리즘에 따라 평균 80200ms 개선이 가능하다.

외부 IdP 라이선스와 트랜잭션 비용을 없애면 지갑·검증 인프라에 따라 장기적으로 TCO 20~40% 절감이 가능하다. DID Auth와 도메인 바인딩은 피싱 저항성을 제공하며, nonce는 재전송을 막고 키 분리·회전은 계정 탈취 리스크를 낮춘다.

OIDC 브리지를 사용하면 기존 앱을 최소 수정해 도입할 수 있다. 다중 발행자 신뢰 모델은 공급망과 파트너 연계의 효율을 높일 수 있다. 수치·범위는 환경에 따라 변동 가능하다.

신뢰 경계를 지키기 위한 선택

도메인 바인딩(aud)은 필수로 두고 nonce의 고유성과 만료를 엄격하게 관리한다. 키는 HSM·TEE·보안 모듈에 두며, 다중 키와 키 회전 정책을 적용하고 DID Document의 verificationMethod는 서명·인증·암호화 용도로 분리한다.

프라이버시 관점에서는 pairwise DID와 최소 공개를 적용하고, 특히 JWT 사용 시 링크어빌리티에 주의한다. Resolver는 다중 소스를 두고 캐시·백오프·서킷 브레이커를 적용해 가용성을 관리한다.

JWT와 JSON-LD 사이에서는 성능·툴링과 선택적 공개·어휘 상호운용성을 비교해야 한다. 온체인과 오프체인 선택은 불변성·최종성과 비용·지연·GDPR 이슈의 균형 문제이며, 자체 지갑과 제3자 지갑 선택은 사용자 경험·배포 속도와 제어·보안 경계 사이의 트레이드오프다.

W3C DID, VC/VP, DID Auth는 중앙 집중식 IdP를 대체하거나 보완하는 신뢰 인프라의 구성 요소다. 증명 포맷, DID Method, OIDC 연계 방식을 사용 사례에 맞춰 선택하고 해석·검증·상태 관리 파이프라인을 정책 기반으로 표준화해야 한다. 관련 명세와 상호운용성 프로파일은 최신 정보 확인이 필요하다.

분산 IDW3C DIDVerifiable PresentationDID AuthOIDC