이 페이지에서는 디지털 신분증 및 사용자 인증 정보를 위해 Google 월렛과 통합하는 것과 관련하여 자주 묻는 질문(FAQ)에 대한 답변을 제공합니다.
온보딩 및 시작하기
Q: 신규 파트너가 신뢰 당사자(RP)로 온보딩하는 단계별 절차는 무엇인가요?
A: 과정 선택하기의 단계별 안내를 따르세요.
Q: RP 온보딩 프로세스는 일반적으로 얼마나 걸리나요?
A: 온보딩에는 일반적으로 영업일 기준 3~5일이 소요됩니다.
Q: 제출 후 활용 당사자(RP) 신청 상태를 어떻게 추적할 수 있나요?
A: 5일이 지나도 연락을 받지 못했다면 wallet-identity-rp-support@google.com에서 지원팀에 문의하세요.
Q: RP 온보딩 양식과 공식 개발자 문서는 어디에서 찾을 수 있나요?
A:
- 온보딩 양식: Google 월렛 신원 확인 파트너 문의 양식
- 개발자 문서: 디지털 신분증 개요
Q: 제공한 정보(예: 제품 이름 및 로고)는 제품 환경에서 어떻게 사용되나요?
A: 제품 이름과 로고는 사용자 대상 동의 화면에 표시되어 사용자가 어떤 신뢰 당사자가 디지털 신분증을 요청하는지 식별하는 데 도움이 됩니다. URL 및 정책 링크도 제품 환경에 표시될 수 있습니다.
Q: 개발 및 테스트를 위해 샌드박스 환경만 사용하려는 경우에도 서비스 약관에 서명해야 하나요?
A: 아니요. 서비스 약관에 동의하는 것은 테스트를 위한 필수 단계가 아닙니다.
Q: 시작하는 데 도움이 되는 참조 구현, 샘플 코드 또는 데모 애플리케이션은 어디에서 찾을 수 있나요?
A:
- GitHub 저장소: ID 참조 구현
- 테스트 웹사이트: verifier.multipaz.org
검증자 등록기관
Q: 검증자 등록 기관이란 무엇이며 어떻게 작동하나요?
A: 검증자 등록 기관은 다운스트림 클라이언트(최종 RP)를 온보딩하는 인증 기관 역할을 합니다. 최종 RP는 Google 월렛과 직접 상호작용하지 않습니다.
Q: 검증자 등록 기관 및 다운스트림 고객의 구체적인 온보딩 절차는 무엇인가요?
A: 검증자 등록기관 가이드의 단계를 참고하세요.
Q: 직접 RP 통합과 어떻게 다른가요?
A: 검증자 등록기관은 고객의 신뢰 관계를 관리하고 고객을 대신하여 Google 월렛과의 통합을 처리하는 반면, 직접 RP는 Google과의 자체 구성을 관리합니다.
Q: 검증자 등록기관에서 Google 구성의 허용 목록에 추가되는 대상은 검증자 등록기관, 최종 RP, 둘 다 중 누구인가요?
A: Google은 검증자 등록기관의 루트 CA 인증서를 허용 목록에 추가합니다. 그러면 검증자 등록기관은 각 다운스트림 최종 RP에 대한 새 리프 인증서를 발급합니다.
Q: 최종 RP, 검증자 등록 기관, Google 월렛 간에 데이터가 어떻게 흐르나요?
A: 검증자 등록 기관은 최종 RP를 위해 Google 월렛에 API 요청을 전송합니다. Google 월렛은 암호화된 사용자 인증 정보 데이터를 검증자 등록 기관에 반환하고, 검증자 등록 기관은 이를 처리하여 최종 신호를 최종 RP에 전송합니다.
Q: 화이트 라벨 솔루션의 경우 사용자 동의 흐름에 검증자 등록기관의 이름을 표시해야 하나요, 아니면 최종 RP의 이름만 표시해도 되나요?
A: 아니요. 인증자 등록기관은 세부정보를 표시하지 않도록 선택할 수 있습니다.
Q: 루트 CA 및 RP 인증서에 허용되는 키 유형과 곡선은 무엇인가요?
A: 인증서는 P-256/ECDSA를 사용하여 생성해야 합니다.
Q: 루트 CA와 RP 리프 인증서 사이에 중간 서명자 인증서를 사용할 수 있나요?
A: 예. 장기 루트 인증서를 안전하게 저장하여(예: HSM에) 운영 중간 인증서에 가끔 서명할 수 있습니다. 그런 다음 이러한 중간 인증서를 사용하여 최종 RP 리프 인증서에 서명할 수 있으므로 침해가 발생한 경우 루트에 영향을 주지 않고 더 쉽게 순환할 수 있습니다.
Q: 인증서에 필요한 수명은 어떻게 되나요?
A: 루트 CA 인증서의 수명은 10년이면 충분합니다. 최종 RP 리프 인증서는 문제가 발생할 경우 효율적으로 순환될 수 있도록 일반적으로 약 1년의 갱신 일정을 따라야 합니다.
Q: 개별 RP(Relying Party) 고객마다 별도의 리프 인증서를 관리해야 하나요?
A: 예. 초기 출시 기간에는 애그리게이터가 각 다운스트림 RP에 대해 별도의 인증서를 관리해야 합니다. 이를 통해 RP별 디스플레이 구성과 정확한 악용 추적이 가능합니다. 이로 인해 대규모 운영 오버헤드가 발생하지만 초기 출시 후 잠재적인 대안(예: RP 메타데이터 해시 사용)을 다시 검토할 예정입니다.
Q: 파트너가 여러 개의 활성 인증서를 동시에 보유할 수 있나요?
A: 예. 이 구성은 RP 또는 애그리게이터당 활성 인증서를 무제한으로 지원하므로 다양한 비즈니스 이름으로 운영하는 파트너에게 유용합니다.
Thinking Process: Q: 고유 이름(주체)은 어떤 형식이어야 하나요?
A: 고유 이름은 파트너별로 전역적으로 고유해야 합니다. 이는 Google에서 수신되는 파트너 요청을 모니터링하고 생태계 신뢰를 보장하는 데 사용하는 정적 식별자 역할을 합니다.
Q: 도메인 바인딩은 어떻게 작동하나요? 원본을 인증서에 삽입해야 하나요?
A: 도메인을 인증서 자체에 직접 삽입할 필요는 없습니다. 대신 API 호출 내의 예상 출처 매개변수를 사용하여 도메인 확인이 수행됩니다. 또한 여러 도메인을 단일 인증서와 원활하게 연결할 수 있습니다. 서명되지 않은 요청의 경우 도메인 또는 앱 패키지 이름과 디지털 지문을 사용하여 바인딩이 실행됩니다.
Q: 화이트 라벨 환경의 인증 UI에서 애그리게이터 세부정보를 생략할 수 있나요?
A: 예. 애그리게이터 정보(예: 이름, 로고, URL, 개인정보처리방침)는 검증 도구 메타데이터 내에서 완전히 선택사항입니다. 이렇게 하면 최종 RP 세부정보만 사용자에게 표시되는 완전한 화이트 라벨 솔루션이 가능합니다.
Q: 샌드박스 환경에서 테스트를 시작하려면 무엇을 제공해야 하나요?
A: 기술적인 관점에서는 샌드박스 루트 인증서만 제공하면 됩니다. 샌드박스는 프로덕션 환경을 동일하게 미러링하도록 설계되었습니다.
Q: 검증자 등록기관(애그리게이터)의 온보딩 프로세스는 직접 RP와 어떻게 다른가요?
A: 애그리게이터는 약간 수정된 절차를 거칩니다. 특정 인증자 등록기관 서비스 약관을 체결한 후에는 접수 절차가 두 부분으로 나뉩니다. 먼저 인증자 등록기관으로서의 지위를 설정하는 기본 양식을 작성한 다음, 온보딩하는 각 RP에 필요한 간소화된 양식을 작성합니다. 각 RP 제출에는 일반적으로 통합 동영상 녹화가 필요하며 검토 절차는 일반적으로 영업일 기준 2~3일이 소요됩니다.
Q: 중개자 역할을 하거나 다른 법인에 인증 서비스를 재판매하려는 고객을 온보딩할 수 있나요?
A: 아니요. Google의 현재 모델 및 선호 방식은 중첩된 리셀러 또는 중개자 모델을 지원하는 대신 검증자 등록기관(애그리게이터) 및 해당 직접 최종 RP와 직접 협력하는 것입니다.
기술 통합 및 API
Q: 요청의 기본 프로토콜은 무엇인가요? 어떤 버전이 지원되나요?
A: 기본 프로토콜은 검증 가능한 프레젠테이션을 위한 OpenID(OpenID4VP) 버전 1.0입니다.
Q: Google은 mDL 프레젠테이션에 어떤 ISO 18013-7 부속서(예: 부속서 B, C, D)를 지원하나요?
A: Google은 부록 D[현재 초안] (DC API를 사용하는 OpenID4VP)를 지원합니다.
Q: 단일 사용자 프레젠테이션에서 여러 사용자 인증 정보를 요청하도록 API 요청을 올바르게 구성하려면 어떻게 해야 하나요?
A: 두 사용자 인증 정보 유형은 동일한 JSON 요청의 단일 dcql 쿼리 객체 내에서 요청해야 합니다.
Q: API를 사용하면 가능한 모든 사용자 인증 정보 유형을 나열하지 않고도 일반 사용자 인증 정보를 요청할 수 있나요?
A: 아니요.
Q: API는 연령 인증을 어떻게 처리하나요? 정확한 생년월일을 요청할 수 있나요, 아니면 'X세 이상' 신호만 요청할 수 있나요?
A: 둘 다 지원됩니다. birth_date, age_in_years 또는 개인 정보 보호 'X 이상' 신호를 요청할 수 있습니다. 영지식 증명(ZKP)도 참/거짓 신호에 사용할 수 있습니다.
Q: PKI 인프라의 요구사항은 무엇인가요?
A: RP는 요청에 서명하기 위해 PKI가 필요합니다. 검증자 등록기관은 자체 CA 역할을 합니다.
Q: 기존 인증서를 사용할 수 있나요, 아니면 Google에서 서명한 새 인증서를 받아야 하나요?
A: RP에는 Google 또는 검증자 등록 기관에서 서명한 새 인증서가 필요합니다. 검증자 등록기관의 경우 문서의 '신뢰 설정' 단계를 따르면 Google에서 루트 인증서를 신뢰합니다.
Q: 웹과 Android 앱에 권장되는 통합 전략은 무엇인가요?
A: 전체 요청은 서버 측에서 생성되어야 합니다. Android에서는 Credman API를 사용하고 웹에서는 Digital Credentials(DC) API를 사용합니다.
Q: 개발자가 사용할 수 있는 디버깅, 로깅, 모니터링 가능성 도구에는 어떤 것이 있나요?
A: 파트너는 wallet-identity-rp-support@google.com 지원 별칭을 사용할 수 있습니다. 특정 로깅 또는 모니터링 가능성 도구는 제공되지 않습니다.
사용자 인증 정보 및 데이터
Q: 국가 및 지역별로 지원되는 디지털 신분증, 발급기관, 사용자 인증 정보는 무엇인가요?
A: 지원되는 지역은 지원되는 발급기관 및 인증서에서 확인하세요.
Q: 새로운 국가 또는 지역의 신분증은 언제부터 지원할 예정인가요?
A: Google에서는 새로운 지역을 적극적으로 추가하고 있습니다. 지원되는 발급기관 페이지에서 업데이트를 확인하세요.
Q: 발급기관에서 사용자 인증 정보를 업데이트하면 최종 사용자에게 알림이 전송되나요?
A: 예, 사용자에게 알림이 전송되고 업데이트가 자동으로 적용됩니다.
테스트 및 환경
Q: 전체 엔드 투 엔드 흐름을 테스트하기 위해 샌드박스 환경에 액세스하려면 어떻게 해야 하나요?
A: 샌드박스는 샌드박스 모드에서 열 수 있습니다.
Q: 공식 출시 지역에 거주하지 않는 파트너가 테스트를 위해 허용 목록에 추가되려면 어떻게 해야 하나요?
A: 테스트 월렛의 Gmail ID를 wallet-identity-rp-support@google.com에 이메일로 보냅니다.
Q: 프로덕션 사용자 인증 정보를 가진 누구나 시연할 수 있도록 데모용 테스트 웹사이트 또는 앱을 사용 설정하는 절차는 무엇인가요?
A: 파트너는 샌드박스 동영상 시연을 포함한 표준 RP 온보딩을 완료해야 합니다.
사용자 환경(UX)
Q: 사용자가 인증 절차를 시작할 때 디지털 신분증이 없거나 Google 월렛 앱이 설치되어 있지 않으면 사용자 환경은 어떻게 되나요?
A: 앱이 없는 사용자는 Play 스토어로 연결됩니다. ID가 없는 사용자는 절반 화면 UI를 사용하여 흐름 내에서 ID를 만들 수 있습니다.
Q: 사용자에게 인증 옵션을 표시하기 전에 사용자의 월렛에 디지털 신분증이 있는지 프로그래매틱 방식으로 감지할 수 있나요?
A: 아니요. 개인 정보 보호를 위해 API는 사용자가 호출해야 합니다.
Q: 사용자 인증 정보를 표시하기 전에 사용자가 생체 인식으로 기기를 잠금 해제하도록 요구할 수 있나요?
A: 사용자 인증(생체 인식, PIN 또는 패턴)은 기본적으로 필요하며 사용 중지할 수 없습니다.
Q: 사용자 동의 화면에서 요청된 속성의 순서를 맞춤설정할 수 있나요?
A: 아니요. Google 월렛에서 알파벳순으로 재정렬합니다.
보안 및 규정 준수
Q: 사용 사례에 서드 파티와 사용자 데이터를 다시 공유하는 작업이 포함됩니다. 서비스 약관에 따라 허용되나요?
A: 예, 제한사항이 적용될 수 있습니다. 자세한 내용은 서비스 약관을 참고하세요.
Q: 규정 준수 목적으로 디지털 ID 솔루션의 보안, 안정성, 접근성과 관련하여 어떤 문서를 사용할 수 있나요?
A: 파트너는 Trail of Bits 보안 검토를 참고할 수 있습니다.
고급 기능 및 로드맵
Q: 개인 정보 보호 연령 인증을 위한 영지식 증명(ZKP)의 기능은 무엇인가요?
A: 영지식 증명(ZKP)은 개인(증명자)이 실제 기본 데이터 자체를 공개하지 않고도 특정 신원 정보를 소유하고 있거나 특정 기준(예: 만 18세 이상, 유효한 사용자 인증 정보 보유)을 충족함을 검증자에게 증명할 수 있는 암호화 방법입니다.
Q: ZK 회로의 여러 버전은 어떻게 처리되나요?
A: RP는 사용 가능한 최신 회로를 요청하기 위해 ZK 검증자 서비스를 구현해야 합니다.
Q: 휴대전화와 웨어러블과 같은 여러 기기에서 사용자 인증 정보 공유 및 관리는 어떻게 작동하나요?
A: 사용자 인증 정보는 단일 기기에 프로비저닝되며 공유할 수 없습니다.
기타
Q: 여권이 취소되면 Google은 신분증 패스 취소를 어떻게 처리하나요?
A: 사용자는 Google 계정 설정에서 패스를 삭제할 수 있으며, 분실된 기기를 신고하여 사용자 인증 정보를 취소할 수 있습니다.
Q: mDL 취소는 어떻게 처리되나요? 실시간인가요?
A: 사용자가 트리거하거나 발급기관(DMV)에서 푸시할 수 있습니다. 기기가 온라인 상태인 경우 실시간으로 이루어지며, 그렇지 않으면 단기 보안 객체(MSO)가 만료됩니다.
Q: RP의 키 순환 정책은 무엇인가요?
A: 연간 순환이 권장됩니다.
Q: Digital Credentials API에서 지원하는 최소 Android 버전은 무엇인가요?
A: Android 9(API 수준 28) 이상입니다.
Q: Digital Credentials API를 지원하는 최소 Chrome 버전은 무엇인가요?
A: Chrome 버전 128 이상입니다.
Q: 어떤 브라우저가 Digital Credentials API를 지원하나요?
A: 브라우저 지원 세부정보는 https://digitalcredentials.dev/ecosystem-support에서 확인할 수 있습니다.
Q: 새로운 국가가 출시되면 어떤 사용자가 신분증을 추가할 수 있나요?
A: 액세스 권한은 Play 스토어의 사용자 국가 설정을 기반으로 합니다.
Q: Digital Credentials API는 iOS에서 작동하나요?
A: 예. 이 API는 Safari와 같은 지원되는 브라우저를 사용하여 작동합니다. 하지만 OpenID4VP는 Apple에서 지원되지 않습니다.