요약

  • WebAuthn Level 4의remoteClientDataJSON초안은 기본적으로 비활성화되며 오리진별 권한 부여를 요구하지만, 허용된 로컬 오리진이 원격 클라이언트가 원격 오리진과 RP ID를 올바르게 검증했다는 증거가 되지는 않습니다.
  • 배포는 초안이 의도한 역할 분담을 유지하면서 해시로 결합된 클라이언트 간 검증 영수증을 유지해야 합니다. 로컬 사용자 에이전트가 원격 클라이언트의 전체 검증을 반복할 필요는 없습니다.

2026년 9월 15일자 Web Authentication Level 4 첫 공개 작업 초안(First Public Working Draft)에서 중요한 것은 새로운 암호 프리미티브가 아닙니다. 핵심은 책임의 이전입니다.

일반적인 WebAuthn 모델에서 브라우저는 자신의 실행 컨텍스트로부터 호출자의 오리진을 도출합니다. 신뢰 당사자 식별자(RP ID)는 별도의 관련 오리진 절차를 제외하고, 일반적으로 오리진의 실효 도메인과 같거나 그 등록 가능 도메인의 접미사여야 합니다. 브라우저가clientDataJSON을 구성하고, 인증자가 그 바이트의 해시에 서명하며, 신뢰 당사자가 의식 유형, 챌린지, 기대 오리진, RP ID 해시를 확인합니다.

웹 기반 원격 데스크톱은 이 깔끔한 국소성을 깨뜨립니다. 인증을 요청하는 웹사이트는 원격 호스트에서 실행되는 반면, 인증자는 사용자의 로컬 기기에 연결되어 있습니다. 로컬 브라우저가 자신의 컨텍스트에서 클라이언트 데이터를 다시 만들면, 원격 세션 안의 신뢰 당사자 오리진이 아니라 원격 데스크톱 웹 클라이언트의 오리진을 기록하게 됩니다. JSON 키 순서, 선택 필드, 공백의 무해한 차이조차 해시를 바꾸어 검증을 깨뜨릴 수 있습니다.

제안된remoteClientDataJSON확장은 원격 측에서 제공된 완전한 클라이언트 데이터 문자열을 받아들이는 방식으로 이 전송 문제를 해결합니다. 로컬 브라우저는 이를 파싱하여 등록 또는 인증에 사용하며, 내용을 추가·삭제·수정해서는 안 됩니다. 직렬화된 클라이언트 데이터를 제공된 문자열로 설정함으로써, 인증자가 원격 기기가 기대하는 것과 동일한 바이트에 서명하도록 만듭니다.

이는 보호 장치 없는 재정의가 아닙니다. 초안은publickey-credentials-remote-client-data-json을 강력한 기능이자 Permissions Policy로 통제되는 기능으로 지정합니다. 기본 권한 상태는denied이고, 명시된 기본 허용 목록은'none'입니다. 사용자 에이전트는 오리진별 구성만 노출해야 하며 "모든 오리진 허용" 스위치를 제공해서는 안 됩니다. 초안은 의식 도중 기회주의적 프롬프트가 아니라, 관리형 브라우저·기기 정책 또는 브라우저 설정에서의 오리진별 명시적 사용자 선택을 가리킵니다.

이것들은 실질적인 보호 장치입니다. 그러나 그것은 로컬 질문에 답합니다. 이 호출 오리진이 여기서 이 확장을 호출해도 되는가? 원격 질문에는 답하지 않습니다. 원격 클라이언트는 RP 오리진을 정확히 식별했으며, 명시된 RP ID가 그 오리진에 허용된다고 올바르게 판단했는가?

알고리즘은 이 구분을 명시적으로 만듭니다. 권한이granted가 아니면 로컬 브라우저는 작업을 거부합니다. 명시적인 RP ID도 요구하고 제공된 JSON을 파싱합니다. 그러나 그 직후, 원격 데이터 안의origin과 그 RP ID 사이의 통상 검사를 건너뜁니다. 초안은 로컬 클라이언트가 RP ID 관련 오리진 검사를 전부 원격 클라이언트에 위임한다고 말합니다. 보안 섹션도 똑같이 직설적입니다. 사용자 에이전트는 호출자가 원격 오리진을 정확히 제공한다고 신뢰하고, 원격 클라이언트가 RP ID 검증을 정직하고 정확하게 수행한다고 신뢰해야 합니다.

확장의 불리언 출력은 의도적으로 좁습니다.true는 확장이 처리되었음을 말할 뿐입니다. 원격 세션을 식별하거나, 검증 정책을 명명하거나, 어떤 관련 오리진 근거가 참조되었는지 보여주거나, 원격 검증 알고리즘의 결과를 담지 않습니다. 바이트 충실성도 마찬가지로 좁습니다. 로컬 브라우저가 클라이언트 데이터를 몰래 재구성하지 않았음은 확립하지만, 그 바이트 안에 이미 존재하는 오리진 주장이 진실하거나 승인된 것임은 확립하지 못합니다.

암호학적 성공에 그 이상의 의미를 부여해서는 안 됩니다. 인증자 서명은 결과를 제공된 클라이언트 데이터 해시와 인증자 데이터에 결합합니다. 신뢰 당사자에게는 여전히 의무 작업이 남아 있습니다. 유형과 챌린지를 확인하고, 클라이언트 데이터 오리진을 검증하고, 자신이 기대하는 RP ID 해시를 확인하는 것입니다. 이 통제들은 필수적입니다. 그러나 RP의 성공적인 판단은, 조직이 나중에 어떤 원격 클라이언트가 위임된 RP ID 판단을 수행했는지, 어떤 정책 버전이 그에 적용되었는지, 어떤 원격 채널이 관여했는지 재구성해야 할 때 여전히 운영상 공백을 남길 수 있습니다.

이 공백은 취약점의 증거가 아닙니다. 이 문서는 브라우저 배포, 상호운용성 또는 사고에 대한 보고서가 아니라 첫 공개 작업 초안입니다. 공개는 공개 검토를 시작하며, W3C 상태 섹션은 이것이 승인을 의미하지 않으며 초안은 변경될 수 있다고 말합니다. 공개된 W3C WebAuthn 저장소 이슈는 또한 용어 의존성을 추적합니다. 기본 비활성화 동작의 의도는 명확하지만,'none'은 의존하는 Permissions Policy 초안에서 아직 규범적 기본 허용 목록 용어로 정의되지 않았습니다. 이 이슈는 동작 변경을 요구하지 않습니다.

따라서 올바른 거버넌스 대응은 위임을 되돌리는 것이 아닙니다. 원격 측에는 로컬 브라우저가 갖지 못할 컨텍스트, 즉 관련 오리진 자료와 플랫폼별 앱 연결 규칙이 있습니다. 로컬 사용자 에이전트에 모든 원격 검사를 독립적으로 재현하도록 요구하면, 확장이 피하려고 설계된 불일치를 다시 만들어냅니다.

대신 배포는 인계 지점에서 클라이언트 간 오리진 검증 영수증을 만들어야 합니다. 영수증은 로컬 호출 오리진과 권한 부여를 원격 세션 및 인증된 채널에 결합하고, 원격 오리진, RP ID, 검증 알고리즘, 정책 버전을 기록하며, 관련 오리진 또는 앱 연결 근거를 참조하고, 정확한remoteClientDataJSON의 해시를 포함해야 합니다. RP 서버의 검증 결과가 이 체인을 닫아야 합니다. 예외, 만료, 폐기 및 이후 정정 사항은 원래 판단을 덮어쓰지 않고 가시적으로 유지되어야 합니다.

이 영수증은 배포 통제이며, WebAuthn 적합성 알고리즘에 추가하자는 제안이 아닙니다. 그 목적은 서로 다른 사실들을 구분된 상태로 유지하는 것입니다. 로컬 기능이 승인되었다, 원격 검증이 수행되었다, 바이트가 보존되었다, 사용자가 인증자와 상호작용했다, RP가 결과를 수용하거나 거부했다. 단일한 녹색 "WebAuthn 성공" 이벤트가 이 다섯 가지를 모두 안전하게 대변할 수는 없습니다.

출처