요약

  • RFC 9901은 IETF Standards Track 규격으로, JWS 페이로드에서 JSON 요소의 선택적 공개를 정의하며 JWT가 주요 사용 시나리오입니다. RFC 7515와 RFC 7519는 참조되는 JWS/JWT 기반선만 제공합니다.
  • 제어 사슬은 '발행자가 한 번 서명하면 끝'이 아닙니다. 발행자는 숨길 수 있는 구조를 결정하고, 홀더는 Disclosure를 선택하며, 검증자는 증거 요구를 제시하고, 애플리케이션 구성이 홀더 키 바인딩의 필요 여부를 결정합니다.
  • SD-JWT는 암호화, 영지식 증명 또는 익명 자격 증명이 아니며, 비연관성을 자동으로 보장하지도 않습니다.

동작 방식

객체 속성의 경우 발행자는 서명된 페이로드에서 평문을 다이제스트로 대체하고, salt, 속성명, 속성값을 포함하는 Disclosure를 별도로 제공합니다. 배열 요소의 경우 Disclosure는 salt와 값으로 구성됩니다. JSON 배열은 UTF-8로 인코딩한 뒤 base64url로 인코딩하여 다이제스트를 계산합니다. 공개 가능한 각 클레임에는 암호학적 무작위성을 갖고 서로 독립적이며 고유한 salt를 사용해야 하며, 무작위 부분은 최소 128비트 이상 권장되고 공개 전까지 홀더만 알아야 합니다.

최상위_sd_alg는 공개 해시 알고리즘을 지정합니다. 이 필드는 중첩할 수 없고 기본값은sha-256이며, 구현은sha-256을 반드시 지원해야 합니다. 발행자가 서명한 JWT는 검증되어야 하며none을 사용할 수 없습니다. 검증자는 먼저 발행자 서명을 확인한 뒤, 제출된 각 Disclosure에 대해 다이제스트를 다시 계산하여 서명된 페이로드의 다이제스트와 비교하고, 그 후에야 처리된 페이로드를 재구성합니다. 다이제스트 불일치, 서명 무효, 허용되지 않는 알고리즘, 형식 오류 또는 필수 클레임 누락이 있으면 거부해야 합니다.

구조는 중첩될 수 있습니다. 숨겨진 하위 항목은 부모 Disclosure에 의존할 수 있으며, 홀더는 완전하고 유효한 재귀 의존 사슬을 제출해야 합니다. 디코이 다이제스트는 숨겨진 클레임의 수나 존재 여부를 모호하게 만들 수 있지만 토큰을 커지게 합니다. 디코이는 사이드 채널 완화 수단이지 연관 방지 메커니즘이 아닙니다.

키 바인딩은 정책에 따라 결정되며 보편적으로 강제되지 않습니다. 프로파일이나 사용 사례에서 바인딩을 요구하는 경우, SD-JWT는 홀더 공개키 또는 그 참조를 담고, 홀더가 KB-JWT를 서명합니다. KB-JWT의typ은kb+jwt이며iat,aud,nonce,sd_hash를 포함합니다.sd_hash는 정확한 발행자 서명 JWT와 선택된 Disclosure를 바인딩합니다. 검증자는 또한 홀더 키, 서명, 알고리즘, 유형, 시간 창, 수신자, nonce 및sd_hash를 확인해야 합니다.

exp처럼 유효성에 영향을 주는 클레임이 선택적 공개 대상으로 설계되면, 검증자가 거부에 필요한 데이터를 갖지 못할 수 있습니다. 애플리케이션은 필수 클레임을 규정하고 누락 시 거부해야 합니다. SD-JWT는 기밀성을 전송 프로토콜에 의존하며 자체 암호화 메커니즘이 없습니다. 개인정보 보호 또는 수동 연관 위험이 중요할 때는 기밀 전송을 사용해야 하고, JWE는 유출되기 쉬운 채널에서 SD-JWT를 감쌀 수 있습니다. salt는 기밀 전송을 대체할 수 없으며, 토큰에서 공개되지 않은 값을 복구할 수도 없습니다.

개인정보 보호 경계

선택적 공개는 익명 자격 증명의 비연관성이 아닙니다. 안정적인 발행자 서명 자격 증명은 공모한 발행자와 검증자가 동일한 자격 증명을 식별하게 할 수 있습니다. 일괄 발행 시 새로운 salt와 새로운 홀더 키를 사용하면 검증자 간 및 서로 다른 제시 간의 비연관성을 개선할 수 있지만, 발행자와 검증자의 공모에는 대항할 수 없습니다. 이 RFC는 배포 규모, 채택률, 법적 컴플라이언스, 구현 성능, 월렛 사용자 경험 또는 특정 폐기 방식에 대한 결론도 제시하지 않습니다.

출처