제안된 WebAuthn 차터는 원시 서명을 연다. 범위는 승인이 아니다

요약

• W3C가 제안한 웹 인증(Web Authentication) 차터는 WebAuthn이 중재하는 임의 데이터 서명을 범위에 넣되, 인증 자격 증명 키와 연관되되 구별되는 서명 키를 사용하도록 하고 있습니다.
• 제안은 에이전틱 AI와 검증 가능한 디지털 자격 증명을 예시로 들면서도, 나열된 중재 기능을 넘어서는 저수준 개인 키 접근과 독립적인 범용 암호 API는 계속 배제하고 있습니다.
• 범위가 곧 성숙도는 아닙니다. 보고 기준 시점에 차터 검토는 진행 중이며, Level 4는 첫 공개 작업 초안(FPWD)이 없고,sign풀 리퀘스트는 초안 상태이며, 설명 문서는 사용자 연구나 브라우저 구현자 신호가 없음을 보여줍니다.
• 공개 기능 채택 접수증은 차터 권한을 정확한 제안, 동의 및 키 분리 주장, 메시지 의미론, 검토, 테스트, 독립 구현, 권고안(Recommendation) 상태 및 실제 채택과 연결해야 합니다.

차터는 문을 열 수 있지만 그 문을 통해 무엇이 들어올지 정하지는 않는다

현재 웹 인증 워킹 그룹 차터는 인식 가능한 목적, 즉 웹 애플리케이션을 위한 강력한 인증을 중심으로 구성되어 있습니다. 그 범위는 오리진에 귀속된 키 쌍, 브라우저가 개인 키를 사용할 수 있음의 증명, 복구, 백업 및 관련 강화 기능을 다룹니다. 암호 연산이나 키 자료에 대한 저수준 접근은 제외합니다.

검토 중인 대체 차터는 이 경계를 바꿉니다. 항목 11은 표준 WebAuthn 인증 구조를 넘어 데이터 서명을 허용합니다. 이는 WebAuthn이 중재하는 원시 서명을 설명하며, 서명 키는 인증에 사용되는 자격 증명 키와 관련되되 구별됩니다. 에이전틱 AI와 검증 가능한 디지털 자격 증명 생태계를 예시로 인용합니다. 신규 항목 두 개는 자격 증명 관리자에 대한 신뢰 신호와 확장 기능의 기밀성에 관한 것입니다.

이것은 의미가 큰 장소(venue) 선택입니다. 다른 암호 프로토콜과 호환되는 서명을 만들 수 있는 웹 API는 단순히 또 하나의 로그인 방식이 아닙니다. 개인 키 자료를 JavaScript에 넘겨주지 않으면서 하드웨어에 귀속된 키가 필요한 지갑, 권한 부여 토큰, 소프트웨어 릴리스 서명 등의 응용을 지원할 수 있습니다.

하지만 현재 진행 중인 기관적 행위는 더 좁습니다. W3C는 8월 10일 제안된 차터에 대한 검토를 요청했습니다. 의견은 9월 7일 23:59 UTC까지 계속 열려 있으며, 기존 차터는 10월 30일로 연장되었습니다. 이 기준 시점에는 승인된 대체 차터가 없습니다. 승인되더라도 워킹 그룹이 이 부류의 기능을 개발할 수 있는지에 대한 질문에만 답합니다. 현재 API를 선택하거나, 그 위험을 확정하거나, 브라우저에 구현을 요구하지는 않습니다.

이 구별은 차터 자체가 그것을 보존하기 때문에 중요합니다. 웹 인증 Level 4는 제안된 규범적 산출물입니다. 해당 페이지는 첫 공개 작업 초안이 아직 공개되지 않았다고 밝히고 2028년 4분기를 예상 완료 시점으로 제시합니다. 위임에서 배포된 코드로 가는 길은 설계상 여전히 깁니다.

“임의”는 기능의 능력을 말할 뿐, 사용자의 의도를 말하지 않는다

일반적인 WebAuthn 어서션은 신뢰 당사자(relying party)의 챌린지를 맨 입력으로 서명하지 않습니다. 인증자는 인증자 데이터와 클라이언트 데이터의 해시를 담은 정의된 구조를 서명합니다. 원시 서명 제안은 의도적으로 다릅니다. 그 출력은 애플리케이션이 제공한 입력에 대한, 변경되지 않은 서명입니다.

이 일반성이 가치를 만듭니다. 기존 검증기가 모두 WebAuthn 어서션 봉투를 이해하지는 않습니다. 지정된 메시지에 대한 기존 방식의 서명은 이미 서명을 검증하는 프로토콜에 맞을 수 있습니다. 하드웨어 기반 키는 JavaScript 밖에 머물면서 웹 애플리케이션이 그 프로토콜에 참여할 수 있습니다.

제안은 또한 WebAuthn의 가장 강한 경계를 그 간극을 넘어 옮기려 합니다. 서명 키는 부모 자격 증명 키와 구별되고 암호학적으로 무관해야 하므로, 악의적인 신뢰 당사자가 새 기능에 유효한 인증 어서션을 만들어내도록 요구할 수 없습니다. 오리진 바인딩은 서명 키가 사이트 간 추적 수단이 되는 것을 막기 위한 것입니다. 사용자 존재(user-presence) 및 사용자 검증(user-verification) 요구 사항은 서명 키 생성 시 고정됩니다. 웹 대면 계층은 무인 서명을 노출해서는 안 되며, 하위 클라이언트-인증자 계층은 이를 사용하는 네이티브 애플리케이션을 위할 수 있습니다.

이들은 의미 있는 설계 약속입니다. 그러나 이것은 한 사람이 무엇을 승인했는지를 증명하는 것과 같지 않습니다.

설명 문서는 거래 확인(transaction confirmation)을 비목표로 명시합니다. 자료가 불투명한 이진 데이터일 수 있다고 가정하며, 서명 전에 이를 이해할 수 있게 보여주는 신뢰된 인터페이스를 요구하지 않습니다. 따라서 성공한 절차는 특정 키가 지정된 존재 또는 검증 정책 하에 작동했음을 증명할 수 있습니다. 그것만으로 사용자가 문서를 읽었거나, 에이전트의 제안 행동을 승인했거나, 결제를 이해했거나, 서명에 나중에 부착된 법적 의미에 동의했음을 증명하지는 않습니다.

이것은 기록에서 몰래 꺼낸 결함이 아니라 선언된 경계입니다. 이후 제품 주장이 그것을 지우면 거버넌스가 실패합니다. “사용자가 검증됨”은 절차의 속성입니다. “사용자가 이 페이로드를 이해했다”는 다른 명제입니다. “자율 에이전트가 이 페이로드를 선택하도록 승인되었다”는 또 다른 명제입니다.

제안은 아직 증명해야 할 증거가 남아 있다

공개 설명 문서는 사용자 연구가 수행되지 않았다고 밝힙니다. 이해관계자 표는 Chrome, Firefox, Safari, Edge로부터의 신호가 없음을 기록합니다. 인증자 구현자 한 곳과 신뢰 당사자 구현자 한 곳이 긍정적으로 등록되어 있습니다. 신호 없음은 거부가 아니라 미해결 상태입니다.

연결된sign확장은 Level 4 첫 공개 작업 초안 마일스톤에 할당된 초안 풀 리퀘스트로 남아 있습니다. 그 이력은 활발합니다. 2024년 9월, 작성자는 대략적인 내부 개념 증명 구성 요소와 당시 다른 워킹 그룹 참여자로부터의 약속이 없음을 보고했습니다. 이후 토론과 참조된 실험은 더 많은 작업이 존재함을 보여줍니다. 그러나 그것들이 검토된 기록을 두 개의 독립적인 상호운용 가능 구현을 보여주는 공개 구현 보고서로 바꾸지는 않습니다.

W3C의 프로세스가 빠진 순서를 제공합니다. 주요 범위 변경은 자문 위원회(Advisory Committee) 검토와 W3C 결정(W3C Decision)이 필요합니다. 첫 공개 작업 초안은 공개 표준 트랙 작업을 시작하며 특허상의 결과를 갖습니다. 수평 검토는 접근성, 국제화, 개인정보 및 보안을 검토해야 합니다. 후보 권고안(Candidate Recommendation)은 최종 검토와 구현 경험의 단계입니다. 권고안은 추가 증거와 W3C 결정을 요구합니다. 배포는 이후 구현자와 신뢰 당사자에 달려 있습니다.

이 상태들 중 어느 것도 의례적인 잉여가 아닙니다. 각각 다른 질문에 답합니다:

Lu Heng의 실행 코드(runner code) 우선 원칙 논증은 이 정확한 경계에서 유용합니다. 공개물은 미래 작업을 조직할 수 있지만, 이후 변경을 운영적으로 실재하게 만들지는 않습니다. 적용은 제한적입니다. W3C는 RIR이 아니고 웹 표준은 번호 자원 레지스트리가 아닙니다. 이전 가능한 규율은 단순히 문서 상태, 구현 증거, 채택이 서로를 사칭해서는 안 된다는 것입니다.

하나의 기능에는 하나의 채택 접수증이 필요하다

제안된 차터에는 이미 일반적 성공 기준이 들어 있습니다. 원시 서명은 그 약속이 서로 벗어날 수 있는 주장의 사슬에 의존하기 때문에 기능 수준의 기록이 필요합니다.

접수증은 차터 조항과 그 상태; 정확한 설명 문서와 명세 리비전; 연산이 전체 입력, 사전 해시 또는 다른 봉투를 서명하는지; 알고리즘과 도메인 분리 관례; 부모 키와 서명 키의 관계; 오리진 경계; 고정된 사용자 존재 및 사용자 검증 정책; 사용자에게 표시되는 것과 그렇지 않은 것; 어테스테이션이 증명하는 것; 연결 가능성 및 핑거프린팅 분석; 브라우저, 인증자 및 신뢰 당사자 신호; 수평 검토 이슈와 처분; 공개 테스트 범위; 독립 구현 증거; 미해결 이의; 그리고 현재 W3C 성숙도 상태를 식별해야 합니다.

여기에는 개인 키, 기기 식별자, 개인 테스트 데이터 또는 악용 가능한 구현 세부사항이 들어가서는 안 됩니다. 또한 이미 W3C 프로세스가 지배하는 작업을 거부할 수 있는 추가 위원회가 되어서도 안 됩니다. 그것은 이미 존재해야 하는 기록에 대한 통합 공개 색인입니다.

그 가치는 교정입니다. 차터가 바뀌면 첫 행이 바뀝니다. 거래 확인이 목표가 되면 사용자 통제 행이 바뀝니다. 브라우저가 “부정적”이라고 말하면 구현자 상태가 바뀌며 “신호 없음”을 과거의 반대로 다시 쓰지 않습니다. 테스트가 프로토콜 혼란을 드러내면 결과와 처분이 계속 붙어 있습니다. 기능이 삭제되면 시기에 맞지 않게 인용되는 차터 문장으로 남는 대신 읽을 수 있는 종단 상태로 끝납니다.

출처

1. W3C 제안된 웹 인증 차터 검토 요청
2. 제안된 웹 인증 워킹 그룹 차터
3. 현재 웹 인증 워킹 그룹 차터
4. 웹 인증 Level 3 권고안
5. 원시 서명 확장 설명 문서
6. 초안sign확장 풀 리퀘스트 #2078
7. W3C 프로세스 문서, 2025년 8월 18일
8. Lu Heng, Running-Code Primacy
9. Lu Heng, Minimum Initial Specification, Localized Future Decision and Voluntary Adoption