1. RFC 9901 탄생

2025년 11월 19일, "Selective Disclosure for JSON Web Tokens", 통칭 SD-JWT (에스디 조트)를 정한 사양이 RFC 9901 로 공개되었습니다.

저자는 다음 3명입니다.

JSON Web Token (JWT) [RFC 7519]JSON Web Signature (JWS) [RFC 7515]ID 토큰JWT 액세스 토큰 [RFC 9068]에서 널리 사용되어 온 인터넷 표준입니다.
거기에 「필요한 부분만, 나중에 잘라 보일 수 있다」라고 하는 새로운 능력을 주는 것이 SD-JWT 입니다.

JOSE 패밀리 (JWS / JWT / JWE)의 계보에,
"Selective Disclosure(선택적 공개)"라는 새로운 기둥이 공식 ​​RFC로 합류했다고 위치할 수 있습니다.


2. SD-JWT는 무엇을 위한 명세?

2-1. 종래의 JWT의 과제:「수시 발행」or 「전부 들어가」

기존의 JWT는, 「서명이 끝난 JSON의 덩어리」를 그대로 서비스에 건네주는 모델이 기본이었습니다.

  • 발행자(IdP나 인증 서버)가 사용자 정보를 정리해 JWT에 포장한다
  • 받은 서비스(리라인 파티)가 그 내용을 모두 읽을 수 있다

이것은 동적으로 수시로 발행하는 OpenID Connect와 같은 모델이라면 선택적 공개도 데이터 최소화도 RP간의 언링커빌리티(RP+RP'-U Unlinkability)도 실현할 수 있다(전형적으로는 PPID=Pairwise Pseudonymous Identifier 를 사용합니다)입니다만, 「사용 목적을 모르는 상태로 미리 증명서를 발행해 두고 나중에 사용한다」라고 하는 것을 하고 싶은 경우, 모두 할 수 없다고 하는 과제를 안고 있었습니다.

예를 들면 「연령」 「주소」 「이름」 「메일 주소」가 1개의 JWT 에 들어가 있을 때, 서비스 측은 사실은 「20세 이상인가 어떤가」만 알면 좋은 장면에서도, 사전 발행해 두고 있던 JWT를 사용하는 경우에는, 주소나 성명까지 전부 보여 버립니다.

이 「전부 들어가」구조는 실장으로서는 심플합니다만, 모아두고 사용한다고 하는 것을 하고 싶은 경우,

  • 선택적 공개가 불가능 = 데이터 수집 최소화 원칙을 충족할 수 없음
  • RP+RP'-U Unlinkability도 충족할 수 없다

같은 한계를 가지고있었습니다. (구현의 단순함과의 트레이드 오프인 것입니다만.)

2-2. 지갑 모델과의 궁합

한편, 저축한 것을 나중에 사용하고 싶다는 유스 케이스는 분명히 있습니다. 전파가 통하지 않는 곳에서의 이용이나, 학교가 망가져 버린 후의 졸업 증서의 제시등이 전형적인 유스 케이스입니다. 「전파가 통하지 않는 것은 그렇게 있는가?」라고 생각할지도 모릅니다만, 그것은 일본이 축복받은 환경에 있기 때문에, 유럽의 석조 건물 안 등, 전파 상황은 추운 한이고, 역으로부터 조금 떨어진 것만으로, 만하임등의 중심 도시에서도, 옥외에서도 전파가 통하지 않게 되어 버립니다. 광대한 미국 등도 물론 그렇네요. 그런 일이 있거나 유럽 EUDI 월렛 등, 최근의 아이덴티티 월렛에서는,

  • 하나의 월렛(스마트폰 앱)이 여러 Verifiable Credentials(VC) 저장하고,
  • 이용자가 「이 서비스에는 이 항목만을 보여준다」라고 선택해 제시한다

라는 모델이 전제가 되고 있습니다. 이것이라면, 발행할 때만, 월렛과 발행자는 ONLINE으로 연결되어 있으면 좋게 되기 때문입니다.

여기서 필요한 것은,

「저장해 둔 하나의 서명 첨부 데이터 중에서, 나중에서 일부만 선택해, 안전하게 보여지는 포맷」

입니다. 이것을 정의하는 것이 RFC 9901 SD-JWT입니다.


3. SD-JWT를 한마디로 말하면

매우 어색하게 말하면, SD-JWT는 다음과 같은 구조입니다.

  1. 베이스는 기존대로 서명된 JWT(JWS)
  2. 그러나 일부 클레임은해시 값만JWT에 넣어 라.
  3. 원래 값과 솔트를 합친 공시 별도로 보관하고 필요할 때만 Verifier에 전달
  4. Verifier는
    • Disclosure에서 해시를 다시 계산합니다.
    • 서명 된 JWT의 해시와 일치하는지 확인하여
    • "확실히 Issuer가 서명 한 데이터의 일부"라고 확인할 수 있습니다.

또한 토큰의 무단 전송을 방지하기 위해 토큰 이용자의 열쇠 페어에 묶는 구조(Key Binding) 도 준비되어 있습니다.
이것과 결합 된 구조 SD-JWT+KB 라고합니다.


4. 3명의 등장 인물과 SD-JWT의 흐름

SD-JWT의 기본적인 등장 인물은 VC의 세계와 같습니다.

  • Issuer(발행자)
    관공서, 은행, 대학 등. 사실에 책임이 있는 조직.
  • Holder(유지자)
    사용자 본인. 스마트 폰의 월렛 앱에서 자격 증명을 유지합니다.
  • Verifier(검증자)
    서비스 제공자. 은행 계좌 개설, 연령 확인, 입관 관리 등.

일반적인 흐름은 다음과 같습니다.

  1. 발행(Issuance)
    • 발행자(Issuer)는 사용자의 속성 정보(주소·생년월일 등)를 JSON에 정리한다
    • '나중에 선택적으로 공개하고 싶은 항목'에 대해서는
      값 + 임의의 소금에서 해시를 계산하고 해시만 JWT에 포함
    • 원래 값 + 솔트는 별도로 Disclosure로 제공됩니다.
    • 서명 된 JWT와 여러 Disclosure를 결합하여 "SD-JWT"로 Holder에 전달
  2. 제시(Presentation)
    • 사용자가 특정 서비스를 이용하려고
    • 월렛은 SD-JWT 중에서 Verifier에 보여주고 싶은 항목의 Disclosure만을 선택한다
    • 서명 된 JWT + 선택한 Disclosure + (필요한 경우 Key Binding JWT)를 Verifier로 보냅니다.
  3. 검증(Verification)
    • Verifier는
      • Issuer 공개 키로 JWT 서명 확인
      • Disclosure를 사용하여 각 항목의 해시를 다시 계산하여 JWT의 해시와 일치하는지 확인
    • 이를 통해 "Issuer가 서명 한 데이터의 일부임"을 확인하면서 공개되지 않은 항목을 보호합니다.

5. 약간 기술적인 이야기 : 소금과 Disclosure

5-1. 솔트 첨부 해시에 의한 선택적 개시

각 클레임(주소나 생일 등)은

  • 솔트 + 값 + (경우에 따라 클레임 이름)

에서 해시를 계산하고 해시 값을 JWT에 포함합니다.

실제로 공개할 때는 Disclosure로

  • 「솔트・클레임명・값」

를 Verifier에 전달합니다.

Verifier 는 같은 순서로 해시를 재계산해, JWT 내의 해시와 일치할지 어떨지로 변조의 유무를 확인합니다.
솔트가 포함되어 있기 때문에 미공개 클레임의 값을 추측하기 어렵습니다.

5-2. Disclosure라는 「공개 파트」

RFC에서 Disclosure는 Base64url로 인코딩된 JSON 배열로 정의되며, 예를 들면 다음과 같습니다.

  • 요소 0: 소금
  • 요소 1: 클레임 이름(배열 요소의 경우 생략될 수 있음)
  • 요소 2: 클레임 값

지갑 내부에서,

"하나의 큰 자격 증명을 세세한 Disclosure의 집합으로 가져 가서 필요한 것만 꺼내 보내"

라는 이미지로 파악하면 알기 쉽다고 생각합니다.

5-3. Key Binding 및 SD-JWT+KB

SD-JWT만으로는, 「토큰을 카피해 타인이 제시해 버린다」공격(리플레이 공격)의 리스크가 남습니다.
따라서 RFC 9901은 SD-JWT를 Holder의 키 쌍에 연결합니다. 키 바인딩 을 정의합니다.

  • SD-JWT에 Holder 공개 키(또는 그 참조) 포함
  • Holder는 발표시 키로 서명했습니다. 키 바인딩 JWT (KB-JWT) 함께 보내기
  • Verifier는
    • SD-JWT와 KB-JWT가 동일한 키에 연결되어 있는지
    • 그 비밀 키를 Holder가 실제로 가지고 있는지 확인하십시오.

키 바인딩 필수 SD-JWT+KB 하면 VC 사본에 대한 내성이 높아집니다.

참고: Holder Binding에는 Key Binding, Claim Binding, Biometrics Binding이 있습니다. +KB는 이 중 키 바인딩을 실현합니다. 다만, Key Binding 의 경우, 디바이스 등 키를 보관하고 있는 미디어 자체를 양도되어 버리면, 스푸핑이 가능하다 (이것을, Alice-to-Bob Attack 등이라고 합니다)라고 하는 과제는 있습니다. 은행 계좌의 매매 등이 바로 그에 해당합니다. 이를 방지하려면 일반적으로 Biometrics Binding이 필요합니다.

5-4. JSON 구조 및 배열에 대한 대응

RFC 9901은 단순한 플랫 JSON뿐만 아니라,

  • 중첩된 객체
  • 배열 요소별 공개
  • "더미 해시 (Decoy Digests)"에 의한 패턴 숨김

라고 하는 케이스에의 대응도 정의하고 있습니다.

그러면

  • "한사람 한사람, 정확히 같은 구조의 자격증명"이라고 추측되지 않도록 한다
  • 공개된 항목 수만으로 추적되는 위험을 줄입니다.

같은 궁리가 가능합니다.


6. SD-JWT와 VC 아이덴티티 지갑

6-1. SD-JWT VC:VC 포맷으로서의 위치설정

IETF는 RFC 9901 SD-JWT를 사용합니다. Verifiable Credentials를 표현하는 사양 と し て
"SD-JWT-based Verifiable Credentials (SD-JWT VC)" 초안이 수립되었습니다.

이것은

  • JSON 형식의 VC
  • SD-JWT로 선택적 공개 가능
  • 그 검증 방법을 정한다.

라는 역할을 가진 사양입니다. 현재 WG Last Call에 들어가기 전의 WG 리뷰 중, 필자도 검토자로서28점 정도 에디토리얼 개선(일부 기술로 취할 수 있는 것도 있습니다만)를 제안하고 있습니다. (미국인이나 독일인이 쓰면 한 문장이 길어져 읽기가 어려워지기 때문에 그것을 분해하거나, 수신의 다용에 의해 의무의 실행자가 모호해지는 문제라든지, 보안, 프라이버시, 공공 평성에 대한 고려사항이라 할 수 있다.sd-jwt-decoder"도 만들었습니다.GitHub에도 있습니다.(HTML 1장 페라이므로, 로컬에서도 간단하게 움직일 수 있습니다=내가 비행기 위에서 드래프트를 검증하는데 필요했다) 때문에, 버그등 찾아내면 풀릭 부탁합니다.

6-2. EUDI 월렛에서의 이용

유럽위원회의 EUDI Architecture Reference Framework (ARF) 그렇다면 유럽 디지털 ID 지갑에서 사용되는 표준으로,

  • OpenID for Verifiable Credentials (OpenID4VCI / OpenID4VP)
  • SD-JWT/SD-JWT VC
  • ISO/IEC 18013-5 모바일 운전 면허증(mDL)

등을 조합하여 이용하는 것으로 나타났습니다.

이 맥락에서 RFC 9901은

EUDI 월렛과 같은 신원 지갑에 저장된 VC
JWT / JOSE 기반으로 구현할 때 핵심 형식 "

라는 위치가 됩니다.

6-3. 월렛 이용자로부터 본 장점

일반 이용자의 체험으로서는, 예를 들면 다음과 같은 형태가 됩니다.

  • 연령 확인
    편의점에서는 '생년월일'이 아니라 '20세 이상이다'의 진위만 제시
  • 주소 확인
    우편 주문 사이트에는 "배송에 필요한 주소"만을 제시하고 다른 속성은 보이지 않는다
  • 본인확인(KYC)
    은행 및 증권 회사에게 필요한 속성만을 조합하여 제시하고 같은 VC를 다른 서비스에서 재사용

이것들은 모두, 「하나의 서명 첨부 데이터를 세세하게 분해해 필요한 부분만 꺼낸다」라고 하는 SD-JWT 의 성질에 의해 실현됩니다.


7. 생태계 확산 (개요)

이미 여러 OSS 및 상용 솔루션이 SD-JWT / SD-JWT VC를 구현에 통합하고 있습니다.

  • 다양한 월렛 프레임 워크에서 SD-JWT 지원 : 내가 이사를 맡고있다,Siros Foundation 가 내고 있는 wwWallet 도 그 중 하나입니다.
  • Authlete 등에 의한 SD-JWT VC 발행 엔드 포인트의 제공
  • EUDI 월렛 프로젝트 및 SPRIND 이니셔티브 채택
  • OpenID Foundation을 통해 OpenID4VC와 SD-JWT VC를 결합한 고 보안 프로파일 (HAIP) 개발

이러한 움직임 위에 RFC 9901은 "기반의 한 장"으로 자리 매김됩니다.


8. 정리

  • RFC 9901 JWT / JWS에 "선택적 공개"라는 능력을주는 인터넷 표준.
  • SD-JWT는
    • 서명 된 JWT 안에는 해시 만 넣습니다.
    • 원래 값과 솔트를 Disclosure로 필요한 경우에만 표시
    • 그래도 Issuer의 서명으로 진정성을 유지
      라는 포맷을 정의하고 있다.
  • 키 바인딩 추가 SD-JWT+KB 이를 통해 지갑 소유자에게 묶인 안전한 발표가 가능합니다.
  • SD-JWT VC 초안, EUDI ARF 및 OpenID4VC 프로파일과 결합하여,
    신원 지갑에 저장된 VC의 핵심 형식 중 하나 로 사용된다.

JOSE / JWT의 계보에 새로운 조각이 더해지면서 ​​월렛 기반 디지털 ID 기반의 현실적인 구현 패턴이 하나 명확해졌다고 할 수 있습니다.