HTTP Message Signatures란 무엇인가
HTTP Message Signatures는 RFC 9421에 정의되어 있으며, HTTP 요청이나 응답의 일부에 대한 디지털 서명을 생성하고 검증하기 위한 IETF 표준입니다. 클라이언트는 적용할 구성 요소를 선택한 뒤(예: method, target URI, authority, 선택된 headers), 그로부터 정규화된 signature base를 만들고 private key로 서명합니다. 결과는 두 개의 header로 전달됩니다. Signature-Input(Section 4.1)은 적용된 구성 요소와 created, expires, keyid, alg 같은 parameter를 나열하고, Signature(Section 4.2)는 signature value 자체를 담습니다. 둘 다 RFC 9651의 Structured Field Values 문법을 사용합니다.
수신자는 실제로 받은 요청으로부터 동일한 signature base(Section 2.5)를 다시 구성하고, keyid가 가리키는 public key를 조회한 뒤 signature를 확인합니다. signature에 포함된 내용이 전송 중에 하나라도 바뀌면 검증은 실패합니다.
앱, API, MCP server에 중요한 이유
대부분의 자동화 트래픽은 user-agent string이나 사용자가 정한 client name으로 자신을 식별합니다. 둘 다 쉽게 복제할 수 있습니다. Message signature는 다릅니다. 요청을 특정 key에 연결하고, 유효한 signature는 private key 보유자만 만들 수 있습니다. crawler, assistant, autonomous agent에서 트래픽을 받는 application의 경우, 이것은 "이 client는 자신이 X라고 말한다"를 "이 request는 X가 공개한 key로 서명되었다"로 바꿉니다.
이 구분은 협력하는 자동화 client를 익명 트래픽이 아닌 알려진 참여자로 다루는 기반이 됩니다. API는 서명된 crawler를 구조화된 endpoint로 라우팅하거나, 알려진 operator에 더 낮거나 다른 rate limit를 적용하거나, MCP server가 tool 호출 주체에 대해 더 많은 context를 갖도록 할 수 있습니다.
검증이 실제로 작동하는 방식
Signature-Input와Signature를 파싱하고 예상한 구성 요소가 포함되어 있는지 확인합니다. 유용한 내용을 거의 포함하지 않는 signature는 증명하는 바가 적습니다.created와expiresparameter를 확인해 허용 범위 안에서 오래된 요청이나 재전송된 요청을 거부합니다( signature replay에 대한 Section 7.2.2 참조).- operator가 알려진 위치에 게시한 key directory와 같이 신뢰할 수 있는 출처에서
keyid을 public key로 해석합니다. IETF Web Bot Auth protocol draft는 자동화 client를 위한 이런 directory를 정의합니다. - 명시된 대로 signature base를 정확히 다시 만들고 선언된 algorithm으로 검증합니다.
- 무엇이 검증되었는지와 어떤 context에서 검증되었는지 기록해 두어, 이후의 결정이 이를 참조할 수 있게 합니다.
운영 환경에서는 손으로 작성한 parsing 대신 유지보수되는 RFC 9421 구현을 사용하세요. canonicalization 세부 사항은 쉽게 잘못 처리될 수 있습니다. signed AI agent requests를 검증하는 방법 가이드는 각 단계를 code와 함께 설명합니다.
유효한 signature가 입증하는 것과 입증하지 못하는 것
유효한 signature는 request가 key로 서명되었다는 점을 입증하며, 해당 key가 domain 아래에 게시되어 있다면 그 request가 그 domain operator와 연관된다는 점도 입증합니다. 하지만 다음은 입증하지 않습니다.
- operator가 정직하거나 action이 안전하다는 것,
- 사람이 해당 request를 지시하거나 승인했다는 것(delegated authority 참조),
- client가 요청하는 행위를 할 수 있도록 허용되었다는 것(agent authorization 참조).
Identity evidence와 permission은 별개의 질문입니다. 애플리케이션의 자체 authentication과 authorization이 여전히 client가 무엇을 할 수 있는지 결정합니다. signed AI agent requests가 무엇을 입증하고 무엇을 입증하지 않는지에 대한 블로그 글에서 이를 더 자세히 설명합니다.
흔한 오해
- "서명되었다는 것은 신뢰된다는 뜻이다." 서명되었다는 것은 귀속 가능하다는 뜻입니다. 신뢰는 귀속된 대상에 대해 사용자가 내리는 policy 결정입니다.
- "signature가 API key를 대체한다." 둘은 서로 다른 질문에 답합니다. API key는 어떤 account가 호출하는지 말해 주고, signature는 어떤 client가 request를 생성했는지 말해 줍니다. 많은 배포 환경에서는 둘 다 유용합니다.
- "서명되지 않은 트래픽은 악성이다." 오늘날 대부분의 자동화 트래픽은 서명되지 않습니다. signature가 없으면 확인할 수 있는 범위가 줄어들 뿐입니다. 그래서 Unknown이 1급 결과입니다.
Proof of Actor가 signature를 다루는 방식
Proof of Actor에서는 게시된 key에 대해 검증되는 signature를 basis verified로 기록하며, 확인 결과가 실제로 입증한 범위에만 한정합니다. 즉, key와 그 key가 속한 identifier입니다. 그 결과로 나오는 class(대개 Agent)는 authorization을 의미하지 않습니다. 결과는 분석을 위한 Understand로 흘러가고, Route에서는 자체 policy가 서명된 client에 구조화된 경로를 부여할지, 다른 limit를 적용할지, 아니면 아무 변경도 하지 않을지를 결정합니다. Web Bot Auth와 같은 signed-agent 표준은 계속 발전하고 있으며, Proof of Actor는 이러한 표준이 성숙해 가는 동안 signed request를 검증하도록 설계되었습니다.
evidence가 무엇을 입증할 수 있는지 더 읽어보거나, early access를 신청하세요.
출처
- RFC 9421: HTTP Message Signatures: signature 구성 요소, parameter 및 검증을 정의하는 IETF standard
- RFC 9651: Structured Field Values for HTTP:
Signature-Input와Signature의 문법 - draft-ietf-webbotauth-httpsig-protocol: 자동화 client에 RFC 9421을 적용하는 IETF Web Bot Auth draft(2026년 11월 기준 작업 중)