신분증 확인 API: 통합 및 평가 가이드 (KO)

신분증 확인 API를 통해 애플리케이션은 신원 증거를 수집 또는 제출하고, 본인이라고 주장하는 사람에 대한 구조화된 결과를 받을 수 있습니다. 워크플로에 따라 신분증을 검증하고, 속성을 추출하고, 실시간 신청자와 참조 인물 사진을 비교하고, 라이브니스(Liveness)를 확인하고, 데이터를 상호 참조하거나, 여러 검사를 하나의 세션으로 통합할 수 있습니다.

API 응답은 증거일 뿐, 완전한 비즈니스 의사 결정은 아닙니다. 프로덕션 통합은 신뢰할 수 있는 캡처, 고객 상태 소유권, 상태 전환, 재시도, 검토, 개인 정보 보호, 기록 보관, 그리고 기술적 결과를 승인, 재시도, 단계적 상향, 검토 또는 거부로 전환하는 정책을 정의해야 합니다.

핵심 요약

• 신분증 확인 API는 하나의 엔드포인트 이상입니다. 실제 계약에는 캡처, 비동기 상태, 증거, 이벤트, 조정, 검토 및 삭제가 포함됩니다.
• 백엔드가 결정을 소유합니다. 클라이언트 리디렉션 또는 시각적 성공 화면은 권위 있는 것이 아닙니다. 최종 상태는 서버 측에서 확인되어야 합니다.
• 결과에는 범위와 이유가 필요합니다. 문서의 진위 여부, 소유자 연결, 라이브니스, 품질 및 상황적 위험은 설명되지 않은 부울로 축소되기보다는 분리되어야 합니다.
• 신뢰성은 실패 경로에서 나타납니다. 멱등성, 웹훅 검증, 이벤트 재생, 시간 초과, 재시도, 버전 관리 및 샌드박스 패리티는 해피 경로만큼 중요합니다.
• 평가는 프로덕션과 유사한 모집단을 사용해야 합니다. 적용 범위, 사기 방지, 완료율, 오탐, 검토 부하 및 개인 정보 보호는 문서, 장치, 지리 및 관련 사용자 세그먼트별로 측정되어야 합니다.

신분증 확인 API는 무엇을 하는가?

신분증 확인 API는 신원 증명 기능에 대한 기계 판독 가능한 인터페이스를 제공합니다. 일반적인 통합은 확인 시도를 생성하고, 신청자를 안전한 캡처 경험으로 안내하고, 진행 상황 또는 완료 이벤트를 수신하고, 최종 증거를 검색하고, 의존하는 조직의 정책을 적용합니다.

NIST SP 800-63A-4 신원 증명 모델은 세 가지 중요한 기능을 구분합니다.

• 해결: 관련 모집단 내에서 주장된 사람을 구별합니다.
• 유효성 검사: 신원 증거 및 속성이 진위인지, 정확한지, 허용 가능한지 여부를 결정합니다.
• 확인: 신청자가 해당 증거와 관련된 대상임을 확립합니다.

API는 이 중 하나, 둘 또는 세 가지 모두를 수행할 수 있습니다. 제품 이름이 범위를 보장하지 않으므로, 요구 사항은 모든 결과에서 예상되는 정확한 결론을 명시해야 합니다.

신분증 확인 API, 문서 API, KYC API 및 OCR 비교

인터페이스	주요 목적	유용한 출력	그 자체로 증명하지 않는 것
OCR API	문서 픽셀을 텍스트 또는 필드로 변환	추출된 이름, 날짜, 번호, 주소	진위 여부, 소유권 또는 고객 위험
문서 확인 API	문서 및 캡처된 증거 유효성 검사	진위 확인, 만료, 필드 일관성, 변조 지표	현재 신청자가 소유하고 있는지 여부
얼굴 매칭 API	제출된 얼굴과 참조 얼굴 비교	임계값에서의 유사성 또는 일치 결정	라이브니스, 문서 진위 여부 또는 법적 신원
라이브니스 API	생체 인식 캡처 시 실제 존재 여부 추정	악의적 의도 없음, 공격, 재시도 또는 점수 증거	개인의 신원
신분증 확인 API	증거 유효성 검사 및 신청자 연결 결합	증거 수준 결과 및 워크플로 결과	완전한 KYC 또는 비즈니스 적격성
KYC API	더 넓은 고객 실사 흐름 지원	신원, 심사, 위험, 워크플로 및 기록	조직 정책 없는 자동 규정 준수

이러한 구분은 아키텍처적 실수를 방지합니다. 예를 들어, 업로드 양식에 OCR을 추가하면 데이터 입력 속도는 빨라지지만 문서의 진위를 확인할 수는 없습니다. 얼굴 매칭을 추가하면 두 이미지가 연결되지만, 두 이미지 중 어느 것이 신뢰할 수 있는 실시간 캡처를 통해 얻어졌는지 확인할 수는 없습니다.

이러한 인터페이스를 둘러싼 광범위한 정책, 심사, 위험 및 지속적인 검토 컨텍스트에 대해서는 KYC 수명 주기 가이드를 참조하십시오. 이 문서는 개발자 신뢰 경계(캡처, API 상태, 증거, 이벤트, 조정 및 백엔드 결정)에 중점을 둡니다.

일반적인 통합 모델

호스팅된 확인 세션

애플리케이션의 백엔드는 세션을 생성하고 단기 URL 또는 토큰을 수신합니다. 사용자는 공급업체에서 호스팅하는 여정에서 캡처를 완료한 다음 애플리케이션으로 돌아옵니다. 이 모델은 프런트엔드 및 장치 복잡성을 줄이면서 서버 측 제어를 유지할 수 있습니다.

주요 질문에는 브랜딩, 도메인 핸드오프, 접근성, 현지화, 모바일 브라우저 지원, 세션 만료, 반환 동작, 사용자가 장치를 전환할 때 애플리케이션이 어떻게 재개되는지가 포함됩니다.

임베디드 웹 또는 모바일 SDK

SDK는 애플리케이션 내에서 캡처 경험을 실행합니다. 더 엄격한 인터페이스 제어 및 장치 기능에 대한 액세스를 제공할 수 있지만, 통합 품질이 보안에 영향을 미칩니다. 버전 지원, 애플리케이션 무결성, 카메라 권한, 가상 카메라 처리, 업데이트 정책 및 원격 측정은 검토의 일부가 됩니다.

독립형 서버 간 확인

고객 시스템은 구조화된 데이터 또는 미디어를 엔드포인트로 직접 보냅니다. 이는 이미 신뢰할 수 있는 캡처, 배치 작업 또는 개별 모듈에 유용합니다. 또한 캡처 무결성, 동의, 품질, 페이로드 보안 및 재생 방지에 대한 책임이 통합자에게로 넘어갑니다.

오케스트레이션된 워크플로

하나의 세션은 문서 유효성 검사, 데이터베이스 확인, 라이브니스, 얼굴 매칭, 심사, 장치 신호 및 수동 검토에 걸쳐 분기될 수 있습니다. API는 워크플로 및 정책 버전을 노출하여 동일한 상태를 나중에 해석할 수 있도록 해야 합니다.

안전한 통합 시퀀스

1. 백엔드에서 시도 생성

신뢰할 수 있는 백엔드는 내부 고객 참조를 생성하고 필요한 워크플로, 로케일 및 정책 컨텍스트와 함께 공급업체를 호출합니다. 브라우저 또는 모바일 코드에 영구 API 자격 증명을 노출하지 마십시오.

생성 작업에 멱등성 전략을 사용하십시오. 클라이언트 시간 초과는 두 번째 청구 가능한 시도를 생성하거나 결과를 원래 고객으로부터 분리해서는 안 됩니다.

2. 단기 캡처 핸드오프 발행

프런트엔드에는 해당 시도에 필요한 범위 지정된 토큰 또는 URL만 제공하십시오. 예상 애플리케이션, 고객 참조, 워크플로 및 만료에 바인딩하십시오. URL, 분석 이벤트 또는 클라이언트 로그에 불필요한 개인 데이터를 넣지 마십시오.

3. 증거 캡처 및 유효성 검사

사용자를 지원되는 증거 및 품질 요구 사항으로 안내하십시오. 복구 가능한 품질 문제와 의심스러운 공격을 분리하십시오. “더 가까이 이동”, “문서 만료”, “캡처 무결성 실패”가 하나의 일반적인 오류가 되어서는 안 됩니다.

4. 인증된 이벤트 수신

웹훅은 확인될 때까지 신뢰할 수 없는 입력으로 간주하십시오. 이벤트 서명 또는 메시지 인증, 타임스탬프 또는 신선도 제어, 예상 대상, 콘텐츠 유형 및 이벤트 식별자를 검증하십시오. RFC 9421은 HTTP 메시지 서명에 대한 일반적인 메커니즘을 정의하지만, 공급업체는 다른 문서화된 서명 체계를 사용할 수 있습니다.

이벤트 식별자를 저장하고 멱등적으로 처리하십시오. 전송 시스템은 재시도합니다. 중복 이벤트는 정상입니다. 도착 순서를 가정하지 말고, 이전 이벤트가 고객을 최종 상태에서 뒤로 이동시키지 않도록 하십시오.

5. 정식 결과 검색

완료 이벤트 후, 공급업체 API에서 최종 시도를 가져오십시오. 이 조정 단계는 단일 웹훅 내용에 대한 의존도를 줄이고 누락되거나 지연된 전달로부터 복구합니다.

6. 조직 정책 적용

구조화된 증거를 조직의 자체 결정 상태로 매핑하십시오. 공급업체가 결과를 권장할 수 있지만, 의존하는 조직은 제품, 고객 이력, 법적 근거, 위험 허용 범위 및 사용 가능한 복구 경로를 알고 있습니다.

7. 전환 기록

내부 고객 참조, 공급업체 시도 식별자, 워크플로 및 버전, 관련 증거 또는 참조, 이유 코드, 이벤트 이력, 정책 버전, 검토자 작업 및 최종 근거를 유지하십시오. 내구성 있는 참조로 충분할 때 복사되는 민감한 데이터를 최소화하십시오.

API가 노출해야 하는 상태 모델

부울 verified 필드는 실제 고객 여정에는 너무 작습니다. 유용한 상태에는 종종 다음이 포함됩니다.

상태	의미	일반적인 애플리케이션 작업
생성됨	시도는 존재하지만 캡처가 시작되지 않음	보안 핸드오프 제시 또는 재전송
진행 중	사용자 또는 비동기 검사가 활성 상태임	기다림; 최종 액세스 허용 안 함
입력 대기 중	더 많은 증거 또는 사용자 작업이 필요함	정확한 복구 지침 표시
재시도 허용됨	캡처 또는 품질이 복구 가능하게 실패함	제한된 새 시도 시작
검토 중	숙련된 검토자가 사례를 소유함	액세스 보류 및 예상되는 다음 단계 노출
승인됨	필요한 증거가 구성된 워크플로를 충족함	조직 정책 및 상태 전환 적용
거부됨	증거가 정의된 제어를 실패함	이의 제기, 제한 또는 대체 경로 적용
만료됨 또는 중단됨	결정 없이 시도가 종료됨	제어된 재시작 허용
기술적 오류	시스템이 증거를 생성할 수 없음	사기로 간주하지 않고 재시도 또는 조정

모든 최종 상태에는 구조화된 이유가 있어야 합니다. 안정적인 기계 코드는 정책 및 분석을 허용하고, 현지화된 인간 메시지는 사용자 및 검토자에게 도움이 됩니다. RFC 9457은 인터페이스 수준에서 기계 판독 가능한 HTTP 문제 세부 정보에 대한 표준 형식을 제공합니다.

결과는 어떤 증거를 포함해야 하는가?

문서 수준 증거

방법과 관련된 증거 유형, 발행 국가, 문서 클래스, 만료, 필드 일관성, 품질 및 유효성 검사 지표를 포함하십시오. 결과가 광학 검사, 칩 데이터, 발행 기관 또는 데이터베이스 상호 참조 또는 다른 소스에서 나온 것인지 명확히 하십시오.

신청자 연결 증거

얼굴 비교, 라이브니스, 캡처 무결성 및 신원 속성 연결을 분리하십시오. 나중에 해석하는 데 필요한 참조 및 결정 임계값 또는 버전을 기록하되, 불필요한 생체 인식 자료를 모든 소비자에게 노출하지 마십시오.

위험 및 운영 증거

장치, IP, 속도, 반복 시도 또는 워크플로 신호는 단계적 상향 및 검토를 안내할 수 있습니다. 이러한 신호는 신원 속성을 조용히 변경해서는 안 됩니다. 각 이유를 생성한 하위 시스템을 보존하십시오.

출처 및 버전

모델, 문서 템플릿, 감시 목록 또는 정책이 변경되면 결과가 변경될 수 있습니다. 공급업체 버전, 워크플로 버전, 결정 시간, 소스 참조 및 인간이 사례를 검토했는지 여부를 저장하십시오.

API 보안 요구 사항

신원 API는 귀중한 개인 및 생체 인식 데이터를 처리하며, 공격자가 자동화할 수 있는 비즈니스 흐름을 노출합니다. OWASP API 보안 상위 10가지는 여기에 직접적으로 관련되는 위험을 강조합니다. 즉, 손상된 객체 권한 부여, 손상된 인증, 과도한 속성 노출, 무제한 리소스 소비, 민감한 흐름 자동화, 부실한 API 재고 및 타사 API에 대한 안전하지 않은 신뢰입니다.

인증 및 권한 부여

테스트 및 프로덕션에 별도의 자격 증명 및 애플리케이션을 사용하십시오. 최소 권한, 순환, 취소, 환경 격리 및 객체 수준 권한 부여를 적용하십시오. 인증된 조직은 식별자를 변경하여 다른 조직의 시도를 검색할 수 없어야 합니다.

업로드 및 리소스 제어

미디어 유형, 크기, 치수, 구조 및 예상 소스를 검증하십시오. 시간 초과, 동시성 제한, 속도 제어 및 시도 제한을 설정하십시오. 확인 호출은 컴퓨팅을 소비하며 확인당 비용이 발생할 수 있으므로, 무제한 엔드포인트는 서비스 거부 및 비용 위험을 모두 안고 있습니다.

데이터 노출

소비자에게 필요한 필드만 반환하십시오. 지원, 분석가, 개발자 및 관리자가 모두 기본적으로 전체 신원 증거를 받지 않도록 운영 역할을 분리하십시오. 로그 및 관찰 도구에서 민감한 페이로드를 수정하십시오.

웹훅 및 재생 제어

이벤트를 인증하고, 서명 확인에 필요한 원시 본문을 보존하고, 만료되거나 잘못 구성된 전달을 거부하고, 이벤트 식별자를 중복 제거하고, 정식 상태를 가져오십시오. 진행 중인 전달을 중단하지 않고 웹훅 비밀을 순환하십시오.

재고 및 버전 관리

모든 활성 엔드포인트, 버전, 호스트, 자격 증명, 콜백, SDK 및 사용 중단 날짜를 문서화하십시오. 프로덕션 데이터가 있는 그림자 테스트 엔드포인트 또는 오래된 유지 관리되지 않는 SDK는 검토된 경로를 훼손할 수 있습니다.

신분증 확인 API를 테스트하는 방법

계약 및 상태 테스트

문서화된 모든 상태, 이유, 재시도, 시간 초과 및 최종 전환을 실행하십시오. 페이지 매김, 필터링, 오류 본문, 하위 호환성 및 알 수 없는 필드 동작을 확인하십시오. 중복되고 순서가 뒤바뀐 웹훅을 시뮬레이션하십시오.

증거 테스트

예상 모집단에서 문서 유형, 국가, 스크립트, 만료 조건, 장치, 카메라 및 네트워크 전반에 걸쳐 허용되고 대표적인 샘플을 사용하십시오. 지원되지 않거나, 읽을 수 없거나, 일치하지 않거나, 조작되었거나, 진짜 증거를 별도로 추적하십시오.

사기 테스트

재생, 인쇄된 증거, 변조된 문서, 가상 카메라, 에뮬레이터, 주입된 미디어, 반복된 신원 및 자동화된 시도에 대한 승인된 공격 세트를 구축하십시오. NIST 원격 증명 요구 사항은 캡처 센서 신뢰도, 위조 미디어 분석, 보호된 채널 및 생체 인식 비교를 구분합니다. 이는 단일 메커니즘이 전체 경로를 다루지 못하기 때문입니다.

운영 테스트

완료율, 재시도, 포기, 수동 검토율, 해결 시간, 지원 문의, 웹훅 지연, 조정 및 가용성을 측정하십시오. 문서, 장치, 네트워크, 언어 및 관련 고객 그룹별로 결과를 분류하십시오.

결정 품질 테스트

하나의 “정확도” 숫자로 공급업체를 비교하지 마십시오. 의도된 임계값에서의 오수락 및 오거부, 공격별 결과, 샘플 수, 신뢰도, 응답 없음 사례 및 하위에서 확인된 결과를 검토하십시오.

개인 정보 보호 및 삭제 테스트

보존 구성, 내보내기, 삭제, 액세스 로그, 지역 처리, 하위 처리자 제어 및 공개 검토 또는 법적으로 요구되는 보류 중에 삭제 요청이 도착할 때의 동작을 확인하십시오.

공급업체를 평가하는 방법

범위 및 보증

어떤 증명 기능이 포함되어 있습니까? 어떤 보증 모델 및 독립 테스트가 적용됩니까? 어떤 구성 요소 및 버전이 테스트되었습니까? 공급업체는 합격이 무엇을 의미하고 무엇을 의미하지 않는지 설명할 수 있습니까?

적용 범위

총계뿐만 아니라 국가 및 문서 매트릭스를 요청하십시오. 오래된 장치, 여러 스크립트, 낮은 품질의 카메라 및 흔하지 않지만 합법적인 문서를 포함하여 고객이 제시하는 증거를 테스트하십시오.

개발자 경험

API 일관성, OpenAPI 품질, SDK 유지 관리, 예제, 샌드박스 시나리오, 웹훅 도구, 변경 로그 규율, 마이그레이션 정책, 상태 페이지 및 지원 에스컬레이션을 검토하십시오. 다섯 줄짜리 해피 경로 샘플은 프로덕션 통합 가이드가 아닙니다.

운영 및 설명 가능성

검토 대기열, 증거 보기, 역할 권한, 감사 로그, 이유 코드, 이의 제기 및 내보내기를 검사하십시오. 인간이 기술적 실패, 품질 재시도, 예상되는 공격 및 신원 불일치를 구별할 수 있는지 확인하십시오.

상업 및 이식성

성공 기반 대 시도 기반 청구, 검토 수수료, 최소값, 제한, 저장소, 지역 옵션 및 종료 조건을 이해하십시오. 공급업체 변경으로 인해 계정 상태를 다시 작성할 필요가 없도록 내부 고객 참조 및 정책 경계를 이식 가능하게 유지하십시오.

일반적인 통합 실수

반환 URL에서 액세스 권한 부여

사용자가 브라우저 경로를 제어합니다. 성공 리디렉션은 인터페이스 상태이지 증명이 아닙니다. 신뢰할 수 있는 백엔드에서 최종 상태를 확인하십시오.

모든 실패를 사기로 간주

권한 거부, 시간 초과, 지원되지 않는 증거, 흐림 및 의심되는 조작은 다릅니다. 이들을 혼합하면 오거부 및 사용할 수 없는 분석이 발생합니다.

웹훅을 정확히 한 번 처리

네트워크는 정확히 한 번 전달을 약속할 수 없습니다. 중복 제거, 단조로운 전환 및 정식 검색을 사용하여 최소 한 번 이벤트를 위해 설계하십시오.

전체 페이로드 로깅

편리한 디버그 로깅은 문서를 복사하고 생체 인식 데이터를 더 넓은 액세스 및 더 긴 보존 기간을 가진 시스템에 복사할 수 있습니다. 식별자, 구조화된 이유 및 제어된 증거 액세스를 사용하십시오.

샌드박스 성공 사례만 테스트

프로덕션 실패는 재시도, 오래된 장치, 에지 문서, 이벤트 지연, 버전 변경 및 검토에서 발생합니다. 실패 시나리오를 승인 스위트의 일부로 만드십시오.

정책 결정 아웃소싱

공급업체 결과는 모든 관할권, 고객 유형, 제품 위험 또는 비즈니스 제한을 알 수 없습니다. 조직의 결정 논리 및 책임성을 보존하십시오.

구현 체크리스트

프로덕션 전에 다음을 확인하십시오.

• API 자격 증명은 서버 측에 유지되며 환경 및 역할별로 범위가 지정됩니다.
• 생성 호출은 멱등적이며 안정적인 내부 고객 참조에 매핑됩니다.
• 캡처 토큰은 단기이며 예상되는 시도에 바인딩됩니다.
• 모든 상태 및 이유에는 명시적인 고객 및 백엔드 작업이 있습니다.
• 웹훅 서명, 신선도, 중복 및 순서가 테스트됩니다.
• 정식 검색은 누락되거나 지연된 이벤트를 조정합니다.
• 증거 수준 출력은 최종 고객 결정과 분리되어 유지됩니다.
• 속도, 업로드, 동시성 및 시도 제어는 자동화된 남용에 저항합니다.
• 문서, 장치, 사기, 개인 정보 보호, 접근성 및 검토 테스트는 프로덕션과 유사한 샘플을 사용합니다.
• 보존, 삭제, 사고 대응, 버전 관리 및 마이그레이션에는 소유자가 있습니다.

Didit을 이용한 신분증 확인

Didit은 구성 가능한 모듈로 신분증 확인을 제공하며, 팀이 라이브니스 감지, 장치 및 IP 분석, 그리고 워크플로 오케스트레이터를 통한 조건부 경로를 추가할 수 있도록 합니다. 공개된 독립형 신분증 확인 가격은 $0.15이며, 공개된 $0.33 KYC 번들은 신분증 확인, 패시브 라이브니스, 얼굴 매칭 및 IP 분석을 결합합니다.

가격 페이지에는 현재 모듈 요금이 나열되어 있으며, 무료 계층은 월 500회 무료 확인입니다. 이러한 제품 결과는 백엔드 소유 정책 및 고객 상태를 대체하기보다는 이를 공급해야 합니다.

자주 묻는 질문

신분증 확인 API란 무엇입니까?

신원 증거를 수집 또는 제출하고, 증거 유효성 및 신청자의 주장된 신원과의 연결에 대한 구조화된 결과를 수신하기 위한 프로그래밍 인터페이스입니다.

신분증 확인 API는 KYC API와 동일합니까?

반드시 그렇지는 않습니다. 신분증 확인은 신원 증거 및 소유자 연결에 중점을 둡니다. KYC API는 심사, 고객 위험, 워크플로, 검토, 기록 및 지속적인 새로 고침도 포함할 수 있습니다.

신원 확인은 프런트엔드에서 실행되어야 합니까?

캡처 인터페이스는 프런트엔드에서 실행될 수 있지만, 영구 자격 증명, 세션 생성, 최종 결과 검색, 정책 결정 및 고객 상태 변경은 신뢰할 수 있는 백엔드에 속합니다.

웹훅이 필요한 이유는 무엇입니까?

많은 확인 및 검토는 비동기식입니다. 웹훅은 애플리케이션에 변경 사항을 알리고, 검색 엔드포인트는 조정을 위한 정식 상태를 제공합니다.

중복 웹훅은 어떻게 처리해야 합니까?

각 이벤트를 확인하고, 식별자를 저장하고, 멱등적으로 처리하고, 이전 상태가 최신 최종 상태를 덮어쓰지 않도록 방지하고, 필요한 경우 정식 시도를 검색하십시오.

샌드박스에는 무엇이 포함되어야 합니까?

프로덕션 계약을 재현하고 성공, 재시도, 거부, 검토, 만료, 기술적 오류, 중복 이벤트, 지연된 이벤트 및 관련 이유 코드에 대한 결정적 사례를 제공해야 합니다.

API가 회사를 규정 준수하게 만들 수 있습니까?

아니요. API는 증거 및 워크플로 결과를 제공할 수 있습니다. 조직은 법률 분석, 정책, 고객 결정, 예외, 기록, 개인 정보 보호 및 지속적인 통제에 대한 책임이 있습니다.

주요 참조

• NIST SP 800-63A-4: 신원 증명 및 등록
• OWASP API 보안 상위 10가지 — 2023
• RFC 9110: HTTP 시맨틱스
• RFC 9421: HTTP 메시지 서명
• RFC 9457: HTTP API 문제 세부 정보

강력한 신분증 확인 통합은 모든 신뢰 경계를 명시적으로 만듭니다. 즉, 누가 시도를 생성하는지, 증거가 어떻게 캡처되는지, 어떤 결과가 정식인지, 이벤트가 어떻게 인증되는지, 각 이유가 무엇을 의미하는지, 어떤 시스템이 최종 고객 결정을 소유하는지 등입니다.