DPoP 키를 회전할 때 기존 access token의 유효성을 어떻게 결정하나요?

기존 access token의 키 계약은 회전으로 자동 변경되지 않습니다. T1이 cnf.jkt=A로 발급됐다면 T1은 키 A proof와만 결합되고, client가 새 키 B를 만든 뒤 T1과 B proof를 제출하면 B의 thumbprint가 달라서 거절됩니다. 이것은 회전 실패가 아니라 sender constraint가 의도대로 작동한 결과입니다. 새 키를 사용하려면 AS가 허용한 refresh 또는 재인증 거래에서 B proof를 제시해 T2: cnf.jkt=B를 받아야 합니다.

상태를 12:00: T1(cnf=A, exp=12:10), current=A로 두면 T1+A는 통과합니다. 12:01에 current를 B로 바꾼 순간 T1+B는 cnf mismatch가 되고, refresh에서 기존 자격과 회전 정책을 통과해 T2를 발급받은 뒤 T2+B가 통과합니다. refresh token도 DPoP-bound라면 refresh 요청은 기존 키 A와 맞아야 하는지, 정상 회전을 위해 새 키를 어떻게 증명할지 별도 계약이 필요합니다.

키 B를 만든 사실만으로 이미 발급된 A token이 즉시 폐기된다고 단정할 수 없습니다. AS가 token family 회수, introspection 상태, 짧은 access-token TTL, refresh rotation 중 무엇을 제공하는지에 따라 A의 잔여 창이 달라집니다. A private key가 유출된 경우 정상 회전과 달리 즉시 회수·재인증을 선택해야 할 수 있습니다. 회수 endpoint나 introspection이 없다면 access token의 짧은 TTL과 refresh family 폐기가 남은 완화책이지만, 이미 탈취된 키가 만료 전 요청을 만드는 창까지 없애지는 못합니다. 모든 공개키를 허용하거나 cnf 비교를 생략하는 편법은 회전은 쉽게 하지만 DPoP를 bearer로 되돌립니다. 동시 refresh 결과, 네트워크 재시도, 분실 기기 복구도 테스트해 새 token이 어느 키에 귀속됐는지 결정적으로 남겨야 합니다.