검증자

검증자는 무언가가 맞는지 확인하는 자리에 붙는 이름입니다. 무엇이 그 자리에 서는지는 쓰는 곳마다 다릅니다. 한쪽에서는 값 하나가 검증자입니다. 다른 쪽에서는 확인을 수행하는 개체가 검증자입니다.

상세

이 말이 가리키는 것은 맥락마다 갈립니다. 갈리는 자리가 품사입니다. 한쪽은 무엇이고 다른 쪽은 누구입니다.

HTTP(HyperText Transfer Protocol) 에서 검증자는 값입니다. RFC 9110(Request for Comments, 의견 요청) 은 자원 메타데이터를 전제조건 안에 넣어 조건부 요청을 만드는 데 쓸 수 있으면 그것을 검증자라고 부른다고 적습니다. 검증자 필드는 선택된 표현의 현재 검증자를 실어 나릅니다. 이 명세가 정하는 형태는 둘입니다. 수정 날짜와 불투명한 엔티티 태그입니다.

디지털 신원에서 검증자는 개체입니다. NIST(National Institute of Standards and Technology) 의 SP 800-63-3(Special Publication, 특별 간행물) 은 검증자를 인증 프로토콜로 청구자가 인증수단을 소유하고 통제하는지 검증해서 청구자의 신원을 검증하는 개체라고 적습니다. 값이 아니라 그 값을 다루는 쪽입니다.

원어도 다릅니다. RFC 9110 이 쓰는 말은 validator 입니다. NIST 문서가 쓰는 말은 verifier 입니다. 한국어에서는 둘 다 검증자로 옮깁니다.

어느 쪽이 먼저 쓰인 뜻인지는 두 문서가 적지 않습니다. 그래서 검증자라는 말만으로는 값을 가리키는지 개체를 가리키는지가 정해지지 않습니다. 맥락 이름을 먼저 대야 뜻이 섭니다.

맥락별 뜻

맥락	뜻	출처
HTTP	전제조건에 넣어 조건부 요청을 만드는 데 쓸 수 있는 자원 메타데이터. 선택된 표현의 현재 상태를 가리키는 값	RFC 9110 8.8 · 8.8.1 · 8.8.2 · 8.8.3 · RFC 9111 4.3
디지털 신원	인증 프로토콜로 청구자가 인증수단을 소유하고 통제하는지 검증해서 청구자의 신원을 검증하는 개체	NIST SP 800-63-3 부록 A · NIST SP 800-63-4 디지털 신원 모델

HTTP

RFC 9110 은 검증자를 자원 메타데이터의 한 성질로 정의합니다. 그 메타데이터를 전제조건 안에서 조건부 요청을 만드는 데 쓸 수 있으면 검증자라고 부릅니다. 검증자 필드는 선택된 표현의 현재 검증자를 전달합니다.

sequenceDiagram
    participant 클라이언트
    participant 오리진서버
    오리진서버-->>클라이언트: 응답에 검증자 필드를 실어 보냄
    Note over 오리진서버: 값은 선택된 표현의 현재 상태를 가리킨다
    클라이언트->>오리진서버: 나중 요청의 전제조건에 그 값을 넣음

안전한 요청에 대한 응답에서 검증자 필드는 오리진 서버가 응답을 처리하며 고른 선택된 표현을 기술합니다. 메서드와 상태 코드의 의미에 따라, 어떤 응답의 선택된 표현이 응답 본문에 실린 표현과 반드시 같지는 않습니다. 상태를 바꾸는 요청에 대한 성공 응답에서는 요청 처리 결과로 이전 선택된 표현을 대체한 새 표현을 기술합니다. 명세가 든 예가 201 Created 응답의 ETag 필드입니다. 새로 만들어진 자원 표현의 엔티티 태그를 전달합니다. 그 엔티티 태그를 나중 조건부 요청에서 검증자로 써서 lost update 문제를 막을 수 있습니다.

Last-Modified 는 수정 날짜 쪽 형태입니다. 응답의 Last-Modified 헤더 필드는 오리진 서버가 선택된 표현이 마지막으로 수정됐다고 믿는 날짜와 시각을 제공합니다. 그 시점은 요청 처리를 마친 시점을 기준으로 정해집니다. RFC 9110 은 마지막 수정 날짜를 합리적이고 일관되게 정할 수 있는 선택된 표현이라면 오리진 서버가 Last-Modified 를 보내야 한다고 SHOULD 로 적습니다. 조건부 요청과 캐시 신선도 평가에 쓰이면 불필요한 전송을 상당히 줄이고 서비스 가용성과 확장성을 크게 개선할 수 있다는 것이 이유라고 적습니다.

ETag 는 엔티티 태그 쪽 형태입니다. 응답의 ETag 필드는 선택된 표현의 현재 엔티티 태그를 제공합니다. 엔티티 태그는 같은 자원의 여러 표현을 구별하는 불투명한 검증자입니다. 표현이 여럿인 이유가 시간에 따른 자원 상태 변화든 콘텐츠 협상이든 둘 다든 상관하지 않습니다. 값은 불투명한 따옴표 문자열입니다. 앞에 약함 표시가 붙기도 합니다. 수정 날짜를 저장하기 불편한 상황에서는 엔티티 태그가 수정 날짜보다 검증에 더 믿을 만할 수 있습니다. HTTP 날짜 값의 1초 해상도가 모자란 상황도 그렇습니다. 수정 날짜가 일관되게 유지되지 않는 상황도 그렇습니다.

캐시도 이 값을 씁니다. RFC 9111 은 캐시가 요청 URI 에 대한 저장 응답을 하나 이상 갖고 있으면서 그중 아무것도 제공할 수 없을 때를 적습니다. 그때 캐시는 전달하는 요청에 조건부 요청 메커니즘을 쓸 수 있습니다. 다음 인바운드 서버가 쓸 만한 저장 응답을 고르게 하려는 것입니다. 저장 응답을 새 응답으로 교체하게 하려는 것이기도 합니다. 이 과정을 저장 응답의 검증 또는 재검증이라고 부릅니다.

디지털 신원

NIST SP 800-63-3 부록 A 는 검증자를 개체로 정의합니다. 인증 프로토콜을 써서 청구자가 인증수단 하나 또는 둘을 소유하고 통제하는지 검증함으로써 청구자의 신원을 검증하는 개체입니다. 그러기 위해 검증자는 인증수단을 가입자 식별자에 잇는 자격증명을 검증하고 그 상태를 확인해야 할 수도 있습니다.

개정 4판의 디지털 신원 모델도 같은 자리를 적습니다. 검증자는 청구자가 인증수단 하나 이상을 소유하고 통제하는지 검증해서 청구자의 신원을 확인합니다. 그러려면 인증수단이 가입자 계정에 묶여 있는지 확인해야 합니다. 그 가입자 계정이 활성 상태인지도 확인해야 합니다. 인증수단 개수를 3판은 하나 또는 둘로 적고 4판은 하나 이상으로 적습니다.

flowchart TD
    C["청구자"] -->|인증 프로토콜| V["검증자"]
    V -->|신원 단언| R["신뢰 당사자"]
    CSP["자격증명 서비스 제공자"] -->|인증수단·자격증명 발급| S["가입자"]
    S -.->|같은 사람이 청구자로 선다| C

모델 안에서 검증자는 혼자 서지 않습니다. 서비스 제공자는 자격증명 서비스 제공자, 신뢰 당사자, 검증자, 신원 제공자 기능을 어떻게든 조합해 수행할 수 있습니다. 신뢰 당사자는 온라인 거래와 서비스를 제공하면서 검증자가 내놓은 가입자 신원 단언에 의존해 접근을 허용합니다. 연합을 쓰면 신뢰 당사자는 신원 제공자의 단언을 통해 가입자 계정의 정보에 접근합니다.

경계

약한 검증자

약한 검증자도 검증자인가. 맞습니다. RFC 9110 은 검증자가 강함과 약함 두 갈래로 온다고 적습니다. 약한 검증자는 만들기는 쉬운 대신 비교에는 쓸모가 훨씬 덜하다고 적습니다. 강한 검증자는 비교에는 이상적인 대신 효율적으로 만들어 내기가 매우 어려울 수 있고 때로는 불가능하다고 적습니다. 명세는 모든 형태의 자원이 같은 강도의 검증자를 따르도록 강제하지 않습니다. 대신 쓰이는 검증자의 종류를 드러냅니다. 그리고 약한 검증자를 전제조건으로 쓸 수 있는 자리에 제한을 겁니다. 두 갈래 다 명세 안에서 검증자로 불립니다.

강한 검증자는 GET 에 대한 200 OK 응답 본문에서 관찰될 만한 표현 데이터의 변화가 일어날 때마다 값이 바뀌는 표현 메타데이터입니다. 강한 검증자는 한 자원에 딸린 모든 표현의 모든 판을 통틀어 시간에 걸쳐 유일합니다. 다만 자원이 다르면 유일성이 함의되지 않습니다. 같은 강한 검증자가 여러 자원의 표현에 같은 시각에 쓰이고 있을 수도 있습니다. 그렇다고 그 표현들이 동등하다는 뜻은 아닙니다.

약한 검증자는 표현 데이터가 바뀌어도 값이 안 바뀔 수 있는 표현 메타데이터입니다. 값을 계산하는 방식의 한계가 이유일 수 있습니다. 시계 해상도가 그런 예입니다. 자원의 가능한 모든 표현에 대해 유일성을 보장하지 못하는 것도 이유일 수 있습니다. 자원 소유자가 데이터의 유일한 연쇄가 아니라 스스로 정한 동등성 기준으로 표현을 묶고 싶어 하는 것도 이유일 수 있습니다. 한 자원의 표현 둘 이상이 같은 시각에 한 검증자를 나눠 쓰면 그 검증자도 약합니다. 그 표현들의 표현 데이터가 동일한 경우는 예외입니다.

엔티티 태그는 둘 중 어느 쪽도 될 수 있습니다. 기본은 강함입니다. 오리진 서버가 어떤 표현에 엔티티 태그를 주면서 그 생성 방식이 강한 검증자의 성질을 다 만족하지 않으면, 오리진 서버는 불투명 값 앞에 대소문자를 구분하는 W/ 를 붙여 그 엔티티 태그를 약하다고 표시해야 합니다. 명세는 이것을 MUST 로 적습니다.

검증자가 아닌 것

검증은 검증자가 아닙니다. RFC 9111 은 캐시가 저장 응답을 두고 다음 인바운드 서버에 선택 기회를 넘기는 그 과정을 검증 또는 재검증이라고 부릅니다. 절차의 이름입니다. 검증자는 그 절차가 실어 보내는 값입니다.

청구자는 검증자가 아닙니다. NIST SP 800-63-3 은 청구자를 하나 이상의 인증 프로토콜로 신원이 검증될 대상이라고 적습니다. 검증하는 쪽이 아니라 검증받는 쪽입니다.

가입자와 인증수단도 검증자가 아닙니다. 인증수단은 검증자가 소유와 통제를 확인하는 대상입니다. 가입자는 그 인증수단을 받아 쥔 쪽입니다.

자격증명 서비스 제공자와 신뢰 당사자도 검증자가 아닙니다. 자격증명 서비스 제공자는 검증자가 확인할 자격증명을 발급하는 쪽입니다. 신뢰 당사자는 검증자가 내놓은 단언을 받아 쓰는 쪽입니다.

역할이 갈린다는 것이 개체가 갈린다는 뜻은 아닙니다. NIST SP 800-63-4 는 자격증명 서비스 제공자와 검증자와 신원 제공자가 별개 역할로 제시되기는 하지만 그 기능들이 한 개체에서 수행될 수도 있다고 적습니다. 여러 개체에 나뉠 수도 있다고 적습니다. 구현에 달렸다는 것입니다. 3판이 검증자를 개체로 정의하는 자리에서, 4판 모델은 검증자를 서비스 제공자가 수행하는 기능 가운데 하나로도 적습니다.

상세

맥락별 뜻

HTTP

디지털 신원

경계

약한 검증자

검증자가 아닌 것

관련 항목

검증자의 하위 종류와 요구사항 표현

검증자를 전제조건으로 쓰는 조건부 요청 헤더

검증자가 성립시키는 조건부 요청 처리

검증자를 캐시가 활용하는 절차

검증자가 속하는 표현 메타데이터의 갈래

검증자를 정의하는 표준·문서

검증자가 신원을 확인하는 대상

검증자와 역할을 나누는 신원 모델 참여자

검증자가 신원을 확인하는 데 쓰는 개념