요약

  • draft-ietf-oauth-status-list-21은 각 참조 토큰에 URI와 압축된 상태 목록 내 색인을 할당한다. 보호된 상태 목록 토큰은 여러 토큰에 대해VALID,INVALID,SUSPENDED또는 애플리케이션별 값을 한 번에 효율적으로 단언할 수 있다. 개정 21은 RFC Editor 대기열에 있는 승인된 인터넷 드래프트이며, 아직 RFC가 아니다.
  • 기본적으로 선택된 값은 상태 목록 토큰이 발급되었을 때의 상태를 설명한다.iat,exp,ttl은 발급, 유효성, 캐싱의 경계를 정하지만, 그 자체로 전환 시각, 권한을 부여한 행위자, 원인, 제공자 게시 시각 또는 신뢰 당사자의 결정을 기록하지는 않는다.
  • Daniel Kade는 프로토콜 외부에서 최소화된 상태 결정 영수증을 제안한다. 토큰 및 목록 지문, URI/색인, 발급자 검증, 네 가지 별개 시계, 디코딩된 의미, 로컬 신선도 정책, 결정 및 이후의 대체가 그것이다. 이는 편집상 지침일 뿐 IETF 요구사항이 아니며, 사적 프레젠테이션 이력 창고가 되어서는 안 된다.

디지털 자격 증명이 거부된 지 6개월 뒤의 검토를 상상해 보자. 검증자는INVALID라고 적힌 한 줄을 보관했다. 그 자격 증명은 여전히 식별할 수 있고, 어쩌면 상태 목록 URI와 색인까지도 알 수 있다. 하지만 자신이 가져왔던 보호된 목록 바이트를 제시할 수는 없다. 해당 항목이 보유자의 사용 시도 전에 바뀌었는지 후에 바뀌었는지, 자신의 캐시가 정책 범위 안에 있었는지, 또는INVALID가 거부의 유일한 이유였는지 알지 못한다. 이후의 목록은 이제 다른 내용을 말하고 있다.

그 예시 어디에도 거부가 잘못이었다는 증거는 없다. 문제는 더 좁다. 남아 있는 값만으로는 그 결정을 재구성할 수 없다.

Token Status List는 상태를 압축하도록 설계되었지, 제도적 기억을 보존하도록 설계되지 않았다. 그것은 중요한 미덕이다. 신뢰 당사자는 검사를 수행할 때마다 식별 가능한 자격 증명 하나에 대해 발급자에게 문의할 필요가 없다. 여러 항목이 담긴 목록을 가져와 보호된 객체를 검증하고, 참조 토큰에 명시된 색인을 찾아 몇 개의 비트를 해석하면 된다. 이 메커니즘은 각 토큰에 대한 이벤트 문서를 담지 않음으로써 확장성과 일종의 군집 프라이버시를 얻는다.

거버넌스 오류는 이 경제성을 거꾸로 읽을 때 시작된다. 간결한 현재의 단언은 중요한 결과에 영향을 줄 수 있다는 이유만으로 연대기가 되지 않는다. 그 결과를 방어하는 데 필요한 기록은 여러 행위자와 여러 시계에 걸쳐 존재한다.

승인된 드래프트도 아직 발행된 RFC는 아니다

Datatracker 기록은 2026년 6월 21일자 개정 21을 OAuth Working Group의 표준 트랙 인터넷 드래프트로 식별한다.이력에는 6월 4일 개정 20에 대한 IESG 승인, RFC Editor 대기열 진입, 6월 21일 개정 21, 그리고 8월 13일 RFC Production Center의 상태Awaiting First editor가 기록되어 있다. 이는 생산 처리 중인 성숙하고 승인된 명세다. 아직 RFC가 아니며, 편집 처리가 최종 텍스트를 여전히 바꿀 수 있다.

개정 21 텍스트는 2026년 12월 23일에 만료된다. 공식20→21 비교는 정확한 버전 경계를 제공한다. 이 기사는 명시된 연구 기준 시점에서 개정 21을 분석하며, 문서의 진행 상황에서 배포 보급률을 추론하지 않고,OAuth Working Group을 어떤 구현의 운영자로 취급하지도 않는다.

이 드래프트는 JOSE 또는 COSE로 보호되는 토큰을 다루며, 용도 가운데 JWT, SD-JWT, CWT, ISO mdoc을 명시한다.JWS와JWT는 JSON 지향 서명 및 클레임 기반을 제공한다.CWT와COSE는 콤팩트한 CBOR 환경을 위한 관련 작업을 수행한다. 상태 메커니즘은 자격 증명의 두 번째 사본이 아니다. 그것은 발급 후 의미가 바뀔 수 있는 참조 토큰에 관한 별도로 보호된 진술이다.

하나의 색인은 하나의 단언을 선택한다

참조 토큰은status클레임을 지닌다. 이 메커니즘에서 그status_list멤버는 음수가 아닌idx와 상태 목록 토큰을 식별하는uri를 포함한다. 이 쌍은 보유자 또는 신뢰 당사자에게 상태를 어디서 가져오고 어느 항목을 검사해야 하는지 알려 준다.

상태 발급자는 참조 토큰당 1, 2, 4 또는 8비트를 선택한다. 서로 다른 색인을 할당하고, 값을 최하위 비트에서 최상위 비트 순으로 바이트에 패킹한 뒤, ZLIB 형식의 DEFLATE를 사용해 바이트 배열을 압축한다.DEFLATE는 압축 데이터 형식을 정의하고ZLIB은 그 래퍼를 정의한다. 결과는 JWT 또는 CWT로 표현되고 서명 또는 MAC으로 보호되는 상태 목록 토큰 안에 들어간다.

이 아키텍처는 세 역할을 분리한다. 발급자는 참조 토큰을 만든다. 상태 발급자는 상태 정보를 받아 보호된 목록을 만든다. 상태 제공자는 그 객체를 제공한다. 한 조직이 세 역할을 모두 수행할 수 있지만, 프로토콜은 이들의 분리를 허용하기도 한다. 제삼자는 보호된 내용을 변경할 권한을 얻지 않고도 서명된 목록을 호스팅할 수 있다.

그 구분은 감사에 중요하다. 상태 발급자의 서명 또는 MAC은 목록 바이트의 출처와 무결성을 확립할 수 있다. 제공자의 HTTP 응답은 전달 관찰을 확립한다. 어느 것도 상태 뒤에 있는 현실 세계 또는 행정적 이벤트가 언제 발생했는지를 확립하지 않는다. 발급자와 제공자가 다르면 이들은 눈에 띄게 다른 통제 표면이고, 같은 회사라면 여전히 다른 기능이다.

상태 레지스트리는 비트가 의미할 수 있는 범위를 더 제한한다. 개정 21은0x00을VALID,0x01을INVALID,0x02를SUSPENDED에 할당하며, 지정된 애플리케이션별 범위와 향후 등록을 위한 여지를 둔다. 비트가 하나보다 많다고 해서 동시에 여러 상태가 생기는 것은 아니다. 전체 비트 그룹은 정확히 하나의 값을 나타낸다. 애플리케이션은 의미가 같거나 호환될 때 등록된 값을 사용해야 한다.

따라서 상태 값은 정의된 어휘 아래의 단언이다. 그것은 토큰의 전체 유효성 결정이 아니다. 드래프트는 참조 토큰 처리가 먼저라고 명시한다. 목록 항목이VALID라고 읽히더라도 만료된 토큰은 만료된 상태로 남는다. 서명, 필수 클레임, 대상자 또는 다른 형식 규칙도 상태 목록을 조회하기 전에 실패할 수 있다. 상태 평가 이후의 로컬 애플리케이션 제한은 신뢰 당사자의 재량에 남는다.

네 개의 시계는 하나로 합칠 수 없다

첫 번째 시계는 상태 원천 시계다. 행정적 또는 현실 세계의 상태가 실제로 언제 바뀌었는가? 자격 증명은 계정 폐쇄 후 철회되거나, 위험 이벤트 후 일시 중지되거나, 검토 후 복원될 수 있다. 개정 21은 그 상류 워크플로를 정의하지 않으며, 간결한 항목은 그 행위자, 원인 또는 이벤트 시각을 담지 않는다.

두 번째 시계는 목록 발급이다. JWT 상태 목록 토큰에서iat는 필수이며 보호된 목록이 언제 발급되었는지 식별한다.exp는 권장되며 발급자가 목록이 만료되었다고 보는 시점을 표시한다. 그 클레임은 단언의 경계를 정한다. 선택된 항목이 언제 바뀌었는지를 소급해 드러내지는 않는다.

세 번째 시계는 전달과 조회다. 상태 제공자는 객체를 직접 또는 CDN 같은 인프라를 통해 제공할 수 있다. 신뢰 당사자는 특정 시각에 응답을 관찰한다. 그 시각은 발급과 다를 수 있으며, 어느 것도 변경이 발급자의 원천 시스템에 들어온 순간과 반드시 같지는 않다.

네 번째 시계는 신뢰 당사자의 결정이다. 자격 증명을 즉시 평가할 수도 있고, 대기열 지연 후에 또는 이후 배치의 일부로 평가할 수도 있다. 가져온 목록이 충분히 신선한지와 디코딩된 값에 어떤 결과가 따르는지는 로컬 정책이 결정한다.

ttl은 이 시계들 가운데 일부를 연결하지만 하나로 통일하지는 않는다. 이는 권장되는 보호 클레임으로, 소비자가 새 사본을 가져와야 하기 전에 상태 목록 토큰을 얼마나 오래 캐시할 수 있는지 표현한다. 개정 21은 두 가지 방어 가능한 전략을 설명한다. 신뢰 당사자는 자체 조회 시각에ttl을 더한 뒤 다시 가져와 제공자 부하를 분산할 수 있다. 중요한 사용 사례에서는iat + ttl에 업데이트를 확인해 약간의 배포 오프셋을 허용할 수 있다.exp와ttl이 HTTP 캐시 헤더와 충돌하면 보호된 토큰 클레임이 우선한다.

궁극적으로 신뢰 당사자는 생태계 지침과 로컬 경계 안에서 검사 간격을 선택한다. 짧은 간격은 신선도를 높일 수 있지만 불합리한 요청량을 초래할 수 있다. 보안 고려사항은 클라이언트가exp와ttl의 경계를 정하도록 경고하여, 발급자가 제공자 URL에 우발적으로 또는 악의적으로 과도한 요청을 유발할 수 없게 하라고 말한다. 따라서 신선도는 비트의 마법 같은 속성이 아니라 공유된 운영상 결정이다.

과거 조회는 선택 사항이며 이벤트 원장이 아니다

기본적으로 개정 21은 최신 상태 정보를 제공하고 목록 발급 시점의 상태를 설명한다. 또한 선택적 과거 해석을 정의한다. 상태 목록 요청에time=<timestamp>를 추가하는 것이다. 지원 서버는 보호된 유효성 구간이 해당 시각을 포함하는 목록을 반환하거나 오류를 반환할 수 있다. 정적 호스팅이 쿼리를 무시하고 현재 객체를 반환하면, 요청된 시각이 반환된 토큰의iat/exp구간 안에 들지 않는 한 클라이언트는 이를 거부해야 한다.

과거 조회는 한 가지 질문을 개선한다. 서비스가 지정된 시각에 관해 어떤 보호된 목록을 단언했는가? 그것은 여전히 정확한 전환 이벤트, 이유 또는 권한을 반드시 공개하지는 않는다. 여러 연속 스냅샷은 두 발급 시각 사이의 변경을 경계지을 수 있지만, 경계는 이벤트 타임스탬프가 아니다. 상류 전환을 아는 서비스는 이를 별도로 보관할 수 있다. 전송 형식이 그것을 만들어 내지는 않는다.

프라이버시 비용은 부수적인 것이 아니다. 드래프트는 강한 이유가 있고 그 함의를 이해하지 않는 한 구현자가 과거 요청을 피하라고 권장한다. 동일한 URI/색인을 반복 저장하고 확인하는 검증자는 상태 프로필을 구축할 수 있다. 현재 및 과거 목록을 다운로드하는 외부인은 발급량이나 철회율을 추정할 수 있다. 선택적 스냅샷 조회를 보편적 영구 로그로 바꾸면, 이 메커니즘을 매력적으로 만든 데이터 최소화 목적이 무너질 수 있다.

압축은 경계 안에서만 프라이버시를 보호한다

여러 참조 토큰을 하나의 목록으로 묶으면 발급자가 어느 정확한 토큰이 요청을 유발했는지 추론하기 어려워진다. 개정 21은 이를 군집 프라이버시라고 부른다. 더 큰 군집은 익명성 집합을 개선하지만 전송 비용을 높인다. 이는 실제 설계 트레이드오프이지 절대적 익명성 주장이 아니다.

HTTP 요청은 여전히 신뢰 당사자의 주소를 드러낼 수 있다. 고유 URI, 토큰당 하나의 목록, 비정상적으로 작은 목록 또는 두드러지는 목록 크기는 군집을 줄일 수 있다. URI/색인 튜플 자체가 추적 가능한 데이터이며, 공모하는 신뢰 당사자들은 프레젠테이션 전반에서 이를 비교할 수 있다.RFC 9901은 비연결 공개가 특히 중요한 SD-JWT 맥락을 제공하며,Oblivious HTTP는 드래프트가 요청자 관찰 가능성을 줄이기 위해 인용한 릴레이 기법 가운데 하나다.

드래프트는 보편적 배열 대신 완화책을 제시한다. 제삼자 호스팅, 비순차적 또는 무작위 색인, 미끼 항목, 다중 목록, 일회용 배치, 재발급 시 새 항목이다. 또한 비일상적 상태가 정보를 유출할 수 있다고 경고한다. 예를 들어SUSPENDED는 이분법적 유효/무효 결과보다 더 구체적인 무언가를 전달한다. 생태계는 그 추가 의미가 프로파일링 표면을 정당화하는지 결정해야 한다.

이 프라이버시 경계는 감사 설계를 제약한다. 좋은 영수증은 모든 자격 증명 프레젠테이션에 대한 은밀한 종단 문서를 모으지 않고도 결정을 입증해야 한다. 지문, 제한된 보존 기간, 접근 통제를 사용해야 한다. 과거 조회는 실제로 발생했을 때만 기록해야 하며, 필드가 존재한다는 이유만으로 과거 수집을 가능하게 해서는 안 된다.

디코딩은 결정 단계이지 사무적 배관이 아니다

1비트 항목은 잘못 읽기에는 너무 작아 보인다. 드래프트의 보안 섹션은 그렇지 않다고 말한다. 비트 순서는 각 바이트 안에서 최하위에서 최상위로 진행되며, 바이트는 정상 순서로 진행된다. 잘못된 데이터를 압축 해제하거나, 잘못된 바이트 또는 비트 위치를 계산하거나, 범위를 벗어난 색인을 수용하는 구현은 잘못된 상태에 도달할 수 있다. 개정 21은 테스트 벡터를 제공하고 그 사용을 권장한다.

검증 순서는 의도적으로 계층화되어 있다. 먼저 참조 토큰을 검증한다. 그다음 URI를 해석하고 상태 목록 토큰을 검증하며, 보호된 유형과 클레임을 포함한다. 그 주체를 URI에 바인딩한다.iat,exp,ttl및 로컬 신선도 규칙을 적용한다. 압축을 해제한다. 색인된 값을 읽는다. 등록된 의미를 해석한다. 그런 다음에야 애플리케이션 정책을 적용한다.

색인이 범위를 벗어나면 어떤 상태 진술도 할 수 없으며 참조 토큰은 거부되어야 한다. 상태 목록 검사가 실패하면 드래프트는 어떤 상태 진술도 할 수 없으며 토큰을 거부해야 한다고 말한다. “상태 진술 없음”은INVALID의 또 다른 표기가 아니다. 정의된 근거를 얻는 데 실패한 것이다. 감사 기록은 그 구분을 보존해야 한다.

감시 사본이 아니라 결정을 보존하라

중요한 결과를 낳는 사용 사례에서 가장 작은 방어 가능한 상태 결정 영수증은 두 개의 지문과 네 개의 시계를 갖는다. 전체 자격 증명을 보관하지 않고 참조 토큰을 지문으로 남기며, 평가된 정확한 상태 목록 토큰을 지문으로 남긴다. URI와 색인, 상태 발급자, 관찰된 제공자, 키 해석 및 서명 또는 MAC 결과, 결과와 관련된 디코딩 구현 또는 테스트 벡터 적합성을 기록한다.

그다음 실제로 알려진 경우 상태 원천 전환 시각을 보관하고, 그렇지 않으면unknown으로 둔다. 목록의iat와exp,ttl정책, 제공자 가져오기 시각, 사용 시 캐시 나이, 결정 시각을 보존한다. 요청이 현재였는지 과거였는지, 요청된 타임스탬프, 디코딩된 숫자 값과 등록된 의미, 신뢰 당사자 자체의 신선도 경계, 애플리케이션 규칙, 취한 조치를 기록한다.

마지막으로 결정에 끝맺음을 준다. 이후 목록이 관찰을 대체할 수 있다. 이의 제기가 조치를 뒤집을 수 있다. 토큰은 독립적으로 만료될 수 있다. 영수증은 당시 시스템이 실제로 본 것을 다시 쓰지 않고 그 정정 또는 종결을 연결해야 한다.

이것은 Token Status List에 필드를 추가하자는 제안이 아니다. 지속적 결과를 설명해야 하는 조직을 위한 Daniel Kade의 프로토콜 외부 통제다. 해시, 최소화된 참조, 짧은 보존 기간은 원시 자격 증명, IP 주소 또는 영구 요청 이력보다 선호될 수 있다.정책의 거울은 선언된 규칙과 관찰 가능한 결정을 비교하는 규율을 제공하고,실행 코드 우선은 구현된 경로를 시야에 두게 하며,옹호가 아닌 현실은 불확실성이 서사 속에서 살아남도록 요구한다. 그 에세이 어느 것도 특정 배포에 관한 기술적 증거는 아니다.

출처